Error: Provider produced an unexpected new value - NSG Flow Logs (azurerm_network_watcher_flow_log)

Problem

When applying changes to an azurerm_network_watcher_flow_log resource, you may encounter an error indicating that the resource already exists, even when it is being created for the first time:

azurerm_network_watcher_flow_log.<name>, provider "provider[\"registry.terraform.io/hashicorp/azurerm\"]" produced an unexpected new value: Root resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own issue tracker.

Error: A resource with the ID "/subscriptions/<id>/resourceGroups/<RG name>/providers/Microsoft.Network/<network name>/NetworkWatcher_usgovvirginia/flowLogs/<flow logs name>" already exists - to be managed via Terraform this resource needs to be imported into the State. Please see the resource documentation for "azurerm_network_watcher_flow_log" for more information.

Cause

This error is typically caused by an eventual consistency issue within the Azure platform. The API call to create the resource is sent to Azure, but the AzureRM provider does not receive confirmation that the resource has finished provisioning before it checks again. This race condition leads Terraform to believe the creation failed and that the existing resource is unmanaged.

This behavior is discussed in the AzureRM provider GitHub repository.

Solutions

The following workarounds can help mitigate this timing issue. The recommended long-term solution is to upgrade the provider (Solution 3).

Solution 1: Increase the Creation Timeout

You can extend the creation timeout for the azurerm_network_watcher_flow_log resource. This gives Azure more time to complete the resource creation before the provider reports a timeout.

Add a timeouts block to your resource configuration.

resource "azurerm_network_watcher_flow_log" "example" {
  ## ... other configuration ...

  timeouts {
    create = "30m"
  }
}

For more details, refer to the AzureRM provider's timeout documentation.

Solution 2: Introduce a Delay with the Time Provider

Use the time_sleep resource from the hashicorp/time provider to introduce an explicit delay in your configuration. This pauses the Terraform run, allowing the Azure resource to stabilize before other operations proceed.

resource "time_sleep" "wait_for_flow_log" {
  create_duration = "60s"

  ## This trigger ensures the sleep resource is recreated
  ## if the flow log resource it depends on changes.
  triggers = {
    flow_log_id = azurerm_network_watcher_flow_log.example.id
  }
}

Solution 3: Upgrade the AzureRM Provider

This issue is reported to be resolved in version 3.x of the hashicorp/azurerm provider. Upgrading the provider to the latest version is the recommended long-term solution.

Update your provider version constraint in your Terraform configuration.

terraform {
  required_providers {
    azurerm = {
      source  = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

You can find more context on the fix in this comment in the provider's GitHub repository.

Additional Information

This behavior is tracked in the following GitHub issue: hashicorp/terraform-provider-azurerm#9395.