TF-004 Implement and maintain state Practice Test 3 — 15 Questions

Question 1

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?

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

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 2

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 3

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 4

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 5

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 E is correct because you must declare a backend block (for example, backend "s3" or backend "azurerm") in the Terraform configuration so Terraform knows which remote backend to use. Option B is correct because after adding the backend block you run terraform init, which initializes the backend and, when existing local state is detected, offers to copy it to the new remote backend. Option D is correct because terraform init prompts 'Do you want to copy existing state to the new backend?' and you must confirm by typing 'yes' to complete the migration. Option A is wrong because deleting the local state file first would destroy the state that needs to be migrated. Option C is wrong because terraform import is used for bringing existing infrastructure under management, not for migrating an already-tracked state file to a remote backend.

Answer

Remove the local state file before running terraform init.

Answer

Manually import all existing resources into the remote state.

Question 6

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

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 7

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

Accepted Answer

Write the module block in main.tf, then run terraform init, then set input variables in terraform.tfvars, then run terraform plan and terraform apply.. Registry modules are sourced; init downloads, variables configure, plan/apply deploy.

Answer

Run terraform init, then write the module block, then set input variables, then run terraform plan and apply.

Answer

Write the module block, then set input variables, then run terraform init, then run terraform plan and apply.

Answer

Write the module block, then run terraform plan and apply, then run terraform init, then set input variables.

Question 8

A company uses Terraform with an S3 backend. A user accidentally deletes the state file. What is the best practice to recover the state?

Accepted Answer

Restore the state file from S3 bucket versioning. When using Terraform with an S3 backend, the state file is stored in S3. If it is accidentally deleted, the best recovery method is to restore it from an S3 bucket versioning-enabled bucket, which retains previous versions of objects. This restores the exact state file, preserving resource mappings and metadata, and avoids the need to re-import or recreate resources.

Answer

Use terraform state pull from the local cache

Answer

Use terraform import on all resources

Answer

Recreate the state from a terraform plan

Answer

Restore from the local terraform.tfstate.backup

Question 9

A developer runs `terraform apply` and receives the error: 'Error acquiring the state lock'. Another engineer is currently running `terraform plan`. What should the developer do?

Accepted Answer

Wait for the lock to be released automatically. Terraform uses a state locking mechanism to prevent concurrent modifications that could corrupt the state file. When another engineer is running `terraform plan`, the lock is held for the duration of the plan to ensure consistency. The lock will be automatically released once the plan completes or times out, so waiting is the appropriate action.

Answer

Run terraform init to reinitialize the backend

Answer

Run terraform force-unlock with the lock ID

Answer

Run terraform plan with -lock=false to bypass the lock

Answer

Delete the lock file from the S3 bucket

Question 10

In a CI/CD pipeline, Terraform state is stored in Terraform Cloud. A pipeline run fails with the error: 'State version conflict'. What is the most likely cause?

Accepted Answer

Two runs started at the same time. Terraform Cloud enforces state locking so that only one run can modify a given workspace's state at a time. When two runs (e.g., concurrent pipeline jobs, or a manual run overlapping a CI run) attempt to write state simultaneously, the second run fails with a 'state version conflict' because the state serial it read is no longer current. This is the classic concurrency symptom.

Answer

Authentication failure with Terraform Cloud

Answer

Missing or incorrect backend configuration

Answer

State file exceeds maximum size limit

Answer

Terraform version mismatch between local and remote

Question 11

An organization uses a shared remote backend. They want to prevent concurrent apply operations that could corrupt the state. What built-in mechanism does Terraform provide?

Accepted Answer

State locking. Terraform's state locking mechanism prevents concurrent operations that could corrupt the state file by acquiring a lock on the backend before running `plan` or `apply`. When using a shared remote backend, the lock is held for the duration of the operation and released upon completion, ensuring only one process modifies the state at a time. Option D refers to state file versioning, which provides the ability to recover previous versions but does not prevent concurrent writes.

Answer

File permissions on the remote state file

Answer

Workspace isolation

Answer

State file versioning

Answer

Backend versioning

Question 12

What is the purpose of the `terraform state list` command?

Accepted Answer

List all resources in the current state file. `terraform state list` lists all resources currently tracked in the Terraform state file, providing their resource addresses. Option B correctly describes this. Option A is incorrect because `terraform state list` does not show planned resources; that is the role of `terraform plan`. Option C lists resources from configuration (not from state), D lists workspaces, and E lists providers.

Answer

List all resources that would be created by the current plan

Answer

List all resources defined in the Terraform configuration

Answer

List all available workspaces

Answer

List all providers used in the configuration

Question 13

A user wants to inspect the current attributes of a specific resource in the Terraform state. Which command should they use?

Accepted Answer

terraform state show . The `terraform state show ` command is specifically designed to inspect the current attributes of a single resource within the Terraform state file. It reads the state directly and outputs the resource's attributes in a human-readable format, making it the correct tool for this task.

Answer

terraform state list <resource>

Answer

terraform output

Answer

terraform plan

Answer

terraform show

Question 14

Which TWO actions will cause Terraform to update the state file?

Accepted Answer

terraform destroy. terraform destroy (B) is correct because it removes all resources managed by the configuration and writes the resulting empty resource set back to the state file, updating it to reflect that nothing is managed. terraform apply (C) is correct because it executes the planned changes against real infrastructure and then persists the new resource attributes, IDs, and dependencies into the state file. The other commands do not modify state: terraform fmt (A) only reformats HCL files, terraform validate (D) only checks configuration syntax and internal consistency, and terraform plan (E) merely refreshes and computes a proposed diff without writing changes to the state file.

Answer

terraform fmt

Answer

terraform validate

Answer

terraform plan

Question 15

Which TWO statements are correct about Terraform state when using the S3 backend with DynamoDB for state locking?

Accepted Answer

The DynamoDB table must exist before running terraform init. Option A is correct because Terraform's S3 backend with DynamoDB locking requires the DynamoDB table (with a partition key of LockID) to already exist before terraform init, since init validates and configures the backend and will fail if the table is missing. Option B is correct because enabling versioning on the S3 bucket is a recommended practice that supports state recovery and consistency, allowing you to roll back to a previous state version if corruption or accidental deletion occurs. Option C is incorrect because the S3 backend configuration requires a key parameter specifying the path to the state file within the bucket. Option D is incorrect because S3 server-side encryption is not enabled by default for Terraform state; you must explicitly configure encrypt = true or apply bucket-level encryption. Option E is incorrect because DynamoDB state locking prevents concurrent write operations that could corrupt state, not read operations.

Answer

State can be stored without specifying a key in the backend configuration

Answer

State is encrypted at rest by default using SSE

Answer

State locking prevents any read operations on the state file