HashiCorp Terraform Associate (004) Question 135
Single answer5 Terraform modulesYour team maintains a reusable Terraform module that creates an AWS VPC, subnets, and route tables. Several application teams use this module from a shared Git repository. A network engineer updates the module in the repository to add new route table logic, and your team wants to test that exact change in one non-production workspace before any other teams receive it. Which approach best allows you to pin that environment to the specific in-progress module version while keeping the configuration reproducible?
- A
Update the module block source to the Git repository with a specific ref, such as a branch, tag, or commit SHA, and run terraform init to install that version.
- B
Keep the existing module source unchanged and run terraform refresh so Terraform downloads the latest module code from the repository.
- C
Replace the module block with individual resource blocks copied from the shared module so the environment can be tested independently.
- D
Add a version argument inside the module block while continuing to use the Git source URL, because Terraform uses version for all module sources.
Show answer and explanation
Correct answer: A
Explanation
The best answer is to pin the module to a specific Git revision in the source address and rerun terraform init. In real-world teams, this allows one workspace or environment to test a change safely before broadly adopting it. Terraform supports module sources from registries, VCS repositories, local paths, and other locations, but version selection differs by source type. Registry modules can use the version argument, while Git-based modules commonly use source strings with ?ref=branch, ?ref=tag, or ?ref=commit-sha. This aligns with Terraform module sourcing documentation and the general best practice of pinning dependencies for reproducibility. It also avoids anti-patterns such as copying module internals into root configurations, which reduces maintainability and consistency across teams.
- A. Correct.
Correct. For modules sourced from Git, Terraform supports selecting a specific revision by using a source address with ref in the query string, such as a branch, tag, or commit SHA. This is the practical way to test an exact module change in one environment while keeping the configuration reproducible. After changing the source, terraform init installs that module version into the working directory.
- B. Incorrect.
Incorrect. terraform refresh updates state to match real infrastructure; it does not fetch newer module source code. Module installation and source changes are handled through terraform init. A common misconception is that refresh updates all external dependencies, but module downloads are separate from state refresh behavior.
- C. Incorrect.
Incorrect. Copying resources out of the shared module breaks reusability and creates configuration drift from the shared standard. While it may let one environment test changes, it is not the best approach for controlled, reproducible module version testing. Terraform module best practices favor reusing and pinning modules rather than duplicating their contents.
- D. Incorrect.
Incorrect. The version argument is used with modules from Terraform registries, not arbitrary Git source URLs. For Git-based modules, the revision is selected in the source address itself, typically using ?ref=. This option reflects a common confusion between registry module versioning and VCS-based module sourcing.