A municipal queue worker must finish a fixed number of batch items with controlled concurrency. Which Job settings express that intent?
Select an answer to reveal the explanation.
Short Explanation
Think factory orders: completions is "how many finished widgets we need," parallelism is "how many assembly lines may run together." Jobs speak that language; Deployments just keep N copies alive forever.
Full Explanation
A municipal queue worker that must finish a fixed number of batch items with controlled concurrency should use Job settings: configure completions for how many successful Pods are required and parallelism for how many may run at once. That expresses “process N work units with at most M in flight,” protecting downstream billing or notice systems from stampeding while still draining the queue.
Setting Deployment replicas equal to queue depth ignores Job semantics and leaves always-on replicas after the queue drains. Using a CronJob schedule of * so parallelism emerges from schedule overlap alone creates uncontrolled storms of Jobs every minute. Setting restartPolicy to Never on a Deployment does not emulate completions; Deployments continuously reconcile replica counts and are not completion-oriented controllers.
Exam caveat: completions counts successful Pods; parallelism caps concurrency; backoffLimit caps retries. The Pod template restartPolicy must be OnFailure or Never. Indexed Jobs appear in newer clusters but the completions/parallelism model is the CKAD core.
Operational check: kubectl get job -o yaml | grep -E 'completions|parallelism|succeeded|failed'; ensure running Pod count stays ≤ parallelism; confirm the Job becomes Complete when succeeded reaches completions.