You own the human approval gate for infrastructure-as-code changes across many teams. How do you decide which changes require an approval, and what makes such an approval meaningful rather than a rubber stamp?

## What an approval gate is actually for It transfers a decision to a human who has the concrete proposed actions in front of them and the standing to refuse. Everything else about the gate — the ticket, the record, the timestamp — is bookkeeping. If the approver cannot realistically say no, there is no gate, only a delay with an audit trail. There are two failure modes and they pull in opposite directions. Too many gates produce attention exhaustion: approvals become reflexive, people batch unrelated changes into one large approved diff to pay the toll once, and the batching makes each diff harder to review, which makes the reflex worse. Too few gates let an irreversible change through unread. The job is to spend a limited approval budget where it buys the most. ## Gate on content, not on volume The useful question is not "is this production?" but "what does this diff contain, and can I undo it?" A workable routing: - **Always human**: destroy or replace of anything stateful or shared; changes to identity and permission boundaries; changes that widen network exposure; changes to backup, retention or encryption settings; anything in the production environment that is not on the auto-approve list. - **Automated checks only**: purely additive resources in non-production; tag, label and description edits; changes bounded by an autoscaler; version bumps of a module already promoted through lower environments. - **Blocked outright, not approved**: actions that no approval should authorise, like destroying a resource declared undeletable. If the answer is always no, encode it as a rule and let the preview fail rather than asking a human every time. That last category matters more than people expect. A gate should not be the place where the organisation's actual rules live; rules that never legitimately vary belong in automated checks that fail closed, and the human gate is for judgment calls the machine cannot make. ## Who should hold it The team that gets paged for the resource. Approval by an owner aligns the incentive: the person accepting the risk is the person who eats the consequence. A central change-advisory board reviewing diffs for systems it does not operate approves everything within a month, because it has no basis to refuse. Separation of duties is worth keeping for production: the author should not be the only approver. But keep it proportionate — a second person from the same team who understands the system is worth more than a senior person from another one who does not. ## Make the diff reviewable, or the gate is theatre This is the part most organisations skip, and it decides the outcome more than the policy does. - Keep changes small. A five-resource diff gets read; a four-hundred-line one gets skimmed. - Split large estates so one change touches one bounded area. - Surface a summary first — counts of create, update, replace and destroy — and highlight the destructive lines. - Eliminate noise. Formatting churn, unstable ordering, and diffs that show unrelated drift every run all teach reviewers that most of the output is ignorable, and that lesson generalises to the one line that mattered. - Give the reviewer the *why*: the linked change description matters as much as the actions. ## The gate is one control among several Approval sits alongside automated rule evaluation of the diff, post-apply verification, and reversibility. They trade off: a change you can undo in one minute needs far less pre-approval than one you cannot undo at all. Investing in reversibility — snapshots before destructive applies, tested restore paths — buys you the right to gate less, which raises the quality of the gating you keep. ## Knowing whether it works Track how often the gate actually changes an outcome. If no approver has declined or amended a change in six months, the gate is not protecting you; it is a tax whose only output is a timestamp. Also watch approval latency and where changes queue: if teams wait a day for approval, they will batch, and batching is the thing that makes diffs unreviewable. Both signals should feed back into what gets auto-approved. ## Interview framing Make the case that approvals are a scarce resource, route them by blast radius and reversibility, put them with the people who operate the system, and then talk about diff readability as a first-class investment. Ending on measurement — a gate that has never stopped anything is theatre — is what distinguishes an owner's answer from a policy recital.