CKAD Exam Questions and Answers

A team is deploying a microservice that requires initialization of a database schema before the main application starts. The init container must run a script that writes to a shared volume. Which configuration correctly ensures the init container completes before the main container runs?

Run the script as a sidecar container that shares the volume with the main container.

Use a postStart lifecycle hook on the main container to run the script.

Define an init container with the script and mount the shared volume to both init and main containers.

Init containers always run to completion before any application container in the pod is started, and each init container must exit with status 0. By mounting the same volume in both the init container and the main container, the script can write required files that the main container reads immediately upon startup. This guarantees the initialization is fully completed before the microservice process begins.

Add a readiness probe to the main container that checks the shared volume.

Why: An init container runs to completion before any main container in the Pod starts, ensuring the database schema script finishes. By mounting the shared volume to both the init container and the main container, the script's output (e.g., schema files) is available to the main application when it launches.

You are tasked with deploying a stateless web application on a Kubernetes cluster. The application is containerized and listens on port 8080. You have created a Deployment named 'webapp' with 3 replicas, and a ClusterIP Service named 'webapp-svc' exposing port 80 targeting the application's port 8080. During testing, you notice that some requests to the service return errors while others succeed. You have verified that all Pods are running and ready. The application logs show no errors. What is the most likely cause of the intermittent failures?

The ClusterIP Service type does not support load balancing.

The Service is not configured with enough endpoints.

The Service's targetPort is set incorrectly, causing traffic to be misrouted.

The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.

Without a readiness probe, kube-proxy considers a Pod 'Ready' as soon as its containers are running, even if the application inside is still initializing, warming up, or temporarily unable to handle traffic. This causes the Service to include such Pods as endpoints, so some requests get routed to a Pod that will sporadically return 5xx errors or drop the connection. A readiness probe solves this by marking the Pod Ready only when it responds successfully to a health check, ensuring the Service’s endpoint list contains only truly available Pods.

Why: The intermittent failures are most likely caused by the absence of a readiness probe in the Deployment. Without a readiness probe, the Service's EndpointSlice controller considers all Pods with a matching label selector as ready endpoints, even if the application inside the container has not finished initializing or is temporarily unable to serve traffic. This results in the ClusterIP Service load-balancing requests to Pods that are not actually ready, causing some requests to fail while others succeed.

A DevOps engineer wants to deploy a logging sidecar container that reads log files from the main application container. Which volume type should be used to share files between the two containers?

emptyDir

emptyDir is a pod-scoped volume that is created empty when a pod is scheduled and survives only as long as the pod runs. It is mounted into all containers sharing the same lifecycle, making it the standard choice for a sidecar that reads logs written by the main application because both can access the same files without any persistent storage overhead. Its ephemeral nature is exactly what you want here—logs are consumed immediately and discarded with the pod, so no cleanup or durability guarantees are needed.

persistentVolumeClaim

configMap

hostPath

Why: An emptyDir volume is the correct choice because it provides a shared, ephemeral storage space that is created when a Pod is assigned to a node and exists as long as that Pod is running. Both the main application container and the sidecar container can mount the same emptyDir volume at different mount paths, allowing the sidecar to read log files written by the main container. This volume type is ideal for sharing files between containers in the same Pod without requiring persistent storage.

A Pod has two containers: one with a liveness probe that fails after 30 seconds. The restartPolicy is 'Never'. What state will the Pod be in after the liveness probe fails?

Running

Failed

A liveness probe failure makes the kubelet kill the container; with restartPolicy: Never the kubelet will not restart it. The container's exit is processed as a terminal status, and the Pod is marked Failed (the phase is exactly Failed when all containers in a Pod have terminated and at least one has exited non-zero or was killed). This is the expected result in this scenario rather than a crash loop.

Unknown

CrashLoopBackOff

Why: When a liveness probe fails, Kubernetes terminates the container and, because the restartPolicy is 'Never', does not restart it. The Pod transitions to the 'Failed' phase, as the container has exited with a non-zero exit code and will not be recreated. This is the expected behavior for a Pod with a single container that fails its health check under a 'Never' restart policy.

Which TWO of the following are valid concurrencyPolicy values for a CronJob?

Parallel

Forbid

Forbid is correct because it is one of the three valid concurrency policies, which prevents concurrent runs by skipping new runs if a previous one is still active.

Serial

Allow

Allow is correct because it is one of the three valid concurrency policies, and it is the default, allowing multiple CronJob instances to run concurrently.

Replace

Why: In Kubernetes, a CronJob's concurrencyPolicy controls how to handle overlapping job executions. The valid values are Allow (default, allowing concurrent runs) and Forbid (skips new run if previous is still running). Among the options given, the two correct answers are Allow and Forbid. Replace is not a valid concurrencyPolicy value; it is a distractor.

A developer wants to containerize a Node.js application. The Dockerfile should first copy only package.json and package-lock.json, run npm install, then copy the rest of the source code. Which Dockerfile best achieves this?

COPY . /app\nRUN npm install

ADD package*.json /app/\nRUN npm install\nADD . /app/

COPY package*.json /app/\nRUN npm install\nCOPY . /app/

This is the recommended pattern: copying only `package*.json` first makes the `RUN npm install` layer depend solely on dependency manifests, so it remains cached unless those files change. After install, the remaining application code is copied in a separate layer, letting source-code edits rebuild quickly without reinstalling dependencies. Using `COPY` for both operations is correct for local build-context files, and if the source contains a `node_modules` directory, a `.dockerignore` entry should exclude it to avoid overwriting the freshly installed dependencies.

ADD . /app\nRUN npm install

Why: It first copies only package.json and package-lock.json (using a wildcard pattern), runs `npm install` to leverage Docker's layer caching, and then copies the rest of the source code. This ensures that subsequent builds only re-run `npm install` when the dependency files change, not on every source code modification, which is a best practice for efficient Docker builds.

Want more Application Design and Build practice?

All Application Deployment questions

Domain 2: Application Deployment

20% of exam · 6 sample questions below

A developer wants to deploy a stateless application as a set of identical pods. They need the pods to be distributed across nodes and have stable network identities. Which resource should they use?

Job

Deployment

DaemonSet

StatefulSet

A StatefulSet assigns each pod a stable, zero-based ordinal hostname (e.g., web-0, web-1) derived from the StatefulSet name and replica index. These identities persist across rescheduling because a replacement pod always inherits the same ordinal and, if configured, the same PersistentVolumeClaim. Combined with a headless service, each pod gets a unique DNS name, which perfectly fulfills the requirement for stable network identities in a stateless or stateful application.

Why: StatefulSet is the correct resource because it provides each pod with a stable, unique network identity (e.g., pod-name-0, pod-name-1) that persists across rescheduling. While Deployment manages replicas for stateless applications, it does not assign per-pod stable hostnames. The question explicitly requires 'stable network identities' for identical pods, which is a defining feature of StatefulSet. A Service combined with a Deployment gives a stable endpoint for the set, not per-pod identities.

A company wants to ensure zero-downtime deployments for a stateless web application running in Kubernetes. They have a single Deployment with 3 replicas and a Service of type LoadBalancer. Which strategy should they use to achieve this?

Use Recreate strategy

Use RollingUpdate with maxSurge=100% and maxUnavailable=100%

Use RollingUpdate with maxSurge=25% and maxUnavailable=0

With maxUnavailable=0, the rolling update guarantees that no existing pods are terminated until replacement pods have been created and reached the Ready state. The default maxSurge=25% allows the deployment to temporarily provision additional pods beyond the desired replica count, ensuring a buffer of ready pods during the transition. This combination provides zero-downtime because traffic continues to be served by the old pods until new pods are fully ready and can take over seamlessly.

Use RollingUpdate with maxSurge=0 and maxUnavailable=25%

Why: A RollingUpdate strategy with maxSurge=25% and maxUnavailable=0 ensures that during a deployment, the desired number of replicas is always available (no downtime). maxUnavailable=0 means no old Pods are terminated until new ones are ready, and maxSurge=25% allows one extra Pod (25% of 3 replicas = 0.75, rounded up to 1) to be created before terminating old ones, maintaining capacity for zero-downtime updates.

Match each volume type to its use case.

emptyDir: Provides temporary storage that is created empty and persists for the lifetime of the pod.

emptyDir is a temporary volume that shares the pod's lifecycle.

hostPath: Mounts a file or directory from the host node's filesystem.

hostPath allows a pod to access the host's filesystem.

persistentVolumeClaim: Requests persistent storage that can be used by a pod and survives pod restarts.

PersistentVolumeClaim provides durable storage independent of pod lifecycle.

configMap: Injects configuration data as files or environment variables.

ConfigMap is used to supply non-sensitive configuration to pods.

emptyDir: Mounts a file or directory from the host node's filesystem.

hostPath: Requests persistent storage that survives pod restarts.

Why: The correct matches are: emptyDir - temporary storage, hostPath - host node directory, PVC - persistent storage, ConfigMap - configuration data. Common confusions involve mixing hostPath and PVC, or emptyDir with hostPath.

You have a Deployment named 'frontend' with 4 replicas. You want to perform a rolling update with the following constraints: the number of pods above the desired count should never exceed 1, and the number of unavailable pods should never exceed 0. Which deployment strategy configuration achieves this?

strategy: rollingUpdate: {maxSurge: 2, maxUnavailable: 0}

strategy: rollingUpdate: {maxSurge: 25%, maxUnavailable: 25%}

strategy: rollingUpdate: {maxSurge: 1, maxUnavailable: 0}

This is the correct configuration because maxSurge: 1 caps the total number of pods at one beyond the desired 4, so at most 5 pods run during the update. Meanwhile, maxUnavailable: 0 forbids terminating any old pod until a new pod has become Ready, ensuring at least 4 pods are always available to serve traffic. Together they enforce exactly the stated constraints: no more than one extra pod and zero downtime.

strategy: type: Recreate

Why: Setting `maxSurge: 1` ensures that during a rolling update, at most one additional pod is created above the desired replica count of 4, and `maxUnavailable: 0` guarantees that no pods are taken down until the new ones are ready. This satisfies the constraints of never exceeding one extra pod and never having unavailable pods.

You have a Deployment 'app' with the following strategy configuration: 'type: RollingUpdate', 'rollingUpdate: {maxSurge: 0, maxUnavailable: 1}'. You update the container image. What is the behavior during the update?

A new pod is created first, then the oldest pod is terminated.

Two old pods are terminated at a time, while new pods are created.

One old pod is terminated, then a new pod is created, repeating until all pods are updated.

With maxSurge=0, the desired replica count cannot be exceeded, and with maxUnavailable=1, at most one pod may be down during the update. This configuration forces a strictly sequential pattern: the controller first terminates an old pod, which counts as one unavailable pod, then creates a new pod to restore the replica count to the desired number. It then repeats this cycle for each remaining old replica, so one old pod is terminated, a new pod is created, and this continues until all pods are rolled over. This approach maintains availability without any temporary scaling up.

All old pods are terminated simultaneously, then new pods are created.

Why: With `maxSurge: 0` and `maxUnavailable: 1`, the RollingUpdate strategy ensures that during the update, no extra pods beyond the desired replica count are created (surge is zero), and at most one pod can be unavailable at any time. The Deployment controller first terminates an old pod (making one unavailable), then creates a new pod to replace it, repeating this process until all pods are updated. This guarantees a controlled, sequential rollout with minimal disruption.

You need to perform a canary deployment using a Service and two Deployments (stable and canary). Which TWO resources or configurations are typically used to route a percentage of traffic to the canary? (Select TWO)

Service Mesh (e.g., Istio VirtualService)

Service Mesh provides fine-grained traffic splitting.

A single Service with multiple label selectors

NetworkPolicy

Ingress with canary annotation

Ingress controllers like NGINX support canary.

HorizontalPodAutoscaler

Why: A Service Mesh like Istio uses a VirtualService resource to define traffic routing rules based on weights (e.g., `weight: 90` for stable and `weight: 10` for canary). This allows fine-grained, percentage-based traffic splitting between two different Kubernetes Services or subsets, which is a core requirement for canary deployments.

Want more Application Deployment practice?

All Application Environment, Configuration and Security questions

Domain 3: Application Environment, Configuration and Security

25% of exam · 6 sample questions below

A container runs as root (UID 0) but the security policy requires the container to run as non-root user 1000. Which pod security context setting should be added?

runAsNonRoot: true

runAsUser: 1000

runAsUser: 1000 directly sets the container process's user ID to 1000, overriding any default user defined in the image's Dockerfile or container runtime configuration. This makes the process run as UID 1000 regardless of the image's original settings, and it is the only way to deterministically satisfy a policy that explicitly requires UID 1000. It is the exact, explicit control needed when the container starts as root by default.

fsGroup: 1000

privileged: false

Why: `runAsUser: 1000` explicitly sets the container's user ID to 1000, ensuring the container process runs as a non-root user. This directly satisfies the security policy requirement to run as UID 1000, overriding the default root (UID 0) behavior.

You are a Kubernetes administrator responsible for a production cluster. A development team has deployed a Pod named 'app-pod' that runs a container with a PostgreSQL database. The team reports that the Pod is failing to start with an error: 'Error: container has runAsNonRoot and image will run as root (runtime error)'. The Pod YAML is as follows:

```yaml apiVersion: v1 kind: Pod metadata: name: app-pod spec: containers: - name: db image: postgres:latest securityContext: runAsNonRoot: true ```

The team wants to ensure the container runs securely without running as root. What is the BEST course of action?

Add `runAsUser: 999` to the container's securityContext to run the container as the postgres user.

Setting `runAsUser: 999` explicitly instructs the kubelet to start the container process with UID 999, which is non-zero. This satisfies the `runAsNonRoot: true` validation because the runtime verifies that the effective UID is not 0. Since the Postgres image commonly defines a `postgres` user with UID 999, this aligns with the image's intended user and avoids running as root. This is the standard, least-privilege fix for a `runAsNonRoot` enforcement failure.

Remove `runAsNonRoot: true` from the securityContext to allow the container to run as root.

Increase the Pod's resource limits because the error is due to insufficient memory.

Create a PodSecurityPolicy that allows running as root.

Why: The PostgreSQL official image runs as the 'postgres' user with UID 999 by default. Adding `runAsUser: 999` to the container's securityContext overrides the user to a non-root UID, satisfying the `runAsNonRoot: true` constraint and allowing the container to start without the runtime error.

Match each Kubernetes concept to its definition.

Pod: Smallest deployable unit in Kubernetes that can contain one or more containers.

Pod is correctly defined as the smallest deployable unit.

Service: An abstraction that defines a logical set of Pods and a policy to access them.

Service is correctly defined as an abstraction for Pod access.

Deployment: A controller that provides declarative updates for Pods and ReplicaSets.

Deployment is correctly defined as a controller for declarative updates.

Ingress: An API object that manages external access to services in a cluster, typically HTTP.

Ingress is correctly defined as managing external HTTP access.

Pod: An abstraction that defines a logical set of Pods and a policy to access them.

Service: Smallest deployable unit in Kubernetes that can contain one or more containers.

Why: Correct matches are Pod with smallest deployable unit, Service with logical set and access policy, Deployment with declarative updates, and Ingress with external HTTP access. Common confusions include swapping Pod and Service definitions.

A pod is running with the following SecurityContext: securityContext: runAsUser: 1000 runAsGroup: 2000 fsGroup: 3000 What UID and GID does the process inside the container use?

UID 1000, GID 3000

UID 1000, GID 2000

runAsUser sets UID, runAsGroup sets GID. Both apply to the container process.

UID 0, GID 2000

UID 3000, GID 2000

Why: The `runAsUser` and `runAsGroup` fields in the Pod's SecurityContext directly set the UID and GID for the container's main process. Here, `runAsUser: 1000` sets the process UID to 1000, and `runAsGroup: 2000` sets the process GID to 2000. The `fsGroup: 3000` field only applies to the group ownership of mounted volumes, not to the process's primary GID.

A developer wants to ensure that a pod runs with a non-root user and cannot gain root privileges. Which SecurityContext settings should be used?

securityContext: allowPrivilegeEscalation: false

securityContext: runAsNonRoot: true

securityContext: runAsNonRoot: true allowPrivilegeEscalation: false

Combining runAsNonRoot: true with allowPrivilegeEscalation: false provides defense in depth: the former ensures the container does not start as root, while the latter prevents the process from gaining any additional privileges beyond its current non-root identity, such as via setuid execution or other escalators. This layered approach both satisfies the non-root mandate and blocks a common privilege escalation vector, making it the correct configuration for secure pod deployment.

securityContext: runAsNonRoot: true allowPrivilegeEscalation: true

Why: Setting `runAsNonRoot: true` enforces that the container's user ID is non-zero (non-root), and `allowPrivilegeEscalation: false` prevents the container from gaining additional privileges beyond its initial set, such as through setuid binaries or kernel capabilities. Together, they ensure the pod runs as a non-root user and cannot escalate to root, satisfying the developer's requirement.

A pod is running with a service account that has been granted a Role to get pods. The pod's code uses the Kubernetes API from within the container. However, the API call fails with a 403 Forbidden error. Which file should the pod read to obtain the authentication token?

/var/run/secrets/kubernetes.io/serviceaccount/token

Correct. The token file is mounted at that path.

/etc/kubernetes/admin.conf

/var/run/secrets/kubernetes.io/serviceaccount/namespace

/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

Why: The pod's service account token is automatically mounted at /var/run/secrets/kubernetes.io/serviceaccount/token. This token is a signed JWT that the pod uses to authenticate to the Kubernetes API server. Without reading this file, the pod cannot present valid credentials, resulting in a 403 Forbidden error.

Want more Application Environment, Configuration and Security practice?

All Application Observability and Maintenance questions

Domain 4: Application Observability and Maintenance

15% of exam · 6 sample questions below

You are debugging a network issue: a pod 'frontend' cannot reach a service 'backend' in the same namespace. The service endpoints are empty. What is the most likely cause?

The pod 'frontend' is not in the same namespace as the service 'backend'.

The service selector does not match the labels of any running pod.

Endpoints are created by the endpoint controller, which watches pods and compares each pod's labels against the service's spec.selector. If no running pod carries every label key/value in that selector, the Endpoints object remains with an empty address list, even though the service itself exists. This is the textbook cause of an empty Endpoints resource and the correct answer to this symptom.

The pod's container port is different from the service port.

The kube-proxy is misconfigured and not updating iptables rules.

Why: B is correct because the most common reason for empty endpoints in a Kubernetes service is that the service's selector does not match the labels of any running pod. The service controller continuously monitors pods and updates the Endpoints object to include only those pods whose labels match the service's selector. If no pods match, the endpoints list remains empty, causing the frontend pod to fail to reach the backend service.

You need to collect metrics from an application running in a pod. The application exposes metrics on port 8080 at /metrics in Prometheus format. Which resource should you configure to allow Prometheus to scrape these metrics?

Create an Ingress resource that exposes the /metrics endpoint externally.

Create a ConfigMap with the Prometheus scrape configuration and mount it into the Prometheus pod.

Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.

This is the standard approach for Prometheus operator's annotation-based discovery: the service's annotations `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` allow the auto-discovery component to generate a scrape_config targeting the service's endpoints on port 8080. The Service provides a stable DNS name and selects the pods, so even if pod IPs change, Prometheus can dynamically look up the current endpoints. This is distinct from the static ConfigMap method because it enables automatic, label-based target discovery across the cluster.

Add a PrometheusRule resource that defines the scrape target.

Why: Prometheus uses a pull-based model to scrape metrics from targets. By adding the `prometheus.io/scrape: "true"` and `prometheus.io/port: "8080"` annotations to a Service that selects the pod, you enable Prometheus's built-in service discovery to automatically detect and scrape the `/metrics` endpoint on port 8080 without manual configuration.

You are designing a health check strategy for a web application. Which TWO probe types should you configure to ensure that traffic is only sent to pods that are ready to serve?

Readiness probe

Controls whether a pod is included in service endpoints.

TCP socket probe

Startup probe

Delays liveness and readiness checks until startup completes, preventing premature traffic.

HTTP GET probe

Liveness probe

Why: A Readiness probe (Option A) is specifically designed to determine whether a pod is ready to serve traffic. If the probe fails, the pod is removed from the Service's endpoints, ensuring traffic is only sent to pods that are ready. This directly fulfills the requirement of controlling traffic routing based on pod readiness.

Based on the exhibit, why is the container being killed and restarted?

The readiness probe is failing, causing the pod to be considered not ready and restarted.

The liveness probe is failing, causing the container to be restarted.

The liveness probe is the probe that determines whether the application inside the container is healthy; if it fails, the kubelet kills the container and restarts it according to the pod's restartPolicy. The exhibit shows a restart counter increasing while the container's status cycles through Running, then terminated, then Running again, which exactly matches the behavior of a failing liveness probe. A liveness probe failure would cause the kubelet to record the reason as "Liveness probe failed: <message>" in the pod events, leading to the automatic restart observed in the exhibit.

The container is running out of memory (OOM).

The container image is being pulled repeatedly.

Why: In Kubernetes, a failing liveness probe causes the kubelet to restart the container. The exhibit shows the container being killed and restarted, which is consistent with liveness probe failure. Option A is incorrect because a failing readiness probe does not restart the container; it only marks the pod as not ready and removes it from service endpoints. Option C is incorrect: OOM would result in a different error message (OOMKilled). Option D is incorrect: repeated image pulls would cause ImagePullBackOff, not a restart after running.

A Pod is stuck in CrashLoopBackOff. You run 'kubectl logs mypod' and get no output. What is the most likely cause?

The Pod is not ready yet.

The application crashes before writing any logs.

The application crashes before writing any logs. This is the correct answer because empty output from `kubectl logs` means the process exited before emitting anything to stdout/stderr. Many applications crash during early startup—such as on missing configuration, failed dependency connection, or a panic in initialization—before reaching any logging call. The container repeatedly restarts, and each attempt produces no logs, so the crash loop yields empty log output.

The liveness probe is failing.

The container never started due to a missing image.

Why: When a Pod is in CrashLoopBackOff and `kubectl logs mypod` returns no output, the most likely cause is that the application crashes before it can write any logs to stdout/stderr. The container starts, runs briefly, and exits before the logging framework initializes, so no log data is captured by the container runtime.

You are a platform engineer at a company that runs a microservices architecture on Kubernetes. The application consists of a frontend service (Node.js), a backend API (Go), and a PostgreSQL database. All components are deployed in the same namespace 'production'. Recently, the backend API has been experiencing intermittent 503 errors from the frontend. The backend API Pods have CPU limits set to 500m and memory limits to 256Mi. The backend API exposes metrics at /metrics and has a liveness probe (HTTP GET /healthz) and a readiness probe (HTTP GET /ready). You notice that during traffic spikes, the backend API Pods are restarted frequently. You examine the metrics and see that memory usage spikes to 250Mi during high load. What is the most likely cause of the restarts and 503 errors?

The liveness probe is misconfigured and should use a TCP check instead.

The memory limit is set too low; the container is being OOMKilled during traffic spikes.

The container's memory limit is 256Mi, yet during traffic spikes memory reaches roughly 250Mi plus cache overhead, which pushes usage over the cgroup limit. When that limit is breached, the kernel OOM killer terminates the container, and restartPolicy causes the observed restarts. The liveness probe is not involved because the kernel acts independently of any probe status.

The readiness probe is failing because the application is not ready, but the liveness probe keeps it alive.

The CPU limit is too low, causing the container to be throttled and timeout.

Why: The backend API Pods are being restarted frequently because the memory limit of 256Mi is too close to the observed memory usage of 250Mi during traffic spikes. When memory usage hits the limit, the Linux kernel's OOM killer terminates the container (OOMKilled), causing the Pod to restart. This restart leads to temporary unavailability, which the frontend sees as 503 errors.

Want more Application Observability and Maintenance practice?

All Services and Networking questions

Domain 5: Services and Networking

20% of exam · 6 sample questions below

A developer wants to expose a set of Pods on a specific port on each node's IP. Which Service type should be used?

LoadBalancer

ClusterIP

NodePort

NodePort exposes on each node's IP at a static port.

ExternalName

Why: NodePort is the correct Service type because it exposes each Pod's port on a static port (the NodePort) on every node's IP address. This allows external traffic to reach the Pods by accessing any node's IP on that specific port, fulfilling the requirement to expose the Pods on a per-node IP basis.

You are responsible for a multi-tier application running in a Kubernetes cluster. The frontend Pods communicate with backend Pods via a Service named 'backend' in the same namespace. Recently, the frontend team reported that the backend Service is intermittently unreachable. You inspect the backend Pods and notice that they are all running and ready, but the Endpoints object for the 'backend' Service shows only a subset of the Pod IPs. You also notice that the backend Pods have a readiness probe configured that checks an HTTP endpoint '/healthz'. The readiness probe has a periodSeconds of 5 and failureThreshold of 3. The application logs show occasional spikes in response time on the /healthz endpoint, sometimes exceeding 15 seconds. You need to resolve the intermittent unavailability without removing the readiness probe. Which action should you take?

Remove the readiness probe configuration from the backend Pods

Add a second readiness probe on a different endpoint to increase redundancy

Change the Service type from ClusterIP to NodePort to bypass endpoint issues

Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness

Increasing failureThreshold to 10 and periodSeconds to 10 gives the readiness probe a much larger tolerance window: the kubelet would need 10 consecutive failed probes spaced 10 seconds apart (i.e., about 90 seconds of continuous failures) before marking the backend Pod unready. This directly addresses transient slowness because brief spikes in latency or occasional failed HTTP responses will not cause the Pod to be dropped from Service endpoints. The tradeoff is that truly dead backends take longer to be removed, but for a multi-tier app that only needs to tolerate temporary degradation, this is the correct, targeted tuning.

Why: Increasing the failureThreshold to 10 and periodSeconds to 10 gives the readiness probe more time (100 seconds total) to tolerate transient slowness on the /healthz endpoint, preventing premature removal of Pod IPs from the Endpoints object. This keeps all backend Pods in the ready state during response time spikes, ensuring the Service remains reachable.

A user creates a Deployment with 3 replicas and a Service of type ClusterIP. The Service selects pods with label 'app: web'. The user wants external clients to access the application via a stable IP address. Which additional resource is required?

A second Service of type NodePort

A NetworkPolicy

An Ingress resource

An Ingress resource is the correct approach because it manages external HTTP(S) access to services using hostnames and URL paths, and it is backed by an ingress controller that typically provisions a stable external IP or load balancer. This gives clients a single, predictable address to reach the deployment, while also supporting TLS termination and advanced routing rules without creating multiple NodePorts.

A ConfigMap

Why: A ClusterIP Service is only reachable within the cluster. To expose a Deployment to external clients via a stable IP, an Ingress resource is required because it provides HTTP/HTTPS routing from outside the cluster to the Service, typically using a load balancer or a reverse proxy like NGINX. Ingress also offers a stable external IP (or hostname) and can manage TLS termination, making it the correct choice for external access with a stable endpoint.

A developer creates a headless Service named 'db' to discover all database pod IPs. The Service selects pods with label 'app: db'. The pods are assigned IPs 10.0.0.1, 10.0.0.2, and 10.0.0.3. When a client performs a DNS lookup for 'db', what will it receive?

The IP of the first pod only

The cluster IP of the Service

All three pod IPs as separate A records

DNS returns all pod IPs as A records for the headless Service.

A round-robin list of pod IPs

Why: A headless Service (clusterIP: None) does not have a cluster IP. Instead, DNS queries for the Service name return A records for all pods matching the selector. Since the Service selects pods with label 'app: db', the DNS lookup for 'db' returns the three pod IPs (10.0.0.1, 10.0.0.2, 10.0.0.3) as separate A records, allowing direct pod-to-pod communication.

You are a platform engineer managing a Kubernetes cluster version 1.28. A development team has deployed a microservice application called 'order-processor' in the 'prod' namespace. The application consists of a frontend Pod 'frontend' and a backend Pod 'backend', each with a single container. The frontend needs to communicate with the backend using a headless Service named 'backend-svc' that selects Pods with label 'app:backend'. The backend Pods are expected to scale horizontally, and the frontend uses a DNS lookup to discover all backend Pod IPs for client-side load balancing. However, after deploying, the frontend is unable to resolve 'backend-svc' to any IP addresses. The backend Pod is running and has the correct label 'app:backend'. The Service 'backend-svc' is defined as a ClusterIP with clusterIP: None. The frontend container has the 'default' DNS policy. What is the most likely cause of the failure?

The headless Service must have the 'publishNotReadyAddresses: true' field to include not-ready Pods.

In a headless Service (`clusterIP: None`), DNS records are generated per ready Pod rather than for a single virtual IP. By default, Kubernetes excludes Pods whose readiness condition is false from DNS A/AAAA record lists, which means a not-ready backend Pod will not appear as a DNS entry and the frontend cannot reach it by name. Adding `publishNotReadyAddresses: true` to the Service spec instructs the cluster DNS to publish the addresses of all backing Pods regardless of readiness, enabling the frontend to discover even not-ready backends. This is the only correct option because it identifies the missing configuration attribute that directly affects DNS population.

The Service and frontend are in different namespaces; the DNS name must be fully qualified.

The backend Pod does not have a readiness probe defined, so it is not considered ready and not added to DNS records.

The frontend Pod's DNS policy is set to 'None' which disables DNS resolution.

Why: A headless Service (clusterIP: None) creates DNS A/AAAA records only for Pods that are in the Ready state. If the backend Pod is running but not ready (e.g., due to a failing readiness probe or other conditions), the Service excludes it from DNS. Setting publishNotReadyAddresses: true on the Service would include all matching Pods regardless of readiness, allowing the frontend to discover the backend IPs. Since the frontend cannot resolve any IPs, the most likely cause is that the Service is not configured to serve not-ready Pods.

Which of the following Service types exposes a pod on a static port on each node's IP address?

LoadBalancer

ExternalName

ClusterIP

NodePort

NodePort exposes the Service on each Node's IP at a static port.

Why: NodePort is the correct answer because it exposes a pod on a static port (in the range 30000-32767) on every node's IP address. When a Service of type NodePort is created, Kubernetes opens that port on all nodes in the cluster, forwarding traffic to the target pods. This allows external access to the pod via any node's IP and the assigned static port.

Want more Services and Networking practice?