TF-004 Understand Terraform's purpose Practice Question
A team uses Terraform to manage infrastructure in AWS. They have a single workspace and store state in an S3 bucket with DynamoDB locking. After a recent apply, the state file became corrupted due to a network interruption during the state write. The team needs to recover the state and prevent future corruption. They have not enabled any backup or versioning. What should they do?
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
✓
Delete the state file and run terraform import for all resources.
Since versioning was not enabled before the corruption, no previous state versions exist in S3. Enabling it now (Option A) does not recover the corrupted state. `terraform state pull` retrieves the *current* state, not a previous version, making Option A ineffective. Manually editing the S3 state (C) is risky and discouraged. `force-unlock` (B) only releases the lock without fixing corruption. Deleting the corrupted state and running `terraform import` for all resources (D) is the only reliable way to recover when no backup is available, though it requires knowing all resource IDs. After recovery, enable S3 versioning and DynamoDB point-in-time recovery to prevent future incidents.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Enable S3 bucket versioning and DynamoDB point-in-time recovery, then use terraform state pull to retrieve a previous state version.
Why it's wrong here
While S3 bucket versioning and DynamoDB point-in-time recovery are crucial best practices for protecting the state file and its associated lock table from accidental deletion or data loss, `terraform state pull` only retrieves the *current* state from the backend. It does not provide a mechanism to revert to or restore a *previous version* of a corrupted state file. To utilize S3 versioning for recovery, one would typically need to manually download a specific historical version and then use `terraform state push` to overwrite the corrupted remote state.
- ✗
Use terraform force-unlock to release the lock and reapply the configuration.
Why it's wrong here
Using `terraform force-unlock` is designed solely to release a stale state lock that prevents new operations, not to repair a corrupted state file. Releasing a lock only addresses the concurrency mechanism, not the integrity of the state data itself. Attempting to reapply a configuration against a fundamentally corrupted state file is highly dangerous, as Terraform's understanding of the infrastructure would be flawed, potentially leading to unintended resource modifications, deletions, or further inconsistencies.
- ✗
Manually edit the state file in S3 to fix the corruption.
Why it's wrong here
Manually editing a Terraform state file, especially directly within a remote backend like S3, is an extremely risky and error-prone operation that should be avoided. The state file is a precise, machine-generated JSON document, and even minor syntax errors, incorrect resource IDs, or misaligned attributes can render it unusable or cause Terraform to misinterpret the infrastructure, leading to severe drift, resource destruction, or an unmanageable state.
- ✓
Delete the state file and run terraform import for all resources.
Why this is correct
When a Terraform state file is irrecoverably corrupted, deleting it and then systematically importing all existing resources is often the only reliable, albeit labor-intensive, method to regain control. This process rebuilds a new, accurate state file by querying the actual infrastructure and associating it with the configuration. While it is time-consuming, requires meticulous attention to detail for every resource, and loses historical state references, it ensures Terraform's state correctly reflects the real-world resources.
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.