TF-004 Understand Terraform basics Practice Question
Exhibit
$ terraform init Initializing the backend... Successfully configured the backend "s3"! Terraform will automatically use this backend unless the backend configuration changes. Error refreshing state: state data in S3 does not have the expected content. This may be due to a bug. If you are sure the state file is valid, run: terraform force-unlock <lock_id>
Refer to the exhibit. A user runs terraform init and receives an error about state data content. The state file in S3 has not been manually modified. What is the most 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
✓
The state file was written by a different Terraform workspace.
The error indicates that the state file content does not match what Terraform expects. This can happen when the state file has a different serial number (e.g., if another process wrote to it) or if the state file is corrupted. However, since the user hasn't manually modified it, the most likely cause is that the state file was modified by a different Terraform process (perhaps from another workspace or different version) that changed the state structure. Option D is correct because a conflicting workspace can write state with a different serial, causing the 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 policy denies access to the state file.
Why it's wrong here
An S3 bucket policy denying access would typically manifest as an `AccessDenied` error from the AWS API, preventing Terraform from even reading or writing the state file. This error indicates a permissions issue at the storage layer, not an inconsistency within the state file's content itself. Terraform would fail to establish a connection or retrieve the object, rather than finding its internal structure or serial number incorrect.
- ✗
Terraform version mismatch between local and state file.
Why it's wrong here
A Terraform version mismatch between the local CLI and the state file typically results in an error explicitly stating an 'Unsupported state file version' or similar incompatibility. This error occurs when the state file's internal format or schema is not compatible with the Terraform CLI version attempting to read it. It's a structural format issue, distinct from a logical content mismatch like an unexpected serial number.
- ✗
The state file is locked by another process.
Why it's wrong here
If the state file were locked by another process, Terraform would report an error indicating it 'Failed to acquire state lock' or 'Error acquiring the state lock'. This mechanism prevents concurrent operations from corrupting the state file during writes. Such an error signifies an inability to gain exclusive access, not an issue with the state file's content or its serial number.
- ✓
The state file was written by a different Terraform workspace.
Why this is correct
When a state file is written by a different Terraform workspace, the serial number or other internal metadata within the state file may not align with what the currently selected local workspace expects. Terraform uses serial numbers to track the evolution of the state and ensure consistency, preventing operations on an outdated or incorrect view of the infrastructure. A mismatch indicates that the remote state's serial number is different from the one Terraform expects for the current workspace, often due to switching workspaces without proper `terraform workspace select` or external manipulation.
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
One of 428 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. 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.