Microsoft.Cdn/profiles/customDomains, what-if shows unmanaged changes with certificateType: 'ManagedCertificate'

[ricemeisterio]

Bicep version az bicep version Bicep CLI version 0.23.1 (b02de2da48)

Describe the bug When using

resource CustomDomain 'Microsoft.Cdn/profiles/customDomains@2022-11-01-preview' =
properties: {
    hostName: HostName
    preValidatedCustomDomainResourceId: null
    tlsSettings: {
      certificateType: 'ManagedCertificate'
      minimumTlsVersion: 'TLS12'
    }
  }

When creating a custom domain for Azure Cdn / Front Door with ManagedCertificate type, once the certificate is provisioned, properties.tlsSettings.secret shows a change that cannot be managed. It creates the custom domain and certificate correctly. However, once the certificate is provisioned future az deployment group what-if What If checks show a change per custom domain, e.g. properties.tlsSettings.secret:

    id: "/subscriptions/b219a2c9-68f0-48fd-bed2-de79f1e35927/resourceGroups/ioa-nonprod-global-frontdoor-rg/providers/Microsoft.Cdn/Profiles/ioa-nonprod-global-frontdoor/secrets/5f2dc483-8ae3-49fb-87cd-bce6f0051628-dev-safetylinks-net"

with no documented method to predefine this at creation time or ignore in what-if or future changes.

To Reproduce

1. Create custom domain for Azure Cdn Front Door Profile using certificateType: 'ManagedCertificate' (resource CustomDomain 'Microsoft.Cdn/profiles/customDomains@2022-11-01-preview')
2. Validate domain, wait for certification provisioning
3. Run az deployment group what-if to review changed property.

Additional context N/A

[btakashi]

I have this same problem, +1

[asbjornu]

I just ran into this as well. @ricemeisterio, did you go through with the deployment? If so, what happened? Was the secret deleted and did that cause the custom domain to become unavailable until a new TLS certificate had been issued, or did it happen gracefully somehow? I would love to know the consequences of deploying this change to production before actually doing it.