TF-004 Interact with Terraform modules Practice Question
Which four of the following statements about interacting with Terraform modules are correct? (Choose four.)
⚠ Common exam trap
HashiCorp often tests the distinction between `source` and `version` attributes in module blocks, and the misconception that modules cannot override provider configurations, which leads candidates to incorrectly select the two wrong options.
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
✓
A module can reference outputs from another module using the syntax module.<MODULE_NAME>.<OUTPUT_NAME>.
This statement is correct because Terraform modules expose outputs that can be referenced by the calling configuration using the syntax `module.<MODULE_NAME>.<OUTPUT_NAME>`. This allows values computed inside a module to be used elsewhere in the root module, enabling modular composition and data sharing between modules.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
A module can reference outputs from another module using the syntax module.<MODULE_NAME>.<OUTPUT_NAME>.
Why this is correct
This statement is correct. Terraform allows a calling configuration to access output values exposed by child modules, which is fundamental for data flow between infrastructure components. The `module.<MODULE_NAME>.<OUTPUT_NAME>` syntax is the standard and required method for referencing these outputs, enabling the composition of complex infrastructure from smaller, reusable building blocks.
- ✓
The source attribute in a module block can reference a local file path, a Git repository, the Terraform Registry, or an HTTP URL.
Why this is correct
This statement is correct. The `source` attribute is a crucial component of a module block, specifying the location from which Terraform should retrieve the module's code. It supports diverse origins, including local file paths (relative or absolute), Git repository URLs (e.g., GitHub, GitLab), official Terraform Registry paths (e.g., `hashicorp/aws/vpc`), and direct HTTP URLs to module archives, offering significant flexibility in module distribution.
- ✓
Terraform automatically downloads module dependencies when running terraform init, including nested modules from the root module.
Why this is correct
This statement is correct. The `terraform init` command is essential for preparing a working directory for Terraform operations, and a key part of this process is downloading module dependencies. It recursively discovers all modules referenced in the configuration, including those nested within other modules, and fetches them into the `.terraform` directory, ensuring all necessary code is available before planning or applying changes.
- ✓
Module inputs are defined as variables in the module's root directory, and outputs are defined as output values that can be consumed by the calling configuration.
Why this is correct
This statement is correct. Modules are designed with clear interfaces: inputs are defined as variables (typically in `variables.tf`) within the module's root directory, allowing the calling configuration to pass parameters. Conversely, modules expose specific data points or resource attributes as output values (defined in `outputs.tf`), which can then be consumed by parent modules or the root configuration, facilitating controlled data exchange.
- ✗
To use a module from a private registry, you must always specify a version constraint in the source attribute of the module block.
Why it's wrong here
This statement is incorrect. While specifying a version constraint in the `source` attribute is highly recommended for reproducibility and stability, especially with private registries, it is not strictly mandatory. Terraform will default to fetching the latest available version if no version constraint is provided, although this practice is generally discouraged for production environments due to potential for unexpected breaking changes.
- ✗
A module can be used to create resources only in the same provider configuration as the root module; it cannot define its own provider configurations.
Why it's wrong here
This statement is incorrect. Modules are highly flexible and can indeed define their own provider configurations, including different aliases or entirely separate provider blocks from the root module. This capability allows a module to interact with multiple instances of a provider (e.g., different AWS regions) or even different providers than those configured in the calling module, significantly enhancing its reusability and isolation.
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.