Terraform is powerful, but understanding how it keeps track of your infrastructure is even more important. On Day 4, I learned the secret behind Terraform’s “memory” — the state file — and why moving it to a remote backend is a must for real-world DevOps work.
What Exactly Is the Terraform State File?
Whenever Terraform creates a resource, it needs to remember:
- What was created
- Its attributes
- Its unique IDs
- Current configuration details All of this is stored in a file called:
terraform.tfstate
This file is the source of truth for Terraform.
It helps Terraform compare two things:
🟢 Desired State
What I define in .tf files (like creating an S3 bucket, EC2 instance, VPC).
🔵 Actual State
What actually exists in AWS right now.
Terraform compares both and decides whether to:
- Create
- Update
- Delete a resource. This is the heart of Infrastructure as Code.
Why Local State is Dangerous
By default, the state file is created locally, which is risky because:
❌ It contains sensitive data
❌ It can be deleted accidentally
❌ It cannot be shared with a team
❌ Multiple people modifying it can corrupt it
This is where remote state storage becomes essential.
Using a Remote Backend (AWS S3)
A remote backend stores the state file in a secure, centralized location.
For AWS users, the most common choice is S3.
Benefits of Remote Backend
- Safe and encrypted storage
- Easy collaboration within teams
- Supports versioning
- Can be accessed by CI/CD pipelines
- Prevents conflicts using state locking
- The state file now lives in S3, not on your laptop.
What Is State Locking?
Terraform operations must happen one at a time.
If two users run terraform apply simultaneously, the state file can get corrupted.
State locking ensures:
- Only one process uses the state at a time
- Others must wait until the lock is released
Earlier, Terraform used DynamoDB for locking.
Now S3 supports
use_lockfile = true, making it much simpler.
Testing the Setup
With the backend configured, commands like:****
- terraform init
- terraform plan
- terraform apply now interact with the remote state file inside S3. You can even run:
List resources:
terraform state list
Show resource details:
terraform state show <resource_name>
Remove resource from state (advanced):
terraform state rm <resource_name>
These commands help you understand and manage the state without touching the file manually.
Key Takeaways from Day 4
✔ Terraform state file is the memory of your infrastructure
✔ Always store state remotely — never locally
✔ Use S3 for remote backend + built-in locking
✔ Never edit the state file manually
✔ Keep separate state files for dev, test, prod
✔ Use versioning/backups for safety
Understanding Terraform state changed how I look at Infrastructure as Code.
It’s not just about writing .tf files — it’s about managing your infrastructure’s single source of truth.
Top comments (0)