Question 328 of 428
TF-004 Use Terraform outside the core workflow Practice Question
You are a platform engineer at a large e-commerce company that uses Terraform Enterprise to manage thousands of infrastructure resources across multiple teams. The company has a central 'networking' workspace that provisions shared VPCs and subnets, and several application workspaces that consume these networking resources via remote state data sources. Recently, the networking team changed the CIDR block of a shared subnet from '10.0.1.0/24' to '10.0.2.0/24' and applied the change successfully. However, the application teams are now reporting that their Terraform runs are failing with errors indicating that the subnet ID they reference does not exist. The application workspaces use the following configuration to consume the subnet:
```hcl data "terraform_remote_state" "networking" { backend = "remote" config = { organization = "mycompany" workspaces = { name = "networking"
} } }
resource "aws_instance" "app" { subnet_id = data.terraform_remote_state.networking.outputs.subnet_id ...
}
```
The application workspaces have not been modified recently. The networking workspace output 'subnet_id' now contains the ID of the updated subnet. What is the most likely cause of the failures?
⚠ Common exam trap
Watch out — candidates often assume the remote state data source always reads the latest state on every run, when in fact Terraform caches the data from the last plan and only refreshes it during a new plan or apply operation.
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 application workspaces are using a cached version of the remote state outputs and need to run 'terraform plan' to refresh.
Terraform caches remote state data during the planning phase, and the `terraform_remote_state` data source only fetches the latest state when `terraform plan` or `terraform apply` is executed. Since the application workspaces have not been modified or re-planned, they are using a stale cached version of the networking workspace's outputs, which still contains the old subnet ID. Running `terraform plan` forces a refresh of the remote state data, retrieving the updated `subnet_id` and resolving the error.
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 application workspaces do not have permission to read the networking workspace's state.
Why it's wrong here
Terraform's remote state data source access is governed by permissions. If an application workspace lacked the necessary permissions (e.g., `terraform cloud_state_versions:read` in Terraform Cloud), the error message would explicitly indicate an authorization failure or access denied, not a failure to find a specific resource like a subnet ID. The problem describes a scenario where the *value* of the subnet ID is incorrect or outdated, implying access was granted but the data itself was stale.
- ✗
The networking workspace output variable 'subnet_id' was removed or renamed.
Why it's wrong here
The question implies that the networking workspace *did* successfully update its subnet and its output now reflects the *new* subnet ID. If the `subnet_id` output variable had been removed or renamed, the application workspaces attempting to reference it via `data.terraform_remote_state.networking.outputs.subnet_id` would encounter an error stating that the output variable does not exist, rather than receiving an outdated value. The issue is about data freshness, not variable existence.
- ✓
The application workspaces are using a cached version of the remote state outputs and need to run 'terraform plan' to refresh.
Why this is correct
When Terraform references a remote state data source, it fetches the state data at the beginning of a `terraform plan` or `terraform apply` run and caches it for the duration of that specific operation. If the upstream networking workspace's state changes *after* the application workspace's last `plan` or `apply`, the application workspace will continue to use its locally cached, now stale, version of the `subnet_id`. A new `terraform plan` execution is required to re-fetch and update this cached remote state data.
- ✗
The application workspaces need to update the remote state data source to reference the new subnet ID.
Why it's wrong here
Terraform remote state data sources are designed to dynamically fetch the latest outputs from a specified remote state. They do not require manual updates to reference new resource IDs. The configuration `data "terraform_remote_state" "networking" {}` automatically points to the current state of the `networking` workspace. Requiring a code change would defeat the purpose of using remote state for dynamic dependency management, which is its primary benefit.
Visual reference
About these practice questions
Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →
Last reviewed: Jun 11, 2026
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.
Question Discussion
Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.
Sign in to join the discussion.