Your Sentinel rule blocks destroying resources tagged data-class=production — why does reading only the planned values miss them?

## Why an "after"-shaped rule cannot see a destroy The rule is simple to state: nothing tagged `data-class = production` may be destroyed or replaced by a run. It is easy to write in a way that silently passes forever. ### Two views of the same plan A Terraform plan offers a policy two different shapes of data. `planned_values` is the **intended end state** — the resources that will exist once apply finishes, with their attribute values. It is convenient and it is the natural thing to iterate. It also, by construction, contains nothing about deletions: a resource being removed is precisely a resource that will not exist afterwards. `resource_changes` is the **diff**. Each entry names an address and carries a `change` object with: - `actions` — one of `["no-op"]`, `["create"]`, `["read"]`, `["update"]`, `["delete"]`, or a delete and a create together when the resource must be replaced; - `before` — the attributes as recorded in prior state; - `after` — the attributes the run intends to produce. For a create, `before` is null. For a pure delete, `after` is null. For an update or a replace, both are populated. So a rule that iterates `planned_values`, or that reads `change.after.tags`, is asking the plan a question the plan answers with silence. Zero violations is not evidence of compliance here; it is evidence the rule looked in the wrong place. ### Reading the prior tag The correct move is to filter `resource_changes` down to changes whose `actions` contain `"delete"`, and read the tag from `change.before`. Prior state is what tells you the resource was labelled production before anyone proposed removing it. Filtering on `"delete"` rather than on the exact list `["delete"]` matters. A replace is expressed as a delete plus a create for the same address; with `create_before_destroy` the two appear in the other order. Matching the exact single-element list quietly exempts every replace, which is often the more dangerous operation — a replaced database is a destroyed database with a new one standing where it was. ### Where undefined bites Attribute access on a resource that has no tags at all yields Sentinel's `undefined` rather than an empty map, and comparisons involving `undefined` are themselves `undefined` rather than false. A rule that indexes `change.before.tags["data-class"]` without a guard will behave unpredictably across a mixed plan. Guard the access — check the value `is not undefined` before comparing, or decide explicitly that an untagged resource is treated as unclassified and allowed. ### The part the plan cannot answer One more limit is worth internalising. `resource_changes` is scoped to what this run touches. If the requirement is "the workspace must never *contain* an unprotected production resource", including ones that no run has proposed changing for months, then the plan cannot answer at all and the rule has to read the state import instead. Deciding which of those two questions you are actually enforcing — a constraint on *changes* or a constraint on *inventory* — is the design decision hiding inside a one-line requirement. ### A related trap If a prior apply already stripped the `data-class` tag, prior state no longer carries it, and a rule keyed on that tag can no longer recognise the resource. That is why teams that gate on a classification tag usually also gate on its removal: the label is the thing the whole control rests on, so an unguarded change to the label quietly disarms every rule downstream of it.