Databricks on AWS Terraform Layout: Terragrunt, YAML, Atlantis

Closing out a five-part Databricks on AWS series, this piece explains the Terraform architecture behind the previously described workspaces, RBAC, and compute setup. The repo splits into reusable, environment-agnostic Terraform modules and per-environment (dev/prd) trees that decide which modules run with which values. The standout design choice is that engineers only ever edit YAML, not HCL: Terragrunt decodes the YAML and injects an environment prefix before passing values to modules, removing humans from the risk of cross-environment naming collisions.

Because each Databricks workspace has its own API host, Terragrunt auto-generates a provider override per workspace layer, using an account-level (mws) provider for account-wide resources and a workspace-scoped provider for in-workspace resources — mixing the two is flagged as a common source of confusing auth errors.

The article also highlights a subtle Terragrunt gotcha: dependency blocks with mock_outputs simplify planning, but omitting "init" from mock_outputs_allowed_terraform_commands causes the very first plan on a fresh tree to fail with a "no outputs" error, since real state doesn't exist yet. This makes strict apply ordering (workspace → pool → policy → compute → assignment/acls, and a parallel Unity Catalog chain) a hard requirement on day one, not a suggestion. Finally, all changes flow through Atlantis-driven merge requests rather than local terraform apply, giving teams a reviewable, GitOps-style change process for the whole platform.