TF-004 Understand Terraform basics Practice Question
Exhibit
terraform {
backend "s3" {
bucket = "my-terraform-state"
key = "prod/terraform.tfstate"
region = "us-east-1"
dynamodb_table = "terraform-locks"
encrypt = true
}
}
resource "aws_instance" "web" {
ami = "ami-0c55b159cbfafe1f0"
instance_type = "t2.micro"
}Refer to the exhibit. An engineer runs 'terraform plan' and receives an error: 'Error refreshing state: state data in S3 does not have the expected content.' The state file exists and is not corrupted. What is the most likely cause?
⚠ Common exam trap
Terraform often tests the distinction between state lock errors and state content mismatch errors, trapping candidates who confuse a missing DynamoDB table or a locked state with a backend configuration mismatch.
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 state file was written by a different backend configuration (e.g., different key or workspace).
The error 'state data in S3 does not have the expected content' indicates a mismatch between the state file's content and what Terraform expects based on the current backend configuration. This typically occurs when the state file was written using a different backend key, workspace, or bucket path, causing Terraform to read a state that does not match the expected serial or lineage. The state file itself is not corrupted, but the backend configuration (e.g., different `key` or `workspace_key_prefix`) points to a different state object in S3.
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 state file is locked by another process.
Why it's wrong here
A state lock prevents concurrent modifications to the Terraform state file, ensuring data integrity during operations. If a lock were active, Terraform would explicitly report an error indicating that the state is currently locked by another operation, often providing a lock ID or user information. This error is distinct from a serial mismatch, which signifies an inconsistency in the state file's versioning rather than an access restriction preventing any operation from starting.
- ✓
The state file was written by a different backend configuration (e.g., different key or workspace).
Why this is correct
Terraform state files include a "serial" attribute that increments with each successful `apply` operation, acting as a version number for the infrastructure state. When a state file is accessed or modified through a different backend configuration, such as a distinct S3 key, a separate workspace, or even a different backend type, Terraform might encounter a `serial` number that does not align with its expected sequence for the current working directory. This discrepancy triggers a "state serial mismatch" error, indicating that the current operation is attempting to interact with a state file that has an unexpected or inconsistent version history.
- ✗
The DynamoDB table does not exist.
Why it's wrong here
The DynamoDB table is crucial for implementing state locking with the S3 backend, preventing concurrent state modifications and ensuring operations are atomic. If this table does not exist, is misconfigured, or is inaccessible due to permissions, Terraform would fail to acquire a lock, resulting in an error specifically stating that the DynamoDB table could not be found or accessed. This error would directly relate to the locking mechanism's failure, not an inconsistency in the state file's version or serial number.
- ✗
The S3 bucket is in a different region.
Why it's wrong here
Terraform's S3 backend requires the configured `region` parameter to precisely match the actual AWS region where the S3 bucket resides. If there is a mismatch between the configured region and the bucket's actual location, Terraform will typically fail to establish a connection or authenticate correctly with the S3 service in the specified region. This would manifest as an access denied or region-specific error, preventing Terraform from even reading the state file, rather than successfully retrieving a state file only to find an incorrect serial within it.
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
Related to this question
About these practice questions
Courseiva writes every TF-004 question from scratch — 428 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This TF-004 practice question is part of Courseiva's free HashiCorp certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the TF-004 exam.