Terraform state management Study Guide — 004

Terraform State Management

This guide covers Terraform state management as scoped by the Terraform Associate 004 exam objectives (004 has been the only version since January 2026; 003 is retired). HashiCorp does not publish objective weightings, so this is one of the current blueprint's estimated-even-weight topic areas, not a confirmed largest-domain percentage — do not rely on a specific question count. It tests your ability to reason about how Terraform tracks infrastructure through state, how state is stored and protected, how to manipulate state safely, and how meta-arguments control resource lifecycle behavior.

Terraform State: Purpose, Format, and Sensitive Data

Terraform state is a JSON file that maps your configuration's resources to real-world infrastructure objects. Without state, Terraform cannot determine what already exists, what needs to change, or what must be destroyed.

Core purposes of state:

• Maps configuration resources to real infrastructure (tracking)
• Stores metadata such as resource dependencies
• Caches resource attributes to improve plan performance
• Enables collaboration via remote backends

terraform.tfstate format:

• Plain JSON, stored locally by default in the working directory
• Contains serial (monotonically increasing version counter), lineage (unique ID per state), version (state file schema version), and resources array
• Each resource entry includes type, name, provider, instances, and all attribute values returned by the provider
• terraform.tfstate.backup is created automatically before each state-modifying operation

Sensitive data in state:

• Terraform stores all resource attributes in plaintext in state, including passwords, tokens, and private keys
• Marking a variable or output as sensitive = true does not remove the value from state — it only suppresses display in CLI output
• State must be protected at rest via backend-level encryption (e.g., S3 SSE, GCS CMEK) and in transit via TLS
• Access to state should be controlled via IAM policies because anyone who can read state can read all secrets

Common traps:

• Believing sensitive = true encrypts the value in state — it does not
• Assuming local state is safe for production — it is not (no locking, no encryption, single point of failure)
• Confusing terraform.tfstate.backup as a full history — it is only the previous single state

Remote Backends

A backend defines where Terraform stores state and performs operations. The default backend is local.

Standard backends store state remotely but run operations (plan/apply) locally. Enhanced backends (HCP Terraform/Enterprise) store state and run operations remotely.

S3 backend configuration example:

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

Azure Blob backend requires: resource_group_name, storage_account_name, container_name, key

GCS backend requires: bucket, optional prefix

Common traps:

• Believing the S3 backend alone provides locking — it requires a separate DynamoDB table
• Confusing encrypt = true in S3 backend (enables SSE) with Terraform-level encryption (does not exist natively)
• Thinking HCP Terraform is only a CI/CD tool — it is also a fully supported remote backend
• Mixing up enhanced vs. standard backends: only enhanced backends run terraform plan remotely