CKAD Application Design and Build Practice Question
A user runs: kubectl apply -f job.yaml. The Job spec has backoffLimit: 0. The pod fails immediately. What happens?
⚠ Common exam trap
Watch out — candidates often confuse `backoffLimit` with pod restart policies (e.g., `restartPolicy: OnFailure`), but `backoffLimit` controls the number of retries at the Job level, not pod restarts, and a value of 0 means no retries, not infinite retries.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The Job enters a Failed state
When `backoffLimit: 0` is set in a Job spec and the pod fails immediately, the Job controller does not retry the pod because the backoff limit is zero. According to Kubernetes Job semantics, the Job is considered failed once the number of failures reaches the `backoffLimit` (0 in this case), so the Job transitions to a Failed state without any further pod creation or retries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The Job is retried indefinitely
Why it's wrong here
Setting backoffLimit: 0 in a Job spec declares that the controller may attempt a Pod creation zero times after the first failure. When the single Pod fails, the controller increments the Job's failure counter to 1, immediately exceeds the allowed limit, and therefore does not schedule any replacement Pod or retry loop. An indefinite retry would require backoffLimit to be unset or a positive value, so this behavior is impossible with this configuration.
- ✗
The pod is restarted until it succeeds
Why it's wrong here
A Job's restart semantics operate at the Pod level: the controller creates new Pods to replace failed ones, while the container restartPolicy is normally Never or OnFailure for Jobs. With backoffLimit: 0, after the first Pod fails the Job controller refuses to create another Pod, so there is no loop of Pod recreations. The kubelet may restart the container only if the Pod's restartPolicy permits, but that does not make the Job retry the Pod until success; the controller's retry budget is already exhausted.
- ✓
The Job enters a Failed state
Why this is correct
The Job controller evaluates the failure count against backoffLimit after a Pod fails; because the limit is 0, the first failure already equals the maximum allowed retries. As a result, the controller marks the Job with the Failed condition, records the failed Pod in status, and stops any further reconciliation. No pending retries remain, so the Job cannot be Active or Complete; its terminal state is Failed.
- ✗
A new pod is created automatically
Why it's wrong here
With backoffLimit: 0, the Job controller's retry algorithm determines that no additional attempts are allowed, so it does not generate a replacement Pod for the failed one. Automatic creation of a new Pod would require the current retry count to be less than the configured limit, but the first failure already matches that limit. Consequently, only the original failed Pod exists and the Job transitions to Failed rather than scheduling new work.
Go deeper
Related to this question
About these practice questions
This CKAD question is part of Courseiva's 826-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CKAD practice question is part of Courseiva's free CNCF certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the CKAD exam.