Module structure and conventions in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Terraform Module Inputs

Which of the following correctly describes how to define an input variable in a Terraform module?

A parameter "region" { default = "us-west-1" }

B input "region" { type = string default = "us-west-1" }

C var region = "us-west-1"

D variable "region" { type = string default = "us-west-1" }

💡 Hint

Terraform uses a specific block keyword to declare variables.

Terraform input variables are declared using the variable block with a name and optional attributes like type and default.

❓ Configuration

intermediate

Correct Output Declaration in Terraform Module

Which option correctly defines an output named instance_ip in a Terraform module?

A output instance_ip = aws_instance.web.private_ip

B output "instance_ip" { value = aws_instance.web.private_ip }

C output "instance_ip" = aws_instance.web.private_ip

D output { name = "instance_ip" value = aws_instance.web.private_ip }

💡 Hint

Outputs use a block with a name and a value attribute.

Terraform outputs are declared with an output block naming the output and specifying the value to expose.

❓ Architecture

advanced

Best Practice for Module Directory Structure

Which directory structure follows Terraform best practices for a reusable module named network?

A

network/
  main.tf
  variables.tf
  outputs.tf
  README.md

B

network/
  network.tf
  inputs.tf
  results.tf
  docs.md

C

network/
  main.tf
  vars.tf
  outs.tf
  README.md

D

network/
  terraform.tf
  variables.tf
  outputs.tf
  README.md

💡 Hint

Look for standard file names used in Terraform modules.

Terraform modules typically use main.tf for resources, variables.tf for inputs, outputs.tf for outputs, and README.md for documentation.

❓ security

advanced

Handling Sensitive Variables in Terraform Modules

Which option correctly marks a variable as sensitive in a Terraform module to avoid showing its value in logs?

A variable "db_password" { type = string private = true }

B variable "db_password" { type = string hidden = true }

C variable "db_password" { type = string sensitive = true }

D variable "db_password" { type = string secret = true }

💡 Hint

Terraform uses a specific attribute to mark variables as sensitive.

The sensitive = true attribute in a variable block tells Terraform to hide the value in output and logs.

❓ service_behavior

expert

Effect of Module Source Changes on Terraform State

You update the source attribute of a Terraform module to point to a new version. What happens to the existing resources managed by the old module version when you run terraform apply?

A Terraform treats the new module as a separate resource set and plans to create new resources while keeping old ones unless explicitly destroyed.

B Terraform ignores the source change and continues using the old module version until manually refreshed.

C Terraform deletes all old resources immediately before applying the new module changes.

D Terraform automatically updates existing resources in place to match the new module source without recreating them.

💡 Hint

Think about how Terraform tracks resources and modules in state files.

Changing the module source is treated as a new module instance. Terraform plans to create new resources from the new source and keeps old resources unless you remove or replace them explicitly.

Practice

1. What is the main purpose of using a Terraform module?

easy

A. To group and reuse cloud resource configurations

B. To write scripts for cloud providers

C. To store cloud provider credentials

D. To monitor cloud resource usage

Solution

1. Step 1: Understand module purpose

   Terraform modules are designed to group related cloud resources together for reuse and better organization.

2. Step 2: Compare options

   Only To group and reuse cloud resource configurations correctly describes this purpose. Other options describe unrelated tasks.

3. Final Answer:

   To group and reuse cloud resource configurations -> Option A

4. Quick Check:

   Module purpose = reuse and grouping [OK]

Hint: Modules group resources for reuse and clarity [OK]

Common Mistakes:

• Confusing modules with scripts
• Thinking modules store credentials
• Assuming modules monitor usage

2. Which of the following is the correct way to call a module named network located in a folder modules/network?

easy

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

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

C. module network { path = "modules/network" }

D. resource "network" { path = "modules/network" }

Solution

1. Step 1: Identify module call syntax

   Terraform uses module "name" { source = "path" } to call modules.

2. Step 2: Check options

   Only module "network" { source = "modules/network" } uses correct module block and source attribute.

3. Final Answer:

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

4. Quick Check:

   Module call uses module block and source [OK]

Hint: Use module block with source attribute for calling modules [OK]

Common Mistakes:

• Using resource instead of module
• Using path instead of source
• Omitting quotes around module name

3. Given this module folder structure:

modules/
  webserver/
    main.tf
    variables.tf
    outputs.tf

What is the purpose of the variables.tf file inside the module?

medium

A. To declare output values from the module

B. To define input variables for the module

C. To write the main resource definitions

D. To store provider configurations

Solution

1. Step 1: Understand file roles in module

   In Terraform modules, variables.tf defines input variables the module accepts.

2. Step 2: Match options

   To define input variables for the module correctly states this. Outputs are in outputs.tf, main resources in main.tf, and provider configs are outside modules.

3. Final Answer:

   To define input variables for the module -> Option B

4. Quick Check:

   variables.tf = input variables [OK]

Hint: variables.tf defines inputs; outputs.tf defines outputs [OK]

Common Mistakes:

• Confusing variables.tf with outputs.tf
• Putting resource code in variables.tf
• Adding provider config inside module

4. You wrote this module call:

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

But Terraform shows an error: "Unsupported argument: db_name". What is the likely cause?

medium

A. The source path is incorrect

B. Module names cannot contain underscores

C. The module does not declare an input variable named db_name

D. db_name should be declared inside main.tf

Solution

1. Step 1: Understand error meaning

   "Unsupported argument" means the module does not expect the given input variable.

2. Step 2: Check module inputs

   If db_name is not declared as a variable in the module's variables.tf, Terraform rejects it.

3. Final Answer:

   The module does not declare an input variable named db_name -> Option C

4. Quick Check:

   Input variables must be declared to be used [OK]

Hint: Declare input variables in module to avoid unsupported argument errors [OK]

Common Mistakes:

• Assuming source path causes unsupported argument
• Thinking module names restrict underscores
• Trying to declare inputs inside main.tf

5. You want to create a reusable module for deploying a virtual machine with optional tags. Which structure correctly supports optional tags with a default empty map?

hard

A. In variables.tf: variable "tags" { type = list(string) }

B. In main.tf: variable "tags" { default = null }

C. In outputs.tf: output "tags" { value = var.tags }

D. In variables.tf: variable "tags" { type = map(string) default = {} }

Solution

1. Step 1: Define optional input variable

   To make tags optional, define a variable with type map(string) and default empty map {}.

2. Step 2: Evaluate options

   In variables.tf: variable "tags" { type = map(string) default = {} } correctly defines this in variables.tf. In main.tf: variable "tags" { default = null } lacks type and uses null default. In outputs.tf: output "tags" { value = var.tags } is output, not input. In variables.tf: variable "tags" { type = list(string) } uses list instead of map.

3. Final Answer:

   In variables.tf: variable "tags" { type = map(string) default = {} } -> Option D

4. Quick Check:

   Optional map variable needs default empty map [OK]

Hint: Use map(string) with default {} for optional tags [OK]

Common Mistakes:

• Using list instead of map for tags
• Not setting a default value
• Declaring variables in outputs.tf