Courseiva

TF-004 Interact with Terraform modules Practice Question

Which TWO statements about Terraform modules are correct?

⚠ Common exam trap

TF-004 often tests the misconception that module outputs are globally visible or that version constraints are always required — candidates over-generalize registry module rules to all source types.

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 be called multiple times in the same configuration with different input variables.

Option D is correct because Terraform allows the same module to be instantiated multiple times within a configuration, and each instance can receive distinct values for its input variables, enabling reuse of the module's logic with different parameters. Option E is correct because the module source attribute supports various source types, including Git repository URLs, and you can pin a specific commit SHA (for example, using a ref query parameter or the ?ref= syntax) to ensure the exact code revision is used. Option A is incorrect because the count meta-argument is supported on module blocks, allowing multiple instances of a module to be created. Option B is incorrect because module outputs are not automatically available as inputs to other modules; they must be explicitly referenced and passed as input variables. Option C is incorrect because version constraints are only required for certain source types such as the Terraform Registry, and are not mandatory for all module sources (e.g., local paths).

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 count meta-argument is not supported on module blocks.

    Why it's wrong here

    This statement is incorrect. Terraform 0.13 introduced support for both the `count` and `for_each` meta-arguments on module blocks, allowing practitioners to instantiate multiple copies of a module dynamically. This feature is crucial for managing collections of similar infrastructure components without duplicating module calls in the configuration. When `count` is used, the module creates `count.index` instances, each accessible via `module.module_name[index]`.

  • ✗

    Module outputs are automatically available as inputs to other modules in the same configuration.

    Why it's wrong here

    This statement is incorrect because module outputs are not automatically exposed or available globally within a Terraform configuration. To utilize an output from one module as an input for another module or resource, it must be explicitly referenced using the syntax `module.<MODULE_NAME>.<OUTPUT_NAME>`. This explicit dependency declaration ensures clarity, prevents naming collisions, and establishes a clear data flow graph within the configuration.

  • ✗

    Module sources must include a version constraint to ensure reproducibility.

    Why it's wrong here

    This statement is incorrect. While highly recommended for production environments to ensure consistent and reproducible deployments, module sources are not strictly required to include a version constraint. Terraform allows module sources without explicit versioning, defaulting to the latest available version or the main branch for Git repositories. However, omitting version constraints can lead to unexpected changes in infrastructure if the upstream module is updated, making reproducibility challenging.

  • ✓

    A module can be called multiple times in the same configuration with different input variables.

    Why this is correct

    This statement is correct. One of the primary benefits of Terraform modules is their reusability, allowing a single module definition to be invoked multiple times within the same root configuration. Each invocation can be given a unique local name and supplied with different input variables, enabling the deployment of distinct instances of similar infrastructure components. This pattern promotes DRY (Don't Repeat Yourself) principles and simplifies managing complex, multi-environment, or multi-tenant infrastructure.

  • ✓

    The source attribute of a module can be a Git repository URL with a specific commit SHA.

    Why this is correct

    This statement is correct. Terraform supports various module sources, including Git repositories. When specifying a Git repository as a module source, it is possible and often recommended to append a `?ref=<COMMIT_SHA>` query parameter to the URL. This allows Terraform to fetch the module from a precise commit hash, ensuring that the exact version of the module code is used, which is critical for reproducibility and immutability of infrastructure deployments.

About these practice questions

One of 434 original TF-004 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

JA

Written and reviewed by Johnson Ajibi, MSc IT Security

Senior Network & Security Engineer · founder of Courseiva

Last reviewed September 2026 · checked against the official HashiCorp exam blueprint

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.