Terraform state is both Terraform's greatest feature and its most common source of production incidents. At small scale a local state file works fine; at team scale it becomes a shared mutable artifact that needs careful management.
Pattern 1 — Remote backends first. Never run production Terraform with local state. S3 + DynamoDB locking on AWS, GCS + native locking on GCP, and Azure Blob Storage are all battle-tested choices. The five minutes it takes to configure a remote backend will save hours of state corruption debugging.
Pattern 2 — Workspaces are not environments. Terraform workspaces were designed for lightweight state isolation, not full environment separation. Using separate root modules per environment (dev, staging, prod) with a shared module library provides the isolation and blast-radius control that workspaces cannot.
Pattern 3 — State segmentation by lifecycle. Networking resources that change quarterly should not share a state file with compute resources that change daily. Blast radius and plan time both shrink when you segment by rate of change.
Pattern 4 — Treat state as sensitive. State files contain plaintext secrets. Encrypt your remote backend bucket, rotate access credentials, and restrict who can perform terraform state commands directly.
Pattern 5 — Drift detection on a schedule. CI applies changes; scheduled pipelines detect drift. Even well-run organizations accumulate console-applied changes. Running terraform plan --detailed-exitcode on a cron schedule surfaces drift before it becomes an incident.