Which action will prevent two Terraform runs from changing the same state file at the same time?

Which action will prevent two Terraform runs from changing the same state file at the same time?

• A. Refresh the state after running Terraform
• B. Delete the state before running Terraform
• C. Configure state locking for your state backend
• D. Run Terraform with parallelism set to 1

Answer: (C)

State locking prevents two Terraform operations from writing to the same state file at the same time by coordinating access through the chosen backend. When you start a run, the backend attempts to acquire a lock on the state; if another run is already holding the lock, the second run will wait or fail, ensuring only one set of changes updates the state at once. This is how concurrent changes are avoided in shared environments. This works best with backends that support locking, such as using S3 for storage with a DynamoDB table to manage locks, or using Terraform Cloud/Enterprise. Without locking, or when using a local backend, multiple runs can race to update the state and corrupt it. The other actions don’t provide this safety: refreshing state after a run doesn’t prevent concurrent access; deleting the state is dangerous and defeats the purpose of tracking resources; limiting parallelism in a single run only affects that run’s internal concurrency and doesn’t stop another separate run from updating the state simultaneously.

State locking prevents two Terraform operations from writing to the same state file at the same time by coordinating access through the chosen backend. When you start a run, the backend attempts to acquire a lock on the state; if another run is already holding the lock, the second run will wait or fail, ensuring only one set of changes updates the state at once. This is how concurrent changes are avoided in shared environments.

This works best with backends that support locking, such as using S3 for storage with a DynamoDB table to manage locks, or using Terraform Cloud/Enterprise. Without locking, or when using a local backend, multiple runs can race to update the state and corrupt it.

The other actions don’t provide this safety: refreshing state after a run doesn’t prevent concurrent access; deleting the state is dangerous and defeats the purpose of tracking resources; limiting parallelism in a single run only affects that run’s internal concurrency and doesn’t stop another separate run from updating the state simultaneously.