SC-900: Identity, Security, and Compliance Concepts
SC-900 is a fundamentals exam, but “fundamentals” does not mean memorizing a disconnected list of Microsoft products. The exam is easier to reason about when identity, security, and compliance are treated as parts of one control system: identity establishes who or what is requesting access, security controls and observes risk, and compliance defines obligations and the evidence that demonstrates how information is governed.
The current SC-900 uses the July 28, 2026 skills map. The heaviest domain is Microsoft security solutions, followed by Microsoft Entra and Microsoft compliance solutions, while the opening concepts domain provides the vocabulary that connects them. Microsoft has announced another English-language update for October 21, 2026, so candidates testing on or after that date should recheck Microsoft Learn before final review. The broader Microsoft security path shows why SC-900 is designed as a conceptual foundation rather than an administrator exam.
A good SC-900 answer therefore starts with the problem being solved. Is the requirement about establishing identity, controlling access, protecting workloads and data, detecting threats, managing posture, retaining information, or proving compliance? Once the category is clear, the Microsoft service becomes easier to place.
Cloud services change who operates physical facilities, hardware, hypervisors, and parts of the platform, but they do not remove customer accountability. The shared responsibility model helps candidates determine which security tasks stay with Microsoft and which stay with the organization. The exact boundary changes across SaaS, PaaS, and IaaS, yet identities, data classification, access decisions, configuration, and many governance obligations remain customer responsibilities.
The exam often tests reasoning rather than a single diagram. Moving from on-premises infrastructure to a SaaS service usually reduces responsibility for servers and operating systems, but poor identity governance or excessive sharing can still expose sensitive data. A useful rule is to ask who can realistically control the setting in question. Microsoft secures the underlying cloud, while customers configure and use cloud services securely.
A fundamentals-level decision should also ask who owns each control after a service is adopted. Moving from on-premises infrastructure to cloud services can shift responsibility for physical security and platform maintenance while leaving identity configuration, data classification, access policy, and many compliance obligations with the customer. SC-900 scenarios become clearer when responsibility is mapped control by control instead of assuming that “cloud” automatically transfers security ownership.
Zero Trust assumes that network location alone should not create trust. The familiar principles—verify explicitly, use least privilege, and assume breach—change how organizations evaluate access requests and design controls. Identity, device condition, application, data sensitivity, location, and risk signals can all contribute to an access decision.
This matters for SC-900 because several Microsoft capabilities implement pieces of Zero Trust, but no single license switch “turns on Zero Trust.” Microsoft Entra can contribute identity and access signals; Defender products contribute threat and workload protection; Purview contributes data and compliance context. Candidates should identify the principle first, then recognize which services help apply it.
Identity answers who a user, workload, application, or device claims to be and provides the foundation for authentication and authorization. Authentication validates an identity claim. Authorization determines what that authenticated identity may do. The difference is fundamental: a user can authenticate successfully and still be denied access because authorization policy does not permit the requested action.
Microsoft Entra ID provides cloud identity and access management, while features such as multifactor authentication, Conditional Access, identity governance, and privileged identity controls strengthen how access is evaluated over time. SC-900 stays at concept level, so candidates should understand what these capabilities accomplish rather than memorize implementation steps.
Defense in depth combines multiple layers so one failure does not immediately become a compromise. Physical security, identity controls, network protection, endpoint safeguards, application security, and data protection can all reduce risk at different points. The layers should be complementary; duplicating the same weak control does not create meaningful depth.
Encryption and hashing fit into this model in different ways. Encryption is reversible with the appropriate key and protects confidentiality. Hashing is designed to produce a one-way representation useful for integrity and certain verification scenarios. Candidates should avoid treating the terms as synonyms simply because both transform data.
Security operations often focuses on events and active threats, while posture management focuses on the current condition of configurations, exposures, recommendations, and control coverage. Microsoft Defender for Cloud and related capabilities help organizations assess cloud-security posture and workload protection, while Secure Score-style measurements can help prioritize improvements.
A posture score should not be mistaken for proof that an environment is secure. Measurements are decision aids. Teams still need to understand the underlying recommendation, business context, compensating controls, and implementation risk. SC-900 questions may test which capability provides a posture-oriented view versus which one investigates or responds to active security events.
Microsoft security solutions include products that protect and investigate different parts of the environment. Defender capabilities can contribute endpoint, identity, email/collaboration, cloud-app, and cloud-workload signals, while Microsoft Sentinel provides cloud-native SIEM and security orchestration capabilities for collecting, correlating, investigating, and responding to security data.
The key fundamentals distinction is between preventing or detecting threats at a control point and aggregating security operations across many sources. A product that protects an endpoint is not the same thing as a SIEM, even though its alerts can feed the SIEM. Thinking in terms of signal source, detection, correlation, investigation, and response keeps the roles clear.
Compliance describes how an organization meets legal, regulatory, contractual, and internal requirements. Microsoft Purview provides capabilities that help govern data, manage risk, support records and retention, discover sensitive information, and address compliance workflows. These tools support compliance; they do not automatically make an organization compliant.
That distinction matters because policies require business interpretation. A retention rule must reflect an actual requirement. A sensitivity label must correspond to meaningful handling expectations. An eDiscovery process requires governance and legal decisions. Technology can apply and document controls, but responsibility for defining appropriate policy remains with the organization.
Governance establishes direction, accountability, policies, and decision rights. Risk management identifies uncertainty and decides how it should be treated. Compliance evaluates obligations and whether required controls are followed. A mature program connects all three: governance sets expectations, risk prioritizes effort, and compliance provides evidence about required behavior.
SC-900 may use Microsoft capabilities to illustrate these concepts, but the concepts remain broader than the tools. Data governance can involve classification, ownership, retention, access, and lifecycle. Risk can involve users, applications, devices, or business processes. Compliance can require assessment, documentation, audit evidence, and remediation. Recognizing the category prevents product-name guessing.
A useful study method is to map every service or feature to the question it primarily answers. Microsoft Entra: who and under what access conditions? Defender: what threats or exposures affect the environment? Sentinel: how are security signals aggregated, investigated, and orchestrated? Purview: how is information governed, protected, retained, discovered, and evaluated against policy?
That model is more durable than memorizing marketing descriptions because Microsoft can rename or reorganize product portfolios while the security problems remain. For SC-900, the goal is to understand the architecture of trust, protection, visibility, and compliance well enough to select the correct family of capabilities without drifting into specialist-level configuration.
Fundamentals questions also become easier when candidates separate preventive, detective, and governance functions. Multifactor authentication can reduce the chance that a stolen password becomes an account compromise. A detection platform can surface suspicious activity after signals appear. A compliance policy or retention requirement can define how information must be handled over time. These are related controls, but they answer different questions. When a scenario asks what reduces unauthorized sign-in risk, what detects suspicious behavior, or what proves information was retained according to policy, the control category should be identified before the product name.
Data protection provides another useful bridge between security and compliance. Encryption can protect confidentiality in transit or at rest, while classification and sensitivity labeling express how information should be handled. Data-loss prevention can act on those classifications or content patterns to reduce inappropriate sharing. Retention controls address how long information should remain available. The important point is that confidentiality, loss prevention, and retention are different objectives even when the same data is involved. SC-900 often rewards recognizing that distinction.
Identity governance is similarly broader than authentication. A user may authenticate correctly but still hold access that is no longer justified after a role change. Access reviews, entitlement processes, privileged access controls, and lifecycle governance help organizations decide whether access should continue. This is why identity belongs in governance as well as security: access must be created, changed, reviewed, and removed according to business need rather than left in place indefinitely.
Finally, candidates should remember that Microsoft services can exchange signals. Identity risk can influence access decisions; endpoint or email detections can contribute to investigations; security operations can correlate multiple signals; information-protection context can shape how sensitive content is handled. The architecture is interconnected, but each service still has a primary role. Exam scenarios become much easier when the candidate asks which layer owns the decision being described.
SC-900 becomes manageable when identity, security, and compliance are treated as connected control layers rather than separate product lists. Start from the requirement, identify the security or governance function, then map that function to the appropriate Microsoft capability. That reasoning mirrors the fundamentals role the exam is meant to validate.
A useful final check is to ask which concept a scenario is testing before focusing on product names. If the problem is identity assurance, data governance, threat protection, or compliance evidence, the right answer should first fit that control objective; the Microsoft service is the implementation context. This prevents memorized branding from replacing the fundamentals that SC-900 is designed to measure.
