Troubleshooting Lab: Manage Built-in Azure Roles
Diagnostic Scenarios
Scenario 1 — Root Cause
A platform engineer receives complaints that a developer cannot deploy an application via Azure CLI. The developer has portal access and can view all resources in the rg-apps-prod resource group without issues. The subscription was migrated to a new Management Group three days ago as part of an internal reorganization.
When trying to execute the deployment, the developer receives the following error:
$ az webapp deploy --resource-group rg-apps-prod --name app-contoso --src-path ./build.zip
(AuthorizationFailed) The client 'dev@contoso.com' with object id 'a1b2c3...'
does not have authorization to perform action
'Microsoft.Web/sites/write' over scope
'/subscriptions/xxxx/resourceGroups/rg-apps-prod/resources'
or the scope is invalid.
The engineer checks the role assignments and finds the following:
$ az role assignment list --assignee dev@contoso.com --all
[
{
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/xxxx/resourceGroups/rg-apps-prod",
"principalName": "dev@contoso.com"
}
]
The developer reported no issues the day before the migration. The developer's account was created six months ago and has never been disabled.
What is the root cause of the observed problem?
A) The Contributor role does not include the Microsoft.Web/sites/write permission, which requires the Website Contributor role
B) There is a deny assignment applied at the Management Group or subscription scope that blocks the action
C) The developer's session token was invalidated by the Management Group migration and needs to be renewed
D) The Contributor role was assigned at the resource group level, but the deploy action requires assignment at the subscription scope
Scenario 2 — Action Decision
An administrator identified that an automated provisioning process failed because the service principal used by the CI/CD pipeline lost its role assignment after a manual permission cleanup performed by another administrator. The cause is confirmed: the Contributor role that existed in the rg-infra-dev resource group was inadvertently removed.
This is a development environment with no production impact. The pipeline has been stopped for 40 minutes. The administrator has the Owner role on the subscription. The security team requires that any new role assignment in managed environments be registered via ticket in the ITSM system before being applied, but the approval process takes an average of 2 hours.
What is the correct action to take at this moment?
A) Immediately reassign the Contributor role to the service principal in the resource group, since this is a development environment with low impact
B) Escalate to the security team requesting an emergency exception and wait for approval before any action
C) Open the ITSM ticket registering the necessary assignment and wait for the approval process before applying the change
D) Temporarily assign the Owner role to the service principal to restore the pipeline while the ticket is being processed
Scenario 3 — Root Cause
A cloud administrator reports that a user with the User Access Administrator role at subscription scope is able to modify resources directly, creating and deleting storage accounts without any additional roles assigned. The administrator opened a ticket claiming this behavior violates the expected permissions model.
The security team requests urgency in the investigation. The tenant uses Microsoft Entra ID with P2 license. The user in question is a member of three security groups.
The investigation returns the following:
$ az role assignment list --assignee user-ops@contoso.com --all --include-groups
[
{
"roleDefinitionName": "User Access Administrator",
"scope": "/subscriptions/xxxx",
"principalName": "user-ops@contoso.com"
},
{
"roleDefinitionName": "Contributor",
"scope": "/subscriptions/xxxx",
"principalName": "sg-platform-team"
}
]
What is the root cause of the observed behavior?
A) The User Access Administrator role includes write permissions over resources, which explains the ability to create storage accounts
B) The user is receiving the Contributor role through group inheritance, and this assignment was not visible in the initial query without the --include-groups flag
C) The Microsoft Entra ID P2 license automatically activates elevated permissions for users who are members of multiple groups
D) There is a misconfigured custom role overlapping with User Access Administrator that expands the user's permissions
Scenario 4 — Collateral Impact
To resolve a specific access issue, an administrator removes the Owner role from a security group called sg-platform-admins at subscription scope and replaces it with the Contributor role at the same scope. This action resolves the immediate reported problem.
What secondary consequence can this change cause?
A) Group members lose the ability to view resources in the subscription, as Contributor does not include read permissions
B) Group members lose the ability to create new role assignments and apply access policies in the subscription
C) The change automatically invalidates all active session tokens of group members, forcing immediate re-authentication
D) Group members lose access to resources created before the change but maintain access to resources created after the new assignment
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The decisive clue in the scenario is the mention of migration to a new Management Group three days before the problem appeared. This operation is the only event that could have introduced a deny assignment inherited from policies or configurations applied at the Management Group level, blocking specific actions even with the Contributor role correctly assigned at the resource group level.
The az role assignment list command confirms that the Contributor role exists and is in the correct scope. The authorization error, therefore, is not caused by lack of granted permission, but by an explicitly denied permission overlaid. Deny assignments take precedence over any granted role, regardless of scope.
The information about the account being created six months ago and never disabled is irrelevant: the problem is not authentication, but authorization. Alternative C uses this irrelevant information as bait.
Alternative A is factually incorrect: Microsoft.Web/sites/write is included in the Contributor role. Alternative D represents a classic misconception about scope inheritance: assignments in parent scopes propagate to child scopes, not the reverse. The most dangerous distractor is C, as it leads the administrator to restart the user's session without solving anything, wasting time in production.
Answer Key — Scenario 2
Answer: C
The critical constraint in the scenario is the security process that requires registration via ticket before assignment. Even though this is a development environment with low impact, the organizational policy makes no exception based on environment criticality. The correct action is to open the ticket and wait, as acting before registration violates an established governance control.
Alternative A ignores the governance restriction by relying on the low impact justification, which is a common reasoning error: process restrictions exist independently of perceived technical risk. Alternative B represents a valid action in some contexts, but the scenario does not describe an emergency that would justify formal exception, and escalating without opening the ticket also doesn't resolve the mandatory registration. Alternative D is the most dangerous distractor: in addition to violating the process, it also elevates privilege beyond what's necessary, replacing Contributor with Owner without technical justification.
Answer Key — Scenario 3
Answer: B
The decisive clue is in the output of the second command, executed with the --include-groups flag. It reveals that the sg-platform-team group, of which the user is a member, has the Contributor role on the subscription. The initial query, without this flag, returned only direct assignments to the user, hiding permissions inherited via group.
The behavior is completely expected by the Azure RBAC model: permissions are additive and include direct and indirect assignments via groups. The administrator who opened the ticket made the diagnostic error of querying only direct assignments.
The information about the Microsoft Entra ID P2 license is irrelevant for resource control plane permissions: P2 enables features like PIM and Identity Protection, but does not automatically expand role permissions. Alternative C uses this information as a distraction. Alternative A is factually incorrect about the scope of User Access Administrator. Alternative D would be plausible, but the scenario presents no evidence of custom roles, and diagnosis should follow available evidence before speculating.
Answer Key — Scenario 4
Answer: B
The fundamental difference between Owner and Contributor is that Owner includes Microsoft.Authorization/*/write, which allows creating and managing role assignments, and permissions to apply Azure Policy. By replacing Owner with Contributor, all group members immediately lose this capability, which can prevent them from managing future access in the subscription, creating new deny assignments, or delegating permissions to other users and service principals.
Alternative A is incorrect: Contributor includes all Reader permissions as a subset, so reading is not affected. Alternative C is incorrect because changes in role assignments do not invalidate active session tokens: permissions are re-evaluated with each API call, but existing sessions are not forcibly terminated. Alternative D represents confusion between RBAC and resource ownership: Azure RBAC does not link access to when the resource was created; permissions apply uniformly to all resources in scope, regardless of when they were created.
Troubleshooting Tree: Manage Built-in Azure Roles
Color Legend:
| Color | Node Type |
|---|---|
| Dark blue | Initial symptom (entry point) |
| 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 authorization denial symptom. Follow each question answering based on what you can observe directly in the environment: execute the commands indicated in the verification nodes before assuming a cause. Resist the temptation to jump to a cause before going through the diagnostic nodes in sequence, as the most obvious cause is often not the real cause when deny assignments or group inheritance are involved.