TF-004 Implement and maintain state Practice Test 2 — 15 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 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. `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 3

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

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 5

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

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

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 8

Which TWO of the following are true about Terraform workspaces?

Accepted Answer

The default workspace is named 'default'. The default workspace is named 'default'. Option E is correct because each Terraform workspace maintains its own separate state file, allowing state isolation for different environments. Option A is incorrect because workspaces do not manage provider configurations; they only separate state. Option B is false because each workspace has its own state file, not shared. Option C is false because the default workspace cannot be deleted.

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 9

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. It leverages the Terraform Cloud API to programmatically download the state file before each apply, storing it in a customer-managed S3 bucket with versioning enabled. This creates automatic, auditable backups independent of Terraform Cloud's availability, satisfying the disaster recovery requirement without changing the remote execution model. Options A and C are either manual or incompatible with Terraform Cloud's remote state management, and option B is not possible as Terraform Cloud does not expose its internal storage for replication.

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 10

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 11

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

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 13

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

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.

Question 15

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

Accepted Answer

The `terraform import` command updates the state file to include an existing resource, enabling Terraform to manage it.. 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

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

Answer

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