Validation errors on conflicting properties

“az vmss update retains the previous zone placement filter when switching between --include-zones and --exclude-zones ### Describe the bug A VM Scale Set can persist either `placement.includeZones` or `placement.excludeZones`. When `az vmss update` is used to switch to the opposite filter, Azure CLI preserves the filter loaded from the existing VMSS and adds the newly requested filter. For example: 1. The VMSS currently has `placement.includeZones`. 2. The user runs `az vmss update` with only `--exclude-zones`. 3. Generic update retains the existing `includeZones` value and adds `excludeZones`. 4. The model passed to the final VMSS create-or-update operation contains both mutually exclusive properties. The reverse transition—existing `excludeZones` followed by `--include-zones`—has the same defect. ### Actual behavior A deterministic test of the real update handler observed both properties at the final `VMSSCreate(command_args=...)` boundary: ```python { "zone_placement_policy": "Auto", "include_zones": ["1"], "exclude_zones": ["2"], } ``` The current validator rejects both flags when they are supplied in one invocation, but it cannot see an opposite filter already present in the VMSS state loaded by generic update. ### Related command `az vmss update` ### Errors A live Azure request was not performed during this investigation, so no local service error or `--debug` log was captured. Azure/azure-cli#33473 documents the Compute response when both properties are sent: ```text BadRequest: Both 'placement.includeZones' and 'placement.excludeZones' cannot be set. ``` ### Issue script & Debug output This was verified deterministically against current `dev` at commit `8bead7f93f086629efb160d56c25f508156925bf`. The regression test supplies an existing VMSS response containing one camelCase placement filter, invokes the actual `update_vmss` handler with only the opposite snake_case argument, mocks the final `VMSSCreate` operation boundary, and inspects the complete `command_args`. Both transition directions are covered. Test command: ```bash PYTHONPATH=src/azure-cli:src/azure-cli-core:src/azure-cli-testsdk \ python -m unittest \ azure.cli.command_modules.vm.tests.latest.test_custom_vm_commands.TestVmCustom.test_update_vmss_switches_zone_placement_filter ``` Before changing production code: ```text FF Ran 1 test FAILED (failures=2) ``` The failures specifically showed the stale opposite filter still present in the model passed to `VMSSCreate`. After the two-line normalization fix, the same test passes in both directions; the canonical `azdev` run reports `1 passed, 2 subtests passed`. Proposed test/fix commit: https://github.com/ryo-whaletech/azure-cli/commit/8f26c3f182c7f1dbd0b3adfd3d7e486c9d32791b No live `--debug` output is available; no Azure resources were changed for this source-level reproduction. ### Expected behavior Updating a VMSS from one zone placement filter to the other should not cause Azure CLI to send both mutually exclusive placement filters in the same request. ### Environment Summary ### Latest released version affected by source inspection ```text azure-cli 2.90.0 core 2.90.0 telemetry 1.1.0 Extensions: None ``` The `azure-cli-2.90.0` source tag (`dc50d475a00ded4a1a1980d4a10a9fbd9a750a81`) contains the same stale-filter update logic. This is source inspection only; a packaged 2.90.0 live failure was not claimed. ### Development verification ```text Repository: Azure/azure-cli Branch: dev Commit: 8bead7f93f086629efb160d56c25f508156925bf Python: 3.13.11 OS: macOS 26.6.2 arm64 ``` ### Live reproduction environment Not performed. No usable authenticated disposable Azure VMSS environment was available, so no live transition or sanitized `--debug` capture is included. ### Additional context - #31951 is the earlier overall Automatic Zone Placement feature request. - #33473 doc”