Terragrunt for DRY configurations in Terraform - Commands & Configuration

Introduction

Managing multiple Terraform configurations can be repetitive and error-prone. Terragrunt helps by letting you write shared settings once and reuse them, saving time and avoiding mistakes.

When you have many Terraform modules that share common settings like backend or provider configurations.

When you want to keep your Terraform code clean and avoid copying the same blocks in multiple places.

When you need to manage infrastructure across multiple environments like dev, staging, and production with similar setups.

When you want to easily update shared configurations in one place and have changes apply everywhere.

When you want to simplify running Terraform commands across multiple modules with consistent options.

Config File - terragrunt.hcl

terragrunt.hcl

terraform {
  source = "git::https://github.com/example-org/terraform-modules.git//vpc"
}

include {
  path = find_in_parent_folders()
}

inputs = {
  region = "us-east-1"
  environment = "dev"
}

This file tells Terragrunt where to find the Terraform module code with source.

The include block imports shared settings from parent folders, helping avoid repetition.

The inputs block passes variables like region and environment to the Terraform module.

Commands

This command initializes the Terraform working directory using Terragrunt, downloading modules and providers as configured.

Terminal

terragrunt init

Expected Output

Downloading terraform modules...

Initializing the backend...

Terraform has been successfully initialized!

This command shows the changes Terragrunt will apply to your infrastructure, helping you review before making changes.

Terminal

terragrunt plan

Expected Output

Refreshing Terraform state in-memory prior to plan...



An execution plan has been generated and is shown below.

Resource actions are indicated with the following symbols:

  + create



Plan: 1 to add, 0 to change, 0 to destroy.

This command applies the planned changes automatically without asking for confirmation, creating or updating resources.

Terminal

terragrunt apply -auto-approve

Expected Output

Applying changes...



Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

→

-auto-approve - Skip manual approval to apply changes immediately

This command removes all resources managed by the Terraform module, cleaning up your infrastructure.

Terminal

terragrunt destroy -auto-approve

Expected Output

Destroy complete! Resources: 1 destroyed.

→

-auto-approve - Skip manual approval to destroy resources immediately

Key Concept

If you remember nothing else from this pattern, remember: Terragrunt lets you write shared Terraform settings once and reuse them everywhere to keep your code clean and consistent.

Common Mistakes

Copying backend and provider blocks in every Terraform module instead of using Terragrunt includes.

This causes duplication and makes updates slow and error-prone.

Use Terragrunt's include feature to share backend and provider configurations in a single parent file.

Running terraform commands directly instead of using terragrunt commands.

Terraform commands won't apply the shared configurations and inputs managed by Terragrunt.

Always run terraform commands through Terragrunt to ensure consistent configuration and variable passing.

Not organizing Terragrunt files in a folder structure that reflects environments and modules.

This makes it hard to manage different environments and reuse configurations properly.

Structure your folders with separate directories for environments and modules, each with their own terragrunt.hcl that includes shared settings.

Summary

Create a terragrunt.hcl file to define shared Terraform module source and inputs.

Use terragrunt commands like init, plan, apply, and destroy to manage infrastructure with shared configs.

Use the include block in terragrunt.hcl to avoid repeating backend and provider settings.

Practice

1. What is the main purpose of using Terragrunt with Terraform?

easy

A. To reuse Terraform configurations and avoid repeating code

B. To replace Terraform with a new tool

C. To write Terraform code in a different programming language

D. To deploy applications without infrastructure

Solution

1. Step 1: Understand Terragrunt's role

   Terragrunt is designed to help reuse and share Terraform code, making it easier to manage infrastructure without repeating code.

2. Step 2: Compare options

   Options B, C, and D describe incorrect uses or misunderstandings of Terragrunt's purpose.

3. Final Answer:

   To reuse Terraform configurations and avoid repeating code -> Option A

4. Quick Check:

   Terragrunt = DRY Terraform code reuse [OK]

Hint: Terragrunt helps avoid repeating Terraform code [OK]

Common Mistakes:

• Thinking Terragrunt replaces Terraform
• Believing Terragrunt changes Terraform language
• Confusing Terragrunt with application deployment tools

2. Which of the following is the correct way to include a Terraform module using Terragrunt?

easy

A. module "app" { source = "./app" }

B. include { path = find_in_parent_folders() }

C. terraform { backend = "s3" }

D. resource "aws_instance" "web" {}

Solution

1. Step 1: Identify Terragrunt syntax for including configs

   Terragrunt uses the include block with path = find_in_parent_folders() to reuse parent configs.

2. Step 2: Differentiate from Terraform syntax

   Options A, C, and D are Terraform syntax: A is a module block, C is backend config, D is a resource block, not Terragrunt includes.

3. Final Answer:

   include { path = find_in_parent_folders() } -> Option B

4. Quick Check:

   Terragrunt include uses find_in_parent_folders() [OK]

Hint: Terragrunt includes parent config with include + find_in_parent_folders() [OK]

Common Mistakes:

• Using Terraform module syntax instead of Terragrunt include
• Confusing backend config with include
• Writing resource blocks inside Terragrunt files

3. Given this Terragrunt configuration snippet:

include {
  path = find_in_parent_folders()
}

inputs = {
  region = "us-east-1"
  env    = "prod"
}

What will happen when you run terragrunt apply in this folder?

medium

A. Terragrunt will apply Terraform code without any variables

B. Terragrunt will fail because inputs cannot be used with include

C. Terragrunt will ignore the inputs block and only use parent config

D. Terragrunt will apply Terraform code using the parent config and inputs region=us-east-1, env=prod

Solution

1. Step 1: Understand include and inputs usage

   The include block imports parent config. The inputs block adds or overrides variables for this folder.

2. Step 2: Predict Terragrunt behavior on apply

   Terragrunt merges parent config with local inputs, so region and env variables are set as given.

3. Final Answer:

   Terragrunt will apply Terraform code using the parent config and inputs region=us-east-1, env=prod -> Option D

4. Quick Check:

   Include + inputs = merged config applied [OK]

Hint: Inputs override or add variables when using include [OK]

Common Mistakes:

• Thinking inputs are ignored with include
• Assuming inputs cause errors
• Believing variables are not passed to Terraform

4. You wrote this Terragrunt config:

include {
  path = find_in_parent_folders()
}

inputs = {
  region = "us-west-2"
  env = "dev"
}

terraform {
  source = "../modules/app"
}

When running terragrunt apply, you get an error: "Error: Unsupported block type". What is the likely cause?

medium

A. The terraform block cannot be nested inside the inputs block

B. The inputs block must come before include

C. The source path is incorrect

D. The region variable is invalid

Solution

1. Step 1: Check Terragrunt config block usage

   Terragrunt requires the terraform { source = ... } block at the root level. It cannot be nested inside other blocks like inputs.

2. Step 2: Identify error cause

   The error "Unsupported block type" usually means the block is misplaced or invalid in Terragrunt config.

3. Final Answer:

   The terraform block cannot be nested inside the inputs block -> Option A

4. Quick Check:

   Misplaced terraform block causes error [OK]

Hint: Terraform block must be correctly placed in Terragrunt config [OK]

Common Mistakes:

• Placing terraform block inside inputs or include
• Wrong order of blocks causing syntax errors
• Incorrect source path causing unrelated errors

5. You manage multiple environments (dev, staging, prod) with Terragrunt. You want to avoid repeating the backend configuration for each environment. Which approach best follows DRY principles?

hard

A. Define backend only in Terraform modules, not in Terragrunt

B. Copy the backend block into each environment's Terragrunt config

C. Create a root Terragrunt config with backend settings and use include in each environment folder

D. Use different backend types for each environment

Solution

1. Step 1: Understand DRY with Terragrunt

   Terragrunt allows sharing common config via a root config and include blocks in child folders.

2. Step 2: Evaluate options for backend reuse

   Create a root Terragrunt config with backend settings and use include in each environment folder uses root config for backend, avoiding repetition. Copy the backend block into each environment's Terragrunt config repeats code, violating DRY. Define backend only in Terraform modules, not in Terragrunt is incorrect because backend is configured in Terragrunt for remote state. Use different backend types for each environment adds complexity without reuse.

3. Final Answer:

   Create a root Terragrunt config with backend settings and use include in each environment folder -> Option C

4. Quick Check:

   Root config + include = DRY backend config [OK]

Hint: Put shared backend in root config, include it in environments [OK]

Common Mistakes:

• Copying backend config to each environment
• Configuring backend only in Terraform modules
• Using different backends unnecessarily