ManagedCluster GET at api-version 2026-06-01 returns containerInsights.logAnalyticsWorkspaceResourceId as empty string when Container Insights is disabled, breaking generated SDK clients

[nadrummond]

Describe the bug

From api-version 2026-06-01, GET Microsoft.ContainerService/managedClusters returns the azureMonitorProfile.containerInsights block for clusters where Container Insights has never been enabled, with an empty string in logAnalyticsWorkspaceResourceId:

"azureMonitorProfile": {
  "containerInsights": {
    "enabled": false,
    "logAnalyticsWorkspaceResourceId": ""
  }
}

Every stable api-version up to and including 2026-05-01 omits the containerInsights block entirely for the same cluster.

The API specification declares this field as an ARM resource id (managedClusters.json for 2026-06-01, ManagedClusterAzureMonitorProfileContainerInsights):

"logAnalyticsWorkspaceResourceId": {
  "type": "string",
  "format": "arm-id",
  ...
}

An empty string is not a valid ARM resource id, so responses at this api-version violate the declared contract for any cluster with Container Insights disabled.

Impact

Generated SDK clients trust the arm-id format. The .NET SDK (Azure.ResourceManager.ContainerService 1.7.0, the first release targeting 2026-06-01) deserializes the field with:

logAnalyticsWorkspaceResourceId = new ResourceIdentifier(prop.Value.GetString());

ResourceIdentifier rejects empty strings, so every full GET of an affected ManagedCluster throws ArgumentException: Value cannot be an empty string. (Parameter 'resourceId') during deserialization — regardless of which property the caller wanted. The SDK team closes this class of report as service-side (Azure/azure-sdk-for-net#52911: "this issue is related to the service side and not the SDK side"), and the sibling defect in NetApp (Azure/azure-sdk-for-net#51803) has been open since August 2025, which is why this is filed against the RP rather than the SDK.

To Reproduce

On any AKS cluster where Container Insights has never been enabled:

az rest --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.ContainerService/managedClusters/<cluster>?api-version=2026-06-01" \
  --query "properties.azureMonitorProfile.containerInsights"
# => { "enabled": false, "logAnalyticsWorkspaceResourceId": "" }

az rest --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.ContainerService/managedClusters/<cluster>?api-version=2026-05-01" \
  --query "properties.azureMonitorProfile.containerInsights"
# => null (block omitted)

Or with the .NET SDK: Azure.ResourceManager.ContainerService 1.7.0, GetContainerServiceManagedClusterResource(id).GetAsync() → throws the ArgumentException above. The same call succeeds when the client pins the wire version via ArmClientOptions.SetApiVersion(ContainerServiceManagedClusterResource.ResourceType, "2026-05-01"), which is the workaround we are shipping.

Expected behavior

When Container Insights is disabled and no workspace is associated, either omit logAnalyticsWorkspaceResourceId (as every api-version through 2026-05-01 does) or return null — never "" in a field declared format: arm-id.

Environment

• Region: North Europe
• api-versions compared: 2026-05-01 (correct) vs 2026-06-01 (regressed)
• Client: Azure.ResourceManager.ContainerService 1.7.0 (.NET), but any strict arm-id consumer is affected

[microsoft-github-policy-service]

Action required from Simon Waight (@sjwaight), Allen Wen (@AllenWen-at-Azure)

[microsoft-github-policy-service]

Kevin Thomas (@kevinkrp93), Maya (@mayasingh17), Vishwanath (@vishiy), saaror would you be able to assist?