Explain the difference between Terraform and Terragrunt at a high level.
Quick Answer
Terraform is the core IaC engine and language. Terragrunt is a thin wrapper around Terraform that adds features the core language doesn't have: DRY backend/provider configuration shared across many environments, automatic dependency ordering between separate Terraform modules/state files (`dependency` blocks), and convenient `run-all` commands to plan/apply many modules at once. Teams reach for Terragrunt when a multi-environment, many-module setup starts accumulating painful duplication in backend blocks and inter-module wiring that native Terraform (even with `for_each`/modules) doesn't cleanly solve — it's an additive tool on top of Terraform, not a replacement for it.
Detailed Answer
This comparison tests whether you understand Terraform's actual scope, since Terragrunt is frequently mistaken for a competing tool rather than a complementary one built directly on top of Terraform.
Terraform — the core engine and language
Terraform provides the HCL language, the provider plugin model, state management, the dependency graph, and the plan/apply workflow. Everything discussed in the rest of this stack (modules, state, variables, lifecycle) is native Terraform functionality.
Terragrunt — a thin wrapper that reduces multi-environment boilerplate
Terragrunt doesn't replace any of that — it wraps the terraform CLI and adds features specifically aimed at large, multi-environment, multi-module setups:
# terragrunt.hcl in environments/prod/vpc/
terraform {
source = "git::https://github.com/my-org/modules.git//vpc?ref=v2.3.0"
}
include "root" {
path = find_in_parent_folders() # shares common backend/provider config
}
inputs = {
cidr_block = "10.0.0.0/16"
}
Key additions:
- DRY backend/provider configuration — instead of repeating an S3 backend block with slightly different keys in every environment's root module, a shared
root.hcl/parent config defines it once and every childterragrunt.hclinherits it. - Explicit inter-module dependencies — a
dependencyblock lets one Terragrunt module read another's outputs (e.g., the VPC module's ID) even though they're entirely separate Terraform state files, without manually wiringterraform_remote_statedata sources everywhere. run-allcommands —terragrunt run-all plan/applyoperate across many modules at once in dependency order, useful for large, decomposed infrastructure with many small state files (a best practice covered in the previous question) that would otherwise require manuallycd-ing into and applying each one.
When to reach for it
Teams adopt Terragrunt once a many-environment, many-module setup (following the "small, isolated state files" best practice) starts accumulating painful repetition in backend configuration and manual cross-module wiring that native Terraform doesn't solve cleanly on its own. It's strictly additive — every terragrunt.hcl ultimately still generates and runs standard Terraform underneath — not an alternative language or engine.
Interview-ready summary
Terraform is the engine; Terragrunt is orchestration tooling on top of it, addressing DRY configuration and cross-module dependency wiring at scale — not a replacement for Terraform itself. (The same framing generally applies to comparisons like Pulumi or CloudFormation, which are alternative engines with their own language/state models, unlike Terragrunt.)