Terragrunt for DRY configurations in Terraform - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Understanding Terragrunt's Purpose

What is the main benefit of using Terragrunt with Terraform?

A It helps avoid repeating the same Terraform code by managing configurations centrally.

B It automatically scales cloud resources based on traffic.

C It replaces Terraform and runs cloud infrastructure without code.

D It provides a graphical interface to design cloud infrastructure visually.

💡 Hint

Think about how Terragrunt helps when you have many similar infrastructure setups.

Terragrunt is a tool that helps keep Terraform configurations DRY (Don't Repeat Yourself) by allowing you to reuse and manage common settings in one place.

❓ Configuration

intermediate

Terragrunt Configuration Inheritance

Given a Terragrunt configuration file terragrunt.hcl that includes a remote_state block, which option correctly shows how to inherit this remote state configuration in a child module?

Terraform

remote_state {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "global/terraform.tfstate"
    region = "us-east-1"
  }
}

A

include {
  path = find_in_parent_folders()
}

remote_state = include.get().remote_state

B

include {
  path = find_in_parent_folders()
}

remote_state {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "global/terraform.tfstate"
    region = "us-east-1"
  }
}

C

include {
  path = find_in_parent_folders()
}

remote_state = local.remote_state

D

remote_state {
  backend = "s3"
  config = {
    bucket = "my-terraform-state"
    key    = "global/terraform.tfstate"
    region = "us-east-1"
  }
}

💡 Hint

Look for the syntax that references the parent's remote_state block after including it.

In Terragrunt, after including a parent configuration with include, you can access its blocks using include.get(). This allows child modules to inherit settings like remote_state without redefining them.

❓ Architecture

advanced

Terragrunt Folder Structure for Multiple Environments

You want to manage Terraform infrastructure for two environments: dev and prod. Using Terragrunt, which folder structure best supports DRY principles and environment isolation?

A

/terraform/
  /dev/
    main.tf
  /prod/
    main.tf
  terragrunt.hcl

B

/modules/
  /dev/
    main.tf
  /prod/
    main.tf

C

/live/
  /dev/
    terragrunt.hcl
  /prod/
    terragrunt.hcl
  terragrunt.hcl

D

/live/
  /dev/
    main.tf
  /prod/
    main.tf

💡 Hint

Think about where Terragrunt files should be placed to share common configs and separate environments.

Terragrunt encourages a folder structure where a root terragrunt.hcl holds shared configs, and environment folders have their own terragrunt.hcl files to override or add environment-specific settings. This keeps code DRY and environments isolated.

❓ security

advanced

Securing Sensitive Variables in Terragrunt

Which approach best protects sensitive variables like passwords when using Terragrunt with Terraform?

A Store sensitive variables directly in <code>terragrunt.hcl</code> files in plain text.

B Use environment variables or encrypted secrets managers and reference them in Terragrunt configs.

C Commit sensitive variables in Terraform <code>.tf</code> files to version control for easy access.

D Hardcode sensitive values in Terraform modules to avoid passing them through Terragrunt.

💡 Hint

Think about how to keep secrets safe and avoid exposing them in code repositories.

Best practice is to avoid storing sensitive data in code files. Instead, use environment variables or secret management tools and reference those securely in Terragrunt configurations.

❓ service_behavior

expert

Terragrunt Behavior with Dependency Blocks

Consider this Terragrunt configuration snippet:

dependency "vpc" {
  config_path = "../vpc"
}

inputs = {
  vpc_id = dependency.vpc.outputs.vpc_id
}

What happens if the ../vpc module has not been applied yet when you run Terragrunt in this module?

A Terragrunt ignores the dependency and applies the current module without the <code>vpc_id</code> input.

B Terragrunt fails with an error because the dependency outputs are missing.

C Terragrunt prompts the user to manually apply the dependency module before continuing.

D Terragrunt automatically applies the <code>../vpc</code> module first, then uses its outputs.

💡 Hint

Think about how Terragrunt manages dependencies between modules automatically.

Terragrunt automatically applies dependency modules first to ensure their outputs are available for the current module. This helps manage complex infrastructure with dependencies smoothly.