Guidance on Location Default Parameter Values

[glsutter]

Describe the bug
In our tenant, we restrict the locations available for resources. Many of the ALZ policies include location parameters with default values that are NOT allowed for resources in our tenant.

To deal with this issue, it seens we have a couple of choices, neither being very good:

• Modify the default values for the location parameters in the policy definition
• Override the value of the parameter when assigning the policy. Of course, this requires identifying all of the policies using locations we do not allow.

Are there other alternatives for dealing with a restricted list of locations? How do others deal with this issue?

Steps to reproduce
Just download the current policies. For example, many of the ALZ policies have a "northeurope" defaultValue for location.

[Springstone]

@glsutter it may be that you're concerned about the "location" parameter in several DeployIfNotExists policies, that we default to "northeurope". This value is required for those deployments, but resources are not deployed in that region, it uses the region you provide as a parameter - and we always use the provided location parameter for deployment location.

E.g. for the Deploy-VNET-HubSpoke.json

We don't deploy to the "location" (red arrow), we use the "vNetLocation" (yellow arrow). The "location" parameter is required for this type of deployment, but resources don't get deployed there.

Does that address your concern?

[glsutter]

Yes, I see that policy has a vNetLocation parameter and the hard-coded location is irrelevant. Thank you for the clarification.

I believe there are other definitions with a defaultValue of northeurope for a location parameter, but those can be overridden when assigning the policy. Is that how those should be handled?

Thanks

[glsutter]

Another related question, I think. When the location of a deployment is hard-coded, doesn't that mean the deployment metadata is stored in that location? I was told that applies to ARM templates and Bicep, but I haven't seen anything documented about deployment metadata for DINE policies. Deployment metadata is in an unexpected region would be undesirable. Of course, this only applies to DINE policies with a hard-coded location in the template.

We're just trying to understand if any of the locations need to be modified for our restricted list of regions.

Thanks

[Springstone]

@glsutter yes, this is correct. Deployment metadata would be stored in the associated region, but has no impact on deployed resources, their operation or management thereof. This is purely to be able to store it somewhere while deploying - once deployed it has no impact.

This should not impact your restricted regions, as resources won't be deployed in those hardcoded regions. They get deployed in the regions specified as part of the template (ARM/Bicep/Terraform).