HashiCorp Terraform Associate (004) Question 133
Single answer5 Terraform modulesA platform team maintains a reusable Terraform module that provisions an AWS VPC. Several application teams consume the module from a shared Git repository. The platform team needs to add new tagging behavior to the module, but they want to avoid unexpectedly changing infrastructure for application teams during their next terraform init or apply. Which approach is the best way to let teams adopt the updated module in a controlled and predictable manner?
- A
In each consuming configuration, pin the module source to a specific Git tag or commit, and have application teams update that version intentionally after reviewing the module change.
- B
Rely on terraform init to automatically detect module changes in the shared Git repository and safely apply only non-breaking updates without version pinning.
- C
Use terraform fmt in the module repository before releasing changes, because formatting the module prevents downstream infrastructure drift for consumers.
- D
Add the new tagging logic directly to the root modules of all application teams instead of changing the shared module, because Terraform modules should not be versioned.
Show answer and explanation
Correct answer: A
Explanation
The safest and most predictable way to roll out changes to a reusable Terraform module is to version and pin the module source in consuming configurations. Common patterns include using a Git source with ref set to a release tag or specific commit, or using a module registry with semantic versions. This gives each application team control over when to adopt a new module version and lets them review the resulting plan before applying. HashiCorp documentation and Terraform best practices emphasize reusable modules, version constraints, and controlled upgrades for module dependencies. In contrast, relying on unpinned module sources can cause unintended changes when teams reinitialize or upgrade dependencies. Formatting tools like terraform fmt help code quality but do not provide release control or compatibility guarantees.
- A. Correct.
Correct. For shared modules, a best practice is to reference a specific version of the module source, such as a Git tag, branch with caution, or ideally an immutable commit SHA or release tag. This allows consumers to control when they adopt changes rather than implicitly pulling the latest code from the repository. In real environments, version pinning reduces the risk of unexpected plan changes and supports predictable upgrades, testing, and rollback.
- B. Incorrect.
Incorrect. Terraform does not provide a safety mechanism that automatically classifies repository changes as non-breaking for modules. If a module source is not pinned to a stable version, consumers may pull newer code during initialization or upgrade workflows and encounter unexpected plan or apply results. This option reflects a common misconception that Terraform manages module compatibility automatically.
- C. Incorrect.
Incorrect. terraform fmt only standardizes configuration formatting. It improves readability and consistency, but it does not affect module versioning, dependency management, or infrastructure drift behavior. Teams may still see changes from updated module code regardless of whether the code is properly formatted.
- D. Incorrect.
Incorrect. Shared modules are specifically intended to encapsulate reusable infrastructure logic, and versioning them is a standard best practice. Copying new logic into every root module creates duplication, increases maintenance overhead, and makes consistent upgrades harder. The statement that Terraform modules should not be versioned is false.