Day 4 — Terraform State File Management & Remote Backend

Terraform works by comparing desired state (your .tf files) with the actual infrastructure using the state file.

What is terraform.tfstate?

• It stores the current state of your infrastructure.

• Terraform uses it to detect what to create, update, or delete.

• It maps real-world resources to Terraform configuration.

⚠️ Never manually edit or delete the state file.

Why Use a Remote Backend?

Storing state locally is risky—especially in teams.

Remote backend (S3) benefits:

• Centralized state for multiple users

• Prevents accidental overwrites

• Enables state locking

• Improves security & reliability

• Supports backups and recovery

Key Concepts

• State Locking: Prevents multiple users from modifying state at the same time

• Isolation: Separate state files for different environments (dev, prod, etc.)

• Regular Backups: Protects against corruption or accidental deletion

Security Considerations (S3 Backend)

• Bucket Policy: Restrict access to authorized users only

• S3 Versioning:

  • Mandatory for native state locking

  • Enables rollback if state is corrupted

• Encryption: Enable server-side encryption (SSE)

• Audit Logs: Enable CloudTrail for access tracking

• IAM Permissions:

  • Grant minimal S3 permissions

  • ❌ No DynamoDB permissions required for native locking

Common Issues & Fixes

• State Lock Error
  If Terraform crashes, the lock may remain
  👉 Fix:

•   terraform force-unlock <lock-id>
  

  • Permission Errors: Verify IAM policies for S3 access

  • Versioning Disabled: Native locking won’t work without it

  • Region Mismatch: Backend and provider regions must match

  • Bucket Name Conflict: S3 bucket names must be globally unique

  • Terraform Version:

    • Minimum: 1.10+ (native S3 locking)

    • Recommended: 1.11+ (stable GA)