How do Azure RBAC custom role definitions behave with regard to lifecycle, assignable scopes and resource location?

Question

I'm struggling to maintain a coherent mental model of how Azure RBAC custom role definitions are stored in Azure, their lifecycle and their relationship with their assignable scopes.

I created a new custom role called "some-custom-role". I set two assignable scopes, subscription_1 and subscription_2. After creating, I run these commands

az role definition list --name some-custom-role --subscription subscription_2 --query [].id -ot
sv

/subscriptions/subscription_2/providers/Microsoft.Authorization/roleDefinitions/b633f26b-3b4b-42ca-a0ed-501c354e4d23

az role definition list --name some-custom-role --subscription subscription_1 --query [].id -otsv

/subscriptions/subscription_1/providers/Microsoft.Authorization/roleDefinitions/b633f26b-3b4b-42ca-a0ed-501c354e4d23

I'm confused. These are two different resources with different IDs, yet they look eerily similar. Is one of the role definition resources the "primary", while the other one is a copy? Changing one of the resources seem to change the other as well. Will the role definition disappear if I delete one of the subscriptions? If I delete both? If I delete the role definition in one subscription, will it disappear in the other one as well? Is there some object in Entra or elsewhere which represents the source of truth for both of these role definition copies?

Answer 1

I made many experiments while authoring the question, so I figured I might as well share my findings in a Q&A. There are several undocumented properties of Azure RBAC roles I've established

• Two different role definitions can not share the same roleName within a single tenant. If I try to create another role definition anywhere in my tenant which I also call some-custom-role, I will get an error.
• If I create a role definition with two assignable scopes which are two different subscriptions, two new resources which represent the role definition are created in my tenant, one for each subscription. All attributes of the role definition are identical, except for the id property, which is different for each subscription.
• If I create a role definition with two assignable scopes which are resource groups within the same subscription, only one role definition resource is created in my tenant.
• If I delete a resource group which a role definition is assignable to - e.g. I delete one of the resource groups which a role definition is assignable to - then the list of assignable scopes for that role definition is updated to reflect the remaining scopes. The id property of the role definition is unchanged.
• If I delete all the assignable scopes for a role definition, the role definition is deleted.
• If I change any property of a role definition which is assignable to scopes in multiple subscriptions, the change is applied to every copy of the role definition in every subscription.
• If I delete a role definition in one subscription with az resource delete --ids <sub-specific-role-definition-resource-id>, any copies in other subscriptions are also deleted.

Role definitions which are assignable across multiple subscriptions have similarities with databases in a multi-master replication setup. Changes to one copy are spontaneously reflected in other copies.