Describe the bug
az cognitiveservices account show returns networkInjections: null for a Foundry (AIServices) account that does have network injection configured. The property is present and correct when the same resource is read via az rest at API version 2025-04-01-preview.
This is a false negative on a property that cannot be changed after account creation. Tooling that checks whether an existing account is network-injected — before deciding whether to deploy into it — will conclude "not injected" and may proceed against the wrong account. The remediation for a genuine mismatch is provisioning a new account and migrating, so a silent wrong answer here is expensive.
To Reproduce
Given a Foundry account created with:
properties: {
networkInjections: [
{
scenario: 'agent'
subnetArmId: '<subnet delegated to Microsoft.App/environments>'
useMicrosoftManagedNetwork: false
}
]
}CLI:
az cognitiveservices account show -n <name> -g <rg> \
--query "properties.networkInjections"
Output:
Raw REST, same resource:
az rest --method get --uri \
"https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.CognitiveServices/accounts/<name>?api-version=2025-04-01-preview" \
--query "properties.networkInjections"
Output:
{
"scenario": "agent",
"subnetArmId": ".../virtualNetworks/<vnet>/subnets/agent-subnet",
"useMicrosoftManagedNetwork": false
}Expected behavior
az cognitiveservices account show returns networkInjections when the account has it, or documents that the command reads an API version which omits the property.
Likely cause
The cognitiveservices command module appears to pin an API version predating networkInjections, so the field is dropped during deserialisation rather than surfaced as unknown.
Environment
- azure-cli 2.77.0
- Resource:
Microsoft.CognitiveServices/accounts, kind: AIServices
- Region:
eastus2
- Confirmed working via REST at
2025-04-01-preview
Impact / workaround
Workaround is to bypass the CLI convenience command and use az rest with an explicit API version. That works, but it is easy to get wrong: the natural command returns a confident, incorrect answer rather than an error, so nothing signals that the result is unreliable.
Describe the bug
az cognitiveservices account showreturnsnetworkInjections: nullfor a Foundry (AIServices) account that does have network injection configured. The property is present and correct when the same resource is read viaaz restat API version2025-04-01-preview.This is a false negative on a property that cannot be changed after account creation. Tooling that checks whether an existing account is network-injected — before deciding whether to deploy into it — will conclude "not injected" and may proceed against the wrong account. The remediation for a genuine mismatch is provisioning a new account and migrating, so a silent wrong answer here is expensive.
To Reproduce
Given a Foundry account created with:
CLI:
Output:
Raw REST, same resource:
Output:
{ "scenario": "agent", "subnetArmId": ".../virtualNetworks/<vnet>/subnets/agent-subnet", "useMicrosoftManagedNetwork": false }Expected behavior
az cognitiveservices account showreturnsnetworkInjectionswhen the account has it, or documents that the command reads an API version which omits the property.Likely cause
The
cognitiveservicescommand module appears to pin an API version predatingnetworkInjections, so the field is dropped during deserialisation rather than surfaced as unknown.Environment
Microsoft.CognitiveServices/accounts,kind: AIServiceseastus22025-04-01-previewImpact / workaround
Workaround is to bypass the CLI convenience command and use
az restwith an explicit API version. That works, but it is easy to get wrong: the natural command returns a confident, incorrect answer rather than an error, so nothing signals that the result is unreliable.