Module composition patterns in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ Architecture

intermediate

Understanding Module Composition with Terraform

You have a Terraform root module that calls two child modules: network and compute. The compute module requires the VPC ID output from the network module. Which is the correct way to pass the VPC ID from network to compute?

Terraform

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

module "compute" {
  source = "./modules/compute"
  vpc_id = ???
}

A vpc_id = module.network.vpc_id

B vpc_id = output.network.vpc_id

C vpc_id = var.network.vpc_id

D vpc_id = local.network.vpc_id

💡 Hint

Think about how Terraform modules expose outputs and how other modules can access them.

In Terraform, outputs from one module can be accessed using module... Here, module.network.vpc_id correctly references the output from the network module.

❓ Configuration

intermediate

Correct Module Source Usage

You want to reuse a Terraform module stored in a GitHub repository. Which source value correctly references the module?

Terraform

module "storage" {
  source = ???
  version = "1.0.0"
}

A "git::https://github.com/terraform-modules/storage.git"

B "https://github.com/terraform-modules/storage"

C "github.com/terraform-modules/storage"

D "terraform-registry/storage"

💡 Hint

Terraform requires a specific syntax to fetch modules from Git repositories.

To use a module from a Git repository, the source must start with git:: followed by the repository URL. Option A is the correct syntax.

❓ security

advanced

Secure Module Composition with Sensitive Variables

You have a root module that calls a child module which requires a sensitive API key. How should you pass this sensitive variable to avoid exposing it in Terraform state or logs?

Terraform

module "service" {
  source = "./modules/service"
  api_key = ???
}

A api_key = "hardcoded-secret"

B api_key = local.api_key

C api_key = var.api_key

D api_key = output.api_key

💡 Hint

Consider how Terraform handles sensitive variables and best practices for secrets.

Passing sensitive data as input variables marked sensitive (like var.api_key) is best practice. Hardcoding secrets or using outputs can expose them. Locals do not protect sensitivity.

❓ service_behavior

advanced

Effect of Module Dependency on Resource Creation Order

Given two modules, db and app, where app depends on the database endpoint output from db, what is the effect on resource creation order when you run terraform apply?

Terraform

module "db" {
  source = "./modules/db"
}

module "app" {
  source = "./modules/app"
  db_endpoint = module.db.endpoint
}

A Terraform creates <code>app</code> and <code>db</code> resources in parallel without order.

B Terraform creates <code>db</code> resources first, then <code>app</code> resources after <code>db</code> outputs are available.

C Terraform creates <code>app</code> resources first, then <code>db</code> resources.

D Terraform fails because modules cannot depend on each other.

💡 Hint

Think about how Terraform manages dependencies between modules using outputs and inputs.

Terraform automatically creates resources in dependency order. Since app uses an output from db, db resources are created first.

✅ Best Practice

expert

Optimizing Module Composition for Reusability and Maintainability

You are designing a Terraform infrastructure with multiple environments (dev, staging, prod). Which module composition pattern best supports reusability and environment-specific customization?

A Create separate child modules for each environment with no shared code.

B Create one root module per environment, each with duplicated child modules customized per environment.

C Hardcode environment values inside child modules and call them without variables.

D Use a single root module with environment-specific variables passed to shared child modules.

💡 Hint

Consider how to avoid code duplication while allowing environment differences.

Using a single root module with environment variables passed to shared child modules promotes code reuse and easier maintenance. Other options cause duplication or inflexibility.