SC-900: Identity and Access in Microsoft Cloud

Identity is the point at which an abstract cloud security policy meets an actual request from a person, device, application, or workload. A company may invest in information protection and threat detection, yet still allow a departing contractor to enter a project workspace because the wrong guest identity remains active. Microsoft SC-900 introduces the concepts needed to understand that chain of events. The SC-900 examination covers security, compliance, and identity foundations across Microsoft cloud services, while more specialized credentials assess hands-on implementation. The valuable skill at fundamentals level is recognizing which control addresses which risk, and where one control ends and another begins.

Imagine a regional retailer introducing Microsoft 365 for headquarters, stores, suppliers, and seasonal workers. Every population has a different employment relationship, device profile, information need, and risk tolerance. A single permissive sign-in rule would be easy to manage but expensive to defend. Treating every user as a uniquely managed exception would create its own operational failures. The administrator must choose a coherent identity model that accounts for sign-in, authorization, guest collaboration, recovery, auditing, and lifecycle events. SC-900 provides a conceptual framework for reasoning about these decisions without pretending that knowing product names is the same as operating the platform.

Identify the actors before choosing controls

Microsoft Entra ID is the identity service used in many Microsoft cloud scenarios. It represents users, groups, service principals, and managed identities, but those objects are not interchangeable. A human user needs interactive authentication and lifecycle management. A service principal represents an application in an identity tenant and can receive permissions to call APIs. A managed identity is an Azure-managed identity that helps a workload obtain credentials without developers maintaining a long-lived secret. Selecting the wrong identity type may create avoidable credentials, administrative overhead, or unintended access. An exam scenario may describe the workload indirectly, so first ask whether a person or a software component is making the request.

An employee can also have several forms of access that should not be confused. Being present in a directory does not automatically grant permission to a document, team, subscription, or application. Group membership can streamline entitlement management; the application or resource still evaluates the permission it recognizes. A customer identity or external collaborator may cross organizational boundaries with different trust settings. In the retailer example, a vendor needs access to a shared planning document, not a general account that can browse internal financial information. Separating identity establishment from resource authorization prevents many mistaken conclusions about what an administrator has actually secured.

Authentication proves identity; authorization limits actions

Authentication asks whether the claimant is who or what they say they are. Passwords are a familiar factor, but weak and reused passwords are easy to steal, phish, or replay. Multifactor authentication adds independent evidence, often using an authenticator, physical key, or device-bound method. The strength of that process depends on resistance to phishing, enrollment integrity, and recovery procedures—not merely on the number of prompts shown to employees. Passwordless methods can improve both security and usability by reducing exposure to shared secrets. An administrator also has to protect identity-proofing and account recovery, because an attacker may try to bypass a strong sign-in method through a weak reset channel.

Authorization occurs after an identity is accepted. Role-based access control groups actions by assigned roles, while resource permissions and application rules determine what a principal may see or change. The principle of least privilege means granting the minimum capability needed for a defined job and withdrawing it when that job changes. It does not mean blindly assigning the narrowest role if doing so forces staff to share privileged accounts or seek emergency exceptions every hour. For someone studying Microsoft Entra Conditional Access, it helps to distinguish sign-in conditions from the permissions that remain after a successful sign-in.

Conditional Access is a decision about context

A Conditional Access policy evaluates signals such as the user, target application, device state, location information, and assessed risk, then applies a grant or session control. It is not a standalone replacement for multifactor authentication, nor is it a guarantee that every risky session can be detected. A retailer may require phishing-resistant authentication for payroll administrators and compliant devices for access to sensitive corporate applications. A different policy may address external suppliers whose devices cannot be managed. In either case, exceptions deserve scrutiny because a broad exclusion can become a preferred route around protection. Policies should be tested against representative identities before an organization relies on them at scale.

Troubleshooting sign-in failures requires following the policy evaluation rather than assuming that one red message explains everything. Was the user targeted by the policy? Was the relevant application included? Did the session present a device claim? Did several policies apply, and did one block access? The sign-in record and policy results matter more than a user's interpretation of an error banner. An administrator must also plan access for recovery accounts while controlling their use and monitoring them carefully. Conditional Access makes a system adaptable to context, but that flexibility creates configuration dependencies that require documentation and repeated verification.

Zero Trust begins with continuous verification

Zero Trust is commonly summarized as verifying explicitly, using least privilege, and assuming breach. Those ideas are useful only when translated into actual controls. An organization cannot treat every request from an internal network as trustworthy, because an attacker may already control a workstation or identity. Access decisions should consider verified identity, device posture, session characteristics, and resource sensitivity. Segmentation and logging reduce the damage that follows a compromised account. The architecture should minimize persistent administrative permissions and make unusual activity observable. None of this means authenticating every click or eliminating all operational trust; it means making trust conditional and evidence-based.

A practical illustration is a finance employee opening a report from an unfamiliar device. The account might be genuine, but the device does not satisfy the control required for that classification of information. The system could block access or require a different access path. Now consider the same employee accessing a public internal announcement. That activity carries a different consequence and may justify a less restrictive user experience. SC-900 candidates should be able to reason about why a policy might differ, rather than memorizing a single supposed best configuration for all users and resources.

Privileged identity changes the risk equation

Administrators can alter identities, applications, security configuration, and sometimes the controls that audit their own behavior. Permanent broad privilege therefore creates concentrated risk. Privileged Identity Management concepts support eligible rather than constantly active assignments, time-bound elevation, approval workflows, and reviewable activation records. Separation of duties can prevent a single person from authorizing and completing a sensitive change. Emergency access remains necessary, but it must be designed for extraordinary use, protected from ordinary compromise paths, and reviewed afterward. These controls should be selected according to the consequences of an account being misused, not by assigning every employee the same procedure.

The SC-300 identity administration exam goes much deeper into configuring identities, access, and governance. SC-900 asks for a sound conceptual distinction: a privileged role determines powerful permissions, while an elevation process controls when those permissions become active and under what conditions. Access reviews address whether continuing permission is justified. Audit logs describe what happened; they do not themselves prevent a harmful administrative change. A mature design links eligibility, activation, oversight, and timely revocation into an understandable sequence.

Governance closes the lifecycle, not just the sign-in screen

Identity security is incomplete if provisioning works but deprovisioning does not. The retailer's seasonal employees need access at the beginning of a contract, role adjustments if they move teams, and reliable removal after the engagement ends. Guest users should have accountable sponsors and review dates. Applications likewise need owners who understand what permissions have been consented to and when credentials or integrations should be retired. The biggest weaknesses often sit between HR, IT, and application administrators rather than inside a single authentication setting. A joiner-mover-leaver process must therefore communicate authoritative changes to every relevant system.

Access governance also needs evidence. An auditor may ask who approved access to a sensitive application, whether the current membership still matches business needs, and which controls applied to privileged operations. Reconstructing those answers from scattered emails is unreliable. Ownership records, review decisions, sign-in evidence, and documented exceptions create a defensible trail. This is not the same as collecting logs indefinitely; retention and access to evidence should themselves reflect legal, privacy, and operational requirements. Security architecture should make reasonable oversight possible without exposing sensitive identity data to unnecessary audiences.

Put SC-900 concepts into operational scenarios

A useful study exercise is to create a matrix for an ordinary employee, external vendor, unattended workload, and privileged administrator. For each, identify how identity is established, what authentication is appropriate, who grants authorization, how access is reviewed, and what ends it. Then introduce a change: the vendor contract expires, the employee loses a device, or a privileged account exhibits unusual sign-in activity. Determine which control responds first and which team has to investigate. This exposes the gaps between knowing terminology and actually understanding cause and effect.

Microsoft has scheduled an English-language SC-900 objective update for October 21, 2026. Candidates testing before or after that date should consult the version of the official study guide that applies to their appointment, including localized exam differences where relevant. The underlying identity logic remains stable: know the actors, authenticate them appropriately, authorize only the necessary actions, evaluate contextual risk, and revoke access when its purpose ends. That reasoning lets a learner answer unfamiliar scenarios without reducing identity security to a brand-name matching exercise.