CKAD Application Design and Build Practice Question
You have a Job that should retry up to 3 times if it fails, and should be considered failed after 4 failures total (including retries). Which YAML fields should you set?
⚠ Common exam trap
Many candidates confuse `spec.backoffLimit` with the total number of allowed failures. In Kubernetes Jobs, `spec.backoffLimit` sets the number of retries after an initial failure, so to allow 4 total failures (initial + up to 3 retries), the value must be 3, not 4.
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
✓
spec.backoffLimit: 3
The `spec.backoffLimit` field in a Kubernetes Job defines the number of retries before considering the Job as failed. Setting it to 3 means the Job will retry up to 3 times after the initial failure, resulting in a total of 4 failures (1 initial + 3 retries), which matches the requirement.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
spec.activeDeadlineSeconds: 4
Why it's wrong here
spec.activeDeadlineSeconds: 4 is a Job-level timeout that caps the total wall-clock time allowed for the Job's pods to run. Once activeDeadlineSeconds expires, the Job and its pods are terminated and the Job is marked as failed, regardless of how many retries were attempted. It does not influence the retry count at all; it's purely a time-bound kill switch.
- ✗
spec.backoffLimit: 4
Why it's wrong here
spec.backoffLimit: 4 tells the Job controller to allow 4 retries after the initial pod failure, yielding 5 total pod attempts. Since the requirement is exactly 3 retries (total 4 attempts), setting 4 is one retry too many. Also note that backoffLimit is measured in retries, not total attempts, so the value must be 3 to satisfy the stated condition.
- ✗
spec.restartPolicy: OnFailure and spec.backoffLimit: 3
Why it's wrong here
spec.restartPolicy is defined in the pod template, not on the Job spec, and governs whether the kubelet restarts containers within the same pod. When set to OnFailure, the kubelet may restart the failed container, but this does not increment the Job's retry counter. The Job controller's retry behavior is controlled solely by spec.backoffLimit; combining restartPolicy: OnFailure with backoffLimit: 3 introduces a redundant mechanism that can lead to double execution or confusion, but it does not change the effective retry count to exactly 3 at the Job level.
- ✓
spec.backoffLimit: 3
Why this is correct
spec.backoffLimit: 3 is the correct field because it directly defines how many times the Job controller will re-create a pod after it fails. The initial pod run counts as the first attempt, and each subsequent re-creation is a retry, so with backoffLimit set to 3, there are exactly 3 retries and a total of 4 attempts. This precisely matches the requirement and is the standard approach for controlling retry attempts in a Kubernetes Job.
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.