An open-data portal engineer asks whether patching a live Pod's image by hand is the supported way to roll a new release under a Deployment. What should the admin answer?
Select an answer to reveal the explanation.
Short Explanation
Hand-editing one runner on the track while the coach still holds the roster just gets overwritten. Own the change on the Deployment so the controller rolls the whole team the same way.
Full Explanation
An open-data portal engineer asking whether patching a live Pod's image by hand is the supported way to roll a new release under a Deployment should be told no: drive updates through the Deployment rollout path rather than one-off live Pod edits. The Deployment owns desired state via its Pod template and ReplicaSets. Manual kubectl edit/patch of a single Pod’s image fights that controller; replacements will follow the template, not the hand edit, and you lose consistent revision history, surge/unavailable controls, and undo.
Claiming manual Pod edits are preferred because Deployments ignore template changes is false—the opposite is true: template changes are the intended signal. Editing Endpoints only does not update container images; Endpoints/EndpointSlices reflect ready backends selected by Services. Changing kube-proxy ConfigMaps to rewrite container images cluster-wide is not how image rollout works and would be an incorrect, dangerous misconception about the dataplane.
Exam caveat: always change the Deployment (or higher-level GitOps source) so the controller converges all replicas uniformly. Operational check: update the Deployment image, verify all Pods show the new image via kubectl get pods -o wide / describe, and ensure rollout history records the revision for the open-data release.