Skip to content
tezvyn:

How ensure Kubernetes pulls correct new image and why avoid :latest?

Source: kubernetes.ioMediumHow cards are made

How ensure Kubernetes pulls correct new image and why avoid :latest?

Tests immutable tagging and Kubernetes image pull behavior. Strong answers demand unique tags like git SHA, explicit deployment spec updates, and explain :latest's reproducibility failures across nodes.

What's really being asked

This question probes your understanding of immutable infrastructure, container image identity, and how Kubernetes handles image resolution and caching across a cluster. The interviewer wants to know if you can design a CI/CD flow that is reproducible and safe at scale, rather than relying on mutable tags that obscure what code is actually executing.

The full answer

First, the candidate should insist on immutable tags generated in CI, such as the git commit SHA, a semantic version, or a monotonic build ID, and explicitly update the Deployment or Pod spec to reference that new tag. Second, they should explain that Kubernetes caches images per node and that the :latest tag is mutable, meaning different nodes can hold different images under the same tag, which breaks consistency. Third, they should mention imagePullPolicy behavior: for a specific tag the default is IfNotPresent, so the kubelet will pull the image only if it is not cached, but because the spec itself changes when the tag changes, the rollout proceeds correctly. Fourth, they should list production downsides of :latest: impossible rollbacks, inability to correlate running code to a build, broken auditability, and the risk that a pod restart pulls an unexpected newer image.

The mistakes people make

A major red flag is suggesting that setting imagePullPolicy: Always solves the problem while continuing to use :latest. This misses the point because :latest is non-deterministic; even with Always, you cannot guarantee every node pulls the same image at the same time, and you lose the ability to pin or rollback. Another weak answer is proposing to manually delete pods or run docker pull on nodes to clear caches, which is not scalable and ignores the actual deployment mechanism. Saying you will use :latest in dev but not prod without explaining why also signals shallow understanding.

What usually comes next

The interviewer may ask how you automate the tag update in the deployment manifest, which opens discussion of GitOps tools like ArgoCD or Flux, templating with Helm or Kustomize, or simple CI sed replacements. They might ask how you handle image pull secrets for private registries, or how you would roll back to a previous image instantly. A senior candidate might also be asked about image signing or admission controllers to enforce immutable tags at deploy time.

A concrete example

In CI, after a successful build, the pipeline tags the image as myapp:abc1234 where abc1234 is the short git SHA. The pipeline then patches the Deployment YAML to set spec.template.spec.containers[0].image to myapp:abc1234 and applies it. Kubernetes sees the pod template change and performs a rolling update, pulling abc1234 only on nodes that do not already have it cached. If a critical bug is discovered, the team immediately reverts the Deployment to the previous git SHA tag, achieving a fast and deterministic rollback. If :latest were used, the team would have no reliable way to know exactly which build was running or to return to it.

Interview question

Why should a CI/CD pipeline update the Deployment spec with a unique image tag rather than repushing the same :latest tag?

  • a.Kubernetes automatically detects when the underlying :latest image changes and redeploys pods
  • b.Updating the spec with a unique tag triggers a controlled rollout and ensures reproducible rollbacksCorrect
  • c.Unique tags prevent the container runtime from caching images and causing stale layer issues
  • d.Setting imagePullPolicy to Always with :latest guarantees all nodes run identical images
Why?

Updating the spec with an immutable tag changes the pod template, driving a controlled rolling update and enabling deterministic rollbacks. The tempting idea that imagePullPolicy: Always fixes :latest is wrong because the tag is mutable, so nodes pulling at different times can still end up running different images.

Just read this? Test yourself on what you have been reading.

Read the original → kubernetes.io

You just looked this up. Could you explain it out loud?

That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.

The iPhone app is on the way

We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.

Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.

Get it on Google PlayiPhone app coming soon

We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.

See open roles