v6.0.0 - 'Deploy-Private-DNS-Zones' policy assignment now contains invalid resource IDs for some private DNS zone IDs

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Versions

terraform: 1.8.5

azure provider: 3.113.0

module: 6.0.0

Description

Describe the bug

In the process of reviewing the terraform plan for the upgrade from v5.2.1 to v6.0.0 I noticed some new behaviour that is undesired in my opinion.

In our environment we are invoking the module two times, because our Connectivity subscription is a legacy subscription that we did not want to be automatically reparented to a new management group; this subscription is where the private DNS zones exist. We thus configured the module not to deploy connectivity resources for the first module invocation (deploy_connectivity_resources=false), and then we called the module a second time to only deploy connectivity resources. In order to wire up the private DNS zone locations for the Deploy-Private-DNS-Zones policy assignment, we used the archetype_config_overrides for the first module invocation. In v5.2.1 this had the desired effect of populating the placeholder private DNS zone resource IDs with the actual values and everything was working fine.

In v.6.0.0, however, we are seeing placeholder entries for entries that we are not even including in our deployment. For example, we have no entries for ARC related private DNS zones, because we don't require those capabilities right now and don't have those zones. In the plan, we're seeing:

# module.enterprise_scale.azurerm_management_group_policy_assignment.enterprise_scale["/providers/Microsoft.Management/managementGroups/lzroot-corp/providers/Microsoft.Authorization/policyAssignments/Deploy-Private-DNS-Zones"] will be updated in-place
  ~ resource "azurerm_management_group_policy_assignment" "enterprise_scale" {
        id                   = "/providers/Microsoft.Management/managementGroups/lzroot-corp/providers/Microsoft.Authorization/policyAssignments/Deploy-Private-DNS-Zones"
        name                 = "Deploy-Private-DNS-Zones"
      ~ parameters           = jsonencode(
          ~ {
              + azureArcGuestconfigurationPrivateDnsZoneId          = {
                  + value = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg_imsd_ops_dns_pr/providers/Microsoft.Network/privateDnsZones/privatelink.guestconfiguration.azure.com"
                }
              + azureArcHybridResourceProviderPrivateDnsZoneId      = {
                  + value = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg_imsd_ops_dns_pr/providers/Microsoft.Network/privateDnsZones/privatelink.his.arc.azure.com"
                }
              + azureArcKubernetesConfigurationPrivateDnsZoneId     = {
                  + value = "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/rg_imsd_ops_dns_pr/providers/Microsoft.Network/privateDnsZones/privatelink.dp.kubernetesconfiguration.azure.com"
                }
              + azureBotServicePrivateDnsZoneId                     = {
                  + value = "/subscriptions/<redacted subscription guid>/resourceGroups/rg_imsd_ops_dns_pr/providers/Microsoft.Network/privateDnsZones/privatelink.directline.botframework.com"
                }

... snip ...

Steps to Reproduce

Create a configuration that does not deploy connectivity resources, but passes in private DNS zone IDs to Deploy-Private-DNS-Zones policy assignment via archetype_config_overrides. Don't include all of the possible private DNS zone IDs.
Run terraform plan
Check the content of the plan for the Deploy-Private-DNS-Zones policy assignment resource.

Screenshots

n/a

Additional context

If there is some other way we should be handling our 'mixed-mode' deployment (calling module twice, treating Connectivity separately), I'm all ears. Back when we set it up this way it seemed to be the way to handle avoiding reparenting of the Connectivity subscription. I'm not sure if there is a better way now, or if it would solve the problem reported in this issue.

Note that there are other entries showing up with placeholder resource IDs in the Deploy-Private-DNS-Zones policy assignment for non-existing/non-required zones as well, the ARC ones were just one example. In my particular deployment we also see: azureIotCentralPrivateDnsZoneId, azureIotDeviceupdatePrivateDnsZoneId, azureMachineLearningWorkspaceSecondPrivateDnsZoneId, azureManagedGrafanaWorkspacePrivateDnsZoneId, azureSiteRecoveryBackupPrivateDnsZoneID, azureSiteRecoveryBlobPrivateDnsZoneID, azureSiteRecoveryBlobPrivateDnsZoneID, azureVirtualDesktopHostpoolPrivateDnsZoneId and azureVirtualDesktopWorkspacePrivateDnsZoneId

Azure / terraform-azurerm-caf-enterprise-scale