A municipal 311 API tags every push as latest and production Pods flip unpredictably between builds. What change makes application releases reproducible?
Select an answer to reveal the explanation.
Short Explanation
latest is like labeling every jar in the pantry "food"—you never know what you are opening. Pin a real version tag or digest so Monday's deploy and Friday's restart serve the same bits.
Full Explanation
Municipal 311 APIs that retag every push as latest create non-reproducible releases: two workers may pull different digests at different times, so production Pods flip unpredictably between builds. The correct practice is to pin each release to an explicit immutable tag (for example v2026.08.19.3) or, stronger, an image digest (@sha256:…) in the Pod or Deployment spec. That identity is what the kubelet pulls, so Monday’s deploy and Friday’s restart serve the same bits the city tested.
Relying on floating latest fails because registries mutate that name; IfNotPresent nodes may keep an old digest while Always nodes pull a newer one, producing mixed fleets. Disabling pulls and baking binaries onto workers with hostPath fails portability and bypasses image immutability. Renaming the Deployment on every push does not freeze image content; it only churns controllers and Services.
Exam caveat: CKAD wants reproducible application releases via image identity in the workload spec. Digests are the strongest pin; unique tags are acceptable when your pipeline never retags the same name.
Operational check: kubectl get deploy -o yaml | grep image: and confirm no :latest; after rollout, kubectl get pods -o jsonpath for containerStatuses imageID and verify digests match across replicas.