Passing Data Between Terraform Modules
An engineer is refactoring a monolithic Terraform configuration into reusable modules. One module outputs a list of subnet IDs. Another module needs to use these subnet IDs to create resources. What is the best way to pass this data between modules?
Quick Answer
The answer is to output the subnet IDs from the first module and reference that output as an input variable in the second module's block. This is correct because Terraform enforces explicit data flow between modules through input and output variables, creating a clear, dependency-aware graph that Terraform uses for parallel execution and change tracking. On the HashiCorp Terraform Associate TF-003 exam, this concept tests your understanding of module composition and the principle that modules should never access another module's resources directly—only through declared interfaces. A common trap is attempting to use data sources or hard-coded values to bridge modules, which breaks dependency tracking and can cause race conditions. Remember the golden rule: outputs are the only way out, inputs are the only way in. For a quick memory tip, think of modules as black boxes with labeled plugs (inputs) and sockets (outputs)—you must always plug an output socket into an input plug to pass data between them.
⚠ Common exam trap
HashiCorp often tests the misconception that remote state data sources are the only way to pass data between modules, when in fact direct output-to-variable passing is the simplest and most maintainable approach within a single Terraform 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
✓
Output the subnet IDs from the first module and reference that output as an input variable in the second module's block.
Terraform modules communicate through explicit input and output variables. By outputting the subnet IDs from the first module and then referencing that output as an input variable in the second module's block, you create a clear, versionable, and dependency-aware data flow. This approach avoids hidden dependencies and ensures Terraform can properly graph the resource dependencies for parallel execution.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a Terraform data source in the second module to query the subnets directly.
Why it's wrong here
This couples the second module to the cloud provider and may not reflect the exact subnets created.
- ✗
Define the subnet IDs as a variable in the first module and pass them to the second module via a remote state data source.
Why it's wrong here
Defining subnet IDs as a variable in the first module is incorrect; they are outputs generated by that module. Passing data via a remote state data source is for accessing outputs from a *separate* Terraform configuration's state file, not for inter-module communication within the same configuration. This approach would introduce an unnecessary dependency on a prior `terraform apply` of the first module's configuration. However, using remote state is appropriate when different, independently deployed root modules need to share data, such as a networking configuration providing details to a compute configuration.
- ✗
Store the subnet IDs in a local file and use the 'file' function to read them in the second module.
Why it's wrong here
This is fragile and not idiomatic; modules should use explicit inputs and outputs.
- ✓
Output the subnet IDs from the first module and reference that output as an input variable in the second module's block.
Why this is correct
This is the correct pattern: module outputs are consumed as module input variables.
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 →
Same concept, more angles
1 more way this is tested on TF-004
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. You have two modules that create resources in different providers. Module A creates a VPC in AWS, Module B creates a Kubernetes cluster that requires the VPC ID. You want to ensure Module B runs after Module A but avoid hardcoding the VPC ID. Which approach is most appropriate?
hard- A.Use a data source in Module B to look up the VPC.
- ✓ B.Output the VPC ID from Module A and pass it as input to Module B.
- C.Use terraform graph to order modules.
- D.Use module dependency via depends_on in the root module.
Why B: It establishes an explicit data dependency between modules without hardcoding values. By outputting the VPC ID from Module A and passing it as an input variable to Module B, Terraform's dependency graph automatically ensures Module A is created before Module B, and the VPC ID is dynamically available at plan time.
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.