Conditional Access, RBAC, and Secure Resource Access

radio_button_uncheckedshort_text Introduction

Early corporate environments protected resources mainly with physical and network boundaries. Being connected to the internal network often meant receiving a high level of trust. With the expansion of the internet, cloud computing, remote work, and mobile devices, this assumption became fragile: legitimate users access resources from anywhere, while attackers can operate from inside a compromised account. The modern response was to move the access decision to a set of identity, device, risk, and context signals.

For the reader, mastering this topic means learning to turn a successful authentication into an access decision proportional to risk. For society, adaptive controls reduce fraud, leaks, and disruptions without forcing everyone to face the same level of friction in every situation. Instead of blindly trusting a location, the organization can explicitly verify each request and grant only what is necessary.

Throughout this chapter, three questions will guide the reading: who can sign in, what that identity can administer, and by which path the resource will be accessed. Conditional Access answers the first question with contextual policies; RBAC answers the second with roles and scopes; Global Secure Access extends the third by converging identity and network security. This separation is the key to understanding the topic and getting scenario questions right on the SC-900.

radio_button_uncheckedshort_text 1. From network trust to identity-driven access

In the traditional model, firewalls, internal segments, and VPNs concentrated protection at the network boundary. Once inside, the user often reached multiple systems. This design worked better when applications and workstations were in the same building or data center. In the cloud, resources can be distributed across Microsoft 365, Azure, SaaS applications, on-premises data centers, and other clouds. The network address alone no longer proves who is using the device nor whether the session remains secure.

The Zero Trust model replaces implicit trust with three principles: verify explicitly, use least privilege, and assume breach. Verifying explicitly means considering identity, authentication method, device, application, network, risk, and resource sensitivity. Least privilege limits what the identity can do. Assume breach leads to monitoring sessions and reducing the reach of a compromised credential or token.

Central idea

The network remains important, but it stops being the only boundary. The modern decision combines identity, context, and resource, and it can change according to the risk of the request.

radio_button_uncheckedshort_text 2. Authentication, Conditional Access , and authorization

Authentication confirms identity. Conditional Access evaluates whether the request should proceed and which additional requirements must be met. Authorization determines the actions allowed on the resource. These mechanisms complement each other, but they are not equivalent. A user can prove who they are, satisfy MFA, and still receive read-only access because of their role. They can also have an administrative role but be blocked because the device is not compliant.

radio_button_uncheckedshort_text 3. What is Microsoft Entra Conditional Access

Microsoft Entra Conditional Access , or Conditional Access , is the Zero Trust policy engine of Microsoft Entra ID. It gathers signals about the request, makes a decision, and applies controls. The simplest way to describe it is an "if... then..." statement: if a given identity tries to access a given resource in a certain context, then block, grant with additional requirements, or limit the session.

The evaluation happens after first-factor authentication is completed. This means Conditional Access does not replace credentials nor act as a primary defense against denial-of-service attacks. It uses the already presented identity and other signals to decide whether the sign-in can continue. This order matters on exam questions: first there is an authenticated attempt; then policies are evaluated; finally the resource applies authorization and session controls.

radio_button_uncheckedshort_text 4. Anatomy of a policy: assignments and controls

A policy has two major sides. Assignments define whom and what the policy applies to, including identities, target resources, and conditions. Access controls define the outcome: block, grant with requirements, or restrict the session. For a policy to be applicable, its assignments must match the sign-in scenario.

In a simple policy, an administrator selects users or groups, chooses an application, and requires MFA. In a more refined policy, they can include all administrative identities, exclude emergency accounts, apply only to the management portal, evaluate network and device, and require a phishing-resistant authentication strength.

radio_button_uncheckedshort_text 5. Included and excluded identities

The policy can target all users, specific people, groups, directory roles, guests, and external users. Certain scenarios also allow policies for workload identities, such as service principals, with appropriate features and licensing. The scope must be broad enough to cover the risk, but controlled enough to be tested.

Exclusions must be used with intent. A critical practice is to keep emergency access accounts, known as break-glass, out of policies capable of blocking all administrators. These accounts are not shortcuts for everyday use: they must be strongly protected, monitored, and used only for recovery. Service and synchronization accounts also require analysis, because non-interactive flows may not satisfy controls designed for people.

Common pitfall

Excluding too many users to avoid problems reduces the policy's coverage. Excluding no one in a block policy can cause a lockout. The goal is to use minimal, justified, and monitored exclusions.

radio_button_uncheckedshort_text 6. Target resources and protected actions

Target resources are the applications, services, or actions to which the controls will be applied. Microsoft Entra allows selecting all resources, specific applications, integrated applications, applications published by Application Proxy, and other compatible targets. The current term "target resources" replaces older references to "cloud apps", but the idea remains: the policy needs to know what is being protected.

It is also possible to protect actions, such as security information registration, and use authentication context to raise the protection of a sensitive operation within an application. Global Secure Access adds traffic forwarding profiles as targets, allowing controls to be applied to Microsoft, internet, and private resource traffic.

radio_button_uncheckedshort_text 7. Conditions: the context of the request

Conditions refine when a policy will be triggered. They do not grant permission; they describe the context that makes the policy relevant. The more signals are combined, the more specific the decision becomes. However, an overly complex policy is hard to test and troubleshoot. In real projects, it is common to prefer smaller policies with a clear objective and consistent naming.

radio_button_uncheckedshort_text 8. Location is not synonymous with security

Conditional Access can use IP ranges, countries, regions, and named locations. A location can be marked as trusted, but that does not automatically make all access originating from it secure. Addresses can be shared, networks can be compromised, and users can work outside the office. Location must be an additional signal, not an absolute proof of identity.

A policy can block countries where the organization does not operate or require MFA outside known networks. Even so, stronger decisions combine location with authentication method, device compliance, and risk. Global Secure Access adds the idea of a compliant network, proving that traffic passed through the tenant's service and its network policies.

radio_button_uncheckedshort_text 9. User risk and sign-in risk

User risk expresses the probability that the identity has been compromised, for example after detection of leaked credentials or anomalous behavior. Sign-in risk expresses the probability that a specific request was not made by the legitimate owner. Both are signals produced by Microsoft Entra ID Protection and require the corresponding licensing features for risk-based policies.

An organization can require MFA when sign-in risk is medium or high and require a secure password change when user risk indicates compromise. The password change control has specific combinations and requirements; at the fundamental level, memorize the goal: MFA proves the identity again in the face of a suspicious sign-in, while the secure password change helps remediate a compromised account.

radio_button_uncheckedshort_text 10. Grant controls

Grant controls determine what must happen for access to be allowed. The administrator can block directly or grant subject to one or more requirements. When multiple controls are selected within the same policy, it is possible to require all or at least one, depending on the configuration. In addition, multiple policies can reach the same sign-in, and all applicable policies must be satisfied.

radio_button_uncheckedshort_text 11. Compliant device and hybrid joined device

A compliant device is evaluated by a management solution, usually Microsoft Intune, according to rules such as OS version, encryption, screen lock, and absence of threats. Intune sends the state to Microsoft Entra ID, and Conditional Access uses that signal. The policy does not remediate the device; it requires that the compliance requirement is already met.

A Microsoft Entra hybrid joined device has a relationship with the on-premises Active Directory and a registration in Microsoft Entra ID. Requiring this state is different from requiring compliance. A device can have a hybrid identity and still fail a compliance policy. In questions, look for the keyword: "managed and healthy" points to compliance; "joined to the on-premises domain and registered in the cloud" points to hybrid join.

radio_button_uncheckedshort_text 12. Session controls

Session controls act after access is granted and limit the experience or the duration of the session. They help reduce exposure without completely blocking work. Examples include sign-in frequency, persistent browser session, app-enforced restrictions, and Conditional Access App Control with Microsoft Defender for Cloud Apps.

Sign-in frequency defines when the user must re-authenticate. Persistent session controls whether the browser can stay signed in after being closed. App-enforced restrictions can offer a limited experience, such as web-only access. Defender for Cloud Apps can monitor the session and block download, copy, or print of sensitive content. Current features also include token protection, customization of Continuous Access Evaluation, and use of Global Secure Access security profiles.

radio_button_uncheckedshort_text 13. How multiple policies are evaluated

Microsoft Entra evaluates all policies applicable to the request. They are not processed as a list where the first replaces the others. If one policy requires MFA and another requires a compliant device, the user must satisfy both. If an applicable policy blocks access, the request is blocked even if another policy grants access with requirements.

Within a single policy, grant controls can be combined by "require all" or "require one". Outside it, requirements from different policies accumulate. This difference explains many design errors: two controls configured as an alternative in the same policy do not cancel an additional requirement from another policy.

Memorization rule

Applicable policies accumulate. Block wins. Requirements from different policies must be satisfied together.

radio_button_uncheckedshort_text 14. Secure deployment, report-only, and the What If tool

Conditional Access is powerful enough to block the entire organization. Therefore, deployment must be gradual: define the objective, identify dependencies, create a pilot group, exclude emergency accounts, use report-only mode, review logs, and only then enable it. Report-only mode evaluates what would happen without enforcing the controls on the user, allowing you to measure impact before real enforcement.

The What If tool simulates a sign-in with identity, resource, platform, client app, and other conditions. It shows applicable policies, non-applicable policies, and grant or session requirements. Sign-in logs display the result per policy and help distinguish an authentication failure, a policy block, and a lack of authorization on the resource.

1. Define the risk and the expected outcome in one sentence.
2. Choose identities and target resources; keep emergency accounts excluded.
3. Add only the conditions necessary for the objective.
4. Select grant or session controls and confirm the "all" or "one" logic.
5. Put the policy in report-only and test with pilot users.
6. Use What If, sign-in logs, and reports to analyze impact.
7. Enable in stages, monitor, and keep a rollback procedure.

radio_button_uncheckedshort_text 15. Classic Conditional Access scenarios

radio_button_uncheckedshort_text 16. What is role-based access control ( RBAC )

Role-Based Access Control, or RBAC , is an authorization model in which permissions are grouped into roles and assigned to identities in a scope . Instead of granting dozens of permissions directly to each person, the organization creates or uses roles consistent with job responsibilities. This simplifies administration, auditing, and access removal.

A role assignment combines three elements: security principal , role definition , and scope . The principal is who receives access; the definition is the set of permissions; the scope is where they apply. The assignment is the link that brings the three together. Removing the assignment revokes that access path.

radio_button_uncheckedshort_text 17. Security principals and role definitions

A security principal can be a user, group, service principal, or managed identity. Using groups reduces individual assignments and makes team changes easier. Service principals and managed identities allow applications and automations to receive only the necessary permissions, avoiding the use of personal accounts in code.

The role definition gathers allowed actions. Built-in roles serve common scenarios; custom roles allow selecting specific permissions when the built-in ones are too broad or insufficient. Creating custom roles increases precision, but also the responsibility of maintaining and reviewing permissions as services evolve.

radio_button_uncheckedshort_text 18. Microsoft Entra roles

Microsoft Entra roles control administrative tasks over directory resources, such as users, groups, applications, authentication methods, policies, and roles. Examples include Global Administrator, User Administrator, Application Administrator, and Conditional Access Administrator. They operate mainly in the identity plane and use permissions exposed by Microsoft Graph.

The scope can be the entire tenant, an administrative unit or, for supported roles, a specific object, such as an application. Administrative units allow delegating tasks to a part of the organization: a regional administrator can manage only users and groups of that region. Not all roles or settings can be limited by administrative unit, so the scope needs to be verified.

Least privilege in Entra

Prefer the specialized role that fits the task. Global Administrator should be rare, protected and, ideally, activated only when necessary through PIM, a topic explored in depth in the next chapter.

radio_button_uncheckedshort_text 19. Azure RBAC and resource scopes

Azure RBAC is the authorization system based on Azure Resource Manager for resources such as virtual machines, networks, vaults, databases, and storage accounts. Broad roles include Owner, Contributor, and Reader. Owner manages resources and access assignments; Contributor manages resources but does not assign roles; Reader only views. There are service-specific roles, which usually serve least privilege better.

The four main scope levels are management group, subscription, resource group, and resource. An assignment at a higher level is inherited by the lower levels. Thus, granting Contributor on the subscription is much broader than granting Virtual Machine Contributor to a machine or resource group. Azure RBAC is predominantly additive: effective permissions result from the sum of assignments, although deny assignments and conditions can limit actions in specific scenarios.

radio_button_uncheckedshort_text 20. Microsoft Entra roles vs Azure roles

The names "role" and " RBAC " appear in both systems, but they protect different types of resources. Microsoft Entra roles administer the directory and identities. Azure roles administer subscription resources through Azure Resource Manager. A person can be a User Administrator in Entra and Reader on a resource group, or have only one of these roles.

By default, Global Administrator does not receive automatic access to Azure resources. Likewise, being Owner of a subscription does not make the person a Global Administrator of the tenant. There is an elevation mechanism for access recovery, but it is an explicit and highly privileged action. For the SC-900, the correct answer usually depends on identifying the managed object: a user, group, or application points to an Entra role; a VM, network, or storage points to an Azure role.

radio_button_uncheckedshort_text 21. The principle of least privilege

Least privilege means granting only the necessary permissions, in the smallest scope and for the shortest appropriate period. An assignment can be technically functional and still be insecure. Giving Owner on a subscription to someone who needs to restart a machine solves the task, but creates the ability to change resources and grant access far beyond the need.

radio_button_uncheckedshort_text 22. From SSE to SASE : cloud-delivered access security

Security Service Edge, SSE , is a security category that delivers access controls and traffic protection through the cloud. It brings policies closer to the user and the resource, regardless of which office the person is in. Secure Access Service Edge, SASE , is a broader architecture that combines SSE security capabilities with wide-area network connectivity, such as SD-WAN.

In the Microsoft ecosystem, Microsoft Entra Internet Access and Microsoft Entra Private Access form the SSE solution and are unified under Global Secure Access in the Microsoft Entra admin center. The proposal is to converge identity, device, and network signals, using consistent policies for Microsoft, internet, SaaS, and private application resources.

radio_button_uncheckedshort_text 23. Microsoft Entra Internet Access

Microsoft Entra Internet Access protects access to the internet and SaaS applications with an identity-based Secure Web Gateway, or SWG . Traffic can be acquired by a client installed on the device or by a remote network, such as a branch office. Policies can block malicious content, restrict site categories, and log destinations, users, devices, and applied rules.

Integration with Conditional Access allows using identity, risk, device, and network context in decisions that reach internet destinations, including services that are not directly federated to Microsoft Entra ID. The service also has a profile for Microsoft traffic, with controls such as compliant network check, universal tenant restrictions, and enriched logs.

Exam keyword

Internet Access is associated with the public internet, SaaS applications, Secure Web Gateway, content filtering, and identity-driven network policies.

radio_button_uncheckedshort_text 24. Microsoft Entra Private Access

Microsoft Entra Private Access offers Zero Trust access to private applications and resources in data centers, hybrid environments, and multicloud. Instead of opening broad connectivity to the network, the organization can grant access per application, FQDN, IP range, port, and protocol. The service uses private network connectors and the Global Secure Access client to forward authorized traffic.

The goal is to modernize or replace VPN scenarios with a ZTNA approach, Zero Trust Network Access. A traditional VPN often places the device inside a network segment; Private Access seeks to connect the identity only to authorized resources. Quick Access covers broader sets of internal addresses, while Private Access applications allow per-application segmentation.

Exam keyword

Private Access is associated with private applications, internal resources, per-application access, ZTNA , and reduced dependence on broad VPN.

radio_button_uncheckedshort_text 25. How Conditional Access and Global Secure Access come together

Conditional Access decides which requirements the identity must satisfy. Global Secure Access acquires and forwards traffic, applies network policies, and provides additional signals. Together, they create a policy that follows the user's request to the destination. A private application can require MFA and a compliant device; an internet destination can receive a security profile; a Microsoft service can require that traffic comes from a compliant network.

This integration reduces the historical separation between identity and network teams. Even so, the controls continue to have different roles: Conditional Access does not replace content filtering, and the SWG does not replace an authorization function in the application. The secure architecture combines layers, logs, and clear responsibilities.

radio_button_uncheckedshort_text 26. Integrated practical scenario

Consider the company Contoso Finance, with Microsoft 365, Azure resources, and a financial system hosted in the on-premises data center. Analysts work in the office and remotely. Administrators need to manage identities and infrastructure, but the company wants to reduce standing privileges, prevent access from insecure devices, and replace the broad VPN of the financial system.

26.1 Access design

• All users receive a baseline policy that blocks legacy authentication.
• The financial application requires MFA and a compliant device.
• High-risk sign-ins are blocked or forwarded for remediation, according to the policy.
• Administrators are targeted by a separate policy with a phishing-resistant authentication strength.
• Emergency accounts are excluded from the block policies, protected, and monitored.
• Analysts receive only the business role in the application; they do not receive administrative roles.
• The identity team receives specialized Microsoft Entra roles, not standing Global Administrator.
• The infrastructure team receives specific Azure roles on the corresponding resource group.
• Microsoft Entra Private Access publishes the financial system per application, without granting general access to the internal network.
• Microsoft Entra Internet Access protects browsing and SaaS applications with network policies and logs.

26.2 How to analyze a user's request

1. The user authenticates to Microsoft Entra ID.
2. Conditional Access identifies user, application, network, device, and risk signals.
3. The policy requires MFA and compliance; all applicable policies must be satisfied.
4. Global Secure Access forwards only the authorized traffic to the private application.
5. The application or Azure RBAC checks the role and scope to decide which actions are allowed.
6. Sign-in, traffic, and audit logs record the decision and the activities.

Logic for scenario questions

Ask in order: was the identity authenticated? Does the policy allow the sign-in? Does the role authorize the action? Does the network path deliver only the necessary resource?

radio_button_uncheckedshort_text 27. Frequent conceptual pitfalls

• Conditional Access is evaluated after first-factor authentication; it does not replace the authentication method.
• MFA confirms with more assurance who the user is; RBAC decides what they can do.
• Compliant device and hybrid joined device are different conditions.
• A trusted location is a signal, not an absolute guarantee of security.
• Multiple applicable policies accumulate; a block policy is not canceled by another grant policy.
• Within a policy, "require one" is OR; "require all" is AND.
• Report-only evaluates impact, but does not force the user to satisfy the controls.
• Microsoft Entra roles do not automatically administer VMs and storage.
• Azure roles do not make the user a Global Administrator of the tenant.
• Owner is broader than Contributor because it also manages access assignments.
• Internet Access protects internet and SaaS; Private Access protects internal and private resources.
• SSE is the security layer; SASE also includes the network connectivity architecture.

radio_button_uncheckedshort_text 28. Quick review for the SC-900

One-sentence summary

Conditional Access decides under which conditions the identity signs in; RBAC limits the actions in the scope ; Global Secure Access carries these decisions to Microsoft, internet, and private application resources.

radio_button_uncheckedshort_text 29. Conclusion

Modern access control does not depend on a single password, network, or role. It combines signals about identity, device, location, application, and risk. Microsoft Entra Conditional Access turns these signals into adaptive decisions: block, require MFA, request stronger authentication, require compliance, remediate risk, or limit the session. The value is in applying proportional protection, avoiding both excessive trust and unnecessary friction.

RBAC complements this decision by limiting what the authenticated identity can do. Principal, role, and scope form an assignment ; least privilege reduces the three to what is necessary. Differentiating Microsoft Entra roles from Azure roles avoids one of the most common errors: confusing directory administration with cloud resource administration.

Global Secure Access extends the same reasoning to the network. Internet Access protects public and SaaS traffic with an identity-driven SWG ; Private Access offers per-application ZTNA for internal resources. My assessment is that the great evolution of this chapter is convergence: identity, authorization, and connectivity stop being silos and start participating in a continuous decision. For the exam, memorizing purposes is essential; for practice, the goal is to create simple, testable, auditable policies consistent with Zero Trust.

Next step in the track

After controlling conditions and permissions, the next chapter goes deeper into governance, privileged access, access reviews, PIM, and risk-based identity protection.

radio_button_uncheckedshort_text 30. Review questions

1. A company wants to allow access to the financial system only when the user completes MFA and is on a compliant device. Which feature directly meets the requirement?

• A) An Azure Reader role applied to the subscription.
• B) A Conditional Access policy with both grant controls required.
• C) Microsoft Entra Private Access without any identity policy.
• D) An administrative unit in Microsoft Entra ID.

Answer explained

Correct answer: B. Conditional Access combines identity and resource with grant controls. The policy must require all selected controls so that MFA and compliance are mandatory.

2. Which statement correctly differentiates Microsoft Entra roles and Azure roles?

• A) Microsoft Entra roles manage resources such as VMs, and Azure roles manage users.
• B) The two roles are equivalent and always apply to the same scope .
• C) Microsoft Entra roles administer directory resources; Azure roles administer resources via Azure Resource Manager.
• D) Global Administrator is automatically Owner of all subscriptions.

Answer explained

Correct answer: C. The systems use the concepts of role and assignment , but they protect different planes. By default, a role does not grant permissions in the other system.

3. An organization wants to assess the impact of a new block policy before affecting users. Which combination is most appropriate?

• A) Enable the policy for everyone and wait for tickets.
• B) Use report-only, the What If tool, and sign-in logs.
• C) Assign Global Administrator to the pilot users.
• D) Replace Conditional Access with an RBAC role.

Answer explained

Correct answer: B. Report-only calculates the result without enforcing the requirements, What If simulates scenarios, and the logs show applied policies and results.

4. Which service is most directly associated with per-application access to private resources without granting broad VPN connectivity?

• A) Microsoft Entra Internet Access.
• B) Azure RBAC .
• C) Microsoft Entra Private Access.
• D) Microsoft Entra User Administrator.

Answer explained

Correct answer: C. Private Access is the ZTNA capability of Global Secure Access aimed at private applications and resources, with granular control per application, address, port, and protocol.

radio_button_uncheckedshort_text Essential glossary

radio_button_uncheckedshort_text Official references and update notes

The content was prepared based on the provided study plan and official Microsoft documentation consulted on July 23, 2026. Cloud services, control names, licensing, and preview features can change; validate the documentation before a deployment.

• Microsoft Learn - Study guide for Exam SC-900
• Microsoft Learn - Describe access management capabilities of Microsoft Entra
• Microsoft Learn - What is Conditional Access in Microsoft Entra ID
• Microsoft Learn - Building a Conditional Access policy
• Microsoft Learn - Conditional Access conditions
• Microsoft Learn - Grant controls
• Microsoft Learn - Session controls
• Microsoft Learn - Report-only mode
• Microsoft Learn - What If tool
• Microsoft Learn - Azure RBAC overview
• Microsoft Learn - Azure roles and Microsoft Entra roles
• Microsoft Learn - Microsoft Entra RBAC overview
• Microsoft Learn - Best practices for Microsoft Entra roles
• Microsoft Learn - What is Global Secure Access
• Microsoft Learn - Microsoft Entra Private Access

Official sources consulted on July 23, 2026. As cloud services evolve continuously, licensing details, regional availability, menu names, and preview features should be confirmed in the current documentation before a real implementation.