TF-004 Implement and maintain state Practice Question
An organization uses Terraform with the AzureRM backend. The team recently split a large configuration into multiple smaller configurations, each with its own state file. They want to share outputs from one configuration (networking) as inputs to another (compute). Which approach should they use to reference the networking state from the compute configuration without duplicating data?
⚠ Common exam trap
HashiCorp often tests the misconception that `terraform output` or automatic sharing between configurations is sufficient, but the correct approach is always to use the `terraform_remote_state` data source to read outputs from a separate state file.
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
✓
Use a 'data' 'terraform_remote_state' block in the compute configuration to read the networking state.
The `terraform_remote_state` data source allows one Terraform configuration to read the root-level output values from another configuration's state file stored in the AzureRM backend. This enables sharing of networking outputs (e.g., subnet IDs) into the compute configuration without duplicating data or manually exporting values. The data source retrieves the state directly from the configured backend, ensuring the compute configuration always uses the latest networking outputs.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Define output values in the networking configuration and they will be automatically available in the compute configuration.
Why it's wrong here
Terraform output values are designed to expose specific attributes of resources *within their own configuration* after `terraform apply` completes. They are not automatically propagated or discoverable by other separate Terraform configurations, even if they share the same backend. To share data between distinct configurations, an explicit mechanism like `terraform_remote_state` is required to bridge this boundary and retrieve the published outputs.
- ✗
Run 'terraform output' on the networking state and save the values to a JSON file, then use 'terraform_remote_state' to read them.
Why it's wrong here
While `terraform output` can display values from a state file, manually running it, saving to a JSON file, and then attempting to parse that file within another configuration is an unnecessary and brittle workflow. The `terraform_remote_state` data source is specifically designed to directly query and retrieve output values from a *remote state backend*, eliminating the need for manual file exports or intermediate steps. This approach ensures a dynamic and robust connection to the source state.
- ✓
Use a 'data' 'terraform_remote_state' block in the compute configuration to read the networking state.
Why this is correct
The `data "terraform_remote_state"` block is the standard and recommended method for sharing information, specifically output values, between separate Terraform configurations. By configuring this data source in the compute configuration to point to the networking configuration's remote state, it can securely and dynamically retrieve the defined output values, such as subnet IDs, for use in creating compute resources. This establishes a clear dependency and promotes modularity.
- ✗
Hardcode the subnet IDs from the networking configuration into the compute configuration.
Why it's wrong here
Hardcoding sensitive or dynamically generated values like subnet IDs directly into the compute configuration is a significant anti-pattern in infrastructure as code. This approach introduces rigidity, makes the configuration difficult to maintain, and creates a high risk of inconsistencies if the networking infrastructure changes. It bypasses Terraform's ability to manage dependencies and retrieve current state, leading to potential deployment failures and operational overhead.
Visual reference
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.