Study HashiCorp Terraform 004 Module Sources: key concepts, common traps, and exam decision cues.
Modules let you package Terraform configuration so it can be reused cleanly. The exam expects you to know where modules come from and how callers interact with them through inputs and outputs.
| Module concept | What it means |
|---|---|
| source | where the module code comes from |
| input variables | values passed into the module |
| outputs | values the module returns |
| local module versus registry module | local path reuse versus published reusable package |
| Interface element | Why the exam cares |
|---|---|
| variables | show what the module expects from callers |
| outputs | show what the module exposes back to callers |
| internal resources | should not be confused with the public interface |
| Trap | Better rule |
|---|---|
| thinking a module is the same as a workspace | modules package code; workspaces separate state |
| treating every internal resource as part of the module interface | the interface is mainly variables in and outputs out |
| assuming module source always means the registry | modules can be local or remote |
Module questions usually test reuse boundaries. First, ask whether the scenario is about packaging repeated configuration. Second, identify the module interface as inputs and outputs rather than internal resources. Third, keep modules separate from workspaces and state strategy. The exam usually rewards the answer that preserves reusable contracts instead of duplicating code.