Your platform deploys whatever the image tag `prod` currently points at. How do you govern that pointer, and would you keep the design?
answer
- A pointer is doing a release system's job
- One value, no history, no separate permission
- It cannot be the target of its own undo
- Move it after success, never before
- Something outside the registry must remember
basics
~20 sA single mutable pointer with no history is a release control plane with no audit trail and no rollback target. Keep the alias for humans, restrict who may push it, record every move externally, and move deployments onto immutable build tags.
solid answer
~50 sTreat `prod` for what it has become: a release switch. That makes three of its properties unacceptable — it has no history, so nothing in the registry says what it meant an hour ago; it has no distinct permission, since anyone with push access to the repository can re-point it; and it cannot serve as a rollback target, because the release you want to undo is what last moved it. I would demote it: deployments name an immutable build tag, the pipeline records that tag, and `prod` is re-pointed afterwards as a signpost for humans and local pulls. Where pointer-driven deploys are genuinely needed — a self-updating edge fleet — keep the alias but wrap it: only the pipeline identity may push it, every move is written to an append-only record with actor, build tag and time, and rollback is an explicit deploy of the previous build tag.
go deeper
Focus on the underlying fact: a mutable name has exactly one value and no memory of the previous one, so anything that needs history must be written down somewhere else.
Be able to describe the mechanics of a move and its consequences: who can push the name, what happens to consumers that already hold an image under it, and why nothing re-pulls automatically.
Argue the operational case. Show how the missing history and the shared push permission turn a routine release into a slow incident, and describe the controls you would add.
Own the position and its cost. Say where release authority lives, what the deploy record must guarantee, when pointer-driven deploys are still correct, and what you accept in exchange for demoting the alias.
### The design under discussion Somewhere in the platform, a deploy resolves the name `registry.internal:5000/indexer:prod` and runs whatever comes back. Re-pointing that name is therefore the act of releasing. It is a seductive design: it is one command, every consumer picks it up without being told anything, and it works identically for a fleet of one host and a fleet of hundreds. The question is not whether it works. It is whether a mutable pointer is an acceptable place to put your release authority. ### What is actually wrong with it **No history.** A registry tag is a single pointer. There is no `git reflog` for it. Once it moves, the previous value is gone unless something outside the registry wrote it down. That is fatal in exactly the moment it matters: during an incident, "what was `prod` before?" is the first question and the registry cannot answer it. **No distinct authority.** Registry permissions are granted per repository, not per tag. Anyone who can push `indexer:7e1c94d` can push `indexer:prod`. So the ability to release is identical to the ability to build, and a compromised or careless build job is a release. **It cannot be its own rollback target.** The release you are undoing is the thing that moved the pointer. Rolling back therefore always requires a name the release did not touch, which means the immutable build tags have to exist anyway. Once you accept that, the pointer stops being a necessity and becomes a convenience. **It hides fleet skew.** Consumers resolve the pointer at different moments, so "we are running `prod`" describes two or three different builds at once during any rollout. A build tag in a deploy record does not have that ambiguity. **It gives no place to hang a check.** Anything you want to be true before a release — tests passed, a change record exists, a human approved — has to attach to an event. "A tag moved" is an event only the registry sees, and only after the fact. ### Where I would land, and why Demote the pointer. Deployments reference immutable build tags; the pipeline emits the tag, the deploy record stores it, and rollback is redeploying the previous recorded tag. `prod` continues to exist and continues to be moved after a successful rollout, because people genuinely want a name meaning "the build we are happy with" for local runs, smoke tests and support. It simply stops being the thing production resolves. This costs something and it is worth naming honestly. Deploys become slightly more verbose — something must carry the tag from build to deploy. Self-updating consumers that poll a name need another mechanism. And the deploy record becomes load-bearing: if it is lost, rollback is archaeology. That last point is a real dependency, and it deserves the same care as the registry itself. ### When I would keep pointer-driven deploys Sometimes the pointer is the right design. Fleets that cannot be orchestrated centrally — appliances, edge nodes, disconnected sites — self-update by re-pulling a name, and inverting that costs far more than it saves. Development and preview environments intentionally track the newest build and gain nothing from pinning. In those cases keep the pointer and add the controls it lacks: 1. **Restrict who may write it.** Only the release pipeline's identity pushes that tag. If the registry cannot express per-tag permissions, put the release in a separate repository whose write access is narrower than the build repository's. 2. **Record every move.** An append-only record of `(alias, build tag, actor, timestamp, reason)` written at the moment of the move. This is the single highest-value addition, because it restores the history the registry never keeps and turns rollback into a lookup. 3. **Make the move the last step.** Move the alias only after a build is verified, never before, so the name never advertises something unproven. 4. **Roll back by build tag anyway.** Even with the pointer in place, the recovery path names the previous build explicitly and the pointer is corrected afterwards. 5. **Force re-resolution deliberately.** Consumers that hold a local image under that name will not notice a move, so anything expected to follow the pointer must pull explicitly rather than assume it is current. ### How I would argue it to a team that likes the current design Not on purity. The argument is a question: *reconstruct, right now, what `prod` pointed at last Tuesday afternoon, and redeploy it.* If that takes more than a minute, the pointer is carrying authority it cannot support, and the fix is not to ban it — it is to make sure something else remembers.
- Registry permissions are usually per repository, not per tag. How do you restrict who may move a release alias?Split the repositories. Builds push to one repository that many identities can write; releases live in a second repository whose write access belongs only to the release pipeline. The promotion between them is a deliberate, separately authorised step, and the mutable release name exists only where few identities can reach it. Where a registry does offer per-tag or pattern-based rules, use them, but do not assume the capability exists.
- What would you record at the moment an alias is moved, and where?Alias, the immutable build tag it now points at, the previous build tag, the identity that moved it, a timestamp, and a link to the run or change that authorised it — written to an append-only store outside the registry, because the registry keeps no history. That record is what makes "redeploy what was live at 14:00" a lookup instead of an investigation, and it is what an audit or a post-incident review will ask for.
- Where is pointer-driven deployment still the right choice?Where central orchestration is not available or not worth it: appliances and edge nodes that self-update by re-pulling a name, and development or preview environments that intentionally track the newest build. In both cases the value of "consumers converge without being told" outweighs precise control. The controls still apply — restricted write access, an external record of each move, and rollback by build tag.
saying these in an interview costs you the question
- Treats the registry as an audit log of tag moves
- Assumes push rights can always be scoped per tag
- Plans to roll back by moving the alias backwards
- Ignores that consumers resolve the pointer at different times
- Bans mutable tags outright with no migration path
- Forgets that the deploy record becomes load-bearing