In Terraform, what are the consequences of putting `depends_on` on a `module` block instead of wiring modules together through their outputs?

## Two ways to order work Terraform decides ordering from a dependency graph it builds by reading references. When the root writes `subnet_ids = module.network.private_subnet_ids`, that reference *is* the edge: the database resources that consume those ids wait for the subnets, and nothing else does. This is an **implicit** dependency, and it is precise because it connects the specific objects that exchange the value. `depends_on` is the **explicit** escape hatch. Available on `module` blocks since Terraform 0.13, it accepts static references to resources, data sources and other modules — not arbitrary expressions: ```hcl module "app" { source = "./modules/app" depends_on = [module.network] } ``` ## What that edge actually means It is not "start this module a bit later". Terraform treats every object declared inside `module.app` as depending on every object inside `module.network`. Three consequences follow. **Parallelism collapses.** Resources in the module that had nothing to do with the network — an SNS topic, a log group — now wait for the last network resource to finish. On a large module that is real wall-clock time added to every apply, and on destroy the ordering reverses and drags the same way. **The reason disappears from the code.** An input variable says *what* is shared. `depends_on = [module.network]` says only *that* something is. Six months later nobody can tell whether it is still needed, and because removing it is untestable except by applying, it never gets removed. **Plans become vague.** This is the consequence that bites daily. A data source whose dependencies might change cannot be safely read during plan, so Terraform defers reading it until apply. Any data source inside a module carrying `depends_on` is a candidate, and everything computed from it becomes `(known after apply)`. You approve a plan that no longer shows the values you were reviewing — which is exactly the thing a plan exists to prevent. ## When it is the right tool The legitimate case is a **behavioural** dependency: module B does not consume any value from A, but will fail or misbehave at runtime unless A exists. The canonical example is IAM — an instance profile's policy must be attached before the instance boots and calls the API, yet nothing in the instance's arguments references the policy. There is no value to pass, so no implicit edge exists, and `depends_on` is the honest expression of it. Even then, prefer the smallest scope that works. Putting `depends_on` on the single resource inside the module that has the behavioural need costs you far less than putting it on the module block, because only that resource is serialised and only its dependents lose plan-time detail. ## The refactor that usually removes it Most module-level `depends_on` in real repositories is a workaround for a module that builds or looks up its own dependency. If the app module calls a data source to find "the" VPC by tag, it has no reference to the network module and therefore needs a manual edge. Invert it: have the module take `vpc_id` and `subnet_ids` as inputs and let the root pass `module.network.vpc_id`. The manual edge disappears, the data source disappears, the plan becomes concrete again, and the module becomes usable against a network it did not create. ```hcl # preferred: the reference is the dependency module "app" { source = "./modules/app" subnet_ids = module.network.private_subnet_ids } ``` ## One hard incompatibility A module that declares its own provider configuration cannot use `depends_on` at all — the same restriction that blocks `count` and `for_each` on such modules. If you meet that error, the module needs its `provider` block removed and its provider configurations passed in by the caller. ## What an interviewer is listening for Weak answers describe `depends_on` as "how you control order in Terraform", which suggests the candidate has never relied on implicit edges. Strong answers state the default (pass the value), name the specific costs of the module-scoped edge — lost parallelism, an undocumented relationship, and `(known after apply)` swallowing the plan — and can give the one class of case, behavioural dependencies with no value to exchange, where it is correct.