How would you design Terraform state management across 200+ configurations with locking, isolation, and disaster recovery?
Whether you can reason about blast radius and isolation boundaries at scale, instead of reaching for one giant state file or treating workspaces as real separation.
I'd split state by isolation boundary, not by convenience: one backend key per environment per component, so a bad apply to staging networking can never touch prod databases. I use an S3 backend with native state locking (the use_lockfile option, GA in Terraform 1.11, so no separate DynamoDB table), versioning and KMS encryption on the bucket, and a strict naming convention like env/component/terraform.tfstate. Terragrunt keeps that backend config DRY across 200 stacks. DR is just bucket versioning plus cross-region replication, with a tested restore runbook.
One state per blast radius.
- How do you recover a corrupted or accidentally deleted state file?
- A lock is stuck after a crashed pipeline. What now?
- How do you pass data between separate state files?
In the book this question runs three pages: it adds a deep dive with a diagram, a decision framework, a pitfalls table and a worked answer to each follow-up.
