Understand IaC concepts →mediumMultiple ChoiceObjective-mapped

TF-004 Understand IaC concepts Practice Question

Exhibit

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

Refer to the exhibit. A team is using this S3 backend configuration. During a deployment, they receive an error that the state file is locked. What is the most likely cause?

⚠ Common exam trap

HashiCorp often tests the distinction between S3 access errors and DynamoDB lock errors, so candidates mistakenly attribute the lock error to S3 bucket issues (like missing bucket or wrong region) rather than recognizing it as a DynamoDB-specific failure.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

The DynamoDB table is not provisioned or the IAM role lacks permissions

The error message 'state file is locked' directly indicates that Terraform is attempting to acquire a lock on the state using DynamoDB, but the lock table either does not exist or the IAM role used by Terraform lacks the required permissions (dynamodb:PutItem, dynamodb:GetItem, dynamodb:DeleteItem, dynamodb:DescribeTable). Without a properly provisioned DynamoDB table or sufficient IAM permissions, the locking mechanism fails, producing this specific error.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
The S3 bucket does not exist
Why it's wrong here
If the S3 bucket specified in the backend configuration does not exist, Terraform would typically return an error indicating that the bucket cannot be found or accessed, preventing state operations entirely. This is a fundamental storage issue, distinct from a state locking failure, which specifically occurs when Terraform attempts to acquire or release a lock on an existing state file. The initial backend initialization would fail due to the missing storage location.
✗
The region is incorrect
Why it's wrong here
Specifying an incorrect AWS region in the S3 backend configuration means Terraform would attempt to connect to a non-existent or incorrect endpoint for the S3 bucket and DynamoDB table. This would result in authentication or connection errors, such as "InvalidRegion" or "NoSuchBucket" if the bucket exists in a different region, rather than a specific state lock acquisition failure, as the underlying services would be unreachable. The communication channel itself would be misconfigured.
✓
The DynamoDB table is not provisioned or the IAM role lacks permissions
Why this is correct
Terraform's S3 backend leverages an Amazon DynamoDB table for robust state locking to prevent concurrent state modifications. If the specified DynamoDB table does not exist, or if the IAM role used by Terraform lacks the necessary `dynamodb:PutItem`, `dynamodb:GetItem`, and `dynamodb:DeleteItem` permissions, Terraform will be unable to acquire or release the state lock. This directly manifests as a "Failed to get lock" or "Error acquiring the state lock" message, as the mechanism designed to prevent race conditions is non-functional.
✗
The key path is incorrect
Why it's wrong here
An incorrect `key` path in the S3 backend configuration means Terraform would attempt to store or retrieve the state file from a non-existent object path within the specified S3 bucket. While this would prevent Terraform from finding or updating the correct state, it would typically result in a "state file not found" or "object does not exist" error. The state locking mechanism, which operates on the *attempt* to modify a state, would still function if the DynamoDB table is correctly configured and accessible, even if the state file itself is missing or at the wrong path.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

TF-004 Understand IaC concepts Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question