HashiCorp Terraform Associate (004) Question 138
Single answer5a Explain how Terraform sources modulesA platform team maintains a reusable VPC module in a Git repository. The networking team wants application teams to consume a specific tagged release of that module directly from Git, while another local module in the same configuration should continue to be loaded from the filesystem during development. The current configuration is failing because Terraform cannot determine the correct module source behavior. Which configuration correctly sources the reusable module from Git at a tagged release while allowing the local module to be sourced from a relative path?
- A
module "vpc" { source = "git::https://example.com/network-modules.git//vpc?ref=v1.2.0" } module "app" { source = "./modules/app" }
- B
module "vpc" { source = "https://example.com/network-modules.git/vpc@v1.2.0" } module "app" { source = "local://modules/app" }
- C
module "vpc" { source = "registry::https://example.com/network-modules.git//vpc?version=v1.2.0" } module "app" { source = "./modules/app" }
- D
module "vpc" { source = "git://example.com/network-modules.git?tag=v1.2.0//vpc" } module "app" { source = "/modules/app" }
Show answer and explanation
Correct answer: A
Explanation
Terraform can source modules from several locations, including local paths, the Terraform Registry, VCS repositories such as Git, and other package locations. For Git-based module sources, Terraform expects the git:: prefix, an optional subdirectory separated by //, and an optional ?ref= query string to pin a branch, tag, or commit. For example: git::https://example.com/repo.git//module-path?ref=v1.2.0. Local modules are typically sourced with relative paths such as ./modules/app or ../shared/module. A key exam concept is distinguishing source address formats: registry modules use registry-style addresses and version arguments, while Git modules use source strings with git:: and ref. This aligns with HashiCorp documentation for module sources and module syntax best practices, especially pinning reusable remote modules to explicit versions or refs for reproducibility.
- A. Correct.
Correct. Terraform supports Git module sources using the git:: prefix, and subdirectories inside the repository are specified with // followed by the path, such as //vpc. To select a specific Git branch, tag, or commit, Terraform uses the ref query parameter, for example ?ref=v1.2.0. A local module can be sourced from a relative filesystem path like ./modules/app. This matches Terraform's documented module source syntax and is a common real-world pattern for pinning reusable modules to a tested release.
- B. Incorrect.
Incorrect. This option mixes unsupported syntax for Git and local sources. Terraform does not use @v1.2.0 in that location to pin a Git module version, and local modules are not referenced with a local:// scheme. A relative path such as ./modules/app is the normal way to source a local module. Someone might choose this because package managers often use @version notation, but Terraform Git module sources use ?ref= instead.
- C. Incorrect.
Incorrect. The registry:: prefix is not used to turn a Git URL into a registry source, and Git sources do not use the version argument in the source string. Registry modules and Git modules are handled differently in Terraform. For Git, the correct mechanism is git:: plus ?ref=. This distractor reflects a common confusion between Terraform Registry versioning and Git refs.
- D. Incorrect.
Incorrect. This source string puts the subdirectory and tag information in the wrong order and uses tag= instead of Terraform's supported ref= query parameter for Git sources. In addition, /modules/app is an absolute path from the filesystem root, not a relative path to a local module in the current configuration. While absolute paths can technically point to a local directory, they do not satisfy the stated requirement to continue sourcing the module from a relative path during development.