A payments API Pod must finish a database schema migration before the main container starts listening. Which multi-container pattern enforces that gate?
Select an answer to reveal the explanation.
Short Explanation
Init containers are the warm-up act: the headliner (your app) does not walk on stage until the warm-up finishes and exits cleanly. Perfect for “migrate first, then listen.”
Full Explanation
A payments API Pod that must finish a database schema migration before the main container starts listening should use an init container. Init containers run to completion in order before application containers start; when the migration init exits 0, the main payments container may begin. That gate prevents the API from accepting city payment traffic against an incomplete schema.
A sidecar that keeps migrating in a loop while the app already serves traffic races schema changes with live requests and is the wrong lifetime. An ambassador proxy that rewrites SQL without a separate setup step addresses outbound adaptation, not ordered pre-start migrations. A postStart lifecycle hook on the Service object is invalid—lifecycle hooks belong on containers, and Services do not run migration hooks.
Exam caveat: Init containers share volumes and networking with the Pod but run sequentially before app containers. Failures block startup (CrashLoop in Init:…). Do not confuse init with sidecars that remain running.
Operational check: kubectl describe pod and confirm Init containers show Complete before the app becomes Running; kubectl logs <pod> -c migrate-init; break the migration on purpose and verify the app container never starts until init succeeds.