Terraform state is the memory of an Azure infrastructure deployment. The state file, terraform.tfstate, records the current state of infrastructure managed by Terraform and acts as the source of truth for Terraform. It stores information about resources that have been created, updated, or deleted. State allows Terraform to know what Azure resources to add, update, or delete. By default, Terraform state is stored locally, which isn't ideal for team or collaborative work. Terraform state can include sensitive information. Storing state locally increases the chance of inadvertent deletion. When using Terraform in Azure Cloud, managing state files efficiently is crucial for infrastructure automation. Terraform stores the state of managed resources in a state file, terraform.tfstate, which can be stored locally or remotely.
The difference between local and remote handling of state determines whether an Azure project remains a single-developer experiment or scales into a production pipeline that multiple engineers can safely operate. Local state creates a situation where each developer sees a different view of reality. Remote state in Azure Storage is the best practice for production. Terraform Plan and Apply ensures controlled infrastructure updates. Mastering Terraform State Management allows handling changes safely and avoiding infrastructure disasters.
Local Terraform State in Azure
What is Local State?
By default, Terraform saves the state file locally in the working directory where Terraform is executed. In Azure projects, this means the terraform.tfstate file is stored on the developer's local machine. The file lives in the root of the Terraform configuration directory.
How Local State Works?
When you run terraform apply, Terraform reads the configuration and compares it to the state file it can find. The presence of the local file determines which resources Terraform believes already exist.
Where is the Local State File Stored?
Terraform stores the state file in the root of the Terraform configuration directory:
/my-terraform-project/
├── main.tf
├── variables.tf
├── outputs.tf
├── terraform.tfstate ← Local state file
You can specify a different file name manually:
terraform apply -state=my_custom_state.tfstate
The ability to rename the state file gives a developer a sense of control over a single machine, but it does not change the fundamental isolation of the file.
Challenges of Using Local State in Azure Projects
Local state doesn't work well in a team or collaborative environment. Terraform state can include sensitive information. Storing state locally increases the chance of inadvertent deletion. When a teammate runs terraform plan, Terraform looks for the state file because the state file is how it knows which Azure resources it is already managing. If the teammate cloned the code but not the state, there is no terraform.tfstate in their folder. From Terraform's point of view, no resources exist yet. It reads the configuration, sees resources it does not recognise, and concludes everything needs to be created from scratch. The impact is duplicate resource creation attempts, failed plans, and drift.
When to Use Local State in Azure?
Local State is useful for testing but unsafe for teams. It is acceptable for initial experimentation on a single machine where no shared resources exist and the risk of accidental deletion is controlled by the developer.
Remote Terraform State in Azure
What is Remote State?
Remote state stores Terraform's state file in an Azure Storage Account, allowing multiple team members to access and update infrastructure safely. Remote state in Azure Storage is the best practice for production.
How Remote State Works in Azure?
Terraform stores the mapping between your configuration and real-world resources in a state file. By default, this file lives locally as terraform.tfstate. That works fine when you are the only person touching the infrastructure, but it falls apart quickly in a team setting. Remote state gives you three key benefits. First, it provides a single source of truth for your infrastructure state. Second, it enables collaboration because everyone reads from and writes to the same location. Third, it provides a foundation for locking and encryption.
How to Configure Remote State in Azure?
Step 1: Create an Azure Storage Account
Terraform needs an Azure Storage Account and a Blob Container to store the state file. Before you use Azure Storage as a backend, you must create a storage account.
Run the following commands or configuration to create an Azure storage account and container:
```
!/bin/bash
RESOURCEGROUPNAME=tfstate
STORAGEACCOUNTNAME=tfstate$RANDOM
CONTAINER_NAME=tfstate
Create resource group
az group create --name $RESOURCEGROUPNAME --location eastus
Create storage account
az storage account create --resource-group $RESOURCEGROUPNAME --name $STORAGEACCOUNTNAME --sku Standard_LRS --encryption-services blob
Create blob container
az storage container create --name $CONTAINERNAME --account-name $STORAGEACCOUNT_NAME
```
Key points:
- Azure storage accounts require a globally unique name
The creation of the resource group, storage account, and container establishes the physical location where Terraform will persist its state. The choice of eastus as location and Standard_LRS as sku reflect typical defaults used in examples. Encryption services blob enables encryption at rest.
Azure subscription: If you don't have an Azure subscription, create a free account before you begin.
Why Remote State Matters in Team Environments
If you have ever worked on a Terraform project with more than one person, you already know the pain of state file conflicts. Someone runs terraform apply on their laptop while you are doing the same thing, and suddenly your infrastructure is in an unpredictable mess. Remote state with locking solves this problem entirely, and Azure Blob Storage is a solid backend for it.
In this guide, I will walk through every step of setting up a remote state backend on Azure Blob Storage with state locking enabled via Azure Storage lease mechanisms. This is a pattern used on dozens of production projects, and it is one of the first things configured on any new Azure Terraform engagement.
The natural question is:
If my Terraform code is in Git, why can I not just push to Git, have a teammate clone the repo, and run terraform apply from their machine?
It sounds reasonable. Both engineers have the same code. Both engineers point at the same Azure subscription. Same instructions, same target. What could go wrong?
Here is what goes wrong.
When your teammate runs terraform plan, Terraform does what it always does first. It looks for the state file, because the state file is how it knows which Azure resources it is already managing. Your teammate cloned the code, not the state. There is no terraform.tfstate in their folder. So from Terraform's point of view, no resources exist yet. It reads the configuration, sees resources it does not recognise, and concludes everything needs to be created from scratch.
The impact layer is immediate. Plans become inaccurate. Apply operations attempt to recreate resources that already exist, leading to errors, API throttling, and cost. In a real Azure environment, this can mean failed deployments and outage risk. The contextual layer connects this to the need for a shared, authoritative state location that is independent of Git.
Remote state gives you three key benefits. First, it provides a single source of truth for your infrastructure state. Second, it enables collaboration because everyone reads from and writes to the same location. Third, it enables safety mechanisms such as locking and encryption.
Authentication and Subscription Context for Remote Operations
When using Terraform in Azure Cloud, managing state files efficiently is crucial for infrastructure automation. Before operations can target Azure, authentication must be established.
If you are not already logged in to Azure, use the Azure CLI to log in to your account.
az login
Your browser window will open and you will be prompted to enter your Azure login credentials. After successful authentication, your terminal will display your subscription information. You do not need to save this output as it is saved in your system for Terraform to use.
A Service Principal is an application within Azure Active Directory whose authentication tokens can be used as environment variables in HCP Terraform. For more information, visit the Azure documentation.
First, list the Subscriptions associated with your Azure account.
az account list
The output includes:
[
{
"cloudName": "AzureCloud",
"id": "00000000-0000-0000-0000-000000000000",
"isDefault": true,
"name": "PAYG Subscription",
"state": "Enabled",
"tenantId": "00000000-0000-0000-0000-000000000000",
"user": {
"name": "[email protected]",
"type": "user"
}
}
]
Select a subscription and copy its id field value. This is the Subscription ID related to your account.
The default option is remote execution — HCP Terraform will perform Terraform operations remotely. When using local execution, HCP Terraform will execute Terraform on your local machine and remotely store your state file in HCP Terraform. For this tutorial, you will use the default remote execution option for the workspace.
Now that Terraform has migrated the state file to HCP Terraform, delete the local state file.
rm terraform.tfstate
Removing the local file prevents accidental reuse of a stale state and reinforces the single source of truth in the remote backend.
State Locking and Security Mechanisms
Terraform State Management includes enabling State Locking to prevent simultaneous changes. Encrypt Terraform State using Azure SSE for security. Backup Terraform State Files to avoid accidental loss. Use Terraform Workspaces for managing multiple environments.
Best Practices for Managing Terraform State
- Use Remote State Storage – Prevents loss and enables collaboration.
- Enable State Locking – Avoids conflicts in concurrent updates.
- Encrypt State Files – Prevents exposure of sensitive data.
- Use terraform refresh Carefully – Updates the state file but can overwrite unintended changes.
- Restrict State File Access – Limit access to prevent unauthorized modifications.
State locking is achieved via Azure Storage lease mechanisms. When one user acquires a lock on the state file, other users are blocked from writing until the lock is released. This prevents the unpredictable mess that occurs when two applies run concurrently.
Encryption at rest is understood as part of remote state configuration. Use Azure SSE for security. The storage account creation command includes --encryption-services blob, which enables encryption.
Restrict State File Access by using Azure RBAC on the storage account and container. Limiting access prevents unauthorized modifications to the state file, which would otherwise corrupt Terraform's view of reality.
Backup Terraform State Files to avoid accidental loss. Azure Blob Storage provides versioning and soft delete capabilities that can be leveraged for recovery.
Use Terraform Workspaces for managing multiple environments. Workspaces allow a single configuration to manage multiple states, such as dev, test, and prod, while keeping state files isolated within the same backend.
Best Practices for Secure and Scalable State Management
Terraform state is a JSON file, terraform.tfstate, that tracks the current state of infrastructure managed by Terraform. It acts as a source of truth for Terraform, storing information about resources that have been created, updated, or deleted.
Why Does Terraform State Matter?
State keeps track of infrastructure deployments. Local State is useful for testing but unsafe for teams. Remote State in Azure Storage is the best practice for production. Terraform Plan and Apply ensures controlled infrastructure updates. Best Practices include encryption, state locking, and backups.
Handling Changes – Terraform Plan, Apply, Destroy
Terraform Plan previews changes. Terraform Apply executes them. Terraform Destroy removes resources tracked in state. All operations rely on an accurate state file.
Step-by-Step: Setting up Remote State in Azure
The practical flow begins with creating an Azure Storage Account and Blob Container, then configuring the Terraform backend to point to that container. The backend configuration references the storage account name, container name, resource group, and access credentials. Once configured, Terraform reads and writes state to Azure instead of the local filesystem.
Best Practices for Secure and Scalable State Management
The following practices are repeatedly emphasized.
- Always use Remote State Storage. Azure Storage, AWS S3, etc., provide durability.
- Enable State Locking to prevent simultaneous changes.
- Encrypt Terraform State. Use Azure SSE for security.
- Backup Terraform State Files to avoid accidental loss.
- Use Terraform Workspaces for managing multiple environments.
The impact of these practices is reduced downtime, auditable changes, and safe team collaboration. The contextual layer connects these practices to the broader Azure lifecycle, where storage accounts, service principals, and subscriptions form a chain of trust from identity to state persistence.
Comparison of Local and Remote State
| Attribute | Local State | Remote State in Azure |
| Local storage on developer machine | Remote storage in Azure Storage Account Blob Container |
| Single developer use | Team collaboration with single source of truth |
| No built-in locking | State locking via Azure Storage lease mechanisms |
| Risk of accidental deletion | Durable storage with backups and versioning |
| Sensitive data exposed on laptop | Encryption at rest with Azure SSE and restricted access |
| Useful for testing | Best practice for production |
The table makes the trade-offs explicit. Local state offers simplicity for initial tests. Remote state offers safety, collaboration, and durability for production Azure workloads.
Operational Workflow with Remote State
When you run terraform apply, Terraform:
Reads the backend configuration pointing to Azure Blob Storage. Retrieves the current state file from the container. Compares the configuration to the state. Acquires a state lock to prevent concurrent writes. Writes the updated state back to the container. Releases the lock.
When you run terraform plan, Terraform:
Retrieves the state from Azure. Performs a diff between desired configuration and actual state. Displays a plan without modifying infrastructure.
When you run terraform refresh, Terraform:
Updates the state file to reflect the real Azure resources. Use terraform refresh carefully because it can overwrite unintended changes.
The workflow ensures controlled infrastructure updates and avoids infrastructure disasters.