A grant-tracking API needs a temporary debug image. How should the application developer change what the Pods run?
Select an answer to reveal the explanation.
Short Explanation
Want a debug build? Change the Deployment's image field—like swapping the film in a camera—and let Kubernetes roll new Pods. No SSH scavenger hunt across nodes required.
Full Explanation
Grant-tracking APIs sometimes need a temporary debug image with extra tooling. The application developer changes what Pods run by updating the Deployment’s container image field to the debug tag (or digest) and letting the rolling update replace Pods. That keeps the change declarative, auditable in GitOps, and reversible with another image pin—appropriate for municipal change-control processes around grant data.
SSH to each worker and docker tag the running container as a debug image fails at scale, bypasses the Deployment controller, and diverges node state from desired spec. Patching the etcd Pod list directly is unsafe and unsupported for application releases. Adding a hostPath volume over /usr/bin creates node coupling and does not define a real image identity for pull, rollback, or CVE tracking.
Exam caveat: changing the Pod template image is the standard CKAD way to switch application bits, including debug builds. Prefer a distinct debug tag rather than mutating :latest in place on the registry.
Operational check: kubectl set image deploy/grant-api grant-api=registry/grant-api:debug && kubectl rollout status deploy/grant-api; verify kubectl describe pod shows the debug image; finish with kubectl rollout undo when triage is complete.