Courseiva
Understand IaC conceptsmediumMultiple ChoiceObjective-mapped

TF-004 Understand IaC concepts Practice Question

A company has a Terraform module that creates an AWS VPC with subnets. They want to reuse this module across multiple AWS accounts. What is the best practice for referencing the module from different root configurations?

⚠ Common exam trap

Candidates may think that using a remote source like S3 or Git is just as good as the HashiCorp Terraform Registry. However, the registry provides built-in version resolution, centralized management, and is the recommended best practice for sharing modules across multiple root configurations and accounts.

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 module registry and specify a version constraint.

Using a module registry with a version constraint is the best practice for reusing Terraform modules across multiple AWS accounts. It provides a centralized, version-controlled source that can be referenced by any root configuration via a simple source address (e.g., `registry.terraform.io/org/module/aws`), ensuring consistency and enabling safe upgrades through semantic versioning. This approach avoids duplicating code and leverages Terraform's built-in dependency resolution and caching mechanisms.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

  • Store the module in a shared S3 bucket and reference it with the module source.

    Why it's wrong here

    While Terraform supports referencing modules stored in an S3 bucket, this method typically lacks the sophisticated version management features inherent to dedicated module registries. Directly using S3 for module sources would necessitate manual version control, perhaps through distinct S3 paths or object versions, which complicates module updates, rollbacks, and consistent consumption across multiple root configurations. It does not offer a centralized, discoverable, and version-aware interface for module consumers.

  • Use a module registry and specify a version constraint.

    Why this is correct

    A module registry, such as the public Terraform Registry or a private registry in Terraform Cloud/Enterprise, provides a centralized, discoverable, and version-controlled repository for sharing modules. Specifying a version constraint (e.g., `~> 1.0.0`) ensures that consumers utilize a compatible module version, enabling controlled updates and preventing unintended breaking changes. This approach significantly promotes reusability, consistency, and efficient collaboration across an organization's Terraform configurations.

  • Use a data source to fetch the module's output from another state.

    Why it's wrong here

    Data sources in Terraform are designed to fetch information about existing infrastructure or data from external sources, including outputs from other Terraform states using `terraform_remote_state`. They do not facilitate the *reuse* of module *code* itself to provision new resources within the current configuration. This method would only allow consuming the *results* (outputs) of a module run elsewhere, not deploying the module's defined resources in the current context.

  • Copy the module code into each root configuration's directory.

    Why it's wrong here

    Copying module code directly into each root configuration's directory creates substantial code duplication, leading to significant maintenance and update challenges. Any bug fix, security patch, or feature enhancement to the module would require manually updating every single copied instance across all configurations. This practice inevitably results in inconsistencies, increased risk of errors, and substantial operational overhead, undermining the core benefits of modularity and reusability.

Visual reference

192.168.1.0 /24 256 addresses (254 usable) 192.168.1.0 /25 Subnet A 128 addr (126 usable) 192.168.1.128 /25 Subnet B 128 addr (126 usable) Borrowing 1 bit from host portion creates 2 subnets (/25)

About these practice questions

One of 428 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 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.