In a Terraform plan, how do you gate a change that lowers a database's backup retention window?

## Two different questions a rule can ask A threshold rule asks: *is the end state acceptable?* Read `change.after` for a managed database, compare its backup retention window against your minimum, deny if it is lower. A no-regression rule — a ratchet — asks a different question: *does this change make things worse?* Read both sides of the diff, `change.before` and `change.after`, and deny when the after value is worse than the before value, regardless of whether either satisfies the target. The two produce different verdicts on the same plan, and the difference matters most for infrastructure that predates the policy. Consider a database sitting at three days of retention against a seven-day standard, and an engineer who needs to change its instance size for capacity reasons. Under the threshold rule, that plan is denied: the resource is `["update"]`, so it is in scope, and `after.backup_retention_period` is 3, which is below 7. The engineer did not lower anything — they touched an unrelated attribute — and now they either fix somebody else's retention setting inside an unrelated change, or they route around the gate. Under the ratchet, `before` is 3 and `after` is 3, nothing got worse, and the change proceeds. Now consider a plan that drops retention from 30 days to 1. The threshold rule catches it. So does the ratchet, because 1 is lower than 30 — and the ratchet would still have caught a drop from 5 to 1, which a seven-day threshold rule catches for the wrong reason and a five-day threshold rule would miss entirely. ## Composing the two In practice you write both and combine them by action: - **Creates** (`actions` contains `create`, and `before` is `null`): apply the absolute minimum. A brand-new database has no history to protect and no excuse; this is where the standard is actually enforced. - **In-place updates** (`actions` contains `update`): apply the comparison. Deny when `after.backup_retention_period < before.backup_retention_period`, or when deletion protection goes from true to false. - **Everything else** (`no-op`, `read`, `delete`): no opinion. The `before is null` case is the one that bites. On a create there is no prior value, so a naive comparison of after against before compares a number to nothing. In most policy languages that does not evaluate to false — it produces no result, and the deny silently never fires. A newly created one-day-retention database would sail through a ratchet-only rule. Branch on the action explicitly rather than relying on the comparison to do the right thing on an empty operand. Note also that a **replacement** is not an update: it destroys and recreates the object, so treat it as a create and apply the absolute minimum. The `before` values in a replacement entry describe an object that will not survive the apply. ## What the ratchet buys, and what it does not What it buys is adoption. It lets you turn a rule on across an estate that does not yet satisfy it, without the rule's first victims being engineers who had nothing to do with the violation. Nothing gets worse from the day it ships, and every new resource is held to the full standard. What it does not buy is progress. A ratchet applied to a three-day database keeps it at three days forever; left alone, it will never reach seven. The ratchet is a holding action while a separate, owned effort drains the backlog, and it should be replaced by the plain threshold once the estate is clean — at which point the comparison becomes redundant, because nothing is below the line to protect. There is a second limitation worth stating out loud: a ratchet only sees resources the run touches. A non-conforming database nobody edits appears in no `["update"]` entry and is never evaluated by either rule. Change-scoped gates are blind to untouched infrastructure by construction. ## What people get wrong - Comparing `after` against a constant and calling it a no-regression rule. - Forgetting that `before` is `null` on a create, so the comparison quietly produces no result. - Treating a replacement as an update and carrying forward the doomed object's prior values. - Believing a ratchet improves anything — it only stops decline. - Reading the prior value out of the `configuration` section, which holds written expressions rather than the values in effect today.