Why must an admission rule that blocks downgrading a StatefulSet's encryption-tier annotation compare object with oldObject?

## State rules and transition rules There are two shapes of admission rule, and choosing the wrong one is a design error that no amount of careful field access will fix. A **state rule** asserts something about the object in front of it: this annotation must equal `encrypted`. It reads `object` only, gives the same answer on a create and an update, and cannot be dodged, because every path that puts the object into the cluster runs through it. A **transition rule** asserts something about a change: whatever this annotation is, it may not go from `encrypted` to anything weaker. It needs two values — the one being submitted and the one already stored — and the stored one exists in exactly one place in the payload, `oldObject`. The practical scenario: a platform team has a `data.example.com/encryption-tier` annotation on StatefulSets that downstream storage tooling reads when it provisions volumes. Some older workloads legitimately still carry a weaker value, and forcing them all to the strong tier today is not on the table. So the requirement is not "everything must be encrypted" — that would break the grandfathered set — but "nothing that is encrypted may become un-encrypted." That requirement is a transition, and it is why the diff is unavoidable. Worth noting *why* the annotation rather than the volume claim template itself: the API server already rejects in-place changes to a StatefulSet's `volumeClaimTemplates`, so a policy guarding those is spending latency on every write to re-decide something the server has already decided. Guard the field that is actually mutable. Recognising which fields the platform already freezes, and declining to duplicate them, is a real part of authoring rules that earn their place in the request path. ## What the diff looks like against the payload `oldObject.metadata.annotations["data.example.com/encryption-tier"]` is the stored value; the same path under `object` is the submitted one. Deny when the old value is `encrypted` and the new value is anything else — including absent, because removing the annotation is a downgrade too and a rule that only compares two present strings misses the deletion case entirely. Then handle the verbs. `oldObject` is null on `CREATE`. If the policy is registered for both verbs, it must branch on `operation`, or the create path either errors or silently produces no decision. The usual answer is two clauses: on `UPDATE`, forbid the downgrade; on `CREATE`, either allow anything (accepting the grandfathered reality) or apply a floor for new workloads, which is a different and stricter decision that deserves to be written down separately. ## The gap a diff rule leaves open An `UPDATE`-only rule sees only updates. Delete the StatefulSet and create a new one at the weaker tier and no update ever occurs, so the rule never runs. The payload itself makes this unavoidable: it carries no history, so at create time the policy genuinely cannot know that an object of this name was encrypted five minutes ago. The engine is not being obtuse — the information does not exist in the document it was handed. So the transition rule is only half a control. Closing it means either adding a create-time floor for the names or namespaces where you care, or guarding the delete as well, or accepting the gap explicitly and knowing you have. What you must not do is present the diff rule as complete: an interviewer asking this question is usually asking whether you notice. ## Denying usefully The payload is also where the denial's content comes from. The author on the other end of a failed apply is looking at a message, not at your rule. Quote the annotation key, the old value and the new value straight out of the request, and the person can revert without opening a ticket. A message that only says the change was blocked by policy converts a five-second fix into an escalation, and repeated escalations are how a guardrail acquires a reputation for being the reason nobody can ship. ## The shorter answer, when it applies If you *can* get away with a state rule, do. It is simpler, it applies uniformly to every verb that submits an object, it is not defeated by recreation, and it needs only half the payload. Reach for the diff when — and only when — weaker end states are legitimately allowed to persist and it is specifically the movement between them that you are forbidding.