Local and remote module sources

Local and Remote Module Sources in Terraform

Why This Topic Is Important

Understanding local and remote module sources is fundamental to the Terraform Associate exam. Modules are the building blocks of reusable Terraform configurations, and knowing how to source them correctly enables you to write maintainable, scalable infrastructure code. This topic typically appears in multiple exam questions and is essential for real-world Terraform usage.

What Are Module Sources?

Module sources define where Terraform should look to find the module code you want to use. When you call a module in your configuration, you must specify a source argument that tells Terraform the location of that module's files.

There are two main categories:

1. Local Module Sources
Local modules are stored on the same filesystem as your root configuration. They use relative or absolute file paths.

Example:
module "vpc" {
  source = "./modules/vpc"}

module "networking" {
  source = "../shared-modules/networking"}

Key characteristics of local modules:
- Path must start with ./ or ../
- No download step required
- Changes are reflected when you run terraform init or terraform apply
- Ideal for organization-specific modules within the same repository

2. Remote Module Sources
Remote modules are stored externally and must be downloaded before use. Terraform supports multiple remote source types:

Terraform Registry (Public and Private):
module "vpc" {
  source = "hashicorp/consul/aws"  version = "0.1.0"}

GitHub:
module "vpc" {
  source = "github.com/hashicorp/example"}

Bitbucket:
module "vpc" {
  source = "bitbucket.org/hashicorp/terraform-consul-aws"}

Generic Git:
module "vpc" {
  source = "git::https://example.com/vpc.git"}

HTTP URLs:
module "vpc" {
  source = "https://example.com/vpc-module.zip"}

S3 Bucket:
module "vpc" {
  source = "s3::https://s3-eu-west-1.amazonaws.com/bucket/vpc.zip"}

GCS Bucket:
module "vpc" {
  source = "gcs::https://www.googleapis.com/storage/v1/bucket/modules/vpc.zip"}

How Module Sources Work

When you run terraform init:

1. Terraform parses your configuration files
2. For each module block, it reads the source argument
3. Local modules are referenced from the filesystem
4. Remote modules are downloaded to the .terraform/modules directory
5. A .terraform/modules/modules.json file tracks downloaded modules

Version Constraints

Version constraints work differently based on source type:

- Terraform Registry: Supports the version argument
- Git sources: Use ref argument for branches, tags, or commits
- Local modules: Do not support versioning

Example with Git ref:
module "vpc" {
  source = "git::https://example.com/vpc.git?ref=v1.2.0"}

Subdirectories in Remote Sources

You can reference subdirectories using double slashes:
module "vpc" {
  source = "git::https://example.com/modules.git//vpc"}

The double slash separates the repository URL from the subdirectory path.

Exam Tips: Answering Questions on Local and Remote Module Sources

Tip 1: Remember the path prefixes
Local modules MUST start with ./ or ../. If you see a path that looks like modules/vpc, this would be interpreted as a Terraform Registry address, not a local path.

Tip 2: Know when terraform init is required
You must run terraform init after adding a new module or changing a module source. This downloads remote modules and updates the module cache.

Tip 3: Understand version vs ref
The version argument only works with Terraform Registry modules. For Git-based sources, use the ref query parameter in the source URL.

Tip 4: Recognize source URL patterns
- Registry: namespace/name/provider
- GitHub: github.com/org/repo
- Generic Git: git::https://...
- S3: s3::https://...

Tip 5: Downloaded module location
Remote modules are stored in .terraform/modules/ after running terraform init.

Tip 6: Double slash for subdirectories
When a question mentions accessing a specific folder within a repository, look for the // syntax in the answer options.

Tip 7: Private registry format
Private registry modules use the format: hostname/namespace/name/provider

Tip 8: Local modules and versioning
If asked about versioning local modules, remember that local modules do not support the version argument. Version control must be managed through your VCS system.