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

Question 1

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?

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

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 2

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 3

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 4

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"]. To access a map output from a module, use the standard map index syntax with brackets and the key name. Option A correctly uses module.sg["web-sg"] to retrieve the security group ID for 'web-sg'. Option B is invalid because dot notation cannot be used with a map key containing a hyphen. Option C incorrectly uses data source syntax; module outputs are accessed via module.. directly. Option D uses an index, which is only valid for list-type outputs, not maps.

Answer

module.sg.web-sg

Answer

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

Answer

module.sg[0]

Question 5

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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

Question 13

You have two modules that create resources in different providers. Module A creates a VPC in AWS, Module B creates a Kubernetes cluster that requires the VPC ID. You want to ensure Module B runs after Module A but avoid hardcoding the VPC ID. Which approach is most appropriate?

Accepted Answer

Output the VPC ID from Module A and pass it as input to Module B.. It establishes an explicit data dependency between modules without hardcoding values. By outputting the VPC ID from Module A and passing it as an input variable to Module B, Terraform's dependency graph automatically ensures Module A is created before Module B, and the VPC ID is dynamically available at plan time.

Answer

Use a data source in Module B to look up the VPC.

Answer

Use terraform graph to order modules.

Answer

Use module dependency via depends_on in the root module.

Question 14

A developer creates a module in a subdirectory called 'networking' relative to the root module. How should the module source be specified in the root module?

Accepted Answer

./networking. When referencing a local module in a subdirectory relative to the root module, the correct path prefix is './' followed by the subdirectory name. Option A, './networking', correctly uses a relative path starting with './' to indicate the 'networking' directory is a child of the root module's directory. This is the standard Terraform convention for local module sources.

Answer

./modules/networking

Answer

../networking

Answer

networking

Question 15

Which THREE statements about module configuration are correct?

Accepted Answer

Module sources can be local paths or remote URLs.. Terraform module sources can be either local file paths (e.g., `./modules/network`) or remote URLs (e.g., `git::https://example.com/repo.git`, `registry.terraform.io/hashicorp/consul/aws`). The `source` argument supports multiple protocols including local, Git, HTTP, and the Terraform Registry, making it flexible for version control and distribution.

Answer

Version constraints can be specified for any module source.

Answer

The outputs of a module are available after apply only.