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

Question 1

A user runs `terraform apply` and receives an error: 'Error acquiring the state lock'. What is the most likely cause?

Accepted Answer

Another user is running a Terraform command that modifies state.. The error 'Error acquiring the state lock' means that another operation currently holds the lock on the state file. Option A is correct because if another user is running a Terraform command that modifies state (such as apply or destroy), the lock will be acquired and subsequent operations will fail. Option B is incorrect because a missing state file would produce a different error (e.g., 'No state file found'). Option C is incorrect because invalid backend configuration is caught during 'terraform init', not during 'apply'. Option D is incorrect because provider incompatibility typically leads to plugin-related errors, not state lock errors.

Answer

The state file is missing.

Answer

The backend configuration is invalid.

Answer

The Terraform provider is incompatible.

Question 2

A team uses an S3 backend with DynamoDB locking. They accidentally delete the DynamoDB table used for state locking. What is the immediate consequence?

Accepted Answer

Terraform commands that require state locking will fail with a locking error.. When the DynamoDB table is deleted, Terraform cannot acquire or release locks, so any command needing locking (apply, plan, destroy) will fail. Option A is correct. Option B is incorrect because Terraform will not proceed without lock; it returns an error. Options C and D are not automatic behaviors.

Answer

State operations will continue without locking, risking corruption.

Answer

Terraform will automatically create a new DynamoDB table.

Answer

The state file will be migrated to local storage.

Question 3

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 `terraform state mv` command can move resource instances from one workspace's state file to another, which explains why production state contains references to development resources. Option A (same backend/prefix) could cause state corruption but would not selectively move resources. Option C is unlikely and error-prone. Option D would allow reading outputs but not modify production state.

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 4

A user wants to use a remote state backend for the first time. After adding the backend configuration, which command must they run to migrate the state from local to remote?

Accepted Answer

`terraform init`. When you add a remote backend configuration to your Terraform code, `terraform init` is the required command to initialize the backend and migrate the existing local state file to the remote backend. During initialization, Terraform detects the backend change, prompts for confirmation, and automatically copies the state from the local `terraform.tfstate` to the configured remote store (e.g., S3, Azure Storage, or Terraform Cloud). Without running `init`, the remote backend is not configured and local state remains unchanged.

Answer

`terraform plan`

Answer

`terraform apply`

Answer

`terraform state push`

Question 5

During a deployment, a user runs `terraform apply` but the command fails because the state lock cannot be acquired. They suspect the lock was released after the previous `apply` but is still held. What command can they use to force unlock the state?

Accepted Answer

`terraform force-unlock <lock_id>`. When Terraform cannot acquire a state lock because it was not properly released (e.g., after a crash or interrupted apply), the `force-unlock` command is the only built-in way to manually break the lock. You must provide the lock ID (obtained from the error message or backend) to override the lock, which is stored in the backend (e.g., DynamoDB, Consul) and prevents concurrent modifications. This command is designed for recovery scenarios where the lock holder is known to be dead.

Answer

`terraform init -force-copy`

Answer

`terraform state unlock`

Answer

`terraform break-lock`

Question 6

A Terraform state file is stored in an S3 bucket with versioning enabled. During a deployment, the state file becomes corrupted due to a network error. What is the best way to recover?

Accepted Answer

Restore the previous version of the state file from S3 versioning.. S3 versioning preserves previous versions of objects, including Terraform state files. When the current state file becomes corrupted, you can restore a prior, uncorrupted version directly from the S3 bucket without data loss or manual re-creation of resources. This is the safest and most efficient recovery method.

Answer

Use `terraform state pull` to overwrite the corrupted state.

Answer

Run `terraform import` to import all resources.

Answer

Delete the state file and run `terraform apply` to recreate all resources.

Question 7

Which command can be used to see the current state of a specific resource in the Terraform state?

Accepted Answer

`terraform state show `. The `terraform state show ` command is specifically designed to display the attributes and current state of a single resource as recorded in the Terraform state file. This allows you to inspect the exact values Terraform is tracking for that resource, which is essential for debugging drift or understanding the current infrastructure representation.

Answer

`terraform output`

Answer

`terraform state list`

Answer

`terraform show`

Question 8

A team uses a remote state backend with partial configuration. They have a `backend` block with only the `bucket` attribute, and the rest of the backend configuration is provided via CLI during `terraform init`. Which of the following best describes the purpose of partial configuration?

Accepted Answer

It allows sensitive backend configuration to be provided dynamically, avoiding hardcoding.. Partial configuration in Terraform remote state backends allows you to split backend settings between the `backend` block in your configuration and dynamic inputs provided at `terraform init` time. This is especially useful for sensitive values like access keys or secret tokens, which can be supplied via CLI flags, environment variables, or interactive prompts, thereby avoiding hardcoding them in version-controlled files. Option D correctly identifies this primary purpose of enhancing security and flexibility.

Answer

It reduces the number of files needed for configuration.

Answer

It is required when using Terraform Cloud.

Answer

It enables state locking.

Question 9

Which two statements about Terraform state files are true? (Choose two.)

Accepted Answer

State files are used to map configuration to real-world resources.. Terraform state files serve as a mapping between configuration and real-world resources (C). They can contain sensitive data such as database passwords or resource attributes (E). However, state files are not automatically encrypted by all backends; encryption depends on the backend configuration (A false). State files should not be stored in version control due to potential sensitive content (B false). Concurrent writes to state files can cause corruption or conflicts, so sharing without locking is problematic (D false).

Answer

State files are automatically encrypted at rest by all backends.

Answer

State files should be stored in version control.

Answer

State files can be shared across multiple users simultaneously without issues.

Question 10

A team uses an S3 backend for state storage with DynamoDB locking. They want to migrate to a new S3 bucket. Which two steps are necessary to perform a successful state migration? (Choose two.)

Accepted Answer

Run `terraform init -reconfigure` to update the backend configuration.. `terraform init -reconfigure` forces Terraform to reinitialize the backend and apply the new backend configuration from the `backend` block without prompting for confirmation. Option E is correct because the `backend` block in the Terraform configuration must be updated to reference the new S3 bucket name; Terraform reads this block during initialization to determine where to store and retrieve state. Together, these steps ensure Terraform knows the new backend location and can properly manage state going forward.

Answer

Run `terraform plan` to verify no resource changes before migration.

Answer

Delete the old state file after migration.

Answer

Manually copy the state file from the old bucket to the new bucket.

Question 11

Refer to the exhibit. A user has this backend configuration. The user then runs `terraform init` and receives an error: 'NoSuchBucket: The specified bucket does not exist'. What is the most likely cause?

Accepted Answer

The bucket does not exist and needs to be created.. The error 'NoSuchBucket: The specified bucket does not exist' directly indicates that the S3 bucket referenced in the backend configuration does not exist in the AWS account. Terraform requires the S3 bucket to already exist before running `terraform init` because it needs to store the state file; it does not create the bucket automatically. Therefore, the most likely cause is that the bucket has not been created yet.

Answer

The AWS region is wrong.

Answer

The DynamoDB table is missing.

Answer

The credentials lack S3 permissions.

Question 12

Refer to the exhibit. A user runs `terraform plan` and receives this error. The user is using a local backend. Which of the following is the most likely cause?

Accepted Answer

The configured state file path's directory does not exist.. With a local backend, Terraform stores state in a local file, typically `terraform.tfstate`. The error indicates that the directory specified for the state file path does not exist. Terraform requires the parent directory to exist before it can write the state file; if it is missing, the plan fails with this error.

Answer

The workspace is not selected correctly.

Answer

The state file is corrupted.

Answer

The backend is misconfigured for remote state.

Question 13

A team uses an S3 backend for Terraform state. During a `terraform apply`, another team member accidentally runs a plan that also modifies the same state. Which feature prevents state corruption in this scenario?

Accepted Answer

State locking via DynamoDB. State locking via DynamoDB prevents concurrent modifications to the state file, ensuring that only one operation can modify the state at a time. Option A (-lock=false) disables locking, which would allow concurrent modifications and risk corruption. Option B (Terraform Cloud remote operations) is not directly related to state locking in this S3 backend scenario. Option D (state versioning) helps recover from corruption but does not prevent simultaneous writes.

Answer

The `-lock=false` flag

Answer

Terraform Cloud remote operations

Answer

State versioning in S3

Question 14

An organization stores state files in an S3 backend with encryption. However, some resource attributes (e.g., database passwords) are stored in plaintext within the state. What is the recommended approach to avoid storing sensitive values in state?

Accepted Answer

Use a secrets backend like Vault to retrieve secrets at runtime and store only references in state. Terraform can mark outputs as sensitive to hide them from display, but they may still be stored in state. Option A is a common practice to avoid storing secrets directly.

Answer

Set the `sensitive` parameter on all resources

Answer

Enable state encryption with a stronger algorithm

Answer

Use the `terraform state rm` command after apply to remove sensitive attributes

Question 15

A team is migrating from local state to an S3 remote backend. They have existing state files in the working directory. After configuring the backend block and running `terraform init`, what is the correct next step to migrate the existing state?

Accepted Answer

Execute `terraform init` and confirm yes when prompted to copy existing state. When migrating from local to remote state, Terraform automatically prompts to copy existing state during `terraform init` if the backend block changes. Selecting 'yes' will migrate the state. Option A correctly describes this process.

Answer

Run `terraform state push` to upload the local state

Answer

Delete the local state file and run `terraform apply` to recreate

Answer

Manually copy the state file to S3 using AWS CLI