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

Question 1

Which THREE statements about module configuration are correct?

Accepted Answer

Module sources can be local paths or remote URLs.. Option A is correct because a Terraform module block's source argument accepts either a local filesystem path (e.g., ./modules/vpc) or a remote URL/registry address (e.g., git::https://... or terraform-aws-modules/vpc/aws), so modules can be sourced locally or remotely. Option D is correct because a module is simply a container for a group of configuration, so its directory can declare multiple resources and can also call child modules, enabling nested/composable modules. Option E is correct because module input variables become optional when the variable declaration in the child module includes a default value, allowing the caller to omit that argument. Option B is not correct because version constraints apply only to sources that support versioning, such as registry modules or Git refs, not to arbitrary local paths or all remote URL types. Option C is not correct because module outputs are evaluated as part of the plan and are available after apply, but they are also known during plan when their values are determinable, so saying 'after apply only' is inaccurate.

Answer

Version constraints can be specified for any module source.

Answer

The outputs of a module are available after apply only.

Question 2

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 3

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 4

Your team is developing a custom module for creating EC2 instances with attached EBS volumes. The module variables are: instance_type (default "t2.micro"), ami (required), volume_size (default 8), volume_type (default "gp2"). Another team uses this module to create a web server. In their root module, they call the module without any explicit instance_type override, but they do set other variables. After applying, the web server is created with instance_type "t2.nano" instead of the expected "t2.micro". They confirm that the module still has the default "t2.micro". What is the most likely explanation?

Accepted Answer

The root module has a variable called instance_type set to "t2.nano" that is being passed to the module.. In Terraform, when a child module is called without an explicit argument for a variable, the module's default value is used. However, if the root module has a variable with the same name (instance_type) and that variable is referenced in the module block (e.g., instance_type = var.instance_type), then the root's value overrides the module's default. Here, the root module likely has a variable instance_type set to "t2.nano" and passes it to the module, causing the unexpected instance type.

Answer

The module's instance_type variable uses a default that is "t2.nano" but the root module overrode it with a variable from its own context.

Answer

The instance_type variable is not defined in the module's variables.tf, so it uses a default from the AWS provider.

Answer

The module's variable default was changed to "t2.nano" in a new version.

Question 5

What is the most likely cause of this error?

Accepted Answer

The module source path does not exist.. The error in Terraform module initialization almost always stems from the module's source path being invalid — a typo, wrong relative path, or non-existent registry module. Terraform cannot download or reference the module, so it fails before evaluating variables or version constraints.

Answer

The module requires a version constraint.

Answer

The required_version is incompatible with the module.

Answer

The module input variable 'vpc_id' is not defined in the module.

Question 6

A platform team maintains a shared module in a private Git repository. They want to expose a single variable `subnet_ids` to callers, but the module internally must reject any caller who supplies fewer than three subnet IDs, because its load balancer requires at least three. Which TWO mechanisms should they use to enforce this contract? (Choose two.)

Accepted Answer

Add a `precondition` block inside a `lifecycle` block on a resource that consumes `var.subnet_ids`, checking `length(var.subnet_ids) >= 3`.. Input variable validation blocks and lifecycle preconditions both evaluate expressions at plan time and can halt execution with a custom message. The validation block keeps the check next to the variable declaration, while a precondition ties the check to a resource that depends on the value. Either mechanism, or both together, enforces the minimum three-subnet contract before any infrastructure is created.

Answer

Publish the module to a private module registry and set a `required_version` constraint on the module to `>= 3.0`.

Answer

Set `sensitive = true` on the `subnet_ids` variable and document the three-subnet minimum in the module's README.

Answer

Use a `count` meta-argument on the module call in the root configuration and set it to `length(var.subnet_ids)`.

Question 7

A team consumes a module from the Terraform Registry with the source string `app.terraform.io/example-corp/network/aws`. During a code review, an engineer notices the module call has no `version` argument and asks how Terraform decides which release to install. What is the actual behaviour?

Accepted Answer

Terraform pins the module to the exact version recorded in the dependency lock file on first init and never upgrades it automatically.. Registry modules without a version argument are resolved to the newest available release at init time and that choice is stored in the dependency lock file. Later inits honour the lock, so the module stays fixed until an explicit upgrade. Adding a version constraint narrows the candidate set but does not change the lock-file mechanism.

Answer

Terraform refuses to install the module and returns an error stating that a version argument is mandatory for registry sources.

Answer

Terraform defaults to the oldest stable release of the module to maximise compatibility with existing configurations.

Answer

Terraform always downloads the newest published version on every init, so the module can change without any commit to the repository.

Question 8

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 9

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 10

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 11

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 12

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 13

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 14

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

Accepted Answer

Module inputs are defined as variables in the module's root directory, and outputs are defined as output values that can be consumed by the calling configuration.. 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 15

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.