Terraform State

You are a Terraform infrastructure engineer. The user wants to configure and manage Terraform state using remote backends (S3, Azure Blob Storage, or Google Cloud Storage).

What to check first

• Run terraform version to confirm Terraform is installed (v0.12+)
• Verify cloud credentials are configured: aws configure (AWS), az login (Azure), or gcloud auth application-default login (GCP)
• Check existing state with terraform state list to see current resources

Steps

1. Create a backend.tf file in your Terraform root directory to define the remote backend configuration
2. For AWS S3: specify bucket, key, region, and encrypt = true in the s3 backend block
3. For Azure: specify resource_group_name, storage_account_name, container_name, and key in the azurerm backend block
4. For GCS: specify bucket, prefix, and optionally encryption_key in the gcs backend block
5. Run terraform init to initialize the backend—Terraform will prompt to migrate existing local state if it exists
6. Confirm migration by typing yes when prompted to copy state to the remote backend
7. Verify state was uploaded by checking the cloud storage bucket directly (S3 console, Azure Storage Explorer, or gsutil ls)
8. Use terraform state pull to download the current state file for inspection or backup
9. Enable state locking by adding DynamoDB (S3), Blob Storage lease (Azure), or GCS native locking

Code

# backend.tf - AWS S3 Example
terraform {
  required_version = ">= 1.0"
  
  backend "s3" {
    bucket         = "my-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    encrypt        = true
    dynamodb_table = "terraform-locks"
  }
}

# backend.tf - Azure Blob Storage Example
terraform {
  backend "azurerm" {
    resource_group_name  = "rg-terraform"
    storage_account_name = "tfstorageaccount"
    container_name       = "tfstate"
    key                  = "prod.tfstate"
  }
}

# backend.tf - Google Cloud Storage Example
terraform {
  backend "gcs" {
    bucket  = "my-terraform-state-bucket"
    prefix  = "prod"
  }
}

# For S3 with DynamoDB locking (optional but recommended)
resource "aws_s3_bucket" "terraform_state" {
  bucket = "my-terraform-state"
}

resource "aws_s3_bucket_versioning" "terraform_state" {
  bucket = aws_s3_bucket.terraform_state.id
  versioning_configuration {
    status = "Enabled"
  }

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Treating this skill as a one-shot solution — most workflows need iteration and verification
• Skipping the verification steps — you don't know it worked until you measure
• Applying this skill without understanding the underlying problem — read the related docs first

When NOT to Use This Skill

• When a simpler manual approach would take less than 10 minutes
• On critical production systems without testing in staging first
• When you don't have permission or authorization to make these changes

How to Verify It Worked

• Run the verification steps documented above
• Compare the output against your expected baseline
• Check logs for any warnings or errors — silent failures are the worst kind

Production Considerations

• Test in staging before deploying to production
• Have a rollback plan — every change should be reversible
• Monitor the affected systems for at least 24 hours after the change