Day 4 - Terraform State File Management with Remote Backend

Today felt different.

Until now, Terraform was just creating resources.
But today, I learned how Terraform remembers what it creates, and how to manage that memory safely using a remote backend.


Why Remote State Matters

When Terraform runs, it keeps track of infrastructure in a state file.

If that file stays on a local machine:

  • It’s not shareable
  • It’s not safe
  • It can easily get corrupted or lost

Moving state to Amazon S3 solves this.

  • Teams can collaborate
  • State is stored securely
  • Changes are tracked with versioning
  • Locking prevents conflicts

What I Built Today

I configured Terraform to:

  • Store state in an S3 bucket
  • Enable encryption
  • Use native state locking (no DynamoDB required)
  • Create a new S3 bucket using Terraform

Step 1: Created S3 Bucket for State

I manually created an S3 bucket and enabled versioning.



Step 2: Configured Remote Backend

I updated my Terraform configuration to use S3 as backend:

backend "s3" {
bucket = "my-terraform-state-bucket"
key = "day-04/dev/terraform.tfstate"
region = "us-east-1"
use_lockfile = true
encrypt = true
}



Step 3: Initialized Terraform

terraform init

Terraform detected the backend and migrated my state to S3.



Step 4: Created S3 Bucket Using Terraform

I used Terraform to create a new S3 bucket:



Step 5: Verified State in S3

After applying, I checked my S3 bucket and saw the terraform.tfstate file.



Step 6: Tested State Locking

This was the most interesting part.

I ran Terraform in two terminals at the same time.

The second command failed with a lock error — which means Terraform successfully prevented concurrent changes.


Step 7: Inspect state

After creating resources, I explored how Terraform tracks infrastructure internally using state commands.



This showed all resources currently managed by Terraform.


This displayed detailed information about the S3 bucket, including its attributes and configuration.


This command pulled the entire state file from the remote backend (S3) in JSON format.

What I Observed

  • Terraform maintains a complete mapping of resources in the state file
  • The state file contains metadata, attributes, and dependencies
  • Even though I don’t see the infrastructure directly, Terraform “knows” everything through state
  • State is now stored remotely in S3, not on my local machine

What I Learned

  • Terraform state is the backbone of infrastructure management
  • Remote state is essential for real-world usage
  • S3 native locking simplifies setup (no DynamoDB needed)
  • Locking prevents accidental overwrites and conflicts

Final Thoughts

Today was not about creating resources.

It was about protecting them.

I realized that the state file is essentially Terraform’s single source of truth , if it’s wrong, everything else can go wrong. Terraform is powerful, but without proper state management, it can become risky.
With remote state and locking in place, it starts to feel production-ready. 


Video Reference


Jay

Comments

Popular posts from this blog

ASM Integrity check failed with PRCT-1225 and PRCT-1011 errors while creating database using DBCA on Exadata 3 node RAC

Lock Tables in MariaDB

Life is beautiful