5.2.2. Module Outputs and Composition
💡 First Principle: A module's outputs are the only values the caller can use, so composing modules means feeding one module's output into another's input — building larger systems by wiring small, well-defined contracts together.
A child module exposes results through output blocks; the caller reads them as module.<name>.<output>. Composition is the practice of connecting modules this way — for example, passing a network module's subnet_ids output into a compute module's subnet_ids input:
This keeps each module focused and lets you assemble infrastructure from reusable parts. The root module orchestrates by passing outputs as inputs, and the dependency between modules is implicit (just like resource references) because module.compute references module.network.subnet_ids.
The design habits that make composition work: give each module one responsibility (a network module builds the network, and the workloads that use it live in modules of their own); keep the module tree flat: HashiCorp recommends, in most cases, only one level of child modules wired together by the root, so every module's inputs and outputs are visible in one place instead of being threaded through intermediate layers, and modules stay easy to recombine; expose only the outputs callers need, since every output becomes interface they can depend on; and document the module: a README stating its purpose with a usage example, plus a description on every variable and output, which registry tooling turns into the inputs/outputs reference.
⚠️ Exam Trap: You can only reference a child module's declared outputs — not its internal resources. module.network.aws_subnet.app.id is invalid; the network module must expose subnet_ids (or similar) as an output first. This boundary is tested.
Reflection Question: How does passing one module's output into another's input create the correct ordering between the two modules, without any depends_on?
