TF-004 Implement and maintain state — 10 Questions

Question 1

An organization uses Terraform with AWS S3 backend and DynamoDB for state locking. During a plan, you receive an error: 'Error acquiring the state lock'. The lock information in DynamoDB shows a lock from a previous session that crashed. What is the most appropriate next step?

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

Accepted Answer

Run terraform force-unlock with the lock ID. When a Terraform process crashes while holding a state lock, the lock remains in DynamoDB and must be manually released. The `terraform force-unlock` command with the specific lock ID is the designed mechanism to override a stale lock, as it directly interacts with the DynamoDB locking table to remove the lock item. This is the safest and most appropriate method, as it ensures the lock is released in a controlled manner without risking state corruption.

Answer

Run terraform unlock

Answer

Wait for the lock to expire automatically

Answer

Delete the lock item from DynamoDB table directly

Question 2

A team uses Terraform Cloud workspaces to manage multiple environments. They notice that the state file for the production workspace is stored in a different backend than the development workspace. Which Terraform feature allows different workspaces to use different backends?

Accepted Answer

Using partial configuration with a backend block that has dynamic workspace references. Terraform supports partial backend configuration, where the backend block can omit certain arguments (like the bucket or path) and those values can be supplied dynamically at initialization time. By using a backend block with dynamic workspace references (e.g., `bucket = "my-state-${terraform.workspace}"` or `key = "${var.env}/terraform.tfstate"`), each workspace can resolve to a different storage location (e.g., a different S3 bucket or a different path within the same S3 bucket) for its state file. This allows the production and development workspaces to store their state in entirely different backend configurations (different instances of the same backend type) without hardcoding the configuration.

Answer

Using the -backend-config flag

Answer

Using the backend block with a workspace key

Answer

Using a remote backend type

Question 3

Which TWO of the following are valid reasons to use Terraform state?

Accepted Answer

Improving performance for large infrastructures by caching resource attributes.. Terraform state serves two primary functions:
1.  **Mapping real-world resources to configuration (Option E):** It maintains a mapping between the resources defined in your Terraform configuration files and the actual infrastructure objects created in the cloud or on-premises. This allows Terraform to know which specific cloud resource (e.g., an EC2 instance with a unique ID) corresponds to a particular `aws_instance` block in your code, enabling it to manage, update, or destroy the correct resources.
2.  **Improving performance by caching resource attributes (Option D):** The state file stores the current attributes of all managed resources. When Terraform runs `plan` or `apply`, it first consults this cached state. This reduces the number of direct API calls to the cloud provider, especially for large infrastructures, thereby improving performance, reducing latency, and helping to stay within API rate limits.

Answer

Automatically applying changes when configuration files are saved.

Answer

Storing sensitive data like passwords and API keys.

Answer

Providing a backup of the infrastructure to restore in case of disaster.

Question 4

Match each Terraform state command to its action.

Accepted Answer

terraform state list: List resources in state. The correct matches are: terraform state list → List resources in state, terraform state show → Display details of a specific resource, terraform state mv → Move an item, terraform state rm → Remove an item. Common confusions include swapping list with rm or thinking mv is primarily for renaming.

Answer

terraform state list: Remove items from state

Answer

terraform state mv: Rename a resource

Question 5

After running `terraform state mv` to rename a resource, the resource's state binding is lost and the resource cannot be managed. Which command should be run to restore the state binding?

Accepted Answer

terraform import. After renaming a resource with terraform state mv, if the state binding is lost, the resource is no longer managed. The terraform import command can re-associate the existing resource with the Terraform configuration by importing it into the state, restoring management.

Answer

terraform state push

Answer

terraform state show

Answer

terraform state rm

Answer

terraform refresh

Question 6

A team uses a Consul backend for Terraform state. They want to encrypt state at rest. What should they do?

Accepted Answer

Use Vault Transit Engine to encrypt the state before storing. The `encrypt` argument in the Terraform Consul backend configuration is used to specify an encryption key for Consul's *gossip protocol*, which encrypts *inter-agent communication*. It does *not* encrypt the state data stored at rest within Consul's KV store. Consul's KV store does not provide native, transparent encryption of values at rest. To achieve state encryption at rest while using Consul as the backend, an external mechanism like HashiCorp Vault's Transit Engine (Option E) would typically be used to encrypt the state data *before* Terraform writes it to Consul. Therefore, option D does not achieve the stated goal of encrypting state at rest.

Answer

Store state in an encrypted S3 bucket instead

Answer

Use Terraform's built-in state encryption feature

Answer

It is not possible to encrypt state with the Consul backend

Answer

Enable encryption in the backend configuration using the `encrypt` argument

Question 7

Which of the following is NOT a valid backend type for storing Terraform state?

Accepted Answer

kubernetes. Kubernetes is not a valid backend type for storing Terraform state. Terraform backends determine where state is stored and how operations are executed; the officially supported backends include local, remote backends like S3, HTTP, and Terraform Cloud, but Kubernetes is not among them. While Kubernetes can be used to run Terraform in a pod, it does not serve as a state storage backend.

Answer

terraform cloud

Answer

local

Answer

s3

Answer

http

Question 8

Which TWO of the following are valid strategies to migrate Terraform state from a local backend to a remote backend?

Accepted Answer

Manually copy the local state file to the remote backend storage. Option B is correct because the state file is just a JSON artifact, so copying the local terraform.tfstate directly into the configured remote backend storage (e.g., an S3 bucket, GCS bucket, or Azure blob container) places the existing state where the remote backend expects it, after which terraform init can be run to bind to it. Option D is correct because after adding or changing the backend block, running terraform init -migrate-state prompts Terraform to copy the existing local state to the newly configured remote backend, preserving resource mappings. Option A is not a migration strategy: terraform import only associates existing infrastructure with resources in state and does not move an existing state file to a remote backend. Option C is incorrect because terraform init -reconfigure reinitializes the backend configuration but explicitly ignores the existing state migration path, so it does not copy local state to the remote backend. Option E is incorrect because terraform state push writes a local state file to the currently configured backend, but it is not the standard documented strategy for migrating from a local backend and requires the backend to already be initialized.

Answer

Use terraform import for each resource

Answer

Change backend configuration and run terraform init -reconfigure

Answer

Use the terraform state push command

Question 9

An organization uses Terraform Cloud workspaces to manage multiple environments. They notice that after promoting a configuration change from development to production workspace, the production workspace's state file contains references to resources that were only created in development. What is the most likely cause?

Accepted Answer

The user ran `terraform state mv` to move resource instances from development to production workspace.. The most likely cause is that the user ran `terraform state mv` to move resource instances from the development workspace to the production workspace. This command manually manipulates the state file, and if used incorrectly, it can move resources between workspaces, causing the production state to reference resources that only exist in development. This is a common mistake when trying to promote changes.

Answer

The workspaces were configured to use the same S3 backend and prefix, causing state overlap.

Answer

A user manually edited the production state file to include development resources.

Answer

The development workspace's output values were used in production via `terraform_remote_state`.

Question 10

A user runs `terraform plan` and notices that the plan includes 'Outgoing changes' for a number of resources that were not modified in the configuration. What is the most likely cause?

Accepted Answer

The resources were manually changed in the cloud provider.. When `terraform plan` shows 'Outgoing changes' for resources that were not modified in the configuration, it indicates that the actual state of the resources in the cloud provider has diverged from the desired state defined in the Terraform configuration. This phenomenon is known as 'drift'. The most common and direct cause of drift, especially when the configuration itself hasn't changed, is that the resources were manually modified outside of Terraform's management (Option B). While an 'outdated state file' (Option D) is a symptom of this drift, and `terraform plan` implicitly refreshes the state to detect these changes, the *root cause* of the state file being outdated and the drift occurring is the manual modification of resources in the cloud. Option D describes a symptom and a necessary action (refreshing the state to reflect reality), not the underlying cause of the drift itself. Option A (provider version change) can cause plan changes but is less directly related to 'drift' from manual changes. Option C (backend configuration change) is unrelated to resource drift.

Answer

The provider version has changed.

Answer

The backend configuration changed.

Answer

The state file is outdated and needs to be refreshed.