A platform keeps every applied rollout as a numbered revision - what does one revision contain, and what happens when you reapply an earlier one?
answer
- one record per accepted apply
- the unit is not the image
- whole declared spec, stored as applied
- going back is a forward apply
- a reference, not a copy of bytes
basics
~20 sA revision is a snapshot of the entire declared spec at one apply - image reference, copy count, reservations, ceilings and settings together. Reapplying an earlier revision runs a normal forward rollout whose target happens to be that older spec.
solid answer
~50 sA revision is one stored copy of the whole declared spec as the platform accepted it: which image content to run, how many copies, what each reserves and may consume at most, which settings reach the process, which checks decide it is ready. Every accepted apply appends one entry, so the history is a list of past desired states rather than a list of diffs. Going back does not edit the live workload and does not rewind any copy in place: you select a retained revision, the platform makes that spec the current desired state, and the same control loop replaces copies under the same batching and readiness gating it uses for any release. So a rollback is a forward rollout with an old target, and it restores every field that revision held - not only the one you regret.
code
yaml · 17 linesrevision: 41
appliedAt: "2026-04-02T11:58:00Z"
spec:
contentDigest: "9f3c1e2b74a0"
replicas: 6
reservation:
cpu: "0.5"
memory: "512MB"
ceiling:
cpu: "2"
memory: "1GB"
settings:
ledgerMode: "dual-write"
batchSize: 500
readyCheck:
path: "/ready"
failuresToFail: 3go deeper
Recall that the platform stores each apply as a numbered revision, and that going back means asking for one of those stored specs again rather than editing anything by hand.
Explain that the stored unit is the entire declared spec, that reapplying one is an ordinary forward rollout obeying the usual batching and readiness gating, and that the history appends rather than pops.
Show the operating judgment: read the target revision field by field before you submit it, confirm its content reference still resolves, and expect a rollback to stall for the same reasons a release does.
Frame the trade-off in retention depth and apply granularity: how many entries are kept decides how far back you can reach, and how much you bundle into one apply decides how precisely you can return.
## What a revision is A workload on a container platform is described by a **declared spec**: which image content to run, how many copies to keep, what each copy reserves and what it may consume at most, which settings and files reach the process, and which checks decide a copy is ready to serve. You do not start copies one at a time; you submit that document and a control loop makes reality match it. A **revision** is that document, stored exactly as it stood when the platform accepted it. Every accepted apply appends one entry. The history is therefore a list of past *desired states* - not a list of diffs, not a transcript of commands somebody typed, and not a backup of anything the workload produced while it ran. Two consequences matter far more than the definition: - **The unit is the whole spec, not the image reference.** A revision that was applied with a raised memory ceiling, an extra setting and a different copy count carries all three alongside the reference to image content. Returning to it brings back all of them. - **The unit is one apply.** Whatever you submitted together becomes one entry, and one entry is the smallest thing you can return to. Bundling an image change and a settings change into a single submission means you cannot later separate them. ## What reapplying one actually does Selecting a retained revision does not edit the live workload and does not rewind any running copy. The platform takes that revision's spec, makes it the current desired state, and the same loop that carries out any release carries this one out: copies are replaced under the same batching, the same readiness gating and the same budgets. In other words, **a rollback is a forward rollout whose target happens to be old**. It also appends rather than pops - the bad entry stays in the history, readable until retention drops it, and a new entry at the top records that the older spec is now what is wanted. This is the difference between the two things people both call "going back": | | Re-pointing a movable name at older content | Reapplying a retained revision | |---|---|---| | What changes | only what that one name resolves to | the entire declared spec | | What is recorded | nothing; the declared spec never changed | a new entry in the revision history | | How copies turn over | only when something forces a fresh resolve | the platform's normal replacement | | What you can read back | a name that may move again tomorrow | the exact spec that is now desired | | Blast radius | invisible; two hosts can disagree | explicit, inspectable, one document | The left-hand column is why "just point it back at the old build" is not the same operation. It leaves the recorded desired state still describing the version you are trying to get rid of, and it depends on something forcing every copy to resolve that name again. ## What a revision does not carry - **Content bytes.** A revision holds a *reference* to image content, not a copy of it. If that content is no longer available from the registry, reapplying the revision fails at fetch time exactly as a fresh release would. - **Anything outside the spec.** Rows committed to a store, messages published to other services, files written into a volume: none of that is described by the spec, so none of it is restored. - **Anything never expressed in the spec.** A change made by hand and never landed in the declared source is in no revision at all, and the next apply - including a rollback - replaces it. ## Retention Platforms keep a bounded number of revisions per workload and drop the oldest as new ones arrive, because the history would otherwise grow without limit. That depth is a setting, and it decides how far back "return to a known-good one" can actually reach. Two habits follow: keep the depth comfortably larger than the number of applies a bad week produces, and remember that a retained entry proves what the spec *was*, not that the content it names still exists. ## Before you reapply one 1. **Read the target revision** instead of trusting the label "the last good release". Compare it field by field against the live spec so you see everything the move will change, not only the image reference. 2. **Check the reference still resolves.** A rollback that fails halfway on a fetch error leaves a stalled replacement sitting on top of an incident. 3. **Expect the same gates.** If the older spec's readiness check cannot pass against today's dependencies, the rollback stalls in exactly the way a bad release does - which is the gating working, not the gating misfiring.
- What happens if you reapply a revision whose referenced image content is no longer in the registry?The apply itself succeeds, because the spec is valid, but the replacement stalls the moment the platform tries to fetch content for the first new copy. The old copies keep serving, since replacement is gated on new copies becoming ready, so you get a stuck rollback rather than an outage. The fix is to restore the content or pick a revision whose reference still resolves.
- How deep should the retained revision history be?Deep enough that the oldest spec you would realistically return to is still present. Count the applies a normal bad week produces and keep more than that, because the entry you need is the one from before the change nobody noticed. Depth costs almost nothing: an entry is a small document, not a copy of any content.
- Does going back to a revision skip the usual readiness gating so it lands faster?No. It is an ordinary apply, so it is replaced batch by batch with each step gated on a new copy reporting ready. That is deliberate: a rollback is a change like any other and can itself be wrong. If you need it faster, the lever is the replacement budget, not an exemption from the checks.
saying these in an interview costs you the question
- Says a rollback only swaps the image reference back
- Thinks the platform stores diffs and replays them in reverse
- Believes a retained revision keeps a copy of the image content
- Expects running copies to rewind in place rather than be replaced
- Assumes the bad revision is deleted the moment you go back