Troubleshooting Lab: Interpret Access Assignments
Diagnostic Scenarios
Scenario 1 — Root Cause
The operations team reports that user Beatriz cannot start virtual machines in the rg-operacoes resource group. The administrator checks the portal and confirms that Beatriz has the Virtual Machine Contributor role assigned directly to the rg-operacoes resource group. The subscription was created three months ago and is active. Beatriz can view resources without issues and reports that the VM start option appears in the interface, but returns an authorization error when confirmed.
The administrator also notes that Beatriz is part of the Equipe-Dev group, which has the Reader role assigned at the subscription level. Beatriz's account was created in Microsoft Entra ID two weeks ago and she has already accessed other resource groups without problems.
When trying to start a VM manually via CLI, the following error is returned:
(AuthorizationFailed) The client 'beatriz@contoso.com' with object id '...'
does not have authorization to perform action
'Microsoft.Compute/virtualMachines/start/action'
over scope '/subscriptions/.../resourceGroups/rg-operacoes/providers/
Microsoft.Compute/virtualMachines/vm-prod-01'
or the scope is invalid.
What is the root cause of the problem?
A) The Reader role inherited from the subscription via the Equipe-Dev group is overriding Beatriz's Virtual Machine Contributor role
B) There is a deny assignment applied to the vm-prod-01 resource or to the rg-operacoes resource group that explicitly blocks the VM start action
C) Beatriz's account is too recent and Microsoft Entra ID has not yet propagated the permissions to the Azure control plane
D) The Virtual Machine Contributor role does not include the Microsoft.Compute/virtualMachines/start/action action by definition
Scenario 2 — Action Decision
The administrator identified that a security group called Equipe-Auditoria has the Owner role assigned at subscription scope. This assignment was made by mistake six days ago and needs to be removed. The subscription is in active production with dozens of critical resources. The security team confirmed that no group member has used Owner permissions since the incorrect assignment, and this was validated in Microsoft Entra ID logs.
The removal needs to be done now, during business hours, without a scheduled maintenance window. The administrator has the User Access Administrator role on the subscription. There are no deny assignments protecting the resources.
What is the correct action to take at this moment?
A) Wait for a maintenance window to remove the assignment, as RBAC changes in production can cause interruption to running services
B) Immediately remove the Owner role assignment from the Equipe-Auditoria group at subscription scope using the portal or CLI, without needing a maintenance window
C) Before removing, apply a deny assignment covering all actions for the Equipe-Auditoria group to immediately block access, then schedule the Owner assignment removal
D) Downgrade the group's role from Owner to Reader as a provisional measure and schedule complete removal for outside business hours
Scenario 3 — Root Cause
Developer Carlos reports that he cannot upload blobs to a Storage Account called stgprojeto01. The administrator checks the Storage Account's Access Control (IAM) panel and finds the following state:
| Principal | Type | Role | Scope |
|---|---|---|---|
| Carlos | User | Storage Blob Data Contributor | stgprojeto01 |
| Equipe-Dev | Group | Reader | Subscription |
Carlos is a member of the Equipe-Dev group. The Storage Account uses LRS redundancy and is in the East US region. The storage account has the firewall configured to allow access only from specific virtual networks, but Carlos confirms he is operating from a VM connected to one of these authorized networks. The network team confirmed there are no NSGs blocking port 443.
Carlos tries via CLI and receives:
ERROR: This request is not authorized to perform this operation using
this permission.
RequestId: a3f1...
Time: 2025-10-14T10:23:45.0000000Z
What is the root cause of the problem?
A) The Reader role of the Equipe-Dev group at subscription scope is preventing writes, as group assignments take precedence over individual assignments
B) The Storage Account's LRS redundancy prevents write operations originating from outside the primary region
C) Access to the Storage Account data plane is being blocked by the storage account firewall, as Carlos's VM does not belong to one of the authorized virtual networks
D) The Storage Blob Data Contributor role was assigned at resource scope, but Carlos's authentication token is being issued for subscription scope, causing scope incompatibility in data plane authorization
Scenario 4 — Diagnostic Sequence
An administrator receives the following report: "I can't delete a resource in the Azure portal. I'm sure I have permission to do so."
The available investigation steps are listed below in random order:
- Verify if there is a deny assignment applied to the resource, resource group, or subscription that covers the delete action
- Confirm which role is assigned to the user and at which scope, using the IAM panel or
az role assignment list - Verify if the resource has a lock of type
CanNotDeleteorReadOnlyapplied - Reproduce the error and collect the exact message returned by the portal or CLI
- Verify if the assigned role includes the specific delete action for the resource type
What is the correct investigation sequence?
A) 2, 5, 1, 3, 4
B) 4, 2, 5, 3, 1
C) 3, 1, 2, 5, 4
D) 1, 3, 2, 5, 4
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The error message returned by the CLI clearly indicates that the principal does not have authorization to execute the action, even with the Virtual Machine Contributor role assigned. The decisive point is that Azure RBAC is additive: the Reader role from the Equipe-Dev group could never block permissions granted by another assignment. This directly eliminates alternative A, which represents the most common misconception of supposing that less permissive roles "win" over more permissive roles.
The clue that confirms alternative B is precisely the contradiction between the valid assignment and the persistent authorization error: when a user has a role that clearly covers the requested action and still receives denial, the only possible explanation within Azure's RBAC model is the existence of an active deny assignment, which has absolute precedence over any role assignment.
The information about the account being created two weeks ago is intentionally irrelevant. Permission propagation in Microsoft Entra ID and Azure RBAC occurs in seconds to a few minutes, not weeks, and the scenario itself confirms that Beatriz already accesses other resources normally.
Alternative D is factually incorrect: start/action is included in the Virtual Machine Contributor role definition. The most dangerous distractor is A, as it leads the administrator to try solving a non-existent problem (conflict between additive roles) while the deny assignment remains active blocking access.
Answer Key — Scenario 2
Answer: B
The cause is already stated in the scenario: Owner assignment by mistake. The context provides all necessary information for the decision. RBAC assignment removals do not affect running resources, as RBAC controls the control plane, not the data plane or operational state of VMs, databases, or other services. Therefore, there is no technical justification to wait for a maintenance window, which eliminates alternative A.
The administrator has User Access Administrator, which includes the Microsoft.Authorization/roleAssignments/delete permission, sufficient to execute the removal without escalation. The action should be taken immediately to end the risk exposure.
Alternative C represents a technically valid action in other contexts, but unnecessarily complex here: creating a deny assignment to temporarily cover an Owner introduces an additional object that will need to be removed later, increasing operational risk without any benefit given that direct removal is safe and immediate.
Alternative D is the most dangerous: downgrading to Reader still keeps the group with legitimate access to all subscription resources, which may not be acceptable from a security perspective, and delays complete resolution unnecessarily.
Answer Key — Scenario 3
Answer: C
Carlos has Storage Blob Data Contributor assigned directly to the Storage Account, which would be sufficient for data plane write operations. RBAC's additive model ensures that the Reader role from the Equipe-Dev group does not interfere. This eliminates alternative A by the same principle as the previous scenario.
The critical clue is in the scenario: the Storage Account firewall is configured to allow access only from specific virtual networks. The returned error message (This request is not authorized to perform this operation using this permission) is the standard Azure Storage message when a request is blocked by the storage account's network firewall, not an RBAC message. RBAC errors return AuthorizationFailed with explicit mention of the principal and action, as seen in Scenario 1.
The information about LRS redundancy and the network team's confirmation about NSG are intentionally irrelevant. LRS has no relation to write authorization, and the absence of NSG blocking on port 443 does not guarantee that the VM is in the list of networks authorized in the Storage Account's own firewall, which is an independent control.
Alternative D describes behavior that does not exist in Azure: the RBAC assignment scope does not affect the issuance or validity of the authentication token for the Storage data plane.
Answer Key — Scenario 4
Answer: B
The correct sequence is 4, 2, 5, 3, 1, and the logic is progressive diagnosis from simplest to most specific.
The first step is always reproduce and collect the exact message (step 4), as it can already reveal whether the blocking is from RBAC, lock, or deny assignment, directing the entire rest of the investigation.
Next, confirm role assignment and scope (step 2) validates whether the user actually has any role that should cover the action. Only after this does it make sense to verify if the role includes the delete action for the specific resource type (step 5), as roles like Contributor do not cover all resource types uniformly.
Step 3 (check locks) comes before step 1 (deny assignments) because locks are much more common in production environments and are quickly verifiable in the portal, while deny assignments are less frequent and require query via CLI or specific APIs.
The sequence in alternative A starts with assignment before collecting the error, which is inefficient. Alternative C starts with locks, which is a specific hypothesis without initial evidence. Alternative D starts with deny assignments, which are the least common and most expensive mechanism to verify, inverting the logic of elimination by probability.
Troubleshooting Tree: Interpret Access Assignments
Color legend:
- Dark blue: initial symptom, investigation entry point
- Medium blue: diagnostic question, decision node
- Red: identified cause
- Green: recommended action or resolution
- Orange: intermediate validation or ambiguous result requiring expectation review
To use this tree when facing a real problem, start at the root node and answer each question based on what you observe in the environment, not what you assume. The first most important bifurcation is reading the error message: it already separates RBAC authorization problems from network or data plane problems, saving an entire unnecessary line of investigation. Follow the paths until you reach an identified cause and only then execute the corresponding action.