HashiCorp Terraform Associate (004) Question 148
Single answer5c Use modules in configurationA platform team created a reusable Terraform module in a separate Git repository to provision an AWS VPC. Application teams must use version 2.4.0 of that module so their infrastructure remains stable across environments. One team adds the following block to its root module:
module "network" { source = "git::https://example.com/network-modules.git//aws-vpc?ref=v2.4.0" cidr_block = "10.20.0.0/16" }
Later, the module authors release v2.5.0, but the application team wants to continue using v2.4.0 until they complete validation testing. Which action should the application team take to ensure Terraform continues using the intended module version?
- A
Keep the ref=v2.4.0 value in the module source and run terraform init; Terraform will continue to use that pinned Git tag unless the source reference is changed.
- B
Add version = "2.4.0" inside the module block; Terraform will enforce that version for any module source, including Git URLs.
- C
Run terraform get -update=false before every plan; this prevents Terraform from reading newer versions from the Git repository even if the source ref changes.
- D
Move the module code into the same repository as the root module; only local modules can be reliably pinned to an exact version.
Show answer and explanation
Correct answer: A
Explanation
This question tests practical module usage in Terraform configurations. For Terraform Associate 004, candidates should know that module installation behavior depends on the module source type. When using a VCS source such as Git, Terraform does not use a version argument inside the module block. Instead, you pin a specific tag, branch, or commit with the ref query parameter in the source address, for example git::https://example.com/repo.git//path?ref=v2.4.0. By contrast, the version argument is for registry modules only. HashiCorp documentation on module sources and module blocks distinguishes these behaviors clearly. In real-world teams, pinning reusable modules to immutable tags or commit SHAs is a best practice for predictable builds and controlled upgrades.
- A. Correct.
Correct. For modules sourced from a Git repository, Terraform uses the source address to determine what to install. Including ?ref=v2.4.0 pins the module to that Git tag, branch, or commit. As long as the source string remains the same, Terraform will continue to select that referenced revision when you run terraform init. This is the standard way to pin versions for VCS-based modules.
- B. Incorrect.
Incorrect. The version argument is supported only for modules installed from a module registry, such as the public Terraform Registry or a private registry that implements the registry protocol. It does not apply to Git, local path, or generic archive sources. A common misconception is assuming version works like provider version constraints for all module sources.
- C. Incorrect.
Incorrect. This does not solve the version-pinning requirement. More importantly, relying on command behavior instead of the module source definition is not the recommended way to control module versions. If the source ref were changed to v2.5.0, Terraform would install that new reference on initialization. Version intent should be declared in configuration, not managed operationally with a repeated CLI habit.
- D. Incorrect.
Incorrect. Local modules can be referenced by path, but Terraform does not provide a built-in versioning mechanism for local module directories. Moving the module into the same repository may simplify development, but it does not create a better version-pinning model than using a Git source with an explicit ref. In practice, Git tags or commits are a common and reliable way to pin reusable modules.