Azure RBAC vs. Conditional Access: Controlling Who Gets In

Azure role-based access control (RBAC) and Conditional Access solve two different problems that sound similar. RBAC decides what a user is allowed to do once they’re signed in — create a VM, delete a storage account, read a resource’s configuration. Conditional Access decides the conditions under which that sign-in is allowed to happen at all — from a compliant device, with MFA completed, from an expected location. One governs actions on resources; the other governs the sign-in event itself, and most real Azure environments need both working together — the same layered thinking behind Zero Trust and defense in depth.

Azure RBAC: who can do what, and where

Azure RBAC assigns permissions to a security principal — a user, group, service principal, or managed identity — through three elements that combine into a single role assignment: the principal (who), a role definition (what actions are permitted), and a scope (where in the resource hierarchy it applies). All three parts are required; a role assignment without a defined scope isn’t a valid assignment.

Scope can sit at four levels, from broadest to narrowest: management group, subscription, resource group, and individual resource. Permissions assigned at a broader scope flow downward automatically — grant Contributor at a resource group and every resource inside it, present now or added later, inherits that access without a second assignment. This is why RBAC design usually favors assigning roles at the highest scope that still satisfies the requirement, rather than repeating the same assignment resource by resource.

Four built-in roles come up constantly on the exam:

• Owner — full control over resources at the scope, plus the unique ability to grant access to others.
• Contributor — full control over resources, but cannot grant access to other users. This is the standard role for hands-on management without administrative control over permissions.
• Reader — view-only; can see configurations but change nothing.
• User Access Administrator — manages who has access to resources, without managing the resources themselves.

When permissions from multiple assignments apply to the same resource, Azure RBAC is additive: it combines every applicable role from every scope rather than letting one override another. A user with Reader at the subscription and Contributor directly on one resource group ends up with Contributor access in that specific resource group, on top of Reader everywhere else — the more specific, more permissive grant simply adds on. The one exception is a deny assignment, which explicitly blocks a specific action and always takes precedence over any role assignment that would otherwise permit it; Azure itself uses deny assignments to protect certain managed resources from deletion or modification.

When no built-in role matches a required set of permissions exactly — say, restarting VMs and reading their metrics without deletion or networking rights — Azure RBAC lets you define a custom role scoped to exactly those actions, avoiding the over-provisioning that comes from handing out a broader built-in role just because it’s close enough.

It’s also worth separating Azure RBAC from Microsoft Entra ID directory roles, which are a distinct system. Directory roles like Global Administrator govern tenant-wide identity tasks — resetting any user’s password, managing licenses — and are managed through Microsoft Entra ID, not Azure Resource Manager. Azure RBAC governs resources like VMs, storage accounts, and virtual networks. A single person might need a directory role for identity administration and a separately scoped Azure RBAC role for managing resources in one subscription; those are two different grants from two different systems.

Conditional Access: if-then rules at sign-in

Conditional Access enforces automated if-then policies evaluated at the moment of sign-in. Each policy checks signals — who the user is, which group they belong to, whether their device is marked compliant, their network location, the application they’re targeting, and the real-time sign-in risk level — and then grants access, blocks it, or requires an extra step like MFA before letting it through — see SSO, MFA, and passwordless authentication for what that extra step actually involves.

This is where Microsoft Entra ID Protection plugs in. Identity Protection detects identity-based risk signals, like an unfamiliar location or a leaked credential, and Conditional Access acts on those signals — challenging a risky sign-in for MFA rather than either waving it through unchallenged or blocking it outright. That graduated response, rather than an all-or-nothing decision, is a hallmark of how the two features work together and requires a Microsoft Entra ID P2 license.

Conditional Access is a premium capability. It requires at least a Microsoft Entra ID P1 license (P2 adds Identity Protection’s risk-based signals); the free tier doesn’t include it at all, and an organization on the free tier that wants Conditional Access has to upgrade first. Organizations without P1 aren’t left with nothing, though — security defaults provide a free, fixed baseline that requires MFA for administrators, just without the granular, condition-based control Conditional Access offers.

A recurring exam pattern: when more than one Conditional Access policy applies to the same sign-in and the results disagree — one policy would grant access, another would block it — the block always wins. This is deliberate: a block decision can’t be overridden by a separate grant policy, or the block would be pointless.

Azure RBAC vs. Conditional Access

	Azure RBAC	Conditional Access
Governs	What actions a principal can perform on resources	The conditions required to sign in at all
Evaluated	Continuously, once access is granted	At the moment of sign-in
Managed through	Azure Resource Manager	Microsoft Entra ID
Built from	Security principal + role definition + scope	Signals (user, device, location, risk) + grant controls
License	Included with Azure	Requires Microsoft Entra ID P1 or P2

How the AZ-900 exam tests this

• The “which system does X” discrimination. A stem describes restricting who can delete a VM versus requiring MFA from unfamiliar locations. The first is RBAC (an action on a resource); the second is Conditional Access (a sign-in condition). Confusing the two is the most common wrong-answer trap in this domain.
• The combined-controls scenario. Many stems ask for a solution meeting two requirements at once — for example, view-only access scoped to one resource group plus mandatory MFA and a compliant device for that account. The correct answer pairs a scoped RBAC role assignment with a separate Conditional Access policy; neither system alone satisfies both halves.
• The scope-and-inheritance question. Expect scenarios asking where to assign a role so it covers exactly the intended resources with the fewest assignments — testing whether you understand that RBAC inherits downward from management group through resource.
• The role-selection-by-restriction pattern. A stem specifies someone needs to manage resources but never grant access to others. That combination always points to Contributor, since Owner would additionally allow granting access — a distinction the exam tests repeatedly with different job titles attached.

Quick reference

• Azure RBAC controls actions on resources; Conditional Access controls the conditions for signing in.
• A role assignment always has three parts: security principal, role definition, scope.
• Scope runs management group → subscription → resource group → resource, broadest to narrowest, with downward inheritance.
• Contributor manages resources but cannot grant access; Owner can do both.
• RBAC combines permissions additively across assignments; only a deny assignment overrides this.
• Conditional Access requires Microsoft Entra ID P1 (or P2 for Identity Protection’s risk signals); it’s not available on the free tier.
• When Conditional Access policies conflict, block always wins over grant.

Once you can tell “who can do what to a resource” apart from “what conditions must be met to sign in,” work through AZ-900 practice questions on this domain to lock in the pattern, and pair this with Azure subscriptions vs. management groups to see how the RBAC scope hierarchy maps onto Azure’s governance structure, plus Azure Policy for how resource configuration rules differ from both.