6.2.2. How Backends Implement Locking
💡 First Principle: Locking capability is backend-specific because each backend uses its platform's own consistency primitive — so whether you get locking, and how, depends entirely on which backend you chose.
Not all backends support locking, and those that do implement it differently. The S3 backend historically paired with a DynamoDB table for locking (and newer Terraform versions also support a native S3 lock file). Other backends use their own mechanisms — Azure Blob uses lease locks, Consul uses sessions, and HCP Terraform locks automatically as part of its run model. Backends that can't provide a locking primitive simply don't lock.
⚠️ Exam Trap: The S3-plus-DynamoDB association is a classic exam fact: with the S3 backend, locking is commonly provided by a DynamoDB table specified in the backend configuration. Also know that HCP Terraform handles locking for you automatically — no extra setup.
Reflection Question: Why can't there be a single universal locking mechanism for all backends — what does each backend depend on?
