A records-management team asks whether modifying a container image means running docker commit against a live Pod. What is the correct application practice?
Select an answer to reveal the explanation.
Short Explanation
docker commit is the "save your messy desk as the official blueprint" anti-pattern. Treat images as immutable: change the Dockerfile or build, push a new tag, and let the Deployment roll forward cleanly.
Full Explanation
Records-management teams sometimes think docker commit against a live Pod is how you version images. That is incorrect application practice. Treat images as immutable build outputs: change the Dockerfile or CI pipeline, rebuild, push a new tag or digest, and roll the Deployment so new Pods replace old ones. Committed writable layers capture ad-hoc edits, secrets, and drift that cannot be reproduced cleanly for audits common in public-sector records systems.
Yes—commit the running container filesystem and retag it as production fails reproducibility and often bloats images with temporary files. Yes—exec into the Pod and edit files in place leaves the writable layer as a false source of truth that vanishes when the Pod is rescheduled. Using kubectl edit on the node to rewrite the container runtime bundle is not an application workflow and fights the declarative Kubernetes model.
Exam caveat: CKAD wants Dockerfile/CI → registry → Deployment image field. Imperative container mutation is an anti-pattern except for short-lived debugging sessions that never become the release artifact.
Operational check: make a deliberate code change in source control, rebuild and push, update the Deployment image, watch kubectl rollout status, and confirm Pods show the new imageID digest across replicas.