Why :latest is a production anti-pattern

WHAT THIS TESTS This checks whether you understand image tag immutability and its impact on reproducible, auditable deployments.

A GOOD ANSWER COVERS The latest tag is not special; it is simply the default tag and is fully mutable, so the same reference can point to different image content over time. In Kubernetes this means two nodes might run different code if they pulled at different moments, and rollbacks are unreliable because there is no distinct prior tag to return to. Kubernetes also sets imagePullPolicy to Always when the tag is latest but IfNotPresent for fixed tags, so caching behavior becomes inconsistent. The fix is immutable tags: semantic versions like 1.4.2, a build identifier, or a git SHA, and for maximum strictness pin by content digest with the at-sha256 form. This guarantees a Deployment spec always resolves to identical bytes, enabling clean rollbacks and audits.

COMMON WRONG ANSWERS Claiming latest always pulls the newest published image on every pod. Believing latest helps rollbacks. Thinking the tag itself is immutable. Ignoring imagePullPolicy interactions.

LIKELY FOLLOW-UPS How does imagePullPolicy change with latest? What does pinning by digest buy you? How do you trigger an update with immutable tags? How does this affect a registry retention policy?

ONE CONCRETE EXAMPLE A team ships app:latest. A node restarts a pod, pulls latest, and gets a newer build than its siblings, causing inconsistent behavior under load. Switching to app:1.4.2 makes each Deployment revision explicit; a bad release is rolled back instantly by reverting to app:1.4.1, and for compliance the manifest pins app@sha256:abc..., so every cluster runs byte-identical images regardless of when they pulled.