[Test-Purpose] [AI-Suggested] Content update request from Product Release signal: [GitHub] azure-cli azure-cli-2.82.0

[learn-build-service-ppe]

Background

A recent product update has been released that may impact our documentation. This could include new features, changes to existing functionality, or other product enhancements.
Your Action Required: Please review the suggestions below and update the relevant documentation to ensure accuracy and completeness.

Signal Details:

• Title: [GitHub] azure-cli azure-cli-2.82.0
• Source URL: https://github.com/Azure/azure-cli/releases/tag/azure-cli-2.82.0
• Repository: https://github.com/Azure/azure-cli
• ReleaseWindowUtc: 2025-12-02 05:39:31Z - 2026-01-13 03:38:44Z
• TargetBranch: release
• currentTag: azure-cli-2.82.0
• targetCommitish: release
• releaseUrl: https://github.com/Azure/azure-cli/releases/tag/azure-cli-2.82.0
• previousTag: azure-cli-2.81.0

Source Signal Summary

• Azure CLI az network application-gateway settings create and az network application-gateway settings update now support Application Gateway backend settings enableL4ClientIpPreservation via the new --enable-l4-client-ip boolean flag (help indicates default false); this property may now also appear in az network application-gateway settings show/list output.
• Azure CLI az network application-gateway probe create and az network application-gateway probe update now support Application Gateway probe enableProbeProxyProtocolHeader via the new --enable-proxy-header boolean flag (help indicates default false); this property may now also appear in az network application-gateway probe show/list output.
• Azure CLI az network application-gateway probe/* and az network application-gateway settings/* AAZ commands moved from ARM Network api-version 2023-11-01 to 2025-01-01; any az command reference content that mentions supported fields/behavior for these commands should align with the newer API version.
• Azure CLI help content for az network application-gateway probe delete/list/show and az network application-gateway settings delete/list/show removed inline :example: blocks from command docstrings, which may reduce/remove examples shown in az ... -h and downstream az command reference generation.
• Azure CLI adds new preview command groups for Azure Cosmos DB Fleet management in the az command reference: az cosmosdb fleet (create/list/show/delete), az cosmosdb fleetspace (create/update/list/show/delete), and az cosmosdb fleetspace account (create/list/show/delete), including new help entries in cosmosdb/_help.py and examples for create/update commands.
• Azure CLI az cosmosdb fleetspace create|update introduces a required --body/-b JSON (string or @file) with documented schema expectations (properties.throughputPoolConfiguration.minThroughput|maxThroughput; create requires properties.serviceTier and properties.dataRegions), enforced by new validation errors; this affects how users must construct request payloads in scripts and docs.
• Azure CLI az cosmosdb fleetspace account create introduces a required --body/-b JSON (string or @file) requiring properties.globalDatabaseAccountProperties.resourceId (ARM ID) and armLocation, with new validation errors that should be reflected in az command reference examples and parameter descriptions.
• Azure CLI az cosmosdb create / az cosmosdb update adds new command parameters/flags --enable-pbe and --default-priority-level (Cosmos DB request priority behavior), which should be documented under the Cosmos DB account create/update parameters.
• Azure CLI az cosmosdb create and az cosmosdb update add a new --disable-local-auth {true|false} (three-state) parameter to disable key-based authentication on the Cosmos DB account (data plane), effectively enforcing Microsoft Entra ID as the only authentication method when set to true; update the az command reference for these commands/parameters and clarify how this differs from --disable-key-based-metadata-write-access (control plane metadata writes).
• Azure CLI az cosmosdb restore adds --source-backup-location, and the --location help text clarifies it is the target write region and the default backup location unless --source-backup-location is provided; --source-backup-location is no longer marked as preview in help/parameter metadata, and specifying --source-backup-location now takes effect for cross-region restore by being applied to restoreParameters.sourceBackupLocation.
• Azure CLI az acr login now always/enforces acquiring the AAD access token using the Azure Container Registry audience/scope https://containerregistry.azure.net, which may change documented authentication behavior and troubleshooting guidance for az acr login token acquisition.
• Azure CLI az postgres flexible-server fabric-mirroring commands (start, stop, update-databases) now allow Fabric mirroring on Azure Database for PostgreSQL Flexible Server instances with High Availability enabled when the PostgreSQL version is 17 or 18; update the az command reference to remove/qualify the prior limitation (“not supported on servers with high availability enabled”) for PG 17+.
• Azure CLI az postgres flexible-server update High Availability workflow: when HA is enabled, the CLI no longer performs the Fabric mirroring configuration check for PostgreSQL versions 17 and 18 (in addition to 11/12), which may affect documented behavior around update-time validation/guardrails for Fabric mirroring settings on HA servers.
• Azure CLI az appservice list-locations adds a new preview flag --managed-instance-enabled to filter regions that support Azure App Service Managed Instance workers (intended to help identify regions where Managed Instance plans are available), and az appservice list-locations --managed-instance-enabled only returns results for Managed Instance-supported SKU tiers (PremiumV4, PremiummV4); for other SKUs (for example S1) the command returns an empty list (document as SKU requirement/validation behavior for the new flag).
• Azure CLI az vmss get-instance-view is migrated to an AAZ-based implementation that calls the Compute REST instanceView endpoints with api-version=2024-11-01; the command’s JSON output shape/fields (and error formatting) may differ from the previous Track-2 SDK-backed implementation, so az vmss get-instance-view output examples in the az command reference may need refresh.
• Azure CLI az vmss get-instance-view --instance-id '*' now retrieves per-VM instance views via the AAZ az vmss list-instances backend (--select instanceView --expand instanceView) and returns a list of each VM’s instanceView payload (which may include null entries), which can affect scripts relying on the previous output behavior for the wildcard --instance-id case.
• Azure CLI added a new Compute command az vmss get-resiliency-view to return the resiliency status for a specific VM Scale Set instance (uses --instance for the instance ID and -n/--name for the VMSS name; the command forces the underlying expand to resiliencyView, so --expand isn’t exposed for this command).
• Azure CLI updated az vmss list-instances with a new flag --resiliency-view to show resiliency status per instance (changes the command’s output from a simple VM instance list to per-instance resiliency-view results).
• Azure CLI az vmss list-instances command reference/help content was expanded/clarified (new help entry, including guidance that for VMSS Flexible Orchestration mode users should use az vm list for full details) and now documents additional parameters including --max-items and --next-token for pagination.
• Azure CLI az postgres flexible-server create and az postgres flexible-server update add --zonal-resiliency {Enabled,Disabled} (default Disabled on create) as the new way to enable/disable the PostgreSQL flexible server high availability feature; help examples were updated to use --zonal-resiliency Enabled instead of --high-availability ZoneRedundant.
• Azure CLI az postgres flexible-server create/update add --allow-same-zone (boolean) to allow primary and standby in the same zone when multi-zone capacity is unavailable; new az postgres flexible-server create example documents this “same zone” behavior.
• Azure CLI az postgres flexible-server create/update deprecate --high-availability and redirect users to --zonal-resiliency (deprecation warning emitted); using --high-availability together with --zonal-resiliency now fails validation (“Setting both … is not allowed”).
• Azure CLI behavior change for PostgreSQL flexible server high availability validation: in single-availability-zone regions, --zonal-resiliency Enabled now requires --allow-same-zone (otherwise the command errors); --allow-same-zone is only permitted when --zonal-resiliency Enabled is set.
• Azure CLI az postgres flexible-server create and az postgres flexible-server update: removed the validator that blocked --high-availability when --storage-type PremiumV2_LRS (Premium SSD v2) is used, so the az command reference and parameter docs for --high-availability should no longer imply it’s unsupported with Premium SSD v2.
• Azure CLI az postgres flexible-server update: fixed high availability enablement with --zonal-resiliency Enabled --standby-zone <zone> so the command no longer fails with (InvalidParameterValue) ... StandbyAvailabilityZone,availabilityZone during update (the update request now preserves the server’s existing availabilityZone, and validation now allows --standby-zone when either zonal resiliency is enabled or HA is zone-redundant).
• Breaking: Azure CLI az postgres flexible-server create now defaults the PostgreSQL Flexible Server --location to canadacentral (previously eastus) when no location is provided; any docs/examples that rely on the implicit default region should be updated.
• Azure CLI az postgres flexible-server migration delete now calls the PostgreSQL Flexible Server migration cancel operation (SDK cancel(...)) instead of a delete operation; docs for the migration workflow should clarify that “delete” cancels an in-progress migration rather than removing a migration resource in the previous sense.
• Azure CLI az postgres flexible-server upgrade now supports upgrading to PostgreSQL major version 18 via the --version/-v parameter (enum expanded to include 18), and help examples for PostgreSQL Flexible Server were updated to use PostgreSQL 18 (e.g., az postgres flexible-server create --version 18 and az postgres flexible-server upgrade ... -v 18).
• Azure CLI (az command reference): The following az postgres flexible-server ... list commands now support the global --ids argument, allowing you to pass the Azure resource ID of the Postgres flexible server instead of specifying --resource-group/--server-name separately: az postgres flexible-server backup list, db list, firewall-rule list, identity list, long-term-retention list, microsoft-entra-admin list, migration list, parameter list, replica list.
• Azure CLI (az postgres flexible-server replica promote): The --name/-n parameter is now explicitly treated/documented as the read replica name (including updated help/error semantics), aligning the command reference with promoting a replica server rather than a generic server name.
• Breaking: Azure CLI az postgres flexible-server replica create adds --name/-n as the preferred parameter for the read replica server name, deprecating --replica-name (help/examples updated to use --name; command now errors if neither --name nor --replica-name is provided).
• Azure CLI breaking-change announcements added for upcoming (Azure CLI 2.86.0, May 2026) parameter deprecations/repurposing in the az postgres flexible-server command groups backup, db, firewall-rule, long-term-retention, and migration (e.g., --backup-name, --database-name, --rule-name, --migration-name deprecated; --name to be repurposed for the child object name; --server-name to be introduced where needed).
• Breaking: Azure CLI az postgres flexible-server index-tuning command group is now deprecated and redirected to az postgres flexible-server autonomous-tuning (via CLI breaking-change/deprecation messaging); update az command reference and any docs that instruct using index-tuning to point to the new command group.
• Azure CLI adds new command group az postgres flexible-server autonomous-tuning with new commands and help content: update (new required --enabled {True|False}), show, list-settings, show-settings --name, set-settings --name --value, list-index-recommendations --recommendation-type {CreateIndex,DropIndex,ReIndex}, and list-table-recommendations --recommendation-type {AnalyzeTable,VacuumTable}; document the new workflows and parameters in the az command reference.
• Azure CLI az postgres flexible-server index-tuning list-recommendations now maps to a renamed implementation and expands --recommendation-type to include ReIndex; update command parameter docs/examples that enumerate allowed values.
• Behavior-only (Azure CLI / PostgreSQL Flexible Server): enabling az postgres flexible-server autonomous-tuning update --enabled True checks regional capability support and may auto-adjust Query Store capture mode (pg_qs.query_capture_mode) when enabling tuning; document these prerequisites/side effects under CLI authentication and configuration / command behavior notes if current docs imply no additional configuration changes.
• Breaking: Azure CLI az postgres flexible-server create changes the default for --database-name/-d to None (no default database name), and --database-name/-d is now documented/enforced as only applicable when --cluster-option ElasticCluster; using --database-name with other --cluster-option values now fails validation with an ArgumentUsageError (update az command reference parameter rules/examples accordingly).
• Azure CLI az sql mi create and az sql mi update (Azure SQL Managed Instance) add a new --memory parameter to set memory size in gigabytes (GB) (memorySizeInGb / memory_size_in_gb), including new examples in az sql mi help/command reference.
• Azure CLI az sql mi update behavior change: the command now explicitly clears requested_logical_availability_zone (sets it to null) during updates to avoid request failures caused by the previous default value (NoPreference), which may change outcomes for documented “availability zone”/zone preference behavior in az sql mi update.
• Azure CLI adds a new command az mysql flexible-server backup delete to delete an on-demand backup by --backup-name/-b for a given flexible server (includes new az help entry and example in mysql/_help.py).
• Azure CLI updates az mysql flexible-server backup show to accept --resource-group/-g and server name (-n/--name) as explicit parameters, and az mysql flexible-server backup show parameter metadata treats --backup-name/-b as an Azure resource ID child segment (id_part='child_name_1'), which may affect documented --ids usage patterns for the command.
• Azure CLI (MySQL) marks --storage-redundancy as deprecated for az mysql flexible-server create, az mysql flexible-server restore, az mysql flexible-server geo-restore, and az mysql flexible-server replica create (new deprecation warnings via register_argument_deprecate), so command reference docs should reflect the deprecation status.
• Azure CLI az mysql external migration flow updates the --version validation/error message to include MySQL server version 8.4 as an allowed value when --version is required for external migrations (now: 5.7, 8.0.21, 8.4).
• Azure CLI az network virtual-appliance create and az network virtual-appliance update add a new command parameter --interface-configs / --nva-interface-configurations (max 3 items) to configure NVA in VNet interface configurations, supporting fields like name (max 70 chars), subnet.id (subnet resource ID), and type (e.g., PrivateNic, PublicNic, AdditionalPrivateNic, AdditionalPublicNic).
• Azure CLI az network virtual-appliance show and az network virtual-appliance list now surface properties.nvaInterfaceConfigurations and properties.privateIpAddress in the command output (JSON), which may require updates to the az command reference/output examples for Network Virtual Appliance.
• Azure CLI adds a new command group az network virtual-appliance identity with new az commands: assign, remove, show, and wait to manage managed identities for a Network Virtual Appliance; assign/remove support --system-assigned and --user-assigned and honor --no-wait.
• Azure CLI az network virtual-appliance create/update updates the --identity object-style parameters to include nested managed identity inputs (system-assigned / mi-system-assigned and user-assigned / mi-user-assigned) alongside existing identity fields, which may affect documented parameter syntax and examples for configuring Network Virtual Appliance identity.
• Azure CLI az network watcher flow-log create and az network watcher flow-log update now support a new --record-types parameter (comma-separated combinations of B,C,E,D) to filter Flow Log records by flow state; if omitted, the command behavior remains “log all traffic” (update az command reference/parameter docs for Network Watcher Flow Logs).
• Azure CLI az network watcher flow-log show (and az network watcher flow-log wait output) now includes the recordTypes field in the returned Flow Log properties when present, which may require updating any documented JSON/output examples for these commands.
• Azure CLI az network watcher flow-log create identity configuration surface was extended under --identity to include system-assigned/mi-system-assigned and user-assigned/mi-user-assigned inputs, and az network watcher flow-log show/wait now return a structured identity object (including principalId, tenantId, and userAssignedIdentities), which may require updating identity-related guidance/examples in the az network watcher flow-log command reference.
• Azure CLI adds a new command group az monitor dashboard to manage Dashboard with Grafana (Azure resource provider Microsoft.Dashboard/dashboards) resources, including az monitor dashboard create (PUT; idempotent create-or-update) with required --resource-group, --dashboard-name/--name (-n), and --location (optional --tags, supports --no-wait), plus show, list (requires --resource-group, supports pagination), delete (confirmation prompt), and wait; --dashboard-name enforces a specific validation pattern and targets the 2025-09-01-preview management-plane API version.
• Azure CLI az containerapp env create adds a new parameter --infrastructure-resource-group (-i) to specify the name of the infrastructure resource group for the managed environment; if omitted, the Azure CLI behavior remains to auto-generate the infrastructure resource group name, and --infrastructure-resource-group (-i) can only be used when --infrastructure-subnet-resource-id (-s) and --enable-workload-profiles (-w) are also provided (otherwise the command returns a required-argument error).
• Azure CLI az containerapp compose create now depends on pycomposefile>=0.0.34 (was 0.0.32), fixing a runtime TypeError when a Docker Compose service uses env_file without an environment section; update any az command reference/prerequisites text that mentions Compose parsing behavior or pinned pycomposefile versions.
• Azure CLI az identity create adds a new --isolation-scope parameter (enum: None, Regional) to set the User Assigned Managed Identity isolationScope property, restricting identity assignment within an Azure region; update az command reference and examples accordingly.
• Azure CLI az identity update command is added (generic update) and supports --tags and the new --isolation-scope parameter to modify a User Assigned Managed Identity’s isolationScope; add/update az command reference for az identity update including usage and examples.
• Behavior change: Azure CLI switches the default API version for Managed Identity (ResourceType.MGMT_MSI) to 2024-11-30, enabling isolationScope support for az identity create/update; docs that mention supported properties/behavior for az identity may need to reflect the new API version-dependent capability.
• Azure CLI az aks install-cli adds a new --gh-token parameter (gh_token) to pass a GitHub authentication token when downloading kubelogin from GitHub releases, helping avoid GitHub API rate limiting; when --gh-token is provided, requests to GitHub release endpoints for kubelogin include an Authorization: Bearer <token> header (affecting how kubelogin version resolution/download is performed).
• Azure CLI az aks nodepool update adds a new --gpu-driver parameter (enum) to control AKS node pool GPU driver behavior, with documented possible values "Install" or "None"; update the az command reference/help and examples where GPU node pool driver management is described.
• Azure CLI az aks nodepool add and az aks nodepool update: --os-sku now accepts the new Linux value Ubuntu2404 (in addition to existing values like Ubuntu, Ubuntu2204, AzureLinux, AzureLinux3), so the az command reference/help for these commands should include Ubuntu2404 as a supported OS SKU option.
• Azure CLI az keyvault key create and az keyvault key import add a new flag --default-data-disk-policy (alias --default-dd-policy) to set a default Key Release Policy for data disk encryption, alongside the existing --default-cvm-policy; mutual exclusivity is enforced between --policy and --default-data-disk-policy, and between --default-cvm-policy and --default-data-disk-policy (erroring if combined).
• Azure CLI az keyvault command module now uses the TypeSpec-generated management SDK (azure-mgmt-keyvault upgraded to 13.0.0), which may change runtime behavior (e.g., error shapes/messages or JSON output fields) for Key Vault management commands even though the az keyvault command/parameter surface is unchanged.
• Azure CLI core JSON serialization (azure.cli.core.util.todict) now uses azure-core’s get_backcompat_attr_name (requiring azure-core 1.37.0) to preserve backward-compatible attribute names when producing --output json/-o json for Azure SDK model objects (notably relevant to az keyvault outputs after the SDK migration).
• Breaking: Azure CLI removes the az maps creator command group and its commands (az maps creator list/show/create/update/delete), including all associated parameters (for example, --creator-name, --storage-units, --location, --tags); the az command reference should be updated to reflect that these commands are no longer available.
• Breaking: Azure CLI changes az maps account create defaults/constraints: the default SKU/kind is now Gen2 (previously Gen1), the account --location/-l is now supported on az maps account create and defaults to eastus (previously effectively forced to global); update guidance and examples that mention deprecated Gen1 or global.
• Azure CLI az network private-endpoint-connection (Private Link resource/provider registration) adds support for Azure Maps accounts via provider Microsoft.Maps/accounts (API version 2023-12-01-preview), enabling private endpoint connection workflows for az maps resources in the az command reference.
• Azure CLI adds preview support for user delegation SAS for OAuth (--auth-mode login) across az storage blob generate-sas, az storage container generate-sas, az storage fs generate-sas, az storage fs directory generate-sas, az storage share generate-sas, az storage file generate-sas, and az storage queue generate-sas, adding/expanding flags --as-user (requires --auth-mode login and --expiry) and --user-delegation-oid (Entra ID object ID authorized to use the SAS); validation rules were updated so --user-delegation-oid errors unless --as-user is also provided.
• Azure CLI adds a new command az storage fs file generate-sas (ADLS Gen2) to generate a SAS token for a specific file path (--file-system/-f, --path/-p, permissions/expiry/start, optional --full-uri), and it participates in the same preview user-delegation SAS flags/validation (--as-user, --user-delegation-oid) where applicable.
• Azure CLI Storage client behavior changes when a user-delegation SAS token is provided (SAS contains sduoid=) together with OAuth login: the CLI prefers the Entra ID token credential and appends the SAS query string to the Storage service URL (Blob/ADLS Gen2/Queue/File), and suppresses the usual “ignored in login auth mode” warning for credential args in this case—documentation may need to clarify how --sas-token + --auth-mode login works for user-delegation SAS.
• Azure CLI az netappfiles check-file-path-availability now includes an :example: in command help/az command reference showing usage with --location, --name, and --subnet-id (as rendered from the AAZ command docstring).
• Azure CLI az netappfiles check-name-availability now includes an :example: in command help/az command reference showing usage with --location, --name, --type, and --resource-group.
• Azure CLI az netappfiles volume replication commands now include new :example: entries in command help/az command reference for external replication/migration workflows: authorize-external-replication, finalize-external-replication, peer-external-cluster (including --peer-ip-addresses array syntax), and perform-replication-transfer.
• Azure CLI adds a new preview command az cognitiveservices agent create (AI Foundry hosted agents) to create a hosted agent version from either a container image (--image) or local source (--source), including new az command reference help with end-to-end examples.
• az cognitiveservices agent create introduces new/updated command parameters and rules that need documenting in the az command reference: --project-name/-p (and existing agent commands now accept --project-name/-p), required --name/-n, mutually exclusive --image vs --source, --dockerfile, --registry, --build-remote, --cpu, --memory, --env/--environment-variables (space-separated key=value), --protocol (responses|streaming), --protocol-version, --description, --min-replicas, --max-replicas, --timeout, --no-wait, --no-start, and --skip-acr-check (bypasses managed-identity ACR access validation).
• az cognitiveservices agent create behavior: when --source is used, Azure CLI builds and pushes a container image to Azure Container Registry (local Docker build/push when available; otherwise falls back to ACR Task remote build, or forced via --build-remote), and the CLI enforces that the resulting image URI includes a tag because the tag becomes the agent “version” in Azure AI Foundry.
• az cognitiveservices agent create deployment workflow changes that should be documented: by default the CLI automatically starts a deployment after version creation and waits until it reaches “running” (configurable via --timeout); --no-start creates the version without deploying (and cannot be combined with --min-replicas/--max-replicas); --no-wait returns immediately with an “InProgress” status payload and instructs using az cognitiveservices agent show to check status.
• Breaking: Azure CLI az sig image-version create and az sig image-version update now document pending default changes: --end-of-life-date will default to “6 months from publish date” (instead of no default) and --block-deletion-before-end-of-life will default to true (instead of no default); update the az command reference and examples that rely on unset values.
• Azure CLI az sig image-version create / az sig image-version update adds a warning for Azure Compute Gallery resources when using api-version 2026-03-03; document the warning if it affects expected output/automation.
• Azure CLI version bump to 2.82.0 (including azure-cli-core 2.82.0) in packaging metadata and requirements files; update any version-pinned install/upgrade documentation that references 2.81.0.
• Azure CLI security update: azure-cli-core 2.82.0 resolves CVE-2025-66418 and CVE-2025-66471; release notes/security guidance may need to reference these fixes for Azure CLI users.
• Azure CLI installation on Windows (MSI packaging): pinned the pywin32 dependency to version 310 (from 311) to resolve an MSI upgrade issue, which may warrant updating Azure CLI Windows install/upgrade guidance or release notes if docs currently mention the affected upgrade behavior.
• az network application-gateway waf-policy managed-rule rule-set changes behavior to support disabled rules by default; update docs if they implied prior defaults.

Suggestions

Note

Suggestions are generated by AI and they may not be entirely accurate or complete. Please check impacted files scope and suggestions details before making changes.

• docs-ref-autogen/Latest-version/latest/appservice.yml:
  1. In the "--managed-instance-enabled" optional parameter description for az appservice list-locations, add that this filter is only applicable to Managed Instance-capable SKUs (Premium v4 tiers, including memory-optimized v4). State that if a non-supported SKU is provided (for example S1), the command returns an empty list.
  2. Add an example under "Examples" showing the intended usage with a Premium v4 SKU (for example az appservice list-locations --sku P1V4 --managed-instance-enabled) to help users discover the correct SKU/flag combination.
  3. In the az appservice list-locations command summary/intro line, clarify that the returned regions are for the specified SKU and any applied worker capability filters (Hyper-V, Linux, Managed Instance). This helps set expectations that filters can further restrict results and may produce an empty list when the selected SKU doesn't support the requested worker type.
• docs-ref-autogen/Latest-version/latest/vmss.yml:
  1. [Correction] Update the az vmss get-instance-view command description/parameter documentation for --instance-id to clarify that when --instance-id '*' is used, the command returns an array of instance views (one entry per VM) rather than a single instance view object. Explicitly note that some entries in the returned list can be null depending on what the backend returns.
  2. Add an example under az vmss get-instance-view that demonstrates using --instance-id '*' and shows the expected JSON shape (list/array). Include a brief example of a JMESPath query pattern that safely handles potential null entries (for example, filtering out nulls before projecting fields) so scripts can be updated accordingly.
  3. Review any wording that implies az vmss get-instance-view always returns a single 'instance view' payload and adjust it to distinguish between single-instance usage (specific instance id or omitted --instance-id) and wildcard usage ('*'). This helps prevent users from assuming a stable output schema across these cases.
• docs-ref-conceptual/Latest-version/release-notes-azure-cli.md:
  1. In the v2.82.0 (January 13, 2026) > RDBMS section, add a release note entry explicitly stating that az postgres flexible-server create/update deprecates --high-availability and redirects users to --zonal-resiliency via a deprecation warning. Clarify that users should switch to --zonal-resiliency for the same intent going forward.
  2. In the same v2.82.0 > RDBMS section, add an entry noting the new validation behavior: specifying both --high-availability and --zonal-resiliency together now fails with a validation error (mutually exclusive arguments). This is important because it can break scripts that include both flags.
  3. Update the existing v2.82.0 > RDBMS bullet "Show high availability feature with zonal resiliency argument" to be more technically specific by referencing the exact parameters (--high-availability and --zonal-resiliency) and the deprecation/mutual-exclusion behavior. This avoids having two separate, potentially ambiguous entries describing the same change.
• docs-ref-conceptual/Latest-version/release-notes-azure-cli.md:
  1. In the January 13, 2026 (Version 2.82.0) > RDBMS section, add a release note entry explicitly stating that az postgres flexible-server create/update deprecates --high-availability and that users should use --zonal-resiliency instead (including that a deprecation warning is emitted when --high-availability is used).
  2. In the same RDBMS section for 2.82.0, add a release note entry stating that specifying both --high-availability and --zonal-resiliency in the same create/update command is now rejected (validation error) and that the flags are mutually exclusive.
  3. Refine the existing 2.82.0 bullet "az postgres flexible-server create/update: Show high availability feature with zonal resiliency argument" to clearly convey the parameter transition (i.e., --zonal-resiliency is the intended replacement interface for the high availability/zonal resiliency configuration) rather than leaving the relationship ambiguous.
• docs-ref-autogen/Latest-version/latest/postgres/flexible-server.yml:
  1. [Correction] In the az postgres flexible-server create section, update the --location -l parameter description to reflect the new implicit default behavior. Specify that when --location is omitted (and no CLI default location is otherwise configured), the command will default to canadacentral.
  2. [Correction] Update the example titled "Create a PostgreSQL flexible server with default parameters..." that runs az postgres flexible-server create with no arguments. Add an explicit note in the example text that the server will be created in canadacentral unless --location (or an explicit CLI default location) is provided.
  3. Add a short note near the create examples (or immediately under the command description) advising users to specify --location explicitly to avoid unintended regional deployments. This note should be scoped to the create command behavior and not expanded into general guidance beyond what’s necessary for correct usage.
• docs-ref-autogen/Latest-version/latest/postgres/flexible-server.yml:
  1. [Correction] Update the az postgres flexible-server migration delete command reference (the migration sub-group page/section) so the description and any explanatory text clearly state that the command cancels an in-progress migration (maps to the service cancel operation), rather than deleting/removing a migration resource. Remove or replace any wording that implies the migration object is deleted as a resource-management action.
  2. In the az postgres flexible-server top-level command list, add the missing entry for az postgres flexible-server migration delete under the migration command group, with a description aligned to the new behavior (for example, 'Cancel an in-progress migration'). This ensures the command inventory matches what users can run in current Azure CLI versions.
  3. Where the migration workflow is described (within the migration command group content), add a short clarification that 'delete' in this context is used to cancel a running migration, and does not imply permanent removal of a historical migration record/resource. Ensure any examples or guidance that previously recommended 'delete' for cleanup are adjusted to describe cancellation semantics.
• docs-ref-autogen/Latest-version/latest/postgres/flexible-server.yml:
  1. [Correction] In the az postgres flexible-server command list, update the index-tuning entry to explicitly state that it is deprecated and redirects to az postgres flexible-server autonomous-tuning (rather than implying it remains a separate functional group). This prevents users from relying on index-tuning as the primary interface.
  2. [Correction] On the az postgres flexible-server index-tuning reference page (and its subcommand sections), add/adjust the deprecation messaging to indicate the command group is redirected and users should run the corresponding autonomous-tuning commands instead. Where the redirected command names differ (for example, list-recommendations vs list-index-recommendations), update the documented command names accordingly.
  3. [Correction] Review any examples on this page that instruct users to run az postgres flexible-server index-tuning ... and update them to use az postgres flexible-server autonomous-tuning ... so the documented workflow matches the post-change CLI guidance and avoids deprecated syntax.
• docs-ref-autogen/Latest-version/latest/postgres/flexible-server.yml:
  1. [Correction] In the "Commands" table on the az postgres flexible-server reference page, update the index-tuning entry (and its subcommand entries) to reflect that the group is deprecated and redirected/aliased to az postgres flexible-server autonomous-tuning. Ensure the table no longer implies index-tuning is the primary interface for tuning operations.
  2. [Correction] Update the az postgres flexible-server index-tuning reference page(s) (the linked flexible-server/index-tuning and its subcommand sections) to explicitly state that calls are redirected to az postgres flexible-server autonomous-tuning and that users should switch to the autonomous-tuning command group. If the CLI behavior is now an alias/redirect rather than an independently supported command group, adjust wording and structure to avoid documenting index-tuning as a separate feature set.
  3. [Correction] Review any examples or workflows in the PostgreSQL Flexible Server CLI docs that instruct users to run az postgres flexible-server index-tuning ... and replace them with the corresponding az postgres flexible-server autonomous-tuning ... commands. This prevents users from following deprecated guidance and seeing breaking-change/deprecation messaging in otherwise current walkthroughs.
• docs-ref-conceptual/Latest-version/release-notes-azure-cli.md:
  1. [Correction] In the January 13, 2026 (Version 2.82.0) > RDBMS section, update the az postgres flexible-server create entry about the database name defaulting to None to also state that --database-name/-d is now only applicable when --cluster-option ElasticCluster and that using it with other --cluster-option values fails validation (for example, with ArgumentUsageError).
  2. In the same RDBMS section, add a brief breaking-change clarification indicating that this is a behavioral/validation change that may break scripts that always pass --database-name regardless of cluster mode. Keep this scoped to the CLI behavior and the affected command (az postgres flexible-server create).
  3. Review the nearby 2.82.0 bullets Add database name field for create with cluster and Change database name field to default to None for az postgres flexible-server create and consolidate/clarify them so it’s explicit that the database name parameter is tied to Elastic Cluster creation scenarios, while non-cluster creation has no default database name from the CLI.
• docs-ref-autogen/Latest-version/latest/postgres/flexible-server.yml:
  1. [Correction] In the az postgres flexible-server create Examples section, update the description for the bare az postgres flexible-server create example that currently states a “default database will be created by CLI”. Remove or revise that claim to reflect that no default database name is chosen/created by default after the change to --database-name defaulting to None.
  2. [Correction] In the --database-name -d parameter description under az postgres flexible-server create, ensure the documentation reflects that the parameter is only valid when --cluster-option ElasticCluster and that using --database-name with other --cluster-option values results in a CLI validation failure (for example, ArgumentUsageError). This prevents users from assuming it is merely ignored outside ElasticCluster.
  3. [Correction] Where the CLI reference shows defaults for parameters (the Properties tables), update --database-name/-d to indicate the default is None (no default database name). This aligns the reference with the breaking change and avoids users relying on an implied default database being provisioned.
• docs-ref-conceptual/Latest-version/release-notes-azure-cli.md:
  1. In the January 13, 2026 (Version 2.82.0) > Network section, add a release note entry for az network virtual-appliance create/update describing the --identity object-style parameter update to support nested managed identity inputs (system-assigned/user-assigned and the corresponding mi-system-assigned/mi-user-assigned aliases).
  2. If the change affects how existing identity configuration inputs are interpreted (for example, new nested keys alongside previous identity fields), briefly clarify in the same release note entry that this is a parameter/schema change that may require updating scripts that pass --identity as an object.
• docs-ref-autogen/Latest-version/latest/network/watcher.yml:
  1. In the az network watcher flow-log create command section, add --record-types to the command syntax and to the Optional parameters list. Document that it accepts a comma-separated list of record type codes (combinations of B,C,E,D) to filter flow log records by flow state.
  2. In the az network watcher flow-log update command section, add --record-types to the command syntax and to the Optional parameters list with the same accepted values (B,C,E,D in comma-separated combinations). Ensure the parameter description clearly indicates it controls which flow log record types are emitted.
  3. For both create and update, explicitly state the default behavior when --record-types is omitted (that flow logs record all traffic / no filtering is applied). This prevents users from assuming filtering is mandatory or that the default behavior has changed.
• docs-ref-autogen/Latest-version/latest/containerapp.yml:
  1. In the az containerapp env create command section, add --infrastructure-resource-group (-i) to the syntax block and the Optional Parameters list, with a description that it specifies the infrastructure resource group name for the managed environment.
  2. In the az containerapp env create parameter description for --infrastructure-resource-group, document the constraint that it can only be used when --infrastructure-subnet-resource-id (-s) and --enable-workload-profiles (-w) are also provided, and that otherwise the command fails due to missing required arguments.
  3. In the az containerapp env create documentation, clarify the default behavior when --infrastructure-resource-group is omitted (the CLI auto-generates the infrastructure resource group name), so users understand that specifying it is optional and only needed to override the generated name.
• docs-ref-autogen/Latest-version/latest/storage/blob.yml:
  1. [Correction] In the az storage blob generate-sas section, update the --user-delegation-oid parameter description to explicitly state that it can only be used with --as-user. Also note that attempting to pass --user-delegation-oid without --as-user will fail validation.
  2. In the --as-user parameter description for az storage blob generate-sas, add a short cross-reference that --user-delegation-oid is an optional companion flag that is only applicable when generating a user delegation SAS (that is, when --as-user is set). This aligns the parameter guidance with the CLI’s enforced behavior.
  3. Add an example under az storage blob generate-sas showing generation of a user delegation SAS using --auth-mode login --as-user --expiry ... and optionally including --user-delegation-oid <object-id>. This prevents confusion about the required flag combination for OAuth-based user delegation SAS.
• docs-ref-autogen/Latest-version/latest/storage/blob.yml:
  1. [Correction] Update the authentication guidance near the top of the az storage blob page that says users must specify one of --auth-mode, --account-key, --connection-string, --sas-token. Clarify that --auth-mode login can be combined with --sas-token for user-delegation SAS scenarios, rather than implying they are mutually exclusive.
  2. In the common parameter documentation for --sas-token (Storage Account Arguments) and/or --auth-mode, add a brief note describing the behavior when --sas-token is supplied with --auth-mode login: for user-delegation SAS (for example, SAS includes sduoid=), Azure CLI uses the Entra ID token credential and attaches the SAS query string to the request URL.
  3. Add an example under at least one representative command on this page (for example, az storage blob show or az storage blob delete) demonstrating --auth-mode login used together with a user-delegation --sas-token, so users can see the intended syntax for this flow.
  4. Where the page discusses --blob-url as including a SAS token, consider a short clarification that user-delegation SAS URLs are expected to be used alongside Entra ID authentication (login), aligning with the --user-delegation-oid description under az storage blob generate-sas and reducing confusion about which credential actually authorizes the request.
• docs-ref-autogen/Latest-version/latest/cognitiveservices/agent.yml:
  1. [Correction] Update the --image parameter description to align with the current versioning behavior. Remove/replace the statement implying AI Foundry manages agent version independently of the image tag, and instead state that the image tag is used as the agent version identifier for the hosted agent in Azure AI Foundry.
  2. In the --source parameter description (and/or the command description where --source is explained), add that the CLI requires the resulting pushed image URI to include a tag because that tag becomes the agent version in Azure AI Foundry. Make clear that tagless image references are not accepted for agent creation.
  3. In the "Create agent using short registry name" example section (or near the examples), add a brief note that specifying a tag is mandatory and that the tag maps to the agent version. This reinforces why all examples include tags and prevents users from attempting tagless image URIs.
• docs-ref-autogen/Latest-version/latest/cognitiveservices/agent.yml:
  1. In the az cognitiveservices agent create reference section, add --no-wait to the command syntax and parameter list. Describe that --no-wait returns immediately with an InProgress status response and that users should use az cognitiveservices agent show to poll/check deployment status until it reaches running.
  2. Update the --timeout parameter description to explicitly tie it to the default behavior: after version creation, the CLI automatically starts the deployment and waits for it to reach running (unless --no-wait is used). Ensure the wording makes it clear that --timeout controls this wait and not only image pull/build time.
  3. Add an example under az cognitiveservices agent create demonstrating asynchronous usage (for example, creating with --no-wait and then calling az cognitiveservices agent show to check status). This ensures the new workflow is discoverable and prevents users from assuming the create command has fully completed deployment when it returns.
• docs-ref-autogen/Latest-version/latest/network/application-gateway/waf-policy/managed-rule/rule-set.yml:
  1. [Correction] In az network application-gateway waf-policy managed-rule rule-set add and ... rule-set update, revise the --rule parameter description so it no longer states that the rule "will be disabled" unconditionally. Describe --rule as configuring rule overrides (including state) and align the text with the behavior where rules may be disabled by default.
  2. Add a brief note in the add and update command sections clarifying the default rule state behavior (that managed rules can be disabled by default) and what happens when --group-name is provided with no --rule. This should explicitly tell users how to achieve the opposite outcome (for example, enabling specific rules) when defaults start as Disabled.
  3. Update or add an example that demonstrates setting rule state explicitly via --rule ... state=... in addition to the existing 'Disable an attack protection rule' example. This ensures examples remain valid and useful when the default state is Disabled and users need to override state intentionally.

---

📚 To learn more about agentic content maintenance workflow, visit Agentic workflow for Learn content maintenance. Sign in using Learn Profile to access the content on this link.

💬 Share your feedback on the Learn Content Maintenance Agentic Workflow here.