Azure Policy, Azure role-based access control, and resource locks are all governance controls, but they answer different questions.

Azure RBAC decides who can perform an action.

Azure Policy evaluates whether resource state complies with organizational rules.

Resource locks protect resources from accidental deletion or modification even when the user otherwise has permission.

Azure RBAC, Azure Policy and resource locks can all affect the same resource but answer different operational questions. Test them separately: a Contributor may have an allowed management action, a policy may deny a configuration that fails the required location or tagging rule, and a CanNotDelete lock may block an otherwise authorized removal. A useful incident record identifies the caller, scope, operation, policy assignment and lock before proposing a fix. When reviewing independent AZ-104 governance practice questions, reject an explanation that recommends granting Owner merely to bypass a denial; first determine which control caused it and whether changing that control would create a wider risk. Microsoft’s official study guide defines the examined governance objectives; a commercial question product is not the issuer’s exam registration.

RBAC controls who can do what

Azure RBAC assigns permissions to security principals at a scope.

A principal can be:

• a user
• a group
• a service principal
• a managed identity

A role definition contains allowed actions, and the assignment attaches that role to the principal at a management group, subscription, resource group, resource, or other supported scope.

This makes RBAC the correct control when the requirement depends on who is making the request.

For example:

• Developers can restart VMs but not change networking.
• A managed identity can read blobs from one storage account.
• An operations group can manage resources in a specific resource group.
• Auditors can read configuration but not change it.

The fundamental RBAC question is identity plus permission.

RBAC evaluation depends on the identity, the role definition, and the scope of the role assignment. A Contributor at a resource group can create and change many resources there but cannot automatically manage access assignments. A role assigned at subscription scope is inherited by child resource groups and resources unless another mechanism, such as a deny assignment, prevents an action.

This is why a permissions problem should be tested with the exact identity and operation. Being an Owner on one resource does not imply permission at a sibling resource, and being able to edit a resource does not prove the identity can assign roles. Azure Activity Log and the access-control view help identify which principal and role assignment were involved.

Azure Policy controls what resource state is allowed

Azure Policy evaluates Azure resource properties against policy rules.

Microsoft explicitly distinguishes Policy from RBAC: RBAC focuses on user actions, while Policy evaluates whether the resulting resource state complies with business rules.

A user can have permission to create a resource and still have the request denied by Policy because the requested configuration is noncompliant.

Examples include:

• requiring specific tags
• allowing only approved regions
• denying public IP configurations in selected scopes
• requiring diagnostic settings
• enforcing allowed SKUs
• auditing encryption configuration

Policy can therefore act regardless of which authorized user created the resource.

The rule is about the resource, not the person.

Azure Policy evaluates resource state represented through Azure Resource Manager. An assignment can audit noncompliance, deny a noncompliant deployment, or use supported modify and deployIfNotExists effects with the necessary identity and permissions. Policy also has a separate denyAction effect, which Microsoft currently documents for blocking DELETE operations under policy conditions. This action-level effect does not confer or replace an Azure RBAC permission, and it should not be confused with a management lock.

Compliance and enforcement should therefore be separated. An audit result tells the administrator that a resource violates a rule; it does not repair the resource. Remediation tasks are used with supported policy effects to bring existing resources toward the desired state. Exemptions can deliberately exclude a scope while preserving the policy assignment and documenting why the exception exists.

Policy effects determine how Azure reacts

Azure Policy can evaluate, audit, modify, deploy related configuration, or deny depending on the policy effect.

A policy using an audit-style effect can report noncompliance without blocking creation.

A deny effect can prevent creation or update of a resource that violates the rule.

Modify and deployment effects can help remediate or add configuration in supported scenarios.

The design should therefore start with the desired governance outcome:

• visibility only
• prevention
• automatic remediation
• configuration deployment

A deny policy is powerful but can disrupt legitimate deployment pipelines if it is introduced without testing.

Policy and RBAC can both allow a request while a resource lock blocks the management operation. Microsoft documents locks as overriding user permissions for the protected control-plane action. A CanNotDelete lock permits authorized modifications but blocks deletion, while ReadOnly blocks both updates and deletions through the management plane.

That makes locks intentionally blunt. They are useful for protecting critical resources from accidental administrative changes, but they do not express nuanced identity-based permissions. The same lock affects an Owner and a Contributor because it applies to the resource scope rather than to one user’s role.

Resource locks protect control-plane operations

Azure resource locks are different again.

Microsoft supports:

• CanNotDelete / Delete lock
• ReadOnly / Read-only lock

A CanNotDelete lock allows authorized users to read and modify the resource but blocks deletion.

A ReadOnly lock prevents both modification and deletion through the Azure control plane.

Microsoft states that the lock overrides user permissions.

That means a subscription owner can still be blocked from deleting a locked resource until the lock is removed by someone who has permission to manage locks.

Locks do not replace RBAC.

A lock does not decide which administrator is allowed to manage the resource under normal conditions.

RBAC still controls management permissions.

The lock adds a protective barrier against particular control-plane changes.

This is useful for resources where accidental deletion would have a large impact, such as:

• production virtual networks
• key platform resources
• critical storage accounts
• shared infrastructure
• central monitoring resources

The correct design is usually RBAC plus locks, not one instead of the other.

Inheritance is a frequent source of surprise. A lock applied to a subscription or resource group is inherited by child resources, including resources created later. The most restrictive applicable lock wins. Extension resources can also inherit the lock from the resource they extend, so deleting a diagnostic setting can fail because the parent resource is locked even though the administrator did not place a lock directly on the diagnostic setting.

Before removing a lock to make one deployment succeed, identify whether the operation genuinely should be permitted. A pipeline repeatedly failing against a deliberate production ReadOnly lock may indicate a process problem rather than an Azure problem.

Locks do not protect every data-plane operation

One of the most important Azure lock details is the control-plane boundary.

Microsoft states that resource locks apply to Azure control-plane operations, not normal data-plane operations.

For example, locking a storage account protects the storage-account resource from certain management changes, but it does not automatically stop a user with data-plane permission from deleting blobs.

That distinction is essential because the word “lock” can sound broader than it really is.

If the security requirement is to prevent data deletion, use the service’s data-protection and authorization features rather than assuming a Resource Manager lock covers the data.

Scope and inheritance affect all three controls differently

RBAC, Policy, and locks all use Azure scope, but they behave differently.

RBAC assignments at a parent scope can grant permissions to child resources.

Policy assignments at a parent scope can evaluate child resources unless excluded.

Locks placed at a parent scope are inherited by resources beneath that scope, with restrictive behavior following the inheritance chain.

In Azure, management-group governance can inherit policies across subscriptions, while a resource group defines an administrative scope for related resources. A budget alert does not deny a deployment, and a tag used in a cost report does not grant or remove permissions. When a resource violates a location policy or lacks a required tag, identify the assignment scope and effect before changing the subscription or resource-group layout.

A governance control placed high in the hierarchy can affect many workloads.

That can be exactly what the administrator wants—or a very large mistake.

Apply all three controls to one resource

Suppose a company has a production resource group.

The requirements are:

• Developers may restart VMs but cannot change network resources.
• Every resource must have a CostCenter tag.
• Production storage accounts must not be deleted accidentally.

Those map naturally to different tools.

RBAC: assign developers a role that provides only the necessary actions.

Azure Policy: require or enforce the CostCenter tag.

Resource lock: apply a CanNotDelete lock to the critical storage account.

Trying to solve all three with only RBAC would make the design harder and less precise.

Locks protect Azure Resource Manager operations, not the service’s ordinary data plane. A lock on a storage account can stop management changes to the account while authorized clients continue reading or writing blobs according to storage data-plane permissions. Conversely, some actions that look like data operations actually invoke a management-plane API and can be blocked by a lock.

This distinction is also why governance troubleshooting should use the request endpoint and error details. If the failing call is going through management.azure.com, RBAC, Policy, deny assignments, and locks are all plausible. If it goes directly to a service endpoint, investigate that service’s data-plane authorization and network controls.

Governance controls can interact

These controls are evaluated in combination.

A user might have RBAC permission to deploy a VM.

Azure Policy can still deny the requested VM if it violates a location or configuration rule.

A user might also have RBAC permission to delete a resource.

A resource lock can still block that deletion.

This layered behavior is deliberate.

RBAC answers who may act.

Policy answers whether the resulting state is compliant.

Locks answer whether selected management changes should be prevented even for otherwise authorized users.

Troubleshoot by identifying which control rejected the action

When an Azure operation fails:

1. Confirm the user or identity has the required RBAC role at the correct scope.
2. Check deny assignments where relevant.
3. Review Azure Policy assignments and compliance results.
4. Look for deny or modify effects affecting the requested resource.
5. Check inherited resource locks.
6. Determine whether the operation is control plane or data plane.
7. Review the activity log and deployment error for the actual denial source.

A useful diagnostic summary is: RBAC answers whether this identity can perform the operation; Policy answers whether the resulting Azure resource state is permitted; resource locks add a scope-wide guard against management changes or deletion. When an operation fails, identify which of those three decision systems actually returned the denial before changing configuration.