Terraform state: shared ownership and safe plans

Operational decision

For a fraud-review service, keep network infrastructure and application-level resources in separately owned state units. Run validation and a plan on the proposed configuration, then apply the approved revision with the same provider lockfile and a serialized state writer. Treat saved plan files and state as sensitive because provider attributes can contain secret material. A plan is also time-sensitive: another actor may change infrastructure after it was reviewed. Recheck drift before apply and abort if the target state no longer matches expectations. The commands below demonstrate review and apply order but do not configure a backend; choose a backend with locking and protected access before collaborative use. Never disable locking to make a stuck pipeline pass.

terraform init -input=false
terraform fmt -check
terraform validate
terraform plan -out=reviewed.plan
terraform apply reviewed.plan

Cost and verification

Remote state adds storage and access-management cost. Locking serializes writes and may make a queued apply wait, which is preferable to corrupting shared state. A saved plan can become stale if remote resources change; keep the approval window short and let the apply fail safely when assumptions no longer hold. Do not print state or plan output into broadly visible logs. Commit configuration and the provider lockfile, while excluding state, state backups, and saved plans from version control.

Common Mistakes

• Do not commit state or saved plans.
• Do not disable locking to clear contention.
• Do not apply an old plan after unrelated infrastructure changes.

Connected lessons

• DevOps Tutorial
• GitOps reconciliation: desired state and drift
• Secrets and configuration across the delivery path
• Backups and disaster recovery: prove the restore path

Operational follow-up

• Configuration management: converge hosts without surprise restarts

Advanced follow-up

• Terraform modules: small interfaces and explicit state owners

Advanced follow-up

• Infrastructure drift: distinguish emergency repair from unauthorized change

Advanced follow-up

• Cloud API throttling: keep infrastructure changes inside a request budget
• Ambiguous cloud creates: reconcile before repeating a timed-out mutation

Advanced follow-up

• Terraform provider locks: review the executable dependency
• Terraform state locks: distinguish a stale lease from an active writer
• Terraform state secrets: redaction is not removal

Continue with: Infrastructure plans: classify every action before apply.