TF-004 Implement and maintain state Practice Question
A company uses Terraform with an S3 backend. A user accidentally deletes the state file. What is the best practice to recover the state?
⚠ Common exam trap
TF-004 often tests the misconception that local backups or 'terraform state pull' can recover a deleted remote state, when the correct answer relies on S3 versioning as the authoritative recovery mechanism.
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
✓
Restore the state file from S3 bucket versioning
When using Terraform with an S3 backend, the state file is stored in S3. If it is accidentally deleted, the best recovery method is to restore it from an S3 bucket versioning-enabled bucket, which retains previous versions of objects. This restores the exact state file, preserving resource mappings and metadata, and avoids the need to re-import or recreate resources.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use terraform state pull from the local cache
Why it's wrong here
The `terraform state pull` command retrieves the *current* state from the configured backend and saves it locally. If the state file in the S3 backend has been corrupted or accidentally deleted, `terraform state pull` will simply retrieve that corrupted or missing state. It does not provide a mechanism to revert to a previous, valid version of the state file, making it ineffective for recovery from such an incident.
- ✓
Restore the state file from S3 bucket versioning
Why this is correct
S3 bucket versioning is a robust feature that automatically retains multiple versions of an object, including `terraform.tfstate`, whenever it is modified or deleted. By enabling versioning on the S3 bucket used for the Terraform backend, administrators can easily browse previous versions of the state file and restore a specific, known-good version. This provides a direct and reliable method for recovering from accidental state file corruption or deletion.
- ✗
Use terraform import on all resources
Why it's wrong here
The `terraform import` command is designed to bring existing, unmanaged infrastructure resources under Terraform's control by mapping them to configuration blocks. It requires specifying the resource type, a local name, and the resource's cloud provider ID for each individual resource. Attempting to use `terraform import` to reconstruct a lost state file for an entire infrastructure would be an extremely time-consuming, error-prone, and impractical manual process, not a viable recovery strategy.
- ✗
Recreate the state from a terraform plan
Why it's wrong here
A `terraform plan` command generates an execution plan that describes the changes Terraform intends to make to align the infrastructure with the configuration. While it compares the configuration to the current state, the plan file itself only contains a diff and proposed actions, not a complete, comprehensive representation of the infrastructure's current state. Therefore, it is impossible to reconstruct a full and accurate `terraform.tfstate` file solely from a `terraform plan` output or saved plan file.
- ✗
Restore from the local terraform.tfstate.backup
Why it's wrong here
When Terraform successfully applies changes, it creates a `terraform.tfstate.backup` file *locally* on the machine where the `apply` command was executed, preserving the state *before* the latest changes. However, this local backup is specific to that machine and that particular operation. If the S3 backend state was corrupted by an external action, a different user, or a subsequent operation from another environment, this local backup would likely be outdated, irrelevant, or simply not present where needed for recovery.
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
This TF-004 question is part of Courseiva's 434-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official HashiCorp exam blueprint
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.