Skip to content

Certified Kubernetes Application Developer (CKAD) - Practice Questions

15 questions for CKAD prep, weighted toward configuration and security (25%) with design, deployment, and networking at 20% each.

CKAD is performance-based, so these are conceptual reinforcement. Nothing replaces typing kubectl under a timer.

Cert page: exams/kubernetes/ckad/

Question 1

Scenario: An application container needs a configuration file generated by another process before it starts. The generator runs for about 10 seconds and then exits. What pattern fits?

A. A separate Job in the same namespace that runs the generator, relying on the app pod to find the file afterwards B. An init container that runs to completion before the app container starts C. A postStart lifecycle hook on the app container that launches the generator as the container starts D. A sidecar container running alongside the app that keeps the generator running for the life of the pod

Answer **Correct: B** **Why:** Init containers run to completion in order, before any app container starts, and share volumes with them. That is exactly a "prepare something then exit" task. A sidecar runs concurrently and would not guarantee the file exists at app start. A separate Job has no shared volume and no ordering guarantee. A `postStart` hook runs after the container has already started, which is too late.

Question 2

Scenario: A Deployment has replicas: 10, maxUnavailable: 0, and maxSurge: 1. How does a rolling update behave?

A. All 10 pods are replaced at the same moment, causing a brief outage while the new replicas start B. Up to 11 pods exist at a time, and available capacity never falls under 10 C. Up to 10 pods exist and 1 is unavailable at a time, so capacity dips to 9 during each replacement D. The update is rejected as invalid, because maxSurge must be 0 whenever maxUnavailable is 0

Answer **Correct: B** **Why:** `maxUnavailable: 0` forbids dropping below the desired count, so a new pod must become ready before an old one is removed. `maxSurge: 1` allows one extra pod above desired, so the peak is 11. This is the safest but slowest setting. Note that both cannot be zero, since that would make progress impossible.

Question 3

Scenario: A pod must read a database password without the value appearing in the pod spec or in kubectl get pod -o yaml output as plaintext you typed.

A. Put the value in a Secret and reference it with secretKeyRef in env, so RBAC controls who can read the value B. Put the value in a ConfigMap and mount it as a file, since ConfigMaps are encrypted at rest by default C. Store it in a pod annotation, which the API server hides from kubectl get output for non-admin users D. Hard-code it as a container arg in the manifest and rely on the image registry's access controls and private repository settings to protect it

Answer **Correct: A** **Why:** A Secret keeps the value out of the workload manifest and lets RBAC control who can read it. ConfigMaps are for non-confidential data and get no special access treatment. Args and annotations are plainly visible in the pod spec. Be honest about the limit: Secrets are base64-encoded, not encrypted, unless encryption at rest is enabled on etcd.

Question 4

Scenario: A pod's readiness probe fails intermittently under load. What is the observable effect?

A. The pod is evicted from the node, because a failing readiness probe signals node pressure to the kubelet B. The container is restarted by the kubelet each time the probe fails, as with a liveness probe C. The pod is taken out of the Service endpoints until the probe passes again, but the container keeps running and is not restarted D. The Deployment rolls back to the previous ReplicaSet as soon as one pod reports not ready

Answer **Correct: C** **Why:** Readiness controls endpoint membership only. A failing readiness probe pulls the pod out of load balancing but leaves it running, which is the intended behavior for a temporarily overloaded pod. Restarting on failure is what a liveness probe does, and confusing the two is the classic CKAD mistake: a liveness probe that is really a readiness check will restart-loop a busy app.

Question 5

Scenario: A CronJob should never run two instances at once, even if one run overruns its schedule.

A. Set successfulJobsHistoryLimit: 1, so only one finished Job is kept and later runs wait for it to be cleaned up B. Set concurrencyPolicy: Forbid, so overlapping runs are skipped C. Set suspend: true, which pauses new runs while the current one finishes and then resumes automatically D. Set concurrencyPolicy: Replace, which cancels the running Job so the new run can start

Answer **Correct: B** **Why:** `Forbid` skips the new run if the previous one is still active. `Replace` also avoids overlap but kills the running job to start the new one, which is different behavior and usually wrong for work you do not want interrupted. `suspend` stops scheduling entirely. The history limit only controls how many finished Jobs are retained.

Question 6

Scenario: Two containers in the same pod need to share files. Which volume type is the simplest fit?

A. emptyDir mounted into both containers of the pod B. persistentVolumeClaim bound to a PersistentVolume provisioned by a StorageClass for the pod C. configMap volume populated with the files that each container writes at runtime D. downwardAPI volume exposing pod labels and annotations as files

Answer **Correct: A** **Why:** `emptyDir` is created when the pod is scheduled and lives as long as the pod, which matches intra-pod sharing exactly. A PVC works but adds a storage dependency you do not need for ephemeral data. `hostPath` couples the pod to a node and is a security concern. `downwardAPI` volumes only expose pod metadata, and `configMap` volumes are read-only.

Question 7

Scenario: A NetworkPolicy is applied selecting the api pods with policyTypes: [Ingress] and one rule allowing traffic from frontend pods. What happens to the api pods' outbound traffic?

A. It depends on the CNI plugin, because each plugin chooses its own default for the direction not listed B. It is blocked, because the pod is now isolated both ways C. It is allowed only to frontend, because the rule's peer applies to the pod's traffic in each direction D. It is unaffected, because only the listed Ingress direction is restricted

Answer **Correct: D** **Why:** A NetworkPolicy only restricts the directions listed in `policyTypes`. Declaring Ingress alone leaves egress completely open. This is why "we added a NetworkPolicy" is not the same as "the pod is isolated." To restrict outbound you must add an Egress policy, and note that a default-deny egress policy usually needs an explicit allow for DNS to kube-dns on port 53.

Question 8

Scenario: A container must not run as root and must not be able to gain additional privileges.

A. securityContext.runAsNonRoot: true and allowPrivilegeEscalation: false B. A PodDisruptionBudget with minAvailable: 1, which limits how many pods voluntary disruptions can remove C. A ResourceQuota on the namespace that caps the CPU and memory the pods may request in total D. securityContext.privileged: false to disable privileged mode

Answer **Correct: A** **Why:** `runAsNonRoot` makes the kubelet refuse to start a container whose image would run as UID 0, and `allowPrivilegeEscalation: false` sets the `no_new_privs` flag so setuid binaries cannot escalate. `privileged: false` is already the default and does not cover either requirement. PDBs govern voluntary disruptions and quotas govern resource consumption.

Question 9

Scenario: A pod requests 100m CPU with a limit of 500m. The node is saturated. What happens?

A. The pod gets 500m regardless, because a limit is a guaranteed allocation that the scheduler reserves on the node B. The pod is OOM-killed like a memory overrun C. The pod is throttled toward its request share but keeps running D. The pod is evicted, because a node under CPU pressure always removes pods that exceed their request

Answer **Correct: C** **Why:** CPU is a compressible resource, so contention produces throttling, not termination. Memory is the incompressible one: exceeding a memory limit gets the container OOM-killed. Knowing which resource kills and which merely slows is a frequent exam distinction.

Question 10

Scenario: You need to expose a pod to other pods in the cluster only, with a stable name.

A. NodePort Service, which opens a port on every node and is meant for traffic from outside B. ClusterIP Service, reachable only from inside the cluster through a stable virtual IP and DNS name C. Ingress, which routes external HTTP and HTTPS requests to Services using host and path rules D. LoadBalancer Service, which provisions a cloud load balancer with an external address

Answer **Correct: B** **Why:** ClusterIP is the default and is reachable only inside the cluster, with a DNS name of `..svc.cluster.local`. NodePort and LoadBalancer both expose externally. Ingress is an L7 router that still needs a Service behind it.

Question 11

Scenario: A Job should run 5 completions with at most 2 running at once.

A. backoffLimit: 5, which retries failed pods five times B. completions: 5 and parallelism: 2, so at most two pods run at a time C. replicas: 5, parallelism: 2, as in a Deployment spec D. completions: 2, parallelism: 5, so five pods run at a time until two succeed

Answer **Correct: B** **Why:** `completions` is how many successful pods the Job needs and `parallelism` caps concurrency. Jobs have no `replicas` field. `backoffLimit` is the retry ceiling before the Job is marked failed, which is a different control entirely.

Question 12

Scenario: After kubectl apply of an updated Deployment, you want to watch the rollout and stop it if it stalls.

A. kubectl scale --replicas=0 on the Deployment to remove every pod B. kubectl rollout undo immediately, before checking whether the new ReplicaSet is progressing at all C. kubectl get pods -w then delete the Deployment if pods stay Pending D. kubectl rollout status to watch, then kubectl rollout pause to freeze it

Answer **Correct: D** **Why:** `rollout status` blocks and reports progress, and `rollout pause` freezes the rollout in place so you can inspect without losing the old ReplicaSet. `rollout undo` is the recovery step after you have decided it failed. Deleting or scaling to zero takes the service down, which is a worse outcome than a paused half-rollout.

Question 13

Scenario: A ConfigMap mounted as a volume is updated with kubectl edit. The application does not see the change.

A. You must delete the pod for any volume update to take effect B. ConfigMap volume contents never update after the pod starts C. The files do update eventually, but the process must re-read them or be restarted D. Only Secrets support live updates, because the kubelet refreshes Secret volumes but treats ConfigMaps as immutable

Answer **Correct: C** **Why:** The kubelet refreshes projected ConfigMap and Secret volumes periodically, so the file on disk changes without a restart. What does not happen automatically is the application noticing. Values injected as environment variables are the genuinely static case: those are fixed at container start and require a restart. `subPath` mounts also do not receive updates.

Question 14

Scenario: You need to debug a distroless container that has no shell.

A. kubectl logs -f <pod> to stream the container output while the failure happens B. Rebuild the image with a shell added and redeploy, losing the failing pod's live state C. kubectl debug -it <pod> --image=busybox --target=<container> to attach an ephemeral debug container D. kubectl exec -it <pod> -- sh to open a shell inside the running container

Answer **Correct: C** **Why:** `kubectl debug` attaches an ephemeral container to the running pod, sharing its namespaces, so you get a shell and can see the target's process tree without changing the image. `exec` fails when there is no shell binary. `logs` helps but does not let you inspect the filesystem or network. Rebuilding works but is slow and reintroduces the shell you deliberately removed.

Question 15

Scenario: A team wants one manifest set customized per environment without templating language.

A. Helm with values files, using Go templating in the chart to render the per-environment differences B. kubectl apply with --set flags to override fields for each environment at deploy time C. Separate full copies of each manifest per environment D. Kustomize with overlays patching a common base, built into kubectl -k

Answer **Correct: D** **Why:** Kustomize is deliberately template-free: a base plus per-environment overlays that patch it, built into `kubectl` as `-k`. Helm is the templating answer and is a fine tool, but the question rules it out. Full copies drift. `kubectl apply` has no `--set` flag.

Where to go deeper