Terraform state is a JSON file mapping your configuration to real Azure resources. Remote state backends (Azure Blob Storage) enable team collaboration, state locking prevents concurrent corruption, and state operations (mv, rm, import) let you manage real-world drift.
Each stage in order — click any step to read what it does.
Remote state architecture: Azure Blob Storage as the backend with locking and team access.
The trade-offs worth knowing before you build this.
Grant engineers Storage Blob Data Contributor on the state container, not the whole storage account. Use Managed Identity in CI pipelines — no client secrets to rotate.
Always enable blob versioning + soft delete on the state storage account. State corruption happens — versioning is your rollback mechanism. Set lifecycle policy: 30 days of versions.
When you rename a resource or move it into a module, use terraform state mv to update the address in state. Without this, Terraform will delete the old resource and create a new one.
Bring existing Azure resources under Terraform management: terraform import azurerm_storage_account.main /subscriptions/.../storageAccounts/mysa. Terraform reads the current config from Azure.
The tfstate JSON format changes between Terraform versions. Manual edits cause schema mismatches. Use terraform state commands (mv, rm, list, show) for all state manipulations.
terraform force-unlock <lock-id> releases a stuck state lock. Only run this when you're 100% sure no other apply is running. Wrong usage corrupts state.
Sign in to share your feedback and join the discussion.
