In the previous subchapter, we added a DynamoDB table to our backend "for locking." Now let's really understand what state locking is and why it is essential when several people work on the same infrastructure. It is the piece that prevents one of the worst possible disasters with Terraform: state corruption.

Remember that the state (Chapter 11) is the file that records which resources exist and how they relate. It is Terraform's "source of truth." Now imagine this situation in a team:

If both modify the state at the same time, their changes mix and get corrupted. The state file can become inconsistent: half-written records, duplicated resources, or a state that no longer reflects reality. A corrupt state is a nightmare: Terraform loses track of what exists, and fixing it by hand is slow and dangerous.

Analogy: it's like two people editing the same document at the same time without coordination, each saving over the other's changes. The result is a ruined document where changes are lost and nothing makes sense. You need that, while one edits, the other waits their turn.

State locking solves this with a simple rule: while someone is modifying the state, no one else can do it at the same time. Terraform puts a "lock" before starting to work and removes it when finished.

This way, operations are serialized: they happen one after another, never at the same time. The state is never corrupted by simultaneous access.

This is where the DynamoDB table we set up in subchapter 20.1 comes in. It acts as the "lock doorman":

1. When someone runs apply (or plan), Terraform writes a lock record in the DynamoDB table (in the LockID key).
2. If someone else tries to run Terraform, it checks the table, sees that there is already an active lock and waits (or notifies that it is locked).
3. When the first person finishes, Terraform deletes the lock record, releasing the lock.

DynamoDB is ideal for this because it guarantees atomic and consistent operations: two people cannot "grab the lock" at the same time; only one wins.

If you try to run Terraform while someone else has the lock, you'll see a message like this:

This tells you who has the lock and since when. It's not a "bad" error: it's Terraform protecting you. You simply wait for the other person to finish and try again.

The good news: once the backend is configured with DynamoDB (subchapter 20.1), locking works automatically, without you having to do anything. Terraform puts on and removes the lock automatically in each operation. You simply work as usual, and the system protects you in the background.

Occasionally, a lock can get "stuck": for example, if someone's connection is cut off in the middle of an apply, the lock might not be released. In those rare cases, there is the terraform force-unlock command to manually remove the lock:

⚠️ Use it with great care. Before forcing the unlock, make sure that no one is actually working on the state. If you force the unlock while someone is really applying changes, you risk the same corruption that locking was meant to prevent. Always confirm with your team first.

State locking, together with remote state (subchapter 20.1), is what makes Terraform safe for teams. Without it, collaboration would be a ticking time bomb: sooner or later two people would overlap and corrupt the state. With it, dozens of people can work on the same infrastructure without fear. It is the foundation, along with the PR flow (subchapter 12.5), of professional work with Terraform.

• If two people modify the state at the same time, it gets corrupted (becomes inconsistent), which is a disaster that's hard to fix. Like two people editing the same document without coordination.
• State locking (locking) prevents this: while someone is working, they put a lock that prevents others from modifying the state at the same time. Operations are serialized (one after another).
• With the S3 backend + DynamoDB, locking works automatically: Terraform writes a lock record in DynamoDB when starting and deletes it when finished.
• If the state is locked, you'll see a message indicating who has it; it's not a bad error, it's protection. You just wait.
• In rare cases of a "stuck" lock, there is terraform force-unlock, but use it with extreme care and only after confirming that no one is working.

In the next subchapter, we'll see how to move the state between backends safely, something necessary when reorganizing or migrating your infrastructure.