Why can a deployment that names an image by tag start different bytes next week, when a digest reference cannot?
answer
- one name is chosen, one is derived
- labels move, content does not
- hash taken over the bytes themselves
- one byte differs, the name differs
- record the digest, not the label
basics
~20 sA tag is a label a publisher attaches and can re-attach to different content at any time, while a digest is computed from the image's own bytes — change one byte and it is a different digest, so nothing can republish under the old one.
solid answer
~40 sA tag is a mutable pointer. The publisher decides what it points at and can repoint it later without anyone downstream editing a line of configuration, so `ledger:1.4` is a statement of intent, not of content. A digest is the opposite: it is a cryptographic hash taken over the image's own bytes, so nobody assigns it — it falls out of the content. Any change at all, whether a new file, a rebuilt base or a different layer order, produces a different digest, and the old digest still names the old bytes. That is why a reference by tag can resolve to different content next week, while a digest reference either resolves to exactly those bytes or does not resolve at all.
go deeper
Be able to say which of the two names a person chose and which one the bytes produced, and give one sentence on why only one of them can ever drift.
Explain the mechanism itself: the hash is taken over the image's own content, so different bytes necessarily yield a different name and cannot reuse the old one.
Show where this bites in production. A deployment record that names only a label cannot say what was running during last night's incident, and cannot be rolled back to it.
Weigh the cost you take on. Recording and pinning content identities everywhere means fixes stop arriving by themselves, so the standard you set has to include how those identities get updated.
## Two ways to name one image An image is a set of read-only layers plus a small document that lists them and records the defaults a runtime should use. Once it is published, people need a way to refer to it: in a deployment file, in a change ticket, in a conversation between two teams. Two kinds of name are in circulation, and they behave nothing alike. A **tag** is a label. Somebody chose the string, attached it to a particular image, and published that association. Nothing about the image's content produced the string, and nothing prevents the publisher from attaching the same string to different content an hour later. A **digest** is a **cryptographic hash computed over the image's own bytes** — over the document that lists the image's layers and its runtime defaults, which in turn names each layer by that layer's own hash. Nobody assigns it. It is the output of a function whose only input is the content. Throughout this explanation, *digest* means the one that names the whole image, not an individual layer's digest. ## Why a content-derived name cannot drift Content addressing simply means the name is computed from the thing named. Three consequences follow, and together they are the whole argument for recording a digest: 1. **Change anything and the name changes.** Rebuild on a patched base, edit one line of a start-up script, add a file: the bytes differ, so the hash differs, so it is a different digest. There is no operation that publishes different content under an existing digest. 2. **The old name keeps working.** Publishing new content does not disturb any existing digest; it adds one. A digest written down last March still names exactly what was written down, whatever has been published since. 3. **A receiver can check it locally.** A host that asked for content by digest can hash what arrived and compare the result. If they match, it holds the bytes that name refers to. That third point is about **integrity only**. It establishes that these are those bytes. It says nothing about who built them, or whether they are fit or permitted to run — those are separate questions with separate owners. ## What a tag is actually for Tags are not a design error. They carry the meaning a digest cannot: - a tag is readable and memorable, while a digest is a long opaque string nobody quotes from memory - a tag expresses intent — the release a team calls `1.4`, or whichever build is currently current - a tag survives a rebuild, which is precisely the moment the content changes - a tag lets a publisher ship a fix without every consumer editing configuration - several tags may point at one image, and a perfectly good image may carry no tag at all - a tag tells you nothing about its content until somebody resolves it, and the answer is only true at that instant Every one of those is a feature for publishing and a hazard for deployment. The property that lets a publisher push a fix to everyone without coordinating is the same property that lets two machines reading one string end up running different software. ## The two names side by side | | tag | digest | |---|---|---| | who chooses it | a publisher | nobody — it falls out of the bytes | | can it mean something else later | yes, at any moment | no | | what it identifies | whatever it points at right now | one exact set of bytes | | what it tells you a year later | which label was in use | exactly what ran | | readable by a person | yes | not usefully | | checkable by the receiver | no, there is nothing to compare against | yes, by hashing what arrived | ## Why this matters to a deployment Picture a payments ledger running in two data centres, deployed from configuration that names a tag. Each site turns that label into content at the moment it starts its workload. If the tag was repointed between those two moments, the sites run different builds from byte-identical configuration — and nothing in the system disagrees, because the configuration, the change ticket and the dashboards all record the label, and none of them records the content. Three practical losses follow, and they are why recording a digest is the standard advice for anything you might later have to account for: - **You cannot say what ran.** "We were on `1.4`" names a label whose meaning at the time is no longer recoverable. - **You cannot roll back to it.** "Restore what we had" needs a target, and the label now points somewhere else. - **You cannot reproduce it.** Fetching the same tag on a laptop gets whatever it means today. Pinning is not free: a frozen reference also stops absorbing fixes on its own, and something has to propose new digests. But the guarantee it buys is unusually clean — the reference resolves to exactly those bytes, or it does not resolve.
- If a publisher copies the identical image into a second registry, does the digest change?No. The digest is computed from the content, so the same bytes carry the same name wherever they are stored, and a host can confirm it by hashing what it received. What does change it is a rebuild: building again from the same source usually produces different bytes — timestamps, ordering, a refreshed base — and therefore a different digest, even though nothing anyone wrote changed.
- Can one image carry several tags at once, and does that create several images?One image, several labels. Tags are pointers into a set of content-addressed objects, so many of them can point at the same digest — a release label, a rolling `current` label and a date label may all resolve to identical bytes. The image is not duplicated and its digest is unchanged; only the number of names pointing at it differs.
- Does a moving tag ever make sense in a deployment reference?Yes, where picking up the newest build automatically is the point and the blast radius is small: a development environment, a scratch cluster, an internal tool nobody depends on. It stops making sense the moment you need to state what ran, or need two places to be running the same thing.
A tag is a label taped to a shelf: someone can move it to a different box tonight and it still reads the same. A digest is a fingerprint of what is in the box — you cannot move it onto other contents, and it changes the moment the contents do.
saying these in an interview costs you the question
- Thinks a version-numbered tag is immutable because it looks specific.
- Says a digest is just a shorter generated alias the publisher assigns.
- Believes fetching the same tag twice always yields the same image.
- Thinks copying identical bytes to another registry changes the digest.
- Claims a digest proves the image is safe and approved to run.