An ops note says changing only a Deployment annotation can record a change-cause, while Pod template changes drive rollouts. Which statement is accurate for when a new rolling update begins?
Select an answer to reveal the explanation.
Short Explanation
Sticky notes on the folder aren’t the same as rewriting the recipe inside. Annotate for change-cause documentation; change the Pod template—image, env, probes—and that’s what actually spins a new ReplicaSet.
Full Explanation
For municipal Deployments, a new rolling update begins when the Pod template changes—container image, env, probes, volumes, and similar template fields—because that hash change causes the Deployment controller to create a new ReplicaSet. Annotation-only metadata updates (including recording kubernetes.kubernetes.io/change-cause) document why a change happened but do not by themselves roll Pods. Separating “sticky-note” annotations from template edits keeps capacity stable when operators only need to label a change-cause for audit without restarting city workloads.
Why the other options fail by concept: Claiming any annotation change always forces Recreate of every Pod is false; metadata annotations on the Deployment object are not Pod template mutations. Label selector changes are not the only—or normal—way to start a rolling update and are dangerous because selector immutability constraints and orphaned Pods can result. ConfigMap data edits do not automatically restart Deployment Pods unless the Pod template references a new ConfigMap name/hash or an external reloader is used; editing ConfigMap alone is not a template change.
Exam caveat: Some teams deliberately bump a template annotation (for example a checksum) to force a rollout when mounted ConfigMaps change—that works because the annotation lives under the Pod template. Distinguishing Deployment-level annotations from template annotations is a frequent exam trap. Also, changing strategy fields does not create a new revision the way template changes do.
Operational check: Before and after an annotation-only patch, compare kubectl get rs and Pod ages—replica sets should be unchanged. After an image or env template change, a new ReplicaSet should appear. Use kubectl rollout history to confirm revisions increment only when the template changed, and attach change-cause when you intentionally roll.