Explicit Wiring
Think of Terragrunt as a general contractor who reads the blueprints (your Terraform modules) and decides in what order to call the subcontractors. The subcontractors (Terraform) do the actual work; the general contractor manages the sequence.
Terragrunt is the industry-standard open-source wrapper for Terraform. Its killer feature is the dependency block, which lets you declare that one stack must complete before another begins — and automatically passes outputs between them.
In plain Terraform, you use data "terraform_remote_state" to read outputs from another state file. This works, but Terraform Core has no concept of "Stack A must run before Stack B." It will happily try to read outputs from a state file that doesn't exist yet and fail. Terragrunt solves this by lifting the dependency logic out of .tf code and into a dedicated configuration layer (terragrunt.hcl).
A typical layout has one directory per stack — vpc, db, app — each with its own terragrunt.hcl. The app stack's config declares a dependency block for each stack it needs, naming where to find that stack's config and a set of fake placeholder outputs for use before the real dependency exists, then references those dependencies' real outputs directly as its own inputs. When Terragrunt reads this file, it knows: "Before I can apply app, I must first apply vpc and db." The outputs reference is what creates the link — Terragrunt reads the remote state of the dependency after it completes and injects those values as inputs to the current module.
The run-all Command
Because you explicitly defined the links, a single command at the root folder lets Terragrunt handle everything: scan every subdirectory for a terragrunt.hcl file, build the dependency graph from every dependency block it finds, and execute in topological order with maximum parallelism — the VPC stack first since it has no dependencies, the database stack in parallel once the VPC completes, and the application stack last since it depends on both. The equivalent commands for other lifecycle operations (plan, destroy) work the same way, with one important twist: destroy runs in reverse dependency order.
The destroy reversal is automatic and critical — Terragrunt knows that to safely tear down infrastructure, you must remove dependents before dependencies (remove app before db, remove db before vpc).
Interviewers frequently ask: "How do you manage dependencies between Terraform stacks?" A weak answer is "we use terraform_remote_state data sources." A strong answer explains the limitation — Terraform Core has no execution ordering concept — and then describes how Terragrunt's dependency block solves it by building a DAG and executing run-all in topological order. Mention that run-all destroy automatically reverses the graph, which demonstrates you understand the full lifecycle, not just creation.