Creating a child module in Terraform - Why You Should Know This

The Big Idea

What if you could fix a problem once and have it fixed everywhere automatically?

The Scenario

Imagine you have to build many similar parts of your cloud setup by copying and pasting the same code again and again.

Each time you want to change something, you must find and update every copy manually.

The Problem

This manual way is slow and easy to mess up.

If you forget one place or make a typo, your cloud setup can break or behave unexpectedly.

It's like trying to fix many copies of a recipe instead of just one master recipe.

The Solution

Creating a child module lets you write the code once and reuse it everywhere.

You can change the module in one place, and all uses update automatically.

This saves time, reduces mistakes, and keeps your cloud setup neat and organized.

Before vs After

✗ Before

resource "aws_instance" "web1" { ... }
resource "aws_instance" "web2" { ... }

✓ After

module "web_server" {
  source = "./child_module"
  count  = 2
  ...
}

What It Enables

You can build complex cloud setups quickly by reusing tested building blocks.

Real Life Example

A company needs 10 similar servers for different teams. Instead of writing code 10 times, they create one child module and deploy it 10 times with different settings.

Key Takeaways

Manual repetition is slow and error-prone.

Child modules let you reuse code easily.

One change updates all uses, saving time and mistakes.

Practice

1. What is the main purpose of creating a child module in Terraform?

easy

A. To avoid using variables in Terraform

B. To break down infrastructure into smaller, reusable pieces

C. To increase the number of resources in the root module

D. To deploy resources only in one cloud provider

Solution

1. Step 1: Understand module purpose

   Child modules help organize infrastructure by splitting it into smaller parts.

2. Step 2: Identify benefits

   This makes code reusable and easier to manage across projects.

3. Final Answer:

   To break down infrastructure into smaller, reusable pieces -> Option B

4. Quick Check:

   Child modules = reusable infrastructure parts [OK]

Hint: Child modules = smaller reusable parts of infrastructure [OK]

Common Mistakes:

• Thinking child modules increase resource count in root
• Believing child modules remove need for variables
• Assuming child modules limit to one cloud provider

2. Which Terraform block correctly includes a child module located in the folder ./modules/network?

easy

A. variable "network" { source = "./modules/network" }

B. resource "network" { source = "./modules/network" }

C. provider "network" { source = "./modules/network" }

D. module "network" { source = "./modules/network" }

Solution

1. Step 1: Identify correct block type

   Child modules are included using the module block in Terraform.

2. Step 2: Check syntax for source

   The source attribute points to the child module folder path.

3. Final Answer:

   module "network" { source = "./modules/network" } -> Option D

4. Quick Check:

   Use module block with source path [OK]

Hint: Use module block with source path to include child module [OK]

Common Mistakes:

• Using resource or provider blocks instead of module
• Placing source inside resource or variable blocks
• Incorrect block type for including modules

3. Given this root module code:

module "web" {
  source = "./modules/webserver"
  instance_count = 3
}

And the child module variables.tf contains:

variable "instance_count" {
  type = number
}

What will be the value of var.instance_count inside the child module?

medium

A. 3

B. 0

C. null

D. 1

Solution

1. Step 1: Check variable passing

   The root module passes instance_count = 3 to the child module.

2. Step 2: Confirm variable usage

   The child module declares instance_count variable to receive this value.

3. Final Answer:

   3 -> Option A

4. Quick Check:

   Passed variable value = 3 [OK]

Hint: Passed variable values appear inside child module as given [OK]

Common Mistakes:

• Assuming default or null if variable is declared
• Confusing variable names or missing passing
• Thinking child module variables reset automatically

4. You wrote this root module code:

module "db" {
  source = "./modules/database"
  db_name = "prod"
}

But Terraform shows an error: An argument named "db_name" is not expected here. Did you mean to define a variable named "db_name"?
What is the likely cause?

medium

A. Terraform does not support passing variables to modules

B. The source path is incorrect

C. The child module does not declare a variable named db_name

D. The root module must use resource block instead of module

Solution

1. Step 1: Analyze error message

   The error indicates that the argument "db_name" is not expected, which happens when the child module does not declare a variable named "db_name".

2. Step 2: Check child module variables

   If child module does not declare variable "db_name", Terraform cannot accept the passed value.

3. Final Answer:

   The child module does not declare a variable named db_name -> Option C

4. Quick Check:

   Passing undeclared argument causes "not expected" error [OK]

Hint: Declare variables in child module to accept passed values [OK]

Common Mistakes:

• Ignoring variable declaration in child module
• Assuming source path error without checking variables
• Thinking modules can't receive variables

5. You want to create a child module that provisions an AWS S3 bucket with a customizable name and versioning enabled by default. Which of the following variables.tf and main.tf snippets inside the child module is the best practice?

hard

A. variables.tf:variable "bucket_name" { type = string }
variable "versioning" { type = bool, default = true }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

B. variables.tf:variable "bucket_name" { type = string, default = "mybucket" }
variable "versioning" { type = string }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

C. variables.tf:variable "bucket_name" { type = string }
variable "versioning" { type = string, default = "true" }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

D. variables.tf:variable "bucket_name" { type = number }
variable "versioning" { type = bool }main.tf:resource "aws_s3_bucket" "bucket" {
bucket = var.bucket_name
versioning {
enabled = var.versioning
}
}

Solution

1. Step 1: Check variable types and defaults

   Bucket name should be string without default to force user input. Versioning is boolean with default true.

2. Step 2: Validate resource usage

   Resource uses var.bucket_name and var.versioning correctly with boolean type for versioning enabled.

3. Final Answer:

   variables.tf with string and bool (default true), main.tf using these variables correctly -> Option A

4. Quick Check:

   Correct types and defaults = variables.tf:
   

   variable "bucket_name" { type = string }
   variable "versioning" { type = bool, default = true }

   
   main.tf:
   

   resource "aws_s3_bucket" "bucket" {
     bucket = var.bucket_name
     versioning {
       enabled = var.versioning
     }
   }

   [OK]

Hint: Use correct variable types and defaults for best practice [OK]

Common Mistakes:

• Using string type for boolean variables
• Setting wrong default types
• Using number type for bucket name