CKAD Application Design and Build Practice Question
A CronJob is configured with concurrencyPolicy: Forbid. The scheduled job takes longer than the interval between schedules to complete. What happens when the next scheduled time arrives while the previous job is still running?
⚠ Common exam trap
Test-takers frequently assume Kubernetes will queue or delay the job (Option D) because that seems logical, but the CronJob controller does not implement queuing — it strictly follows the concurrencyPolicy (Allow, Forbid, or Replace) without any built-in retry or backlog mechanism.
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 CronJob controller skips the new execution and logs a warning
When `concurrencyPolicy: Forbid` is set, the CronJob controller ensures that only one instance of the job runs at a time. If the previous job is still running when the next scheduled time arrives, the controller skips the new execution entirely and logs a warning (e.g., 'job already running'). This prevents overlapping executions, which is critical for workloads that must not run concurrently.
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 running job is killed to make room for the new one
Why it's wrong here
This would be the behavior of concurrencyPolicy: Replace, where the CronJob controller actively terminates the old Job's Pods to let a new Job start. With Forbid, the controller does not touch the running Job; it merely declines to create another one, leaving the in-flight execution intact. Killing an already-running Job also risks leaving partial state or losing work, which is why Forbid is often chosen for non-idempotent tasks.
- ✗
The new job starts immediately, overriding the running one
Why it's wrong here
Overriding implies that the new Job supersedes the old one, which is closer to Replace. Under Forbid, the controller checks whether any Job created by this CronJob is still active and, if so, completely forgoes creating the new Job—there is no 'override' or takeover. The schedule simply comes and goes without action; the running Job continues unaffected.
- ✓
The CronJob controller skips the new execution and logs a warning
Why this is correct
When the scheduler fires and concurrencyPolicy: Forbid is set, the CronJob controller inspects the CronJob's .status.active list for Job references that still exist and have not completed. If at least one is found, the controller skips creating a new Job and emits an event (often surfaced as a warning, e.g., 'skipped' or 'already active') to record the missed schedule. No retry is made at that point; the next scheduled time governs future executions.
- ✗
The new job is queued and starts after the running job completes
Why it's wrong here
Forbid does not hold or enqueue the new run; it deliberately discards the trigger. The new Job only starts at a future scheduled time if the previous Job has completed by then, not in direct response to the earlier one finishing. There is no concurrency policy that queues Jobs—Allow would start it concurrently, Replace would start immediately, and Forbid simply skips.
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.