How do you manage Terraform state securely in a multi-team environment?

Think of Terraform state as a shared bank ledger. If multiple tellers write to the same page at the same time, the numbers get corrupted. If someone photocopies the ledger and takes it home, sensitive account details are exposed. Managing state securely means controlling who can read it, who can write to it, and ensuring only one person writes at a time.

Terraform state contains the full mapping between your HCL code and real infrastructure — including resource IDs, IP addresses, and sometimes sensitive values like database passwords and private keys. In a multi-team environment, this state must be stored remotely (never in Git), encrypted, locked during operations, and access-controlled. The standard pattern on AWS is an S3 bucket with server-side encryption (KMS), versioning enabled for recovery, and a DynamoDB table for state locking.

The locking mechanism prevents concurrent writes. When terraform plan or apply runs, it acquires a lock in DynamoDB using the state file path as the key. If another team member or pipeline tries to run simultaneously, they get a lock error and must wait. This prevents state corruption from concurrent modifications. The lock is released automatically when the operation completes, or can be force-unlocked with terraform force-unlock if a pipeline crashes mid-operation.

At multi-team scale, state should be split by ownership boundary. Each team or component gets its own state file — the networking team manages vpc/terraform.tfstate, the platform team manages eks/terraform.tfstate, and application teams manage their own app/terraform.tfstate. This means a terraform destroy by the app team cannot touch the VPC or EKS cluster. Cross-team references use terraform_remote_state data sources or SSM parameters rather than managing resources across state boundaries.

The non-obvious gotcha is that terraform_remote_state requires read access to the other team's state file, which contains all their sensitive outputs. A safer alternative is writing shared values to SSM Parameter Store or Vault, so consumers get only the specific values they need without accessing the full state. Also, state files should never be committed to Git — even encrypted state contains sensitive metadata that can leak through Git history even after deletion.