TF-004 Read, generate and modify configuration Practice Question
A company manages a large Terraform configuration with an S3 backend and DynamoDB locking. After initial setup, they modify the backend block in the main.tf to change the S3 bucket name. Running 'terraform plan' yields: 'Backend reinitialization required. Please run "terraform init".' They run 'terraform init' but it prompts to migrate state from the old bucket to the new one. The old bucket is empty (no state files) because the configuration has never been applied. The team wants to avoid unnecessary state migration. Which step should they take?
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
✓
Run 'terraform init -reconfigure' to skip state migration.
The correct action is to use 'terraform init -reconfigure', which allows reinitialization without migration by ignoring the existing backend configuration and starting fresh. Option B (deleting .terraform) would also work but is less efficient and may lose cached modules. Option C is unnecessary because there is no state to manage. Option D would force migration, which the team wants to avoid.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Run 'terraform init -reconfigure' to skip state migration.
Why this is correct
This option is correct because the `-reconfigure` flag instructs Terraform to disregard any existing backend configuration and reinitialize the backend from scratch. When a backend has been changed to an empty S3 bucket, using `-reconfigure` prevents Terraform from attempting an unnecessary state migration from a non-existent or empty previous state, effectively resetting the backend configuration to the new, empty S3 bucket without errors. This is the most efficient and intended method for such a scenario.
- ✗
Delete the .terraform directory and run 'terraform init' again.
Why it's wrong here
Deleting the `.terraform` directory forces Terraform to reinitialize everything, including provider plugins and the backend configuration. While this action would ultimately resolve the issue by clearing any cached backend information and allowing `terraform init` to configure the new, empty S3 bucket, it is an overly drastic measure. It requires re-downloading all provider plugins, which is less efficient and not the targeted solution provided by the `-reconfigure` flag for backend changes.
- ✗
Change the backend configuration back to the original bucket and run 'terraform state rm' to clear resources.
Why it's wrong here
This approach is incorrect because the problem statement implies the *new* S3 bucket is empty, not necessarily the original one. Even if the original bucket were empty, attempting to run `terraform state rm` would be futile as there would be no resources tracked in the state to remove. Furthermore, changing the backend configuration back to an original bucket only to then clear state is a convoluted and unnecessary step when the goal is to establish a new, empty state in the *current* backend configuration.
- ✗
Run 'terraform init -migrate-state' and accept the migration.
Why it's wrong here
The `-migrate-state` flag explicitly instructs Terraform to attempt migrating the state from the previously configured backend to the newly specified one. Since the new S3 bucket is described as empty, there is no existing state to migrate *to* from a previous location, and attempting this would likely result in errors or an unnecessary operation. This flag is intended for scenarios where you are moving an *existing* state to a new backend location, not for initializing a new, empty 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
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.