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

Question 1

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?

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

Accepted Answer

State locking via DynamoDB. When using an S3 backend, Terraform state locking is implemented via a DynamoDB table. If two users run apply/plan concurrently, the second operation is blocked because it cannot acquire the lock, preventing state corruption. This is the standard AWS-recommended configuration for S3 backends.

Answer

The `-lock=false` flag

Answer

Terraform Cloud remote operations

Answer

State versioning in S3

Question 2

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 state stores resource attributes in plaintext, including sensitive values like database passwords, even when the backend is encrypted at rest. The recommended approach is to never store the secret itself in state — instead, retrieve it at runtime from a secrets manager (Vault, AWS Secrets Manager) and store only a reference (e.g., the secret ARN or path) in state. This keeps the sensitive value out of state entirely.

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 3

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 4

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. `terraform import` is the correct mechanism to bring an existing resource back under Terraform management by associating it with a resource address in state using its real-world ID. After `terraform state rm`, the resource still exists in the cloud but is no longer tracked, so import is the only command that re-establishes that mapping. The syntax is `terraform import `.

Answer

`terraform state push` with the original state file

Answer

`terraform plan` and then `terraform apply`

Answer

`terraform refresh` and then `terraform plan`

Question 5

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 6

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). Option A is correct because using separate state files per environment (dev, prod) isolates blast radius and prevents a change in one environment from corrupting or locking another, which is a core Terraform team best practice. Option C is correct because enabling state locking (e.g., via S3 + DynamoDB, Terraform Cloud, or Consul) prevents concurrent runs from simultaneously writing to the same state, avoiding corruption and race conditions. Option D is correct because a remote backend shared by the team (such as S3, GCS, Azure Blob, or Terraform Cloud) centralizes state, enables locking, versioning, and access control, and avoids each engineer holding a divergent local copy. Option B is not recommended because state files often contain secrets in plaintext and committing them to version control risks credential exposure and merge conflicts; state should live in a secured remote backend instead. Option E is not recommended because manually editing state is error-prone and unsupported; drift should be corrected with terraform import, terraform state mv/rm, or by reapplying configuration.

Answer

Store state files in a version control repository

Answer

Manually edit the state file to correct drift

Question 7

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 8

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 9

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 10

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 11

Which TWO statements about Terraform state locking are correct?

Accepted Answer

State locking prevents concurrent modifications to the same state file.. Option A is correct because state locking exists precisely to prevent two Terraform runs from concurrently modifying the same state file, which would otherwise risk corruption or lost updates. Option E is correct because locking is a backend capability: backends such as the S3 backend require an associated DynamoDB table (configured via dynamodb_table) to provide locking, and other backends like Consul or Terraform Cloud also implement locking natively. Option B is wrong because the local backend does not support state locking at all, so it cannot be enabled by default. Option C is wrong because Terraform Cloud does support state locking as part of its managed remote backend. Option D is wrong because locking is needed whenever concurrent operations could touch the same state, including automated CI/CD pipelines or a single user running overlapping runs, not only when multiple team members run terraform apply simultaneously.

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 12

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 correct action is to run terraform force-unlock with the lock ID from the error message. This command safely removes the stale lock from the DynamoDB table after verifying that no other process is running, allowing the apply to proceed. It is the intended mechanism for resolving stuck locks without risking state corruption.

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 13

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 error shown is Terraform's state-lock error, which occurs when a lock entry exists in the backend (e.g., DynamoDB for S3) but no active process holds it. This typically happens when a previous terraform apply was killed (Ctrl+C, CI runner timeout, network drop) before Terraform could release the lock, leaving a stale lock that blocks new operations.

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 14

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.. In Terraform, a resource is only recreated when its own configuration or a dependency it references changes. If aws_instance.web does not reference the terraform_remote_state data source in its arguments, changes to the remote state's outputs have no effect on the instance's desired state, so no recreation occurs.

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 15

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.. Terraform backend blocks require all mandatory arguments for the chosen backend type; if required fields are missing, terraform init fails with an error rather than silently falling back. Terraform does not supply defaults for backend configuration arguments and does not prompt interactively for them during init.

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.