Terraform modules are reusable, self-contained packages of Terraform configurations that can be sourced from various locations. Understanding module sources is crucial for the Terraform Associate certification.
**Local Paths**
Modules can be referenced using local file paths, either relative (./mo…Terraform modules are reusable, self-contained packages of Terraform configurations that can be sourced from various locations. Understanding module sources is crucial for the Terraform Associate certification.
**Local Paths**
Modules can be referenced using local file paths, either relative (./modules/vpc) or absolute paths. This is ideal for modules within the same repository or project structure.
**Terraform Registry**
The public Terraform Registry (registry.terraform.io) hosts verified and community modules. Reference syntax follows: source = "hashicorp/consul/aws" with version constraints. Private registries are also supported for enterprise environments.
**GitHub and GitLab**
Modules can be sourced from Git repositories using HTTPS or SSH URLs. Examples include:
- source = "github.com/hashicorp/example"
- source = "git::https://example.com/module.git"
You can specify branches, tags, or commits using ref parameter.
**Bitbucket**
Similar to GitHub, Bitbucket repositories serve as module sources with appropriate URL formatting.
**HTTP URLs**
Modules can be downloaded from any HTTP/HTTPS endpoint serving archive files (.zip, .tar.gz). Terraform automatically extracts the contents.
**S3 Buckets**
AWS S3 buckets can host modules using s3:: prefix, requiring appropriate AWS credentials for access.
**GCS Buckets**
Google Cloud Storage buckets support module hosting with gcs:: prefix.
**Module Versioning**
When using registry modules, version constraints ensure consistency:
- version = "~> 2.0" (allows 2.x versions)
- version = ">= 1.0, < 2.0" (range specification)
**Best Practices**
1. Always pin module versions in production
2. Use private registries for proprietary modules
3. Implement semantic versioning for custom modules
4. Document module inputs and outputs
Understanding these source options enables flexible infrastructure code organization, promotes reusability across teams, and supports various deployment workflows from development through production environments.
Module Sources and Locations in Terraform
Why Module Sources and Locations Matter
Understanding module sources is fundamental to working with Terraform effectively. Modules allow you to reuse infrastructure code, maintain consistency across environments, and follow DRY (Don't Repeat Yourself) principles. Knowing where and how to reference modules is essential for both real-world implementations and the Terraform Associate exam.
What Are Module Sources?
A module source tells Terraform where to find the module code. When you declare a module block, the source argument is required and specifies the location from which Terraform should download or reference the module.
Types of Module Sources
1. Local Paths Local modules are referenced using relative or absolute file paths: module "vpc" { source = "./modules/vpc"} Local paths must begin with ./ or ../ to indicate a local reference.
2. Terraform Registry The public Terraform Registry is the default source for community modules: module "vpc" { source = "hashicorp/consul/aws" version = "0.1.0"} Registry modules follow the format: NAMESPACE/NAME/PROVIDER
3. GitHub Modules can be sourced from GitHub repositories: module "vpc" { source = "github.com/hashicorp/example"} You can also use HTTPS or SSH URLs with the git:: prefix.
4. Bitbucket Similar to GitHub: module "vpc" { source = "bitbucket.org/hashicorp/example"}
5. Generic Git Repository Any Git repository can be used: module "vpc" { source = "git::https://example.com/modules.git"}
6. HTTP URLs Modules can be downloaded from HTTP endpoints serving archive files: module "vpc" { source = "https://example.com/vpc-module.zip"}
8. GCS Buckets Google Cloud Storage buckets work similarly: module "vpc" { source = "gcs::https://www.googleapis.com/storage/v1/bucket/module.zip"}
How Module Downloading Works
When you run terraform init, Terraform downloads modules from their specified sources and stores them locally in the .terraform/modules directory. This initialization step must be repeated if you change module sources or versions.
Version Constraints
For registry modules, you can specify version constraints: version = "~> 1.0" - Allows any 1.x version version = ">= 1.0, < 2.0" - Range specification version = "= 1.0.0" - Exact version
Subdirectories in Sources
You can reference subdirectories within a repository using double slashes: source = "github.com/hashicorp/example//modules/vpc"
Exam Tips: Answering Questions on Module Sources and Locations
Key Points to Remember:
• Local paths MUST start with ./ or ../ - this is frequently tested
• The terraform init command downloads modules - remember this association
• Registry module format is NAMESPACE/NAME/PROVIDER - know this structure
• Version constraints only work with registry modules, not local paths or Git sources
• Downloaded modules are stored in .terraform/modules
• Double slashes (//) indicate subdirectory paths within a repository
• Private registry modules use a different format: HOSTNAME/NAMESPACE/NAME/PROVIDER
• Questions may test whether you understand when to use different source types based on scenarios
• Be familiar with the authentication requirements for private sources (SSH keys, tokens)
Common Exam Scenarios:
1. Identifying the correct source syntax for different providers 2. Understanding when terraform init must be run 3. Recognizing valid vs invalid module source formats 4. Knowing where downloaded modules are stored locally 5. Understanding version constraint syntax and behavior