HashiCorp Terraform Associate (004) Question 146
Single answer5c Use modules in configurationYour team maintains a reusable Terraform module named network in a private Git repository. A root configuration uses this module to create VPCs for dev and prod. After a teammate updates the module to change default subnet behavior, a new terraform init -upgrade in the root configuration begins planning unexpected changes in prod, even though the root module code was not edited. You want to reduce this risk while continuing to use the shared module from Git. Which action is the best way to make module usage more predictable across environments?
- A
Pin the module
sourceto a specific Git ref such as a tag or commit SHA, and update that ref intentionally when you want to adopt module changes. - B
Run
terraform refreshbefore every plan so Terraform reloads the module's previous behavior from the state file. - C
Add
version = "~> 1.0"to the Git-based module block so Terraform can enforce semantic versioning for that repository. - D
Move the module code into the root configuration directory so Terraform stops treating it as a module and no longer updates it.
Show answer and explanation
Correct answer: A
Explanation
This scenario tests practical module consumption in Terraform. When using child modules, especially shared modules across environments, you should make module versions explicit to avoid drift caused by unplanned upstream changes. For Terraform Registry modules, use the version argument. For Git-based modules, pin the module in the source address using a specific tag, branch, or preferably a commit SHA or release tag via ?ref=. Running terraform init -upgrade can cause Terraform to retrieve newer module code if your source points to a moving target such as a default branch. HashiCorp documentation for module sources and module versioning guidance emphasizes using fixed versions for predictable runs and safer collaboration.
- A. Correct.
Correct. For modules sourced from Git, the reliable way to control what code is used is to pin the
sourceto a specific ref, such as?ref=v1.2.0or a commit SHA. That makes module selection deterministic across environments and prevents unexpected behavior when someone updates the repository's default branch. Teams can then deliberately change the ref when they are ready to consume a tested module version. - B. Incorrect.
Incorrect.
terraform refreshupdates state with real infrastructure information; it does not restore or lock module source code. Module code is downloaded duringterraform init, and state does not preserve the previous implementation details of a module in a way that would prevent new code from being used. - C. Incorrect.
Incorrect. The
versionargument is used with modules from the Terraform Registry, not with arbitrary Git sources. A common misconception is that all module sources support theversionmeta-argument, but Git-based modules must be constrained through thesourceURL itself, typically with arefquery parameter. - D. Incorrect.
Incorrect. Copying module code into the root configuration removes reusability and does not address the core versioning problem in a maintainable way. It also defeats the purpose of shared modules across environments and teams. Best practice is to keep the module reusable and control the exact module revision being consumed.