CKAD Practice Test 2 — 25 Questions

Question 1

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?

Accepted Answer

The service selector does not match the labels of any running pod.. 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.

Answer

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

Answer

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

Answer

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

Question 2

A developer wants to inject database credentials into a pod as environment variables. The credentials are stored in a Kubernetes Secret named 'db-creds' with keys 'username' and 'password'. Which pod spec snippet correctly injects both values as environment variables?

Accepted Answer

envFrom:
- secretRef:
    name: db-creds. `envFrom` with `secretRef` injects all key-value pairs from a Secret as environment variables into the pod. This directly satisfies the requirement to inject both 'username' and 'password' from the 'db-creds' Secret without needing to specify each key individually.

Answer

env:
- name: username
  valueFrom:
    secretKeyRef:
      name: db-creds
      key: username

Answer

envFrom:
- configMapRef:
    name: db-creds

Answer

envFrom:
- secretKeyRef:
    name: db-creds

Question 3

A pod in the 'production' namespace is in a CrashLoopBackOff state. The pod has been running successfully for several days. You run 'kubectl describe pod app-pod -n production' and see the message: 'OOMKilled'. What is the MOST appropriate action to resolve this issue?

Accepted Answer

Increase the memory limit in the pod's container resource specification. The pod is in CrashLoopBackOff due to OOMKilled, meaning the container exceeded its memory limit and was terminated by the Linux kernel's Out-Of-Memory (OOM) killer. Increasing the memory limit in the pod's container resource specification allows the container to use more memory without being killed, directly resolving the OOM condition.

Answer

Increase the CPU request for the container

Answer

Delete and recreate the pod to clear the crash loop

Answer

Delete the namespace and redeploy all workloads

Question 4

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?

Accepted Answer

The Deployment lacks a readiness probe, causing the Service to route traffic to Pods that are not ready.. 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.

Answer

The ClusterIP Service type does not support load balancing.

Answer

The Service is not configured with enough endpoints.

Answer

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

Question 5

A pod's container has securityContext with runAsNonRoot: true but no runAsUser set. The container image has a user 'appuser' with UID 1001. Will the pod run successfully?

Accepted Answer

Yes, because the container image user is non-root. When `runAsNonRoot: true` is set in the pod's security context without an explicit `runAsUser`, Kubernetes checks the container image's user (as defined in the Dockerfile `USER` directive). If that user is non-root (UID 1001 in this case), the container runs as that user, satisfying the non-root requirement. The pod will start successfully because the image user is non-root, and no explicit `runAsUser` is required.

Answer

No, because runAsNonRoot requires an explicit runAsUser

Answer

No, because the container image user is unknown

Answer

Yes, because runAsNonRoot is ignored if runAsUser is not set

Question 6

You need to schedule a task that runs every day at 2:00 AM. The task should be allowed to run even if a previous instance is still running. Which concurrencyPolicy should you set in the CronJob spec?

Accepted Answer

Allow. Setting `concurrencyPolicy: Allow` in a CronJob spec permits a new job instance to start even if a previous instance is still running. This is the default behavior when the field is omitted, and it directly satisfies the requirement that the task must run at 2:00 AM regardless of any overlapping executions.

Answer

Replace

Answer

Forbid

Answer

Ignore

Question 7

You have a Deployment that uses a ConfigMap. You update the ConfigMap, but the pods are not picking up the changes. What is the MOST efficient way to force the pods to use the new ConfigMap values without downtime?

Accepted Answer

Run 'kubectl rollout restart deployment/deployment-name'. A is correct because `kubectl rollout restart deployment/deployment-name` triggers a new ReplicaSet and gracefully terminates old pods while creating new ones, which will mount the updated ConfigMap. This avoids downtime by leveraging the Deployment's rolling update strategy, ensuring the new pods read the current ConfigMap data from the volume mount or environment variable reference.

Answer

Delete the pods manually and let the ReplicaSet recreate them

Answer

Delete the ConfigMap and recreate it with the same name

Answer

Edit the Deployment to add an annotation, triggering a rollout

Question 8

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?

Accepted Answer

Create a Service with annotation 'prometheus.io/scrape: "true"' and 'prometheus.io/port: "8080"'.. 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.

Answer

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

Answer

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

Answer

Add a PrometheusRule resource that defines the scrape target.

Question 9

You have a Service that exposes a Deployment. Some pods are not receiving traffic. 'kubectl get endpoints my-service' shows only 2 out of 3 pod IPs. What is the most likely cause?

Accepted Answer

One pod is not ready (readiness probe failing). The most likely cause is that one pod is not ready because its readiness probe is failing. Services only forward traffic to pods that are in the Ready state, as reflected in the Endpoints object. If a pod fails its readiness probe, it is removed from the list of endpoints, even if it is running and has the correct labels.

Answer

The Deployment has a wrong targetPort

Answer

The Service type is NodePort

Answer

One pod has a different label than the Service selector

Question 10

A Pod in a namespace with a ResourceQuota that sets 'limits.cpu: 4' and 'limits.memory: 8Gi' is being created with the following container resources: requests: cpu: 2, memory: 4Gi; limits: cpu: 4, memory: 8Gi. The namespace also has a LimitRange with default limits of cpu: 500m, memory: 512Mi. Which statement is true about this resource configuration?

Accepted Answer

The Pod will be admitted because it respects both the ResourceQuota and the LimitRange. B is correct because the Pod explicitly sets its own limits (cpu: 4, memory: 8Gi) and requests (cpu: 2, memory: 4Gi), which are within the ResourceQuota's 'limits.cpu: 4' and 'limits.memory: 8Gi' constraints. The LimitRange default limits only apply to containers that do not specify limits; since this Pod specifies limits, the defaults are ignored. The Pod is admitted as it satisfies both admission controllers.

Answer

The Pod will have its limits overridden by the LimitRange defaults because limits must be set

Answer

The Pod will be rejected because the limits exceed the LimitRange default

Answer

The Pod will be rejected because requests must equal limits

Question 11

Which kubectl command streams logs from a pod named 'web-pod' in real-time?

Accepted Answer

kubectl logs -f web-pod. The `-f` flag (short for `--follow`) tells kubectl to stream logs from the pod in real-time, similar to `tail -f` on a file. This is essential for live monitoring of application output as it is generated.

Answer

kubectl logs --since=5m web-pod

Answer

kubectl logs --tail=100 web-pod

Answer

kubectl logs web-pod

Question 12

A developer configures a liveness probe for a container that takes a long time to start (about 120 seconds). The probe uses httpGet on port 8080 with a path '/healthz'. The probe is configured with initialDelaySeconds=10, periodSeconds=10, failureThreshold=3. The pod enters CrashLoopBackOff. What is the MOST likely cause?

Accepted Answer

The liveness probe is failing too early because initialDelaySeconds is too low for the slow-starting container. The liveness probe is configured with initialDelaySeconds=10, which means Kubernetes will start probing 10 seconds after the container starts. Since the application takes about 120 seconds to become healthy, the probe will fail immediately. With failureThreshold=3 and periodSeconds=10, the probe will fail after 30 seconds (3 * 10s), causing Kubernetes to restart the container before it has finished initializing, leading to CrashLoopBackOff.

Answer

The failureThreshold should be increased to 10

Answer

The httpGet path '/healthz' is incorrect and should be '/ready'

Answer

The readiness probe is misconfigured and should be used instead of a liveness probe

Question 13

Match each volume type to its use case.

Accepted Answer

emptyDir: Provides temporary storage that is created empty and persists for the lifetime of the pod.. 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.

Answer

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

Answer

hostPath: Requests persistent storage that survives pod restarts.

Question 14

Match each Kubernetes concept to its definition.

Accepted Answer

Pod: Smallest deployable unit in Kubernetes that can contain one or more containers.. 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.

Answer

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

Answer

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

Question 15

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?

Accepted Answer

Increase the failureThreshold to 10 and periodSeconds to 10 to tolerate transient slowness. 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.

Answer

Remove the readiness probe configuration from the backend Pods

Answer

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

Answer

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

Question 16

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?

Accepted Answer

StatefulSet. 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.

Answer

Job

Answer

Deployment

Answer

DaemonSet

Question 17

Which command forwards port 8080 on the local machine to port 80 on a pod named 'web-pod'?

Accepted Answer

kubectl port-forward pod/web-pod 8080:80. `kubectl port-forward` creates a direct tunnel from a local port to a port on a specific pod. The syntax `kubectl port-forward pod/web-pod 8080:80` forwards local port 8080 to port 80 on the pod named 'web-pod', enabling local access to the pod's service without requiring a Service object.

Answer

kubectl expose pod web-pod --port=8080 --target-port=80

Answer

kubectl proxy --port=8080 --target=pod/web-pod:80

Answer

kubectl exec web-pod -- curl http://localhost:8080

Question 18

You need to debug a pod that is not responding. Which command attaches an ephemeral debug container to a running pod named 'web-pod'?

Accepted Answer

kubectl debug -it web-pod --image=busybox --target=web-container. `kubectl debug` with the `--image` flag creates an ephemeral container in the specified pod for interactive debugging. The `-it` flag provides an interactive TTY, and `--target=web-container` attaches the ephemeral container to the same Linux namespace as the target container, allowing direct troubleshooting of the unresponsive pod without modifying its original containers.

Answer

kubectl debug web-pod --copy-to=debug-pod --image=busybox

Answer

kubectl attach web-pod

Answer

kubectl run debug --image=busybox -it

Question 19

A CronJob is configured with concurrencyPolicy: Forbid and schedule: '*/5 * * * *'. The first job takes 7 minutes. What happens when the next scheduled time arrives?

Accepted Answer

The new job is skipped. C is correct because when `concurrencyPolicy: Forbid` is set, the CronJob controller skips creating a new job if the previous job is still running at the next scheduled time. Since the first job takes 7 minutes and the schedule is every 5 minutes, the new job is skipped to prevent overlapping executions.

Answer

The previous job is terminated

Answer

The new job waits until the previous job completes

Answer

A new job is created immediately

Question 20

During a rolling update, you want to ensure that at most 2 pods are unavailable at any time. Which field should you set in the Deployment spec?

Accepted Answer

spec.strategy.rollingUpdate.maxUnavailable: 2. `spec.strategy.rollingUpdate.maxUnavailable` specifies the maximum number of Pods that can be unavailable during a rolling update. Setting `maxUnavailable: 2` ensures that at most 2 Pods are unavailable at any time, allowing the update to proceed while maintaining the desired availability.

Answer

spec.strategy.type: Recreate

Answer

spec.replicas: 2

Answer

spec.strategy.rollingUpdate.maxSurge: 2