Azure Policy vs RBAC vs Resource Locks.

Who may act, what state is allowed, and what must not change

These controls are complementary. A Contributor may be authorized to create a resource through RBAC, yet Azure Policy can deny the deployment because its state is noncompliant. The same Contributor may be authorized to delete a resource, yet an inherited lock can block that control-plane deletion.

Compare the controls by requirement

Azure RBAC: authorize a principal at scope

An Azure role assignment combines three elements: a security principal, a role definition and a scope. The role definition supplies allowed operations; the assignment applies those permissions at a management group, subscription, resource group or resource scope, with inheritance to children.

• Principal: user, group, service principal or managed identity.
• Role: built-in or custom collection of allowed management and/or data actions.
• Scope: where the assignment applies.
• Least privilege: grant only the operations and scope needed for the task.
• Effective access: consider inherited assignments, groups, conditions and applicable deny assignments.

RBAC answers an identity-aware question. If a rule must apply to resource state no matter which authorized person or workload submits the request, Policy is usually the better governance mechanism.

Azure Policy: evaluate and govern resource state

A policy definition contains conditions and an effect. An assignment applies a definition—or an initiative containing several definitions—to a scope. Azure Policy evaluates applicable resources while honoring configured exclusions and exemptions.

Existing noncompliant resources are not universally fixed merely because a policy is assigned. The effect, evaluation trigger and remediation configuration determine what happens. Test impact before assigning restrictive rules broadly.

Resource locks: broad control-plane protection

Management locks can be applied at subscription, resource-group or resource scope. Child resources inherit locks from parents. Azure exposes two levels:

• CanNotDelete (Delete): authorized principals can read and modify the resource but cannot delete it through the protected control-plane path.
• ReadOnly: authorized principals can read but cannot update or delete the resource through the control plane.

Control plane only: locks protect Azure Resource Manager operations. They do not automatically block data-plane operations against the service endpoint. A storage-account lock does not by itself prevent an authorized data-plane principal from deleting blobs.

Locks can also block operations that seem harmless because some services use POST for actions such as listing keys or regenerating credentials. Check service-specific behavior before placing ReadOnly locks on production resources.

Worked scenario: govern a production storage account

An organization needs operators to manage a production storage account, requires approved location and diagnostics, and wants to prevent accidental deletion.

1. Assign operators a least-privilege Azure RBAC role at the storage-account or resource-group scope.
2. Assign Azure Policy rules for allowed locations, required tags and diagnostic configuration.
3. Use audit first to assess impact, then select deny, modify or deployIfNotExists effects according to the requirement.
4. Create any required remediation task and ensure its managed identity has the necessary role.
5. Apply a CanNotDelete lock at the resource or resource-group scope.
6. Configure storage data-plane roles, soft delete, versioning and backup/recovery separately; the resource lock does not protect blob contents.
7. Document who can modify policy assignments and remove locks, and monitor those governance changes.

This design gives operators legitimate access, enforces compliant configuration and adds an accidental-deletion barrier without confusing management-plane protection with data protection.

How the controls combine on one request

Do not memorize an oversimplified universal evaluation order. Instead, test each required gate:

1. Identity and RBAC: is the principal authenticated and authorized for the requested operation at the effective scope?
2. Resource lock: does a lock at the resource or an inherited parent scope prohibit the control-plane operation?
3. Azure Policy: would the resulting resource state or supported action violate any applicable assignment?
4. Service/data-plane controls: if the request targets resource data, what service-specific authorization, network and protection rules apply?

A successful operation must satisfy every applicable control. Granting Owner does not make a noncompliant Policy result compliant, and adding a management lock does not grant or revoke data-plane access.

Troubleshoot the correct governance layer

1. Read the error and operation: identify the resource provider action and whether it targets control or data plane.
2. Check effective RBAC: review direct and inherited role assignments at the failing scope.
3. Check locks: inspect the resource and parent resource group/subscription for inherited CanNotDelete or ReadOnly locks.
4. Check Policy details: identify the assignment, definition, effect, parameters, scope and exemption that produced denial or noncompliance.
5. For remediation: verify the assignment identity, role assignment, supported effect and remediation-task status.
6. Retest narrowly: correct the intended control rather than granting broad access or removing governance globally.

AZ-104 practice checks with explanations

Common AZ-104 mistakes

• Using RBAC to enforce a configuration rule that must apply regardless of user.
• Assuming Policy grants permissions to a principal.
• Assuming a Contributor can bypass a deny Policy effect.
• Choosing ReadOnly when only deletion protection is required.
• Checking only the resource and missing an inherited parent lock.
• Believing a resource lock protects database rows, blobs or other data-plane content.
• Assuming all existing noncompliant resources remediate automatically.
• Removing broad governance instead of diagnosing the assignment, lock or role at the correct scope.

Frequently asked questions

Official Microsoft references

• Current AZ-104 study guide
• Azure Policy overview
• Understand Azure role assignments
• Lock Azure resources
• Control-plane and data-plane operations

Confirm current service behavior and scope before changing production governance. ITCertPath uses original learning scenarios and does not reproduce confidential exam questions.