TF-004 Use the core Terraform workflow Practice Question
An organization uses Terraform workspaces to manage multiple environments (dev, staging, prod). They notice that terraform plan in the prod workspace unexpectedly shows changes to a resource that should be identical across workspaces. The resource uses a backend that stores state in an S3 bucket. What is the most likely cause?
⚠ Common exam trap
A common misconception in Terraform is that workspace differences are solely due to state management issues (like copying state or versioning) rather than configuration logic. The trap here is assuming that identical resource definitions across workspaces are automatically enforced without checking for workspace-aware variables like 'terraform.workspace' in the configuration.
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 terraform.workspace variable is used in the resource configuration.
If the `terraform.workspace` variable is used directly in a resource configuration (e.g., in a name, tag, or identifier), the resource definition will differ between workspaces. Since the prod workspace has a different workspace name than dev, the plan will show changes to resources that are otherwise identical, as Terraform detects the difference in the interpolated value.
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 prod workspace was created by copying the dev workspace state.
Why it's wrong here
Copying state from one workspace to another, such as from `dev` to `prod`, would merely initialize the `prod` workspace's state file to reflect the resources managed by `dev` at that specific moment. However, `terraform plan` evaluates the *current configuration* against the *current state* to determine necessary changes. If the underlying Terraform configuration files are identical for both workspaces, the plan would also be identical, assuming no external changes have occurred. The act of copying state itself does not introduce a mechanism for future plan differences; rather, it defines the starting point of managed resources.
- ✗
The S3 bucket does not support versioning.
Why it's wrong here
S3 bucket versioning is a critical feature designed to preserve multiple versions of an object, including Terraform state files, enabling recovery from accidental deletions or corruption. While essential for state file integrity and disaster recovery, the presence or absence of versioning on the S3 backend bucket has no direct impact on the differences observed between `terraform plan` outputs for distinct workspaces. The `plan` command only considers the *latest* state file version to determine the current infrastructure, not its historical versions or the versioning capability of the backend.
- ✓
The terraform.workspace variable is used in the resource configuration.
Why this is correct
The `terraform.workspace` variable provides the name of the currently selected workspace, allowing for dynamic configuration based on the execution context. By incorporating this variable into resource arguments, such as `name = "my-resource-${terraform.workspace}"` or conditional logic using `count` or `for_each`, the same configuration can provision distinct resources or resource attributes across different workspaces. This direct manipulation of resource definitions based on the workspace name is the most common and intended mechanism for generating varying `terraform plan` outputs from a single set of configuration files.
- ✗
The provider version differs between workspaces.
Why it's wrong here
Terraform workspaces operate on a single, shared set of configuration files. Provider versions are typically declared within the `terraform` block or `provider` blocks in these configuration files, meaning all workspaces utilizing that configuration will inherently use the same provider version. While different provider versions *could* theoretically lead to varying plan outputs due to changes in resource schemas or behavior, this scenario would only occur if the underlying configuration files themselves were different or if the provider block was dynamically configured per workspace, which is not standard practice for workspace usage.
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 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.