Private Endpoint Creation Fails for Azure AI Foundry: Provider Marks Cognitive Account as Complete While ARM State Is Still "Accepted"

[pmogacs]

Is there an existing issue for this?

• I have searched the existing issues

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave comments along the lines of "+1", "me too" or "any updates", they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment and review the contribution guide to help.

Private Endpoint Creation Fails for Azure AI Foundry: Provider Marks Cognitive Account as Complete While ARM State Is Still "Accepted"

Overview

When deploying Azure AI Foundry (Microsoft.CognitiveServices/accounts) using the Terraform azurerm_ai_services resource, the AzureRM provider reports the account creation as complete even though Azure still returns a provisioning state of Accepted.

Because Terraform incorrectly considers the resource finished, it immediately attempts to create a Private Endpoint, which then fails with:

AccountProvisioningStateInvalid: ... account ... in state Accepted

This causes the entire deployment to fail.

---

Impact

This issue blocks fully automated AI Foundry deployments involving Private Endpoints.

Workarounds require:

• Adding manual waits or sleep commands
• Using artificial depends_on or retry logic
• Adding external provisioning checks

These workarounds are not ideal in IaC-driven workflows.

---

Suggested Fix

The provider should:

• Poll the ARM provisioning state until it reaches Succeeded.
• Not return success based solely on the initial terminal event.
• Align with other AzureRM resources that properly wait for final provisioning state.

---

Terraform Version

1.3.7

AzureRM Provider Version

4.58.0

Affected Resource(s)/Data Source(s)

azurerm_ai_services

Terraform Configuration Files

resource "azurerm_resource_group" "example" {
  name     = "example-resources"
  location = "West Europe"
}

resource "azurerm_ai_services" "example" {
  name                = "example-account"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  sku_name            = "S0"

  tags = {
    Acceptance = "Test"
  }
}

resource "azurerm_private_endpoint" "example" {
  name                = "example-endpoint"
  location            = azurerm_resource_group.example.location
  resource_group_name = azurerm_resource_group.example.name
  subnet_id           = azurerm_subnet.endpoint.id

  private_service_connection {
    name                           = "example-privateserviceconnection"
    private_connection_resource_id = azurerm_ai_services.example.id
    is_manual_connection           = false
  }
}

Debug Output/Panic Output

module.ocu_foundry.module.foundry.azurerm_ai_services.aifoundry: Creation complete after 1m10s
...
Error: ... AccountProvisioningStateInvalid: ... account ... in state Accepted

Expected Behaviour

Terraform should wait until the Cognitive Services / AI Foundry account reaches the Succeeded provisioning state before allowing dependent resources (like Private Endpoints) to be created.

Actual Behaviour

Terraform logs indicate:

• The azurerm_ai_services resource completes after ~70 seconds.
• Azure still reports the provisioning state as Accepted.
• Terraform proceeds to create the Private Endpoint.
• Private Endpoint creation fails with HTTP 400 Bad Request.

Error snippet

Error: creating Private Endpoint ...
unexpected status 400 ... AccountProvisioningStateInvalid:
Call to Microsoft.CognitiveServices/accounts failed.
Account ... in state Accepted

Steps to Reproduce

1. Deploy an Azure AI Foundry resource using:
   • azurerm_ai_services
2. In the same blueprint create a dependent azurerm_private_endpoint.
3. Run terraform apply.
4. Observe:
   • Provider marks AI Foundry account creation complete early.
   • Azure ARM still reports Accepted.
   • Private Endpoint creation fails.

Important Factoids

No response

References

No response

[promisinganuj]

Hi @pmogacs ,

Thank you for taking time to report this issue.

Please note that azurerm_ai_services resource is no longer supported. The recommended way to deploy cognitive account is to use azurerm_cognitive_account resource with kind = AIServices. The documentation update to reflect this guidelines is in progress.

Please get back to us if you still get the issue while using azurerm_cognitive_account.

[phil-bevan]

I am using the azurerm_cognitive_account resource with kind=AIServices and can confirm that I am seeing this problem

[promisinganuj]

Hi @phil-bevan , @pmogacs , @vibhuanand. I tested this on my end and was unable to reproduce the reported behavior. When using azurerm_cognitive_account, the private endpoint is created successfully without requiring a custom poller.

At this point, there isn’t enough information to identify a provider-side issue. Please share the exact error message along with a minimal, complete, and reproducible Terraform configuration using azurerm_cognitive_account so this can be investigated further.

[vibhuanand]

@phil-bevan @pmogacs, could you share a minimal, complete repro using azurerm_cognitive_account (kind="AIServices") + azurerm_private_endpoint?

Specifically, can you paste:

1. The exact Terraform error text (
2. A minimal TF config that reproduces (RG + VNET/subnet + cognitive_account + private_endpoint)
3. A short log/evidence snippet that shows TF marks cognitive_account “Creation complete”, but Azure still reports provisioningState=Accepted right after.

For (3), the easiest proof is:

• run with: TF_LOG=DEBUG TF_LOG_PATH=./tf-debug.log terraform apply
• immediately after the cognitive account reports created, run:
  az cognitiveservices account show -g -n --query properties.provisioningState -o tsv

If you can provide those, I’ll update the PR description with the repro + logs and we can tighten scope if needed.

[phil-bevan]

@vibhuanand I see you linked a PR to fix a timing issue which would make sense as I have seen this issue again on another deployment that has worked previously. Do you still need me to provide the logs etc above?

[vibhuanand]

@phil-bevan, @promisinganuj needs more evidence as per - #31712 (comment).

[promisinganuj]

@phil-bevan I see that a reference to another similar issue in the Foundry sample repo has been added to this PR. Let me see if I can use that to reproduce the issue. Wait for my reply before providing additional evidence from your end.

FYR @ZiChuanBuXiu

[isBhuvan]

I am also facing this issue. It has been occurring for the past couple of days. Earlier, it was working fine.