How-to
Who Should Approve a terraform apply?
Approve a terraform apply by risk, not by job title. IAM, network, and data-store changes need a named owner. Tag hygiene should not wait on a director. How to design the gate without approval fatigue.
terraform apply approval · reference
The person who should approve a terraform apply is the person who can own the blast radius of that exact plan — not whoever is next in Slack.
Most approval pain comes from one rule for every change. Governance is risk-based routing, not a stamp queue.
Approve the plan, not the pull request
A merged PR is necessary. It is not sufficient.
Between merge and apply, state refreshes, someone else applies first, or a workspace points at the wrong account. The artefact to approve is the saved plan (terraform plan -out, then apply that file). If your gate only looks at Git, you approved a story.
Reviewers need:
- resource addresses and the create / update / destroy counts,
- policy failures and warnings,
- who requested the run and which identity will apply,
- a one-screen blast-radius note (what is public, what is stateful).
The longer write-up is approval gates for safe rollouts.
A practical routing table
| Change class | Who approves | Default |
|---|---|---|
| Tags, comments, documentation-only | Automation + author | Auto-apply after policy |
| Stateless compute behind existing network | Team lead or on-call for that service | One reviewer |
| IAM, org policies, key trusts | Security or platform identity owners | Two-person rule in prod |
| Ingress, DNS, peering, firewalls | Network / platform owners | No self-approve |
| Databases, disks, backups | Data or service owner | Mandatory human |
| Break-glass | Incident commander + recorded role | Time-boxed, reviewed after |
Write this table down. If everything is “platform team,” you will get rubber stamps at 5 p.m. on Friday.
Who should not be the only approver
- The CEO, by default. Escalation is fine. A standing bottleneck trains people to go around the process.
- A shared “terraform” GitHub account. That is a credential, not a reviewer.
- The model that drafted the HCL. AI for IaC can narrate a plan. It cannot accept residual risk.
Identity is part of the gate
Approvals are fiction if apply still uses a laptop access key.
Prefer OIDC from CI or a control plane role (GitHub Actions OIDC), SSO-backed users, and SCIM so leavers lose apply rights the same day they lose email.
If you want this table attached to the saved plan — not the pull request — use approval workflows. Fewer reviews. Better ones.