TF-003 Interact with Terraform modules — 10 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.