Your Terraform Runs Keep Conflicting Because Nobody Configured State Locking

Your Terraform runs keep conflicting because nobody configured state locking.

Here's why it matters.

Terraform state is a shared file.

Every time you run terraform apply, Terraform reads the state file, compares it to your config, figures out what changed, and writes the new state back.

If two people run apply at the same time, they're both reading and writing to the same file. That's a race condition.

What goes wrong without locking:

Person A runs apply. Person B runs apply at the same time. Both read the same state and both make changes. Person B's write overwrites Person A's changes.

Now your state file says resource X exists, but it was actually deleted. Or it says resource Y has config Z, but it actually has config W.

Your state no longer reflects reality and Terraform is now guessing.

State locking prevents this.

When you configure a backend that supports locking, Terraform acquires a lock before doing anything. If someone else is already running, you get a message saying the state is locked and who has it.

No race condition. No corrupted state. No mysterious drift.

The fix is simple.

Use a remote backend that supports locking. Most do: S3 with DynamoDB, Azure Blob, GCS, Terraform Cloud. Local state files don't lock.

If you're running Terraform as a team without state locking, you're one concurrent apply away from a very bad day.

#TechTuesday #LearnWithOJ #SoftwareEngineering #DevOps #SRE #Terraform #InfrastructureAsCode #IaC