CKAD Application Design and Build Practice Question
Which THREE of the following are valid fields in a CronJob specification?
⚠ Common exam trap
In the CKAD exam, a common pitfall is confusing CronJob-level fields with Job template fields. Fields like completions and parallelism belong to the Job template (under jobTemplate.spec), not to the CronJob specification itself.
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
✓
successfulJobsHistoryLimit
In a CronJob specification, `successfulJobsHistoryLimit` is a valid field that controls how many completed jobs are retained in the cluster's history. This field defaults to 3 and helps manage resource usage by automatically cleaning up old Job records after the limit is exceeded.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
completions
Why it's wrong here
The `completions` field is not part of the CronJob specification itself; it belongs inside the `jobTemplate.spec` that defines the Jobs the CronJob will create. A CronJob only configures schedule, concurrency, history limits, and the Job template. Setting `completions` directly at the CronJob level would be invalid and is a common misconception when learners conflate the controller resource with its generated Jobs.
- ✓
successfulJobsHistoryLimit
Why this is correct
`successfulJobsHistoryLimit` is a valid top-level field in a CronJob's `spec` that limits how many successful Job runs are retained after completion, with a default of 3. It works alongside `failedJobsHistoryLimit` to manage the cluster's storage footprint and keep `kubectl get cronjob` history list clean. This field is uniquely CronJob-level; it has no meaning inside a single Job.
- ✓
concurrencyPolicy
Why this is correct
`concurrencyPolicy` is a valid CronJob `spec` field that governs whether new Jobs are allowed to overlap with an in-progress run. It accepts three values: `Allow` (default), which lets concurrent Jobs run; `Forbid`, which skips the scheduled invocation while a Job is still running; and `Replace`, which cancels the current Job and starts a new one. This policy is evaluated by the CronJob controller at each scheduled time, distinct from per-Job pod scheduling semantics.
- ✓
schedule
Why this is correct
`schedule` is a required, top-level field in a CronJob's `spec` that provides the cron expression defining when Jobs are created, such as `*/5 * * * *`. It uses UTC by default, and the CronJob controller interprets it to compute the next run times. Without a valid schedule, the CronJob cannot exist, making it the core trigger for the resource.
- ✗
parallelism
Why it's wrong here
`parallelism` is not a CronJob-level field; it lives in the Job's `spec` within the `jobTemplate`. It controls how many Pods can run concurrently for a given Job, complementing `completions` to determine the Job's execution shape. Since CronJob merely wraps a Job template, parallelism must be nested under `jobTemplate.spec.parallelism`, not set directly at the CronJob root.
Go deeper
Related to this question
About these practice questions
Courseiva writes every CKAD question from scratch — 826 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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.