Day 4 : Terraform State File and Remote Backend

Today was one of those “oh… now Terraform makes sense” days. Everything finally clicked how Terraform keeps track of infrastructure, how it knows what changed and why teams shouldn’t rely on local state at all.

This is my Day 04 breakdown, in simple terms and straight from my terminal experience.

1. Understanding Terraform State (tfstate)

Before today, I never really understood how Terraform decides what to create, update, or destroy. Now I do and it’s all thanks to the state file.

Terraform stores every single detail about your infrastructure inside:

terraform.tfstate

This file contains:

• resource metadata
• IDs and attributes generated by AWS
• dependency relationships
• the full mapping between your .tf files and real-world infrastructure

Terraform literally updates infrastructure by comparing:

Desired State (your code)
vs
Actual State (stored in the state file)

That comparison is what makes Terraform incredibly smart.

2. The Problem with Local State

By default, Terraform saves the state file on your machine.
And honestly, that’s risky for anything beyond solo experimentation.

Local state creates issues like:

Being unable to collaborate
Easy accidental deletion
No state locking
No versioning
Security risks

Once you understand how critical the tfstate file is, you automatically understand why teams use a remote backend.

3. Remote Backend with S3 and Why It Matters

Today, I configured Terraform to store the state file in AWS S3.

This changes everything:

Safe and centralized storage
Versioning (optional but very useful)
Better collaboration
No accidental losses
Encrypted by default
Easy rollback

And with the new backend behavior, S3 now handles state locking internally, meaning no extra DynamoDB setup.

Huge improvement.

Backend Block I Used Today

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

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "first_bucket" {
  bucket = "devopswithzacks-bucket-001"

  tags = {
    Name        = "My bucket 2.0"
    Environment = "Dev"
  }
}

4. State Locking Prevents Disaster

State locking prevents two people from running:

terraform apply

at the same time.

Without locking You can corrupt the state file and break your entire infrastructure. But With S3 backend and the new lockfile behavior is Safe, Reliable and Team-ready. No DynamoDB needed.

5. Commands I Used Today

I ran:

• terraform init
• terraform plan
• terraform apply -auto-approve
• terraform state list
• terraform state show
• terraform state pull
• terraform state show <resource name>

The state commands were the highlight especially terraform state show, which lets you see the internal details Terraform stores about a specific resource. It was the moment I actually understood how Terraform remembers.

---

Day 04 Video Walkthrough

My Day 04 Takeaways

• Terraform’s state file is the heart of everything.
• Local state is fine for practice but dangerous for real work.
• S3 remote backend makes Terraform professional and safe.
• State locking prevents broken deployments.
• Understanding state and how Terraform really works.

Honestly, this day felt like a major level-up. Day 04 wasn’t just theory it was understanding how Terraform truly behaves behind the scenes. This is the kind of knowledge that separates beginners from engineers who can manage real infrastructure.

Excited for Day 05 Let’s keep going.