How do you version Docker images: Git SHA or SemVer?

What's really being asked

This question evaluates whether you understand that a Docker tag is a mutable pointer, not a guarantee, and that production deployments require immutable, traceable artifacts. The interviewer wants to see if you distinguish between build-time identity and release-time identity. They also care whether you recognize that Git SHA and SemVer are not mutually exclusive but serve different stages of the supply chain.

The full answer

First, state that every CI build should produce an image tagged with the full Git commit SHA. This creates an immutable, one-to-one mapping between source code and artifact that eliminates ambiguity during debugging. Second, explain that Semantic Versioning should be applied only to images that pass promotion gates and are declared release-worthy. SemVer tags like v1.2.3 are human-readable and communicate breaking-change contracts, but they are floating aliases that can be moved. Third, describe a hybrid workflow where the SHA tag is the canonical reference stored in deployment manifests and Helm values, while SemVer tags are convenience labels for changelog consumers and rollback menus. Fourth, mention that rolling tags such as v1 or v1.2 are acceptable for non-production consumers who want automatic patches, but production manifests should pin the exact SHA or the full SemVer triple to prevent drift.

The mistakes people make

A major red flag is recommending latest as a production tag because it is non-deterministic and makes rollbacks nearly impossible. Another mistake is treating SemVer as immutable. Candidates who say v1 always points to the same image misunderstand that tags are mutable pointers in Docker. Similarly, using only SemVer without SHA tags loses the direct source-to-artifact link, forcing teams to hunt through build logs to map a version back to code. Finally, suggesting build-number tags alone misses the traceability to source control that Git SHA provides.

What usually comes next

The interviewer may ask how you prevent tag mutation in production, so be ready to discuss registry immutability policies or admission controllers that reject unpinned images. They might also ask how to handle hotfix branches, which is a chance to explain tagging those builds with the branch name plus SHA and later re-tagging with a patched SemVer. Another follow-up is how to garbage-collect old images without breaking rollback. The answer is to keep every SHA for a retention window and only delete untagged intermediates.

A concrete example

Suppose a pipeline builds commit abc1234. The CI system tags the image myapp:abc1234 and pushes it. After passing integration tests, the image is promoted and receives myapp:v1.2.3, myapp:v1.2, and myapp:v1. The Kubernetes production manifest references myapp:abc1234 directly, while the release notes point consumers to myapp:v1.2.3. If a critical bug is found, the team can instantly roll back to the previous SHA because the deployment history contains the immutable reference, not a floating tag.