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 sidecar container running alongside the app B. An init container that runs to completion before the app container starts C. A separate Job in the same namespace D. A postStart lifecycle hook on the app container

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 once B. Up to 11 pods exist at a time, and capacity never drops below 10 C. Up to 10 pods exist and 1 is unavailable at a time D. The update is rejected as invalid

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 ConfigMap and mount it B. Put the value in a Secret and reference it with secretKeyRef in env C. Hard-code it as a container arg D. Store it in an annotation

Answer **Correct: B** **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 container is restarted B. The pod is removed from Service endpoints until the probe passes again C. The pod is evicted from the node D. The Deployment rolls back

Answer **Correct: B** **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 concurrencyPolicy: Forbid B. Set concurrencyPolicy: Replace C. Set suspend: true D. Set successfulJobsHistoryLimit: 1

Answer **Correct: A** **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. persistentVolumeClaim B. hostPath C. emptyDir D. configMap

Answer **Correct: C** **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. `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 is blocked B. It is unaffected C. It is allowed only to frontend D. It depends on the CNI plugin

Answer **Correct: B** **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. securityContext.privileged: false C. A PodDisruptionBudget D. A ResourceQuota

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 is evicted B. The pod is throttled toward its request share but keeps running C. The pod is OOM-killed D. The pod gets 500m regardless

Answer **Correct: B** **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 B. LoadBalancer Service C. ClusterIP Service D. Ingress

Answer **Correct: C** **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. completions: 5, parallelism: 2 B. completions: 2, parallelism: 5 C. replicas: 5, parallelism: 2 D. backoffLimit: 5

Answer **Correct: A** **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 rollout status then kubectl rollout pause B. kubectl get pods -w then delete the Deployment C. kubectl rollout undo immediately D. kubectl scale --replicas=0

Answer **Correct: A** **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. ConfigMap volume contents never update B. The projected files do update eventually, but the process must re-read them or be restarted C. You must delete the pod for any volume update D. Only Secrets support live updates

Answer **Correct: B** **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 exec -it <pod> -- sh B. kubectl debug -it <pod> --image=busybox --target=<container> C. kubectl logs -f <pod> D. Rebuild the image with a shell and redeploy

Answer **Correct: B** **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 B. Kustomize with overlays patching a common base C. Separate full copies per environment D. kubectl apply with --set

Answer **Correct: B** **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