TF-004 Interact with Terraform modules Practice Test 4 — 15 Questions

Question 1

A developer creates a module in a subdirectory of their Terraform configuration and wants to reference it from the root module. The directory structure is: /terraform-project/modules/networking. Which source argument should they use in the module block?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

source = "./modules/networking". Terraform resolves local module paths relative to the root module's directory. The path `./modules/networking` correctly references the `networking` subdirectory within the `modules` folder, starting from the root of the Terraform configuration. This is the standard syntax for referencing a local module in a subdirectory.

Answer

source = "file:///terraform-project/modules/networking"

Answer

source = "/terraform-project/modules/networking"

Answer

source = "hashicorp/networking/aws"

Question 2

An organization stores their Terraform modules in a private Git repository. They need to reference a module that resides in a subdirectory called 'modules/rds' within the repository 'infra-modules' on the main branch. Which source argument should be used?

Accepted Answer

source = "git::https://github.com/org/infra-modules.git//modules/rds". Terraform's module source syntax for Git repositories uses a double slash (`//`) to specify a subdirectory within the repository. The format `git::https://github.com/org/infra-modules.git//modules/rds` tells Terraform to clone the repository at the main branch and then use the module located in the `modules/rds` subdirectory. This is the standard way to reference a module in a subdirectory of a Git repository.

Answer

source = "git::https://github.com/org/infra-modules.git"

Answer

source = "git::https://github.com/org/infra-modules.git:modules/rds"

Answer

source = "git::https://github.com/org/infra-modules.git//rds"

Question 3

After applying a module that creates a VPC, a user wants to use the VPC ID in another resource within the root configuration. How should they reference the output from the module?

Accepted Answer

vpc_id = module.vpc.vpc_id. In Terraform, module outputs are accessed using the syntax `module..`. Since the module is named `vpc` and it exposes an output called `vpc_id`, the correct reference is `module.vpc.vpc_id`. This allows the root configuration to consume the VPC ID created by the module.

Answer

vpc_id = module_vpc.vpc_id

Answer

vpc_id = data.module.vpc.vpc_id

Answer

vpc_id = local.vpc_id

Question 4

A team is using a module from the Terraform Registry. When they run 'terraform init', they receive an error stating that the module source cannot be downloaded. The module source is correct. What is the most likely cause?

Accepted Answer

The internet connection is down.. The error 'module source cannot be downloaded' occurs during terraform init when Terraform tries to fetch the module from the registry but cannot reach it. Since the module source is correct, the most likely cause is a network connectivity issue, such as the internet being down. The other options are less likely: A (output variable misspellings) would not prevent downloading; B (provider version conflict) would cause a different error later; D (forgotten init) is illogical because the error occurs while running init.

Answer

The module output variable names are misspelled.

Answer

The provider version in the module conflicts with the root provider version.

Answer

The user forgot to run 'terraform init' before 'terraform plan' or 'apply'.

Question 5

A module defines an input variable with 'sensitive = true'. The root module tries to use that variable in an output block. What happens when running 'terraform apply'?

Accepted Answer

The output value is hidden in the CLI output but still available in the state.. When a variable is marked `sensitive = true`, Terraform prevents its value from being displayed in CLI output for any output that references it. However, the value is still stored in the state file and can be used within the module. Therefore, `terraform apply` succeeds, but the output value is hidden in the CLI output while remaining available in the state.

Answer

The apply fails with an error because sensitive variables cannot be used in outputs.

Answer

The output is displayed normally because outputs are always visible.

Answer

The output is removed from the plan entirely to protect the sensitive value.

Question 6

A developer wants to create multiple instances of a module that provisions a single EC2 instance. They want to create 3 EC2 instances. Which approach is most efficient and concise?

Accepted Answer

Use the 'count' meta-argument in the module block.. The `count` meta-argument in a module block allows you to create multiple instances of the entire module (including its EC2 instance) by specifying a number. This is the most efficient and concise approach when you need a fixed number of identical module instances, as it avoids code duplication and leverages Terraform's built-in iteration.

Answer

Set the source argument to a list of three URLs.

Answer

Use the 'for_each' meta-argument with a list of numbers.

Answer

Copy the module block three times with different names.

Question 7

A module outputs a map of security group IDs keyed by name. In the root module, a resource needs to reference the security group ID for the name 'web-sg'. How should the root configuration access this value?

Accepted Answer

module.sg["web-sg"]. When a module outputs a map, the root configuration accesses values using map key syntax: module.[""]. Since the output is keyed by name, module.sg["web-sg"] correctly retrieves the security group ID for 'web-sg'. This is standard Terraform HCL syntax for map outputs.

Answer

module.sg.web-sg

Answer

data.module.sg["web-sg"]

Answer

module.sg[0]

Question 8

A team renamed a module from 'module.network' to 'module.vpc' in their configuration. They run 'terraform plan' and see that Terraform wants to destroy the old network resources and create new ones. They want to preserve the existing resources without downtime. What should they do?

Accepted Answer

Add a 'moved' block to the configuration to map the old module address to the new one.. The `moved` block in Terraform allows you to refactor module addresses without destroying and recreating resources. By adding a `moved` block that maps the old module address (`module.network`) to the new one (`module.vpc`), Terraform will automatically update the state to reflect the new address during the next plan and apply, preserving the existing infrastructure and avoiding downtime.

Answer

Use 'terraform state mv' to move the resources to the new module address.

Answer

Update the module source to a new version.

Answer

Accept the destroy and recreate since it's the only way.

Question 9

Which TWO are benefits of using Terraform modules?

Accepted Answer

Encapsulation of complexity, providing a clean interface.. Terraform modules encapsulate complex infrastructure logic into a single, reusable abstraction. By defining input variables and output values, modules provide a clean interface that hides internal resource configurations, making configurations easier to manage and maintain.

Answer

Faster execution of terraform plan and apply.

Answer

Reduction in state file size.

Answer

Enhanced security by automatically encrypting state files.

Question 10

Which TWO module source types support version constraints in Terraform?

Accepted Answer

Terraform Public Registry. The Terraform Public Registry supports version constraints via the `source` argument using the `registry.terraform.io` namespace, allowing you to specify a version range (e.g., `~> 1.0`) in the module block. Option E is correct because the Terraform Cloud Private Registry also supports version constraints, enabling you to pin or constrain module versions from private repositories using the same syntax as the public registry.

Answer

HTTP URL to a zip archive

Answer

Local file path

Answer

Git URL with a branch reference

Question 11

Which THREE files are considered part of the standard module structure?

Accepted Answer

main.tf. `main.tf` is the primary entry point for defining the core resources and data sources in a Terraform module. It is one of the three mandatory files (along with `variables.tf` and `outputs.tf`) that constitute the standard module structure, as specified by HashiCorp's module best practices.

Answer

backend.tf

Answer

terraform.tfvars

Question 12

After running `terraform plan`, the user receives an error: `Error: Missing required variable`. The variable 'vpc_cidr' is provided. What is the most likely cause?

Accepted Answer

The module requires a variable 'environment' that is not passed.. The error 'Missing required variable' indicates that a variable required by the module has not been provided. Even though 'vpc_cidr' is supplied, the module likely defines a required input variable named 'environment' without a default value, and the user did not pass it in the module block. Terraform enforces that all required variables without defaults must be explicitly set by the caller.

Answer

The module block syntax is incorrect.

Answer

The variable 'vpc_cidr' is misspelled.

Answer

The variable 'vpc_cidr' conflicts with a provider variable.

Question 13

What is the correct way to resolve this provider version conflict?

Accepted Answer

Change the root module's required version to ~> 2.70.. The root module's required_providers version constraint must be compatible with the version constraints declared in any child modules. The error indicates the root module requires a provider version that conflicts with the consul module's constraint (e.g., ~> 2.70). Changing the root constraint to ~> 2.70 aligns it with the child module, satisfying Terraform's version resolution logic during `terraform init`.

Answer

Ignore the module's required_providers and force install the root version.

Answer

Remove the required_providers block from the root module.

Answer

Manually edit the .terraform/modules/consul/main.tf to change the version.

Question 14

Which version of the module was downloaded and why?

Accepted Answer

3.19.0, because it is the latest version matching the constraint ~> 3.0, which allows any 3.x version.. The constraint `~> 3.0` in Terraform's version constraint syntax allows only the rightmost element to increment. Since `3.0` is a two-part version, the constraint permits any version in the `3.x` range (i.e., `3.0.0` up to but not including `4.0.0`). Therefore, the latest version matching that constraint is `3.19.0`, which is the highest available 3.x version.

Answer

3.0.0, because ~> 3.0 only allows the exact version 3.0.0.

Answer

3.19.0, because it is the latest version and version constraints are ignored.

Answer

3.0.0, because ~> 3.0 is limited to patch updates within 3.0.x.

Question 15

A team is using a module from the Terraform Registry and wants to ensure they always get the latest patch version of the 3.2.x series. Which version constraint should they use?

Accepted Answer

~> 3.2.0. The `~>` (pessimistic constraint) operator in Terraform allows only the rightmost version component to increment. For `~> 3.2.0`, this means any version >= 3.2.0 and < 3.3.0, which precisely matches the requirement for the latest patch within the 3.2.x series. Option C is correct because it locks the major and minor versions while permitting patch-level updates.

Answer

~> 3.2

Answer

3.2.*

Answer

>= 3.2, < 4.0