Terraform Associate Domain 5: Terraform modules (Not published)

Overview

Terraform modules covers packaging configuration for reuse. It has four objectives. Explaining how Terraform sources modules covers where modules come from, local paths, the Terraform Registry, Git and other sources. Describing variable scope covers how input variables and outputs form a module's interface and how values pass between a calling configuration and a module. Using modules covers calling a module, passing inputs and consuming outputs. Managing module versions covers pinning module versions for registry and versioned sources to ensure stable, predictable reuse.

Modules are how Terraform configuration is made reusable and maintainable. The exam rewards understanding where modules are sourced from, how variables and outputs define a module's interface and scope, how to call modules and pass data, and how to pin module versions. These concepts build on the configuration domain and apply in real projects of any size.

Why it matters on the exam

Modules are central to real Terraform use and a distinct, testable topic. The exam tests how modules are sourced, scoped, used and versioned. Candidates lose points by misunderstanding module sources, by not grasping that a module's variables and outputs are its only interface and that variable scope is local to the module, by passing data incorrectly between calling configuration and module, or by not pinning module versions, risking unexpected changes. Understanding modules as reusable, versioned, interface-bound units of configuration is the skill this domain rewards. Module questions test where a value is visible and how a source is versioned, so building a small module and calling it from a root configuration is what makes the scoping rules stick.

How it's tested

Terraform Associate questions in this domain test how modules are sourced, their variable scope, how to call them, and how to version them. Module questions often show a module block, so check its source, its version argument and the inputs and outputs passed across the module boundary.

Module source

A reuse need is described, and you choose the module source type.
Module interface and scope

A data-passing need is described, and you choose inputs, outputs and scope.
Module versioning

A stability need is described, and you choose module version pinning.

Reasoning it through

A team reuses a shared module from the Terraform Registry across many projects and wants a provider upgrade to the module not to change their infrastructure unexpectedly. Referencing the module without a version lets it change. Pinning the module to a specific version with a version argument ensures each project uses a known, stable module version until the team deliberately upgrades, which is the versioning practice the exam expects.

Objectives 4

Official objectives from the HashiCorp outline, in outline order.

5a Explain how Terraform sources modulesLocal paths, the registry, Git and other module sources.

What it means: This covers where Terraform gets modules: local file paths, the public Terraform Registry and private registries, Git repositories, and other supported sources, specified in the module's source argument.
What to understand: A module call's source argument tells Terraform where to find the module. Local paths reference modules in the same project, the registry hosts shareable versioned modules, and Git and other sources fetch from repositories. The source type affects whether versioning is available.
How it shows up: A module-reuse need is described, and you must choose the source type.
Common confusion: Confusing a local module source with a registry source; local paths are for in-project modules, while the registry hosts shareable versioned modules.

5b Describe variable scope within modulesHow inputs and outputs form a module's interface.

What it means: This covers variable scope: a module's input variables and output values are its interface, variables are local to the module, and data passes in through inputs and out through outputs between the calling configuration and the module.
What to understand: A module is a black box with a defined interface: it receives input variables and returns outputs. Variables are scoped to the module, not globally shared, so the calling configuration passes values in and reads outputs back. This encapsulation is what makes modules reusable.
How it shows up: A data-passing or scope question is posed, and you must apply module variable scope.
Common confusion: Expecting variables to be globally shared across modules; variables are scoped to their module and passed explicitly.

5c Use modules in configurationCalling a module and passing inputs and outputs.

What it means: This covers calling a module with a module block, passing input variables to it, consuming its output values in the calling configuration, and composing configuration from multiple modules.
What to understand: A module block references the source and supplies input variable values. The module's outputs are then available to the calling configuration as references. Modules can be composed and reused multiple times with different inputs, structuring larger configurations cleanly.
How it shows up: A module-usage need is described, and you must call the module and pass data correctly.
Common confusion: Not passing required inputs or not referencing module outputs correctly from the calling configuration.

5d Manage module versionsPinning module versions for stable reuse.

What it means: This covers managing module versions by specifying a version argument for registry and versioned sources, using version constraints to pin or bound the version, so module upgrades are deliberate and reuse is stable and predictable.
What to understand: For registry and other versioned sources, the version argument pins the module version with constraints, just as provider versions are pinned. This prevents an unexpected module change from altering infrastructure and makes reuse reproducible. Version pinning is a best practice for shared modules.
How it shows up: A stability or upgrade need is described, and you must pin the module version.
Common confusion: Omitting a version constraint on a registry module, allowing unexpected upgrades.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

Module source argument

Tells Terraform where to find a module.

Remember
Local, registry, Git and more.

Tested as
Source questions.

Trap
Confusing source types.
Local module

A module in the same project by path.

Remember
For project-internal reuse.

Tested as
Source questions.

Trap
Confusing with the registry.
Terraform Registry

Hosts shareable versioned modules.

Remember
Supports version pinning.

Tested as
Source questions.

Trap
Expecting versioning from local paths.
Module interface

Input variables and output values.

Remember
The module's only interface.

Tested as
Scope questions.

Trap
Expecting global variable sharing.
Variable scope

Variables are local to the module.

Remember
Pass data in explicitly.

Tested as
Scope questions.

Trap
Assuming global scope.
Module block

Calls a module with inputs.

Remember
References source and inputs.

Tested as
Usage questions.

Trap
Omitting required inputs.
Module outputs

Values the module returns.

Remember
Consumed by the caller.

Tested as
Usage questions.

Trap
Not referencing outputs correctly.
Module composition

Combining multiple modules.

Remember
Reuse with different inputs.

Tested as
Usage questions.

Trap
Duplicating configuration instead.
Module version argument

Pins the module version.

Remember
For registry and versioned sources.

Tested as
Versioning questions.

Trap
Omitting it on registry modules.
Version constraints

Bound the allowed module version.

Remember
Make upgrades deliberate.

Tested as
Versioning questions.

Trap
Allowing unexpected upgrades.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

Local vs. registry module source

Concept	Meaning	Key difference	Common trap
Local path	Module in the same project	No versioning	Expecting version pinning
Registry	Shareable hosted modules	Supports version pinning	Confusing with local

Module inputs vs. outputs

Concept	Meaning	Key difference	Common trap
Input variables	Values passed into the module	The module's parameters	Confusing with outputs
Output values	Values the module returns	Consumed by the caller	Confusing with inputs

Pinned vs. unpinned module version

Concept	Meaning	Key difference	Common trap
Pinned version	Fixed with a constraint	Stable, deliberate upgrades	Omitting on registry modules
Unpinned version	No version constraint	Risk of unexpected changes	Using for shared modules

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

No module version

What candidates pick
Reference a registry module without a version argument for a shared, reused module.

Why it looks right
It works without one.

Why it's wrong
Pinning the module version ensures stable, reproducible reuse and prevents unexpected changes from an upgrade.

Clue to watch for The module is shared and must not change unexpectedly.
Global variables

What candidates pick
Expect a variable defined in the root to be automatically available inside a module.

Why it looks right
It seems convenient.

Why it's wrong
Module variables are scoped to the module; values must be passed in explicitly through the module block.

Clue to watch for Data must move between the calling configuration and a module.
Local for sharing

What candidates pick
Use a local path to share a module across many separate projects.

Why it looks right
Local paths are simple.

Why it's wrong
The Terraform Registry or a versioned source is suited to sharing modules across projects with version control; local paths are for in-project reuse.

Clue to watch for A module must be shared and versioned across projects.
Ignore module outputs

What candidates pick
Expect to read a module's internal resource attributes directly from the caller.

Why it looks right
The resources exist in the module.

Why it's wrong
Only the module's declared outputs are accessible to the caller; internal attributes are encapsulated.

Clue to watch for The caller needs a value from inside a module.
Missing required input

What candidates pick
Call a module without supplying its required input variables.

Why it looks right
Defaults might cover it.

Why it's wrong
Required input variables must be supplied in the module block, or the configuration is invalid.

Clue to watch for The module declares required variables.

Answer framework

For any Domain 5 scenario, use these steps to find the answer the exam expects.

Choose the module source for the reuse need: a local path for in-project reuse, or the registry or a versioned source for sharing across projects.
Treat the module's input variables and outputs as its only interface, remembering variables are scoped to the module.
Call the module with a module block, passing required inputs and referencing its outputs from the calling configuration.
Compose configuration from multiple modules, reusing them with different inputs rather than duplicating code.
Pin module versions with the version argument for registry and versioned sources so upgrades are deliberate and reuse is stable. Where two module sources seem to fit, prefer the one whose version can be pinned, such as the public or a private registry.

Practice question

A team reuses a module from the Terraform Registry across many projects and wants to ensure that a new release of the module does not unexpectedly change their infrastructure. What should they do when calling the module?

Reference the module without specifying a version Specify a version argument to pin the module to a known version Copy the module's code into each project Use a local path instead of the registry

Show the answer

Answer B. Specifying a version argument pins the registry module to a known version, so each project keeps using that stable version until the team deliberately upgrades, preventing unexpected infrastructure changes from a new release. Referencing without a version allows unexpected upgrades, copying the code loses the benefits of a shared versioned module, and switching to a local path abandons the registry and its versioning rather than solving the stability need.

Want more like this? The Terraform Associate practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Approach this domain as learning how configuration becomes reusable. Start with module sources, distinguishing local paths for in-project reuse from the registry and versioned sources for sharing across projects, since the source affects versioning. Then master the module interface and scope: a module is a black box whose input variables and outputs are its only interface, and variables are scoped to the module and passed explicitly.

Practice calling modules, passing required inputs and consuming outputs, and composing several modules. Finally, learn module version pinning, which parallels provider versioning, to keep shared modules stable and upgrades deliberate.

Building and calling your own small module makes these concepts concrete. Build a module with inputs and outputs, call it twice with different values, and review missed practice questions by objective. Afterwards, move to Domain 6, Terraform state management. Because the exam rewards practical familiarity, write small configurations and run the workflow in a demo environment rather than only reading, and review missed practice questions by objective to find weak spots.

FAQ

How does Terraform source modules?

Through the module block's source argument, which can point to a local path, the public or a private Terraform Registry, a Git repository, or other supported sources.

What is a module's interface?

Its input variables and output values. The calling configuration passes values in through inputs and reads results through outputs, and the module's internals are otherwise encapsulated.

Are module variables globally shared?

No. Variables are scoped to the module in which they are declared. Data must be passed explicitly from the calling configuration into the module through its input variables.

How do I use a module in my configuration?

Add a module block that references the source, supply the required input variables, and reference the module's outputs where you need its results in the calling configuration.

Why pin module versions?

Pinning a registry or versioned module's version with the version argument keeps reuse stable and reproducible, so a new module release does not unexpectedly change your infrastructure until you deliberately upgrade.

What is the difference between a local and a registry module?

A local module is referenced by a file path within the same project and is not versioned. A registry module is hosted for sharing and supports version pinning across projects.

How does Domain 5 connect to the rest of the exam?

Modules organize the configuration of Domain 4, are deployed with the workflow of Domain 3, and their resources are tracked in the state of Domain 6.

Related domains

Other Cloud Computing certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Terraform Associate Domain 5: Terraform modules

Overview

How it's tested

Module source

Module interface and scope

Module versioning

Objectives 4

High-yield concepts

Module source argument

Local module

Terraform Registry

Module interface

Variable scope

Module block

Module outputs

Module composition

Module version argument

Version constraints

Side by side

Local vs. registry module source

Module inputs vs. outputs

Pinned vs. unpinned module version

Exam traps

No module version

Global variables

Local for sharing

Ignore module outputs

Missing required input

Answer framework

Practice question

Checklist

Study strategy

FAQ

Other Cloud Computing certifications

Test your Domain 5 knowledge

Keep going