Plan/Apply Approval Workflows

The control that makes automated infrastructure safe is a human approving the plan before apply. A Terraform plan is a precise, reviewable artifact — it lists every resource being created, changed in place, or destroyed and recreated — so reviewing it is much like reviewing a code diff. The approval gate is where a reviewer catches the -/+ replacement of a production database before it happens instead of explaining the outage afterward.

Designing the gate well is mostly about three things: what to actually read in the plan, how short to keep the window between approval and apply, and how much stricter production should be than a sandbox. A gate that rubber-stamps summary counts is worse than no gate, because it manufactures false confidence.

The Plan as a Review Artifact

Read a plan the way you read a code diff: line by line, looking for the dangerous changes. The symbols carry the meaning — + creates, ~ updates in place, - destroys, and -/+ destroys and recreates. The -/+ lines and the - lines are where outages live. A plan that says "Plan: 4 to add, 1 to change, 2 to destroy" is hiding the two things you most need to look at behind a one-line summary.

# aws_db_instance.main must be replaced
-/+ resource "aws_db_instance" "main" {
    ~ instance_class = "db.t3.medium" -> "db.m5.large"
    ~ character_set_name = "AL32UTF8" -> "WE8ISO8859P1" # forces replacement
      # (12 unchanged attributes hidden)
  }

Plan: 1 to add, 0 to change, 1 to destroy.

The summary reads "1 to add, 1 to destroy" — innocuous until you notice the added and destroyed resource is the same database, replaced because character_set_name is a force-new argument: RDS cannot change a database's character set in place, so Terraform must destroy the instance and its data and recreate it. (An engine_version bump, by contrast, is an in-place upgrade.) Approve on the summary alone and you have signed off on destroying production data. The forces replacement annotation is the warning, and it only appears in the body of the plan.

Approval Gates

The gate is built from required reviewers on the pull request and an environment protection rule that holds the apply until a named approver signs off. On GitHub, a protected environment with required reviewers pauses the apply job until someone approves it in the UI; GitLab and others have equivalents. Production gets a manual apply approval on top of code review — two distinct sign-offs, because the code being correct and the plan being safe to apply right now are different judgments.

What to Scrutinize

Spend the review budget where the damage is. Replacements (-/+) of stateful resources — databases, volumes, anything holding data — are the highest-stakes lines. Large destroy counts deserve a pause to confirm they are intended, not the result of a botched refactor that dropped a moved block. IAM and security-group changes are the ones that quietly widen access or lock you out. A plan that only adds resources is low-risk; a plan that destroys, replaces, or rewrites permissions is where a reviewer earns their keep.

Drift and Stale Plans

An approved plan describes the world as it was when the plan ran. Let it sit for hours and reality drifts — someone else applies, a console change lands, an autoscaler moves a count — and the saved plan now describes a world that no longer exists. Applying it can fail or, worse, change something the plan no longer accurately represents. Keep the plan-to-apply window short, and re-plan if the approval has gone stale rather than applying an old artifact against new reality.

Segregating Production

Production should not run on the same loose process as a sandbox. Give it stricter approval — more required reviewers, a named on-call approver, a manual gate — and separate credentials, so the role CI assumes for prod is distinct from the one it uses for dev and can be revoked independently. A sandbox apply going wrong costs an afternoon; a production apply going wrong costs an incident, and the gate should reflect that asymmetry.