Network injection requires Microsoft.App and Microsoft.ContainerService registration; undocumented and fails after account creation

Summary

Deploying a Foundry account with networkInjections (scenario: 'agent') fails on a subscription that has not registered Microsoft.App and Microsoft.ContainerService. Neither the network-injection setup docs nor the 15-private-network-standard-agent-setup sample mention this prerequisite.

The failure is unusually costly because it surfaces after the account resource is accepted, so the deployment leaves a Failed Foundry account behind that must be cleaned up before retrying.

Repro

Subscription with Microsoft.App and Microsoft.ContainerService in NotRegistered. Region eastus2.

Minimal template:

resource account 'Microsoft.CognitiveServices/accounts@2025-04-01-preview' = {
  name: accountName
  location: location
  kind: 'AIServices'
  sku: { name: 'S0' }
  identity: { type: 'SystemAssigned' }
  properties: {
    allowProjectManagement: true
    customSubDomainName: accountName
    publicNetworkAccess: 'Disabled'
    disableLocalAuth: true
    networkAcls: { defaultAction: 'Deny' }
    networkInjections: [
      {
        scenario: 'agent'
        subnetArmId: agentSubnetId   // delegated to Microsoft.App/environments, /26
        useMicrosoftManagedNetwork: false
      }
    ]
  }
}

az deployment group create ...

Actual

ResourceProviderExtensionError: ExtendedErrorInfo:: Kind: AmlRp, Code: BadRequest,
Message: Capability host creation failed with agent messages:
{"Status":5,"ErrorCode":"400","Messages":[
  "Subscripton '<sub-id>' is not registered with the required resource providers,
   please register with the resource providers Microsoft.App and Microsoft.ContainerService."
]}

The account reaches provisioningState: Failed.

Note the message also contains a typo: Subscripton.

Expected

Either:

1. the prerequisite is documented alongside the other requirements (delegated subnet, /27 minimum, RFC1918), and added to the sample's prerequisites; or
2. ARM preflight rejects the deployment before the account resource is created, so no Failed account is left behind.

Confirmation

After az provider register -n Microsoft.App and az provider register -n Microsoft.ContainerService, the identical deployment succeeded:

• account provisioningState: Succeeded, publicNetworkAccess: Disabled
• capability host auto-created — kind: Agents, Succeeded
• networkInjections reads back correctly

Environment

• API version 2025-04-01-preview
• Region eastus2
• Delegated subnet /26, delegation Microsoft.App/environments
• Azure CLI 2.77.0, Bicep 0.40.2

Additional note

Capability-host creation on an injected account took roughly 35 minutes. That is worth stating in the docs so operators do not assume a hang and cancel mid-deploy.