An init container must read database credentials that the main app also uses. What is an appropriate approach?
Select an answer to reveal the explanation.
Short Explanation
Secrets are shared keys on the building keyring: hand a copy to the setup crew (init) and to the staff (app) who both need the door opened—don’t paint the password on the hallway ConfigMap.
Full Explanation
An init container that must read database credentials the main application also uses should mount the same Secret—as a volume or as environment variables—into both the init and app containers that need it. Secrets are referenced per container from Pod spec volumes/env; sharing one Secret object keeps municipal database passwords consistent for migration init and runtime without baking credentials into either image.
Baking credentials into the init image only and omitting them from the app fails as soon as the app must connect after init exits. Storing passwords in a publicly readable ConfigMap labeled “secret” misuses ConfigMaps—labels do not provide confidentiality. Putting credentials only on a node hostPath and hoping both containers find them destroys portability and weakens security reviews.
Exam caveat: Prefer Secret volumes with tight defaultMode for files, or env injection when the runtime expects variables. Never commit credentials into container layers. Init and app can each reference the same secretName.
Operational check: kubectl apply the Secret; reference it from both containers; kubectl describe pod for mount events; confirm init completes and the app connects; scan image history to ensure no password strings remain.