Study HashiCorp Terraform 004 Module Versions: key concepts, common traps, and exam decision cues.
Using a module is easy. Using a module safely is what the exam actually cares about. HashiCorp expects you to understand version constraints, caller-module boundaries, and why external module upgrades should not be left wide open by accident.
| Need | Strongest first fit |
|---|---|
| reuse shared Terraform logic | call a module |
| make upgrades predictable | constrain module versions |
| pass values into module behavior | use module input variables |
| consume values from a module | use module outputs |
| Version choice | Risk profile |
|---|---|
| no version constraint on an external module | less predictable future behavior |
| bounded version constraint | safer controlled upgrades |
| exact version pin | maximum predictability, less flexibility |
| Trap | Better rule |
|---|---|
| assuming the provider lock file pins module versions | it does not; module versioning is separate |
| leaving external module versions unconstrained | safer defaults usually bound or pin module versions |
| treating module inputs like global variables everywhere | input values still belong to the caller-module interface |
When using shared modules, keep two ideas separate. Version constraints make external module upgrades predictable. The provider lock file does not pin external module versions. Child modules receive values through variables and return useful values through outputs. Terraform Associate questions often test whether you accidentally blur provider dependency locking with module version management.