A one-off database migration Job failed and must be run again. What is the appropriate application approach?
Select an answer to reveal the explanation.
Short Explanation
A failed migration Job is a checked-off chore that went wrong—you start a fresh chore (new Job), you do not promote it into a forever-running Deployment or DaemonSet. Completion work gets another finite attempt.
Full Explanation
When a one-off database migration Job for a records system fails, the appropriate application approach is to create a new Job (or delete and recreate the Job) to start another completion-oriented run. Failed Jobs retain status and retry history; many fields are immutable, so recreation is the normal, auditable way to attempt DDL again under change control.
Increasing the Deployment replica count so migrations run continuously beside the API risks repeated migrations, partial locks, and coupling batch DDL to the web controller’s lifecycle. Changing the failed Job into a DaemonSet so every node retries the migration forever is dangerous for schema changes. Setting the Service externalTrafficPolicy to Local does not reschedule or re-run Jobs—it only affects external traffic routing.
Exam caveat: Treat each migration attempt as an explicit Job apply with a unique name in CI. Do not convert failed batch work into long-running Deployments. Verify backoffLimit and logs before rerunning against production-like schemas.
Operational check: kubectl get job; kubectl delete job migrate-… or apply a new manifest; kubectl logs on the new Pod; confirm Job status Succeeded before starting API traffic that depends on the new schema.