Terraform modules explained (for the 004 exam)

Modules are how Terraform scales from a single file to reusable, maintainable infrastructure — and they are a named objective on the 004. The good news: the concepts are simple once you have written one.

What a module is

A module is just a folder of Terraform configuration. The directory you run commands in is the root module; any module it calls is a child module. Modules let you package a pattern once (say, a network or a database) and reuse it with different inputs, which keeps configuration DRY and consistent.

Inputs and outputs

A module exposes input variables (its parameters) and outputs (values it returns to the caller). You pass values in when you call the module, and you read its outputs to wire modules together. Knowing how data flows in and out is the heart of the modules objective.

Calling a module

You call a module with a module block and a source argument. The source can be a local path, a Git repository, or a registry address. For remote modules you should also pin a version so upgrades are deliberate.

• Local: source = "./modules/network"
• Registry: source = "terraform-aws-modules/vpc/aws" with a version constraint

The registry and versioning

The public Terraform Registry hosts community and verified modules; HCP Terraform adds a private registry for your organisation. Use version constraints (for example ~> 5.0) so a module upgrade never surprises you mid-apply. Expect the exam to test source types and why version pinning matters.

Handy things to know for the exam

• count and for_each work on module blocks, not just resources.
• Child modules do not automatically see the root module's providers unless configured.
• Outputs are the only way a caller reads values from a child module.

Write one module, call it twice with different inputs, and read its outputs — then the objective is done. Reinforce with the study plan and a good course.