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
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.