Resource IDs

/subscriptions/{sub}/resourceGroups/{rg}/providers/{Namespace}/{type}/{name}
/subscriptions/{sub}/resourceGroups/{rg}/providers/Microsoft.KeyVault/vaults/{vault}/secrets/{secret}          # child
{resource-id}/providers/Microsoft.Insights/diagnosticSettings/{name}                                           # extension
/subscriptions/{sub}/resourceGroups/{rg}                                                                       # resource group
/providers/Microsoft.Management/managementGroups/{mg}                                                          # management group

A child type adds a /{subtype}/{name} pair; the name has as many /-separated segments as the type (vaults/secrets → vault/secret).
An extension resource (diagnostic settings, locks, role assignments) hangs off another resource's ID with its own /providers/….
Prefer IDs from Azure over IDs you build: az <service> show … --query id -o tsv, az resource show --ids <id>, or a Bicep symbol's .id. In Bicep, resourceId() builds a string, but it creates no dependency and doesn't check the resource exists.

Resource providers

Each namespace (Microsoft.Storage, Microsoft.Web, …) is a resource provider that a subscription must be registered for.

Automatic: the portal registers what you create; a Bicep or ARM deployment registers the providers declared in the template. Not the supporting ones a resource creates on its own (monitoring, security), and not under Terraform azurerm v5 by default.
Manual: az provider register --namespace Microsoft.App. It needs */register/action, which Contributor and Owner include. Registration adds the provider's app to your Entra tenant, so register only what you use.
State: az provider show --namespace <ns> --query registrationState. Registration runs region by region; a resource can be created in a region once that region is done, so code shouldn't wait for Registered everywhere.
You can't unregister while resources of that provider exist. Re-register when a provider adds regions you need.

API versions

Every request, template resource and SDK client targets an API version. Each version has its own property set and defaults; Key Vault's permission-model default changed at 2026-02-01, for example (reference/keyvault/access-and-errors.md).

az provider show --namespace Microsoft.Storage \
  --query "resourceTypes[?resourceType=='storageAccounts'].{versions:apiVersions[0:5], locations:locations}"

Choosing one:

Templates: the newest stable version that your Bicep CLI has types for (no BCP081 warning), set explicitly per resource.
SDKs: each package pins its versions; upgrade the package rather than overriding.
Raw REST: the newest stable from the provider's list. Previews change without notice.

Newest stable versions on 2026-10-20 for types this hub uses (REST specs; "Bicep" means Bicep 0.48.1 has types for it):

Type	Newest stable	Bicep
`Microsoft.Resources/resourceGroups`	2025-04-01	yes
`Microsoft.Resources/deployments`	2026-06-01	yes
`Microsoft.Resources/deploymentStacks`	2025-07-01	yes
`Microsoft.Authorization/roleAssignments`	2022-04-01	yes
`Microsoft.Authorization/locks`	2020-05-01	yes
`Microsoft.KeyVault/vaults`	2026-05-15	yes
`Microsoft.Storage/storageAccounts`	2026-09-01	no: newest with types is 2026-06-01
`Microsoft.Network/virtualNetworks`	2026-03-01	no: newest with types is 2026-01-01

Recheck before relying on the table; the command above is the live answer.

Control plane and data plane

https://management.azure.com (Resource Manager) creates and configures resources. The data each resource holds is served at its own endpoint (https://<vault>.vault.azure.net, https://<account>.blob.core.windows.net) with its own permissions and limits. Locks, Azure Policy and Resource Manager throttling apply to the control plane only.