AZ-104 RBAC vs Azure Policy vs resource locks: which control fits?

AZ-104 identity and governance questions often place Azure RBAC, Azure Policy, and resource locks near each other because they all affect control. They are not interchangeable. RBAC answers who can do something. Policy answers what configurations should be allowed, denied, audited, or remediated. Locks protect resources from management-plane deletion or modification.

If you know which question is being asked, the answer becomes much clearer. A support engineer who needs read-only access is an RBAC scenario. A company that wants to require approved regions is a Policy scenario. A production database that must not be accidentally deleted may need a resource lock.

The exam-style habit is to identify the control objective before reading the options. Is the organization assigning permission, enforcing a standard, or preventing a high-impact change?

Azure role-based access control assigns permissions to users, groups, service principals, or managed identities at a scope such as management group, subscription, resource group, or resource. AZ-104 questions often test least privilege and correct scope selection.

A help desk technician who only needs to restart virtual machines in one resource group should not receive Owner at the subscription. The better pattern is a role that matches the task, assigned at the narrowest useful scope.

When reviewing RBAC questions, ask four things: who needs access, what action do they need, which resources are in scope, and how will the assignment be reviewed later? That keeps access decisions practical and defensible.

Azure Policy is about governance rules. It can audit, deny, append, modify, or help remediate resource configurations depending on the policy effect and assignment. It is useful when an organization wants resources to follow a standard across a scope.

Examples include allowed regions, required tags, approved VM sizes, storage security requirements, or configuration baselines. These are not mainly questions about one user's permission. They are questions about what resource states should be permitted or reported.

A common wrong answer is using RBAC when the organization needs configuration enforcement. RBAC can stop unauthorized people from creating resources, but it does not by itself define which regions, tags, or settings are compliant for authorized deployments.

Resource locks help prevent accidental deletion or modification of important Azure resources. In AZ-104 scenarios, a lock may be relevant when the resource is production-critical and the risk is an unintended management-plane change.

Locks are not a replacement for RBAC or Policy. A lock can help prevent deletion, but it does not assign least-privilege access or enforce a tagging standard across new resources. It is one layer in a governance design.

When a question mentions accidental deletion, production protection, or preventing modification by authorized users, think about locks. When the question mentions who should have access, think RBAC. When it mentions standards at scale, think Policy.

Real Azure governance usually combines all three. A subscription might use RBAC to assign roles, Policy to require approved regions and tags, and locks to protect selected production resources. AZ-104 scenarios often reward choosing the missing control, not assuming one control solves everything.

During practice, write a one-line reason for the selected control. Example: 'Policy fits because the requirement is to enforce allowed regions across a subscription.' Another example: 'RBAC fits because the requirement is limited read access for an auditor.'

This simple distinction also improves storage, compute, networking, and monitoring questions. Many Azure operations decisions still depend on scope, permission, compliance, and change protection.