Memory hook: Inputs in; outputs out; versions explicit.
Must remember
A module is a directory of Terraform configuration. The directory where you execute Terraform is the root module; its module blocks call child modules. File names such as main.tf are conventions: Terraform loads the directory’s configuration together.
A child module has its own variable scope. It cannot read a root variable simply because the name matches. Pass region = var.region or another explicit argument; read results through module.network.subnet_ids when the child declares that output.
Module sources may be local paths, registry addresses, version-controlled repositories or supported archives. Registry modules support the version argument. A Git source can pin a tag or commit with ?ref=...; a local module has no independently downloaded version. Rerun init after changing module sources or selected versions.
Prefer small modules that expose useful architecture choices and compose through outputs. Do not put provider configuration inside a reusable module when the caller should control accounts and regions. Provider requirements belong in the child; provider configurations normally come from the root.
Recall drill: sketch two calls to the same VPC module, with different CIDRs. Explain why their resource addresses differ and why their input values do not leak into each other.
Choose under exam pressure
| Requirement | Choice and reason |
|---|---|
| Reuse a network pattern | Call a module with explicit inputs and consume its outputs. |
| Repeatable remote module source | Pin a registry version or immutable Git commit. |
Traps
- The provider lock file does not pin a registry module.
- A module is a code boundary, not automatically a state or security boundary.
Active recall
1. Can a child directly read var.region from its parent?
Only if the caller passes a value to an input declared by the child.
2. How do you read a child result?
Declare an output in the child and reference module.
3. Does every module have separate state?
No. Child modules are recorded within the root module’s state.
4. How do you pin a Git module?
Use a source reference to a specific tag or, more strictly, commit.
5. Where should reusable-module provider settings usually live?
In the root caller, passed or inherited by the child as appropriate.