What is Terraform State

Objective

In this section, we discuss the concept of Terraform state.

Terraform is responsible for creating or altering resources on a platform (for example, deploying pods to Kubernetes or creating resources on AWS). To manage this, Terraform needs some sort of memory — a record of the current state of resources at any given time.

This “memory” is called the Terraform state.

It’s useful because, based on what you ask Terraform to do, it can look up the current state from its state file and generate the so-called terraform plan. In short:

The current state + desired configuration → Terraform Plan

---

Where is Terraform State Stored?

When you initialize a Terraform project with terraform init, the state is often stored locally in a file named .tfstate.

At first glance, that seems fine — but losing this file means losing Terraform’s memory. Without it, Terraform can no longer understand what resources exist or what to change. Hence, securing this file and avoiding accidental deletion is critical.

Best Practices

• Store the state file remotely — for example, in AWS S3, so that your team can share infrastructure changes safely. Using S3 versioning and locking also adds extra security and recoverability.

• Alternatively, store it in HashiCorp Cloud, which provides fine-grained access controls and additional convenience.

---

How to Store the State File in S3

To store your Terraform state remotely in S3, follow these steps:

1. Create an S3 bucket to hold the state file. Example: tf-state-bucket

2. Create a DynamoDB table to manage state locking. Example: tf-state-table with partition key LockID

3. Ensure your Terraform IAM role has GetObject and PutObject permissions for the S3 bucket.

Then, configure your Terraform backend in a file named backend.tf:

terraform {
  backend "s3" {
    bucket         = "tf-state-bucket"
    key            = "key-for-deployment"
    region         = "us-east-2"
    dynamodb_table = "tf-state-table"
  }
}

This tells Terraform to use S3 as the remote backend. All changes to your infrastructure will now be reflected in the S3 state file.

This is particularly important when using GitHub Actions or other CI/CD workflows, since those runs are ephemeral — they don’t persist local state. A remote S3 backend ensures consistent state management across environments and runs.