What if you could stop copying code by hand and just tell Terraform where to get it automatically?
Why Module sources (local, registry, git) in Terraform? - Purpose & Use Cases
Imagine you need to build many parts of your cloud setup by copying and pasting code from different places every time.
You keep files scattered on your computer, download code from websites, or clone repositories manually for each project.
This manual way is slow and confusing.
You might forget to update code, make mistakes copying, or lose track of which version you used.
It becomes hard to share your work with teammates or reuse code safely.
Using module sources lets you tell Terraform exactly where to find reusable code pieces.
You can point to local folders, official registries, or git repositories.
This makes your setup clean, consistent, and easy to update.
copy code from random files and paste everywhere
module "example" { source = "git::https://github.com/user/repo.git" }
You can build cloud infrastructure faster and safer by reusing trusted code from anywhere.
A team shares a module from a git repo to create virtual machines with the same settings, avoiding repeated work and errors.
Manual copying is slow and error-prone.
Module sources let you reuse code from local paths, registries, or git repos.
This improves speed, consistency, and teamwork.
Practice
source argument specify in a Terraform module block?Solution
Step 1: Understand the role of
Thesourcein a modulesourceargument tells Terraform where to get the module code from, such as a local folder, registry, or Git repo.Step 2: Identify what
It does not specify Terraform version, cloud provider, or outputs; those are separate configurations.sourcedoes not specifyFinal Answer:
The location where Terraform finds the module code -> Option AQuick Check:
Modulesource= module location [OK]
- Confusing source with Terraform version
- Thinking source defines outputs
- Assuming source sets cloud provider
modules/network?Solution
Step 1: Identify local module source syntax
Local modules use a relative or absolute path as thesource. Here, "modules/network" is a relative path.Step 2: Check other options for correctness
module "net" { source = "registry/modules/network" } uses registry syntax incorrectly; module "net" { source = "git::https://example.com/network.git" } is for Git sources; module "net" { source = "network" } lacks the folder path.Final Answer:
module "net" { source = "modules/network" } -> Option AQuick Check:
Local module source = folder path [OK]
- Using registry or git syntax for local modules
- Omitting folder path in source
- Confusing source with module name
module "web" {
source = "git::https://github.com/example/terraform-web.git"
version = "v1.0.0"
}What will Terraform do when you run
terraform init?Solution
Step 1: Understand Git source syntax in Terraform
Thesourcestarting with "git::" tells Terraform to clone a Git repository from the URL.Step 2: Interpret the version argument with Git sources
Theversionhere refers to a Git tag or branch to checkout, so Terraform will checkout "v1.0.0" after cloning.Final Answer:
Clone the Git repository at the given URL and checkout version v1.0.0 -> Option CQuick Check:
Git source + version = clone and checkout tag [OK]
- Thinking version is Terraform Registry version
- Assuming source is local folder
- Believing version is unsupported for Git
module "db" {
source = "git::https://github.com/example/terraform-db.git"
version = "1.0.0"
}When running
terraform init, you get an error. What is the likely cause?Solution
Step 1: Check Git tag naming conventions
Git tags often start with 'v' (e.g., 'v1.0.0'). If the tag is named with 'v', specifying '1.0.0' causes a mismatch.Step 2: Verify other options for errors
Git URLs are valid sources; local path is not required; module name 'db' is valid.Final Answer:
The version should be prefixed with 'v' like 'v1.0.0' to match Git tags -> Option BQuick Check:
Git version tag must match exact Git tag name [OK]
- Omitting 'v' prefix in version for Git tags
- Thinking Git URLs are invalid module sources
- Assuming module names have strict rules
hashicorp/aws with version 4.0.0. Which is the correct module block to use?Solution
Step 1: Identify Terraform Registry module source syntax
Modules from the Terraform Registry use the format "namespace/module" as the source, e.g., "hashicorp/aws".Step 2: Check other options for correctness
module "aws_module" { source = "git::https://github.com/hashicorp/aws.git" version = "4.0.0" } uses Git URL which is incorrect for Registry modules; module "aws_module" { source = "./hashicorp/aws" version = "4.0.0" } uses local path; module "aws_module" { source = "registry/hashicorp/aws" version = "4.0.0" } uses invalid prefix "registry/".Final Answer:
module "aws_module" { source = "hashicorp/aws" version = "4.0.0" } -> Option DQuick Check:
Registry modules use "namespace/module" source format [OK]
- Using Git URL for Registry modules
- Adding extra prefixes like 'registry/'
- Using local paths for Registry modules
Ready to prove it?
Pass the test and this pattern moves unknown
