Describe the bug
When using az containerapp create --yaml <file>, the containerapp CLI extension serializes the
full internal model object and sends it as the HTTP PUT request body. All unset/optional fields
are included as null instead of being omitted.
This causes Azure Resource Manager (ARM) to fail during deserialization when it tries to convert
a null value into a non-nullable type such as System.Boolean. The result is an HTTP 400 error.
Key offending null field confirmed via --debug:
{
"tags": null,
"extendedLocation": null,
"identity": null,
"managedBy": null,
"kind": null,
"properties": {
"configuration": {
"secrets": null,
"activeRevisionsMode": null,
"ingress": {
"fqdn": null,
"transport": null,
"traffic": null,
"allowInsecure": null, <- ARM tries to deserialize this as System.Boolean -> FAILS
"ipSecurityRestrictions": null,
"stickySessions": null,
"clientCertificateMode": null,
...
},
"dapr": null,
"runtime": null,
...
},
"template": {
"revisionSuffix": null,
"initContainers": null,
"containers": [
{
"command": null,
"args": null,
"env": null,
"volumeMounts": null,
"probes": null
}
],
"volumes": null,
"serviceBinds": null"
},
"workloadProfileName": null,
...
}
}
az containerapp update --yaml works : The update command uses HTTP PATCH and sends
only a sparse/diff body (without null fields), which succeeds. In this case, update requires the
resource to already exist and cannot be used for initial creation.
This bug has been confirmed on both Global Azure (AzureCloud) and Azure China (AzureChinaCloud).
Related command
az containerapp create --name <app> --resource-group <rg> --yaml <path-to-yaml>
Errors
Bad Request({"type":"https://tools.ietf.org/html/rfc9110#section-15.5.1",
"title":"One or more validation errors occurred.",
"status":400,
"errors":{"$":["The JSON value could not be converted to System.Boolean.
Path: $ | LineNumber: 0 | BytePositionInLine: 4."]}})
Issue script & Debug output
Minimal reproduction YAML (capp-test.yaml):
location: eastus
name: capp-test
resourceGroup: my-rg
type: Microsoft.App/containerApps
properties:
managedEnvironmentId: /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/managedEnvironments/<env>
configuration:
ingress:
external: true
targetPort: 80
template:
containers:
- name: capp-test
image: mcr.microsoft.com/k8se/quickstart:latest
resources:
cpu: 0.5
memory: 1Gi
scale:
minReplicas: 1
maxReplicas: 1
Reproduce:
az containerapp create --name capp-test --resource-group my-rg --yaml capp-test.yaml --debug
Debug log shows the PUT request body contains dozens of null fields, including
"allowInsecure": null, which ARM cannot deserialize as System.Boolean.
Expected behavior
The CLI extension should omit null/unset fields from the PUT request body (or use JSON merge
patch semantics), so that ARM only receives fields that are explicitly set in the YAML.
Workaround that works today: use az deployment group create --template-file xxx.bicep (Bicep
or ARM JSON), which does not have this serialization issue.
Environment Summary
az --version
azure-cli 2.84.0
core 2.84.0
telemetry 1.1.0
Extensions:
containerapp 1.3.0b4
resource-graph 2.1.1
Dependencies:
msal 1.35.0b1
azure-mgmt-resource 24.0.0
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\xxx.azure'
Extensions directory 'C:\Users\xxx.azure\cliextensions'
Python (Windows) 3.13.11 (tags/v3.13.11:6278944, Dec 5 2025, 16:17:02) [MSC v.1944 32 bit (Intel)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
az containerapp update --yaml (PATCH) works correctly because it sends a sparse body
az deployment group create --template-file (Bicep/ARM JSON) works correctly
- The
--yaml input flag is unique to az containerapp commands; other services
(az vm, az aks, az deployment) do NOT support --yaml as an input format
Describe the bug
When using
az containerapp create --yaml <file>, the containerapp CLI extension serializes thefull internal model object and sends it as the HTTP PUT request body. All unset/optional fields
are included as
nullinstead of being omitted.This causes Azure Resource Manager (ARM) to fail during deserialization when it tries to convert
a
nullvalue into a non-nullable type such asSystem.Boolean. The result is an HTTP 400 error.Key offending null field confirmed via --debug:
{ "tags": null, "extendedLocation": null, "identity": null, "managedBy": null, "kind": null, "properties": { "configuration": { "secrets": null, "activeRevisionsMode": null, "ingress": { "fqdn": null, "transport": null, "traffic": null, "allowInsecure": null, <- ARM tries to deserialize this as System.Boolean -> FAILS "ipSecurityRestrictions": null, "stickySessions": null, "clientCertificateMode": null, ... }, "dapr": null, "runtime": null, ... }, "template": { "revisionSuffix": null, "initContainers": null, "containers": [ { "command": null, "args": null, "env": null, "volumeMounts": null, "probes": null } ], "volumes": null, "serviceBinds": null" }, "workloadProfileName": null, ... } }az containerapp update --yamlworks : The update command uses HTTP PATCH and sendsonly a sparse/diff body (without null fields), which succeeds. In this case,
updaterequires theresource to already exist and cannot be used for initial creation.
This bug has been confirmed on both Global Azure (AzureCloud) and Azure China (AzureChinaCloud).
Related command
Errors
Issue script & Debug output
Minimal reproduction YAML (
capp-test.yaml):Reproduce:
Debug log shows the PUT request body contains dozens of
nullfields, including"allowInsecure": null, which ARM cannot deserialize asSystem.Boolean.Expected behavior
The CLI extension should omit null/unset fields from the PUT request body (or use JSON merge
patch semantics), so that ARM only receives fields that are explicitly set in the YAML.
Workaround that works today: use
az deployment group create --template-file xxx.bicep(Bicepor ARM JSON), which does not have this serialization issue.
Environment Summary
az --version
azure-cli 2.84.0
core 2.84.0
telemetry 1.1.0
Extensions:
containerapp 1.3.0b4
resource-graph 2.1.1
Dependencies:
msal 1.35.0b1
azure-mgmt-resource 24.0.0
Python location 'C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\python.exe'
Config directory 'C:\Users\xxx.azure'
Extensions directory 'C:\Users\xxx.azure\cliextensions'
Python (Windows) 3.13.11 (tags/v3.13.11:6278944, Dec 5 2025, 16:17:02) [MSC v.1944 32 bit (Intel)]
Legal docs and information: aka.ms/AzureCliLegal
Your CLI is up-to-date.
Additional context
az containerapp update --yaml(PATCH) works correctly because it sends a sparse bodyaz deployment group create --template-file(Bicep/ARM JSON) works correctly--yamlinput flag is unique toaz containerappcommands; other services(az vm, az aks, az deployment) do NOT support
--yamlas an input format