During a Helm upgrade of a billing chart, a one-shot migrate Job runs before the new Deployment pods start. At awareness depth, what Helm feature typically drives that Job?
Select an answer to reveal the explanation.
Short Explanation
Hooks are like stage cues in a play: before the main actors walk on, a short scene (your migrate Job) runs. Charts wire those cues so upgrades do not forget the migration step.
Full Explanation
During a Helm upgrade of a billing chart, a one-shot migrate Job that runs before new Deployment pods start is typically driven by chart hooks—annotations that schedule Jobs or other resources at defined lifecycle points (pre-upgrade, post-install, and similar). At CKAD awareness depth, recognize hooks as the chart mechanism for ordered migrate-then-roll patterns in municipal billing upgrades rather than inventing controllers.
Why the other options fail by concept: ReplicaSet controllers create Pods for ReplicaSets; they do not generally create migration Jobs before every Pod. Ingress TLS annotations do not trigger database migrations on handshake. kubectl wait alone does not invent migration Jobs without chart configuration defining them.
Exam caveat: Hook Jobs can block upgrades if they fail—read hook weight/delete policies. Hooks may need RBAC to talk to databases or manage Jobs. Not every chart uses hooks; some rely on init containers instead—inspect templates. Failed hooks leave releases in failed states visible in helm history.
Operational check: helm get manifest / helm template and search for helm.sh/hook annotations on Jobs before upgrading billing. During upgrade, kubectl get jobs,pods -n <ns> --watch to see the migrate Job complete before new Deployment Pods roll. On failure, kubectl logs the Job Pod and consider rollback per runbook.