Implement and maintain state →mediumMultiple ChoiceObjective-mapped

TF-004 Implement and maintain state Practice Question

Exhibit

terraform {
  backend "s3" {
    bucket = "my-company-terraform-state"
    key    = "prod/terraform.tfstate"
    region = "us-east-1"
    encrypt = true
  }
}

Refer to the exhibit. A developer runs `terraform apply` but receives an error that the state file is locked. Which of the following is a likely cause?

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

✓

Another user has an active plan or apply running

A state lock error indicates that the state file is currently locked by another process. This commonly occurs when another user or an automated process is running a terraform plan or apply that holds the lock. Options such as a missing DynamoDB table, nonexistent S3 bucket, lack of s3:ListBucket permission, or incorrect encryption key would result in different error messages related to backend configuration or permissions, not a lock 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 DynamoDB table for locking is not configured
Why it's wrong here
When using an S3 backend with state locking, Terraform is configured to use a DynamoDB table for distributed state locking. If this DynamoDB table were entirely missing or incorrectly specified in the backend configuration, Terraform would typically fail during the `terraform init` phase, or report a backend configuration error, rather than specifically encountering a state lock error during `apply`. A state lock error implies the locking mechanism *exists* but is currently engaged, preventing concurrent state modifications.
✗
The S3 bucket does not exist
Why it's wrong here
If the configured S3 bucket for storing Terraform state did not exist, `terraform init` would fail because it couldn't configure the backend, or `terraform apply` would fail with an error indicating the bucket could not be found or accessed. This type of error would prevent Terraform from even attempting to read or write state, and thus would not manifest as a state lock error. A state lock error presumes the backend is accessible but the state is currently locked by another operation.
✗
The IAM user lacks s3:ListBucket permission
Why it's wrong here
Lacking the `s3:ListBucket` permission would prevent Terraform from listing objects within the S3 bucket, which might be necessary for certain backend operations or state file discovery. However, a permission error would typically result in an explicit "Access Denied" message from AWS, indicating insufficient privileges, rather than a state lock error. A state lock error specifically indicates that the state file is currently locked by another operation, not that the user lacks the fundamental ability to interact with the S3 service.
✗
The encryption key is incorrect
Why it's wrong here
If an incorrect or inaccessible KMS encryption key (e.g., `kms_key_id` in the S3 backend configuration) were specified for the S3 state file, Terraform would fail to decrypt the state file during read operations or encrypt it during write operations. This would manifest as a KMS-related error, such as "AccessDeniedException" or "NotFoundException" for the key, or a decryption failure. It would not present as a state lock error, which pertains to concurrent access management.
✓
Another user has an active plan or apply running
Why this is correct
Terraform's state locking mechanism, often implemented via a DynamoDB table when using an S3 backend, is designed to prevent concurrent operations from corrupting the shared state file. When one user or automated process initiates a `terraform plan` or `terraform apply` that modifies the state, a lock is acquired. If another user or process attempts to run a state-modifying command simultaneously, Terraform will detect the active lock and report a state lock error, preventing the second operation from proceeding until the lock is released.

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 Implement and maintain state Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question