Since 2026-09-29 around 21:20 UTC, ARM control-plane calls on two existing Grounding with Bing Search accounts fail intermittently. The accounts are kind Bing.Grounding, SKU G1, location global, created with Bicep (Microsoft.Bing/accounts@2020-06-10) on a pay-as-you-go subscription in East US 2, one per environment. Both read back as provisioningState: Succeeded under 2020-06-10 and 2025-05-01-preview, and grounding keeps working at runtime through the existing Foundry project connections.
What fails, all from the Activity Log:
-
POST .../listKeys?api-version=2020-06-10 returns 404 {"code":"ResourcePostActionFailed","message":"ResourcePostActionFailed: Not Found"}. Same identity, same request, 200 two seconds later.
- An idempotent
PUT of the unchanged account returned 404 ResourceCreationFailed: Not Found once and 400 ResourceCreationValidateFailed: The resource validation failed once, with 200 for the identical body before and after.
Out of 35 calls between 2026-09-29 12:00 and 2026-09-30 12:45 UTC, 5 failed: across both accounts, two callers (a deployment service principal with Contributor on the resource group, and a user with Owner), and both operation types. Nothing changed on our side: the template is identical across successes and failures, no role assignments changed, and Microsoft.Bing is registered. Permission problems in our tenant return 403 AuthorizationFailed, which we have seen separately; these are 404 and 400 from the provider. No Service Health event was published.
Failing correlation ids (UTC):
- 2026-09-29 21:22:47, listKeys, 404:
59e7956a-1853-4743-9487-0982b54d577f
- 2026-09-29 23:05:51, PUT, 404:
98da8d79-1ea7-4cbb-b49b-6d88d11a68f5
- 2026-09-30 12:35:10, listKeys, 404:
a6e09faf-bc0d-4021-8798-a1afa2fb00f7
- 2026-09-30 12:37:57, PUT, 400:
27c0781d-864d-4ba5-a475-6881f6454258
- 2026-09-30 12:42:08, listKeys, 404:
43bce5fb-0d40-4260-91a5-b737244be528
Succeeding ids for comparison: 45bf12d4-3b7b-46bb-bdb6-b84cf59cbc1b (listKeys 200 at 12:35:12, two seconds after the 12:35:10 failure, same caller) and 35fdf44d-20f5-4c0b-a13b-4e36258d183e (PUT 200 at 23:23:16 after the 23:05:51 failure, same caller, same body).
Impact: our deployment builds the Foundry GroundingWithBingSearch connection with listKeys(bing.id, '2020-06-10').key1, as in the Microsoft sample (foundry-samples, 45-basic-agent-bing), so each intermittent failure fails the whole environment deployment. We have stopped touching the account and connection during deployments as a workaround, which means we cannot rotate the key until this is resolved.
Questions:
- Is there a known issue with the Microsoft.Bing resource provider since 2026-09-29, or a backend migration affecting Bing.Grounding accounts?
- Has the recommended pattern of reading the key with
listKeys at deployment time changed?
- Is there anything about an account created this way that would make the provider treat it differently?