Hotspot Question You have a management group named MG1 that contains an Azure subscription and a resource group named RG1. RG1 contains a virtual machine named VM1. You have the custom Azure roles…

This question tests understanding of Azure RBAC custom role assignments, scope inheritance, and how multiple role assignments combine (additive permissions) for users at different scopes (management group, subscription, resource group).

Submitted by satoshi_tk· Mar 6, 2026Secure identity and access

Question

Hotspot Question You have a management group named MG1 that contains an Azure subscription and a resource group named RG1. RG1 contains a virtual machine named VM1. You have the custom Azure roles shown in the following table. The permissions for Role1 are shown in the following role definition file. The permissions for Role2 are shown in the following role definition file. You assign the roles to the users shown in the following table. For each of the following statements, select Yes if the statement is true. Otherwise, select No. NOTE: Each correct selection is worth one point. Answer:

Exhibits

Answer Area

User1 can delete VM1.
User2 can delete VM1.
User3 can delete VM1.

Explanation

Approach. In Azure RBAC, permissions are additive - if a user has multiple role assignments, they accumulate all allowed actions across those assignments. Scope inheritance means a role assigned at a management group level applies down to all subscriptions and resource groups within it. Role definitions with 'notActions' restrict specific operations even if 'actions' grants broad permissions. To evaluate each statement, you must determine: (1) what scopes each user's roles apply to, (2) what combined actions are permitted or excluded via notActions, and (3) whether the specific operation in the statement falls within the effective permissions at the relevant scope. For example, if Role1 grants 'Microsoft.Compute/*/read' but has a notAction for 'Microsoft.Compute/virtualMachines/write', a user with only Role1 cannot create or modify VMs. If a user has Role2 assigned at the management group scope, they inherit those permissions down to RG1 and VM1 unless explicitly denied. Always check both the assignableScopes and the actions/notActions arrays in the role definition files to determine the effective permission at the target resource.

Concept tested. Azure RBAC custom roles: scope inheritance (management group → subscription → resource group → resource), additive permissions from multiple role assignments, and the effect of 'notActions' in restricting operations within broader 'actions' grants.

Reference. https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles

Topics

#Azure RBAC#Custom roles#Management groups#Permission inheritance

Community Discussion

No community discussion yet for this question.

Full AZ-500 Practice