Microsoft SC-900 Security, Compliance, and Identity Fundamentals Readiness Guide: How to Evaluate Skills Across the Current Exam Domains

 

SC-900 is a fundamentals certification, but the current exam expects more than recognition of Microsoft security product names. The skills measured from July 28, 2026 place the largest emphasis on Microsoft security solutions, followed by Microsoft Entra capabilities, compliance capabilities, and foundational security, compliance, and identity concepts. A candidate should be able to take a business or security statement and identify which layer of the Microsoft ecosystem addresses it, while keeping basic principles such as Zero Trust, least privilege, shared responsibility, and governance in view.

The exam is best approached as a map of responsibilities. Some controls establish identity. Others protect cloud workloads, networks, endpoints, applications, or data. Some detect and investigate threats. Others help an organization classify information, apply retention or data-loss controls, and produce compliance evidence. If you learn these capabilities as isolated feature lists, similar-sounding answer choices become difficult. If you learn what problem each layer solves, the architecture becomes much easier to reason about. The SC-900 study guide is useful for broad exam orientation; this guide focuses on proving readiness domain by domain.

Use a readiness scale based on explanation quality

At Level 0, you recognize a term such as Conditional Access, Microsoft Defender for Cloud, or Microsoft Purview. At Level 1, you can define it. At Level 2, you can select it in a simple scenario and distinguish it from a neighboring capability. At Level 3, you can explain how the control fits a larger security or compliance objective and name a condition that would change your choice. For SC-900, you want at least Level 2 across the blueprint and Level 3 on the core distinctions that connect identity, threat protection, and information governance.

A useful test is to answer without product slogans. Instead of saying “Defender for Cloud provides cloud security,” explain that it helps assess and improve security posture and provides workload protection capabilities across cloud resources. Instead of saying “Purview is compliance,” explain that Purview capabilities help discover, classify, govern, protect, and investigate information and support compliance workflows. Precise purpose beats memorized marketing language.

Domain 1: understand shared responsibility before individual controls

Cloud security begins with shared responsibility. Moving to a cloud service changes which tasks the provider operates and which remain with the customer, but it does not make the customer’s security responsibilities disappear. The exact split differs across infrastructure, platform, and software services. As more of the stack is managed by the provider, customers generally retain responsibility for areas such as identities, access decisions, data, configurations, and the way services are used.

SC-900 readiness means you can reason about that shift. If an organization uses a SaaS application, it does not patch the underlying host, but it still decides who can access business data and how information should be protected. If it runs virtual machines, it owns more configuration and guest-system responsibility. A scenario may ask who is responsible for a task; answer from the service model rather than from the vague assumption that “Microsoft secures Azure.”

Understand defense in depth as layered risk reduction

Defense in depth means relying on multiple protective layers so that the failure of one control does not automatically expose the asset. Typical layers include physical security, identity, perimeter or network controls, compute, application safeguards, and data protection. The exact diagram is less important than the principle: strong security does not depend on one firewall, one password, or one endpoint product.

A readiness exercise is to take a sensitive application and list independent protections. Strong authentication reduces account takeover risk. Conditional Access can enforce context-based requirements. Network controls limit exposure. Application security reduces exploitability. Encryption protects data under defined conditions. Monitoring and incident response improve detection and containment. If you can explain how the layers complement rather than duplicate each other, the concept is secure.

Zero Trust is a decision model, not a product

Zero Trust is commonly summarized through principles such as verify explicitly, use least privilege, and assume breach. The important exam skill is understanding how those principles affect access decisions. An identity should not receive broad access merely because it is inside a corporate network. Decisions can consider user, device, application, location, risk, requested resource, and other signals. Access should be limited to what is necessary and reevaluated as conditions change.

Do not treat Zero Trust as the name of a single Microsoft service. Microsoft Entra, Defender products, network controls, device management, and data-protection capabilities can all support a Zero Trust strategy. If a question asks which principle is being applied when access is restricted to the minimum needed, think least privilege. If it describes continuous evaluation of context rather than trusting network location, think explicit verification and assumed compromise.

Understand the relationship among identity, authentication, and authorization

Identity represents an entity such as a user, workload, application, or device. Authentication establishes that the entity is who or what it claims to be. Authorization determines what an authenticated entity is allowed to do. These concepts are related but not interchangeable. A user can authenticate successfully and still be unauthorized to open a sensitive resource.

SC-900 questions often become easier when you identify which stage is failing. A passwordless method or multifactor authentication concerns authentication strength. A role assignment or access policy concerns authorization. Microsoft Entra ID provides identity and access capabilities that connect these stages, but understanding the concepts independently prevents feature-name confusion.

Know why multifactor authentication matters

Multifactor authentication combines evidence from different factor categories so that a stolen password alone is insufficient. It reduces the risk of credential compromise but should not be described as eliminating account takeover. Attackers can still use phishing, token theft, social engineering, malware, or other techniques, which is why layered controls matter.

For readiness, focus on the purpose: strengthen authentication. If the question asks how to reduce reliance on passwords, consider passwordless approaches. If it asks how to require stronger verification under certain conditions, Conditional Access can help enforce policies that include authentication requirements. Do not confuse the authentication method with the policy engine that decides when it is required.

Microsoft Entra ID is the identity foundation

Microsoft Entra ID is Microsoft’s cloud identity and access management service for users, groups, applications, and other identities. It supports authentication, single sign-on, application access, identity governance integrations, Conditional Access, and related capabilities. SC-900 expects you to understand its role in controlling access across Microsoft cloud environments and connected applications.

A good readiness test is to distinguish directory identity from resource authorization. Entra establishes and manages identities and can enforce access policies, while Azure role-based access control determines what authenticated principals can do to Azure resources within defined scopes. The technologies work together, but they solve different parts of the access problem.

Conditional Access is policy based on signals and requirements

Conditional Access evaluates signals and enforces access controls according to policy. Signals can include user or group, application, device state, location, risk, and other context. Controls can require stronger authentication, compliant devices, or other conditions. The key is that access is conditional rather than based only on a successful username-and-password event.

Avoid a common mistake: Conditional Access is not itself an authentication factor. It is a policy system that can require specific authentication strength or other controls. If an exam scenario describes “require MFA for administrators from risky contexts,” identify the policy decision separately from the MFA method it invokes.

Understand external identities and federation conceptually

Organizations often collaborate with partners, contractors, or customers who are not internal employees. External identity capabilities support controlled access for people outside the primary organization. Federation allows trust relationships in which identities can authenticate through an external identity provider rather than creating a completely separate credential lifecycle in every environment.

At fundamentals level, focus on why these patterns exist: reduce duplicate identities, improve collaboration, and preserve control over resource access. The resource organization still decides what the external identity is allowed to do. Authentication source and authorization target are related but distinct.

Domain 3: distinguish posture management from threat protection

Security posture management asks whether resources are configured according to good security practices and where risk exists. Workload protection focuses more directly on detecting or defending against threats affecting servers, containers, databases, storage, and other workloads. Microsoft Defender for Cloud spans cloud security posture and workload-protection capabilities, which is why it appears in scenarios about improving cloud-resource security.

A candidate should be able to distinguish “find and remediate insecure cloud configurations” from “investigate a suspicious sign-in” or “correlate incidents across endpoints and identities.” Different Microsoft security products address different layers. Start with the protected asset and desired action before choosing a product.

Recognize common Azure network security controls

Azure network security includes capabilities such as network security groups, Azure Firewall, web application firewall, DDoS protection, and Azure Bastion. They are not interchangeable. Network security groups filter network traffic at defined scopes. Azure Firewall provides centralized network firewall capabilities. Web Application Firewall protects web applications from common web attacks at the application layer. DDoS Protection helps mitigate distributed denial-of-service attacks. Bastion provides secure remote access to virtual machines without directly exposing management ports through public IP addresses.

For exam readiness, match the threat or access need to the layer. Protecting a web app from malicious HTTP requests is different from filtering general network flows. Secure administrative access is different from DDoS mitigation. If you can state the layer each control protects, many distractors disappear.

Understand Key Vault as protected secret and key storage

Azure Key Vault helps securely store and control access to secrets, keys, and certificates. The fundamental problem it solves is avoiding unsafe secret handling such as hard-coded credentials in source code or configuration files. Access to a vault should itself be controlled through identity and authorization.

Do not describe Key Vault as a general-purpose document repository or identity provider. It protects cryptographic and secret material used by applications and administrators. In a scenario that says “the application must retrieve a database secret without embedding it in code,” protected secret storage is the relevant concept.

Microsoft Defender XDR connects signals across security domains

Microsoft Defender XDR brings together extended detection and response across signals such as endpoints, identities, email, applications, and cloud apps to help security teams detect, investigate, and respond to attacks. The exam-level distinction is that it provides a correlated security view across multiple Microsoft Defender products rather than serving as a network firewall or compliance catalog.

If a scenario emphasizes a multi-stage attack that crosses endpoint, identity, and email signals, correlation and incident investigation are central. If it asks to assess Azure resource posture, Defender for Cloud is a closer fit. If it asks to collect and analyze broad security logs from many sources in a SIEM, Microsoft Sentinel is more relevant. Know the purpose boundary.

Microsoft Sentinel is SIEM and security orchestration

Microsoft Sentinel is a cloud-native security information and event management platform with security orchestration, automation, and response capabilities. It ingests security data from many sources, supports analytics and detection, helps investigate incidents, and can automate response workflows. The key exam clue is broad security monitoring and correlation across an environment.

Do not reduce Sentinel to “a place for logs.” The security value comes from using those logs and signals to detect and investigate threats. Conversely, do not choose Sentinel for a question whose primary concern is configuring a firewall or classifying sensitive documents. Identify whether the problem is security operations, preventive control, identity, or compliance.

Domain 4: compliance starts with knowing the information

Information protection begins with understanding what data exists and how sensitive it is. Microsoft Purview capabilities can help discover and classify information, apply sensitivity labels, and support policies that govern how information is handled. Labels express business meaning such as confidentiality and can trigger protection or handling requirements depending on configuration.

A fundamentals candidate should understand the difference between identifying sensitive information and investigating an active cyberattack. Both matter to security, but they use different toolsets. Purview is strongly associated with information protection, data governance, compliance, and risk workflows rather than endpoint threat detection.

Data Loss Prevention is about controlling risky data movement

Data Loss Prevention policies help detect sensitive information and prevent or warn against inappropriate sharing or transfer in supported locations. The central question is not merely whether the data is confidential, but how policy should respond when users or processes attempt risky actions. DLP can support education, warning, or blocking depending on the context and configuration.

For readiness, distinguish DLP from encryption and access control. Encryption protects data under defined cryptographic conditions. Access control determines who can access a resource. DLP evaluates content and activity to reduce unintended or prohibited disclosure. A mature design can use all three together.

Retention is different from backup

Retention policies and labels help organizations keep or delete content according to business, legal, or regulatory requirements. Backup focuses on recovering data after loss or corruption. The two can overlap in business outcomes but are not the same function. Keeping a record for seven years because regulation requires it is a retention problem, not simply a backup schedule.

Exam scenarios may use wording such as “must retain records for a required period” or “must delete content after a policy-defined time.” Those phrases point toward records and retention capabilities. If the need is to restore accidentally deleted operational data, think recovery rather than compliance retention.

eDiscovery supports legal and investigative workflows

Electronic discovery capabilities help organizations identify, preserve, collect, review, and export electronic information relevant to legal or internal investigations. At SC-900 level, recognize the purpose rather than implementation procedure. A request from legal counsel to preserve and search communications related to a case is an eDiscovery scenario, not a threat-detection or DLP problem.

The distinction matters because several compliance tools interact with the same data. Retention preserves content under policy. DLP reduces risky disclosure. eDiscovery helps locate and manage content for investigations. Audit records user and administrative activity. Know the question being asked of the data.

Audit supports accountability and investigation

Audit capabilities record activities so organizations can understand who did what and when. Audit data can support investigations, compliance evidence, operational troubleshooting, and accountability. It does not prevent every bad action, but it helps make activity observable.

A strong readiness answer distinguishes an audit trail from an access policy. If the requirement says “prevent unauthorized access,” authorization controls are primary. If it says “determine which administrator changed the setting,” audit data is central. Security controls can be preventive, detective, or investigative; understand the role requested by the scenario.

Compliance Manager helps assess compliance posture

Microsoft Purview Compliance Manager helps organizations assess compliance against standards or regulations, track improvement actions, and understand responsibilities. The exam-level concept is compliance posture and evidence management, not automatic certification. A tool can help assess and organize compliance work; it does not make an organization compliant simply because it is enabled.

Watch for wording that asks how to measure progress against a compliance framework or manage recommended actions. That is different from protecting an endpoint, configuring an identity, or preventing sensitive data from leaving a location.

Build a product-boundary map

Create a one-page map with four questions. “Who are you?” points toward Entra and authentication. “What can you access?” points toward authorization and access policies. “What is attacking or misconfigured?” points toward security controls and Defender/Sentinel capabilities. “What data must be protected, governed, retained, or investigated?” points toward Purview and compliance tools. This map is simplified, but it gives you a reliable first classification.

Then add exceptions and overlaps. Defender for Cloud can contribute to regulatory compliance views while remaining primarily a cloud-security platform. Identity signals can feed security operations. Purview data protection can support security objectives. The goal is not rigid silos; it is knowing the primary purpose of each capability before considering integration.

Use practice questions to test the reason for every choice

When you work through SC-900 practice questions, explain each answer with a “because” statement. “Conditional Access, because the requirement is to make access depend on contextual signals.” “Sentinel, because the requirement is SIEM-style security monitoring and correlation across sources.” “Purview DLP, because the goal is to control inappropriate movement of sensitive content.” If your reason is merely “I remember that name,” the knowledge is fragile.

For each incorrect answer, state what that product actually does and why it does not fit the scenario. This is critical for SC-900 because Microsoft security services overlap at the edges. Learning the boundaries between them is more valuable than memorizing another list of features.

Create scenarios that cross domains

A realistic security problem rarely stays in one domain. Suppose an administrator account is phished, a suspicious sign-in occurs, sensitive files are downloaded, and the activity must be investigated. Identity controls determine authentication and access. Defender products may provide threat signals. Sentinel may correlate broader telemetry. Purview can help protect or investigate sensitive information. Audit records may support the timeline. The answer to an exam question depends on which step it asks about.

Practice underlining the action verb: require, detect, investigate, classify, retain, block, assess, monitor, or authorize. Then identify the asset: identity, Azure resource, endpoint, network, email, application, or information. Action plus asset often reveals the correct product category.

Final domain-by-domain self-assessment

For security concepts, you should explain shared responsibility, defense in depth, Zero Trust, least privilege, encryption basics, and governance. For identity, you should explain Entra ID, authentication, MFA, passwordless concepts, Conditional Access, external identities, and the separation of authentication from authorization. For Microsoft security solutions, you should place network controls, Key Vault, Defender for Cloud, Defender XDR, and Sentinel correctly. For compliance, you should distinguish information protection, DLP, retention, eDiscovery, audit, and compliance assessment.

Use the Microsoft certification training hub to place SC-900 in context if you intend to continue into role-based Microsoft security certifications. But do not let the next certification distract from this exam’s level: SC-900 rewards clear conceptual mapping more than deep configuration syntax.

Final readiness standard

You are ready when a new scenario can be classified before you look at the answer choices. You should be able to identify whether the central problem is identity, authorization, network protection, workload posture, threat detection, security operations, information protection, retention, investigation, or compliance assessment. Then you should be able to name the Microsoft capability that fits and explain why a nearby option is less appropriate.

The strongest sign of readiness is that product boundaries feel logical rather than arbitrary. You know why Sentinel is not a firewall, why Conditional Access is not an authentication factor, why retention is not backup, and why Purview DLP is not the same as an access-control list. That conceptual precision is what turns a fundamentals syllabus into usable security knowledge.

Distinguish encryption at rest, in transit, and in use conceptually

Encryption discussions become clearer when you ask when the data is being protected. Encryption at rest protects stored data on disks or in persistent storage. Encryption in transit protects data as it moves across networks. Technologies that protect data during processing address a different state. SC-900 is a fundamentals exam, so the important skill is understanding that one encryption control does not automatically cover every state of data.

Also separate encryption from hashing. Encryption is designed so authorized parties can recover the original data with appropriate cryptographic material. Hashing is a one-way transformation commonly used for integrity checks and secure representations of values such as passwords when combined with appropriate password-storage practices. If a scenario asks for confidentiality of transmitted information, hashing is not a substitute for encrypted transport. If it asks to verify that content was not changed, integrity mechanisms become more relevant.

Understand role-based access control as scoped authorization

Azure role-based access control assigns permissions through roles at defined scopes such as a management group, subscription, resource group, or resource. The same identity can therefore have different authority in different parts of an Azure environment. The fundamentals idea is that authorization should be granted according to job responsibility and constrained to the smallest practical scope.

This is where least privilege becomes operational. Giving every operator Owner rights at the subscription level is easy but unnecessarily risky. A more appropriate role at a narrower scope reduces blast radius. For exam readiness, distinguish Azure RBAC from directory roles and from Conditional Access. All influence access, but they answer different questions: what can a principal do to Azure resources, what administrative role does it have in the identity system, and under what conditions can it access a cloud application?

Separate security posture from secure score-style guidance

Security posture is the overall condition of an environment: configurations, exposures, vulnerabilities, controls, and practices that affect risk. Microsoft services can provide assessments and recommendations that help teams identify weaknesses and prioritize improvement. A score or recommendation should be treated as guidance, not as proof that an environment is secure. Raising a score without understanding the underlying control can lead to checkbox behavior.

A good SC-900 answer therefore focuses on purpose. If the organization wants to assess cloud resources against security recommendations and improve configuration, posture-management capabilities are relevant. If the organization needs to investigate an active incident, a different security-operations capability is required. The same environment can use both; the exam asks you to identify which objective is central in the described moment.

Distinguish preventive, detective, and corrective controls

Preventive controls attempt to stop an unwanted event: strong authentication, access restrictions, network filtering, and DLP blocking can all serve preventive roles. Detective controls reveal suspicious or noncompliant activity through logs, alerts, and analytics. Corrective controls help restore or remediate the environment after a problem is identified. Some Microsoft capabilities participate in more than one category, but the classification helps you understand the outcome a scenario is asking for.

Suppose a question says administrators need to know when suspicious activity occurs across many systems. That points toward detection and security operations rather than another preventive firewall rule. If it says users must be stopped from sharing classified files externally, DLP or information-protection controls are more directly relevant. Train yourself to identify the control objective before the product.

Understand governance as decision ownership

Governance establishes how an organization makes and enforces decisions about technology, risk, data, and accountability. It includes policies, standards, roles, review processes, and evidence. Compliance is related but narrower: it concerns meeting specific legal, regulatory, contractual, or internal requirements. An organization can be technically compliant with a narrow requirement and still have weak governance, or have a strong governance program that manages many obligations at once.

This distinction helps with SC-900 questions that mention risk management, policies, standards, and regulatory evidence. Microsoft tools can support governance and compliance workflows, but the organization still owns decisions about classification, retention periods, acceptable risk, access rules, and response procedures. Technology enforces or measures policy; it does not invent the business policy on its own.

Run a ten-minute mixed-domain drill

Take ten minutes and write one scenario for each of these actions: authenticate a user, authorize an Azure resource action, require stronger access conditions, protect a web application, store an application secret, detect threats across endpoints and identities, aggregate security events, classify confidential information, stop risky data sharing, retain a regulatory record, and investigate user activity. Then map each scenario to the relevant Microsoft capability and explain one plausible distractor.

The exercise exposes weak boundaries quickly. If you repeatedly confuse Sentinel with Defender XDR, study the difference between broad SIEM/SOAR operations and extended detection and response across Microsoft security signals. If you confuse Conditional Access with RBAC, revisit conditional admission versus resource permissions. If you confuse eDiscovery with audit, revisit legal content workflows versus activity records. Ten minutes of targeted distinction work can be more valuable than another hour of passive reading.

Keep fundamentals answers proportionate to the question

SC-900 often rewards the simplest capability that directly satisfies the requirement. Do not add an incident platform when the question only asks for stronger authentication, or a compliance product when the stated need is network filtering. Read every qualifier, identify the requested outcome, and choose at the correct architectural layer. This prevents overengineering and keeps product overlap from becoming confusing.