CKAD Application Design and Build Practice Question
Which field in a CronJob spec specifies the maximum number of successful jobs that should be retained?
⚠ Common exam trap
Test-takers frequently confuse `backoffLimit` (retry logic) with history limits, or invent plausible-sounding field paths like `.spec.jobHistory.succeeded` that mimic the correct field but use incorrect nesting or naming.
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.successfulJobsHistoryLimit
The `.spec.successfulJobsHistoryLimit` field in a CronJob spec explicitly controls the number of successful jobs that are retained after completion. This field defaults to 3 and, when set to 0, suppresses the retention of any successful job history, directly managing cluster resource usage by limiting the accumulation of completed Pods.
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.jobTemplate.spec.backoffLimit
Why it's wrong here
The .spec.jobTemplate.spec.backoffLimit field belongs to the underlying Job template created by the CronJob and controls how many times the Job restarts its pods before being marked failed. It does not affect how many completed Job objects are retained in the cluster, which is explicitly governed by successfulJobsHistoryLimit and failedJobsHistoryLimit at the CronJob spec level. Even if a Job ultimately succeeds after retries, backoffLimit will not prune old Job entries.
- ✓
.spec.successfulJobsHistoryLimit
Why this is correct
The correct field is .spec.successfulJobsHistoryLimit, a top-level CronJob spec attribute that sets the maximum number of successfully completed Job objects to keep. Its default value is 3, and setting it to zero disables retention entirely, causing the CronJob controller to delete each successful Job as soon as it finishes. This field directly controls the number of historical Job objects visible in the cluster, distinct from failedJobsHistoryLimit which governs failed Jobs.
- ✗
.spec.jobHistory.succeeded
Why it's wrong here
There is no .spec.jobHistory.succeeded field in the CronJob API; the schema only defines successfulJobsHistoryLimit and failedJobsHistoryLimit as direct children of the CronJob spec. A field named jobHistory.succeeded would imply a nested object with a 'succeeded' key, which Kubernetes would reject as an unknown field during validation. The actual history limits are simple integer fields, not a map of job states.
- ✗
.spec.history.successfulJobsLimit
Why it's wrong here
The path .spec.history.successfulJobsLimit is invalid because the CronJob spec does not contain a nested history object; the correct field is successfulJobsHistoryLimit, which combines the word 'History' into the field name. Substituting 'successfulJobsLimit' also loses the required 'HistoryLimit' suffix, making it non-existent in the API. Misremembering the field structure can lead to errors in manifest validation.
Go deeper
Related to this question
About these practice questions
One of 826 original CKAD practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.