A nightly GIS tile rebuild must run to completion and then exit. Which workload is appropriate?
Select an answer to reveal the explanation.
Short Explanation
Batch work is a to-do list item, not a 24/7 receptionist. A Job runs the rebuild, counts success, and stops—unlike a Deployment that would keep restarting the "finished" process forever.
Full Explanation
Nightly GIS tile rebuilds for a municipal mapping team are finite batch work: the process should run until it succeeds, then stop. Configure a Job with completions (and optional parallelism) so Kubernetes creates Pods until the required number of successful Pods is reached and then marks the Job Complete. That matches overnight tile pipelines that must not linger as always-on Deployments consuming cluster capacity after the work is done.
A Deployment whose liveness probe deliberately fails when the job finishes abuses health checks to stop replicas and still leaves a long-running controller reconciling Pods. A DaemonSet that rebuilds tiles forever on every node is continuous per-node agent behavior, not a scheduled batch completion. A bare Pod with restartPolicy Always loops without Job completions tracking, backoffLimit, or a clear Succeeded state operators can monitor.
Exam caveat: Job Pod templates must use restartPolicy OnFailure or Never—not Always. Distinguish completions (successful finishes required) from parallelism (concurrent Pods). CKAD expects Job for run-to-completion application workloads such as GIS rebuilds.
Operational check: kubectl apply -f tile-job.yaml; watch kubectl get jobs for the Completions column; kubectl get pods -l job-name=… until Succeeded; confirm no new Pods appear after success; kubectl describe job for conditions.