Extension resources throws error when their name is empy string not deployed but dependent on another resource
- Dominant language
- Bicep
- Stars
- 3.6k
- Forks
- 830
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 79
Description
**Bicep version**
Bicep CLI version 0.38.33 (6bb5d5f859)
**Describe the bug**
We have extension resources : https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/extension-resource-types#microsoftkubernetesconfiguration
It seems these extension resources act differently when they have conditions and referenced in dependsOn statement. To demonstrate this see below steps
**To Reproduce**
Let's have the following template:
```bicep
param extension1Name string = ''
param extension2Name string = ''
resource aks 'Microsoft.ContainerService/managedClusters@2025-07-02-preview' = {
name: 'aks00232'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
properties: {
dnsPrefix: 'aksdns00232'
servicePrincipalProfile: {
clientId: 'mis'
}
agentPoolProfiles: [
{
name: 'agentpool'
count: 3
vmSize: 'Standard_DS2_v2'
osType: 'Linux'
mode: 'System'
type: 'VirtualMachineScaleSets'
}
]
}
}
resource extension1 'Microsoft.KubernetesConfiguration/extensions@2024-11-01' = if (!empty(extension1Name)) {
name: extension1Name
scope: aks
properties: {
extensionType: 'type1'
scope: {
cluster: {
releaseNamespace: 'namespace1'
}
}
releaseTrain: 'stable'
autoUpgradeMinorVersion: true
version: null
configurationSettings: {}
configurationProtectedSettings: {}
}
}
resource extension2 'Microsoft.KubernetesConfiguration/extensions@2024-11-01' = if (!empty(extension2Name)) {
name: extension2Name
scope: aks
dependsOn: [
extension1
]
properties: {
extensionType: 'type2'
scope: {
cluster: {
releaseNamespace: 'namespace1'
}
}
releaseTrain: 'stable'
autoUpgradeMinorVersion: true
version: null
configurationSettings: {}
configurationProtectedSettings: {}
}
}
```
Here we deploy AKS cluster and two extension resources. Both extension resources have conditions and are deployed only when the condition is met. The second extension depends on the first extension. You should be able to deploy the second extension without problem if the condition is not met on the first extension and it is not deployed. For example you can use the following bicep parameters file for that scenario:
```bicep
using 'test.bicep'
param extension2Name = 'extension1'
```
With that example the deployment fails on validation with the following error message:
```
VERBOSE: Using Bicep v0.38.33
VERBOSE: Calling Bicep with arguments: build-params "D:\dev\GitHub\BicepTemplates\test.bicepparam" --stdout
VERBOSE: Using Bicep v0.38.33
VERBOSE: Calling Bicep with arguments: build "D:\dev\GitHub\BicepTemplates\test\test.bicep" --stdout
VERBOSE: Using Bicep v0.38.33
VERBOSE: Calling Bicep with arguments: build-params "D:\dev\GitHub\BicepTemplates\test.bicepparam" --stdout
VERBOSE: Performing the operation "Creating Deployment" on target "identities".
New-AzResourceGroupDeployment: 20:43:25 - Error: Code=InvalidTemplate; Message=Deployment template validation failed: 'The resource 'Microsoft.ContainerService/managedClusters/aks00232/providers/Microsoft.KubernetesConfiguration' is not defined in the template. Please see https://aka.ms/arm-syntax for usage details.'.
New-AzResourceGroupDeployment: The deployment validation failed
```
If I add some dummy name to the first extension and if the condition is not met the deployment will work but that for me is workaround as the condition and the code for the extension works perfectly fine if it is used on regular resources so there is issue only when it is extension resource. That means that the ARM engine acts differently on regular resources and extension resource. So from my perspective this is a bug in ARM. It seems that the extension resource is still somehow processed even when the condition is not met and by processing it it tries to use the empty string as name and thus giving error that it cannot find the resource. Although if you give it some dummy name and that dummy resource does not exists ARM somehow does not generates the error.
Here is a code with workaround for this issue which will not generate the error using the same bicep parameters file:
```
param extension1Name string = ''
param extension2Name string = ''
resource aks 'Microsoft.ContainerService/managedClusters@2025-07-02-preview' = {
name: 'aks00232'
location: resourceGroup().location
identity: {
type: 'SystemAssigned'
}
properties: {
dnsPrefix: 'aksdns00232'
servicePrincipalProfile: {
clientId: 'mis'
}
agentPoolProfiles: [
{
name: 'agentpool'
count: 3
vmSize: 'Standard_DS2_v2'
osType: 'Linux'
mode: 'System'
type: 'VirtualMachineScaleSets'
}
]
}
}
resource extension1 'Microsoft.KubernetesConfiguration/extensions@2024-11-01' = if (!empty(extension1Name)) {
name: !empty(extension1Name) ? extension1Name : 'dummy1'
scope: aks
properties: {
extensionType: 'type1'
scope: {
cluster: {
releaseNamespace: 'namespace1'
}
}
releaseTrain: 'stable'
autoUpgradeMinorVersion: true
version: null
configurationSettings: {}
configurationProtectedSettings: {}
}
}
resource extension2 'Microsoft.KubernetesConfiguration/extensions@2024-11-01' = if (!empty(extension2Name)) {
name: !empty(extension2Name) ? extension2Name : 'dummy2'
scope: aks
dependsOn: [
extension1
]
properties: {
extensionType: 'type2'
scope: {
cluster: {
releaseNamespace: 'namespace1'
}
}
releaseTrain: 'stable'
autoUpgradeMinorVersion: true
version: null
configurationSettings: {}
configurationProtectedSettings: {}
}
}
```
I have not tested with other extension resources but I would assume it is the same behavior as it will be strange if the issue is only present for Microsoft.KubernetesConfiguration/extensions resource type.
**Additional context**
Add any other context about the problem here.
Contributor guide
Research direction
Start with the Bicep template and .bicepparam example in the issue, reproducing the deployment with extension1Name empty and extension2Name set. Compare validation with the dummy-name workaround and determine whether the failure is in Bicep output or ARM handling. Done means the conditional extension dependency validates without requiring a dummy resource name.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- azure
- Domain
- cloud, infrastructure
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100