Module sources (local, registry, git) in Terraform - Step-by-Step Execution

Process Flow - Module sources (local, registry, git)

Start Terraform config

↓

Identify module source type

↓

Local

↓

Load from local path

↓

Use module in config

↓

Terraform plan/apply

Terraform reads the module source type (local path, registry, or git), loads the module accordingly, then uses it in the configuration.

Execution Sample

Terraform

module "example" {
  source = "./modules/example"
}

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  version = "3.0.0"
}

module "app" {
  source = "git::https://github.com/org/repo.git"
}

This config uses three modules: one local, one from the registry, and one from a git repository.

Process Table

Step	Module Name	Source Type	Action	Result
1	example	local	Read source './modules/example'	Load module files from local path
2	example	local	Check version '1.0'	Version info noted (local modules usually no version enforcement)
3	vpc	registry	Download 'terraform-aws-modules/vpc/aws' version '3.0.0'	Module downloaded from Terraform Registry
4	vpc	registry	Verify version '3.0.0'	Version confirmed and module ready
5	app	git	Clone repo 'https://github.com/org/repo.git'	Module cloned from git repository
6	app	git	Use default branch or ref	Module ready for use
7	all	all	Modules loaded	Terraform plan/apply can proceed
8	-	-	End of module source loading	All modules ready for configuration use

💡 All module sources loaded successfully, ready for Terraform plan and apply

Status Tracker

Variable	Start	After Step 1	After Step 3	After Step 5	Final
module.example.source	undefined	./modules/example	./modules/example	./modules/example	./modules/example
module.vpc.source	undefined	undefined	terraform-aws-modules/vpc/aws	terraform-aws-modules/vpc/aws	terraform-aws-modules/vpc/aws
module.app.source	undefined	undefined	undefined	git::https://github.com/org/repo.git	git::https://github.com/org/repo.git

Key Moments - 3 Insights

Why does the local module not enforce version like registry modules?

Local modules are loaded directly from your file system, so Terraform does not manage versions for them. See execution_table rows 1 and 2 where version is noted but not enforced.

How does Terraform know which branch or commit to use for a git module?

If no specific ref is given, Terraform uses the default branch of the git repo. This is shown in execution_table row 6.

What happens if a module source is invalid or unreachable?

Terraform will fail during the module loading step, stopping before plan/apply. This is not shown here because all sources load successfully.

Visual Quiz - 3 Questions

Look at the execution table, what source type is used for the 'vpc' module at step 3?

A registry

B local

C git

D unknown

💡 Hint

Check the 'Source Type' column at step 3 in the execution_table.

At which step does Terraform clone the git repository for the 'app' module?

A Step 2

B Step 4

C Step 5

D Step 7

💡 Hint

Look for the action mentioning 'Clone repo' in the execution_table.

If the local module path changes, which variable in variable_tracker would update?

A module.vpc.source

B module.example.source

C module.app.source

D None

💡 Hint

Local module source is tracked under 'module.example.source' in variable_tracker.

Concept Snapshot

Terraform modules can come from three main sources:
- Local path: direct folder on your computer
- Registry: official Terraform module repository with versioning
- Git: remote git repository URL
Terraform loads modules based on source type before planning.
Local modules do not enforce versions; registry modules do.
Git modules clone the repo and use default or specified refs.

Full Transcript

This visual execution shows how Terraform handles module sources from local paths, the Terraform Registry, and git repositories. It starts by reading the module source type, then loads the module accordingly. Local modules load directly from the file system without strict version enforcement. Registry modules are downloaded with version checks. Git modules are cloned from remote repositories using the default branch or specified references. After all modules are loaded, Terraform proceeds to plan and apply. Variables track the source values for each module as they update through the steps. Key beginner questions about versioning and git refs are answered by referencing the execution steps. The quiz tests understanding of source types, steps of cloning, and variable tracking. The snapshot summarizes the core concepts for quick recall.

Practice

1. What does the source argument specify in a Terraform module block?

easy

A. The location where Terraform finds the module code

B. The version of Terraform to use

C. The cloud provider for the module

D. The output variables of the module

Solution

1. Step 1: Understand the role of source in a module

   The source argument tells Terraform where to get the module code from, such as a local folder, registry, or Git repo.

2. Step 2: Identify what source does not specify

   It does not specify Terraform version, cloud provider, or outputs; those are separate configurations.

3. Final Answer:

   The location where Terraform finds the module code -> Option A

4. Quick Check:

   Module source = module location [OK]

Hint: Remember: source means 'where to get the module' [OK]

Common Mistakes:

• Confusing source with Terraform version
• Thinking source defines outputs
• Assuming source sets cloud provider

2. Which of the following is the correct syntax to use a local module located in a folder named modules/network?

easy

A. module "net" { source = "modules/network" }

B. module "net" { source = "registry/modules/network" }

C. module "net" { source = "git::https://example.com/network.git" }

D. module "net" { source = "network" }

Solution

1. Step 1: Identify local module source syntax

   Local modules use a relative or absolute path as the source. Here, "modules/network" is a relative path.

2. 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.

3. Final Answer:

   module "net" { source = "modules/network" } -> Option A

4. Quick Check:

   Local module source = folder path [OK]

Hint: Local modules use folder paths as source [OK]

Common Mistakes:

• Using registry or git syntax for local modules
• Omitting folder path in source
• Confusing source with module name

3. Given this module block:

module "web" {
  source = "git::https://github.com/example/terraform-web.git"
  version = "v1.0.0"
}

What will Terraform do when you run terraform init?

medium

A. Download the module from the local folder named terraform-web

B. Download the module from the Terraform Registry

C. Clone the Git repository at the given URL and checkout version v1.0.0

D. Fail because version is not supported for Git sources

Solution

1. Step 1: Understand Git source syntax in Terraform

   The source starting with "git::" tells Terraform to clone a Git repository from the URL.

2. Step 2: Interpret the version argument with Git sources

   The version here refers to a Git tag or branch to checkout, so Terraform will checkout "v1.0.0" after cloning.

3. Final Answer:

   Clone the Git repository at the given URL and checkout version v1.0.0 -> Option C

4. Quick Check:

   Git source + version = clone and checkout tag [OK]

Hint: Git source means clone repo; version is Git tag/branch [OK]

Common Mistakes:

• Thinking version is Terraform Registry version
• Assuming source is local folder
• Believing version is unsupported for Git

4. You wrote this module block:

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?

medium

A. The module name 'db' is invalid

B. The version should be prefixed with 'v' like 'v1.0.0' to match Git tags

C. The source URL must be a local path for modules

D. Git URLs cannot be used as module sources

Solution

1. 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.

2. Step 2: Verify other options for errors

   Git URLs are valid sources; local path is not required; module name 'db' is valid.

3. Final Answer:

   The version should be prefixed with 'v' like 'v1.0.0' to match Git tags -> Option B

4. Quick Check:

   Git version tag must match exact Git tag name [OK]

Hint: Match version exactly to Git tag name (often starts with 'v') [OK]

Common Mistakes:

• Omitting 'v' prefix in version for Git tags
• Thinking Git URLs are invalid module sources
• Assuming module names have strict rules

5. You want to reuse a module from the Terraform Registry named hashicorp/aws with version 4.0.0. Which is the correct module block to use?

hard

A. module "aws_module" {
source = "git::https://github.com/hashicorp/aws.git"
version = "4.0.0"
}

B. module "aws_module" {
source = "registry/hashicorp/aws"
version = "4.0.0"
}

C. module "aws_module" {
source = "./hashicorp/aws"
version = "4.0.0"
}

D. module "aws_module" {
source = "hashicorp/aws"
version = "4.0.0"
}

Solution

1. 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".

2. 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/".

3. Final Answer:

   module "aws_module" { source = "hashicorp/aws" version = "4.0.0" } -> Option D

4. Quick Check:

   Registry modules use "namespace/module" source format [OK]

Hint: Registry modules use "namespace/module" as source [OK]

Common Mistakes:

• Using Git URL for Registry modules
• Adding extra prefixes like 'registry/'
• Using local paths for Registry modules