TF-004 Use Terraform outside the core workflow Practice Question
A small startup is using Terraform to deploy AWS resources. They have two separate environments: development and production. Currently, they manage two sets of Terraform configuration files in different directories, each with its own state file stored locally. The CEO wants to reduce duplication and simplify management. The team decides to restructure into a single configuration with workspaces. After implementing workspaces, they run `terraform workspace new dev` and `terraform workspace new prod`, then `terraform apply` in the dev workspace. However, when they switch to prod and run `terraform apply`, the plan shows that Terraform wants to recreate all resources instead of managing the existing production resources. What is the most likely reason for this behavior?
⚠ Common exam trap
HashiCorp often tests the misconception that workspaces automatically inherit or share state from previous configurations, when in fact each workspace starts with a completely empty state unless explicitly migrated.
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 team did not migrate the existing production state into the 'prod' workspace.
When the team restructured into a single configuration with workspaces, they created new empty workspaces (`dev` and `prod`) but did not migrate the existing production state file into the `prod` workspace. Terraform workspaces maintain separate state files, so without importing the existing production state into the `prod` workspace, Terraform has no record of the existing production resources and plans to create them from scratch. The `terraform workspace new` command creates a fresh, empty state for that workspace.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Workspaces cannot be used for different environments; only for temporary feature branches.
Why it's wrong here
This statement is incorrect. Terraform workspaces are explicitly designed to manage multiple distinct states for a single configuration, making them highly suitable for separating environments like development, staging, and production. While they can indeed be utilized for temporary feature branches, their primary and widely adopted utility extends to robust environment management, directly contradicting the claim that they cannot be used for different environments.
- ✗
The Terraform configuration uses the same resource names in both workspaces, causing conflicts.
Why it's wrong here
This statement is incorrect because Terraform workspaces maintain entirely separate and isolated state files for each environment. Consequently, resources defined with identical names in the configuration, such as `aws_instance.web`, will be tracked independently within each workspace's state, preventing any naming conflicts or collisions between resources deployed in different environments.
- ✓
The team did not migrate the existing production state into the 'prod' workspace.
Why this is correct
This is the correct explanation. When a new workspace, such as 'prod', is created, it initializes with an empty state file, meaning it has no knowledge of existing infrastructure. Any pre-existing production resources are not automatically associated with this new workspace; their state must be explicitly migrated or imported into the 'prod' workspace's state file using commands like `terraform state mv` or `terraform import` to bring them under Terraform management within that specific context.
- ✗
The team must configure a remote backend for workspaces to function correctly.
Why it's wrong here
This statement is incorrect. Terraform workspaces are fully functional even when using the default local backend, where state files are stored within the `.terraform` directory of the working directory. While configuring a remote backend is strongly recommended for collaborative environments, providing benefits like state locking, versioning, and durability, it is not a mandatory prerequisite for the fundamental operation or correct functioning of Terraform workspaces themselves.
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.