A Terraform plan rule matching only the `create` action let a database retention downgrade ship. Why?

## The action vocabulary Every entry in a Terraform plan's `resource_changes` array has a `change.actions` field, and it is an **array of strings**, not a single verb. The values you will meet: | `actions` | meaning | |---|---| | `["no-op"]` | resource is managed but this run does nothing to it | | `["create"]` | resource does not exist yet and will be created | | `["read"]` | a data source that will be read during apply | | `["update"]` | attributes change in place; the resource keeps its identity | | `["delete"]` | resource is destroyed and not recreated | | `["delete", "create"]` | replacement: destroy the old object, then create the new one | | `["create", "delete"]` | replacement with create-before-destroy ordering | A rule that fires only when the array contains `create` therefore covers creations and both orderings of a replacement — and misses every in-place edit. That is exactly how a retention downgrade ships past a gate: lowering a backup window on an existing database does not destroy anything, so Terraform plans it as `["update"]`, the filter does not match, and the rule never runs. The gate is green because it never looked, not because the change was safe. ## The correct filter For a rule about the *end state* of anything this run touches, match when `actions` contains `create` **or** contains `update`. Equivalently: skip entries whose actions are exactly `["no-op"]`, `["read"]` or `["delete"]`, and evaluate the rest. Both formulations catch replacements, because a replacement pair always contains `create`. Two traps live in that sentence: **Do not pattern-match the array by equality.** A rule written against `["delete", "create"]` will not match `["create", "delete"]`, and which one you get depends on whether the resource has create-before-destroy lifecycle behaviour. Test for *membership* in the array, never for a specific array literal, and never assume a fixed length. **Do not index `change.after` without knowing the action.** For a `["delete"]` entry, `after` is `null`. Reaching into it for an attribute produces a missing value, and in most policy languages a rule body that cannot resolve a value does not evaluate to false — it produces no result at all, so the deny simply never fires. Undefined is not false. A rule that crashes is loud; a rule that quietly evaluates to nothing is the dangerous one, because it looks exactly like a pass. The same asymmetry applies to `before`, which is `null` on a create. ## Why `no-op` is skipped deliberately Skipping `no-op` is not laziness; it is the scoping decision that makes the gate survivable. The plan lists every managed resource, including ones nobody has touched in years. A rule that judges them all blocks an engineer for infrastructure that is not in their diff and not theirs to fix. Filtering on the action confines the gate to the blast radius of the change under review: new databases must be right, edited databases must be right, and the estate's existing debt is handled by some other mechanism rather than by ambushing whoever next edits a tag. ## Diagnosing this class of bug When a change that obviously violates a rule ships anyway, work backwards through three questions in order: 1. **Did the rule see the resource at all?** Print or assert the set of addresses the filter selected. Nine times out of ten the answer is "no", and the filter is why. 2. **If it saw it, did it read a value?** A missing attribute — wrong key name, wrong nesting, `after` being null — resolves to nothing, and the rule body silently produces no result. 3. **Only then, is the comparison itself wrong?** Threshold direction, unit mismatch, string versus number. Most policy authors start at step three and lose an afternoon there. Filters fail far more often than comparisons. ## Regression-proofing the fix Once you widen the filter to include `update`, write the case down as a fixture: a small plan document containing one `["update"]` entry that lowers the retention window, asserted to produce a denial. Action-filter regressions are invisible in production — the gate stays green — so the only thing that catches them is a test that feeds the rule a plan it is supposed to reject. ## What people get wrong - Assuming only a creation can introduce a violation. - Writing `actions == ["create"]` instead of testing membership. - Assuming a replacement is reported as an `update`. - Reading `change.after` for a resource being destroyed. - Assuming `no-op` entries are absent from the array, and so writing a rule that also fires on untouched infrastructure.