How to fix Provider responds with 409 Conflict and errors with ServiceBusy in Terraform

In most cases, the 409 ServiceBusy error is transient. Simply re-run the terraform apply command. If the error was temporary service load, the second attempt will succeed without any code changes.

terraform apply

This resolves the issue in the majority of cases.

If the error persists across multiple retries, add explicit dependencies between resources that may be conflicting. This forces Terraform to create resources sequentially rather than in parallel, reducing contention.

resource "azurerm_storage_account" "sa1" {
  name                     = "storage1"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
}

resource "azurerm_storage_account" "sa2" {
  name                     = "storage2"
  resource_group_name      = azurerm_resource_group.rg.name
  location                 = azurerm_resource_group.rg.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  depends_on               = [azurerm_storage_account.sa1]
}

If errors persist after retries, work with your network administrator to verify that any firewall or proxy between your Terraform client and Azure is not interfering with HTTP retry logic.

Specifically, check that the HTTP RFC Retry-After response-header field is configured correctly. Ensure it includes appropriate status codes and that HTTP 202 (Accepted) responses are not being flagged as security threats or blocked.

You can enable debug logging in Terraform to see the actual HTTP responses:

TF_LOG=DEBUG terraform apply 2>&1 | grep -i "retry\|409\|202"

If the error message mentions that a resource already exists (e.g., 'RoleAssignmentExists'), verify whether the resource was created outside of Terraform or in a previous failed run.

Import the existing resource into your Terraform state:

terraform import azurerm_resource_type.name /subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/Microsoft.Provider/resourceType/{resource-name}

Then update your Terraform configuration to match the imported resource.

If using the AzAPI provider (newer alternative to AzureRM), you can configure custom retry logic for specific error patterns:

terraform {
  required_providers {
    azapi = {
      source = "Azure/azapi"
    }
  }
}

provider "azapi" {
  retry_config {
    error_message_regex = ["ServiceBusy", "429"]
    interval_seconds    = 10
    max_interval_seconds = 180
  }
}

This will automatically retry requests matching these patterns with exponential backoff.

For large infrastructure deployments, split the terraform apply into multiple smaller operations targeting different resource groups or technologies. This reduces the load on Azure's service endpoints.

For example, instead of applying all resources at once:

# First wave: core infrastructure
terraform apply -target=azurerm_resource_group.main

# Second wave: storage
terraform apply -target=azurerm_storage_account.primary

# Third wave: compute
terraform apply -target=azurerm_virtual_machine.main