Enforcement Decisions

## Two different documents A policy engine does not look at your infrastructure. It looks at a **document** describing your infrastructure, and everything the rule can decide is bounded by what that document contains. **The plan document** is a description of a single proposed change. For each resource involved it carries an address, a type, the action being taken (create, update, replace, destroy, or no-op) and the attribute values the resource will have afterwards. Crucially, a resource that the change does not touch is **not in the document at all**. The plan is a delta, not a census. **The recorded state** is the opposite shape. It is a record of every resource this codebase currently manages, with the attribute values each of them actually has. There is no change and no action in it, because nothing is being proposed — it is a snapshot of what is. **An inventory export** from the cloud provider is wider still: it lists resources in the account regardless of who created them or whether any codebase manages them. Resources created by hand, by another team's codebase, or by a tool that predates your pipeline appear here and appear nowhere else. ## The coverage gap this exposes If every rule you own runs only against plans, the set of resources you have ever actually evaluated is exactly the set somebody has changed since you turned the rules on. Everything else has been silently excluded. Two situations make this concrete: 1. **A resource nobody is changing.** A production database sitting on an engine version that has since gone end-of-support is a real risk — it stops receiving patches — but nothing about it is being deployed. It generates no plan, so it triggers no evaluation. It can stay invisible indefinitely, precisely because it is stable. 2. **A rule you added after the fact.** You write a new rule today. It applies to hundreds of existing resources, but it will only ever fire on the ones that happen to come up in a future change. The rest are grandfathered by accident, not by decision. Re-expressing the rule so it reads state or inventory closes both gaps in one move: the input becomes the population rather than the delta. ## What this looks like in practice A state-or-inventory run is normally **scheduled** rather than triggered by a change — nightly or hourly — because there is no change event to hang it on. Its output is not a pass or fail on somebody's pipeline; it is a set of findings about resources that already exist and are already running. Nothing is being deployed, so there is nothing to refuse. The finding lands in a queue and the response is a human workflow: annotate it, ticket it, fix it forward, or re-run the rule to show it is gone. ## Where each source stops - **State** covers what this codebase manages, and only that. A resource somebody clicked into existence in the console is not in your state file, so a state-only scan will miss it entirely. - **Inventory** covers the account, so it sees the hand-made resources too — often the worst offenders, because they never passed through any pipeline. But it is provider-shaped rather than code-shaped, so the addresses in the findings do not map neatly back onto modules and repositories, which makes routing harder. Most mature setups read both, and treat a resource that appears in inventory but not in state as a finding in its own right. ## The thing to say in an interview The plan gate and the state scan are not two implementations of the same control. The plan gate is the only one that can act **before the resource exists**, and it gives feedback inside the author's own change. The state scan is the only one whose input includes the resources nobody is touching, which is where long-lived risk accumulates. Keeping only the first gives you a green pipeline over an estate you have never examined; keeping only the second means every violation is discovered after it is already running.