Error 715-123420 when creating GlobalStandard model deployment via ARM SDK

Question

A community member has associated this post with a similar question:
Foundry model deployment fails with 715-123420 for all tested models

Only moderators can edit this content.

Error 715-123420 when creating GlobalStandard model deployment via ARM SDK

Simon Ouyang 5

I'm getting error 715-123420: An error occurred. Please reach out to support for additional assistance when deploying models to Azure Foundry resources (Cognitive Services, kind: AIServices).

Details:

Operation: Create model deployment (deployments.beginCreateOrUpdate via ARM SDK, also reproduced with az cognitiveservices account deployment create and Azure portal UI)
SDK: @azure/arm-cognitiveservices 8.1.0 (Node.js)
Model: gpt-5.4, format: OpenAI
SKU: GlobalStandard
Affected regions: southcentralus, eastus2, swedencentral, polandcentral (all regions showing GlobalStandard capacity for this model)
Fails on all three surfaces: ARM SDK, Azure CLI, and Azure portal UI

What works:

All read operations (list resources, list models, model capacities) succeed
Existing deployments created before the error started are unaffected and serving traffic
Quota usage shows 0% utilization with plenty of headroom

What does not work:

Any new deployment creation, regardless of model, region, or capacity value
Error persists after 30+ minutes of cooldown

Reproduction:

az cognitiveservices account deployment create \

--name <my-foundry-resource> \

--resource-group <my-resource-group> \

--deployment-name gpt-5-4 \

--model-name gpt-5.4 \

--model-format OpenAI \

--model-version 2026-01-14 \

--sku-name GlobalStandard \

--sku-capacity 1

Trace information: Removed PII

Context: This started after creating multiple model deployments across ~40 Foundry resources in a short time window. Prior to the error, deployments were succeeding normally. Is there a per-subscription cooldown or internal rate limit on deployment creation that is not surfaced as a 429?Title: Error 715-123420 when creating GlobalStandard model deployment via ARM SDK and CLI

Body:

I'm getting error 715-123420: An error occurred. Please reach out to support for additional assistance when deploying models to Azure Foundry resources (Cognitive Services, kind: AIServices).

Details:

Operation: Create model deployment (deployments.beginCreateOrUpdate via ARM SDK, also reproduced with az cognitiveservices account deployment create and Azure portal UI)
SDK: @azure/arm-cognitiveservices 8.1.0 (Node.js)
Model: gpt-5.4, format: OpenAI
SKU: GlobalStandard
Affected regions: southcentralus, eastus2, swedencentral, polandcentral (all regions showing GlobalStandard capacity for this model)
Fails on all three surfaces: ARM SDK, Azure CLI, and Azure portal UI

What works:

All read operations (list resources, list models, model capacities) succeed
Existing deployments created before the error started are unaffected and serving traffic
Quota usage shows 0% utilization with plenty of headroom

What does not work:

Any new deployment creation, regardless of model, region, or capacity value
Error persists after 30+ minutes of cooldown

Reproduction:

az cognitiveservices account deployment create \

--name <my-foundry-resource> \

--resource-group <my-resource-group> \

--deployment-name gpt-5-4 \

--model-name gpt-5.4 \

--model-format OpenAI \

--model-version 2026-01-14 \

--sku-name GlobalStandard \

--sku-capacity 1

Trace information: Removed PII

Context: This started after creating multiple model deployments across ~40 Foundry resources in a short time window. Prior to the error, deployments were succeeding normally. Is there a per-subscription cooldown or internal rate limit on deployment creation that is not surfaced as a 429?

Anshika Varshney 15,710 Reputation points Microsoft External Staff Moderator

2026-03-25T01:05:46.68+00:00

Hi Simon Ouyang,

Thanks for sharing the details. From what you described in the thread, the deployment create call is failing everywhere you try it (ARM SDK, Azure CLI, and the Azure portal), while read calls still work and older deployments keep serving traffic. That strongly suggests this is not a client SDK bug and not a quota read issue, but something on the backend path that validates or approves new deployments.

In community reports, the same error code 715 123420 has also shown up during model deployment validation and creation, sometimes affecting an entire region or the create path itself rather than the template syntax or quota.

One known cause that has been called out publicly is a security heuristic or fraud protection false positive that blocks model deployment creation for some subscriptions or patterns of activity. In one Microsoft internal community post, they explicitly mention 715 123420 as an Azure anti fraud heuristic false positive that can block deployments, and that switching regions sometimes works. Your thread also mentions this started after many deployments were created in a short time window, which matches the kind of pattern that can trigger a protective block.

Here are practical troubleshooting steps you can try, written in simple terms.

First, slow down and try again after a longer cool down window. You already waited around thirty minutes, but with backend protection blocks, it can take longer to clear. If you have automation creating many deployments, pause it for a while and retry a single deployment later.

Second, try a different region that you have not tested yet. I know you already tried several, but if you can test one more supported region outside the current list, it helps confirm whether this is tied to a specific region capacity or a subscription level block. People have reported that switching regions sometimes works with this same error.

Third, confirm the request is using a supported resource type and API version for deployments. For ARM and Bicep, model deployments are created as a child resource under Microsoft CognitiveServices accounts deployments, and the template reference lists the supported API versions and properties. If your tooling is pinned to a preview API version, try a newer supported API version for the deployments resource if available in your environment.

Fourth, isolate whether the block is tied to one Foundry resource or broader. If you can, try creating a brand-new Foundry resource and then create one deployment there only. Since your existing deployments still serve traffic, a quick isolation test like this can show whether the issue is limited to specific resources or impacts any new deployment creation in the subscription.

Fifth, share the trace details in the private chat so others can compare patterns. Your thread already includes Trace ID, Client request ID, and Service request ID. Keeping those in the post is helpful because it lets moderators and engineers correlate the backend failure path without guessing.

Reference links that match this scenario

ARM and Bicep resource reference for model deployments under Microsoft CognitiveServices accounts deployments [learn.microsoft.com]

Other community reports showing the same error during deployment validation or deployment creation [learn.microsoft.com] [learn.microsoft.com]

I Hope this helps. Do let me know if you have any further queries.

Thankyou!
Simon Ouyang 5 Reputation points

2026-03-25T16:20:00.59+00:00

Does it mean I should not try to deploy the model via SDK, instead I need to create it in UI for every region since SDK has Azure anti fraud heuristic false positive that can block deployments.
Anshika Varshney 15,710 Reputation points Microsoft External Staff Moderator

2026-03-31T20:17:13.3333333+00:00

Hi Simon Ouyang,

Error 715‑123420 is not an SDK issue. Deployments created via SDK, CLI, or Azure portal UI all use the same backend, so switching methods won’t avoid it. The error is caused by a backend anti‑fraud / safety false positive, often triggered by rapid or repeated Global Standard deployments across regions. Existing deployments keep working, but new ones are temporarily blocked. Workarounds are trying a different region or creating a fresh Foundry project.

Thankyou!
Simon Ouyang 5 Reputation points

2026-03-31T20:53:29.15+00:00
Hi Anshika, thanks for confirming the 715-123420 error is triggered by the anti-fraud/safety system flagging rapid or repeated Global Standard deployments across regions.

Our workflow requires deploying Global Standard models across multiple regions as part of normal operations. To avoid re-triggering this, could you clarify:

What are the specific thresholds (e.g., max deployments per minute/hour, max concurrent region deployments) that trigger the anti-fraud flag?

Is there a recommended interval or backoff strategy between cross-region deployments that stays safely below the threshold?

If exact thresholds can't be shared, can our subscription be allowlisted or have the sensitivity adjusted for this pattern?
Simon Ouyang 5 Reputation points

2026-03-31T20:54:07.55+00:00
IGNORE below comment since it is duplicate, I cannot delete this comment.
Hi Anshika, thanks for confirming the 715-123420 error is triggered by the anti-fraud/safety system flagging rapid or repeated Global Standard deployments across regions.

Our workflow requires deploying Global Standard models across multiple regions as part of normal operations. To avoid re-triggering this, could you clarify:

What are the specific thresholds (e.g., max deployments per minute/hour, max concurrent region deployments) that trigger the anti-fraud flag?

Is there a recommended interval or backoff strategy between cross-region deployments that stays safely below the threshold?

If exact thresholds can't be shared, can our subscription be allowlisted or have the sensitivity adjusted for this pattern?
Anshika Varshney 15,710 Reputation points Microsoft External Staff Moderator

2026-03-31T21:37:30.33+00:00
Hi Simon Ouyang,

1. About thresholds the exact thresholds that trigger the anti-fraud / safety (RTFP) system are not publicly documented and can’t be shared. That includes limits like “X deployments per minute/hour” or “Y concurrent regions.” The detection logic is adaptive and evaluates multiple signals together (for example, burst patterns, rapid retries, and cross‑region concurrency), rather than a single fixed counter. This is why the same workflow may succeed on some days and get flagged on others.

2. Backoff / pacing guidance Since exact numbers aren’t exposed, there’s no officially documented “safe” interval. However, from observed behavior across multiple threads:

Rapid, parallel GlobalStandard deployments across many regions are more likely to trigger the block.

Immediate retries after a failure often prolong the block. A practical mitigation is to serialize cross‑region deployments, introduce a conservative delay between regions, and avoid retry storms. While this doesn’t guarantee avoidance, it has reduced flags in real-world cases. This is a guidance-based workaround, not a guaranteed rule. [stackoverflow.com]

3. Allowlisting / sensitivity adjustment Yes, when this pattern is part of a legitimate, recurring workload, the usual path is for Microsoft to engage the internal Fraud/Security operations team. Several cases have been escalated through collaboration tickets to review the subscription and unblock or adjust enforcement for valid usage. This is not self-service and requires backend review, but it is the correct path for subscriptions with consistent multi-region deployment needs. [learn.microsoft.com], [learn.microsoft.com]

Summary

Thresholds are intentionally not disclosed.

No official numeric backoff guidance exists, only observed best practices.

Allowlisting or tuning is possible, but only via security/fraud escalation.

I Hope this helps. Do let me know if you have any further queries.

Thankyou!

1 answer

Simon Ouyang 5 Reputation points

2026-03-25T16:20:00.59+00:00

Does it mean I should not try to deploy the model via SDK, instead I need to create it in UI for every region since SDK has Azure anti fraud heuristic false positive that can block deployments.
Anshika Varshney 15,710 Reputation points Microsoft External Staff Moderator

2026-03-31T20:17:13.3333333+00:00

Hi Simon Ouyang,

Error 715‑123420 is not an SDK issue. Deployments created via SDK, CLI, or Azure portal UI all use the same backend, so switching methods won’t avoid it. The error is caused by a backend anti‑fraud / safety false positive, often triggered by rapid or repeated Global Standard deployments across regions. Existing deployments keep working, but new ones are temporarily blocked. Workarounds are trying a different region or creating a fresh Foundry project.

Thankyou!
Simon Ouyang 5 Reputation points

2026-03-31T20:53:29.15+00:00

Hi Anshika, thanks for confirming the 715-123420 error is triggered by the anti-fraud/safety system flagging rapid or repeated Global Standard deployments across regions.

Our workflow requires deploying Global Standard models across multiple regions as part of normal operations. To avoid re-triggering this, could you clarify:

What are the specific thresholds (e.g., max deployments per minute/hour, max concurrent region deployments) that trigger the anti-fraud flag?

Is there a recommended interval or backoff strategy between cross-region deployments that stays safely below the threshold?

If exact thresholds can't be shared, can our subscription be allowlisted or have the sensitivity adjusted for this pattern?
Simon Ouyang 5 Reputation points

2026-03-31T20:54:07.55+00:00

IGNORE below comment since it is duplicate, I cannot delete this comment.
Hi Anshika, thanks for confirming the 715-123420 error is triggered by the anti-fraud/safety system flagging rapid or repeated Global Standard deployments across regions.

Our workflow requires deploying Global Standard models across multiple regions as part of normal operations. To avoid re-triggering this, could you clarify:

What are the specific thresholds (e.g., max deployments per minute/hour, max concurrent region deployments) that trigger the anti-fraud flag?

Is there a recommended interval or backoff strategy between cross-region deployments that stays safely below the threshold?

If exact thresholds can't be shared, can our subscription be allowlisted or have the sensitivity adjusted for this pattern?

Answer 1

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more