TF-004 Understand Terraform basics Practice Question
A platform team manages a large Terraform codebase with hundreds of resources across multiple environments (dev, staging, prod). They use terraform workspaces to manage environment-specific state files. Recently, an engineer made changes to the production workspace but forgot to switch from the dev workspace before applying. The apply was successful, but now the production resources are in an inconsistent state. The team wants to recover the production state to match the actual infrastructure. The previous state file for production was backed up in an S3 bucket before the accidental apply. What is the best course of action?
⚠ Common exam trap
A common trap in Terraform exams is the misconception that `terraform apply` can accept a state file as an argument, when in fact `terraform apply` always uses the workspace's current state, and state manipulation requires dedicated commands like `state push` or `state pull`.
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
✓
Use terraform state push with the backup state file to overwrite the current state
`terraform state push` directly overwrites the current state file in the workspace with a provided state file. Since the team has a backup of the production state file taken before the accidental apply, pushing that backup restores the state to exactly match the actual infrastructure, assuming no other changes occurred. This is the fastest and most reliable method to recover from an incorrect state overwrite, as it bypasses any reconciliation logic and replaces the state wholesale.
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 mv to correct the state entries by mapping resources from the backup to the current state
Why it's wrong here
terraform state mv only re-addresses existing entries within one state file; it cannot restore a superseded state. The backup must be pushed back with terraform state push, then reconciled via refresh. State mv is tempting when renaming or moving resources between addresses, not for rolling back an accidental apply.
- ✗
Use terraform import to manually import each production resource based on the backup state
Why it's wrong here
Import writes existing resources into state but cannot restore the prior attribute values or resource addresses recorded in the backup, so hundreds of resources would be re-imported with drift. Import is correct when adopting unmanaged infrastructure into Terraform for the first time.
- ✗
Use terraform workspace select prod then terraform apply with the backup state file
Why it's wrong here
terraform apply does not accept a state file argument; state location is configured through the backend, so this command cannot restore the backup. It is tempting because selecting the prod workspace seems to target production state, but the mechanism for restoring a backup is pushing it to the backend, not passing it to apply.
- ✓
Use terraform state push with the backup state file to overwrite the current state
Why this is correct
terraform state push overwrites the current state file with the supplied backup, restoring production's recorded resource mappings to match reality. Because the accidental apply occurred in the dev workspace, the production state was corrupted; pushing the S3 backup realigns state with actual infrastructure before further operations.
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 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.