TF-003 Use the core Terraform workflow Practice Test 3 — 15 Questions

Question 1

A team uses Terraform to manage infrastructure. They have multiple configuration directories for different environments (dev, staging, prod). They want to reuse common modules across environments. Which approach aligns with the core Terraform workflow best practices?

Accepted Answer

Use a single configuration with separate state files and variable files for each environment. Option A is correct because it follows the core Terraform workflow of separating configuration from state and using variable files to manage environment-specific differences. By maintaining a single configuration directory with separate state files (e.g., via different backends or state file paths) and variable files (e.g., `dev.tfvars`, `prod.tfvars`), the team avoids duplication and ensures that all environments use the same module versions and resource definitions, which is a best practice for consistency and maintainability.

Answer

Use workspaces with state stored in a local backend

Answer

Copy the configuration into each environment directory and modify as needed

Answer

Create separate Terraform configurations for each environment with hardcoded values

Question 2

When running `terraform plan`, an engineer sees that Terraform proposes to destroy an existing resource even though the configuration file appears unchanged. What is the most likely cause?

Accepted Answer

The resource's `count` or `for_each` meta-argument was removed from the configuration. Option A is correct because removing the `count` or `for_each` meta-argument from a resource block causes Terraform to interpret the resource as no longer being managed by the configuration. Since Terraform tracks resources by their logical address in the state, the absence of the meta-argument means the existing resource (previously indexed, e.g., `resource.name[0]`) no longer matches any configuration block, so Terraform plans to destroy it. This is a common source of unexpected destruction when the resource count is reduced or the loop construct is removed entirely.

Answer

Another user ran `terraform destroy` without the engineer's knowledge

Answer

The state file was corrupted and lost the resource

Answer

The resource was manually deleted from the cloud provider console

Question 3

An organization uses a remote backend (S3) with DynamoDB for state locking. A developer runs `terraform plan` and gets the error: "Error acquiring the state lock: ConditionalCheckFailedException". What is the most likely cause?

Accepted Answer

Another Terraform process is currently holding the state lock. The error 'ConditionalCheckFailedException' occurs when Terraform attempts to acquire a lock in DynamoDB but the conditional write fails because the lock item already exists with a different lock ID. This indicates another Terraform process (or a stale lock) is currently holding the state lock, preventing concurrent operations to protect state integrity.

Answer

The S3 bucket does not exist

Answer

The DynamoDB table is not yet created

Answer

The Terraform version is incompatible with the backend

Question 4

A team is using Terraform workspaces to manage multiple environments with a single configuration. They store state in an S3 backend. Which statement about Terraform workspaces is true?

Accepted Answer

The default workspace is named "default" and cannot be deleted. Option B is correct because the default workspace in Terraform is always named 'default' and cannot be deleted. This workspace is created automatically when you initialize a configuration, and it serves as the baseline workspace for state management. The S3 backend fully supports workspaces, and each workspace stores its state under a separate path in the S3 bucket, enabling environment isolation without changing the configuration.

Answer

There is a limit of 10 workspaces per configuration

Answer

Workspaces can only be used with the local backend

Answer

Workspaces automatically isolate variable values and provider configurations

Question 5

An engineer accidentally destroys a critical resource by running `terraform apply` after an incorrect `terraform plan`. They want to recover the resource quickly. What should they do?

Accepted Answer

Restore the previous version of the configuration and run `terraform apply` again. If the resource was destroyed, Terraform's state still knows about it (unless state was also deleted). The best recovery is to revert the configuration to the previous version and run `terraform apply`. If state is intact, Terraform will recreate the resource.

Answer

Modify the configuration to match the destroyed resource and run `terraform import`

Answer

Use `terraform force-unlock` to unlock the state and then run `terraform plan`

Answer

Run `terraform state rm` to remove the destroyed resource from state and then re-import it

Question 6

A company has a monolithic Terraform configuration that manages all of its AWS infrastructure. They want to break it into smaller, manageable configurations without causing downtime or resource duplication. Which approach best follows the core Terraform workflow?

Accepted Answer

Use `terraform state mv` to move resources from the monolithic state to new state files for the smaller configurations. Option B is correct because `terraform state mv` allows you to move resources from the monolithic state file into separate state files for the new, smaller configurations without destroying or recreating resources. This adheres to the core Terraform workflow by preserving the existing infrastructure state, avoiding downtime, and preventing resource duplication. The command updates the state mapping so that Terraform continues to manage the same real-world resources under the new configuration structure.

Answer

Create separate configurations from scratch and manually recreate all resources by running `terraform apply`

Answer

Import all existing resources into the new configurations before removing the old configuration

Answer

Delete the monolithic state and apply all new configurations at once

Question 7

A developer is troubleshooting a Terraform configuration that fails during `terraform plan` with the error: "Error: Invalid reference". The error points to a line that references `var.environment` in a module block. What is the most likely cause?

Accepted Answer

The variable `environment` is not defined in the child module's variables.tf. Option C is correct because when a Terraform module block references a variable like `var.environment`, that variable must be defined in the child module's `variables.tf` file. The error 'Invalid reference' indicates Terraform cannot resolve the variable within the module's scope, meaning the child module does not declare an input variable named `environment`. Without this declaration, the module cannot accept the value passed from the root module.

Answer

The Terraform version does not support module variables

Answer

The variable `var.environment` is not defined in the root module's variables.tf

Answer

The module source path is invalid

Question 8

An organization uses Terraform with a remote backend in Azure. After a network outage, a developer attempts to run `terraform apply` and receives the error: "Error: Failed to get existing workspaces: blob (key) not found". What is the most likely cause?

Accepted Answer

The state file for the current workspace was deleted or corrupted. Option C is correct because the error 'blob (key) not found' indicates that Terraform cannot locate the state file for the current workspace in the Azure storage container. After a network outage, the state file may have been deleted or corrupted, preventing Terraform from reading the existing state. This error is specific to the missing blob key, not to authentication or storage account availability.

Answer

The Terraform backend configuration has incorrect access key

Answer

The Azure storage account was deleted

Answer

The workspace was not created via `terraform workspace new`

Question 9

Which TWO statements accurately describe the `terraform plan` command? (Select TWO.)

Accepted Answer

It automatically refreshes the state before creating the plan. `terraform plan` creates an execution plan and can optionally save it to a file. It does not apply changes; it only shows what will happen. It supports refresh option.

Answer

It can be used to destroy infrastructure if the `-destroy` flag is set

Answer

It applies changes to infrastructure

Answer

It requires no configuration files in the directory

Question 10

Which TWO actions are part of the core Terraform workflow? (Select TWO.)

Accepted Answer

Write Terraform configuration files. The core workflow consists of: Write (author config), Plan (review changes), Apply (execute). Options that match are 'Write configuration' and 'Review execution plan'.

Answer

Create infrastructure manually via cloud console

Answer

Commit changes to version control

Answer

Run unit tests on the configuration

Question 11

Which THREE are valid uses of the `terraform state` command? (Select THREE.)

Accepted Answer

Move a resource from one state file to another. Option B is correct because `terraform state mv` allows you to move a resource from one state file to another, which is useful for refactoring configurations or splitting state files. This command updates the resource's address in the target state while preserving its tracked attributes and lifecycle.

Answer

Force unlock the state lock

Answer

Import an existing resource into state

Question 12

Refer to the exhibit. A developer runs `terraform init` and then `terraform plan`. The plan output shows that Terraform will create the AWS instance. However, the state file is expected to be stored in S3 under the key "prod/terraform.tfstate". Which statement is true?

Accepted Answer

The state will be stored in S3 in the us-east-1 region, and the EC2 instance will be created in us-west-2. Option C is correct because the backend configuration specifies the S3 bucket and key 'prod/terraform.tfstate' for state storage, and the AWS provider region (us-west-2) is independent of the backend region. The backend block does not include a 'region' argument, so Terraform defaults to us-east-1 for state storage, while the EC2 instance is created in the provider's configured region (us-west-2).

Answer

The state will be stored locally because the S3 backend configuration is invalid

Answer

The state will be stored in S3 in the us-west-2 region because the provider overrides the backend region

Answer

The `terraform plan` will fail because the S3 bucket is not created yet

Question 13

Refer to the exhibit. A developer runs `terraform plan -out=tfplan` and then `terraform apply "tfplan"`. During apply, network fails and apply is interrupted. The developer then runs `terraform apply` again (without a plan file). What will happen?

Accepted Answer

It will create a new plan and apply only the changes that are still needed. When `terraform apply` is run without a plan file, Terraform automatically creates a new plan based on the current state and configuration, then applies only the changes that are still needed. Since the previous apply was interrupted, the state file reflects the partial progress, and the new plan will detect any remaining resources that still need to be created, updated, or destroyed, ensuring idempotent behavior.

Answer

It will automatically use the previously saved plan file `tfplan`

Answer

It will fail because the state is locked from the previous apply

Answer

It will resume the previous apply from where it left off

Question 14

Refer to the exhibit. A developer runs the commands shown. The Terraform configuration defines a `random_pet` resource. The developer expects the plan to show a new resource to be created, but it says "No changes." What is the most likely reason?

Accepted Answer

The random_pet resource was already created in a previous apply and is still in the state. Option A is correct because the `random_pet` resource was already created and recorded in the Terraform state file during a previous `terraform apply`. When the developer runs `terraform plan` again without any changes to the configuration, Terraform compares the current state to the configuration and finds no differences, resulting in 'No changes.' The resource already exists in the state, so no new resource is planned.

Answer

The `-auto-approve` flag prevents showing changes in the plan

Answer

The `random_pet` resource is not supported by the Terraform version

Answer

The backend is local, so changes are not persisted across runs

Question 15

A developer runs terraform plan and sees that a resource will be destroyed. They want to confirm the exact cause of the destruction before applying. What should they do?

Accepted Answer

Run terraform show after plan.. Running `terraform show` after `terraform plan` displays the plan output in a human-readable format, including the full set of changes (create, update, destroy) and the attributes that triggered them. This allows the developer to inspect the exact reason a resource is marked for destruction, such as a changed required argument or a removed configuration block. It is the standard way to review plan details without applying.

Answer

Review the state file directly.

Answer

Run terraform validate.

Answer

Run terraform graph.