Terraform State — The Brain Behind Terraform

In the previous article, we learned how Terraform works.

Terraform doesn't simply read your .tf files and call the APIs of AWS, Azure, or another cloud provider.

Instead, every execution follows a process like this:

Configuration
      ↓
Terraform State
      ↓
Refresh
      ↓
Execution Plan
      ↓
Apply

Throughout this entire workflow, Terraform State is the most critical component.

You could say:

If your configuration represents your desired infrastructure, Terraform State is Terraform's memory.

It is also one of the most misunderstood concepts for engineers who are just getting started with Terraform.

Does Terraform Really Need State?

Imagine you have a simple EC2 instance.

Your Terraform configuration looks like this:

resource "aws_instance" "web" {
  instance_type = "t3.micro"
}

You run Terraform Apply for the first time.

AWS creates:

EC2
ID = i-0123456789

Later, you run:

terraform plan

Now consider these questions.

How does Terraform know:

• This EC2 instance already exists?
• Which EC2 belongs to this resource?
• What is its ID?
• What is its current IP address?
• What is its ARN?
• Should it create another one?

Terraform cannot guess.

The provider cannot guess either.

AWS only knows:

"There is an EC2 instance."

It has absolutely no idea that this instance corresponds to a Terraform resource named:

aws_instance.web

Terraform needs somewhere to store that relationship.

That place is Terraform State.

What Is Terraform State?

Terraform State is simply a file.

By default, it is named:

terraform.tfstate

Inside the file is a large amount of metadata.

A simplified example looks like this:

{
  "resources": [
    {
      "type": "aws_instance",
      "name": "web",
      "instances": [
        {
          "attributes": {
            "id": "i-0123456789",
            "instance_type": "t3.micro",
            "private_ip": "10.0.0.15"
          }
        }
      ]
    }
  ]
}

The JSON format itself is not what matters.

The important part is that Terraform knows this mapping:

aws_instance.web
 
↓
 
AWS EC2
 
↓
 
i-0123456789

This mapping is what makes Terraform possible.

What Does Terraform State Store?

State stores much more than just a resource ID.

It contains a wide range of information that Terraform needs to understand your infrastructure.

For example:

• Resource IDs
• ARNs
• IP addresses
• DNS names
• Metadata
• Provider information
• Dependency information
• Outputs
• Sensitive values returned by providers

For example:

aws_lb.main
 
↓
 
ARN
 
↓
 
DNS Name
 
↓
 
Security Groups
 
↓
 
Subnets

Because Terraform already remembers these relationships, it doesn't need to rediscover everything from scratch every time it runs.

State acts as Terraform's memory.

How Does Terraform Work with State?

Every time Terraform runs, it follows roughly the same workflow.

Read Configuration
 
↓
 
Read State
 
↓
 
Refresh State
 
↓
 
Compare
 
↓
 
Create Execution Plan

This is an important detail that many beginners misunderstand.

Terraform does not compare your configuration directly with the cloud infrastructure.

Instead, it compares:

Configuration
 
VS
 
Terraform State (after Refresh)

That distinction is fundamental to understanding how Terraform works.

What Is Refresh?

Imagine someone logs into the AWS Console and changes your EC2 instance from:

t3.micro

to:

t3.small

Terraform doesn't automatically know about this change.

Your State file still contains:

t3.micro

During the Refresh step, Terraform asks the provider:

What does this EC2 instance look like now?

The provider responds:

t3.small

Terraform updates its State.

Only after that does it compare the refreshed State with your configuration.

Desired
 
↓
 
t3.micro
 
Actual
 
↓
 
t3.small

Terraform concludes:

Infrastructure Drift

As a result, your execution plan will show something similar to:

~ update in-place

What Is Infrastructure Drift?

Infrastructure Drift occurs when your actual infrastructure no longer matches your Terraform configuration.

For example:

• A developer modifies a Security Group directly in the AWS Console.
• An operations engineer changes the size of a virtual machine.
• Someone deletes a resource manually from the cloud provider's portal.

Terraform detects these changes during the Refresh step.

This is one of the biggest reasons Infrastructure as Code exists.

If infrastructure can be changed manually at any time, your source of truth quickly becomes unreliable.

The more manual changes happen, the less confidence you can have in your Terraform configuration.

What Happens Without State?

Without State, Terraform has no way of knowing:

• Which resources already exist
• Which resources belong to this configuration
• Which resources should be updated
• Which resources should be destroyed

The result is often something like this:

Plan:
 
+ Create everything

This is why losing your State file is considered one of the most serious incidents in an Infrastructure as Code environment.

The infrastructure may still exist, but Terraform has lost its memory of it.

Local State

By default, Terraform stores State locally on your machine.

terraform.tfstate

Advantages:

• Simple to get started
• No additional configuration
• Perfect for learning and experimentation

Disadvantages:

• Cannot be shared with teammates
• No locking mechanism
• Easy to lose
• Not suitable for collaborative environments

Local State is great for personal projects, prototypes, and learning Terraform.

It is not the right choice for production infrastructure.

Remote State

In production environments, Terraform State is almost always stored remotely.

Common backends include:

• Terraform Cloud
• Amazon S3
• Azure Storage
• Google Cloud Storage

Using a Remote State backend provides several important benefits:

• A shared State for the entire team
• Version history
• State locking
• Protection against accidental overwrites
• Backup and recovery
• Access control and permissions

For most engineering teams, Remote State is considered the standard approach.

It allows multiple engineers and CI/CD pipelines to work with the same infrastructure safely.

Why State Locking Matters

Imagine two engineers both running:

terraform apply

at exactly the same time.

Engineer A is creating a VPC.

Create VPC

Engineer B is deleting a Security Group.

Delete Security Group

If both executions write to the State simultaneously, the State file can become inconsistent or even corrupted.

To prevent this, Remote Backends implement State Locking.

When Terraform starts an operation, it acquires a lock.

Another execution must wait until the first one finishes.

You'll often see a message like:

Acquiring state lock...

Although it may seem like a small feature, State Locking is one of the most important safeguards for production infrastructure.

Without it, concurrent Terraform operations could easily overwrite each other's changes.

Should You Ever Edit State Manually?

In almost every situation, the answer is:

No.

Terraform completely trusts its State.

If you manually edit the State file, Terraform may:

• Lose the mapping between resources
• Recreate existing infrastructure
• Destroy the wrong resources
• Become permanently out of sync with the real infrastructure

If you need to modify State, use Terraform's built-in commands instead of editing the JSON file directly.

For example:

terraform state list
terraform state show
terraform state mv
terraform state rm

These commands understand the internal structure of the State and perform changes safely.

Directly opening terraform.tfstate in a text editor should only be considered as a last resort, and only when you fully understand the consequences.

Common Misconceptions About Terraform State

Terraform reads infrastructure directly every time it runs

Not exactly.

Terraform always relies on State as the source of truth during its planning process.

The provider is queried during Refresh, but State remains the central component that Terraform works with.

State only stores resource IDs

No.

State stores a significant amount of metadata that Terraform uses to calculate execution plans efficiently.

Without that metadata, Terraform would have to rediscover everything on every execution.

Local State is good enough for production

For an individual learning Terraform, yes.

For a team or a production environment, definitely not.

Production infrastructure should use a Remote State backend with versioning and locking.

Deleting the State file is harmless

Deleting the State file does not delete your infrastructure.

However, Terraform loses all knowledge of what it previously managed.

From Terraform's perspective, those resources effectively no longer exist.

Recovering from this situation can be time-consuming and, in some cases, risky.

Summary

Terraform State is much more than a JSON file.

It is the memory that allows Terraform to understand the infrastructure it manages.

Without State:

• Terraform doesn't know which resources belong to it.
• It cannot determine whether resources should be created or updated.
• It cannot accurately detect changes in your infrastructure.

A simple way to think about it is:

Your configuration describes the infrastructure you want, while Terraform State remembers the infrastructure Terraform already manages.

Understanding Terraform State is one of the biggest milestones in moving from simply using Terraform to truly understanding how Terraform works.

Next Up

Now that you understand how Terraform remembers your infrastructure, the next challenge is organizing that infrastructure as your project grows.

As the number of resources increases, placing everything in a single directory quickly becomes difficult to manage.

In the next article, we'll explore Terraform Modules and learn how to design reusable, maintainable infrastructure like a software engineer rather than simply writing infrastructure code.