welcome[bot]
commented
1 month ago Thank you for opening an issue! One of our team members will get back to you with additional information.
If this is a product issue, please close this issue and contact the product's support instead. For a list of support websites, see Support for Microsoft products and apps.
I've recently had to spend far too long getting an Azure Policy to deploy Lighthouse delegations to resource groups in subscriptions.
The major problem I encountered was that when creating policy to use DeployIfNotExists to deploy registrationAssignment objects, I was trying to use some of the aliases derived from the registrationDefinition which the registrationAssignment was assigning, aliases such as:
registrationAssignment/registrationDefinition.id registrationAssignment/registrationDefinition.name and so on.
It transpires that when you deploy a registrationAssignment via an ARM template, the only definition-related attribute which gets populated on the registrationAssignment object is actually registrationAssignment.registrationDefinitionId. The attributes on the 'embedded' registrationDefinition do not get populated and so the aliases targeting them do not work.
I have not tried every method to create registrationAssignments, it could be under some circumstances, e.g. via the Azure Portal, that these attributes do get filled. However in the scenario where you're using Portal, you're far less likely to be using Policy to deploy Lighthouse delegations in the first place.
I would suggest that someone needs to work out if there are situations where the registrationAssignment/registrationDefinintion.XXX attributes are filled in. If there are scenarios, then the documentation should be updated to reflect when these can be used, and when they are blank. If there are actually no scenarios in which these attributes are filled, then I'd suggest the aliases are removed.