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

Question 1

A Terraform module defines an output 'instance_ips'. In the root module, how should this value be referenced?

Accepted Answer

module.my_module.instance_ips. Outputs from a child module are accessed in the root module using the `module..` syntax. The `module` keyword is a reserved reference that Terraform uses to expose all outputs defined within a module block, allowing the root configuration to consume values like `instance_ips` as `module.my_module.instance_ips`.

Answer

var.instance_ips

Answer

local.instance_ips

Answer

resource.my_module.instance_ips

Question 2

A developer creates a directory structure with a module located at './modules/networking'. The root configuration references it with source = './modules/networking'. What is the behavior when running terraform init from the root directory?

Accepted Answer

Terraform uses the module directly from the local filesystem.. When a module source is a relative path like './modules/networking', Terraform interprets it as a local filesystem path. During `terraform init`, Terraform reads the module directly from the specified directory without any network access, downloading, or registry interaction. This is the standard behavior for local module references in Terraform.

Answer

Terraform requires a network connection to verify the module.

Answer

Terraform attempts to download the module from the public registry.

Answer

Terraform returns an error because the module path is not absolute.

Question 3

An organization uses Terraform modules to provision multiple environments. They have a module 'vpc' that uses a for_each argument in the root module to create VPCs per environment. Each VPC requires a unique CIDR block passed via variable. What is the best practice to pass different CIDRs per instance?

Accepted Answer

Define a map variable with environment names as keys and CIDRs as values, then pass the entire map to the module.. Using a map variable with environment names as keys and CIDRs as values allows Terraform's `for_each` to iterate over the map, creating one VPC per environment with its specified CIDR. This approach is clear, scalable, and maintains a direct key-value association. Option B (hardcoding) is not scalable and violates infrastructure as code best practices. Option C uses `count.index` and `element()` on a list, which works but is less explicit and can lead to errors if list order changes. Option D is irrelevant because module outputs are read after creation and cannot be used to define input CIDRs.

Answer

Hardcode the CIDR within each module block.

Answer

Use a list variable for CIDRs and reference them with count.index and element().

Answer

Use a module output to fetch the CIDR from a data source.

Question 4

A module 'web_app' defines an input variable 'instance_count' with type = number and a validation block ensuring it is between 1 and 10. What happens if a user sets instance_count = 0?

Accepted Answer

Terraform returns an error during validation and stops execution.. HashiCorp Terraform validates input variables against their declared type and any validation blocks before applying configuration. When `instance_count = 0` is set, the validation block's condition `var.instance_count >= 1 && var.instance_count <= 10` evaluates to `false`, causing HashiCorp Terraform to halt with an error during the `terraform plan` or `terraform validate` phase, preventing any further execution.

Answer

Terraform applies the module with zero instances, as a value of 0 is allowed.

Answer

Terraform ignores the validation if the variable is explicitly set.

Answer

Terraform uses the default value for instance_count from the module.

Question 5

A root module uses a module that creates an AWS EC2 instance. The module outputs the instance ID. The root module then uses this output in a null_resource provisioner. After modifying the module, terraform plan shows that the EC2 instance will be destroyed and recreated. What is the impact on the null_resource?

Accepted Answer

The null_resource will be destroyed and recreated alongside the EC2 instance.. The null_resource's triggers typically depend on the module's output (the instance ID). When the EC2 instance is destroyed and recreated, its ID changes, which updates the trigger value. Terraform interprets this change as a need to destroy and recreate the null_resource along with its provisioner, ensuring the provisioner runs again with the new instance ID.

Answer

The null_resource prompts the user to confirm before any changes.

Answer

The null_resource will remain unchanged because it is not directly attached to the module.

Answer

The null_resource will fail to run because the output is temporarily unavailable during destroy.

Question 6

A module requires a specific provider configuration with aliases. The root module has two provider configurations: provider 'aws' (default) and provider 'aws' with alias = 'uswest'. The module uses the us-west alias. How should the module block be configured to ensure the correct provider is used?

Accepted Answer

Use the providers argument in the module block: providers = { aws = aws.uswest }.. Terraform uses the `providers` argument in a module block to explicitly map provider configurations from the root module into the module. Since the root module has two AWS provider configurations (default and `uswest` alias), and the module requires the us-west alias, the mapping `providers = { aws = aws.uswest }` ensures the module uses the aliased provider. Without this explicit mapping, Terraform would default to the root module's default provider, which may not have the correct region or settings.

Answer

Set required_providers inside the module to include the alias.

Answer

Include a provider block inside the module block with alias = 'uswest'.

Answer

Do nothing; Terraform automatically uses the default provider.

Question 7

After adding a new module sourced from a Git repository with a specific tag, terraform init reports that the module is being downloaded. What is the best practice to ensure the team uses the same version of this module consistently?

Accepted Answer

Use a Git tag, like '?ref=v1.0.0', to pin the version.. Using a Git tag (e.g., `?ref=v1.0.0`) in the module source URL pins the module to a specific, immutable commit. This ensures that every team member downloads the exact same version of the module, regardless of future changes to the default branch. Terraform resolves the tag to a commit hash and caches it, providing deterministic and reproducible infrastructure.

Answer

Use a version constraint in the module block, e.g., version = 1.0.0.

Answer

Specify the source as the branch name 'main'.

Answer

Use the 'latest' tag in the source URL.

Question 8

Which TWO statements are correct when refactoring a monolithic Terraform configuration into modules?

Accepted Answer

Module outputs are necessary to expose values to the root module.. Module outputs are the mechanism by which a root module accesses values from child modules. Without outputs, any resource attributes created inside a module remain encapsulated and inaccessible to the calling configuration, making it impossible to use those values for interpolation or to pass them to other resources or modules.

Answer

All modules must reside in a separate directory outside the root module.

Answer

A module should contain only one resource to keep it simple.

Answer

Variables are optional in modules if hardcoded values are acceptable.

Question 9

Which THREE of the following are valid ways to reference a module output value within the same Terraform configuration?

Accepted Answer

In the count or for_each of another module or resource.. Options A, B, C, and E are correct ways to reference a module output value within the same Terraform configuration. Module outputs can be used in `count` or `for_each` meta-arguments (A), directly in resource arguments (B), in data source filter blocks (C), and in `locals` blocks for transformation (E). Option D is incorrect because provider blocks require static configuration and cannot reference module outputs; provider configurations are resolved before any resources or modules.

Answer

In a provider block to set endpoints.

Question 10

In the configuration, what is the likely result of the resource block 'aws_flow_log'?

Accepted Answer

It will create one flow log per network module instance, using the vpc_id output from each.. `for_each` in Terraform iterates over each element in a map or set, creating one resource instance per element. When `for_each` is used with `module.networks`, it iterates over each module instance, and `each.value.vpc_id` references the `vpc_id` output from that specific module instance. This results in one `aws_flow_log` resource per network module instance, each associated with its respective VPC.

Answer

Terraform will error because for_each cannot be used with module outputs.

Answer

The resource will be created only for the last module instance due to overwriting.

Answer

It will create one flow log for each VPC using a count based on length of module.networks.

Question 11

Based on the error, what is the most likely reason the 'acl' argument is not expected?

Accepted Answer

The module version currently installed does not have an 'acl' variable.. The error indicates that the 'acl' argument is not recognized by the Terraform module. This typically occurs when the installed module version does not expose an 'acl' variable in its schema. Terraform validates arguments against the module's declared variables; if 'acl' is absent from the module's variables.tf, Terraform will reject it as an unexpected argument.

Answer

The argument name is misspelled; it should be 'acl_control'.

Answer

The module requires the 'acl' to be set inside a separate block.

Answer

The 'bucket' argument is missing; 'acl' must follow it.

Question 12

A team wants to use a networking module from the public Terraform Registry. They need to ensure they always get the latest patch version within the 1.2.x series. Which version constraint should they use in the module block?

Accepted Answer

version = "~> 1.2". Uses the pessimistic version constraint operator `~>`, which in Terraform allows only the rightmost version component to increment. When written as `~> 1.2`, it permits any version `>= 1.2.0` and `< 1.3.0`, effectively locking to the 1.2.x series while allowing patch updates. This matches the requirement to always get the latest patch within 1.2.x without accidentally upgrading to 1.3.0 or 2.0.0.

Answer

version = "= 1.2.0"

Answer

version = ">= 1.2.0, < 2.0.0"

Answer

version = ">= 1.2.0"

Question 13

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?

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 14

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 15

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