A Kustomize overlay must bump a Deployment’s container image tag without hand-editing every base YAML file. Which field is designed for that change?
Select an answer to reveal the explanation.
Short Explanation
Think of images: newTag as swapping the shipping label on every crate without unpacking the warehouse. One overlay line retags the container image across matching workloads.
Full Explanation
A Kustomize overlay that must bump a Deployment’s container image tag without hand-editing every base YAML file should use the images transformer with newName and/or newTag entries. That purposeful field rewrites image references during the build so municipal overlays can promote versions per environment while the base stays version-agnostic. City release managers then change only the overlay’s images list when promoting a ticket API build from staging to production, instead of scattering tag edits through shared manifests.
Why the other options fail by concept: The replicas field only adjusts replica counts on named workloads and never rewrites container image tags. namespace: only rewrites the target namespace for namespaced objects. secretGenerator only creates Secret objects from literals or files; it does not bump Deployment container image tags.
Exam caveat: images matching is based on the image name present in the base manifests; if the name string does not match, the transformer silently does nothing—always verify with kubectl kustomize. newName can retarget a city pull-through registry mirror. Prefer immutable digests in production overlays when floating tags are a supply-chain risk for municipal clusters.
Operational check: Add an images entry with newTag (and optionally newName) in the overlay, run kubectl kustomize <overlay> | grep image:, confirm the expected tag, then kubectl apply -k and kubectl get pods -o jsonpath to verify running containers show the new image before announcing the civic release.