TF-004 Interact with Terraform modules — Timed 25 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".. It correctly demonstrates the Terraform syntax for pinning a module from the public registry: the `version` argument is a separate attribute within the module block, not embedded in the source string. Option B is ambiguous; while adding a `version` argument inside the module block is the right idea, the phrasing could be misinterpreted as placing the version inside the source attribute. The official Terraform documentation requires the version to be a standalone argument as shown in Option C. Option A is incorrect because `required_providers` locks provider versions, not module versions. Option D is a valid approach but is not the standard practice for registry modules.

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

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

Accepted Answer

A module source can be a local file system path.. Terraform supports various module sources. Option A is correct because a module source can indeed be a local file system path, allowing for development and testing of modules on your local machine using relative or absolute paths (e.g., `./modules/my-module`). Option D is also correct as Terraform can source modules directly from Git repositories, including those accessed via SSH protocol (e.g., `git::ssh://git@github.com/user/repo.git//path/to/module`). Other supported sources include HTTP/HTTPS URLs, S3 buckets, GCS buckets, and the Terraform Registry (public or private).

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 3

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

Accepted Answer

Design modules to have a single clear purpose.. 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. When referencing modules, especially from a registry, using version constraints (e.g., `version = "~> 1.0"`) is crucial for ensuring consistent deployments and preventing unexpected breaking changes from upstream module updates. Finally, modules should explicitly define outputs for any important resource attributes or computed values that consumers of the module might need to reference or use in other parts of their configuration.

Answer

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

Answer

Create a new module for each individual resource type.

Question 4

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' is a definitive indicator that Terraform does not recognize the module source as a registry module. The 'version' argument is exclusively supported for modules sourced from the Terraform Registry. Therefore, despite the STEM's initial statement, the error implies that the module source is not being treated as a registry module. Option A correctly identifies this core reason. Option C is a specific instance of a non-registry module, but the error itself points to the broader category. Options B and D describe valid syntax or constraints for supported scenarios, which is not the case here.

Answer

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

Answer

The module source is from a Git repository, which does not support the 'version' argument.

Answer

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

Question 5

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.. Terraform modules are designed to be reusable and configurable.

**Statement A**: 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.

**Statement D**: Modules can be sourced from various locations, including local paths relative to the calling configuration. This is a common pattern for organizing smaller, internal modules within the same repository or project directory, allowing for modularity without requiring separate version control repositories for every small module.

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 6

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

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.. It uses Git tags to pin each root module to a specific version (e.g., ref=v1.2.3), ensuring all environments use the same module version. While the current workflow already does this, the key improvement is to adopt a coordinated update process where all root modules are updated simultaneously when a new tag is created, preventing drift. This approach works with private Git repositories, as version constraints (like ~> 1.2) are not supported for Git module sources.

Answer

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

Answer

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

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.

Question 7

Which three of the following describe correct practices or behaviors when interacting with Terraform modules? (Choose three.)

Accepted Answer

Module outputs are accessible from the root configuration using the syntax `module..`.. Option A is correct because Terraform modules can be sourced from a local file path using the `source` argument, such as `'./modules/networking'`, allowing reference to modules within the same repository or filesystem. Option C is correct because module outputs are accessible in the root configuration via `module..`. Option F is correct because the `terraform get` command downloads and updates modules from remote registries (and also updates local modules if the source has changed). Options B, D, and E are incorrect: B is incorrect because Terraform does not automatically apply local changes made inside the `.terraform/modules` directory; these changes can be overwritten by subsequent `terraform init` or `terraform get` commands. D is incorrect because modules can be sourced from various locations including local paths, Git repositories, and HTTP URLs, not just the public Terraform Registry. E is incorrect because module input variables are not automatically populated from environment variables without explicit variable declarations; they must be explicitly defined and then can be overridden by environment variables (TF_VAR_name).

Answer

Module input variables are automatically populated from environment variables without explicit variable declarations.

Answer

When using a module from a Git repository, Terraform automatically applies any local changes made inside the `.terraform/modules` directory.

Answer

Terraform modules can only be sourced from the public Terraform Registry.

Question 8

Which TWO module source types are supported by Terraform natively?

Accepted Answer

Terraform Registry (e.g., hashicorp/consul/aws). Terraform natively supports the Terraform Registry as a module source, using the shorthand syntax like `hashicorp/consul/aws` which resolves to a registry-based module. The Terraform Registry is the default public registry, and Terraform can also use private registries via the `registry.terraform.io` hostname. This is a built-in source type that requires no additional plugins or configuration. Additionally, Terraform natively supports local file paths (e.g., `./modules/vpc`) for modules, allowing for modularization within a single repository or local development before publishing to a registry.

Answer

Docker Hub repositories

Answer

Jenkins plugin repository

Answer

npm packages

Question 9

Given the plan output, how is the module 'instances' configured in the root module?

Accepted Answer

The root module uses for_each in the module block with a map variable.. The explanation correctly describes the characteristics of a Terraform plan output when `for_each` is used on a module block with a map variable (key-value structure like 'instance1', 'instance2'). However, this description *is* the missing input from the STEM. The explanation's role is to justify the correct answer based on the *provided* STEM and options, not to provide missing context from the STEM itself. If the described plan output were provided in the STEM, the explanation would be accurate and the answer correct.

Answer

The module uses count with a list variable.

Answer

The module is declared twice with different names.

Answer

The module contains a resource with for_each inside.

Question 10

Which of the following files is NOT required in a Terraform module?

Accepted Answer

providers.tf. The explanation incorrectly states that `variables.tf` and `outputs.tf` are essential for a reusable module. A module can be reusable and functional without input variables (thus no `variables.tf`) or without output values (thus no `outputs.tf`). While `main.tf` is conventionally used for core resource definitions, its specific name is not strictly required, as resources can be defined in any `.tf` file. `providers.tf` is indeed not strictly required, as provider configurations can be inherited from the calling module or defined via `required_providers` blocks in other files (e.g., `main.tf`). Therefore, `variables.tf`, `outputs.tf`, and `providers.tf` are all technically not strictly required files in a Terraform module, making the question ambiguous if only one answer is expected.

Answer

main.tf

Question 11

You have a list of VPC configurations and want to create multiple VPCs using a single module block with for_each. Which statement is true?

Accepted Answer

When using for_each, the module's outputs will be a map of output values for each instance.. When you use `for_each` on a module block, Terraform creates multiple instances of the module, and the module's outputs become a map of output values keyed by the `for_each` key. This allows you to access each instance's outputs via the map, enabling iteration over the created resources.

Answer

for_each on a module is not supported.

Answer

You can use for_each on a module block only if the module is published in the registry.

Answer

for_each on a module block requires the module to support count.

Question 12

Which module source type does NOT support version constraints?

Accepted Answer

Local path. Local path module sources (e.g., `./modules/foo`) and HTTP URL sources (e.g., `https://example.com/module.tar.gz`) do not support version constraints because there is no remote registry or repository to resolve a version from. Terraform uses the local filesystem path or downloads the HTTP URL directly, so the `version` argument in a `module` block is ignored for these source types. In contrast, Git repositories and the Terraform Registry both support version constraints via their respective resolution mechanisms.

Answer

Git repository

Answer

Terraform Registry

Question 13

Which TWO of the following are valid ways to reference a module from the Terraform Registry?

Accepted Answer

source = "hashicorp/consul/aws". The Terraform Registry uses a three-part namespace format: `//`, where `hashicorp/consul/aws` specifies the `consul` module from the `hashicorp` namespace for the `aws` provider. This format is the standard way to reference a module hosted in the public Terraform Registry, and Terraform automatically resolves it to the registry's HTTPS URL.

Answer

source = "hashicorp/consul"

Answer

source = "github.com/hashicorp/terraform-aws-consul"

Answer

source = "./modules/consul"

Question 14

You are developing a module. Which TWO actions are recommended best practices?

Accepted Answer

Use local values to simplify expressions.. Options B and D are correct. Using local values (B) simplifies expressions and improves readability within a module, as recommended by Terraform best practices. Defining outputs (D) for resources that need to be consumed by the root module or other modules enables proper data flow and reusability. Option A is incorrect because relying on the same provider configuration as the root module reduces module portability; explicit provider configurations are preferred. Option C is incorrect because hardcoding default values reduces flexibility for module consumers; variables should have sensible defaults but allow overrides. Option E is incorrect because absolute paths make modules less portable; relative paths or module registries are preferred.

Answer

Use the same provider configuration as the root module.

Answer

Hardcode default values for all variables.

Answer

Define outputs for all resources created.

Answer

Use absolute paths in module source.

Question 15

A company uses a Terraform module from the registry for AWS VPC (source = "terraform-aws-modules/vpc/aws", version = "3.0.0"). They updated the module version to "3.1.0" and ran terraform plan. To their surprise, the plan shows that all VPC resources will be replaced (destroyed and recreated) instead of updated in place. They did not change any input variables. The module's release notes mention only bug fixes and minor improvements. What is most likely causing the full resource replacement?

Accepted Answer

The module's new version changed the resource names or identifiers.. If the module changes the internal resource names (e.g., from 'aws_vpc.main' to 'aws_vpc.this'), Terraform interprets the old resources as removed and new ones to create, resulting in full replacement. This is a common issue when a module renames its resources between versions, even if the functionality remains the same. Option A is incorrect because a new required variable would cause Terraform to prompt for a value or throw an error, not generate a plan showing resource replacement. Option B is incorrect because while a change in the default CIDR block could trigger replacement of the VPC resource if the user was relying on the default and the attribute is immutable, such a fundamental change in a default for a core resource like VPC is highly unlikely in a minor version update (3.0.0 to 3.1.0) that only mentions 'bug fixes and minor improvements' without explicit warning of a breaking change. Renaming internal resources (Option D) is a more common cause for full resource replacement during module refactoring in minor versions. Option C is incorrect because provider version changes alone rarely force replacement unless there are incompatible schema changes, which are unlikely in a minor version update.

Answer

The module's new version introduced a new required variable.

Answer

The module's new version changed the default CIDR block.

Answer

The module's new version uses a different provider version.

Question 16

A team has a root module that calls a local module using count to conditionally create an AWS RDS instance based on a boolean variable `rds_enabled`. The root module sets `rds_enabled` to the value of a data source that checks if a tag exists on an S3 bucket. The relevant code is: `count = var.rds_enabled ? 1 : 0`. When they run terraform plan, they receive the error: "Error: Invalid count argument: The count value is not yet known". The S3 bucket already exists. What is the underlying issue?

Accepted Answer

The count value must be known when Terraform evaluates it during planning, but the data source result is not guaranteed to be known at that point.. Terraform requires `count` to be a known value before it can finalize the resource graph during the plan. `terraform plan` does perform a refresh and can read data sources, but a data source result is not guaranteed to be known at the moment Terraform evaluates `count`—for example, if the data source depends on values that are not yet known. This can happen even when the underlying object, such as the S3 bucket, already exists. Options A, B, and D are incorrect: data sources can be used in count conditions, module blocks support `count`, and the module itself is not the problem.

Answer

Data sources cannot be used in a count condition.

Answer

The count in a module block cannot depend on a data source.

Answer

The module does not support count.

Question 17

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.. 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 18

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.. 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 19

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.. 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 20

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.. 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.