Skip to main content
OpsRoadmaps

Checklists / terraform-pr

Terraform Pull Request Checklist

Review an infrastructure change the way infrastructure breaks: plan first, state safe, blast radius known.

9 steps · 9 required · last reviewed (next review 2027-03-19) · updated 2026-09-21

Related focus areas:DevSecOpsGitOpsInfraOps

Roadmaps covering the same ground:AWS Security ImprovementDevSecOps RolloutProduction-Ready Kubernetes

Sign in to run this checklist

Infrastructure code review is not app code review with longer files — the failure modes are different (state corruption, surprise destroys, provider drift). This checklist is for both the author and the reviewer: the author attaches evidence, the reviewer verifies it.

The single most valuable artifact is the plan output. A PR without a plan is a request to approve a change nobody has seen.

  1. terraform plan output is attached to the PR (additions AND destructions visible)

    required

    The plan is the change. Reviewing HCL without the plan reviews what the code says, not what the cloud will do.

  2. Every destroy (-) action in the plan is individually justified

    required

    Destroying a resource is the one class of change that can silently delete data or drop an endpoint — each one gets a sentence of why it is safe.

  3. State is remote, locked, and encrypted — no local state files in the PR

    required

    Local state means credentials and topology in random laptops; locking means two engineers cannot corrupt state concurrently.

  4. Changes are additive where possible (rename = destroy + create; use lifecycle blocks to avoid it)

    required

    Terraform treats a rename as destroy-then-create; an unreviewed rename is how databases get dropped by a refactor.

  5. New resources have tags/labels matching the ownership convention

    required

    Untagged resources become orphans nobody dares delete — the cloud bill and the incident response both suffer.

  6. Secrets are referenced, never hardcoded (var, secret manager, or data source)

    required

    A secret in HCL is a secret in state, in plan output, and in git history — three leaks for the price of one.

  7. Plan is re-run against the latest main before merge

    required

    Infrastructure drifts; a plan from this morning may not describe what merging now will do.

  8. Rollback is documented: previous commit, apply, and expected drift

    required

    For infrastructure, rollback is usually git revert + apply — but write it down before you need it at 2 a.m.

  9. Module changes are checked for consumers beyond this stack

    required

    A shared module edit has a blast radius of every stack that includes it — search before you change.

Run it against your real gaps

A checklist is most useful when you know which controls you are actually missing. A free OpsRoadmaps assessment scores your controls with explainable findings and builds a roadmap from the results.

Assess my stack

Checklists document self-reported practice. Items were last reviewed 2026-09-19 — adapt them to your own environment.