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

Question 1

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?

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

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

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 5

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.

Question 6

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

Refer to the exhibit. The configuration fails with an error indicating that the module does not support the 'enable_vpn_gateway' argument. What is the most likely cause?

Accepted Answer

The module version '3.18.0' does not include the 'enable_vpn_gateway' variable; it was added in a later version.. The error message indicates that the module does not support the 'enable_vpn_gateway' argument. In Terraform, module arguments are defined by the module's published variables. The module version '3.18.0' predates the introduction of the 'enable_vpn_gateway' variable, which was added in a later version. Upgrading the module version to one that includes this variable resolves the error.

Answer

The argument name is misspelled; it should be 'enable_vpn' instead.

Answer

The module does not support VPN gateways at all.

Answer

The module source is incorrectly specified; it should use a git URL instead of the registry path.

Question 8

You are managing a Terraform configuration that uses a public module from the registry to deploy an AWS VPC. The module is defined with a version constraint of '~> 3.0'. After running 'terraform init', you run 'terraform plan' and notice that the plan output indicates the module will be updated from version 3.18.0 to 3.20.1. However, you are concerned because the module's changelog shows that version 3.19.0 introduced a breaking change: it removed the 'enable_dns_hostnames' variable and replaced it with 'enable_dns_support'. Your configuration currently uses the 'enable_dns_hostnames' variable. You want to avoid any breaking changes in the production environment while still receiving non-breaking updates. What should you do?

Accepted Answer

Change the version constraint to "~> 3.18.0" to stay within the 3.18.x releases.. The version constraint '~> 3.18.0' restricts updates to only patch versions within the 3.18.x series (e.g., 3.18.1, 3.18.2), which will never include the breaking change introduced in 3.19.0. This allows you to receive non-breaking bug fixes and security patches while avoiding the removal of the 'enable_dns_hostnames' variable. The pessimistic version constraint operator (~>) in Terraform locks the major and minor version when specified with three segments, ensuring no unexpected breaking changes from higher minor versions.

Answer

Fork the module repository and maintain a custom version that retains the 'enable_dns_hostnames' variable.

Answer

Change the version constraint to ">= 3.0.0, < 3.19.0" and run 'terraform init -upgrade'.

Answer

Update the configuration to use the new 'enable_dns_support' variable and update the module to version 3.20.1.

Question 9

Which TWO options are valid ways to reference a Terraform module from a registry?

Accepted Answer

source = "hashicorp/consul/aws". The Terraform registry module source syntax requires the format `namespace/name/provider`, and `hashicorp/consul/aws` follows this exactly. This tells Terraform to fetch the module from the public registry, using the `hashicorp` namespace, the `consul` module name, and the `aws` provider. The `version` constraint in option C is also valid, as it pins the module to a compatible version range using the `~>` operator, which is a standard Terraform version constraint syntax.

Answer

source = "consul/aws"

Answer

from = "hashicorp/consul/aws"

Answer

source = "hashicorp/consul/aws?ref=v1.0.0"

Question 10

A developer runs `terraform plan` and receives the error: "Error: Unsupported argument; An argument named 'enable_vpn_gateway' is not expected here." What is the most likely cause?

Accepted Answer

The module version 5.0.0 does not support the 'enable_vpn_gateway' argument.. The error 'Unsupported argument' indicates that the module version currently in use does not define an input variable named 'enable_vpn_gateway'. In Terraform, each module version has a fixed set of input variables; if you attempt to pass an argument that is not declared in the module's variables.tf, Terraform will reject it. The most common reason for this is that the module version has been updated or changed, and the argument was removed or renamed in that version.

Answer

The source address is misspelled 'vpc' instead of 'vpc/aws'.

Answer

The source module is not pinned to a specific version, so it may have changed.

Answer

The module must be sourced from a different registry or repository.

Question 11

Which four of the following statements about interacting with Terraform modules are correct? (Choose four.)

Accepted Answer

A module can reference outputs from another module using the syntax module.... This statement is correct because Terraform modules expose outputs that can be referenced by the calling configuration using the syntax `module..`. This allows values computed inside a module to be used elsewhere in the root module, enabling modular composition and data sharing between modules.

Answer

To use a module from a private registry, you must always specify a version constraint in the source attribute of the module block.

Answer

A module can be used to create resources only in the same provider configuration as the root module; it cannot define its own provider configurations.

Question 12

Drag and drop the steps to manage Terraform state locking with a backend in the correct order.

Accepted Answer

Configure backend with locking, then run terraform init, then run terraform apply, then run terraform destroy.. Backend config must include locking mechanism; init sets up backend, apply uses lock.

Answer

Run terraform init, then configure backend with locking, then run terraform apply, then run terraform destroy.

Answer

Configure backend with locking, then run terraform apply, then run terraform init, then run terraform destroy.

Answer

Run terraform apply, then configure backend with locking, then run terraform init, then run terraform destroy.

Question 13

Match each Terraform function to its category.

Accepted Answer

max(): numeric. Terraform functions are categorized by the type of data they operate on. The correct matches are: max() (numeric), lower() (string), and concat() (collection). Common confusions include misclassifying functions across categories.

Answer

max(): string

Answer

lower(): collection

Question 14

A team is using a private module registry from a third-party vendor. When running terraform init, they receive an error: 'Error downloading module: could not download module... server responded with 401 Unauthorized'. What is the most likely cause?

Accepted Answer

The registry credentials are missing or invalid.. The 401 Unauthorized error indicates that the request to the private module registry was received but authentication failed. Private registries require valid credentials (such as an API token or username/password) to be configured, typically via a `.terraformrc` or `credentials` block in the CLI configuration. Without these, Terraform cannot authenticate and the download is rejected.

Answer

The module source URL is incorrect.

Answer

The Terraform version is too old for the module.

Answer

The network firewall is blocking outbound connections.

Question 15

A module block references a module with version constraint '>= 2.0, < 3.0'. An older version 1.5 is already cached from a previous init. The team wants to ensure they use a newer version. After running terraform init -upgrade, what happens?

Accepted Answer

Terraform upgrades to the latest version in the range 2.x that is not yet cached.. `terraform init -upgrade` instructs Terraform to ignore any cached versions and re-check the registry for the newest available version that satisfies the version constraint `>= 2.0, < 3.0`. Since the constraint excludes 3.0, the latest version in the 2.x series will be selected and downloaded, overwriting the cached 1.5 version.

Answer

Terraform upgrades to version 3.0 because it is the latest.

Answer

Terraform returns an error because version 1.5 is incompatible with the constraint.

Answer

Terraform uses the cached version 1.5 because it is already present.