A short-lived overnight report Job must stop retrying after a few failed attempts instead of restarting forever. Which approach best matches Job failure handling?
Select an answer to reveal the explanation.
Short Explanation
A Job is like a limited coupon for retries: backoffLimit is how many stamps you get before the clerk says stop. Pair that with OnFailure or Never—Always belongs to long-running controllers, not batch Jobs.
Full Explanation
A short-lived overnight report Job for a city analytics team must stop retrying after a few failed attempts instead of restarting forever. Set backoffLimit on the Job and use restartPolicy OnFailure or Never on the Pod template. Those settings bound failed municipal report attempts, protect downstream databases from retry storms, and leave a clear Failed Job state for operators to inspect after the overnight window.
Setting restartPolicy to Always on the Job’s Pod template is not valid for Jobs and conflicts with completion-oriented semantics. Converting the Job into a Deployment with a livenessProbe that kills bad Pods misuses both controllers and probes. Omitting backoffLimit and relying on a ClusterIP Service to absorb failures does nothing for Job retry budgets—Services load-balance Ready endpoints; they do not manage batch failure limits or completions.
Exam caveat: The default backoffLimit is commonly 6; activeDeadlineSeconds can add a hard time bound. Understand how OnFailure versus Never changes whether the same Pod retries or a replacement Pod is created under the Job.
Operational check: apply a deliberately failing Job with backoffLimit set to 2; kubectl get job,pods until the Job shows Failed; confirm retries stop; kubectl describe job for the conditions message and related events.