Terraform Best Practices: How to Not Nuke Production

Sun, 25 Jan 2026 20:30:00 +0530

Writing Terraform is easy. Managing Terraform at scale without destroying your company’s infrastructure is hard.

If your idea of “state management” is a file on your laptop named terraform.tfstate.backup2, stop. Here are some tips to not embarrass yourself in front of management.

1. Remote State is Non-Negotiable

If you work on a team (or ever plan to), your state file cannot live on your local machine.

The Problem: If two people run terraform apply at the same time with different local states, you get a race condition that corrupts everything.
The Fix: Use a Remote Backend (like AWS S3).
The Lock: Use DynamoDB for state locking. This prevents “Person B” from writing to the state while “Person A” is still deploying.

# backend.tf
terraform {
 backend "s3" {
 bucket = "my-corp-terraform-state"
 key = "prod/app-server/terraform.tfstate"
 region = "us-east-1"
 dynamodb_table = "terraform-state-locks"
 encrypt = true
 }
}

*Fig: Actual footage of a DevOps engineer looking at a local state file.*

2. Keep it DRY Dummy!

Stop Copy-Pasting resource blocks. If you need 5 web servers, do not write the aws_instance block 5 times. Use Modules.

IaC on Ansuman Satapathy

Terraform Best Practices: How to Not Nuke Production

1. Remote State is Non-Negotiable

2. Keep it DRY Dummy!