Provider responds with "409 Conflict" and errors with "ServiceBusy" during Terraform Apply

Problem

When running terraform apply to create resources in Microsoft Azure, such as a PostgreSQL database, the operation fails with a 409 Conflict error. The provider debug logs show a ServiceBusy error message from the Azure API.

plugin.terraform-provider-azurerm_v2.66.0_x5: AzureRM Response for https://management.azure.com/subscriptions/xxxx-xx-xxxx-xxxx/resourceGroups/test-rg/providers/Microsoft.DBForPostgreSQL/servers/test-server?api-version=2017-12-01:
HTTP/1.1 409 Conflict
Content-Type: application/json; charset=utf-8

{"error":{"code":"ServiceBusy","message":"Service is temporarily busy and the operation cannot be performed. Please try again later."}}

[DEBUG] module.postgres-sql.azurerm_postgresql_server.main: apply errored, but we're indicating that via the Error pointer rather than returning it: creating PostgreSQL Server "test-server" (Resource Group "test-rg"): postgresql.ServersClient#Create: Failure sending request: StatusCode=0 -- Original Error: autorest/azure: Service returned an error. Status=<nil> Code="ServiceBusy" Message="Service is temporarily busy and the operation cannot be performed. Please try again later."

Cause

This error can occur when a network firewall or security appliance intercepts and blocks API requests that it flags as a potential threat.

In this specific scenario, the Azure API responds to a PUT request with an HTTP 202 (Accepted) status, which includes a Retry-After response header. Some firewalls misinterpret this combination as a security threat, blocking subsequent retries from the Terraform provider and causing the operation to fail with a ServiceBusy error.

Adding a time_sleep resource to the Terraform configuration does not resolve the issue because the root cause is the firewall blocking the request, not a transient service availability problem.

Solutions

Solution 1: Adjust Firewall Rules for the Retry-After Header

You will need to work with a server or network administrator to investigate the firewall configuration. The administrator should validate why the firewall flags requests containing a Retry-After header on 202 (Accepted) responses as a threat.

To resolve the issue, the administrator must create an exemption or adjust the firewall rule to allow these legitimate API calls from the Terraform provider to pass through to the Azure API.

Outcome

After the firewall configuration is updated to exempt the 202 (Accepted) status with the Retry-After header, the terraform apply command should complete successfully without the 409 Conflict or ServiceBusy errors.

Additional Information

• The Retry-After response-header field is defined in the HTTP/1.1 RFC2616 specification.
• For more details on configuring the AzureRM provider, please refer to the official Terraform documentation.