Before deploymentpipeline-terraform-review

Infrastructure Change Review Checklist

15 items ·12 critical ·3 warn ·0 info

How to use this checklist

This is the checklist for the change author and the change reviewer when the change touches real infrastructure state: Terraform apply, Ansible playbook run, Kubernetes manifest apply, cloud API call. It assumes the underlying repository has already passed the Git Repository Production Readiness and Pull Request Review checklists.

A change that has not been worked through this list is not ready for production, regardless of how clean the diff looks. Destructive actions and data migrations are the items most often missed at review; they fail in production instead.

Sign-off

Every critical item must pass. A failing critical item blocks the apply; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical12 items

The change is classified as additive, modifying, or destructive, and the PR or ticket carries that classification. A "no" destroy plan has been confirmed for `terraform plan` and for any Ansible task with `state: absent`.
The blast radius is stated in the description: which environments, which accounts or projects, which clusters, which databases, which load balancers. A change that touches production state without a stated blast radius is rejected.
No state mutation happens outside the formal plan/apply path. `terraform apply` is invoked only from CI with the reviewed plan, never from a developer laptop against production.
```
grep -RIn --include="*.tf" "backend \"local\"" . || true; grep -RIn --include="*.tf" "backend \"s3\"" . | head
```
State locking is enabled and verified (Terraform: DynamoDB lock on S3 backend; Ansible: no shared mutable state). `terraform force-unlock` has not been used in the last 90 days except in a documented incident.
Ansible tasks and Terraform resources are idempotent: re-running the change is a no-op, and the diff after the second run is empty. This is verified for at least one resource in the change set, not just trusted.
Destructive actions (database drops, bucket deletes, namespace deletes, persistent volume reclaim) require a deliberate `prevent_destroy` (Terraform) or `failed_when` / dry-run gate (Ansible). Production data stores have explicit protection.
The rollback path is written down: which commit reverts, what data migration must be reversed, which dependencies (DNS, secrets, certificates) must be re-pointed, and who is on call if the rollback itself fails.
Schema and data migrations are forward-compatible with the previous application version. A migration that requires downtime is paired with a feature flag or an explicit downtime runbook step.
For Terraform, the full `terraform plan -out=tfplan` was generated and the human reviewer has read the plan, not only the summary. For Ansible, `ansible-playbook --check --diff` (or `--check` against a staging inventory) has been observed.
Provider versions, module sources, collection versions, and container image tags are pinned to a digest or exact version. No change references `latest`, a branch, or an unpinned range that can drift between plan and apply.
No plaintext credentials, tokens, or keys appear in the diff. All sensitive values are sourced from the secret manager (Vault, AWS Secrets Manager, SOPS) at apply time. The CI plan output has been scanned for the same.
```
gitleaks detect --source . --no-banner --redact --log-opts="origin/main..HEAD"
```
Approval evidence (PR approvals, change ticket number, change-advisory-board outcome) is attached to the deploy pipeline as a required condition. Deploying without that evidence is a pipeline error, not a warning.

Warning3 items

A change window exists for the affected environment, the window is in the future, and the change has been scheduled against the change-management system with the correct risk class.
The dashboards and alerts that cover the changed component have been identified by URL, and any new alerts (or alert suppressions) needed for the change window are filed with the on-call team.
A post-apply validation plan exists: which queries, which health endpoints, which Argo CD / Flux sync states are expected after apply. The validation must run before the change is considered complete.