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

Question 1

A team uses Terraform with remote state in an S3 backend and DynamoDB for state locking. A user runs 'terraform apply' and receives the error: 'Error acquiring the state lock'. The lock info shows a lock ID and caller. What is the best immediate course of action?

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

Accepted Answer

Check if another Terraform process is running; if not, use 'terraform force-unlock' with the lock ID.. The error indicates a state lock is held, typically by another Terraform process or a stale lock. The best immediate course is to verify no other process is running (e.g., via 'ps' or task manager), then use 'terraform force-unlock -lock-id=<LOCK_ID>' to release the lock. This is the safe, documented procedure that preserves the state file and DynamoDB lock table integrity.

Answer

Delete the state file from S3 and re-run apply.

Answer

Manually delete the DynamoDB lock table item.

Answer

Wait for 15 minutes and re-run apply.

Question 2

What is the primary purpose of 'terraform init'?

Accepted Answer

To initialize the working directory, download providers, and set up the backend.. The 'terraform init' command is the first step in the core Terraform workflow. Its primary purpose is to initialize the working directory containing Terraform configuration files, download and install the required provider plugins (e.g., AWS, Azure, GCP), and configure the backend (e.g., local, S3, Terraform Cloud) for state storage. Without running 'terraform init', subsequent commands like 'terraform plan' or 'terraform apply' will fail because the providers and backend are not set up.

Answer

To format the Terraform configuration files.

Answer

To apply changes to the infrastructure.

Answer

To preview infrastructure changes before applying them.

Question 3

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 4

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 5

Which TWO commands are part of the core Terraform workflow? (Choose two.)

Accepted Answer

terraform init. `terraform init`, is correct because it initializes a working directory containing Terraform configuration files, downloading and installing the required providers and modules. This is the first command in the core Terraform workflow, which follows the sequence: init, plan, apply. Without `init`, subsequent commands like `plan` or `apply` will fail due to missing provider plugins and backend configuration.

Answer

terraform fmt

Answer

terraform console

Answer

terraform get

Question 6

Which TWO scenarios could cause 'terraform plan' to show 'No changes' even though the configuration file was recently modified? (Choose two.)

Accepted Answer

The user ran 'terraform plan' from a different directory that does not contain the modified configuration.. `terraform plan` operates on the configuration files in the current working directory. If the user runs the command from a different directory that does not contain the modified configuration, Terraform will compare the state against the unmodified files in that directory, resulting in 'No changes'. Option B is correct because a `lifecycle` block with `ignore_changes` tells Terraform to disregard changes to specified attributes when planning, so even if the configuration file modifies that attribute, Terraform will not detect a diff and will report 'No changes'.

Answer

The resource was manually updated in the cloud provider console.

Answer

A new resource block was added.

Answer

The provider version was changed in the required_providers block.

Question 7

Which THREE are valid methods to manage Terraform state files? (Choose three.)

Accepted Answer

Local state file. Option B (Local state file) is correct because Terraform's default behavior stores state in a local file named terraform.tfstate in the working directory, which is a fully valid way to manage state for solo or simple workflows. Option C (Terraform Cloud state storage) is correct because Terraform Cloud (and Terraform Enterprise) provides a managed remote backend that stores state, supports locking, versioning, and team collaboration, making it a legitimate state management method. Option E (Remote backends such as S3, AzureRM, GCS) is correct because configuring a backend block (e.g., backend "s3", "azurerm", or "gcs") stores the state file remotely and enables locking and shared access, which is the recommended approach for teams. Options A (terraform state push) and D (terraform state mv) are not state management methods but rather state manipulation subcommands: terraform state push manually uploads a local state to a remote backend, and terraform state mv moves resources within state, so neither constitutes a method of storing or managing the state file itself.

Answer

terraform state push

Answer

terraform state mv

Question 8

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

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 10

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

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

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

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

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

Accepted Answer

Write Terraform configuration files. The core Terraform workflow consists of three main steps: Write, Plan, and Apply. Option B (Write Terraform configuration files) is correct because authoring HCL configuration that defines the desired infrastructure is the foundational first step of the workflow. Option C (Review the execution plan) is correct because running terraform plan and reviewing the proposed changes is the second core step, allowing you to verify what Terraform will create, modify, or destroy before applying. Option A is incorrect because Terraform is a declarative IaC tool; manually creating resources in a cloud console bypasses Terraform's state and workflow entirely. Option D is incorrect because committing to version control, while a best practice, is not a defined step of the core Terraform workflow itself. Option E is incorrect because running unit tests on configuration is a supplementary validation practice, not one of the core workflow stages of write, plan, and apply.

Answer

Create infrastructure manually via cloud console

Answer

Commit changes to version control

Answer

Run unit tests on the configuration

Question 15

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