TF-004 Practice Test 26 — 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

The user runs `terraform init` successfully, but then `terraform plan` still fails with a different error: "Error: No configuration files found in this directory." The directory contains backend.tf and main.tf. What is the most likely cause?

Accepted Answer

The user is not in the same directory as the .tf files.. The error 'No configuration files found in this directory' indicates that Terraform cannot locate any .tf files in the current working directory. Even though the directory contains backend.tf and main.tf, the user must be in that directory when running `terraform plan`. This is a common path issue, not a configuration or syntax problem.

Answer

The backend block is misconfigured.

Answer

The workspace name in the backend configuration is incorrect.

Answer

The main.tf file contains invalid syntax.

Question 3

An organization uses a shared remote backend. They want to prevent concurrent apply operations that could corrupt the state. What built-in mechanism does Terraform provide?

Accepted Answer

State locking. Terraform's state locking mechanism prevents concurrent operations that could corrupt the state file by acquiring a lock on the backend before running `plan` or `apply`. When using a shared remote backend, the lock is held for the duration of the operation and released upon completion, ensuring only one process modifies the state at a time. Option D refers to state file versioning, which provides the ability to recover previous versions but does not prevent concurrent writes.

Answer

File permissions on the remote state file

Answer

Workspace isolation

Answer

State file versioning

Answer

Backend versioning

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"]. 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 5

Which of the following are core concepts or behaviors of Terraform's execution model and state management? (Choose four.)

Accepted Answer

Terraform apply executes the changes proposed by the plan, and can be run with or without a prior plan being saved.. Terraform's execution model is fundamentally a desired state model: the configuration declares the target state, and Terraform computes the actions needed to reach it. The state file is the critical mapping between configuration and real-world resources, tracking metadata like dependencies and attributes. The plan phase produces a dry-run execution plan without making changes, while apply executes those changes and can be run directly without a saved plan file. These four behaviors—desired state, state file mapping, plan as dry-run, and apply as execution—are core to how Terraform operates.

Answer

Terraform refresh automatically updates the state file to match real-world infrastructure by modifying resources if differences are found.

Answer

Terraform destroy removes all resources defined in the configuration from the state file only, without affecting the actual infrastructure.

Question 6

A DevOps engineer wants to modify the Terraform configuration to control resource lifecycle behavior. Which TWO meta-arguments can be used to influence the order of creation and destruction?

Accepted Answer

create_before_destroy. `create_before_destroy` is a meta-argument used within a `lifecycle` block to instruct Terraform to create a replacement resource before destroying the existing one, directly influencing the order of creation and destruction during updates. Option B is correct because `depends_on` explicitly sets dependencies between resources, ensuring that Terraform creates or destroys resources in a specific order based on those declared dependencies.

Answer

for_each

Answer

prevent_destroy

Answer

count

Question 7

When running terraform plan, the output indicates that a resource will be replaced (destroy then create) due to a change in the 'name' attribute. However, the engineer only changed a tag. What is the most likely cause?

Accepted Answer

The 'name' attribute is computed and any change to the resource forces replacement.. When a resource attribute is marked as 'computed' and 'ForceNew' in the Terraform provider schema, any change to that attribute—or, in some provider implementations, any change to the resource at all—triggers a destroy-and-create cycle. In this scenario, the engineer changed only a tag, but the provider has been configured to treat the entire resource as requiring replacement if any attribute changes, often because the 'name' attribute is computed from other inputs or because the provider's internal logic forces replacement on any update. This is a known behavior in certain Terraform providers where the 'name' attribute is set to 'Computed' and 'ForceNew' in the schema, causing any modification to the resource to result in a plan that shows replacement.

Answer

The tag change triggered a ForceNew attribute.

Answer

The resource has create_before_destroy enabled.

Answer

The underlying API does not support in-place updates.

Question 8

Refer to the exhibit. You need to add a security group to each instance. You have a local value defined as 'security_group_map = { "subnet-1" = "sg-1", "subnet-2" = "sg-2" }'. Which expression should be used to reference the security group ID in the resource block?

Accepted Answer

vpc_security_group_ids = [local.security_group_map[var.subnet_ids[count.index]]]. It properly references the local value `security_group_map` using the `local.` prefix, which is required in Terraform to access local values. It then uses the subnet ID from `var.subnet_ids[count.index]` as the key to look up the corresponding security group ID. This ensures each instance gets the correct security group based on its subnet index.

Answer

vpc_security_group_ids = [lookup(security_group_map, var.subnet_ids[count.index])]

Answer

vpc_security_group_ids = [security_group_map[var.subnet_ids[count.index]]]

Answer

vpc_security_group_ids = [lookup(local.security_group_map, var.subnet_ids[count.index])]

Question 9

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 10

A team uses Terraform with a remote backend that stores state in Azure Storage. A developer runs terraform apply and receives an error: 'Error refreshing state: state data in Azure Blob does not have expected content.' What is the most likely cause?

Accepted Answer

The state file was manually edited.. The error 'state data in Azure Blob does not have expected content' indicates that Terraform's internal consistency check failed when reading the state file. This typically occurs when the state file has been manually edited outside of Terraform, corrupting its JSON structure or checksum. Terraform expects the state to be in a specific format and will reject any blob content that does not match its expected schema or hash.

Answer

The Azure Storage account access key has expired.

Answer

The blob name contains uppercase letters.

Answer

The Terraform version is incompatible with the backend.

Question 11

A company uses Terraform Cloud and wants to enforce policies that prevent creating resources with public IP addresses unless explicitly approved. What Terraform Cloud feature should they use?

Accepted Answer

Sentinel policies. Sentinel is HashiCorp's policy-as-code framework that integrates directly with Terraform Cloud. It allows you to define fine-grained, logic-based policies (e.g., 'deny resources with public IPs unless a specific approval tag is present') that are enforced during the plan phase before any resources are created. This is the correct feature for enforcing custom governance rules on infrastructure provisioning.

Answer

VCS integration

Answer

Workspaces

Answer

Run tasks

Question 12

Which TWO of the following are valid ways to use Terraform outside the core workflow? (Choose two.)

Accepted Answer

Using Terraform outputs as inputs for other tools like Ansible.. Terraform outputs can be consumed by other tools like Ansible via the `terraform output` command or by referencing the state file, enabling integration in multi-tool workflows. Option E is correct because the Terraform state file (`.tfstate`) contains all resource attributes and dependencies, which can be parsed programmatically or with tools like `terraform graph` to generate infrastructure diagrams, extending Terraform's use beyond provisioning.

Answer

Using Terraform to manage application secrets lifecycle.

Answer

Using Terraform to install software on existing servers.

Answer

Using Terraform as a CI/CD pipeline tool.

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

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 15

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