Q: How do you manage and secure Terraform state files across multiple environments?

Never store development and production state in the same S3 bucket or storage account. Deploy dedicated S3 buckets in dedicated AWS accounts (e.g. `s3-tfstate-dev` in Dev Account, `s3-tfstate-prod` in Prod Account). A compromised dev IAM key cannot access production state.

Configure the S3 bucket with customer-managed AWS KMS keys (SSE-KMS). Enforce TLS 1.2+ for all data in transit via S3 bucket policies rejecting non-HTTPS requests.

# S3 Bucket Policy enforcing HTTPS only
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Deny",
    "Principal": "*",
    "Action": "s3:*",
    "Resource": ["arn:aws:s3:::prod-tfstate-bucket/*"],
    "Condition": { "Bool": { "aws:SecureTransport": "false" } }
  }]
}

Use AWS DynamoDB or native S3 locking (Terraform 1.10+) to prevent concurrent applies from corrupting state. Enable S3 bucket versioning so any accidental corruption can be rolled back to the previous version in seconds. Enable MFA Delete on production buckets.

terraform {
  backend "s3" {
    bucket         = "prod-tfstate-bucket-unique"
    key            = "networking/vpc.tfstate"
    region         = "us-east-1"
    dynamodb_table = "prod-tfstate-locks"
    encrypt        = true
  }
}

Deny direct human access to the production S3 state bucket. Only the automated CI/CD pipeline role (GitHub Actions / GitLab CI via OIDC) has permissions to read and write state files.