Terraform Associate (004): Terraform Modules

Topic snapshot

Sample questions

These questions are original IT Mastery practice items aligned to this topic area. They are designed for self-assessment and are not official exam questions.

Question 1

Topic: Terraform Modules

A team uses VCS-driven HCP Terraform workspaces for dev, stage, and prod. Each environment has its own root configuration, but the same application stack was created by copying and pasting identical resource blocks into all three directories. The team now wants one standardized pattern, easier maintenance when the stack changes, and normal plan review before apply. What is the best next step?

Options:

• A. Import each environment again to standardize the configuration.

• B. Use locals for shared values but keep separate resource blocks.

• C. Keep copied blocks and switch behavior with terraform.workspace.

• D. Extract a reusable module and reference a versioned source per environment.

Best answer: D

Explanation: The best solution is to move the repeated infrastructure into a reusable module. That gives the team one maintained implementation for all environments while preserving separate root configurations and normal HCP Terraform plan review.

Modules are Terraform’s built-in mechanism for reuse and standardization. When dev, stage, and prod each contain copied resource blocks, every change must be repeated in multiple places, which increases drift and maintenance risk. A child module lets the team define the shared application stack once and call it from each environment’s root module with different input values.

This approach fits all of the stated requirements:

• one standardized pattern
• easier updates in one place
• continued plan review before apply in the existing VCS-driven workflow

By contrast, workspaces help separate state and runs, locals reduce repeated expressions inside a configuration, and terraform import brings existing objects under management. None of those replaces copy-pasted resource definitions with a reusable implementation.

• Workspace confusion using terraform.workspace can change behavior, but it does not turn duplicated resource blocks into a shared reusable pattern.
• Locals only local values can reduce repeated expressions, but the resource blocks would still be copied in multiple places.
• Wrong purpose terraform import is for associating existing infrastructure with state, not for refactoring configuration for maintainability.

Question 2

Topic: Terraform Modules

A team reuses a registry module across several environments:

module "network" {
  source  = "appcorp/network/aws"
  version = "~> 2.4.0"
}

What is the main benefit of including the version argument in this module block?

Options:

• A. It pins the provider plugin versions used by the module.

• B. It keeps module selection predictable and reduces unexpected breaking changes.

• C. It stores the module’s resources in a separate state file.

• D. It automatically upgrades the module to any future major release.

Best answer: B

Explanation: Module version constraints tell Terraform which registry module releases are acceptable. That keeps runs more predictable across environments and helps prevent a newer module release from introducing breaking changes unexpectedly. Teams can then upgrade on purpose instead of by surprise.

In a module block, the version argument constrains which releases Terraform can install from a registry source. This matters for reused modules because teams depend on stable inputs, outputs, and behavior across environments. Without a constraint, a fresh working directory or an intentional upgrade can pull a newer module release, including one with breaking changes. By setting an allowed version range, teams make runs more predictable and choose when to test and adopt newer module versions.

Version constraints control acceptable module releases; they do not pin provider plugins or change how Terraform state is stored.

• Provider confusion fails because module version constraints do not lock provider plugin versions; provider version constraints handle that.
• Separate state fails because using a module does not create a separate state file for that module’s resources.
• Automatic major upgrades fails because version constraints are used to limit acceptable releases, not to allow all future breaking versions.

Question 3

Topic: Terraform Modules

Which Terraform construct should you use when you want to package the same group of resources once and reuse it across multiple configurations for consistency and clearer separation of infrastructure patterns?

Options:

• A. A provider configuration

• B. A backend block

• C. A workspace

• D. A module

Best answer: D

Explanation: Use a module when you need reusable infrastructure building blocks. Modules let you define a repeated resource pattern once, then call it from multiple configurations with variables and outputs for consistent implementation.

A Terraform module is a container for multiple resources that are used together. It is the standard way to reuse a repeated infrastructure pattern, such as a network, application tier, or security baseline, across teams or environments while keeping configuration organized. A module accepts input variables, creates the needed resources, and can return output values to the calling configuration.

• Package the repeated pattern once.
• Call it from different configurations as needed.
• Keep behavior more consistent across deployments.

Providers, backends, and workspaces each solve different Terraform problems, but none of them are the main construct for reusable infrastructure design.

• The option about a provider configuration fails because providers define how Terraform talks to APIs, not how repeated resources are packaged.
• The option about a backend block fails because backends manage where state is stored and locked, not reusable infrastructure patterns.
• The option about a workspace fails because workspaces separate state instances, but they do not define reusable resource groupings.

Question 4

Topic: Terraform Modules

A team uses the same root module in HCP Terraform workspaces for dev, stage, and prod. Each run starts from a fresh working directory. Their shared Registry module currently looks like this:

module "network" {
  source     = "acme/network/aws"
  cidr_block = var.cidr_block
}

They have already validated the 2.4.x module line. The publisher just released 3.0.0 with breaking input changes. The team wants predictable builds across environments and to adopt module updates only through reviewed pull requests. Which change best meets these requirements?

Options:

• A. Run terraform init -upgrade in each workspace

• B. Add version = "~> 2.4.0" to the module block

• C. Copy the module into each environment directory

• D. Rely on .terraform.lock.hcl to pin the module version

Best answer: B

Explanation: A module version constraint makes the allowed Registry module release line explicit in configuration. In fresh HCP Terraform runs, that keeps dev, stage, and prod on the same reviewed 2.4.x range and prevents an unexpected 3.x upgrade without a pull request.

Module version constraints are how Terraform keeps reused Registry modules predictable. In this scenario, each HCP Terraform run initializes from scratch, so the configuration must declare which module versions are acceptable. Using version = "~> 2.4.0" means Terraform can use 2.4.x releases, but not 2.5 or 3.0.0, which protects the team from unintended breaking changes while still allowing compatible patch updates.

When the team is ready to move to a newer module line, they update the constraint in version control and review that change through the normal workflow. This supports cross-environment consistency because all workspaces evaluate the same version rule from the same configuration. The closest distraction is the lock file, but Terraform lock files apply to providers, not module versions.

• Lock file confusion fails because .terraform.lock.hcl records provider selections, not Registry module versions.
• Forced upgrades with terraform init -upgrade seeks newer allowed versions instead of preventing unexpected module changes.
• Copying code locally removes centralized module reuse and makes environment drift more likely over time.

Question 5

Topic: Terraform Modules

A teammate wants to reuse a shared module and shows you this configuration:

module "network" {
  source = "git::https://example.com/platform/iac-modules.git//modules/vpc?ref=v1.2.0"
}

Which interpretation of the source value is correct?

Options:

• A. It uses a local module path named modules/vpc.

• B. It uses a public registry module at version v1.2.0.

• C. It uses a Git repo subdirectory pinned to v1.2.0.

• D. It uses an HCP Terraform private registry module.

Best answer: C

Explanation: This is a valid Git-based module source. The git:: prefix tells Terraform to fetch from Git, //modules/vpc selects a subdirectory in that repository, and ?ref=v1.2.0 pins the module to a specific Git ref.

Terraform modules can be sourced from local paths, registry addresses, and supported version-control repositories. In this snippet, the decisive clue is the git:: prefix, which means Terraform will download the module from a Git repository. The //modules/vpc portion does not indicate a local path; it tells Terraform to use a subdirectory inside the cloned repository. The ref query parameter selects the branch, tag, or commit to use.

By contrast, a local module source looks like ./modules/vpc or ../modules/vpc, and a registry source looks like namespace/name/provider or a hostname-prefixed private registry address. The key skill is recognizing the source format so you know how Terraform will retrieve the module.

• Registry confusion fails because registry modules use registry addresses, and versions are typically set with a separate version argument.
• Local path confusion fails because local sources use filesystem paths like ./modules/vpc; here, //modules/vpc selects a Git repo subdirectory.
• Private registry confusion fails because HCP Terraform private registry modules use registry-style addresses, not a git::https://...git URL.

Question 6

Topic: Terraform Modules

A cloud engineer runs terraform plan from the root module and reviews this configuration:

# root/main.tf
module "app" {
  source = "./modules/app"
}

output "instance_size" {
  value = var.instance_size
}

# modules/app/variables.tf
variable "instance_size" {
  type = string
}

Assume no other files define instance_size. What is the best next step to make this work?

Options:

• A. Change the output to module.app.var.instance_size.

• B. Run terraform init so the root inherits child variables.

• C. Declare instance_size in root and pass it to module "app".

• D. Set instance_size only in terraform.tfvars for both modules.

Best answer: C

Explanation: The variable "instance_size" block inside modules/app creates an input only for that child module. It does not make var.instance_size available in the root module, so the root must declare its own variable and pass the value into the module explicitly.

Terraform input variables are scoped per module. In the snippet, modules/app/variables.tf declares an input that code inside the child module can reference as var.instance_size. The root module is a separate scope, so its output block cannot use var.instance_size unless the root also declares that variable.

To send a value into a child module, the calling module must pass it explicitly in the module block. A common pattern is to declare the variable in the root module, set its value with a .tfvars file, environment variable, or CLI option, and then map it into the child module. If the root needs a value back from the child, the child must expose an output and the root reads module.app.<output_name>.

The key takeaway is that child-module input variables are not automatically visible to the root module.

• Referencing module.app.var.instance_size fails because a module exposes outputs, not its internal input-variable namespace.
• Using terraform.tfvars alone does not populate child module variables automatically; values must still be passed through the module block.
• Running terraform init installs modules and providers, but it does not change variable scope rules.

Question 7

Topic: Terraform Modules

In Terraform, what does the source argument inside a module block specify?

Options:

• A. Where the module’s state file will be stored

• B. Which input variables the module is allowed to accept

• C. Where Terraform should obtain the reusable module code

• D. Which provider version the module must use

Best answer: C

Explanation: The source argument identifies where Terraform gets a module’s code from. It is about locating reusable module code, not about provider versions, state storage, or the module’s variable definitions.

In a Terraform module block, source tells Terraform where to read or download the reusable module code. Common sources include a local filesystem path, the Terraform Registry, a private registry, or a version control source such as Git. Terraform resolves that module source during terraform init when it installs required modules.

The source argument does not control provider version selection, backend or state storage, or the list of variables a module can accept. Provider versions are defined in provider requirements, state location is controlled by backend configuration, and module inputs are defined inside the module itself. The key idea is that source answers one question: where does this module come from?

• Provider confusion misses that provider versions are set separately from module location.
• State confusion fails because state storage is controlled by the backend, not by a module’s source.
• Variable confusion is incorrect because input variables are defined by the module author and passed as arguments in the module block.

Question 8

Topic: Terraform Modules

A team wants the root module to use the ID of a resource created inside a child module.

# root module
module "network" {
  source     = "./modules/network"
  cidr_block = "10.0.0.0/16"
}

output "network_id" {
  value = module.network.vpc_id
}

# modules/network/main.tf
resource "aws_vpc" "main" {
  cidr_block = var.cidr_block
}

Based on this configuration, what is the correct way for the child module to expose the VPC ID to its caller?

Options:

• A. Add variable "vpc_id" {} to modules/network.

• B. Add locals { vpc_id = aws_vpc.main.id } to modules/network.

• C. Add output "vpc_id" { value = aws_vpc.main.id } to modules/network.

• D. Reference aws_vpc.main.id directly from the root module.

Best answer: C

Explanation: Terraform uses outputs as the supported interface for returning selected values from a child module to its caller. Since the root module references module.network.vpc_id, the child module must declare an output with that name.

In Terraform, module boundaries define scope. Input variables send values into a module, while output values expose selected results back to the caller. In this example, the root module is trying to read module.network.vpc_id, but the child module currently defines only a resource, not an exported value.

To make that reference valid, the child module needs an output such as:

output "vpc_id" {
  value = aws_vpc.main.id
}

The caller can then use module.network.vpc_id in its own outputs, resources, or expressions. By contrast, resources and locals inside the child module remain internal to that module. The key takeaway is that outputs form the public interface of a module.

• Variable direction A variable named vpc_id would accept input into the child module, not send a value back out.
• Direct resource access The root module cannot reference a resource declared inside a child module.
• Local scope A local value can simplify expressions inside the child module, but it is not exported to callers.

Question 9

Topic: Terraform Modules

A platform team published a standard network configuration to the HCP Terraform private registry. An application team needs to use the same configuration in dev, stage, and prod, keep the module version pinned, and review changes through normal Terraform plans. What is the best next step in the root configuration?

Options:

• A. Add a data block to pull the shared network configuration from the registry.

• B. Add resource blocks for the network components in each environment configuration.

• C. Add a terraform block to declare the module source and required version.

• D. Add a module block that references the registry source and pins a module version.

Best answer: D

Explanation: To use reusable Terraform configuration from a registry, Git repository, or local path, the root module must call it with a module block. That supports consistent cross-environment reuse, version pinning, and normal plan/apply review.

Terraform modules are the mechanism for packaging reusable configuration. When a team wants the same infrastructure pattern across multiple environments, the root module should instantiate that reusable package with a module block. The block specifies the module source, can pin a registry version, and passes environment-specific input values. Terraform then evaluates that module as part of the usual plan and apply workflow, so changes stay reviewable and tracked in state.

resource blocks define infrastructure objects directly, data blocks read existing information, and terraform blocks configure settings such as required Terraform versions, providers, or backends. The key takeaway is that reusable configuration is consumed through a module block.

• Direct resources create infrastructure, but they duplicate code instead of reusing a shared module.
• Data lookup reads existing information; it does not instantiate reusable Terraform configuration.
• Terraform settings control Terraform behavior and requirements, not module calls.

Question 10

Topic: Terraform Modules

A team has copied the same resource blocks into six Terraform configurations. They want one shared implementation so future changes are made once, while each configuration can still pass a few different values. Which Terraform approach best meets this maintainability and standardization goal?

Options:

• A. Put the repeated resources in terraform.tfvars.

• B. Keep the copies and run terraform fmt after each edit.

• C. Move the repeated resources into a reusable child module.

• D. Use separate workspaces for the copied configurations.

Best answer: C

Explanation: A reusable child module is Terraform’s standard way to define a set of resources once and call it many times. That improves maintainability because updates happen in one place, while input variables let each configuration customize needed values.

Terraform modules are the standard mechanism for reuse and standardization. You place the shared resource definitions in a child module, then call that module from one or more root modules, passing different input variables for environment-specific details such as names, tags, or CIDR ranges. This keeps the implementation in one location, reduces copy-and-paste drift, and makes future updates easier because each caller uses the same underlying pattern.

• Modules package related resources for reuse.
• Input variables let each caller customize values without changing the shared logic.
• Copying resource blocks increases maintenance effort and inconsistency risk.

Formatting commands and state-isolation features are useful, but they do not replace reusable module-based design.

• terraform fmt only standardizes file formatting; it does not centralize duplicated resource logic.
• Workspaces separate state for a configuration, but they do not turn copied blocks into a shared implementation.
• terraform.tfvars provides variable values, not reusable resource definitions.

Continue with full practice

Use the Terraform Associate (004) Practice Test page for the full IT Mastery route, mixed-topic practice, timed mock exams, explanations, and web/mobile app access.

Try Terraform Associate (004) on Web View Terraform Associate (004) Practice Test

Related focused pages

• Free Terraform Associate (004) Full-Length Practice Exam
• IaC with Terraform
• Terraform Fundamentals
• Core Terraform Workflow
• Terraform Configuration
• Terraform State Management
• Terraform Maintenance
• HCP Terraform

Free review resource

Read the Terraform Associate (004) Cheat Sheet on Tech Exam Lexicon, then return to IT Mastery for timed practice.