TF-004 Implement and maintain state Practice Question
An organization uses Terraform Cloud workspaces to manage multiple environments. They notice that after promoting a configuration change from development to production workspace, the production workspace's state file contains references to resources that were only created in development. What is the most likely cause?
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
✓
The user ran `terraform state mv` to move resource instances from development to production workspace.
The `terraform state mv` command can move resource instances from one workspace's state file to another, which explains why production state contains references to development resources. Option A (same backend/prefix) could cause state corruption but would not selectively move resources. Option C is unlikely and error-prone. Option D would allow reading outputs but not modify production state.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The workspaces were configured to use the same S3 backend and prefix, causing state overlap.
Why it's wrong here
Terraform Cloud workspaces inherently manage their state files in isolation, abstracting the underlying backend configuration from the user. Each workspace maintains a distinct state, preventing accidental overlap by design. Configuring a shared S3 backend and prefix is a pattern typically used for local Terraform runs or self-managed remote backends, not how Terraform Cloud natively stores or isolates state for its managed workspaces.
- ✓
The user ran `terraform state mv` to move resource instances from development to production workspace.
Why this is correct
The `terraform state mv` command is the standard and intended method for relocating resource instances within or between Terraform state files. When executed against a remote backend like Terraform Cloud, it directly modifies the state of the target workspace, effectively transferring the management of specific resources from one state to another, such as from a development to a production workspace.
- ✗
A user manually edited the production state file to include development resources.
Why it's wrong here
Manually editing a Terraform state file is extremely risky and strongly discouraged due to the complex JSON structure and sensitive data it contains. Such an action could easily introduce syntax errors, corrupt the state, or lead to inconsistencies that prevent Terraform from correctly managing resources, making it an unreliable and unsupported method for transferring resource ownership between workspaces.
- ✗
The development workspace's output values were used in production via `terraform_remote_state`.
Why it's wrong here
The `terraform_remote_state` data source is designed solely to retrieve output values from a different Terraform state. It establishes a read-only dependency, allowing one configuration to reference data from another. It does not transfer the management of resource instances or merge state files; the resources themselves remain managed by their original workspace.
Go deeper
Related to this question
About these practice questions
This TF-004 question is part of Courseiva's 428-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.