Microsoft SC-900: Identity, Compliance and Cloud Security Foundations

The SC-900 Security, Compliance, and Identity Fundamentals exam is often approached as a tour of Microsoft product names. That is the least durable way to learn it. The important subject is how trust works in a cloud environment: who establishes an identity, how access decisions are made, who owns responsibility for a control, and why protecting or retaining information is not the same as keeping a service online. Within Microsoft certifications, SC-900 provides vocabulary for people who must work with security teams even if they do not administer every control themselves.

Imagine a small company moving email, file sharing and several applications into Microsoft 365 and Azure. Its director asks whether the cloud provider now handles security, whether multifactor authentication is enough, and whether confidential files can be stopped from leaving the company. Each question combines several controls and a business decision. Microsoft has announced updates to the SC-900 objectives for later in October 2026; that announced revision is not the same as the objectives effective on October 10. Preparation should follow the official study guide aligned to the actual examination date, with concepts taking priority over screenshot memorization.

Understand what cloud security responsibility means

The shared responsibility model explains why moving infrastructure does not transfer every risk to the service provider. Microsoft maintains the physical facilities and much of the underlying infrastructure, while the customer remains responsible for information, identities and its own configurations. The division varies between infrastructure, platform and software services. A hosted mailbox reduces the customer’s server-maintenance burden, but the customer still decides whether former employees retain access and whether sensitive attachments can be sent externally. Describing these boundaries is more valuable than repeating the phrase 'shared responsibility' without consequences.

Security principles become clearer when contrasted. Confidentiality concerns unauthorized disclosure, integrity concerns improper alteration, and availability concerns whether authorized people can use a service. An encryption key helps confidentiality, but a lost key may harm availability. A backup supports recovery but cannot establish whether an unauthorized administrator changed a record before the backup ran. Treat the principles as competing engineering requirements in specific situations. A finance service might require tightly limited modifications, quick restoration and auditable access; one setting will not provide all three.

The zero-trust approach replaces assumptions based on a trusted network perimeter with explicit verification, least privilege and attention to possible compromise. A user inside the office can still have a stolen credential or infected device. Likewise, a contractor working remotely should not be denied purely because of geography when policy can evaluate identity, device risk and the application requested. Zero trust is an architectural method, not one license or toggle. Explain how a proposed control limits access or detects misuse, and which uncertainty remains after it is in place.

Defense in depth recognizes that controls will sometimes fail. Authentication may stop many unauthorized users, but an application bug or excessive database permission can still expose information. Segmentation, hardening, monitoring, encryption and response planning are useful because they protect different failure modes. A mature analysis does not claim that adding more layers always increases safety; conflicting policies, unowned alerts and untested exceptions can make a system less manageable. The goal is several coherent barriers with visible ownership, not a collection of independent dashboards that nobody reviews.

Follow identity from registration to permission

Microsoft Entra ID provides identity and access capabilities used across cloud applications. A directory account is a representation of a person or workload, whereas authorization determines which resources it may use. Authentication verifies a claim about identity; authorization decides what follows from that claim. A user can successfully sign in yet be denied a particular SharePoint document. Conversely, a service principal can possess powerful application permissions without any employee interactively signing in. These distinctions matter when investigating an access complaint because the apparent symptom can originate at different stages.

Multifactor authentication requires additional evidence beyond one credential, but factors differ in resilience. A password paired with a mobile push prompt is not identical to a phishing-resistant passkey or security key. Security questions and simple patterns do not become separate factors merely because a user enters them in separate screens. Plan enrolment, replacement of lost authenticators and support exceptions before forcing a new method across a workforce. SC-900 generally tests conceptual understanding rather than exhaustive administration, yet a scenario may still ask which authentication approach reduces an identified threat.

Conditional Access evaluates policies against user, application and contextual signals to decide what conditions govern access. A managed and compliant device may be required for a high-risk application, while a low-risk collaboration service may permit more flexible use. A policy is not always a simple allow-or-deny decision; grant and session controls can shape a sign-in and ongoing use. The user experience matters. If a rule breaks payroll processing on a deadline, the right remedy is to examine policy scope, device state and legitimate business needs, rather than permanently switching security off.

Role-based access control supports least privilege by assigning defined responsibilities instead of unrestricted administrative access. A person who needs to reset passwords should not automatically receive permissions to change subscription billing or security policy. Privileged Identity Management introduces the idea of eligible roles and time-limited activation, while access reviews help detect entitlements that outlive their business purpose. Governance is therefore a lifecycle: request, approve, grant, use, review and remove. SC-900 candidates should connect these verbs with risk rather than seeing roles as names to memorize for a multiple-choice test.

Distinguish protection from detection and response

Microsoft Defender offerings cover different security environments, including endpoints, identities, email and cloud workloads. Their names can change, and the underlying distinction matters more: a preventive configuration tries to reduce the opportunity for harm, while detection identifies a suspicious condition or behavior. A device sensor can report malicious activity; an application policy can block a dangerous action; incident response determines what to do when evidence accumulates. No single alert proves malicious intent, and the absence of an alert does not establish that every workload is safe.

Security operations centers need an organized picture of events. Microsoft Sentinel is a cloud-native security information and event management and response platform used to collect, correlate and investigate relevant telemetry. It does not invent trustworthy data from systems that are not logging their activity. A sign-in event, an endpoint detection and a storage access record have different meanings; correlation produces a useful lead only when analysts understand that context. For SC-900, know why organizations centralize monitoring, what an incident represents and why automation should remain controlled by reliable evidence and appropriate review.

Microsoft Defender for Cloud adds posture assessment and workload protection across supported cloud environments. A secure score or compliance recommendation can help prioritize changes, but the score is not a legal certification or an assurance that breaches cannot occur. A development subscription and a payroll production environment may contain the same configuration finding with vastly different consequences. Cloud posture information should guide investigation: what resource is affected, is exposure reachable, which identity owns the resource, and how quickly can the problem be repaired without creating an outage?

Compliance requirements introduce distinct obligations. A financial regulator, a contract and an organization’s internal policy might all impose controls, but they do not carry identical authority. Microsoft compliance tools can support the work through assessments, evidence collection and retention controls. Buying a licensed product does not make an organization compliant: it still needs lawful policies, appropriate roles and proof that requirements are implemented. This is important on foundational questions that ask whether a feature 'ensures compliance.' In most realistic settings, technical features support a compliance program rather than replace it.

Protect information through its entire lifecycle

Microsoft Purview provides information-protection, data-governance and compliance capabilities. Sensitive information types and classifiers help recognize content, while sensitivity labels can apply handling rules such as encryption and markings. A label is not always an instruction to retain a record, and retention is not always about confidentiality. For example, a contract might be confidential for commercial reasons but still subject to a required disposal schedule. Keeping those objectives separate avoids confusing information protection with records management in both exam questions and everyday business decisions.

Data loss prevention attempts to limit unsafe information movement based on defined policies. Consider an employee sending a spreadsheet containing customer data to a personal email address. The organization might block the transfer, warn the employee or allow an approved exception depending on the sensitivity, location and business context. Coverage differs across email, collaboration services and managed endpoints. DLP should not be imagined as an invisible, flawless barrier around every copy of information. The most effective program combines well-designed policies, meaningful exceptions and user education backed by consistent monitoring.

Retention, eDiscovery and audit answer related but different needs. Retention establishes how information is preserved or disposed of. eDiscovery helps identify and manage relevant records during a legal or investigative process. Audit logs provide evidence about actions but may not contain every detail investigators want. A company deciding to delete old employee records must account for normal retention, privacy requirements and active litigation holds. A broad 'keep everything forever' approach is not automatically safer: it increases privacy exposure, storage cost and the volume of material an attacker might access.

Information governance becomes harder when AI assistants and external apps retrieve enterprise files. A user may be allowed to ask a chatbot a question while not being authorized to read every document the chatbot could access. Model behavior cannot repair inappropriate SharePoint permissions or accidental publication of a sensitive site. Administrators must examine identity, content permissions, labeling and the permissions granted to connected applications. Foundational understanding is being able to ask who can read a piece of information, what may happen to it next, and which evidence would reveal an improper action.

To prepare effectively, build a concept map around a simple employee journey. The employee joins, receives an account, registers an authentication method, opens a company application, creates a sensitive file, reports a suspicious email, and eventually leaves. For every stage identify the underlying security principle, the relevant Microsoft capability and the human decision that technology cannot make alone. Test yourself by swapping scenarios: a contractor, a privileged administrator, an automated workload. If you can reason clearly about trust, access, prevention, detection and information governance, product-name questions become easier and real collaboration with security teams becomes substantially better.