Terraform State File Locking Conflicts in Shared Workspaces

When multiple engineers run `terraform apply` against the same state file simultaneously, one gets a state lock error and must wait or force-unlock, risking state corruption. So what? Engineers either wait idle for the lock to release or force-unlock and risk writing a partial state that drifts from actual infrastructure. So what? Drifted state means the next `terraform plan` shows phantom changes or misses real resources, leading engineers to distrust the plan output. So what? Distrust in plan output means engineers skip reviewing diffs carefully and rubber-stamp applies, or they avoid making infrastructure changes altogether, accumulating technical debt. So what? Accumulated infrastructure debt means security patches, scaling adjustments, and cost optimizations get deferred until an incident forces emergency changes under pressure. So what? Emergency infrastructure changes without proper planning cause outages, blast radius miscalculations, and cascading failures across dependent services. The structural root cause is that Terraform's state model assumes a single serial operator per state file, but organizations split infrastructure into shared workspaces by team boundaries (e.g., 'platform-prod') rather than by change frequency and ownership, creating artificial contention among engineers who rarely modify the same actual resources.