Which practice helps maintain safe concurrent work with Terraform state in a team?

Which practice helps maintain safe concurrent work with Terraform state in a team?

• A. Enable state locking on the backend
• B. Use a local backend for all teams
• C. Share the state file via a shared drive
• D. Run apply from multiple machines simultaneously

Answer: (A)

State locking on the backend prevents multiple Terraform runs from updating the same state at the same time. Terraform's state file is the source of truth for what exists in your infrastructure; if two people run apply concurrently, their changes can collide, leading to corrupted state or lost updates. Turning on locking lets the backend coordinate access so only one operation can modify the state at a time, keeping the state consistent. Remote backends commonly used by teams—such as S3 with a DynamoDB table for locking, or Terraform Cloud/Enterprise—provide this locking mechanism. Without it, using a local backend or sharing the state file through a drive offers no safe way to serialize access, and running apply from multiple machines simultaneously can cause race conditions and state corruption.

State locking on the backend prevents multiple Terraform runs from updating the same state at the same time. Terraform's state file is the source of truth for what exists in your infrastructure; if two people run apply concurrently, their changes can collide, leading to corrupted state or lost updates. Turning on locking lets the backend coordinate access so only one operation can modify the state at a time, keeping the state consistent.

Remote backends commonly used by teams—such as S3 with a DynamoDB table for locking, or Terraform Cloud/Enterprise—provide this locking mechanism. Without it, using a local backend or sharing the state file through a drive offers no safe way to serialize access, and running apply from multiple machines simultaneously can cause race conditions and state corruption.