Question

Your team stores Terraform state in a plain HTTP backend that does not implement state locking. Several engineers run 'terraform apply' against the same configuration from their laptops throughout the day. What is the primary risk of this setup, and how should it be addressed?

Accepted Answer

Concurrent applies can corrupt the state file because writes are not serialized; migrate to a backend that supports locking (e.g., S3 with DynamoDB or HCP Terraform).

Answer

There is no real risk because Terraform automatically retries any failed write, so no backend change is needed.

Answer

The main risk is slower plans; enabling parallelism with -parallelism=1 will resolve any contention.

Answer

The state will grow too large; enabling gzip compression on the HTTP backend prevents concurrent-write issues.