Microsoft.Cdn/profiles/secrets works with FrontDoor profile but not CDN

[CamiloTerevinto]

Bicep version 0.27.1

Describe the bug Deploying a Microsoft.Cdn/profiles/secrets@2024-02-01 resource against a Microsoft.Cdn/profiles@2024-02-01 with SKU Standard_AzureFrontDoor (or Premium_AzureFrontDoor) works, but fails with "That action isn't valid on this profile" when the SKU is Standard_Microsoft.

To Reproduce

Assuming a Key Vault has been previously created, that it contains a certificate, and that the FrontDoor/CDN application has been granted access to it:

param profileName string
param keyVaultName string
param keyVaultSecretName string

resource profile 'Microsoft.Cdn/profiles@2024-02-01' = {
  name: profileName
  location: 'global'
  sku: { name: 'Standard_Microsoft' }
}

resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName

  resource secret 'secrets' existing = {
    name: keyVaultSecretName
  }
}

resource profileSecret 'Microsoft.Cdn/profiles/secrets@2024-02-01' = {
  parent: profile
  name: '${keyVaultName}-${keyVaultSecretName}-latest'
  properties: {
    parameters: {
      secretSource: {
        id: keyVault::secret.id
      }
      useLatestVersion: true
      type: 'CustomerCertificate'
    }
  }
}

Additional context This was reported over 2 years ago under #5567 but the "solution" is a workaround at best and not an actual solution.

[stephaniezyen]

This looks to be an issue with the Microsoft.Cdn RP team. I would suggest opening up a support ticket with them if you would like this issue to be resolved sooner.

[charlesb87]

Good day! I face the exact same issue with the SKU Standard_Microsoft. @CamiloTerevinto can you share to me what is the workaround you mention?

All the best

[CamiloTerevinto]

Hey @charlesb87, we decided to just stop using classic CDNs altogether and moved everything to a Standard Front Door. You can see the original workaround here: https://github.com/Azure/bicep/discussions/5567