A building-permits platform wants a controlled image bump through the Deployment controller. Which change correctly triggers a new rollout?
Select an answer to reveal the explanation.
Short Explanation
The Deployment watches the Pod template like a blueprint stamp—change the stamp (image tag and friends) and a new revision rolls out. Tweaking an unrelated Service name does not flip that stamp.
Full Explanation
A building-permits platform that wants a controlled image bump through the Deployment controller must change the Pod template—typically by updating the container image tag on the Deployment. The Deployment computes a template hash and creates a new ReplicaSet revision when that template changes; RollingUpdate (or Recreate) then replaces Pods according to strategy. That is the supported, auditable trigger for a municipal release driven by the controller rather than by side-channel edits.
Only renaming the Service that selects the Pods without changing the Pod template does not create a new Deployment revision; Services are a separate discovery object. Only editing an unrelated ConfigMap that no Pod mounts or references likewise leaves the Pod template hash unchanged, so no rollout starts. Only increasing revisionHistoryLimit without altering the Pod template merely changes how many old ReplicaSets are kept; it does not bump the application image or trigger replacements.
Exam caveat: template changes trigger rollouts; unrelated object renames do not. Also note some ConfigMap/Secret updates still require Pod restarts depending on consumption pattern—but the question asks what correctly triggers a Deployment rollout. Operational check: change the image on the Deployment, watch a new ReplicaSet appear, and confirm rollout status completes for the permits API.