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.

Terraform modules can be sourced from various locations, categorized as either local or remote sources. Understanding these sources is essential for organizing and reusing infrastructure code effectively.

**Local Module Sources**

Local modules are stored on the same filesystem where Terraform is executed. They are referenced using relative or absolute file paths. For example:

hcl
module "vpc" {
source = "./modules/vpc"
}

Local modules are ideal for development, testing, and when modules are specific to a single project. They offer fast access since no network requests are required, and changes are reflected instantly. However, sharing local modules across teams requires manual file distribution.

**Remote Module Sources**

Remote modules are hosted externally and downloaded by Terraform during initialization. Common remote sources include:

1. **Terraform Registry** - The public registry or private registries:
hcl
module "vpc" {
source = "hashicorp/vpc/aws"
version = "3.0.0"
}

2. **GitHub/Bitbucket** - Version control repositories:
hcl
module "vpc" {
source = "github.com/example/terraform-modules//vpc"
}

3. **S3 Buckets** - AWS storage:
hcl
module "vpc" {
source = "s3::https://bucket-name.s3.amazonaws.com/modules/vpc.zip"
}

4. **HTTP URLs** - Generic web locations:
hcl
module "vpc" {
source = "https://example.com/modules/vpc.zip"
}

Remote modules enable team collaboration, version control, and centralized module management. The `terraform init` command downloads remote modules to the `.terraform/modules` directory.

**Key Considerations**

- Remote modules support versioning for stability
- Local modules are best for rapid iteration
- Remote sources require network connectivity
- Both types use the same module block syntax
- Mixing local and remote modules in a single configuration is fully supported

Choosing between local and remote sources depends on your workflow, team size, and module reusability requirements.

Terraform Registry modules are pre-built, reusable infrastructure components published on the Terraform Registry (registry.terraform.io), which serves as a central repository for sharing Terraform configurations. These modules encapsulate best practices and common infrastructure patterns, allowing teams to leverage community expertise and accelerate deployment processes.

The Registry hosts two types of modules: public modules created by the community and private modules for organizations using Terraform Cloud or Terraform Enterprise. Public modules are freely available and cover popular use cases across major cloud providers like AWS, Azure, and Google Cloud Platform.

To use a Registry module, you reference it in your Terraform configuration using a source address that follows this format: <NAMESPACE>/<NAME>/<PROVIDER>. For example, hashicorp/consul/aws references the Consul module for AWS maintained by HashiCorp. You can specify version constraints to ensure consistency and prevent unexpected changes when modules are updated.

Registry modules must adhere to specific standards, including proper documentation, semantic versioning, and a standard module structure with main.tf, variables.tf, and outputs.tf files. Verified modules, indicated by a blue checkmark, have been reviewed by HashiCorp and meet additional quality requirements.

Key benefits of using Registry modules include reduced development time since you build upon existing solutions, improved consistency across infrastructure deployments, and easier maintenance through version management. Organizations can create private modules to standardize internal infrastructure patterns while maintaining security and compliance requirements.

When selecting modules, evaluate factors such as download counts, recent updates, documentation quality, and whether the module is verified. The Registry provides detailed information about module inputs, outputs, dependencies, and usage examples to help you make informed decisions.

For the Terraform Associate exam, understanding how to source modules from the Registry, specify versions, and recognize the benefits of modular infrastructure design is essential knowledge.

Git and version control systems serve as powerful module sources in Terraform, enabling teams to share, version, and manage reusable infrastructure code effectively. When referencing modules from Git repositories, Terraform supports various protocols including HTTPS, SSH, and the generic Git protocol.

To source a module from Git, you use a special URL format in your module block. For GitHub repositories, you can use the shorthand syntax: source = "github.com/organization/repository". For generic Git repositories, use: source = "git::https://example.com/repo.git".

Version control module sources offer several key advantages. First, you can pin specific versions using ref arguments, such as ?ref=v1.0.0 for tags, ?ref=branch-name for branches, or ?ref=commit-sha for specific commits. This ensures infrastructure consistency across environments and prevents unexpected changes from affecting your deployments.

SSH authentication is commonly used for private repositories. The syntax follows: source = "git::ssh://git@github.com/org/repo.git". Terraform uses your local SSH configuration and keys for authentication, making it seamless to access private modules.

You can also reference subdirectories within repositories using double-slash notation: source = "git::https://example.com/repo.git//modules/networking". This allows multiple modules to exist in a single repository while enabling selective usage.

Best practices include always specifying a version reference for production environments, using semantic versioning tags for clear version management, and documenting module dependencies. Organizations often maintain private module repositories to standardize infrastructure patterns across teams.

When Terraform initializes, it downloads modules from Git sources to the .terraform/modules directory. The terraform init command handles this process, and subsequent runs use the cached modules unless you run terraform init -upgrade to fetch newer versions matching your constraints.

Module input variables are a fundamental concept in Terraform that enable you to create flexible, reusable, and configurable infrastructure modules. They serve as the primary mechanism for passing values into a module from the calling configuration.

Input variables are declared within a module using the 'variable' block. Each variable can include several optional arguments: 'description' provides documentation about the variable's purpose, 'type' specifies the expected data type (string, number, bool, list, map, object, etc.), 'default' sets a fallback value when no value is provided, and 'validation' allows you to define custom validation rules.

Example variable declaration:

variable "instance_type" {
description = "EC2 instance type"
type = string
default = "t2.micro"
}

When calling a module, you pass values to these input variables using arguments within the module block:

module "web_server" {
source = "./modules/ec2"
instance_type = "t3.medium"
}

Input variables promote the DRY (Don't Repeat Yourself) principle by allowing you to write generic modules that can be customized for different environments or use cases. For instance, a single EC2 module can deploy development, staging, and production instances by varying the input parameters.

Best practices include always providing descriptions for documentation, using appropriate type constraints to catch errors early, setting sensible defaults where applicable, and using sensitive = true for confidential values like passwords or API keys to prevent them from appearing in logs.

Variables can also be marked as required by omitting the default value, forcing users to provide a value when using the module. This ensures critical configuration parameters are explicitly defined.

Understanding module input variables is essential for the Terraform Associate exam, as they form the foundation of module composition and code reusability in Terraform configurations.

Module output values in Terraform are a crucial mechanism for exposing specific data from a child module to its parent module or root configuration. They serve as the return values of a module, allowing you to share computed values, resource attributes, or any other data that needs to be accessible outside the module scope.

When you create a module, you define output values using the 'output' block within your module's configuration files. Each output has a name and a value expression that determines what data gets exported. For example, an output might expose a resource's ID, IP address, or any computed attribute.

The syntax for defining an output value is straightforward:

output "instance_id" {
description = "The ID of the EC2 instance"
value = aws_instance.example.id
sensitive = false
}

Key attributes of output blocks include:
- 'value': Required attribute specifying the data to export
- 'description': Optional documentation explaining the output's purpose
- 'sensitive': Boolean flag to mark sensitive data, preventing it from being displayed in CLI output

To access module outputs from a parent configuration, you use the syntax: module.<MODULE_NAME>.<OUTPUT_NAME>. For instance, if you have a module named 'vpc', you would reference its 'vpc_id' output as module.vpc.vpc_id.

Outputs enable module composition by allowing modules to pass data between each other. This creates a clean interface where modules can remain encapsulated while still sharing necessary information. Root modules can also use outputs to display important values after terraform apply completes.

Best practices include providing meaningful descriptions for all outputs, marking sensitive outputs appropriately, and only exposing values that consumers of the module actually need. This maintains clean module interfaces and reduces unnecessary coupling between components in your Terraform configurations.

Variable encapsulation in Terraform modules is a fundamental concept that promotes clean, maintainable, and reusable infrastructure code. It refers to the practice of isolating variables within a module's scope, ensuring that internal implementation details remain hidden from external consumers while exposing only necessary inputs and outputs.

When you create a Terraform module, variables defined within that module are not accessible from the parent or calling module unless explicitly exposed. This creates a clear boundary between the module's internal workings and its public interface. The module declares input variables using the 'variable' block, which serves as the entry point for configuration values passed by the caller.

This encapsulation provides several benefits. First, it enables abstraction by hiding complex logic behind simple variable interfaces. Users of your module only need to understand what inputs are required, not how they are processed internally. Second, it promotes reusability since modules can be shared across projects with confidence that internal variables won't conflict with other configurations.

To implement variable encapsulation effectively, define input variables in a 'variables.tf' file within your module directory. These variables can include descriptions, types, default values, and validation rules. The calling module then passes values to these variables when invoking the module block.

Output values complement input variables by exposing specific attributes from the module to the parent configuration. This controlled exposure ensures that only intended data flows between module boundaries.

Best practices include using descriptive variable names, providing comprehensive descriptions, setting appropriate default values where sensible, and implementing type constraints and validation blocks to ensure data integrity. This approach creates self-documenting modules that are easier to maintain and less prone to errors when used by team members or the broader community.

The module block syntax in Terraform is a fundamental concept that allows you to organize and reuse infrastructure code effectively. A module block is used to call and instantiate a child module from your root module or another parent module.

The basic syntax of a module block consists of the following structure:

module "module_name" {
source = "path/to/module"

# Input variables
variable1 = value1
variable2 = value2
}

Key components of the module block syntax include:

1. **Module Keyword**: Every module block starts with the 'module' keyword, indicating you are referencing external or local module code.

2. **Module Name**: The label following the module keyword (in quotes) serves as a unique identifier within your configuration. This name is used to reference the module's outputs elsewhere in your code.

3. **Source Argument**: The source argument is mandatory and specifies where Terraform should find the module code. Sources can be local paths, Terraform Registry, GitHub, S3 buckets, or other supported locations.

4. **Input Variables**: After the source, you pass values to the module's input variables. These arguments correspond to variables defined within the called module using variable blocks.

5. **Optional Meta-Arguments**: Module blocks support several meta-arguments including 'version' (for registry modules), 'providers' (to pass provider configurations), 'count' and 'for_each' (to create multiple instances), and 'depends_on' (to establish explicit dependencies).

Example with meta-arguments:

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

count = var.create_vpc ? 1 : 0

cidr = "10.0.0.0/16"
name = "my-vpc"
}

To access module outputs, use the syntax: module.module_name.output_name

Understanding module block syntax enables you to build modular, maintainable, and scalable Terraform configurations while promoting code reuse across your infrastructure projects.

Passing values to modules in Terraform is a fundamental concept that enables code reusability and flexibility. When you create a module, you define input variables that act as parameters, allowing the module to be customized for different use cases.

To pass values to a module, you use the module block in your root configuration. Within this block, you specify arguments that correspond to the input variables defined in the module. These arguments can be literal values, references to resources, data sources, local values, or outputs from other modules.

Here is a basic example:

module "vpc" {
source = "./modules/vpc"
vpc_cidr = "10.0.0.0/16"
environment = var.environment
tags = local.common_tags
}

In this example, three values are passed to the vpc module: a hardcoded CIDR block, a variable reference, and a local value reference.

Modules can have required and optional input variables. Required variables must be provided when calling the module, while optional variables have default values defined in the module's variables.tf file. If you do not supply a value for an optional variable, Terraform uses the default.

You can also pass complex data types such as lists, maps, and objects to modules. This allows for sophisticated configurations:

module "subnets" {
source = "./modules/subnets"
subnet_config = {
public = ["10.0.1.0/24", "10.0.2.0/24"]
private = ["10.0.3.0/24", "10.0.4.0/24"]
}
}

Best practices include using descriptive variable names, providing descriptions for each input variable, and validating inputs using validation blocks. This approach ensures modules are self-documenting and helps prevent configuration errors.

Understanding how to effectively pass values to modules is essential for building maintainable, scalable Terraform configurations and is a key topic for the Terraform Associate certification exam.

Module outputs in Terraform are essential for sharing data between modules and the root configuration. When you create a module, you can define outputs that expose specific values from resources created within that module, making them accessible to the calling configuration.

To access module outputs, you use the syntax: module.<MODULE_NAME>.<OUTPUT_NAME>

First, you need to define outputs in your child module. In the module's outputs.tf file, you declare output blocks:

output "instance_id" {
description = "The ID of the EC2 instance"
value = aws_instance.example.id
}

output "public_ip" {
description = "The public IP address"
value = aws_instance.example.public_ip
}

Once the module is called in your root configuration, you can reference these outputs elsewhere. For example:

module "web_server" {
source = "./modules/ec2"
instance_type = "t2.micro"
}

resource "aws_eip" "example" {
instance = module.web_server.instance_id
}

output "server_ip" {
value = module.web_server.public_ip
}

Key points about module outputs:

1. Outputs must be explicitly defined - only values declared as outputs are accessible outside the module.

2. You can use module outputs as inputs to other modules, creating dependencies between modules.

3. The 'sensitive' argument can mark outputs containing confidential data, preventing them from displaying in logs.

4. Output values are computed after terraform apply completes for that module.

5. You can use the 'depends_on' meta-argument in output blocks when implicit dependencies are insufficient.

6. Module outputs can be complex types including lists, maps, and objects.

Accessing module outputs enables modular architecture where components communicate through well-defined interfaces, promoting reusability and maintainability in your Terraform configurations.

Module version constraints in Terraform are essential mechanisms that allow you to specify which versions of a module your configuration can use. This ensures consistency, stability, and predictable infrastructure deployments across different environments.

When sourcing modules from a registry like the Terraform Registry or a private registry, you can define version constraints using the 'version' argument within the module block. This prevents unexpected breaking changes when module authors release updates.

The version constraint syntax supports several operators:

1. **Exact version (=)**: Specifies a precise version, e.g., version = "=1.2.0"

2. **Greater than or equal (>=)**: Allows the specified version and any newer versions, e.g., version = ">=1.0.0"

3. **Less than or equal (<=)**: Restricts to the specified version and older, e.g., version = "<=2.0.0"

4. **Pessimistic constraint (~>)**: The most commonly used operator, allowing only the rightmost version component to increment. For example, ~>1.2.0 permits 1.2.1, 1.2.9, but not 1.3.0. Similarly, ~>1.2 allows 1.3, 1.9, but not 2.0.

5. **Range combinations**: You can combine constraints, e.g., version = ">=1.0.0, <2.0.0"

Example module block with version constraint:

module "vpc" {
source = "hashicorp/vpc/aws"
version = "~>3.0"
}

Best practices include:
- Always specify version constraints for production environments
- Use pessimistic constraints to receive bug fixes while avoiding breaking changes
- Document version requirements in your codebase
- Regularly review and update version constraints during maintenance windows

Version constraints only apply to modules from registries. Local modules and modules from Git repositories use different versioning approaches, such as Git tags or branches. Understanding version constraints helps maintain infrastructure stability while allowing controlled updates to your Terraform modules.

Version pinning in Terraform modules is a critical best practice that ensures infrastructure stability and reproducibility. When referencing modules, specifying exact versions prevents unexpected changes from breaking your infrastructure.

**Why Version Pinning Matters:**
Modules evolve over time with new features, bug fixes, and potentially breaking changes. Using unpinned versions means your infrastructure could behave differently each time you run terraform init, leading to inconsistent deployments.

**Best Practices:**

1. **Always Pin Module Versions:** Use the version argument when calling modules from registries. Example: version = "2.1.0" rather than leaving it unspecified.

2. **Use Semantic Versioning Constraints:** Terraform supports various version constraint operators:
- Exact version: "= 2.1.0"
- Greater than or equal: ">= 2.1.0"
- Pessimistic constraint: "~> 2.1" (allows 2.1.x but not 2.2.0)

3. **Pessimistic Constraints Are Recommended:** The ~> operator is ideal for production as it allows patch updates while preventing major or minor version changes that might introduce breaking modifications.

4. **Lock Files:** Terraform generates .terraform.lock.hcl files that record the exact versions used. Commit this file to version control to ensure team consistency.

5. **Review Before Updating:** Before changing version constraints, review the module changelog to understand what changes are included.

6. **Test Updates in Non-Production:** When updating module versions, validate changes in development or staging environments first.

7. **Document Version Requirements:** Maintain documentation explaining why specific versions are pinned, especially when avoiding known issues.

8. **Regular Updates:** Schedule periodic reviews of module versions to incorporate security patches and improvements while maintaining stability.

For private modules using Git sources, pin using tags or commit SHAs rather than branch names. This ensures deterministic builds and prevents unexpected changes from affecting your infrastructure deployments.