Policy ArmResourceId has incorrect formatting — an Azure CLI error message that cost me a whole debugging session, when the real reason was just a hyphen in the policy name.

Hi everyone 👋

Setting up an Azure Front Door WAF Policy through the CLI, I ran into an error that — as it turns out — a lot of other people have been hitting for over three years, ever since it was first reported back in December 2022.

😱 The error

Running a simple WAF policy creation command:

az network front-door waf-policy create --name my-waf-policy --resource-group <rg> --mode Detection --sku Premium_AzureFrontDoor

Azure comes back with:

(BadRequest) WebApplicationFirewallPolicy validation failed. More information "Policy ArmResourceId has incorrect formatting".

Reading that message, the obvious first suspect is the resource group, subscription ID, or some ARM resource ID being malformed somewhere — that’s exactly what the field name ArmResourceId points to. I double-checked the resource group, permissions, region… all fine.

🔍 What’s actually happening

The real root cause has nothing to do with any ARM resource ID: the WAF policy name can’t contain a hyphen (-) or any character other than letters and digits — it must start with a letter and contain only alphanumeric characters. my-waf-policy is a perfectly valid name everywhere else in Azure, but this particular API rejects it with an error message that never mentions that constraint at all.

This isn’t a guess on my part — the issue Azure/azure-cli-extensions#5625 was reported on 2022-12-11, and Microsoft confirmed this exact root cause just a day later. What’s notable is what happened next:

  • Microsoft’s fix was to add a help-text hint on the --policy-name parameter (PR #5658, which closed the issue on 2022-12-20) — not to fix the actual error message returned by the service itself.
  • Other users kept reporting the same error throughout 2024–2026: in August 2024, someone asked Microsoft to fix the misleading message at its root, on the Azure Front Door server side, instead of just patching CLI help text; in October 2024, someone tried it in the Portal with a hyphenated name and got the exact same failure; in February 2025, someone found that Azure’s own official documentation lists the only naming constraint as “max length = 128” — no mention of the alphanumeric-only rule anywhere.
  • In June 2025, I left a comment on that same issue after hitting it myself — by then it had been open for almost three years with no real fix.
  • The issue was closed and then reopened in July 2025, and as of February 2026 people are still reporting it — including in Azure’s own official AVM Bicep module.

In short: a simple validation rule, an error message that points at completely the wrong cause, and no real fix at the source for over three years — just a CLI help-text patch.

🛠️ The fix

  • Name the WAF policy using only letters and digits, starting with a letter — no hyphens, underscores, or any other special character, regardless of what the official docs say the constraint is.
  • If you hit Policy ArmResourceId has incorrect formatting while creating a WAF policy (CLI, Bicep, and the Portal can all trigger it), check the resource name first — not the resource group or permissions.
  • If debugging through the CLI/API isn’t giving you any useful clues, try creating the same policy through the Azure Portal instead — according to community reports, the Portal tends to surface a much clearer error for this exact case than the CLI/API does.

💡 What I took away

A cloud provider’s error message can sometimes point you in a completely wrong direction — the field name in the message (ArmResourceId) sent me looking in the wrong place for a while, when the actual issue was an undocumented naming rule. When a validation error doesn’t make sense, it’s worth searching the exact error text on GitHub issues before digging further yourself — there’s a good chance someone else already found the real root cause.

📚 References