When an admission rule starts requiring a backup-retention label on PersistentVolumeClaims, what happens to the 400 PVCs that already exist?
answer
- It runs on requests, not on records
- Stored objects submit nothing
- Start date is a watermark
- Churn decides retroactive reach
- Legacy PVCs may never be rewritten
basics
~10 sNothing happens to them. Admission evaluates API write requests, not stored objects, so the 400 existing PVCs keep running unlabelled and are never checked again unless something submits a write for them.
solid answer
~40 sAdmission control is a hook on the API server's write path: it runs when a create, update or delete request arrives, and it is handed that one request. Stored objects generate no requests, so installing the rule does not evaluate, fix, flag or delete anything already in the cluster. The 400 unlabelled PVCs keep serving storage exactly as before, and the rule will only ever see one of them if someone or something submits a write for it — which for a long-lived PVC may be never. The practical consequence is that the rule's start date is a watermark on the request stream, not a statement about the estate. Closing the gap needs a separate pass that enumerates stored objects and evaluates them, plus a remediation plan for what it finds.
go deeper
Remember the one-line rule: admission runs on API write requests, so objects already stored are untouched until something writes to them again. Be able to say what that means for a resource nobody edits.
Be ready to walk the request path — authentication, authorisation, mutating admission, schema validation, validating admission, persist — and to explain why a stored object never enters it on its own.
Show that you size the legacy population before announcing enforcement, and that you pair the gate with a separate pass over stored objects plus an owner and a date for remediation.
Own the distinction between a control being enforced from a date and a population being compliant, and make sure nobody in your organisation reports the first number as if it were the second.
## What admission actually intercepts A validating admission rule is a hook on the Kubernetes API server's **write path**. When a client — a person running `kubectl`, a CI job, a GitOps controller, or one of Kubernetes' own controllers — submits a create, update or delete, the API server authenticates the caller, authorises the request, runs mutating admission, validates the object against the schema, runs validating admission, and only then persists the object. The policy engine is handed an **AdmissionReview** describing that one request: the object being written, the stored object it replaces on an update (the old object), the requesting user and their groups, the operation and resource, and whether the request is a dry run. Note the shape of that input. It is one object, at one instant, in one request. It carries no other object in the cluster, no cluster-wide state and no history. And the decisive property for this question: **no request, no evaluation.** Objects sitting in etcd do not generate requests on their own. ## So what happens to the 400 PVCs Nothing. They are stored records backing running workloads. They are unlabelled and they stay unlabelled. Installing the rule does not walk the cluster, does not annotate violators, does not block reads, and certainly does not delete anything. The rule fires the next time a write for one of those PVCs reaches the API server — and for a PersistentVolumeClaim, whose whole purpose is to outlive the pods that mount it, that write may simply never come. ## Two populations, not one After the rule ships you have two disjoint sets: - objects **created or written since** the rule was enabled, every one of which was evaluated; - objects **already stored**, none of which was. The gate's own telemetry can only ever describe the first set. That is why an admission pass rate is not a compliance percentage for the estate, and why the honest sentence is "enforced for new and updated PVCs since 14 March" rather than "all PVCs comply". ## Churn decides how fast the gap closes The same rule has wildly different retroactive reach depending on what resource it matches, because resources differ in how often they are re-submitted: | Resource | Re-submitted | Effective reach | | --- | --- | --- | | Pods | constantly (rollouts, evictions, drains, scaling) | most of the fleet within a deploy cycle | | Deployments, ConfigMaps | on each change | weeks to months | | PVCs, StatefulSets, namespaces, RBAC | rarely, sometimes never | close to zero | So before claiming a gate covers something, ask how often an object of that kind is actually written. High-churn resources self-heal through normal traffic; low-churn ones do not, and that is where the permanent legacy pocket lives. Note that the high-churn case has its own hazard: the re-evaluation lands whenever the object is next recreated, which may be during an incident rather than during a deploy. ## Closing the gap Because admission structurally cannot look backwards, something else has to: a pass that **lists stored objects and evaluates them out of band**. That mechanism has a different character from a gate — it reports after the fact rather than preventing, it can produce a large backlog on first run, and it needs an owner for remediation. Pair it with a plan: which of the 400 get relabelled, by whom, by when, and which are formally excepted with an expiry. ## What interviewers listen for The wrong answer treats the rule as if it applied to the cluster's contents. The right answer says the rule applies to **requests**, names the resulting legacy population, and immediately reaches for a different mechanism to find and fix it — rather than assuming the gate quietly cleaned up behind itself.
- Would the answer change if the rule matched Pods instead of PersistentVolumeClaims?In effect, yes. Pods are recreated constantly by rollouts, evictions, drains and scaling, and each recreation is a fresh CREATE request that the rule evaluates. So a pod-level rule reaches most of the fleet within a deploy cycle without anyone re-submitting anything. The mechanism is identical — only the churn rate differs — and the catch is that a non-conforming legacy workload then breaks at its next recreation, which you do not get to schedule.
- How would you find the 400 unlabelled PVCs in the first place?By listing the stored objects and evaluating them outside the admission path — the same rule logic applied to an inventory rather than to a request stream. That pass is detective, not preventive: it tells you what is already wrong, produces a backlog on first run, and needs an owner and a date attached to each finding. Admission then keeps the backlog from growing while you work it down.
It is a metal detector at the door, not a search of the building. Everyone who walks in from now on is checked; whoever is already inside is not.
saying these in an interview costs you the question
- Claims the new rule retroactively fixes or deletes existing objects
- Assumes stored objects are re-validated on the next controller resync
- Treats a 100% admission pass rate as 100% of the estate compliant
- Thinks the API server periodically replays webhooks over etcd contents
- Says the rule blocks reads of non-conforming objects