TF-004 Use Terraform outside the core workflow Practice Question
A company uses Terraform with remote state stored in an S3 bucket. An operator accidentally runs 'terraform destroy' on a production workspace and wants to recover the state before the operation. What is the best course of action?
⚠ Common exam trap
A common misconception in the Terraform exam is that 'terraform state pull' can recover a previous state, but it only fetches the current state from the backend, which after a destroy is the empty state, not a historical version.
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 the S3 bucket's versioning if enabled.
S3 bucket versioning, when enabled, automatically retains all versions of an object, including overwrites and deletions. By restoring the previous version of the state file (e.g., via the AWS console, CLI, or SDK), the operator can recover the exact state that existed before the 'terraform destroy' command was run, allowing Terraform to resume managing the infrastructure correctly.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Re-run 'terraform apply' to recreate resources.
Why it's wrong here
Re-running 'terraform apply' with a lost or corrupted state file is ineffective for recovery. Terraform relies on its state file to understand the existing infrastructure. If the state is missing or incorrect, 'terraform apply' will attempt to create resources it believes are absent, potentially leading to "resource already exists" errors if the infrastructure is still present, or even unintended modifications or destruction if the configuration differs from reality. This action does not restore the crucial mapping between configuration and real-world resources.
- ✗
Restore the state file from a DynamoDB backup.
Why it's wrong here
DynamoDB is utilized by the Terraform S3 backend exclusively for state locking, not for storing the actual state file content. Its purpose is to prevent concurrent 'terraform apply' operations from corrupting the state by ensuring only one user can modify it at a time. The state file itself resides in the S3 bucket. Therefore, attempting to restore the state file from DynamoDB is impossible as it does not contain the state data.
- ✗
Use 'terraform state pull' to retrieve the last known state.
Why it's wrong here
The 'terraform state pull' command retrieves the *current* version of the remote state file and saves it locally. If the remote state file has been accidentally deleted, corrupted, or overwritten with an empty state, 'terraform state pull' would simply download that incorrect or empty version. This command does not offer any functionality to revert to a *previous* valid state or recover from a loss, making it unhelpful in this scenario.
- ✓
Restore the state file from the S3 bucket's versioning if enabled.
Why this is correct
If S3 bucket versioning is enabled, every modification or deletion of the Terraform state file creates a new version, preserving previous states. This feature allows an administrator to easily retrieve and restore a previous, known-good version of the state file directly from the S3 bucket's version history. This is the most robust and recommended method for recovering from accidental state file deletion or corruption when using the S3 backend.
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.