Microsoft SC-900 - Microsoft Security Compliance and Identity Fundamentals

Microsoft defines Microsoft Entra ID (formerly Azure Active Directory) as “a cloud-based identity and access management (IAM) service” that “helps your employees sign in and access resources.” In SCI learning paths, Entra ID is positioned as the tenant’s identity provider (IdP) that authenticates users and issues tokens for applications using standards such as OpenID Connect, OAuth 2.0, and SAML, which applications then use to authorize access based on roles/claims. Microsoft further explains that Entra ID provides single sign-on, Conditional Access, MFA, and token-based authorization—all core IdP capabilities that govern who can access what across Microsoft 365, Azure, and thousands of SaaS apps.

By contrast, an extended detection and response (XDR) system refers to Microsoft Defender XDR, which focuses on incident detection, correlation, and response—not identity provisioning or token issuance. A security information and event management (SIEM) system refers to Microsoft Sentinel, which aggregates and analyzes logs and alerts—not primary authentication. An Azure management group is a governance scope used to organize subscriptions and apply policy/RBAC at scale; it is not an authentication/authorization service. Therefore, within Microsoft’s SCI scope, Microsoft Entra ID is an identity provider used to perform authentication (verifying identity and issuing tokens) and to enable authorization in applications and resources that consume those tokens.

Sensitive Information Types (SITs) support regular expressions (regex), which allow for custom pattern matching to detect sensitive content like credit card numbers, social security numbers, or custom identifiers. Regex is fundamental to the detection logic within SITs.

SCI Extract: " Sensitive information types use pattern matching techniques, including regular expressions, keyword matches, and checksums to identify sensitive data. "

In Microsoft 365, Data Loss Prevention (DLP) policies are designed to “help you identify, monitor, and automatically protect sensitive information” across services such as Exchange Online, SharePoint Online, OneDrive, and Microsoft Teams. Microsoft’s guidance explains that DLP uses sensitive information types—including built-in classifiers like Credit Card Number—to detect when content matches a defined pattern and then enforce protective actions. With DLP, you can create rules that trigger when email messages contain customer lists with credit card numbers, and choose actions to block the message, restrict access, or notify and educate users via policy tips and incident reports. Microsoft further notes that DLP “prevents the accidental sharing of sensitive information,” can require user justification to override, and supports granular conditions (e.g., number of matches, recipients internal vs. external) to ensure that only risky transmissions are stopped. By applying a DLP policy to Exchange with the Credit Card Number sensitive info type, an organization can block or quarantine outbound mail that includes those numbers, thereby reducing regulatory and data-exposure risk. Other options listed—retention policies, conditional access, and information barriers—serve different purposes (data lifecycle, access/authentication conditions, and restricting communication between groups) and do not inspect message contents for sensitive data. Hence, DLP policies are the correct control to restrict sending emails that contain customer lists and associated credit card numbers.

Microsoft’s hybrid identity guidance explains that Microsoft Entra Connect (formerly Azure AD Connect) is the tool used to synchronize identities from on-premises AD DS to a Microsoft Entra tenant, enabling hybrid identity. Microsoft states that hybrid identity is achieved by connecting your on-premises directory with your cloud directory so users have a single identity to access both environments. This does not require two Microsoft 365 tenants; rather, it requires one Microsoft Entra tenant integrated with your on-premises AD DS. For authentication models—Password Hash Synchronization (PHS), Pass-through Authentication (PTA), or federation (AD FS)—Microsoft specifies that directory synchronization is required so that user objects exist in Entra ID and can authenticate to cloud services while maintaining a consistent identity. Thus, Entra Connect is used to implement the synchronization underpinning hybrid identity; two M365 tenants are unnecessary; and synchronization between AD DS and Entra ID is required for authenticating hybrid identities across Microsoft cloud services.

The Service Trust Portal is Microsoft’s public-facing portal that centralizes how Microsoft manages privacy, compliance, and security for its cloud services. It provides independent audit reports, compliance guides, data protection resources, and details on Microsoft’s internal controls and practices. It’s the authoritative place to learn how Microsoft meets global, regional, and industry standards.

ï‚· Compliance Manager tracks only customer-managed controls. No

ï‚· Compliance Manager provides predefined templates for creating assessments. Yes

ï‚· Compliance Manager can help you assess whether data adheres to specific data protection standards. No

Microsoft Purview Compliance Manager is described as a feature that “helps you manage your organization’s compliance requirements” by giving you assessments, improvement actions, and a compliance score that “measures your progress in completing recommended actions” aligned to regulations and standards. The service does not track only customer-managed controls; Microsoft’s documentation clarifies that Compliance Manager includes “Microsoft-managed controls and customer-managed controls,” and it tracks both within each assessment to show overall posture. It also provides prebuilt (predefined) assessment templates for common regulations and industry standards so organizations can “create assessments from templates” such as GDPR, ISO/IEC 27001, and the Data Protection Baseline.

Importantly, Compliance Manager evaluates control implementation and improvement actions mapped to requirements; it does not scan or classify individual data to determine whether specific data items “adhere” to a standard. Instead, it helps you assess organizational compliance posture by tracking the status of controls, assigning actions, and recording evidence. Thus:

“Tracks only customer-managed controls” → No (it tracks Microsoft-managed and customer-managed).

“Provides predefined templates for creating assessments” → Yes (prebuilt templates are a core feature).

“Helps you assess whether data adheres to specific data protection standards” → No (it measures control/compliance posture, not data-level adherence).

Box 1: No

Compliance Manager tracks Microsoft managed controls, customer-managed controls, and shared controls. Box 2: Yes

Box 3: Yes

Microsoft describes Azure Policy as the built-in governance service that lets you “create, assign, and manage policies” to enforce organizational standards and “assess compliance at scale.” It continuously evaluates existing resources for compliance and can take effect-enforcement actions such as deny, append, or modify during create/update operations. Azure Policy “helps you audit and enforce your standards” across subscriptions and resource groups, and its compliance dashboard shows overall and per-policy compliance states for all resources. By contrast, Azure Blueprints focuses on orchestrating deployments of artifacts (such as policy assignments, role assignments, and templates) for new environments; Microsoft guidance positions Policy as the engine that evaluates and enforces those standards on existing resources. Sentinel is a SIEM/SOAR for security analytics, and Anomaly Detector is a Cognitive Service—not a governance/compliance enforcement tool. Therefore, to assess compliance and enforce standards for existing Azure resources, the prescribed control plane is Azure Policy with its evaluation cycle, initiative (policy set) support, and remediation tasks.

Microsoft describes Windows Hello for Business (WHfB) as replacing passwords with a device-bound credential: “Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or a PIN.” WHfB authenticators are biometric gesture or PIN unlocking an asymmetric key stored on the device (typically in the TPM). Microsoft clarifies that the PIN is not a password and is “local to the device” and used to unlock the user’s private key. Consequently, Yes—a PIN is a supported WHfB sign-in gesture.

Conversely, the Microsoft Authenticator app is a separate Azure AD (Microsoft Entra ID) authentication method (push notifications, TOTP, passwordless phone sign-in). It is not the WHfB credential; WHfB relies on keys/certificates on the device, not on the Authenticator app.

Finally, WHfB credentials are per-device: Microsoft states the credential is “tied to a device” and the private key never leaves the device, which means it does not roam/sync across a user’s different devices. Each device enrolls and provisions its own WHfB key and gesture. These statements from Microsoft SCI documentation lead to the outcomes: No / Yes / No.