Creating a child module in Terraform - Practice Exercises

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding child module source paths

You have a Terraform root module and want to include a child module located in a folder named modules/network. Which source value correctly references this child module?

A "./modules/network"

B "network/modules"

C "../modules/network"

D "modules/network/"

💡 Hint

Think about the path relative to the root module where you call the child module.

The source path for a child module is relative to the root module's directory. Using "./modules/network" correctly points to the modules/network folder inside the root module.

❓ Configuration

intermediate

Passing variables to a child module

You want to pass a variable named region with value "us-west-2" to a child module. Which is the correct way to do this in the root module?

Terraform

module "child" {
  source = "./modules/child"
  // pass region here
}

A variables.region = "us-west-2"

B var.region = "us-west-2"

C region = "us-west-2"

D input.region = "us-west-2"

💡 Hint

Variables are passed by naming them directly inside the module block.

To pass variables to a child module, you assign values directly using the variable name as the key inside the module block.

❓ Architecture

advanced

Module output usage in root module

A child module outputs a value named subnet_id. How do you correctly reference this output in the root module?

Terraform

output "subnet_id" {
  value = module.child.subnet_id
}

A module.child.subnet_id

B child.subnet_id

C module.subnet_id.child

D output.child.subnet_id

💡 Hint

Outputs from child modules are accessed using module...

To get an output from a child module, you use module.child.subnet_id where child is the module block name.

❓ security

advanced

Avoiding sensitive data exposure in child modules

You have a child module that outputs a sensitive value like a password. What is the best way to prevent this sensitive output from showing in the root module's plan or apply output?

A Encrypt the output value manually before output

B Do not declare the output in the child module

C Set <code>private = true</code> on the output

D Mark the output as <code>sensitive = true</code> in the child module

💡 Hint

Terraform has a built-in way to mark outputs as sensitive.

Marking an output as sensitive = true tells Terraform to hide its value in CLI output and logs, protecting sensitive data.

❓ service_behavior

expert

Effect of changing child module source on Terraform state

You update the source path of a child module in your root module to point to a different folder with a different resource configuration. What happens when you run terraform apply?

A Terraform will automatically migrate the state from old to new module resources

B Terraform will treat the new module as a new set of resources and try to create them, leaving old resources orphaned

C Terraform will delete all old resources before creating new ones

D Terraform will throw an error and refuse to apply

💡 Hint

Think about how Terraform tracks resources by module source paths.

Changing the source path makes Terraform see the child module as different. It creates new resources but does not remove old ones automatically, causing orphaned resources unless manually handled.

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