Terragrunt for DRY configurations in Terraform - Step-by-Step Execution

Process Flow - Terragrunt for DRY configurations

Write common config in terragrunt.hcl

↓

Reference common config in child modules

↓

Run terragrunt apply in child module

↓

Terragrunt merges configs

↓

Terraform runs with merged config

↓

Infrastructure deployed with DRY configs

Terragrunt lets you write shared config once and reuse it in many places, avoiding repetition.

Execution Sample

Terraform

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

include {
  path = find_in_parent_folders()
}

Child terragrunt.hcl references common config from parent to reuse settings.

Process Table

Step	Action	Config Source	Merged Config	Result
1	Terragrunt reads child terragrunt.hcl	Child file	Child config only	Partial config loaded
2	Terragrunt finds parent terragrunt.hcl	Parent file	Parent config only	Common config loaded
3	Terragrunt merges parent and child configs	Parent + Child	Combined config	Full config ready
4	Terragrunt runs terraform with merged config	Merged config	Final config	Terraform applies infrastructure
5	Terraform deploys resources	Final config	N/A	Infrastructure created
6	Execution ends	N/A	N/A	Deployment complete

💡 All configs merged and terraform applied successfully

Status Tracker

Variable	Start	After Step 2	After Step 3	Final
config	{}	{common settings}	{common + child settings}	{merged config}

Key Moments - 2 Insights

Why does Terragrunt look for a parent terragrunt.hcl?

Terragrunt searches parent folders to find shared config to merge with child config, as shown in execution_table step 2 and 3.

What happens if child and parent configs have the same setting?

Child config overrides parent config for that setting during merge (step 3), ensuring specific customization.

Visual Quiz - 3 Questions

Look at the execution_table, at which step does Terragrunt merge parent and child configs?

A Step 1

B Step 3

C Step 2

D Step 4

💡 Hint

Check the 'Action' column for merging configs in execution_table row 3.

According to variable_tracker, what is the state of 'config' after step 2?

A {}

B {common + child settings}

C {common settings}

D {merged config}

💡 Hint

Look at the 'After Step 2' column for 'config' in variable_tracker.

If the child config overrides a setting from the parent, which step shows this effect?

A Step 3

B Step 2

C Step 1

D Step 5

💡 Hint

Merging configs and resolving conflicts happens at step 3 in execution_table.

Concept Snapshot

Terragrunt helps avoid repeating config by
sharing common settings in a parent terragrunt.hcl.
Child configs include parent with 'include' block.
Terragrunt merges configs before running Terraform.
Overrides in child config customize behavior.
Run 'terragrunt apply' in child folder to deploy.

Full Transcript

Terragrunt is a tool that helps you keep your Terraform configurations DRY, meaning you don't repeat the same settings in many places. You write common configuration once in a parent terragrunt.hcl file. Then, in child folders, you write terragrunt.hcl files that include the parent config using the 'include' block. When you run 'terragrunt apply' in a child folder, Terragrunt reads the child config, finds the parent config, merges them together, and then runs Terraform with the combined configuration. If the child config has settings that overlap with the parent, the child's settings take priority. This way, you can share common infrastructure settings and customize only what you need in each child folder. The execution table shows these steps clearly, from reading configs to merging and applying infrastructure. The variable tracker shows how the configuration state changes as Terragrunt processes the files. This approach saves time and reduces errors by avoiding duplicated code.

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