A city finance team needs a report that runs once each night, finishes, and then stops. Which OKE workload object fits that pattern?
Select an answer to reveal the explanation.
Short Explanation
A Job is a sprint that ends when the work is done; a CronJob is the calendar that starts those sprints. A Deployment is for always-on services, so it is the wrong home for a once-a-night report.
Full Explanation
A city finance report that runs once each night, finishes, and stops fits a CronJob that creates a Job on the nightly schedule. Jobs model run-to-completion work: the Pod executes, succeeds or fails per restart policy, and stops. CronJob is the calendar controller that instantiates those Jobs on a timetable. That pattern matches batch municipal reporting without leaving a permanent serving replica idle all day.
A Deployment with a single replica that never exits fails by concept because Deployments keep Pods continuously running for long-lived services; forcing a batch into a Deployment either never exits cleanly or requires awkward sleep loops. A StatefulSet that pins the report Pod to one node fails because StatefulSets provide stable identity and ordered storage for stateful services, not scheduled finish-and-stop batch work. A DaemonSet so every worker runs the report simultaneously fails because DaemonSets place a Pod on every (selected) node for node-local agents, which multiplies a single nightly report into cluster-wide duplicate work.
Exam caveat: CronJob concurrency and history limits matter—overlapping nightly Jobs can double-bill or double-write finance outputs if a prior run is still going. Operational check: set an explicit schedule and successful/failed history limits, run a one-off Job first to validate the report image, then watch the CronJob create a completed Job after the window and confirm no leftover Pods remain Running.