Terraform Registry modules - Mini Project: Build & Apply

Using Terraform Registry Modules

📖 Scenario: You are setting up cloud infrastructure using Terraform. To simplify your work, you want to use a module from the Terraform Registry that creates a virtual private cloud (VPC) network.This project will guide you step-by-step to configure Terraform to use a Registry module, set variables, and apply the module to create a VPC.

🎯 Goal: Build a Terraform configuration that uses the official Terraform Registry module terraform-aws-modules/vpc/aws to create a VPC with a specific CIDR block and enable DNS support.

📋 What You'll Learn

Use the Terraform Registry module terraform-aws-modules/vpc/aws

Set the VPC CIDR block to 10.0.0.0/16

Enable DNS support and DNS hostnames

Output the VPC ID after creation

💡 Why This Matters

🌍 Real World

Using Terraform Registry modules helps you quickly build cloud infrastructure by reusing tested and community-approved code.

💼 Career

Cloud engineers and DevOps professionals often use Terraform modules to standardize and speed up infrastructure deployment.

1

Initialize Terraform configuration with provider

Create a Terraform configuration file that declares the aws provider with the region set to us-east-1.

Terraform

# Your code here

Hint

Use the provider "aws" block and set region = "us-east-1".

2

Add the Terraform Registry VPC module

Add a module block named vpc that uses the source terraform-aws-modules/vpc/aws with version ~> 3.0.

Terraform

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

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

# Your code here

Hint

Use a module "vpc" block with source and version attributes.

3

Configure the VPC module with CIDR and DNS settings

Inside the module "vpc" block, set cidr to "10.0.0.0/16", enable_dns_support to true, and enable_dns_hostnames to true.

Terraform

terraform {
  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"
  # Your code here
}

Hint

Add the three variables inside the module block exactly as shown.

4

Output the VPC ID

Create an output block named vpc_id that outputs the value of module.vpc.vpc_id.

Terraform

terraform {
  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"
  cidr                = "10.0.0.0/16"
  enable_dns_support  = true
  enable_dns_hostnames = true
}

# Your code here

Hint

Use an output block with the name vpc_id and set value = module.vpc.vpc_id.

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