TF-003 Implement and maintain state — Timed 40 Questions

Question 1

A team is using a remote backend in Terraform Cloud. After a failed apply, the state file is locked. The team lead wants to unlock the state immediately. What should be done?

Accepted Answer

Run terraform force-unlock with the lock ID. The `terraform force-unlock` command with the lock ID is the correct way to manually unlock a state file in Terraform Cloud after a failed apply. This command overrides the backend's lock mechanism, which is designed to prevent concurrent modifications and state corruption. Deleting or editing the state file would bypass Terraform's safety guarantees and risk data loss or inconsistency.

Answer

Delete the state file from the backend and reinitialize

Answer

Manually edit the state file to remove the lock

Answer

Run terraform unlock

Question 2

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?

Accepted Answer

Run terraform force-unlock with the lock ID. The correct answer is B because 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 3

A developer is working on a Terraform configuration that manages a single resource. They want to import an existing AWS EC2 instance into state. Which command should they use?

Accepted Answer

terraform import. Option C is correct because `terraform import` is the dedicated command for bringing an existing infrastructure resource (like an AWS EC2 instance) under Terraform management by attaching it to a resource block in the state file. It requires the resource address and the provider-specific ID (e.g., `aws_instance.my_instance i-1234567890abcdef0`) to map the real-world resource into the Terraform state without modifying the resource itself.

Answer

terraform apply

Answer

terraform refresh

Answer

terraform state mv

Question 4

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. Option C is correct because 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., `key = "${var.env}/terraform.tfstate"`), each workspace can resolve to a different storage path or even a different backend type when combined with workspace-specific `-backend-config` files. This allows the production and development workspaces to store their state in entirely different backends 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 5

After running terraform apply, you see the error: 'Error: Error loading state: state snapshot was created by Terraform v0.12.0, but this is Terraform v1.2.0'. What should you do to resolve this?

Accepted Answer

Run terraform apply with no changes to upgrade the state format. Option B is correct because running `terraform apply` with no changes triggers Terraform to automatically upgrade the state file format to the version compatible with the current Terraform binary (v1.2.0). Terraform state files are versioned internally, and when a newer version of Terraform reads an older state format, it performs an in-place upgrade during the next state write operation, such as an apply that results in no changes. This avoids manual intervention or data loss.

Answer

Run terraform state upgrade

Answer

Delete the state file and reimport resources

Answer

Downgrade Terraform to v0.12.0

Question 6

A user wants to remove a specific resource from Terraform state without destroying the actual infrastructure. Which command should they use?

Accepted Answer

terraform state rm resource. The `terraform state rm` command is the correct choice because it removes a specified resource from the Terraform state file without making any API calls to the actual infrastructure provider. This allows the resource to be detached from Terraform management while leaving the real-world resource running, which is exactly what the user wants.

Answer

terraform taint resource

Answer

terraform state mv resource

Answer

terraform destroy -target=resource

Question 7

A company uses Terraform to manage infrastructure across multiple AWS accounts. They want to use a single S3 bucket to store state files for all accounts, but ensure that state files are isolated per account. What is the best approach?

Accepted Answer

Use separate state files with unique S3 key prefixes per account. Option B is correct because using separate state files with unique S3 key prefixes per account ensures that each AWS account's Terraform state is stored in the same S3 bucket but logically isolated. This approach leverages S3's hierarchical key structure to prevent cross-account state contamination, while still allowing centralized management. Terraform's backend configuration supports dynamic key prefixes (e.g., `key = "account-${var.account_id}/terraform.tfstate"`), enabling per-account isolation without requiring separate buckets or workspaces.

Answer

Use Terraform workspaces with a single state file

Answer

Store all state in the same S3 key

Answer

Use a DynamoDB table with different lock IDs per account

Question 8

Which TWO of the following are valid methods to share data between Terraform configurations?

Accepted Answer

Store shared data in a common backend and read it via data sources. Option D is correct because storing shared data in a common backend (e.g., an S3 bucket with DynamoDB locking) and reading it via data sources (like the `terraform_remote_state` data source) allows different Terraform configurations to consume outputs from one another without duplicating state or breaking isolation. This pattern is the recommended way to share data across configurations because it leverages the backend's locking and consistency guarantees.

Answer

Use output variables across configurations

Answer

Use modules to share state

Answer

Use depends_on to pass values

Question 9

Which THREE of the following are best practices for managing Terraform state?

Accepted Answer

Use remote backends to store state files. Remote backends (e.g., S3, Azure Storage, Terraform Cloud) store state outside the local filesystem, enabling team collaboration, durability, and integration with state locking and encryption. This prevents loss of state due to local machine failure and ensures all team members work from the same state file, which is critical for consistent infrastructure management.

Answer

Edit state files directly to fix drift

Answer

Store state files locally to avoid network latency

Question 10

Which TWO of the following are true about Terraform workspaces?

Accepted Answer

The default workspace is named 'default'. Option D is correct because when you create a Terraform workspace, the default workspace is automatically named 'default'. This is the workspace that exists in every Terraform backend configuration unless you explicitly create or switch to another workspace. The name 'default' is a reserved identifier for the initial workspace.

Answer

Workspaces can be used to manage different provider configurations

Answer

All workspaces share the same state file

Answer

The default workspace can be deleted

Question 11

You are a DevOps engineer at a company that uses Terraform to manage infrastructure in AWS. The team recently adopted Terraform Cloud for remote state management and collaboration. They have a single workspace named 'production' that manages all production resources. Currently, the state file is stored in Terraform Cloud's default backend. The team wants to implement a disaster recovery strategy where they can restore the state file if Terraform Cloud experiences an outage. They also want to ensure that state file backups are taken automatically before every apply. Which approach should they recommend?

Accepted Answer

Use Terraform Cloud's API to download the state file before each apply and store it in a secure S3 bucket with versioning enabled. Option D is correct because it provides an automated, auditable backup of the Terraform state file before each apply, using Terraform Cloud's API to download the state and storing it in an S3 bucket with versioning enabled. This ensures disaster recovery capability independent of Terraform Cloud's availability, while versioning allows rollback to any previous state backup. The approach aligns with the requirement for automatic backups before every apply without altering the remote execution model.

Answer

Manually download the state file from Terraform Cloud UI after each apply

Answer

Enable S3 replication on Terraform Cloud's internal state storage

Answer

Switch to an S3 backend with DynamoDB locking and configure Terraform Cloud to run remotely but store state locally

Question 12

A team manages infrastructure with Terraform and uses a remote backend in an S3 bucket. After a recent state migration, a developer runs 'terraform plan' and gets an error: 'Error: Error loading state: NoSuchKey: The specified key does not exist.' The developer confirms that the state file exists in the bucket. What is the most likely cause?

Accepted Answer

The backend configuration in the Terraform code does not match the actual state file path.. The error 'NoSuchKey: The specified key does not exist' indicates that Terraform is looking for the state file at a specific key (path) in the S3 bucket, but that key does not exist. Since the developer confirms the state file exists in the bucket, the most likely cause is a mismatch between the backend configuration in the Terraform code (e.g., the `key` argument) and the actual path where the state file is stored. This often happens after a state migration if the backend configuration was not updated to reflect the new location.

Answer

Terraform state locking is enabled but the lock was not released.

Answer

The S3 bucket policy does not allow reading the state file.

Answer

S3 bucket versioning is enabled, and the state file is a non-current version.

Question 13

An organization uses Terraform with the AzureRM backend. The team recently split a large configuration into multiple smaller configurations, each with its own state file. They want to share outputs from one configuration (networking) as inputs to another (compute). Which approach should they use to reference the networking state from the compute configuration without duplicating data?

Accepted Answer

Use a 'data' 'terraform_remote_state' block in the compute configuration to read the networking state.. Option C is correct because the `terraform_remote_state` data source allows one Terraform configuration to read the root-level output values from another configuration's state file stored in the AzureRM backend. This enables sharing of networking outputs (e.g., subnet IDs) into the compute configuration without duplicating data or manually exporting values. The data source retrieves the state directly from the configured backend, ensuring the compute configuration always uses the latest networking outputs.

Answer

Define output values in the networking configuration and they will be automatically available in the compute configuration.

Answer

Run 'terraform output' on the networking state and save the values to a JSON file, then use 'terraform_remote_state' to read them.

Answer

Hardcode the subnet IDs from the networking configuration into the compute configuration.

Question 14

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

Accepted Answer

Improving performance for large infrastructures by caching resource attributes.. Option D is correct because Terraform state acts as a cache for resource attributes, which significantly improves performance for large infrastructures. By storing the current state of resources locally or remotely, Terraform avoids making repeated API calls to the cloud provider for every `plan` or `apply` operation, reducing latency and API rate limits. This caching mechanism is essential for efficiently managing complex deployments with hundreds or thousands of resources.

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 15

You are a DevOps engineer for a company that uses Terraform to manage infrastructure across multiple AWS accounts (production, staging, development). Each account has its own Terraform configuration and remote state stored in an S3 bucket with DynamoDB locking. Recently, the production deployment pipeline failed with the error: 'Error: Error loading state: AccessDenied: Access Denied'. The pipeline runs under an IAM role that has been working for months. The S3 bucket policy and IAM role permissions have not been changed. However, the team did recently enable S3 bucket versioning and added a lifecycle policy to transition objects to Glacier after 30 days. The state file was last modified 35 days ago. What is the most likely cause of the error?

Accepted Answer

The state file was transitioned to Amazon S3 Glacier by the lifecycle policy, and Terraform cannot read it without restoration.. D is correct because the S3 lifecycle policy transitions objects to the Glacier storage class after 30 days. The state file was last modified 35 days ago, so it has been moved to Glacier. Terraform cannot read objects in the Glacier storage class directly; it requires a restoration (e.g., using `aws s3api restore-object`) before the state can be accessed, resulting in the 'AccessDenied' error.

Answer

The DynamoDB lock table has a stale lock from a previous deployment that is blocking read access.

Answer

The IAM role's permissions were inadvertently revoked due to a recent AWS policy change.

Answer

The S3 bucket policy now denies access to objects older than 30 days due to a new condition key.

Question 16

A team is using a shared backend for Terraform state. After running terraform apply, the state file is locked for an extended period, causing other team members to fail with 'Error acquiring the state lock'. What is the most likely cause?

Accepted Answer

A previous terraform apply command was interrupted or crashed, leaving a stale lock.. Option A is correct because Terraform uses a locking mechanism (typically via DynamoDB for AWS S3 backends) to prevent concurrent state modifications. If a `terraform apply` is interrupted or crashes, the lock may not be released, leaving a stale lock entry. This causes subsequent operations to fail with 'Error acquiring the state lock' until the lock is manually removed or expires (if TTL is configured).

Answer

Another team member is actively running terraform apply on the same state.

Answer

The backend configuration was changed without running terraform init.

Answer

The state file contains resources that no longer exist in the cloud provider.

Question 17

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.. Option B is correct because `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.

Question 18

Which four of the following statements about Terraform state management are correct? (Choose all that apply. There are four correct answers.)

Accepted Answer

Sensitive data stored in state files can be protected by encrypting the state backend at rest.. Remote state backends like S3 or Azure Storage support state locking (via DynamoDB or Azure Blob lease) to prevent concurrent modifications, ensuring consistency. The `terraform state rm` command removes a resource from state without destroying the real infrastructure, which is useful for detaching management. Encrypting the state backend at rest (e.g., S3 server-side encryption or Azure Storage encryption) protects sensitive data like passwords or keys stored in the state file. The `terraform import` command updates the state file to include an existing resource, allowing Terraform to take over its management without recreating it.

Answer

Terraform automatically backs up the previous state file every time a new state is written.

Answer

The `terraform state list` command can modify the state file to rename a resource.

Question 19

Drag and drop the steps to use Terraform modules from the registry in the correct order.

Question 20

Match each Terraform state command to its action.