Terraform Registry modules - Commands & Configuration

Introduction

Terraform Registry modules help you reuse pre-made building blocks for your cloud infrastructure. They save time by letting you add complex setups with simple code instead of writing everything from scratch.

When you want to create a virtual network with best practices without writing all the details yourself

When you need to add a managed database service quickly and correctly configured

When you want to deploy a common application setup like a web server cluster with load balancing

When you want to share your infrastructure code with others in a reusable way

When you want to keep your Terraform code clean and organized by using tested modules

Config File - main.tf

main.tf

terraform {
  required_version = ">= 1.0"
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 4.0"
    }
  }
}

provider "aws" {
  region = "us-east-1"
}

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "~> 3.0"

  name = "example-vpc"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  public_subnets  = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  private_subnets = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway = true
  single_nat_gateway = true
}

This Terraform file sets up the AWS provider and uses a module from the Terraform Registry to create a Virtual Private Cloud (VPC). The module "vpc" block pulls the VPC module from the registry, specifying the version and configuration like network ranges and availability zones. This module handles creating subnets, routing, and NAT gateways automatically.

Commands

This command downloads the module and provider plugins needed for your configuration. It prepares your working directory for Terraform commands.

Terminal

terraform init

Expected Output

Initializing the backend...



Initializing provider plugins...

- Finding hashicorp/aws versions matching "~> 4.0"...

- Installing hashicorp/aws v4.50.0...

- Installed hashicorp/aws v4.50.0 (signed by HashiCorp)



Terraform has been successfully initialized!



You may now begin working with Terraform. Try running "terraform plan" to see

any changes that are required for your infrastructure. All Terraform commands

should now work.

This command shows what Terraform will create or change based on your configuration. It helps you verify before applying.

Terminal

terraform plan

Expected Output

An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Terraform will perform the following actions:



  # module.vpc.aws_vpc.main will be created

  + resource "aws_vpc" "main" {

      + cidr_block = "10.0.0.0/16"

      + enable_dns_support = true

      + enable_dns_hostnames = true

      + id = (known after apply)

      ...

    }



Plan: 10 to add, 0 to change, 0 to destroy.



─────────────────────────────────────────────────────────────────────────────



Note: You didn't specify an "-out" parameter to save this plan, so Terraform

can't guarantee to take exactly these actions if you run "terraform apply" later.

This command applies the planned changes to create the infrastructure. The flag skips manual approval to speed up the process.

Terminal

terraform apply -auto-approve

Expected Output

aws_vpc.main: Creating...

aws_vpc.main: Creation complete after 3s [id=vpc-0abcd1234efgh5678]

...

Apply complete! Resources: 10 added, 0 changed, 0 destroyed.

→

-auto-approve - Automatically approve the apply step without asking for confirmation

This command removes all the infrastructure created by Terraform. The flag skips manual approval.

Terminal

terraform destroy -auto-approve

Expected Output

aws_vpc.main: Destroying...

aws_vpc.main: Destruction complete after 2s

...

Destroy complete! Resources: 10 destroyed.

→

-auto-approve - Automatically approve the destroy step without asking for confirmation

Key Concept

If you remember nothing else from this pattern, remember: Terraform Registry modules let you reuse tested infrastructure code easily by just referencing them in your configuration.

Common Mistakes

Not running 'terraform init' before 'terraform plan' or 'apply'

Terraform won't download the module or provider plugins, causing errors.

Always run 'terraform init' first to prepare your working directory.

Using a module source without specifying a version

This can cause unexpected changes if the module updates with breaking changes.

Always specify a version constraint to keep your infrastructure stable.

Changing module source code directly inside the .terraform directory

Changes will be overwritten on the next 'terraform init' and are not tracked.

Copy the module to your own directory if you want to customize it, or use module inputs.

Summary

Use 'terraform init' to download modules and providers before planning or applying.

'terraform plan' shows what infrastructure changes will happen without applying them.

'terraform apply' creates or updates infrastructure based on your configuration and modules.

'terraform destroy' removes all created infrastructure safely.

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