Skip to main content
Now that we understand what Terraform state is, let’s examine how Terraform manages state in practice and why it matters for collaboration, safety, and incremental updates.
The image features the text "Terraform State Management" with a minimalist design, including a gradient blue shape on a white background.

​
Example: A simple Azure Storage Account

Here is a minimal azurerm_storage_account resource using a variable for the storage account name:
When you run terraform apply and pass the storage account name, Terraform does two things:
  • Creates (or updates) the resource in Azure.
  • Writes a local state file called terraform.tfstate (by default).
You do not create this file manually—Terraform manages it automatically. Example apply and local state output:
This terraform.tfstate file represents the current infrastructure as Terraform knows it.

​
What is inside the state file?

Terraform state acts as the authoritative mapping between your configuration and the real-world infrastructure. Think of it as Terraform’s memory: without it, Terraform cannot determine which resources exist, their IDs, or which attributes have changed. A simplified excerpt of a Terraform state file (JSON):
This JSON includes provider info, resource types and names, and all recorded attributes (SKU, replication type, access tier, etc.). Because the state can contain sensitive or critical information (resource IDs, endpoints, sometimes secrets), protecting state is essential.
Protect your state: state files can contain sensitive values (resource IDs, endpoints, and occasionally secrets). When storing state remotely, enable encryption and strict access controls to prevent unauthorized access.

​
Where is state stored?

  • By default: terraform.tfstate stored locally in your working directory. This is fine for learning, demos, or single-user scenarios.
  • For teams and automation: use a remote backend (Azure Storage, Amazon S3, Terraform Cloud, etc.) to centralize state, provide locking, and improve access control.
Warning: Local state lacks concurrency protection. Multiple users or CI jobs operating on the same local state can cause conflicts or corruption. Use a remote backend for team workflows.

​
Remote backends — why and when to use them

Remote backends provide several advantages:
  • Centralized storage so all team members and CI pipelines use the same state.
  • Locking support (depending on backend) to prevent concurrent operations.
  • Access control, auditability, and encryption at rest.
  • Integration with remote runs and workspace concepts (e.g., Terraform Cloud).
Popular backend options:
  • Azure Storage Account: reliable for Azure-native workflows.
  • Amazon S3 (with DynamoDB locking): common for AWS and cross-cloud setups.
  • Terraform Cloud: managed state, remote runs, and policy enforcement.
References:

​
Quick comparison: local vs remote state

​
Why state matters (summary)

  • Maps Terraform configuration to real resources (IDs, attributes).
  • Enables incremental updates — Terraform only modifies what changed.
  • Prevents duplicate resource creation and is required for plan/apply/destroy/import.
  • Serves as the source of truth for Terraform operations.
Check your working directory for terraform.tfstate to confirm the resources you’ve deployed. Now that you understand Terraform state and why it’s important, the next step is to configure a remote backend suited to your team and automation needs.

Watch Video