This chapter provides a deep dive into deny assignments and resource locks, two critical access control mechanisms in Azure that enforce strict restrictions on resources. For the AZ-104 exam, questions on these topics typically account for 5-10% of the Identity Governance domain (Objective 1.2). Understanding the differences between deny assignments, role-based access control (RBAC) denials, and resource locks is essential for designing secure Azure environments and passing the exam.
Jump to a section
Imagine a corporate building where the CEO (Azure subscription owner) can grant access badges to any employee for any floor. However, the board of directors (Azure Policy or management groups) can issue a 'blacklist' that overrides any badge access: even if an employee has a badge for Floor 5, a blacklist entry for that employee on Floor 5 prevents entry. The blacklist is not a badge itself—it's a rule that cancels out badges. In Azure, deny assignments are like these blacklist entries: they explicitly deny access to specific actions, even if a role assignment (badge) grants that access. They are created by Azure Blueprints or management groups and cannot be removed by subscription owners—only by the entity that created them. Resource locks are like a temporary 'do not enter' sign on a specific door: they apply to all users equally, regardless of their badges, and can be removed by an owner. Deny assignments are permanent until the policy is removed, while locks are manually applied and removed.
What Are Deny Assignments?
Deny assignments are a type of authorization rule that explicitly denies access to a set of actions for a specific scope, regardless of any role assignments that grant access. They are created by Azure Policy, Azure Blueprints, or management groups to enforce compliance and prevent accidental or malicious changes. Unlike RBAC role assignments, which can grant permissions, deny assignments block actions even if the user is an Owner or has a custom role with wildcard permissions.
How Deny Assignments Work Internally
Azure Authorization uses an allow system with an explicit deny override. The process for evaluating access is: 1. Check if there is an explicit deny assignment that matches the action and scope. If yes, deny access. 2. If no explicit deny, check for any role assignments that grant the action. If found, allow. 3. If no explicit deny and no grant, deny by default.
Deny assignments are stored in the Azure Resource Manager (ARM) as a separate resource type: Microsoft.Authorization/denyAssignments. They have a unique ID and are scoped to a management group, subscription, resource group, or resource. Each deny assignment includes:
- DenyAssignmentName: A descriptive name.
- Scope: The Azure resource scope where the deny is effective.
- DenyAssignmentId: A GUID.
- Principals: The users, groups, or service principals to which the deny applies. If empty, it applies to all principals.
- ExcludePrincipals: Principals exempted from the deny.
- DoNotApplyToChildScopes: If true, the deny does not cascade to child resources.
- Permissions.Actions: List of allowed actions that are denied (e.g., Microsoft.Compute/virtualMachines/write).
- Permissions.NotActions: Actions that are explicitly allowed despite the deny.
- Permissions.DataActions: Similar for data plane actions.
- Permissions.NotDataActions: Data actions allowed despite the deny.
Key Components, Values, and Defaults
Deny assignments are inherited by default: a deny at a management group applies to all child subscriptions, resource groups, and resources unless DoNotApplyToChildScopes is set to true.
Deny assignments cannot be modified or deleted by users who do not have Microsoft.Authorization/denyAssignments/write permission, which is typically only given to the creator (e.g., Azure Policy service principal) or a Global Administrator with elevated access.
Maximum number of deny assignments per subscription: 200 (soft limit, can be increased by support).
Deny assignments are not visible in the Azure portal by default. They can be viewed using Azure CLI: az role assignment list --all or PowerShell: Get-AzDenyAssignment.
Built-in deny assignments: Azure Blueprints creates deny assignments to lock down resources created by the blueprint. Azure Policy can create deny assignments via the Deny effect or DenyAction effect.
Configuration and Verification Commands
View deny assignments:
az role assignment list --all --query "[?properties.denyAssignmentName!=null]"Or specifically:
az deny-assignment list --scope /subscriptions/<sub-id>PowerShell:
Get-AzDenyAssignment -Scope /subscriptions/<sub-id>To identify who created a deny assignment, check the CreatedBy property in the JSON output.
Resource Locks: A Different Mechanism
Resource locks are a separate feature that prevents accidental deletion or modification of resources. They are set at a scope (subscription, resource group, or resource) and apply to all users, including Owners. There are two types: - CanNotDelete: Users can read and modify a resource but cannot delete it. - ReadOnly: Users can read a resource but cannot modify or delete it.
Resource locks are implemented as a deny assignment internally? No—they are a separate authorization check that overrides all role assignments. When a lock is applied, Azure Resource Manager checks for the lock before allowing any write or delete operation. If a lock is present, the operation is denied with a specific error code: ScopeLocked.
Interaction with Related Technologies
RBAC vs Deny Assignments: RBAC grants permissions; deny assignments block permissions. Deny assignments always override RBAC grants. For example, a user with Owner role (full access) cannot delete a resource if a deny assignment blocks Microsoft.Compute/virtualMachines/delete.
Azure Policy vs Deny Assignments: Azure Policy can use the Deny effect to prevent resource creation or modification, but that is a policy evaluation during deployment. Deny assignments are persistent and block any attempt to change existing resources. Azure Policy can also create deny assignments via the DenyAction effect (preview) to block actions on existing resources.
Resource Locks vs Deny Assignments: Resource locks are simpler, apply to all users, and are visible in the portal under 'Locks'. Deny assignments are more granular, can target specific principals, and are not visible in the portal by default. Both can coexist; a resource lock adds an additional layer of protection.
Management Groups: Deny assignments can be applied at management group level, affecting all child subscriptions. This is powerful for enforcing organization-wide policies.
Exam Trap: Confusing Deny Assignments with Resource Locks
Common exam scenario: A question describes a situation where a user cannot delete a resource despite being an Owner. The answer might be either a resource lock or a deny assignment. Key differentiator: Resource locks are visible in the portal under 'Locks' and can be removed by an Owner. Deny assignments are not visible there and require specific permissions to remove. Also, resource locks apply to all users equally, while deny assignments can target specific users or groups.
Step-by-Step: Creating a Deny Assignment via Azure Policy
Create a custom policy definition that uses the Deny effect (or DenyAction for existing resources).
Assign the policy at a management group or subscription scope.
Azure Policy automatically creates a deny assignment for the assigned scope. The deny assignment's principals include all users/groups in the scope.
Verify: Use az deny-assignment list to see the new deny assignment.
Test: Attempt an action that the policy denies; it should fail with a 403 Forbidden error.
Resource Lock Creation and Management
Resource locks can be created via portal (under 'Settings' > 'Locks'), Azure CLI, or PowerShell.
az lock create --name MyLock --lock-type CanNotDelete --resource-group MyRGPowerShell:
New-AzResourceLock -LockName MyLock -LockLevel CanNotDelete -ResourceGroupName MyRGTo delete a lock:
az lock delete --name MyLock --resource-group MyRGNote: You need Microsoft.Authorization/locks/write permission, which is included in Owner and User Access Administrator roles.
Edge Cases and Exceptions
Deny assignments created by Azure Blueprints are automatically removed when the blueprint assignment is deleted.
Deny assignments with empty principals apply to all users, including service principals and managed identities.
ExcludePrincipals can be used to exempt certain users (e.g., break-glass accounts) from a deny assignment.
DataActions: Deny assignments can also block data plane operations (e.g., reading blobs in a storage account). This is less common but tested.
Resource locks on management groups: As of now, resource locks cannot be applied to management groups directly; they apply only to subscriptions, resource groups, and resources.
Resource locks vs RBAC: A resource lock does not change your RBAC permissions; it just adds an additional check. You can still see the resource in the portal, but you cannot perform the locked operation.
How to Identify the Source of a Deny
If a user receives a 403 error, check the error message. If it mentions ScopeLocked, it's a resource lock. If it mentions DenyAssignment, it's a deny assignment. You can also use Azure Resource Graph to find deny assignments:
authorizationresources
| where type == "microsoft.authorization/denyassignments"Identify the Need for Restriction
Determine whether you need to prevent deletion or modification of a resource for all users (resource lock) or block specific actions for specific users (deny assignment). For compliance requirements like 'no one can delete a storage account', a resource lock is simpler. For 'only the security team can modify network security groups', a deny assignment targeting other users is more appropriate. Document the scope (subscription, resource group, resource) and the principals involved.
Choose the Correct Mechanism
If you need to protect against accidental deletion, use a CanNotDelete resource lock. If you need to prevent any changes, use a ReadOnly lock. If you need to block specific actions (e.g., write operations) for a subset of users while allowing others, use a deny assignment via Azure Policy or Blueprints. Remember that resource locks apply to all users equally, while deny assignments can be granular.
Create the Resource Lock
Navigate to the resource in Azure portal, go to 'Settings' > 'Locks', and add a lock with a name and type (CanNotDelete or ReadOnly). Alternatively, use Azure CLI: `az lock create --name LockName --lock-type CanNotDelete --resource-group RGName`. The lock is applied immediately. Verify by attempting to delete the resource; you should receive a 403 error with 'ScopeLocked'.
Create the Deny Assignment via Policy
Define an Azure Policy with the `Deny` or `DenyAction` effect. For example, to deny deletion of virtual machines, create a policy that denies `Microsoft.Compute/virtualMachines/delete`. Assign the policy at the desired scope. Azure Policy automatically generates a deny assignment. Confirm by listing deny assignments: `az deny-assignment list --scope /subscriptions/...`.
Test and Validate Restrictions
Attempt the blocked action with a test user account that has Owner permissions. For resource locks, expect a 'ScopeLocked' error. For deny assignments, expect a 'DenyAssignment' error. Use Azure Monitor logs to audit the attempts. If the restriction is too broad, adjust the policy or lock scope. For deny assignments, you can use ExcludePrincipals to allow break-glass accounts.
Enterprise Scenario 1: Compliance Enforcement with Deny Assignments
A multinational corporation must ensure that no production resource can be modified outside of approved change windows. They use Azure Blueprints to deploy a standard set of resources with a deny assignment that blocks write operations for all users except a specific security group. The blueprint creates the deny assignment at the resource group level. The security group is granted Microsoft.Authorization/denyAssignments/write permission to modify the assignment if needed. Common mistake: The deny assignment accidentally blocks critical updates, causing outages. The solution is to carefully define the NotActions list to allow necessary operations (e.g., read, list).
Enterprise Scenario 2: Protecting Critical Resources with Resource Locks
A financial services company has a storage account containing audit logs. They apply a ReadOnly resource lock to prevent any modification or deletion. Even the subscription Owner cannot delete the storage account without first removing the lock. This ensures compliance with regulatory requirements for data retention. Misconfiguration: Applying a CanNotDelete lock instead of ReadOnly allows modifications, which could compromise data integrity. The company uses Azure Policy to enforce that all storage accounts containing logs must have a ReadOnly lock, automatically remediating if missing.
Enterprise Scenario 3: Combining Locks and Deny Assignments
A healthcare organization uses both mechanisms: resource locks on critical databases to prevent accidental deletion, and deny assignments to block non-admin users from changing firewall rules. The deny assignment is applied at the management group level, affecting all subscriptions. Resource locks are applied per resource. A break-glass procedure allows Global Administrators to temporarily remove a lock if needed, but deny assignments require policy exemption. Performance: deny assignments are evaluated in real-time during authorization, adding minimal latency. Scale: With hundreds of deny assignments, the authorization system remains efficient due to indexing.
What AZ-104 Tests (Objective 1.2)
The exam focuses on:
Differentiating between resource locks and deny assignments.
Understanding when to use each.
Knowing the types of resource locks (CanNotDelete, ReadOnly).
Recognizing that deny assignments are created by Azure Policy and Blueprints.
Understanding that resource locks apply to all users, while deny assignments can target specific principals.
Knowing how to view deny assignments (CLI/PowerShell, not portal).
Common Wrong Answers and Why
'A resource lock prevents all modifications.' Wrong: ReadOnly prevents modifications, but CanNotDelete allows modifications. Candidates often confuse the two.
'Deny assignments are visible in the portal under Access control (IAM).' Wrong: They are not visible there; they require CLI or PowerShell to view.
'Resource locks override RBAC but deny assignments do not.' Wrong: Both override RBAC, but resource locks are simpler and apply to all users.
'You can remove a deny assignment if you are an Owner.' Wrong: Only the creator (e.g., Azure Policy) or users with Microsoft.Authorization/denyAssignments/write can delete them.
Specific Numbers and Terms
Lock types: CanNotDelete, ReadOnly.
Deny assignment limit: 200 per subscription.
Error codes: ScopeLocked for locks, DenyAssignment for deny assignments.
Commands: az lock create, az deny-assignment list.
Built-in roles with lock write: Owner, User Access Administrator.
Edge Cases and Exceptions
Resource locks do not prevent changes to the lock itself if you have permission.
Deny assignments can have DataActions to block data plane operations.
If a resource lock and a deny assignment both block an action, the action is blocked.
Azure Blueprints automatically create deny assignments; deleting the blueprint removes them.
How to Eliminate Wrong Answers
If the scenario mentions 'all users' or 'everyone', it's likely a resource lock.
If the scenario mentions 'specific users' or 'compliance policy', it's a deny assignment.
If the question says 'visible in the portal', it's not a deny assignment.
If the question says 'can be removed by an Owner', it's a resource lock.
Resource locks prevent accidental deletion or modification and apply to all users equally.
Deny assignments explicitly block actions and can target specific principals, overriding any RBAC grants.
Resource locks are visible in the portal under 'Locks'; deny assignments are not visible there.
Deny assignments are created by Azure Policy (DenyAction effect) or Azure Blueprints.
Use `az deny-assignment list` or `Get-AzDenyAssignment` to view deny assignments.
Resource locks have two types: CanNotDelete (allows modifications) and ReadOnly (prevents modifications).
A subscription Owner can delete a resource lock but cannot delete a deny assignment without additional permissions.
Maximum of 200 deny assignments per subscription.
These come up on the exam all the time. Here's how to tell them apart.
Resource Locks
Applies to all users equally (including Owners).
Two types: CanNotDelete and ReadOnly.
Visible in Azure portal under 'Locks'.
Created manually or via Azure Policy (deployIfNotExists).
Can be deleted by an Owner or User Access Administrator.
Deny Assignments
Can target specific users, groups, or service principals.
Blocks specific actions (e.g., write, delete) defined in the assignment.
Not visible in the portal; viewed via CLI/PowerShell.
Created automatically by Azure Policy (DenyAction effect) or Azure Blueprints.
Cannot be deleted by subscription Owner; requires special permissions.
Mistake
Resource locks prevent all modifications to a resource.
Correct
Only ReadOnly locks prevent modifications. CanNotDelete locks allow modifications but prevent deletion.
Mistake
Deny assignments can be viewed and managed in the Azure portal under Access control (IAM).
Correct
Deny assignments are not visible in the portal by default. They must be viewed via Azure CLI, PowerShell, or Azure Resource Graph.
Mistake
A subscription Owner can always delete a resource lock.
Correct
Yes, an Owner can delete a resource lock because they have `Microsoft.Authorization/locks/write` permission. However, they cannot delete a deny assignment unless they have `Microsoft.Authorization/denyAssignments/write`.
Mistake
Deny assignments and resource locks are the same thing.
Correct
They are different. Resource locks are a simple protection applied manually or via policy, visible in the portal, and apply to all users. Deny assignments are more complex, created by Azure Policy or Blueprints, not visible in the portal, and can target specific principals.
Mistake
Azure Policy deny effect creates a deny assignment that blocks only resource creation.
Correct
The `Deny` effect blocks creation or modification of resources during deployment, but it does not create a persistent deny assignment for existing resources. The `DenyAction` effect (preview) creates a deny assignment that blocks actions on existing resources.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A resource lock is a simple setting that prevents all users (including Owners) from deleting (CanNotDelete) or modifying (ReadOnly) a resource. It is visible in the portal and can be removed by an Owner. A deny assignment is a more granular authorization rule that blocks specific actions for specific users, overriding any role assignments. It is created by Azure Policy or Blueprints, not visible in the portal, and cannot be removed by a subscription Owner without special permissions.
Deny assignments are not visible in the Azure portal. Use Azure CLI: `az deny-assignment list --scope /subscriptions/<sub-id>` or PowerShell: `Get-AzDenyAssignment -Scope /subscriptions/<sub-id>`. You can also query Azure Resource Graph: `authorizationresources | where type == 'microsoft.authorization/denyassignments'`.
Both resource locks and deny assignments block actions. If both are present, the action is blocked. They are independent; a deny assignment does not override a resource lock, and vice versa. The most restrictive applies.
Only users or service principals with `Microsoft.Authorization/denyAssignments/write` permission can delete a deny assignment. This is typically the creator (e.g., Azure Policy service principal) or a Global Administrator with elevated access. Subscription Owners do not have this permission by default.
The 'Deny' effect blocks resource creation or modification during deployment (e.g., preventing creation of a VM in a specific region). The 'DenyAction' effect (preview) creates a deny assignment that blocks actions on existing resources (e.g., preventing deletion of all VMs). 'Deny' does not create a persistent deny assignment; 'DenyAction' does.
No, resource locks cannot be applied directly to management groups. They can be applied only to subscriptions, resource groups, and individual resources. To enforce restrictions at the management group level, use Azure Policy or deny assignments.
The error message includes 'ScopeLocked' and indicates that the operation is not allowed due to a resource lock. For example: 'The scope '/subscriptions/.../resourceGroups/.../providers/...' is locked and cannot be modified or deleted.'
You've just covered Deny Assignments and Resource Locks Deep Dive — now see how well it sticks with free AZ-104 practice questions. Full explanations included, no account needed.
Done with this chapter?