Skip to main content

Practice exam · CNCF

Certified Kubernetes Application Developer (CKAD) practice exam

50
questions
120
minutes
66%
to pass the practice exam
60
questions in the bank

Short answer

The Certified Kubernetes Application Developer (CKAD) practice exam has 50 questions in 120 minutes, with a 66% passing mark, as configured here. The fastest way to know whether you are ready is to sit a full exam on the clock and read your score by domain, not only the total.

Domains covered

  • Application Design and Build
  • Application Deployment
  • Application Environment, Configuration and Security
  • Application Observability and Maintenance
  • Services and Networking

Sample questions, with explanations

Three questions from the bank, open to read.

Question 1 · Application Design and Build

A StatefulSet runs a primary-replica database where pod ordinal 0 must always be fully Ready before ordinal 1 starts, because replicas bootstrap by streaming from the primary. After switching the StatefulSet's podManagementPolicy to Parallel to speed up rollouts, the replicas now intermittently fail to bootstrap. What is the correct understanding?

  1. Parallel guarantees ordinal 0 starts first but skips its readiness gate; add an initContainer to ordinal 0 to slow it down
  2. Parallel only affects scale-down ordering, so the bootstrap failures must be caused by a misconfigured readiness probe
  3. podManagementPolicy controls volume attachment order, not pod startup order; the issue is a PVC binding race
  4. Parallel podManagementPolicy launches all pods at once without waiting for predecessors to become Ready; revert to OrderedReady to preserve the ordinal startup dependency ✓ (correct)
Why this is correct

The correct understanding is that podManagementPolicy: Parallel tells the StatefulSet controller to create (and delete) all pods simultaneously without waiting for any predecessor to become Running and Ready. Since the replicas depend on the primary (ordinal 0) being Ready first, Parallel breaks that ordering — reverting to OrderedReady (the default) restores the guarantee that ordinal N waits for ordinal N-1 to be Ready. 'Parallel only affects scale-down ordering' is wrong: it affects both creation and deletion, and creation ordering is precisely what was lost. 'podManagementPolicy controls volume attachment order' is wrong: it governs pod startup/termination sequencing, not PVC binding; each pod still binds its own stable PVC regardless of policy. 'Parallel guarantees ordinal 0 starts first but skips its readiness gate' is wrong — Parallel makes no first-start guarantee at all; all pods are launched together, so adding an initContainer to ordinal 0 would not enforce any cross-pod ordering.

Question 2 · Application Observability and Maintenance

A liveness probe uses `exec` with the command `["cat", "/tmp/healthy"]`, periodSeconds: 5, timeoutSeconds: 1, failureThreshold: 3. The app deletes /tmp/healthy when it deadlocks. Operators report that even with periodSeconds 5 and failureThreshold 3, the container sometimes takes much longer than ~15 seconds to restart after the file disappears. Which factor BEST explains the extra delay?

  1. An exec probe runs a process inside the container each period; under heavy CPU contention the probe command itself can be slow to schedule or exceed timeoutSeconds, stretching the time to accumulate three consecutive failures. ✓ (correct)
  2. Liveness exec probes are evaluated by the API server, which batches them on a 60-second control loop, so restarts are always delayed.
  3. failureThreshold only counts failures that occur on even-numbered periods, doubling the effective time.
  4. The probe waits for the readinessProbe to fail first before it is allowed to count any failures.
Why this is correct

The correct option reflects how exec probes actually work: each probe forks a process inside the container, and under CPU starvation that process may be slow to start or exceed timeoutSeconds, so 'failure' detection per period drifts and the three consecutive failures take longer than the nominal 15 seconds to accumulate. The 'API server batches on a 60s loop' option is wrong because probes are executed by the kubelet on the node, not the API server, and there is no 60-second batching. The claim that failureThreshold only counts even-numbered periods is fabricated; consecutive failures are counted every period. Liveness does not wait on readiness; the two probes are independent and a liveness failure does not require a readiness failure first.

Question 3 · Application Environment, Configuration and Security

A Pod in namespace `team-a` has no `serviceAccountName` set. The application inside needs to list Pods in its own namespace via the Kubernetes API. An admin has created a Role granting `list` on `pods` and a RoleBinding referencing the ServiceAccount `pod-reader` in `team-a`. The application still receives a 403 Forbidden. Assuming the token is correctly mounted and valid, what is the most likely cause?

  1. A Role can only bind to users and groups, never to ServiceAccounts, so the binding silently has no effect.
  2. The token mounted in the Pod is for the node's kubelet identity, which RBAC always denies for namespaced API calls.
  3. RoleBindings cannot grant `list` on Pods; a ClusterRoleBinding is required for any verb on the `pods` resource.
  4. The Pod is running under the namespace's `default` ServiceAccount, not `pod-reader`, so the RoleBinding's permissions do not apply to it. ✓ (correct)
Why this is correct

Correct: When `serviceAccountName` is omitted, the Pod runs as the namespace's `default` ServiceAccount. The RoleBinding grants permissions to `pod-reader`, a different identity, so the `default` SA the Pod actually authenticates as has no `list pods` permission and gets 403. The fix is to set `serviceAccountName: pod-reader` (or bind the role to `default`). The distractor claiming RoleBindings can't grant `list` on Pods is false — namespaced resources like Pods are exactly what Roles/RoleBindings are for; ClusterRoleBindings are for cluster-scoped access, not a requirement here. The kubelet-identity distractor is wrong because Pods authenticate with their ServiceAccount's projected token, not the node's credentials. The claim that Roles cannot bind to ServiceAccounts is the opposite of reality — `subjects` in a RoleBinding explicitly supports `kind: ServiceAccount`.

Take the full practice exam

  • 50 questions drawn from the bank, with a 120-minute timer
  • Score by domain and a review of every question
  • An AI tutor to talk through each question you miss
  • What you miss feeds your study plan
Start the practice examStudy the path first

Independent, unofficial practice exam. CNCF and the exam name are trademarks of their owners; UpSkillScore is not affiliated with them. Format and passing mark are the exam's configuration in UpSkillScore, not an official statement.

Frequently asked questions

How many questions does the Certified Kubernetes Application Developer (CKAD) practice exam have?

It has 50 questions and a 120-minute limit. The passing mark of the practice exam is 66%.

Is this the official Certified Kubernetes Application Developer (CKAD) exam?

No. It is an independent practice exam built to match the structure of the real one. It does not replace the official exam.

Do I need an account to take it?

You can read the structure and sample questions without an account. Taking the full timed exam, scoring by domain and the AI tutor need one.