Approvals
Building Approval Gates for Safe Infrastructure Rollouts
How to design approval gates that catch risky IaC changes before they reach production, while avoiding approval fatigue.
2026-07-05 · 2 min read
An approval gate is effective only when the approver has enough context to make a decision. If you are deciding who that person is, start with who should approve a terraform apply.
If an “approve” button doesn’t show the diff, the policies triggered, and the expected impact, the workflow becomes ceremony—and ceremony fails in the real world.
Gate the change based on risk, not habit
Approval should be classified:
- network perimeter changes,
- IAM role/policy trust changes,
- managed database configuration changes,
- any change that increases external exposure.
Low-risk changes (for example, tag-only hygiene) can often be auto-approved with policy warnings or without an explicit gate.
Make the approver’s job explicit
Approvers need:
- a summary of what changed,
- why it matters (severity + blast radius),
- what remediation is expected,
- the exact plan diff they are approving.
OrchesTerra connects these pieces in one place: the governed review includes the infrastructure diff and policy results, so the approver isn’t guessing. Learn more at approval workflows.
Avoid approval fatigue
Approval fatigue appears when:
- reviewers approve without reading (approvals happen immediately),
- too many changes require approval,
- approvers review a stream of noisy diffs with no prioritization.
Fix it by:
- reducing the scope of gated changes,
- prioritizing by severity,
- requiring comments for approvals (so you capture reasoning).
Common pitfalls
- Gating everything.
- Allowing self-approval for the same change.
- No timeout / no escalation for pending approvals.
- Emergency bypass without audit.
- No feedback loop from incident outcomes into the approval matrix.
Start with a 14-day trial and run approval gates on real drift remediation work to tune risk thresholds.
