TF-Associate-004 - Terraform state management (11% of the exam) - Section 6b

Describe state locking.

Terraform locks state during operations that write it, so two applies cannot corrupt state concurrently; support depends on the backend. Candidates should reason about why locking matters for teams and what -lock and force-unlock do.

state lockingbackend lock supportconcurrent apply protectionforce-unlock

Practice question for this objective

Free sampleTerraform state managementmedium

Two engineers on the same team run 'terraform apply' against the same S3 backend configuration at almost the same moment. The backend is configured with a DynamoDB table for locking. What happens to the second apply?

terraform {
  backend "s3" {
    bucket         = "acme-tf-state"
    key            = "prod/network/terraform.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "acme-tf-locks"
  }
}

AThe second apply proceeds in parallel and Terraform merges the two resulting state files automatically once both finish.
BThe second apply overwrites the first run's state because S3 always keeps only the most recent upload.
CThe second apply waits silently in a queue and starts automatically the instant the first run releases the lock.
DThe second apply fails to acquire the state lock and stops, reporting that the state is already locked by the other run. Correct

State locking on a supporting backend blocks a second concurrent write, so overlapping applies cannot corrupt shared state. The S3 backend uses the configured DynamoDB table to hold a lock for the duration of a state-mutating operation, so a second apply cannot acquire the lock while the first run holds it and it stops rather than writing concurrently.

Why A is wrong: This is tempting because Terraform does track state carefully, but there is no automatic merge of concurrent writes; locking exists precisely to stop two writes overlapping.

Why B is wrong: S3 versioning and last-write-wins are real concerns, but the DynamoDB lock is what prevents this overwrite by blocking the second writer before it starts.

Why C is wrong: Terraform does retry lock acquisition briefly, but it does not queue indefinitely and start silently; if the lock is still held it reports failure rather than proceeding unattended.

Why D is correct: With a DynamoDB table configured, the S3 backend acquires a lock before writing state, so the second run cannot take the lock while the first holds it and it halts with a lock error.

See more TF-Associate-004 practice questions, answers explained.

Exam traps in Terraform state management

Answers that look right on this material and are not. Each one is a distractor from a different question in the TF-Associate-004 bank for this domain.

Locking is impossible with Terraform unless HCP Terraform is purchased, regardless of the backend chosen.
Why it is wrong: This is tempting because HCP Terraform does provide locking, but locking is also available through many self-managed remote backends, so a paid product is not the only option.
Set force_unlock = true so the second run waits for the lock held by the first run to clear.
Why it is wrong: Tempting because it mentions locking, but force_unlock is not a backend argument, and forcing an unlock removes protection rather than adding a wait.
The plan corrupts the state because reading it during an in-progress apply produces a partial write.
Why it is wrong: This is tempting given the concurrency, but 'terraform plan' does not write state, so it cannot introduce a partial write of its own.

Describe state locking.

Practice question for this objective

Exam traps in Terraform state management

More in this domain