Terraform Registry modules - Step-by-Step Execution

Process Flow - Terraform Registry modules

Start Terraform config

↓

Declare module block

↓

Specify source from Registry

↓

Terraform init downloads module

↓

Terraform plan applies module resources

↓

Terraform apply creates infrastructure

↓

End

Terraform config declares a module from the Registry, init downloads it, then plan and apply create resources.

Execution Sample

Terraform

module "example" {
  source = "terraform-aws-modules/vpc/aws"
  version = "3.14.2"
  name = "my-vpc"
  cidr = "10.0.0.0/16"
}

This code uses a VPC module from Terraform Registry to create a VPC with a given name and CIDR.

Process Table

Step	Action	Details	Result
1	Read config	Find module block with source terraform-aws-modules/vpc/aws	Module identified
2	Run terraform init	Download module version 3.14.2 from Registry	Module code downloaded locally
3	Run terraform plan	Evaluate module inputs (name, cidr)	Plan shows VPC resource to create
4	Run terraform apply	Apply plan to cloud provider	VPC created with specified name and CIDR
5	End	Infrastructure created as per module	Success

💡 Terraform apply completes, infrastructure matches module configuration

Status Tracker

Variable	Start	After init	After plan	After apply
module_source	undefined	terraform-aws-modules/vpc/aws	terraform-aws-modules/vpc/aws	terraform-aws-modules/vpc/aws
module_version	undefined	3.14.2	3.14.2	3.14.2
module_name	undefined	my-vpc	my-vpc	my-vpc
module_cidr	undefined	10.0.0.0/16	10.0.0.0/16	10.0.0.0/16
infrastructure_state	empty	module code downloaded	plan ready	VPC created

Key Moments - 3 Insights

Why do we run 'terraform init' before 'terraform plan' when using Registry modules?

'terraform init' downloads the module code from the Registry so Terraform knows what resources to create. Without init, plan cannot evaluate the module. See execution_table step 2.

What happens if the module version is not specified?

Terraform uses the latest version available in the Registry by default. Specifying version ensures consistent infrastructure. This is shown in variable_tracker for module_version.

How does Terraform know what resources the module will create?

Terraform reads the module code downloaded during init, then uses inputs to plan resources. This is shown in execution_table step 3.

Visual Quiz - 3 Questions

Look at the execution_table, what happens at step 2?

A Terraform reads the configuration file

B Terraform applies the infrastructure changes

C Terraform downloads the module code from the Registry

D Terraform creates the VPC resource

💡 Hint

Check execution_table row with Step 2 describing 'terraform init'

According to variable_tracker, what is the value of module_version after 'terraform init'?

A 3.14.2

B undefined

C latest

D my-vpc

💡 Hint

Look at variable_tracker row for module_version under 'After init' column

If the module source was changed to a local path, how would the execution_table step 2 change?

A Terraform would download the module from the Registry

B Terraform would skip downloading and use local code

C Terraform would fail because source is invalid

D Terraform would apply the plan immediately

💡 Hint

Consider what 'terraform init' does when source is local instead of Registry

Concept Snapshot

Terraform Registry modules allow reuse of community or official modules.
Declare a module block with source and optional version.
Run 'terraform init' to download module code.
Run 'terraform plan' and 'apply' to create resources.
Specifying version ensures consistent deployments.
Modules simplify infrastructure management.

Full Transcript

Terraform Registry modules let you use pre-built infrastructure code. You write a module block in your Terraform config with a source pointing to the Registry module. Running 'terraform init' downloads the module code locally. Then 'terraform plan' reads the module inputs and shows what resources will be created. Finally, 'terraform apply' creates the resources in your cloud account. Specifying a version locks the module version for stability. This process helps you reuse tested infrastructure components easily.

Practice

1. What is the main purpose of using Terraform Registry modules in your infrastructure code?

easy

A. To reuse tested infrastructure code easily

B. To write all infrastructure code from scratch

C. To avoid using any external code

D. To manually configure cloud resources without code

Solution

1. Step 1: Understand Terraform Registry modules

   Terraform Registry modules are pre-built, reusable pieces of infrastructure code shared publicly or privately.

2. Step 2: Identify the main benefit

   Using these modules helps you avoid rewriting code and ensures you use tested, reliable configurations.

3. Final Answer:

   To reuse tested infrastructure code easily -> Option A

4. Quick Check:

   Terraform Registry modules = reuse code easily [OK]

Hint: Modules = reuse tested code, save time [OK]

Common Mistakes:

• Thinking modules require writing all code manually
• Believing modules prevent code reuse
• Confusing modules with manual resource setup

2. Which of the following is the correct syntax to include a Terraform Registry module in your configuration?

easy

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

B. resource "example" { source = "terraform-aws-modules/vpc/aws" version = "3.0.0" }

C. module "example" (source = "terraform-aws-modules/vpc/aws", version = "3.0.0")

D. include "example" { source = "terraform-aws-modules/vpc/aws" version = "3.0.0" }

Solution

1. Step 1: Recognize the correct block type

   Terraform modules are included using the module block, not resource or include.

2. Step 2: Check syntax for module block

   The correct syntax uses curly braces with key-value pairs for source and version.

3. Final Answer:

   module "example" { source = "terraform-aws-modules/vpc/aws" version = "3.0.0" } -> Option A

4. Quick Check:

   Use module block with source and version [OK]

Hint: Use module block with source and version keys [OK]

Common Mistakes:

• Using resource block instead of module
• Using parentheses instead of braces
• Using include keyword which is invalid

3. Given this Terraform module block:

module "network" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.0.0"
  name    = "my-vpc"
  cidr    = "10.0.0.0/16"
}

What will happen when you run terraform init?

medium

A. Terraform downloads the latest version ignoring the specified version

B. Terraform throws an error because version is missing

C. Terraform downloads version 3.0.0 of the VPC module from the registry

D. Terraform ignores the module and continues without it

Solution

1. Step 1: Understand terraform init behavior with modules

   When terraform init runs, it downloads modules specified with source and version.

2. Step 2: Check version usage

   The version is specified as "3.0.0", so Terraform downloads exactly that version from the registry.

3. Final Answer:

   Terraform downloads version 3.0.0 of the VPC module from the registry -> Option C

4. Quick Check:

   terraform init downloads specified module version [OK]

Hint: terraform init downloads modules with specified version [OK]

Common Mistakes:

• Assuming version is optional and causes error
• Thinking terraform ignores version and downloads latest
• Believing terraform skips modules on init

4. You wrote this module block:

module "db" {
  source = "terraform-aws-modules/rds/aws"
  version = "1.0.0"
  engine = "mysql"
}

When running terraform init, you get an error: Module version 1.0.0 not found. What is the likely cause?

medium

A. The source URL is incorrect and does not point to a module

B. The specified version 1.0.0 does not exist in the Terraform Registry for this module

C. The engine parameter is invalid and causes version error

D. Terraform init requires internet disabled to find modules

Solution

1. Step 1: Analyze the error message

   The error says version 1.0.0 not found, meaning Terraform cannot find that version in the registry for the module.

2. Step 2: Check common causes

   Either the version is mistyped or does not exist. The source looks correct, and engine parameter does not affect version lookup.

3. Final Answer:

   The specified version 1.0.0 does not exist in the Terraform Registry for this module -> Option B

4. Quick Check:

   Version not found error = wrong or missing version [OK]

Hint: Check module version exists in registry before using [OK]

Common Mistakes:

• Blaming source URL when it is correct
• Thinking parameters cause version errors
• Assuming terraform init works offline for modules

5. You want to use a Terraform Registry module but customize it with your own settings. Which approach is best practice?

hard

A. Use the module without specifying version to always get latest

B. Copy the module code into your project and edit it directly

C. Ignore the module and write all resources manually

D. Use the module with source and version, then override variables in your configuration

Solution

1. Step 1: Understand module customization

   Terraform modules accept input variables to customize behavior without changing module code.

2. Step 2: Identify best practice

   Using source and version ensures stable code, and overriding variables lets you customize safely.

3. Final Answer:

   Use the module with source and version, then override variables in your configuration -> Option D

4. Quick Check:

   Customize modules via variables, keep source and version fixed [OK]

Hint: Override variables, don't copy module code [OK]

Common Mistakes:

• Copying module code causes maintenance issues
• Not specifying version risks unexpected changes
• Ignoring modules wastes time and effort