Engineers struggle to trace where a value comes from because the root module calls a module that calls another module, four levels deep, and each level re-exports its child's outputs. Which refactoring does HashiCorp's module guidance favor?
Select an answer to reveal the explanation.
Short Explanation
Deep nesting is like Russian dolls: to find anything you open five layers. Keep the tree shallow and let the root module do the wiring, passing one module's outputs into the next module's inputs.
Full Explanation
HashiCorp's module composition guidance recommends keeping the module tree relatively flat and composing modules in the root module. Instead of each module calling and wrapping the next, the root module calls each building-block module directly and connects them by passing one module's outputs into another module's input variables, a pattern often described as dependency inversion. Every dependency then appears in one readable place, modules stay independently testable and reusable, and engineers can trace a value through a single hop rather than four layers of re-exported outputs. The depends_on argument controls operation ordering; it does not document or simplify the flow of values, and unnecessary explicit dependencies make plans more conservative. Merging everything into one large module removes the nesting by abandoning modularity, recreating a monolith with an oversized interface. Re-exporting every attribute at every level enlarges each module's contract and makes the tracing problem worse, because every layer now has more outputs that must stay stable. Exam caveat: some nesting is fine for tightly coupled internal submodules, but a shared building block should not hide other shared building blocks. Operational check: draw the module tree from the configuration and confirm no shared module calls another shared module after the refactor.