Your storageClass admission rule has enforced for a month — why can it still not tell you how many existing volumes violate it?

## Admission is a write-path control A validating admission rule is invoked because someone is writing an object. The API server sends the engine a review containing the object being written, the old object when it is an update, the identity of the requester and their groups, and a flag saying whether this is a dry run. What it does **not** contain is anything else in the cluster: no other objects, no aggregate state, no history. The rule renders a verdict on one object, in isolation, at the moment of the write. Everything else about the criterion follows from that single fact. ## What the gap looks like in practice You add the rule that dynamically provisioned volumes must use an approved encrypted storage class. From that moment, every new or updated claim naming an unapproved class is rejected. Meanwhile: - Claims created last year with an unencrypted class are untouched. Nothing writes them, so nothing evaluates them. - A workload that never gets redeployed never gets re-checked. - Your admission logs, no matter how clean, describe only the requests that arrived. A month of zero denials could mean the estate is clean or it could mean nobody created a volume. So the enforcing rule cannot answer the first question anyone asks about a new guardrail: how big is the problem we already have? Treating a green admission history as a compliance statement is the canonical mistake here, and it is the version of this mistake a platform interviewer probes. ## The report surface The capability that closes the gap is a background or continuous evaluation: the engine lists (and watches) the objects a policy matches, evaluates them outside the write path, and records the results. The design point to insist on is **where the results land**. Log lines are nearly useless for this — they are unstructured, they scroll away, they cannot be grouped by namespace and they cannot be joined to ownership. What you want is results written back into the API as objects: Kyverno emits report resources you can query with `kubectl`, and Gatekeeper's audit controller records violations in the status of the constraint. Either shape gives you a queryable inventory with the cluster's own RBAC on it, which you can list per namespace, aggregate onto a dashboard, and diff week over week. That inventory does several jobs at once: - **Sizing.** Forty-one claims across nine namespaces is a migration plan; "some volumes are probably unencrypted" is not. - **Progress.** The count going down is the only evidence the migration is happening. - **Drift after an exception.** When one namespace is excepted, the report still shows what is inside it, so the carve-out does not become invisible. - **Reconciliation.** If the engine was ever disabled during an incident, the background scan is how you find out what slipped in while it was off. ## What background scanning does not do It reports; it does not retroactively fix. Finding a violating claim does not delete the volume or evict the workload — that would be a catastrophic default for a control whose whole purpose is preventing new mistakes. Some engines can be configured to act on existing resources; treat that as a separate and much more dangerous capability with its own review, not as part of turning reporting on. ## The costs you should ask about Background evaluation is not free, and this is where the platform chair matters: - The engine has to list and watch every object kind its policies match, cluster-wide. On a large cluster that is real memory in the engine and real load on the API server. - Scans run on an interval, so the report is eventually consistent — it is a picture of a few minutes ago, not of now. - Engines cap how many violations they will record per policy so a report object does not grow without bound. A brand-new rule on a big estate can therefore return a **truncated** list, and reading that truncated number as the total is a real and easy mistake. Check the limit before you quote a figure. ## The interview shape The question is usually asked as a trap with an obvious wrong answer available: the rule is enforcing, so the cluster must be compliant. The strong answer separates the two controls cleanly — admission decides about writes, background evaluation describes state — and then treats "does this engine have a usable report surface" as something you check before adopting it, not something you discover you need after the first audit-style question arrives.