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

Question 1

An organization uses Terraform workspaces to manage multiple environments (dev, staging, prod) with the same configuration. What is the primary benefit of using workspaces for state management?

Accepted Answer

Each workspace has its own independent state file, preventing environment conflicts. Terraform workspaces allow each environment (dev, staging, prod) to maintain its own independent state file within the same backend configuration. This isolation prevents state conflicts, such as one environment's resources being accidentally overwritten or destroyed by operations intended for another environment, which is critical for safe multi-environment management.

Answer

Workspaces reduce the number of Terraform configurations needed

Answer

Workspaces automatically synchronize state across team members

Answer

Workspaces enable role-based access control to state

Question 2

A user accidentally ran `terraform state rm` on a critical resource, removing it from state but not destroying the actual infrastructure. Later, they need to re-import the resource. Which sequence of commands correctly accomplishes this?

Accepted Answer

`terraform import` using the resource address and ID of the resource. After removal, the resource is unmanaged. `terraform import` re-associates it with state. Option D is the correct sequence.

Answer

`terraform state push` with the original state file

Answer

`terraform plan` and then `terraform apply`

Answer

`terraform refresh` and then `terraform plan`

Question 3

Which TWO of the following are required when configuring a Terraform backend for remote state storage?

Accepted Answer

A backend type (e.g., s3, azurerm, gcs). Every Terraform backend configuration must specify a backend type (e.g., s3, azurerm, gcs) to define where state is stored. Option E is correct because authentication credentials are required to access the remote backend; without valid credentials, Terraform cannot read or write state to the configured storage location.

Answer

Encryption at rest configuration

Answer

State locking support

Answer

Workspace configuration

Question 4

Which THREE of the following are best practices for Terraform state management in a team environment?

Accepted Answer

Use separate state files for different environments (dev, prod). Best practices for Terraform state management in a team environment include using separate state files for different environments (dev, prod) to isolate changes, enabling state locking to prevent concurrent modifications and conflicts, and storing state files in a remote backend shared by the team to enable collaboration and persistence. Option B (storing state in a version control repository) is not recommended because state files can contain sensitive data and are prone to conflicts when multiple team members apply changes concurrently. The correct options are A, C, and D.

Answer

Store state files in a version control repository

Answer

Manually edit the state file to correct drift

Question 5

Refer to the exhibit. A Terraform configuration includes an `aws_instance.web` resource. The state shows the instance with a specific AMI and instance type. After running `terraform plan`, Terraform reports no changes. However, an engineer observes that the actual instance in AWS has a different AMI ID but the same instance type. What is the most likely cause?

Accepted Answer

The state file has not been refreshed since the manual AMI change; it still reflects the old AMI. The state file is stale because it has not been refreshed since the AMI was manually changed outside of Terraform. When `terraform plan` runs, by default it first refreshes the state, but if the manual change occurred before the last refresh, the plan would have detected drift. However, if no refresh has occurred after the manual change, the plan compares the configuration with the old state, showing no changes. The issue is that the state file still reflects the old AMI. Option B correctly identifies that the state has not been refreshed since the manual change.

Answer

The instance type was modified after the last apply, but AMI was not

Answer

The `terraform plan` command ignores drift by default

Answer

The AMI data source is returning a different value each time

Question 6

A DevOps engineer manages infrastructure with Terraform using an S3 backend with DynamoDB locking. During a `terraform apply`, the engineer's network connection drops. After reconnecting, they run `terraform plan` and get an error: "Error acquiring the state lock." The lock is from the previous session. The engineer has verified that no other operations are running. What is the appropriate next step to proceed?

Accepted Answer

Use `terraform force-unlock <lock_id>` to remove the stale lock. `terraform force-unlock` is the intended mechanism to manually remove a stale lock from the DynamoDB table when the process that held the lock has terminated abnormally. The engineer has confirmed no other operations are running, so the lock is orphaned and safe to remove. This command requires the specific lock ID, which is provided in the error message.

Answer

Delete the DynamoDB table and recreate it

Answer

Wait 15 minutes for the lock to expire automatically

Answer

Run `terraform init` to reset the backend connection

Question 7

A company manages multiple microservices across AWS accounts. Each service has its own Terraform configuration and state file stored in a shared S3 bucket. The team uses `terraform_remote_state` data sources to read outputs from other services' state files. A service team recently changed the output structure in their state, breaking the `terraform_remote_state` calls from other services. The affected services now show errors during plan. What is the best practice to avoid such cross-service dependency issues?

Accepted Answer

Publish service outputs to a dedicated data store (e.g., AWS SSM Parameter Store or Consul) and have other services consume those values instead of reading state directly. The best practice is to decouple services by using a dedicated data store (e.g., AWS SSM Parameter Store or Consul) as a service registry or contract. This avoids tight coupling to the internal state representation of another service. Option A correctly implements this pattern. Option D (CMDB) is overly generic and not specifically designed for Terraform state outputs. Options B and C are reactive measures, not proactive best practices.

Answer

Use versioning on the S3 bucket and revert to a previous state version

Answer

Lock the state files and require approval for any changes

Answer

Store outputs in a configuration management database and read from there

Question 8

A new developer joins a project that uses Terraform with a remote backend in GCS (Google Cloud Storage). They clone the repository and run `terraform init` successfully. However, when they run `terraform plan`, they get an error: "Error loading state: AccessDenied: 403 my-project-terraform-state@my-project.iam.gserviceaccount.com does not have storage.objects.get access to the Google Cloud Storage bucket." What is the most likely resolution?

Accepted Answer

Grant the `Storage Object Viewer` role to the service account on the GCS bucket. The error 'AccessDenied: 403 ... does not have storage.objects.get access' indicates that the service account used by Terraform lacks read permissions on the GCS bucket. Granting the 'Storage Object Viewer' role to that service account on the bucket provides the necessary `storage.objects.get` permission, allowing Terraform to read the state file. Option C is correct; options A, B, and D are not appropriate solutions.

Answer

Disable access control on the bucket temporarily

Answer

Run `terraform init -reconfigure` to regenerate the backend configuration

Answer

Change the backend to local state and commit the state to the repository

Question 9

Which TWO statements about Terraform state locking are correct?

Accepted Answer

State locking prevents concurrent modifications to the same state file.. State locking prevents concurrent modifications to the same state file, ensuring consistency. Option E is correct because state locking relies on backend support; for example, S3 requires a DynamoDB table to enable locking. Option B is false because local state backends do not support locking; it is not enabled by default. Option C is false because Terraform Cloud fully supports state locking automatically. Option D is false because state locking is necessary for any operation that modifies state, even with a single user, to prevent corruption.

Answer

State locking is enabled by default when using a local state backend.

Answer

State locking is not supported in Terraform Cloud.

Answer

State locking is only necessary when multiple team members are running terraform apply simultaneously.

Question 10

A team of five engineers manages infrastructure using Terraform with remote state stored in an S3 bucket and state locking via a DynamoDB table. After a power outage, an engineer notices that a terraform apply command fails with the message: 'Error: Error acquiring the state lock'. The engineer suspects that a lock from a previous run has not been released. The team needs to proceed with applying changes. Which action should the engineer take to resolve the issue safely?

Accepted Answer

Run terraform force-unlock with the lock ID obtained from the error message.. The `terraform force-unlock` command is the intended safe method to release a stuck lock when the lock holder process is confirmed dead. The lock ID is provided in the error message. Option A is incorrect because Terraform state locks do not have a default automatic expiration; they must be explicitly released. Option B is risky: directly deleting the lock record from DynamoDB can lead to inconsistent state if not done carefully, and is not recommended as a standard practice. Option D bypasses locking entirely with `-lock=false`, which can cause state corruption if other operations are in progress, so it is unsafe.

Answer

Wait for the lock to expire automatically (locks have a 5-minute TTL).

Answer

Delete the lock record from the DynamoDB table using the AWS CLI.

Answer

Run terraform apply with the -lock=false flag to bypass locking.

Question 11

Refer to the exhibit. A team member receives this error when running terraform apply. What is the most likely cause?

Accepted Answer

A previous Terraform process was terminated abruptly, leaving a stale lock.. The lock info shows an operation type "OperationTypeInvalid", which typically occurs when a previous Terraform process was terminated abruptly (e.g., Ctrl+C, crash), leaving the lock in place.

Answer

The state file is corrupted and needs to be restored from backup.

Answer

Another user is currently running terraform apply on the same state.

Answer

The S3 bucket containing the state has been deleted.

Question 12

Refer to the exhibit. A developer updates the network state and runs terraform apply. The aws_instance.web is not recreated. Which statement explains this behavior?

Accepted Answer

The instance resource does not reference the remote state data source, so changes to the remote state do not trigger recreation.. The data source data.terraform_remote_state.network is read during planning and is not stored in state. If the remote state changes, Terraform will see the new vpc_id and may update the security group, but the instance resource does not depend on the remote state, so it is not affected.

Answer

Terraform automatically locks the remote state to prevent changes during apply.

Answer

The security group resource depends on the remote state, and it was updated, but the instance was not affected.

Answer

The remote state data source is cached and only refreshes every hour.

Question 13

Refer to the exhibit. A developer creates a new Terraform configuration with this backend block and runs terraform init. What will happen?

Accepted Answer

Terraform will return an error and fail to initialize.. The backend block is missing required arguments (like bucket and region). Terraform will return an error during initialization and will not proceed.

Answer

Terraform will initialize with a local backend because the remote backend configuration is incomplete.

Answer

Terraform will use default values for the missing arguments and initialize successfully.

Answer

Terraform will prompt the developer interactively for the missing arguments.

Question 14

Refer to the exhibit. A developer runs terraform plan and sees "No changes". However, the developer knows that manual changes were made to the infrastructure outside Terraform. What is the most likely reason terraform plan does not detect the drift?

Accepted Answer

The manual changes were made to resources not managed by Terraform.. Terraform plan detects drift by comparing the current configuration against the state file, but only for resources that Terraform manages. If manual changes are made to resources that are not recorded in Terraform's state (i.e., resources created outside of Terraform or not imported), then plan will not detect them because those resources are unknown to Terraform. Options B, C, and D are incorrect: B is false because plan can detect drift with refresh; C is not necessarily true as the changes may still exist; D is false because modern Terraform refreshes state by default before planning, but that refresh only applies to managed resources.

Answer

Terraform only detects drift when running terraform apply.

Answer

The manual changes were reverted before the plan was run.

Answer

Terraform plan does not refresh state by default; it uses the existing state file.

Question 15

Refer to the exhibit. An engineer runs the commands shown in sequence. After executing 'terraform state rm', the next 'terraform plan' shows that the resource will be created. What is the most likely reason?

Accepted Answer

The 'terraform state rm' command only removes the resource from the state file, not the actual infrastructure. The next plan sees the configuration and attempts to create a new resource.. The 'terraform state rm' command removes the resource from the state file but does not destroy the actual infrastructure. The resource still exists in AWS. The next 'terraform plan' sees that the resource is not in state but the configuration still exists, so it plans to create a new resource with the same configuration.

Answer

The 'terraform state rm' command triggers an automatic recreation of the resource.

Answer

The resource was destroyed by a separate process.

Answer

The state file was corrupted after removal.