4.3 Resource Locks and Azure RBAC

4.3 Resource Locks and Azure RBAC

Quick Answer: Apply CanNotDelete locks so resources can be updated but not deleted; apply ReadOnly locks so resources cannot be updated or deleted (similar to forcing Reader-like restrictions on the control plane). Locks inherit downward and require Owner or User Access Administrator (or equivalent locks permissions) to remove. Pair locks with Azure RBAC roles—Owner, Contributor, Reader, User Access Administrator, security roles, and Key Vault roles—assigned at the correct scope. Remember deny assignments can block actions even when a role allows them.

Resource locks

Management locks sit above normal RBAC allow rules for the operations they restrict. Even an Owner cannot delete a resource that has a CanNotDelete lock until the lock is removed (and removing the lock itself requires authorization permissions).

Inheritance and precedence

• Locks on a subscription or resource group apply to resources inside, including resources created later.
• The most restrictive lock in the inheritance chain takes precedence.
• You cannot add locks at management group scope in the portal model described by Microsoft docs—locks are subscription / resource group / resource scoped.
• Attempting to delete a resource group fails entirely if any resource inside is locked against delete—Azure does not partially delete the group.

Control plane vs data plane (critical trap)

Locks protect Azure Resource Manager control-plane operations (management.azure.com). They do not turn a storage account into an immutable data vault by themselves:

• A CanNotDelete lock on a storage account stops deleting the account resource, but blob data can still be deleted via data-plane APIs unless other data protections exist.
• A ReadOnly lock on a storage account can block list keys (a POST control-plane operation) and some management actions, pushing callers toward Microsoft Entra data-plane auth—yet data-plane writes may still occur depending on the API path.
• ReadOnly on a resource group can block VM start/restart (POST actions) and other management operations that look “operational” but are control-plane writes.

Scenario: Finance applies CanNotDelete on the production resource group containing a SQL server. An engineer with Contributor can still scale the database and patch firewall rules, but cannot delete the server or the resource group. Separately, application users continue to run INSERT/DELETE on table data—the lock never intended to freeze SQL row operations.

Who can create or delete locks?

Creating or deleting locks requires Microsoft.Authorization/locks/* (or broader Microsoft.Authorization/*). Built-in roles that include this capability include:

• Owner
• User Access Administrator

Specialized custom roles can grant only lock actions if you want lock operators without full Owner. Contributor cannot manage locks—a classic exam discriminator.

Operational gotchas worth memorizing

• Backup and restore point cleanup can break if a CanNotDelete lock blocks the resource group Azure Backup uses for restore points.
• Managed applications (for example some Databricks patterns) create system-locked managed resource groups you should not fight—delete the service, not the lock, when decommissioning.
• Locks do not block subscription cancellation workflows the way they block resource deletes.

Azure RBAC fundamentals

Azure role-based access control grants allow permissions to security principals (users, groups, service principals, managed identities) at a scope.

Scope hierarchy

Management group
  └── Subscription
        └── Resource group
              └── Resource

Permissions inherit downward. Assign at the highest scope that still meets least privilege. Prefer resource group or resource scope over subscription-wide Owner.

A role assignment has three parts: security principal + role definition + scope. Optional conditions (ABAC) can further constrain assignments (for example, allow blob access only when a certain tag matches).

Built-in roles you must know cold

Key Vault–related roles (control vs data plane)

Key Vault is a favorite exam surface because control-plane roles (who can change vault firewall, diagnostics, locks) differ from data-plane roles (who can get secrets/keys/certificates):

Always confirm whether the vault uses the Azure RBAC permission model or legacy access policies—chapter 3 covered that choice; here the point is that “Contributor on the RG” is not the same as “can read production connection strings.”

Security Admin vs Security Reader

• Security Reader: view recommendations, alerts, security posture.
• Security Admin: also change security policies/configuration in Defender for Cloud–related settings without granting full resource Contributor on every workload.

Neither replaces Owner for deleting production VMs, and neither alone is the universal answer for “who can remove a resource lock.”

Deny assignments (overview)

Deny assignments attach a set of denied actions to principals at a scope. They block operations even if a role assignment would allow them. Key facts for SC-500:

When troubleshooting “I have Owner but still cannot delete,” check locks, deny assignments, and Policy, in that mental order.

Combining locks and RBAC in real designs

1. Production RG: Contributors deploy apps; CanNotDelete on the RG and on shared Key Vault/SQL; Owner only via PIM eligible assignment.
2. Platform subscription: Hub VNet and firewall get CanNotDelete; network admins get Network Contributor at RG, not subscription Owner.
3. Audit: Security Readers view Defender; they do not get Contributor “to make reading easier.”
4. Break glass: Two User Access Administrator / Owner accounts protected with PIM, monitored, not used daily.

Exam traps

• Believing Contributor can remove locks.
• Thinking ReadOnly lock stops SQL row updates or blob data-plane deletes in all cases.
• Confusing User Access Administrator (manage access) with Contributor (manage resources).
• Assigning Owner when Contributor + separate UAA would better separate duties.
• Forgetting lock inheritance when a child resource “mysteriously” cannot be deleted.

Locks stop accidents; RBAC stops unauthorized people; Policy stops bad configurations; deny assignments are the platform’s hard blocks—SC-500 expects you to pick the right layer.