HashiCorp Terraform Associate (004) Question 136
Single answer5a Explain how Terraform sources modulesYour team maintains a reusable Terraform module for VPC networking in a separate Git repository. A project currently references the module with a local path during development, but you now need all environments in CI/CD to pull a specific immutable version of that module directly from the shared repository. Which module source configuration best meets this requirement?
- A
source = "./modules/vpc"
- B
source = "git::https://example.com/network-modules.git//vpc?ref=v1.2.0"
- C
- D
source = "registry.terraform.io/example/network-modules/vpc?version=1.2.0"
Show answer and explanation
Correct answer: B
Explanation
Terraform can source modules from local paths, Terraform registries, VCS repositories such as Git, and other package locations. In this scenario, the requirement is to pull the module directly from a shared Git repository and pin to a specific immutable release for consistent CI/CD behavior. The correct syntax is a Git source address with the git:: prefix, an optional subdirectory separated by //, and a ?ref= query to select a tag, branch, or commit. HashiCorp documentation on module sources and module blocks describes these source address formats and the use of version separately for registry modules. Best practice is to pin reusable modules to a specific tag or commit rather than relying on an unpinned branch so builds remain reproducible.
- A. Incorrect.
Incorrect. A local path source loads the module from the current filesystem, which is useful for local development but does not ensure CI/CD pulls from the shared remote repository. It also depends on the module being present in the same directory structure wherever Terraform runs.
- B. Correct.
Correct. Terraform supports sourcing modules from Git repositories using the git:: prefix. The double slash // selects the subdirectory containing the module within the repository, and the ref query parameter pins the module to a specific tag, branch, or commit. Using a tag such as v1.2.0 is a common way to reference an immutable released version in CI/CD.
- C. Incorrect.
Incorrect. This looks plausible, but it is not valid Terraform module source syntax for a Git source. Terraform does not infer Git module subdirectories and version tags from a plain HTTPS path in this format. For Git-based modules, the git:: prefix is required, and subdirectories and revisions must be specified with //subdir and ?ref=.
- D. Incorrect.
Incorrect. This mixes registry-style addressing with a Git-style version query. For Terraform Registry modules, the version is not set in the source string using ?version=. Instead, the source would typically be a registry address such as example/network-modules/vpc/aws and the version would be set in a separate version argument. Also, this scenario states the module is stored in a separate Git repository, not necessarily published to a registry.