Troubleshooting Lab: Assign roles at different scopes
Diagnostic Scenarios
Scenario 1 — Root Cause
The operations team reports that user marcos@contoso.com can list and view all resources within the resource group rg-app-prd, but cannot create or modify any resources in that group. The responsible administrator claims to have assigned the Contributor role to this user directly on rg-app-prd two days ago.
Upon investigation, the administrator runs the following command and gets the output below:
az role assignment list --assignee "marcos@contoso.com" --all --output table
PrincipalName RoleDefinitionName Scope
-------------------- -------------------- -----------------------------------------------
marcos@contoso.com Reader /subscriptions/aaaa-1111-bbbb-2222
marcos@contoso.com Contributor /subscriptions/aaaa-1111-bbbb-2222/resourceGroups/rg-app-prd
The administrator also verifies that rg-app-prd was created three weeks ago, that the subscription is active, and that the environment's monthly cost has recently increased due to the addition of new resources.
When trying to create a virtual machine, marcos@contoso.com receives the following message:
The client 'marcos@contoso.com' with object id 'xxxx' does not have authorization
to perform action 'Microsoft.Compute/virtualMachines/write' over scope
'/subscriptions/aaaa-1111-bbbb-2222/resourceGroups/rg-app-prd'
or the scope is invalid.
What is the root cause of the inability to create resources in rg-app-prd?
A) The Contributor role was assigned correctly, but the recent cost increase activated an automatic lock on the subscription.
B) There is a resource lock of type ReadOnly applied on rg-app-prd or at an ancestor scope, which prevents write operations regardless of RBAC roles.
C) The Reader role assigned at the subscription overrides the Contributor role assigned at the resource group, since assignments at higher scopes take precedence.
D) The error message indicates that the resource group scope was invalidated after recreating the group with the same name.
Scenario 2 — Action Decision
The security team identified that a service principal called sp-deploy-automacao has the Owner role assigned at the Sub-Producao subscription. The cause is identified: the previous automation lead assigned Owner instead of Contributor by mistake, and the service principal never needed to manage other users' permissions.
The environment is production with dozens of active pipelines that use this service principal for resource deployment. Changing credentials or the service principal identity would require updating all pipelines, which is out of scope approved for this week. The security team requires that the privilege escalation be eliminated today.
What is the correct action to take at this moment?
A) Remove the Owner assignment and assign Contributor at the same subscription scope, without changing credentials or the service principal identity.
B) Remove the Owner assignment and not assign any other role until pipelines are audited and minimum necessary scopes are mapped.
C) Keep the Owner assignment and create a deny assignment to specifically block the Microsoft.Authorization/roleAssignments/write action.
D) Replace the service principal with a new one with Contributor assigned and update the pipelines on an urgent basis.
Scenario 3 — Root Cause
A developer reports that julia@contoso.com cannot access any resources from the Sub-Dev subscription, even though she received the Contributor role at the MG-Desenvolvimento management group, which contains that subscription.
The administrator verifies the assignments with the following command:
az role assignment list \
--assignee "julia@contoso.com" \
--scope "/providers/Microsoft.Management/managementGroups/MG-Desenvolvimento" \
--output table
PrincipalName RoleDefinitionName Scope
------------------- -------------------- -------------------------------------------------------
julia@contoso.com Contributor /providers/Microsoft.Management/managementGroups/MG-Desenvolvimento
The administrator also confirms that Sub-Dev is listed as a child of MG-Desenvolvimento in the portal, that the subscription was moved to this management group 72 hours ago, and that julia@contoso.com has an active Microsoft 365 license.
When trying to access any resource from Sub-Dev through the portal, julia@contoso.com receives the message:
You don't have access to this subscription.
Contact your administrator.
What is the root cause of the problem?
A) The Microsoft 365 license of julia@contoso.com is preventing access to the Azure portal, as this type of license does not include Azure access by default.
B) Permission propagation after moving a subscription to a management group can take up to 24 hours, and since the move occurred 72 hours ago, the cause must be different: the MG-Desenvolvimento management group is not correctly associated with the tenant.
C) The role assignment was made in the correct management group, but permission inheritance for newly associated subscriptions can take up to 30 minutes to propagate; since the move occurred 72 hours ago, this timeframe would have already expired, indicating that the subscription may not be effectively under MG-Desenvolvimento in the control plane, despite the visual display in the portal.
D) The scope type used in the az role assignment list command is incorrect for management groups, which makes the command return invalid data; the actual assignment may not exist.
Scenario 4 — Diagnostic Sequence
An administrator receives a report that pedro@contoso.com cannot delete a resource group called rg-legado within the Sub-Corp subscription, despite having the Contributor role assigned at that subscription.
The available investigation steps are:
P1. Verify if there is any resource lock of type CanNotDelete applied to rg-legado or to the Sub-Corp subscription.
P2. Verify if pedro@contoso.com has any explicit deny assignment that covers the Microsoft.Resources/subscriptions/resourcegroups/delete action.
P3. Confirm that the Contributor role is effectively assigned to pedro@contoso.com at the Sub-Corp subscription and that the scope is correct.
P4. Try to perform the deletion using an account with Owner to determine if the problem is permission-related or resource blocking.
P5. Verify if there are resources within rg-legado that have individual locks that prevent the deletion of the group.
What is the correct investigation sequence?
A) P3 → P2 → P1 → P5 → P4
B) P1 → P3 → P2 → P4 → P5
C) P4 → P1 → P3 → P2 → P5
D) P3 → P1 → P5 → P2 → P4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The output of the az role assignment list command confirms that the Contributor role is correctly assigned at rg-app-prd. This eliminates any hypothesis of missing or incorrect assignment. The observed behavior, reading working and writing blocked, is exactly the pattern caused by a resource lock of type ReadOnly. This type of lock allows GET operations but blocks PUT, POST, PATCH and DELETE, operating in a separate layer from RBAC and overriding it.
The information about the cost increase is deliberately irrelevant and has no relationship with access blocks. It was included to induce reasoning toward alternative A, which describes non-existent behavior in Azure.
Alternative C represents the most dangerous diagnostic error in this scenario: confusing the additive RBAC model with a hierarchical precedence model. Azure RBAC does not override more permissive roles with less permissive roles; it combines them. If alternative C were true, it would be impossible to restrict permissions at lower scopes for users with broad roles at higher scopes, which contradicts the very design of RBAC.
Acting based on alternative C would lead the administrator to remove valid assignments without solving the real problem, keeping the resource lock intact and the user blocked.
Answer Key — Scenario 2
Answer: A
The problem is identified and specific: the service principal has Owner when it needed Contributor. The critical constraint of the scenario is that the identity cannot be replaced and pipelines cannot be changed this week. The correct action is to remove the excessive assignment and replace it with the appropriate role at the same scope, without any identity or credential changes.
Alternative B would be technically correct in a deep review scenario, but ignores the explicit constraint that the privilege escalation needs to be eliminated today. Leaving the service principal without any role would interrupt all production pipelines immediately.
Alternative C represents a technically interesting approach, but deny assignments in Azure cannot be created directly by administrators via standard RBAC; they are managed by specific blueprints and policies. Even if it were possible, maintaining Owner and trying to block specific actions is a fragile approach that does not cleanly eliminate excessive privilege.
Alternative D solves the problem structurally, but violates the approved scope constraint for the week, making it incorrect given the presented context.
Answer Key — Scenario 3
Answer: D
The central clue is in the format of the --scope parameter used in the command. The correct value to reference a management group in Azure CLI is:
/providers/Microsoft.Management/managementGroups/{groupId}
This format is correct in the presented output, and the assignment appears listed. However, the question describes access denied behavior after 72 hours, well beyond any propagation window. This points to a structural problem, not latency.
Alternative C is partially correct in mentioning that 72 hours would already exceed any propagation window, but erroneously concludes that the subscription is not in the control plane. The portal verification confirms that the subscription is visually associated with the management group. The real point is that the visual display in the portal may not immediately reflect the effective state of the control plane after a move, and the role assignment, although appearing in the command, may be referencing a management group whose link with the subscription has not yet been completely processed in the authorization plane.
The information about the Microsoft 365 license is deliberately irrelevant. Microsoft 365 licenses do not interfere with Azure portal access or RBAC permissions.
Answer Key — Scenario 4
Answer: A
The correct diagnostic sequence is P3 → P2 → P1 → P5 → P4, and it follows the principle of validating first what you know before investigating what you suspect.
P3 first: before investigating blocks, it's necessary to confirm that the role assignment that should work actually exists and is in the correct scope. A diagnosis that skips this step may waste time investigating blocks when the cause is simply a missing assignment or wrong scope.
P2 second: deny assignments take precedence over any RBAC role and are invisible in the default role assignment listing. Checking this before investigating resource locks avoids the error of concluding that "permissions are correct" without considering explicit denials.
P1 third: check resource locks on the resource group and subscription, as a CanNotDelete would block deletion regardless of the RBAC permissions confirmed in the previous steps.
P5 fourth: check locks on individual resources within the group, which would also prevent deletion of the parent group.
P4 last: using an account with Owner to isolate whether the problem is permission-related or structural blocking is a valid validation technique, but destructive as a diagnosis if executed before understanding the environment state. It should be the last confirmation resort, not the starting point.
Troubleshooting Tree: Assign roles at different scopes
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| Medium blue | Diagnostic question |
| Red | Identified cause |
| Green | Recommended action or resolution |
| Orange | Intermediate verification or validation |
To use this tree when facing a real problem, start with the root node describing the symptom: a principal without access it should have. Follow through the first diagnostic question and answer based on what you can directly observe, using the commands indicated in the verification nodes. Each branch progressively leads you from a verifiable question to the specific cause and, from there, to the correct action. Don't advance to investigate blocks or deny assignments before confirming that the role assignment exists; validating the simplest first is the principle that organizes the entire tree.