TF-003 Interact with Terraform modules Practice Test 1 — 15 Questions

Question 1

A team is using a module from the public Terraform Registry. They want to ensure that the module is pinned to a specific version to avoid unexpected changes. Which approach should they use?

Accepted Answer

Set 'version' in the module's source attribute, e.g., source = "terraform-aws-modules/vpc/aws" with version = "3.2.0".. Option C is correct because the Terraform Registry module syntax requires the version constraint to be specified as a separate argument within the module block, not embedded in the source string. Pinning to a specific version (e.g., "3.2.0") ensures that only that exact module version is used, preventing unexpected changes from upstream updates. This is the standard approach for versioning public registry modules in Terraform.

Answer

Use 'required_providers' block in the root module to lock the module version.

Answer

Add a 'version' argument inside the module block.

Answer

Store the module locally in a vendor directory and reference it by path.

Question 2

An engineer is refactoring a monolithic Terraform configuration into reusable modules. One module outputs a list of subnet IDs. Another module needs to use these subnet IDs to create resources. What is the best way to pass this data between modules?

Accepted Answer

Output the subnet IDs from the first module and reference that output as an input variable in the second module's block.. Option D is correct because Terraform modules communicate through explicit input and output variables. By outputting the subnet IDs from the first module and then referencing that output as an input variable in the second module's block, you create a clear, versionable, and dependency-aware data flow. This approach avoids hidden dependencies and ensures Terraform can properly graph the resource dependencies for parallel execution.

Answer

Use a Terraform data source in the second module to query the subnets directly.

Answer

Define the subnet IDs as a variable in the first module and pass them to the second module via a remote state data source.

Answer

Store the subnet IDs in a local file and use the 'file' function to read them in the second module.

Question 3

A developer creates a module that provisions an AWS EC2 instance and an S3 bucket. The module outputs the instance ID and bucket ARN. When using this module, the root configuration references module.my_module.instance_id and module.my_module.bucket_arn. After running terraform apply, they notice that the bucket ARN is empty. What is the most likely cause?

Accepted Answer

The output value in the module is defined incorrectly, e.g., referencing a non-existent attribute.. Option C is correct because the most likely cause of an empty output value is that the output block in the module references an attribute that does not exist on the resource. For example, if the output is defined as `output "bucket_arn" { value = aws_s3_bucket.my_bucket.arn }` but the resource is actually `aws_s3_bucket.my_bucket` and the correct attribute is `arn`, a typo like `arnn` or `id` would cause Terraform to return an empty string (or an error during plan). Terraform validates attribute references at plan time, but if the attribute is missing or misspelled, the output value will be empty or cause a failure.

Answer

The output is defined in the module but not in the root configuration.

Answer

The S3 bucket creation depends on another resource that hasn't been created yet.

Answer

The IAM role used by Terraform does not have permission to read the bucket ARN.

Question 4

Which TWO statements about Terraform module sources are correct? (Select TWO.)

Accepted Answer

A module source can be a local file system path.. Option A is correct because Terraform allows module sources to be local file system paths, enabling you to reference modules stored on your local machine. This is useful for developing and testing modules before publishing them, and the path can be relative or absolute, such as `./modules/my-module` or `/home/user/modules/my-module`.

Answer

Modules can only be sourced from the public Terraform Registry.

Answer

Running 'terraform plan' automatically downloads any missing modules.

Answer

The module source is defined in a separate 'source' block within the module.

Question 5

Which THREE practices are recommended when using Terraform modules? (Select THREE.)

Accepted Answer

Design modules to have a single clear purpose.. Option A is correct because Terraform modules should follow the single-responsibility principle: each module should encapsulate a clear, focused purpose (e.g., provisioning a VPC, an EC2 instance, or a database). This makes modules reusable, testable, and easier to compose. A module that tries to do too many things becomes brittle and hard to maintain.

Answer

Hardcode provider-specific details like region inside the module to simplify usage.

Answer

Create a new module for each individual resource type.

Question 6

The above configuration references a module from the Terraform Registry. After running 'terraform init', the user runs 'terraform plan' and gets an error: 'Error: Unsupported argument' for 'version'. What is the most likely cause?

Accepted Answer

The 'version' argument is not supported for this module because the source is not a registry module.. The error 'Unsupported argument' for 'version' occurs because the module source is not from a Terraform Registry. The 'version' argument is only valid when the source is a registry module (e.g., 'hashicorp/consul/aws'). If the source is a local path, Git URL, or other non-registry source, Terraform does not support the 'version' argument, as versioning is managed by the registry's metadata.

Answer

The 'version' argument must be specified as a constraint like '>= 3.19.0' instead of an exact version.

Answer

The 'version' argument should be placed inside a 'required_providers' block.

Question 7

After running 'terraform apply', the user sees that the 'aws_s3_bucket_object' is created successfully, but the bucket name is not as expected. What is the most likely reason?

Accepted Answer

The output 'bucket_name' in the module is set to 'aws_s3_bucket.this.id', which is the bucket name, so the bucket name should be as expected.. Option D is correct because the module output 'bucket_name' is defined as 'aws_s3_bucket.this.id', and in Terraform, the 'id' attribute of an 'aws_s3_bucket' resource is exactly the bucket name (not a generated ID). Since the user sees the object created successfully, the module is being called and the output is correctly referencing the bucket name, so the bucket name should be as expected. The question implies the user's expectation is wrong or the bucket name is actually correct, making D the only statement that aligns with Terraform's behavior.

Answer

The module variable 'bucket_name' is not consumed by the resource; the resource uses a hardcoded name.

Answer

The module output is incorrectly defined; it should use 'bucket' attribute instead of 'id'.

Answer

The module does not have an output for the bucket name, so the reference fails silently.

Question 8

You are a DevOps engineer at a company that manages infrastructure for multiple environments (dev, staging, prod) using Terraform. The team has created a reusable module for deploying an AWS ECS Fargate service. The module accepts variables for environment name, container image tag, and desired count. The module is stored in a private Git repository. The root configurations for each environment are stored in separate directories, each with its own backend configuration. Recently, a developer added a new feature to the module that requires a new variable 'enable_xray' (boolean, default false). After updating the module source to point to the new commit, the developer runs 'terraform init' and 'terraform plan' in the dev environment. The plan shows that the ECS service will be updated, but the output does not show any changes related to X-Ray. The developer expected that setting 'enable_xray = true' in the dev root module would enable X-Ray tracing. However, the plan shows no changes to the task definition. What is the most likely cause?

Accepted Answer

The module does not reference the 'enable_xray' variable in any resource, so setting it has no effect.. Option D is correct because the `enable_xray` variable, even when set to `true` in the root module, will not cause any changes in the plan unless the module's resources actually reference that variable. In Terraform, a variable declared in a module has no effect on infrastructure unless it is used in a resource argument. The developer saw no changes to the task definition because the module's code likely does not include a condition or argument that uses `enable_xray` to enable X-Ray tracing on the ECS task definition.

Answer

The module source was not updated correctly; it still points to the old commit.

Answer

The developer forgot to run 'terraform init' after changing the module source.

Answer

The variable 'enable_xray' is not declared in the module's variables.tf file.

Question 9

A team is using a module from the Terraform Registry. They want to ensure that changes to the module's source version are tested in a non-production environment before being applied to production. Which approach best supports this workflow?

Accepted Answer

Use a version constraint like ~> 1.0 in the module configuration and test the module in a non-production workspace before promoting to production.. Option D is correct because using a version constraint like `~> 1.0` allows Terraform to automatically select the latest compatible patch version within the specified minor version range. This enables safe, incremental updates that can be tested in a non-production workspace first, and then promoted to production by simply applying the same configuration. The constraint ensures that breaking changes (major version bumps) are not automatically pulled in, giving the team control over when to adopt them.

Answer

Fork the module repository and manage the module internally as a private module.

Answer

Pin the module to an exact version (e.g., version = "1.2.3") and update it manually after testing in isolation.

Answer

Configure the module source to reference the latest commit from the default branch of the repository.

Question 10

Which TWO statements about Terraform module structure and best practices are correct? (Choose two.)

Accepted Answer

A module should define variables for any values that need to be customized by the calling configuration.. Option A is correct because Terraform modules are designed to be reusable and configurable. By defining input variables for any customizable values (e.g., resource names, sizes, regions), the module abstracts away hardcoded details and allows the calling configuration to pass in specific values via variable assignments. This follows the principle of encapsulation, where the module's internal logic remains unchanged while its behavior adapts to the caller's needs.

Answer

A module should assume the calling configuration will provide all necessary provider configurations.

Answer

A module must have all Terraform code in a single main.tf file.

Answer

A module should rely on direct attribute references to resources in the calling configuration.

Question 11

Refer to the exhibit. The configuration fails with an error indicating that the module does not support the 'enable_vpn_gateway' argument. What is the most likely cause?

Accepted Answer

The module version '3.18.0' does not include the 'enable_vpn_gateway' variable; it was added in a later version.. Option B is correct because the error message indicates that the module does not support the 'enable_vpn_gateway' argument. In Terraform, module arguments are defined by the module's published variables. The module version '3.18.0' predates the introduction of the 'enable_vpn_gateway' variable, which was added in a later version. Upgrading the module version to one that includes this variable resolves the error.

Answer

The argument name is misspelled; it should be 'enable_vpn' instead.

Answer

The module does not support VPN gateways at all.

Answer

The module source is incorrectly specified; it should use a git URL instead of the registry path.

Question 12

You are managing a Terraform configuration that uses a public module from the registry to deploy an AWS VPC. The module is defined with a version constraint of '~> 3.0'. After running 'terraform init', you run 'terraform plan' and notice that the plan output indicates the module will be updated from version 3.18.0 to 3.20.1. However, you are concerned because the module's changelog shows that version 3.19.0 introduced a breaking change: it removed the 'enable_dns_hostnames' variable and replaced it with 'enable_dns_support'. Your configuration currently uses the 'enable_dns_hostnames' variable. You want to avoid any breaking changes in the production environment while still receiving non-breaking updates. What should you do?

Accepted Answer

Change the version constraint to "~> 3.18.0" to stay within the 3.18.x releases.. Option C is correct because the version constraint '~> 3.18.0' restricts updates to only patch versions within the 3.18.x series (e.g., 3.18.1, 3.18.2), which will never include the breaking change introduced in 3.19.0. This allows you to receive non-breaking bug fixes and security patches while avoiding the removal of the 'enable_dns_hostnames' variable. The pessimistic version constraint operator (~>) in Terraform locks the major and minor version when specified with three segments, ensuring no unexpected breaking changes from higher minor versions.

Answer

Fork the module repository and maintain a custom version that retains the 'enable_dns_hostnames' variable.

Answer

Change the version constraint to ">= 3.0.0, < 3.19.0" and run 'terraform init -upgrade'.

Answer

Update the configuration to use the new 'enable_dns_support' variable and update the module to version 3.20.1.

Question 13

Which TWO options are valid ways to reference a Terraform module from a registry?

Accepted Answer

source = "hashicorp/consul/aws". Option A is correct because the Terraform registry module source syntax requires the format `namespace/name/provider`, and `hashicorp/consul/aws` follows this exactly. This tells Terraform to fetch the module from the public registry, using the `hashicorp` namespace, the `consul` module name, and the `aws` provider. The `version` constraint in option C is also valid, as it pins the module to a compatible version range using the `~>` operator, which is a standard Terraform version constraint syntax.

Answer

source = "consul/aws"

Answer

from = "hashicorp/consul/aws"

Answer

source = "hashicorp/consul/aws?ref=v1.0.0"

Question 14

A developer runs `terraform plan` and receives the error: "Error: Unsupported argument; An argument named 'enable_vpn_gateway' is not expected here." What is the most likely cause?

Accepted Answer

The module version 5.0.0 does not support the 'enable_vpn_gateway' argument.. Option D is correct because the error 'Unsupported argument' indicates that the module version currently in use does not define an input variable named 'enable_vpn_gateway'. In Terraform, each module version has a fixed set of input variables; if you attempt to pass an argument that is not declared in the module's variables.tf, Terraform will reject it. The most common reason for this is that the module version has been updated or changed, and the argument was removed or renamed in that version.

Answer

The source address is misspelled 'vpc' instead of 'vpc/aws'.

Answer

The source module is not pinned to a specific version, so it may have changed.

Answer

The module must be sourced from a different registry or repository.

Question 15

Your company manages infrastructure for multiple environments (dev, staging, prod) using Terraform. You have a shared networking module stored in a private Git repository. The module is used by several root configurations. The current workflow requires developers to manually update the module version in each root module's source attribute when a new version is tagged. This has led to configuration drift and occasional use of incompatible module versions. You want to implement a more reliable approach that ensures all environments use the same consistent version of the module, while still allowing controlled upgrades. Which approach best addresses this concern?

Accepted Answer

Use a version constraint like "~> 1.2" in the module source and adopt a workflow to update the constraint across all root modules simultaneously only when ready.. Option D is correct because it uses a version constraint (e.g., `~> 1.2`) to allow automatic patch-level updates while preventing major or minor breaking changes, and it enforces a coordinated workflow where all root modules update the constraint simultaneously. This eliminates configuration drift and ensures consistent module versions across environments, while still enabling controlled upgrades. The approach leverages Terraform's built-in version constraint syntax to balance consistency with flexibility.

Answer

Publish the module to the public Terraform Registry and use a version constraint in each root module.

Answer

Pin each root module to a specific Git tag (e.g., ref=v1.2.3) and manually update each root module when a new tag is created.

Answer

Remove the version constraint from the module source so that Terraform always fetches the latest commit from the default branch.