Terraform State Management Strategy

What this prompt does

This prompt designs a Terraform state management strategy for a [organization_type] with [team_count] teams managing [resource_count] resources across [environment_count] environments on [cloud_provider]. It configures a remote backend ([backend_type]) with encryption at rest, state versioning for history, and locking, and provides a backend.tf with variable interpolation for environment separation.

It then plans state isolation via [isolation_approach], splitting state per [state_boundary] to limit blast radius, and explains the trade-off between one large monolithic state and many small ones. It covers state file organization with [structure_approach] and cross-state references for [cross_state_references] using terraform_remote_state data sources, concurrency handling in [ci_tool] with locking and queuing, protection of [sensitive_resources] using [mitigation_strategy], migration procedures (terraform state mv, import, rm) with rollback, and disaster recovery that backs state up to [backup_destination] with a documented break-glass lock-override process. State is where Terraform setups quietly go wrong, so the plan treats remote backends, isolation, and locking as non-negotiable from day one.

When to use it

• You're standing up Terraform for multiple teams and want safe state boundaries from day one
• You need a remote backend with locking before concurrent applies cause corruption
• You want to limit blast radius by splitting state per service and environment
• You need cross-state references so app state can read networking outputs
• You're concerned about secrets landing in state files
• You need documented migration and disaster-recovery procedures
• You're moving resources between states and want a tested, reversible procedure first
• You want a break-glass process defined before an incident, not improvised during one

Example output

The AI returns a backend.tf configuration, a written discussion of monolithic versus split state, a directory structure following [structure_approach], terraform_remote_state data-source examples for [cross_state_references], CI locking config for [ci_tool], a sensitive-data mitigation section for [sensitive_resources], step-by-step migration commands with rollback notes, and a disaster-recovery runbook. Expect prose plus code blocks per numbered concern so the reasoning behind each boundary is explicit.

Pro tips

• Choose [state_boundary] by service plus environment so a bad apply to one service can't damage another
• Enable versioning on the backend so you can recover a previous state if an apply goes wrong
• Prefer reading secrets from a secrets manager via data sources ([mitigation_strategy]) over storing them in state
• Document the exact terraform state mv/import/rm steps with rollback before you need them under pressure
• Configure [ci_tool] locking and queuing so two pipelines never apply the same state at once
• Restrict who can override a lock, since the break-glass path bypasses the protection locking provides
• Wire cross-state reads for [cross_state_references] through terraform_remote_state so a service consumes networking outputs without duplicating them
• Replicate the [backup_destination] cross-region so a regional outage doesn't take your state with it