TF-004 Implement and maintain state Practice Question
An engineer has been managing a production environment with Terraform using a local state file. The team now requires that state be stored remotely in an AWS S3 bucket so multiple engineers can collaborate. The engineer adds a backend block to the existing configuration and runs `terraform init`. Terraform reports that it has detected a pre-existing local state and asks whether to copy it to the new backend. Which action should the engineer take to preserve the existing resource tracking?
⚠ Common exam trap
The trap here is assuming that refresh or a manual state push is needed to move state to a new backend, when `terraform init` performs the migration itself.
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
✓
Answer yes, allowing Terraform to migrate the local state to the S3 backend.
When a backend block is added to a configuration that previously used local state, `terraform init` detects the existing state and offers to migrate it. Accepting the prompt copies the local state data into the new remote backend, preserving resource tracking. Declining leaves the local state in place, and no other command performs this migration automatically. Manual copying or forcing a state push are unsupported or dangerous alternatives that can leave the backend uninitialized or overwrite newer data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Answer no, then run `terraform refresh` to push the local state to S3.
Why it's wrong here
`terraform refresh` only reconciles state with real infrastructure; it does not relocate state between backends. Answering no to the migration prompt leaves the configuration using the local backend, so the S3 bucket remains empty. Refresh would query existing resources but still write results to the local state file, not to S3, so collaboration would remain impossible.
- ✗
Answer no, then manually copy terraform.tfstate into the S3 bucket using the AWS CLI.
Why it's wrong here
Manually uploading the state file bypasses Terraform's backend initialization and integrity checks. Terraform would not have registered the S3 backend for the working directory, so plans would still read local state. Additionally, the raw file may not match the backend's expected key path or metadata, and concurrent access could corrupt it. The supported migration path is to let `terraform init` handle the copy.
- ✓
Answer yes, allowing Terraform to migrate the local state to the S3 backend.
Why this is correct
Answering yes instructs Terraform to copy the existing local state data into the newly configured S3 backend. This preserves the mapping between configuration resources and real infrastructure, so subsequent plans compare against the correct remote state rather than starting empty. The migration is a one-time copy during `terraform init`; after it completes, the local terraform.tfstate is no longer used for this configuration.
- ✗
Answer yes, then immediately run `terraform state push` to overwrite the S3 state with the local file.
Why it's wrong here
Answering yes already copies the local state into the S3 backend during init, so a subsequent `terraform state push` is redundant and risky. The push command forcibly overwrites remote state and is intended for recovery scenarios, not routine migration. Using it here could clobber state if another process wrote to the bucket between init and push, and it does not address any missing backend configuration.
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.