TF-004 Practice Test 24 — 15 Questions

Question 1

Which TWO statements accurately describe key purposes of Terraform?

Accepted Answer

Terraform enables declarative infrastructure provisioning.. Terraform allows users to define infrastructure using declarative configuration (HCL), specifying the desired end state rather than step-by-step procedures. Option D is correct because Terraform supports multiple cloud providers (AWS, Azure, GCP) and many other services through providers, enabling multi-cloud and multi-provider management. Option B is incorrect: Terraform does not have built-in security scanning; security scanning is typically handled by external tools or integrated via providers. Option C is incorrect: While Terraform can be used within CI/CD pipelines, it does not automate the pipelines themselves; CI/CD tools like Jenkins or GitHub Actions handle pipeline automation. Option E is incorrect: Terraform primarily manages immutable infrastructure, but this is a characteristic of how it manages resources (by replacing rather than modifying), not a core purpose statement.

Answer

Terraform provides built-in security scanning.

Answer

Terraform automates continuous delivery pipelines.

Answer

Terraform manages both mutable and immutable infrastructure.

Question 2

A team of five engineers manages infrastructure using Terraform with remote state stored in an S3 bucket and state locking via a DynamoDB table. After a power outage, an engineer notices that a terraform apply command fails with the message: 'Error: Error acquiring the state lock'. The engineer suspects that a lock from a previous run has not been released. The team needs to proceed with applying changes. Which action should the engineer take to resolve the issue safely?

Accepted Answer

Run terraform force-unlock with the lock ID obtained from the error message.. The `terraform force-unlock` command is the intended safe method to release a stuck lock when the lock holder process is confirmed dead. The lock ID is provided in the error message. Option A is incorrect because Terraform state locks do not have a default automatic expiration; they must be explicitly released. Option B is risky: directly deleting the lock record from DynamoDB can lead to inconsistent state if not done carefully, and is not recommended as a standard practice. Option D bypasses locking entirely with `-lock=false`, which can cause state corruption if other operations are in progress, so it is unsafe.

Answer

Wait for the lock to expire automatically (locks have a 5-minute TTL).

Answer

Delete the lock record from the DynamoDB table using the AWS CLI.

Answer

Run terraform apply with the -lock=false flag to bypass locking.

Question 3

A team wants to ensure that their infrastructure configuration repeatedly results in the same environment regardless of the initial state. Which IaC concept is most directly associated with this goal?

Accepted Answer

Idempotency. Idempotency ensures that applying the same configuration multiple times always results in the same desired state, regardless of the starting state. In Terraform, this is achieved by the provider's ability to detect drift and reconcile the real-world infrastructure with the declared configuration in the .tf files. Without idempotency, repeated runs could create duplicate resources or fail to correct unintended changes.

Answer

Version control

Answer

Orchestration

Answer

Provisioning

Question 4

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 5

A user runs `terraform apply` and receives an error: 'Error acquiring the state lock'. What is the most likely cause?

Accepted Answer

Another user is running a Terraform command that modifies state.. The error 'Error acquiring the state lock' means that another operation currently holds the lock on the state file. Option A is correct because if another user is running a Terraform command that modifies state (such as apply or destroy), the lock will be acquired and subsequent operations will fail. Option B is incorrect because a missing state file would produce a different error (e.g., 'No state file found'). Option C is incorrect because invalid backend configuration is caught during 'terraform init', not during 'apply'. Option D is incorrect because provider incompatibility typically leads to plugin-related errors, not state lock errors.

Answer

The state file is missing.

Answer

The backend configuration is invalid.

Answer

The Terraform provider is incompatible.

Question 6

A company wants to use Terraform to create Azure resources. They have written a configuration file but when they run `terraform init`, they get a warning about an 'incomplete lock file'. What should they do first?

Accepted Answer

Delete the `.terraform.lock.hcl` and re-run `terraform init`. The warning about an 'incomplete lock file' indicates that the `.terraform.lock.hcl` file is corrupted, incomplete, or from an incompatible provider version. The correct first step is to delete the existing lock file and re-run `terraform init`, which will regenerate a fresh lock file based on the current configuration and provider requirements. This ensures dependency integrity before any planning or applying.

Answer

Change the provider version in the configuration

Answer

Run `terraform apply` immediately

Answer

Run `terraform plan` to update the lock file

Answer

Run `terraform validate` to fix the warning

Question 7

A team uses an S3 backend for state storage with DynamoDB locking. They want to migrate to a new S3 bucket. Which two steps are necessary to perform a successful state migration? (Choose two.)

Accepted Answer

Run `terraform init -reconfigure` to update the backend configuration.. `terraform init -reconfigure` forces Terraform to reinitialize the backend and apply the new backend configuration from the `backend` block without prompting for confirmation. Option E is correct because the `backend` block in the Terraform configuration must be updated to reference the new S3 bucket name; Terraform reads this block during initialization to determine where to store and retrieve state. Together, these steps ensure Terraform knows the new backend location and can properly manage state going forward.

Answer

Run `terraform plan` to verify no resource changes before migration.

Answer

Delete the old state file after migration.

Answer

Manually copy the state file from the old bucket to the new bucket.

Question 8

In a CI/CD pipeline, Terraform state is stored in Terraform Cloud. A pipeline run fails with the error: 'State version conflict'. What is the most likely cause?

Accepted Answer

Two runs started at the same time. A 'State version conflict' in Terraform Cloud typically occurs when two runs attempt to modify the same state concurrently. Even though Terraform Cloud serializes runs via a queue, a conflict arises if a run completes before another run that started based on an older state version. Terraform Cloud detects that the state has changed externally, resulting in a version conflict. Missing or incorrect backend configuration (option B) would cause errors like 'backend initialization required' or 'workspace not found', not specifically a state version conflict. Authentication failures (A) yield access denied errors. State size limits (C) produce size-related errors. Version mismatches (D) cause compatibility warnings.

Answer

Authentication failure with Terraform Cloud

Answer

Missing or incorrect backend configuration

Answer

State file exceeds maximum size limit

Answer

Terraform version mismatch between local and remote

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

A company uses Terraform with an S3 backend. A user accidentally deletes the state file. What is the best practice to recover the state?

Accepted Answer

Restore the state file from S3 bucket versioning. Using S3 versioning is the best practice because it allows you to restore the previous version of the state file. Other options, such as relying on local caches or re-importing resources, are not reliable or efficient.

Answer

Use terraform state pull from the local cache

Answer

Use terraform import on all resources

Answer

Recreate the state from a terraform plan

Answer

Restore from the local terraform.tfstate.backup

Question 11

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 12

A user wants to import an existing AWS EC2 instance into Terraform state so it can be managed. After writing the resource block matching the instance, what is the correct next step?

Accepted Answer

Run 'terraform import' with the resource address and ID of the instance.. After writing the resource block that matches the existing EC2 instance, the correct next step is to run 'terraform import' with the resource address and the instance ID. This command maps the real-world infrastructure to the Terraform state, allowing Terraform to manage the resource without destroying or recreating it. Without this explicit import, Terraform has no knowledge of the existing instance in its state file.

Answer

Run 'terraform plan' to see if the import is necessary.

Answer

Run 'terraform refresh' to sync state with the existing resource.

Answer

Run 'terraform apply' directly; Terraform will detect the existing resource and import it.

Question 13

A company wants to manage both on-premises and cloud infrastructure with a single tool. Which feature of Terraform makes this possible?

Accepted Answer

Provider plugins. Terraform uses provider plugins as the abstraction layer that allows it to interact with different infrastructure platforms. Each provider plugin (e.g., AWS, Azure, vSphere) implements the necessary API calls to manage resources on that platform. By using multiple provider plugins in the same configuration, Terraform can manage both on-premises infrastructure (e.g., VMware vSphere) and cloud infrastructure (e.g., AWS EC2) with a single tool.

Answer

State files

Answer

Provisioners

Answer

Workspaces

Question 14

Match each Terraform command to its primary function.

Accepted Answer

terraform init: Initializes a working directory containing Terraform configuration files. The correct matches are: init initializes the workspace, plan creates an execution plan, apply executes changes, destroy tears down resources. Common mistakes include confusing init with apply or plan with destroy.

Answer

terraform init: Applies changes to infrastructure

Answer

terraform plan: Destroys all resources

Question 15

Which THREE actions should be taken when migrating Terraform state from local to a remote backend?

Accepted Answer

Run terraform init to initialize the backend and migrate state.. `terraform init` is the command that initializes the backend configuration and, when a backend block is added to the configuration, automatically prompts to migrate the existing local state file to the new remote backend. This command handles the state migration seamlessly without requiring manual intervention, ensuring the state file is copied and the backend is configured correctly.

Answer

Remove the local state file before running terraform init.

Answer

Manually import all existing resources into the remote state.