2.4 Role Assignment Interpretation and Deny Effects
Key Takeaways
- Effective Azure access is usually additive across direct, group, and inherited RBAC assignments.
- Deny assignments can block allowed RBAC actions and are often created by Azure managed services or governance features.
- Resource locks and Azure Policy are not RBAC roles, but they can still prevent operations that RBAC would otherwise allow.
- Case-study tables should be read by calculating principal, role, scope, inheritance, and blocking controls.
How To Read An Access Scenario
Role assignment interpretation is a repeatable exercise. Identify the requested operation first, then identify the principal performing it. Next, list every role assignment that applies directly to that principal and through groups. Finally, check whether any blocking control prevents the operation.
A role assignment applies when its scope is the target resource, a parent resource group, the subscription, or a parent management group. Assignments inherit down. Assignments do not inherit upward. Reader on a VM does not let the user read every resource in the resource group. Reader on the resource group normally lets the user read the VM.
| Question clue | What to do |
|---|---|
| User is member of multiple groups | Add applicable permissions from all groups. |
| Assignment is on subscription | Apply it to child resource groups and resources. |
| Assignment is on one resource group | Do not apply it to sibling resource groups. |
| Role is Contributor | Resource changes are allowed, but role assignment is not. |
| Role is Owner | Resource changes and access delegation are allowed unless blocked. |
| Deny assignment exists | Check whether the denied action matches the attempted action. |
| Lock exists | Check whether the operation is delete or write. |
Additive Permissions And Inheritance
Azure RBAC is generally additive. If Mia is Reader at subscription scope and Contributor on rg-dev, she can read the subscription and manage resources in rg-dev. The narrower Contributor assignment does not remove the broader Reader assignment. Likewise, if she gets VM Contributor through one group and Reader through another, both apply where their scopes match.
There is no normal Azure RBAC allow assignment that cancels another allow assignment. To remove access, remove the direct assignment, remove the group assignment, remove the user from the group, narrow the scope, or use a governance control where appropriate. Do not look for a built-in role called No Access in standard RBAC questions.
Deny Assignments
Deny assignments are special access controls that prevent principals from performing specified actions even if RBAC would otherwise allow them. Administrators usually do not create deny assignments directly in routine portal workflows. They are commonly associated with Azure managed applications, blueprints-style governance patterns, deployment stacks or other managed service scenarios where Azure must protect resources from modification.
The exam may not ask you to author a deny assignment, but it can ask you to interpret one. If a principal has Contributor at subscription scope but a deny assignment blocks Microsoft.Compute/virtualMachines/delete on a managed resource group, the delete operation fails. The Contributor role is not broken. A more specific blocking control is taking effect.
| Control | Created as RBAC role? | Typical effect |
|---|---|---|
| RBAC allow assignment | Yes | Grants allowed actions at a scope. |
| Deny assignment | Separate control | Blocks specified actions despite allow assignments. |
| CanNotDelete lock | No | Prevents deletion of protected resources. |
| ReadOnly lock | No | Prevents write and delete operations. |
| Azure Policy deny effect | No | Rejects noncompliant create or update requests. |
Locks And Policy As Blocking Effects
Resource locks are management controls, not identity roles. A CanNotDelete lock prevents deletion by users who otherwise have delete permission. A ReadOnly lock is stronger; it prevents write and delete operations and can affect service operations that require management-plane writes. Locks can be applied at subscription, resource group, or resource scope and inherit downward.
Azure Policy can also block operations. A policy with a deny effect might prevent creating public IP addresses, deploying resources outside allowed regions, or creating storage accounts without required settings. The user may have Contributor, but Resource Manager rejects the request because it violates policy.
Scenario: A user has Owner on a resource group but cannot delete a storage account. A CanNotDelete lock exists on the storage account. The correct explanation is the lock, not missing RBAC. Remove the lock or choose an allowed operation, depending on governance requirements.
Scenario: A user has Contributor on a subscription but cannot create a VM in westus. The policy allows only eastus and centralus. The correct fix is to deploy to an allowed region or change the policy assignment if governance approves. Owner would not solve the policy deny unless the user also has permission to modify the policy assignment and the organization permits that change.
Portal And CLI Decision Logic
Use the portal's Access control (IAM) > Check access to quickly inspect roles for a principal at a resource. Use Locks on the resource, resource group, or subscription to inspect lock inheritance. Use Policy > Compliance and assignment details to understand deny or modify effects.
CLI commands for interpretation:
az role assignment list --assignee <object-id> --all --include-inherited
az lock list --resource-group rg-prod
az policy assignment list --scope /subscriptions/<sub-id>
az policy state list --resource-group rg-prod
When a case study provides tables, write a quick effective-access grid. Columns should be principal, source, role, assignment scope, target scope, inherited yes or no, and blocker. This prevents the common mistake of seeing a broad role and ignoring a lock or policy.
Exam Traps
Trap 1: assuming Owner always wins. Owner is powerful but does not bypass every governance control. Locks, policy deny effects, and deny assignments can stop operations.
Trap 2: confusing read access with data access. Reading the storage account resource does not always mean reading blobs. Reading a Key Vault resource does not automatically mean reading secrets under current RBAC-based access models.
Trap 3: applying child scope upward. Contributor on one resource group does not grant access to another resource group or to subscription-level billing settings.
Trap 4: forgetting group membership. If the user is in a group that has access at a parent scope, the user may have access even when no direct user assignment is listed.
Trap 5: treating policy as after-the-fact reporting only. Audit policies report. Deny policies block requests. Modify and deployIfNotExists can change or remediate configurations depending on policy design.
A user has Contributor on a resource group but cannot delete a VM because a CanNotDelete lock exists on the VM. What explains the failure?
A user has Reader at subscription scope and Contributor on one resource group. What access does the user have?
A policy assignment denies creation of public IP addresses. A user with Owner at resource group scope tries to create one and fails. What should you conclude?