State locking with DynamoDB in Terraform - Step-by-Step Execution

Process Flow - State locking with DynamoDB

Terraform Init

↓

Check DynamoDB Lock Table

↓

Try to Acquire Lock

↓

Release Lock

↓

Complete

Terraform uses a DynamoDB table to lock the state file during operations. It tries to acquire a lock before applying changes, waits if locked, then releases the lock after completion.

Execution Sample

Terraform

terraform {
  backend "s3" {
    bucket = "my-terraform-state"
    key    = "state.tfstate"
    region = "us-east-1"
    dynamodb_table = "terraform-lock"
  }
}

This Terraform backend configuration enables state locking using a DynamoDB table named 'terraform-lock'.

Process Table

Step	Action	DynamoDB Lock Table State	Lock Acquired?	Terraform Behavior
1	Terraform Init starts	Empty (no lock)	No	Attempts to acquire lock
2	Acquire lock request sent	Empty (no lock)	Yes	Lock acquired, proceed
3	Terraform applies changes	Lock held by current operation	Yes	Apply changes to infrastructure
4	Terraform finishes apply	Lock held by current operation	Yes	Releases lock
5	Lock released	Empty (no lock)	No	Operation complete
6	Another Terraform run starts	Empty (no lock)	No	Attempts to acquire lock
7	Acquire lock request sent	Lock held by another operation	No	Waits and retries until lock free

💡 Terraform stops waiting when the lock is released and it successfully acquires the lock.

Status Tracker

Variable	Start	After Step 2	After Step 3	After Step 4	After Step 5	After Step 7
Lock Status	Unlocked	Locked by current run	Locked by current run	Locked by current run	Unlocked	Locked by another run

Key Moments - 3 Insights

Why does Terraform wait before applying changes sometimes?

Terraform waits because the DynamoDB lock table shows the state is locked by another operation (see execution_table row 7). It retries until the lock is released.

What happens if Terraform does not release the lock?

If Terraform does not release the lock (see execution_table row 4), other runs will be blocked indefinitely, causing delays and potential errors.

How does Terraform know the lock is free?

Terraform checks the DynamoDB lock table state (execution_table column 'DynamoDB Lock Table State'). When it is empty, Terraform can acquire the lock and proceed.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Terraform first acquire the lock?

A Step 3

B Step 1

C Step 2

D Step 5

💡 Hint

Check the 'Lock Acquired?' column in execution_table row 2.

According to variable_tracker, what is the lock status after Step 5?

A Locked by current run

B Unlocked

C Locked by another run

D Unknown

💡 Hint

Look at the 'Lock Status' variable value after Step 5 in variable_tracker.

If the lock is held by another operation, what does Terraform do according to the execution_table?

A Waits and retries to acquire the lock

B Proceeds with apply anyway

C Fails immediately

D Deletes the existing lock

💡 Hint

See the 'Terraform Behavior' column at Step 7 in execution_table.

Concept Snapshot

Terraform state locking with DynamoDB:
- Uses a DynamoDB table to lock state during operations
- Acquires lock before applying changes
- Waits if lock is held by another run
- Releases lock after apply completes
- Prevents concurrent state modifications

Full Transcript

Terraform uses a DynamoDB table to lock the state file during infrastructure changes. When Terraform starts, it tries to acquire a lock by writing to the DynamoDB table. If the lock is free, Terraform proceeds to apply changes. If the lock is held by another operation, Terraform waits and retries until the lock is released. After finishing, Terraform releases the lock so others can proceed. This prevents multiple Terraform runs from changing the state at the same time, avoiding conflicts and corruption.

Practice

1. What is the main purpose of using a DynamoDB table in Terraform state management?

easy

A. To lock the Terraform state and prevent concurrent changes

B. To store Terraform configuration files

C. To host Terraform modules

D. To run Terraform commands remotely

Solution

1. Step 1: Understand Terraform state locking

   Terraform uses state locking to avoid multiple users changing infrastructure at the same time, which can cause conflicts.

2. Step 2: Role of DynamoDB in locking

   DynamoDB acts as a lock store to keep the Terraform state safe by preventing concurrent modifications.

3. Final Answer:

   To lock the Terraform state and prevent concurrent changes -> Option A

4. Quick Check:

   State locking = prevent concurrent changes [OK]

Hint: DynamoDB locks state to avoid conflicts [OK]

Common Mistakes:

• Thinking DynamoDB stores config files
• Confusing locking with module hosting
• Assuming DynamoDB runs Terraform commands

2. Which Terraform backend configuration snippet correctly enables state locking with DynamoDB?

easy

A. backend "s3" { bucket = "mybucket" key = "state.tfstate" region = "us-east-1" }

B. backend "local" { path = "./terraform.tfstate" dynamodb_table = "terraform-lock" }

C. backend "s3" { bucket = "mybucket" key = "state.tfstate" region = "us-east-1" dynamodb_table = "terraform-lock" }

D. backend "gcs" { bucket = "mybucket" dynamodb_table = "terraform-lock" }

Solution

1. Step 1: Identify backend type supporting DynamoDB locking

   Only the S3 backend supports DynamoDB for state locking in Terraform.

2. Step 2: Check for required parameters

   The S3 backend requires bucket, key, region, and dynamodb_table to enable locking.

3. Final Answer:

   backend "s3" with bucket, key, region, and dynamodb_table -> Option C

4. Quick Check:

   S3 backend + dynamodb_table = locking enabled [OK]

Hint: Use S3 backend with dynamodb_table for locking [OK]

Common Mistakes:

• Adding dynamodb_table to unsupported backends
• Missing key or region in S3 backend
• Using local backend with DynamoDB

3. Given this backend configuration, what happens if two users run terraform apply at the same time?

backend "s3" {
  bucket         = "mybucket"
  key            = "prod/terraform.tfstate"
  region         = "us-west-2"
  dynamodb_table = "tf-locks"
}

medium

A. Both users can apply changes simultaneously without issues

B. Terraform will lock the state in DynamoDB, allowing only one user to apply at a time

C. Terraform will throw an error because DynamoDB is not supported

D. The state file will be overwritten causing conflicts

Solution

1. Step 1: Understand DynamoDB locking behavior

   DynamoDB table is used to lock the state file so only one user can modify it at a time.

2. Step 2: Effect on concurrent applies

   If two users run apply simultaneously, one will get the lock and the other will wait or fail until the lock is released.

3. Final Answer:

   Terraform locks state in DynamoDB, allowing one user at a time -> Option B

4. Quick Check:

   DynamoDB lock = single user apply [OK]

Hint: DynamoDB locks state to serialize applies [OK]

Common Mistakes:

• Assuming simultaneous applies succeed
• Thinking DynamoDB is unsupported
• Believing state file overwrites happen

4. You configured your Terraform backend with DynamoDB locking but receive this error: Error locking state: ConditionalCheckFailedException. What is the most likely cause?

medium

A. Terraform version is too old to support DynamoDB locking

B. The S3 bucket name is misspelled

C. The backend block is missing the region parameter

D. The DynamoDB table does not exist or has incorrect permissions

Solution

1. Step 1: Understand the error meaning

   ConditionalCheckFailedException usually means DynamoDB cannot perform the lock operation, often due to missing table or permission issues.

2. Step 2: Check backend configuration and AWS resources

   If the DynamoDB table does not exist or Terraform lacks permission to access it, locking fails with this error.

3. Final Answer:

   DynamoDB table missing or permission issues -> Option D

4. Quick Check:

   ConditionalCheckFailedException = DynamoDB table or permissions [OK]

Hint: Check DynamoDB table existence and permissions first [OK]

Common Mistakes:

• Blaming S3 bucket name for DynamoDB error
• Ignoring Terraform version compatibility
• Overlooking missing region parameter

5. You want to ensure your Terraform state locking is highly available and prevents accidental unlocks. Which combination of DynamoDB table settings is best practice?

hard

A. Enable point-in-time recovery and use a strong primary key with consistent read

B. Use a simple primary key and disable point-in-time recovery to reduce costs

C. Use eventual consistency and no encryption for faster locking

D. Create multiple DynamoDB tables for locking in different regions

Solution

1. Step 1: Identify high availability features

   Point-in-time recovery protects against accidental deletes or corruption of the lock table.

2. Step 2: Understand locking consistency needs

   Using a strong primary key and consistent reads ensures reliable lock state and prevents race conditions.

3. Step 3: Evaluate other options

   Disabling recovery or using eventual consistency risks losing lock data or causing conflicts; multiple tables add complexity without benefit.

4. Final Answer:

   Enable point-in-time recovery and use strong primary key with consistent read -> Option A

5. Quick Check:

   Recovery + strong key + consistency = best locking [OK]

Hint: Enable recovery and strong keys for safe locking [OK]

Common Mistakes:

• Disabling recovery to save money
• Using eventual consistency causing conflicts
• Creating multiple tables unnecessarily