SC-900 Microsoft Security Compliance and Identity Fundamentals Questions and Answers

Microsoft’s Zero Trust guidance in the Security, Compliance, and Identity (SCI) materials frames three core principles: “Verify explicitly,” “Use least-privilege access,” and “Assume breach.” The guidance explains that identity is the new control plane in cloud-based environments: identity becomes the primary security boundary, with access decisions evaluated continuously using signals such as user identity, device health, location, and risk. In Zero Trust, organizations must “verify explicitly”—that is, require strong authentication and explicit authorization for every access request, not just initial logon, and base decisions on the permissions and context presented. The model also directs organizations to “assume breach”, operating with the expectation that an attacker may already be inside the environment and therefore applying containment practices such as micro-segmentation, telemetry, and rapid detection and response. Conversely, the traditional notion of defining the perimeter by physical locations or network boundaries is explicitly rejected; the documentation emphasizes that network location is no longer a reliable trust signal and should not be treated as the primary boundary. Therefore, the statements that align with Microsoft’s Zero Trust principles are: Use identity as the primary security boundary (B), Always verify user permissions explicitly (C), and Always assume the user/system can be breached (D).

Azure Blueprints lets you define a repeatable set of artifacts—like ARM/Bicep templates, role assignments, and Azure Policy—that you can assign to multiple subscriptions to deploy resources and guardrails consistently.

documents: =

Microsoft’s Windows Hello for Business replaces passwords with strong, two-factor authentication that is tied to the device and unlocked with a user gesture. The Microsoft Learn description states that Windows Hello for Business “replaces passwords with strong authentication” and that “users sign in using a gesture, such as a PIN, facial recognition, or fingerprint.” It further clarifies that the credential is protected by the device’s secure hardware and that the gesture (PIN or biometric) unlocks the private key used to authenticate. The guidance explains that “biometrics (face or fingerprint) or a PIN” are supported as the user’s sign-in method, and that the PIN “is unique to the device” and does not roam, reducing attack surface.

By contrast, email verification and security questions are not authentication gestures for Windows Hello for Business. They are not listed as supported methods for unlocking the Hello for Business key or completing interactive sign-in to Windows. Therefore, the three supported Windows Hello for Business authentication methods from the options provided are fingerprint, facial recognition, and PIN. This aligns with Microsoft’s documented model where the user enrolls a biometric (face or fingerprint) or creates a PIN, and subsequently uses that gesture to unlock the hardware-bound credential for secure sign-in and access to resources.

Microsoft sets out clear privacy principles for Microsoft 365 and Microsoft cloud services. In Microsoft’s privacy commitments, Microsoft states that customers control their data: “You control your data.” Microsoft also pledges transparency about data practices: “We are transparent about data collection and use.” These two commitments are among the core privacy principles articulated across Microsoft 365 privacy and Microsoft Purview documentation, which emphasize customer choice, clear explanations of data processing, and admin capabilities to access, export, and delete data. Additional Microsoft privacy principles often listed alongside these include security of your data, strong legal protections, no content-based targeting, and benefits to you, but the key point for this question is that Control and Transparency are explicitly called out as privacy principles.

By contrast, shared responsibility is not a privacy principle; it is a cloud security model used in Azure/Microsoft cloud guidance. That model explains that security is a shared responsibility between Microsoft (for the cloud infrastructure) and the customer (for their data, identities, endpoints, and configurations). It describes how duties are divided for protecting services and workloads, not a privacy promise to end users. Therefore, the correct selections are Yes for Control and Transparency, and No for Shared responsibility.

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.

In Microsoft Purview eDiscovery, to search, preserve, analyze, and export content, you must first create a case. A case acts as a container for all eDiscovery activities, including placing users and content locations on litigation hold, running content searches, and exporting results for legal or compliance review.

SCI Extract: "Cases are used in Microsoft Purview eDiscovery (Standard and Premium) to manage, organize, and execute the various tasks associated with identifying and delivering content during an investigation or litigation."

In Microsoft 365 information protection guidance, Microsoft explains that sensitivity labels are persistent: when a label is applied to a file or email, the label information is stored as metadata so that the protection settings “travel with the content” wherever it’s saved or shared. Labels can apply encryption, content marking (headers, footers, watermarks), and DLP-friendly metadata, but encryption is optional—some labels only classify/mark without encryption. Microsoft also emphasizes that labels are not restricted to predefined categories; administrators can create custom label names, descriptions, and scoped policies to reflect an organization’s taxonomy (for example, Public, Confidential, Highly Confidential, or industry-specific categories). Because the defining property that always applies is that the label remains attached to the content and enforces configured policy across Microsoft 365 services and supported third-party locations, the accurate characteristic is persistent. Options “encrypted” (not always) and “restricted to predefined categories” (incorrect—labels are customizable) do not universally describe sensitivity labels.

Microsoft Purview Data Loss Prevention (DLP) defines supported service locations for policy enforcement. The Microsoft Learn/SCI materials state that DLP policies “help protect sensitive information across Microsoft 365 services” and can be scoped to common workloads. In the DLP overview, Microsoft explicitly lists the core cloud locations: “You can create DLP policies that protect content in Exchange Online, SharePoint Online, and OneDrive for Business.” The Teams workload is also included: “DLP can monitor and take protective actions on Microsoft Teams chat and channel messages.” These statements confirm that applying a DLP policy to Exchange Online email (A), OneDrive accounts (B), and Teams chat and channel messages (D) is supported.

By contrast, Exchange Online public folders (C) are not listed among supported DLP locations in the SCI documentation, and Viva Engage (formerly Yammer) (E) is not a standard Microsoft Purview DLP location in the core list above (Viva Engage has separate governance and communication compliance controls). Therefore, from the supported locations enumerated in Microsoft’s DLP guidance, the correct answers are Exchange Online email, OneDrive accounts, and Teams chat and channel messages.

Microsoft defines Microsoft Entra ID Governance as the capability to manage “the identity lifecycle, access lifecycle, and privileged access” so organizations can ensure “the right people have the right access to the right resources at the right time.” The product family explicitly lists the following core features: “Lifecycle workflows, Entitlement management, Access reviews, and Privileged Identity Management (PIM).” Microsoft further explains that PIM helps you “manage, control, and monitor access within your organization,” enabling just-in-time elevation, approval workflows, MFA/justification on activation, and detailed auditing for privileged roles. By contrast, the other options are separate Microsoft Entra offerings outside ID Governance: Verifiable credentials (Microsoft Entra Verified ID) issues and validates digital credentials; Permissions Management (Microsoft Entra Permissions Management) provides CIEM for multi-cloud permissions; and Identity Protection offers risk-based detection and policies for sign-ins and users. Therefore, among the choices, the feature that is included in Microsoft Entra ID Governance is Privileged Identity Management (PIM), which is specifically called out by Microsoft as a pillar of ID Governance and is used to govern privileged access with policy-based controls, time-bound assignments, approvals, and comprehensive auditability.

Microsoft Entra Permissions Management is Microsoft’s cloud infrastructure entitlement management (CIEM) solution delivered in the Microsoft Entra admin center, not in the Microsoft Purview compliance portal. Microsoft guidance describes it as a CIEM service that provides “centralized visibility, right-sizing, and governance of permissions across clouds” and is accessed and administered from the Entra portal under Permissions Management. The Purview compliance portal is used for compliance solutions such as Compliance Manager, Information Protection, DLP, eDiscovery, and Insider Risk—not CIEM—so statement 1 is No.

Permissions Management supports multicloud environments. Microsoft documentation states that it “discovers, monitors, and manages permissions for identities and resources across Microsoft Azure, Amazon Web Services (AWS), and Google Cloud Platform (GCP).” It calculates a Permission Creep Index (PCI), surfaces excessive permissions, and recommends remediation across these clouds; therefore, using it to manage permissions in AWS is supported—statement 2 is Yes.

Regarding secure scores: Permissions Management focuses on entitlements (e.g., effective permissions, PCI, right-sizing actions). Microsoft Secure Score (and Identity Secure Score) are separate posture metrics exposed in Microsoft 365 Defender and Microsoft Entra ID, respectively. The Permissions Management blade does not present Microsoft Secure Score; instead, it shows CIEM-specific insights and PCI. Consequently, the claim that Secure Score can be reviewed from Permissions Management in the Entra admin center is No.

In Microsoft 365 compliance, sensitivity labels (Microsoft Purview Information Protection) are the feature designed to classify and automatically protect data. Microsoft states that sensitivity labels “let you classify and protect your organization’s data” and that a label “can apply protection settings such as encryption” to files and emails. Labels can be deployed so that protection is applied without user action: Microsoft explains that labels “can be applied automatically, recommended, or by users,” and that administrators can “auto-apply a sensitivity label to content in SharePoint, OneDrive, and Exchange based on conditions such as sensitive info types, keywords, or trainable classifiers.” When a label with protection is applied, “encryption settings travel with the content” and enforce usage rights like who can open, print, or forward, even outside the organization.

By contrast, Content Search and eDiscovery are discovery/investigative tools and do not enforce protection. Retention policies manage how long content is kept or deleted, but they don’t encrypt content. Therefore, the Microsoft 365 compliance capability that encrypts content automatically based on specific conditions is sensitivity labels with auto-labeling policies in Microsoft Purview.

Microsoft documents for Defender for Endpoint (MDE) describe it as an enterprise endpoint security platform that supports Windows 10/11, Windows Server, Linux, macOS, and mobile platforms (Android and iOS/iPadOS). The platform provides threat and vulnerability management, attack surface reduction, next-generation protection, endpoint detection and response, and automated investigation and remediation across those supported operating systems. Because MDE supports Windows client operating systems and servers, it can also be used on Azure virtual machines that run supported Windows versions; onboarding methods include local scripts, Microsoft Endpoint Manager, or cloud integrations, allowing VM endpoints to receive the same protection and EDR capabilities as physical devices.

By contrast, malware scanning in SharePoint Online, OneDrive, and Microsoft Teams is provided by Microsoft Defender for Office 365 (Safe Attachments for SharePoint, OneDrive, and Teams)—a different service within the Microsoft 365 Defender family. This service analyzes files as they are uploaded or shared to detect and block malicious content in collaboration workloads, which is outside the scope of MDE’s endpoint-focused protections. Therefore: Android protection (Yes), Azure VMs running Windows 10 (Yes), and SharePoint Online anti-virus protection by MDE (No, handled by Defender for Office 365).

documents: =

Microsoft Entra ID Protection evaluates risk during authentication, not only after the user is authenticated. The service provides “real-time” assessment as part of the sign-in flow and also processes “offline” detections, enabling Conditional Access to act before a session is granted. In Microsoft’s terminology, “sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner,” while “user risk represents the probability that a given identity or account is compromised.” These risks are surfaced as risk detections and can be used to trigger MFA, block access, or require secure password reset. Each detection and calculated risk is classified by Microsoft Entra ID Protection with “Low, Medium, or High” levels so administrators can triage and automate policy responses appropriately. Because detections are calculated in real time as part of the sign-in evaluation (and also through subsequent analysis), it is incorrect to say they are generated once the user is authenticated. The accurate view is that Identity Protection continuously analyzes telemetry and produces detections and risk levels that may be acted upon before, during, and after sign-in, with user risk expressing the likelihood that the identity itself is compromised and sign-in risk expressing the likelihood that a particular authentication attempt is not legitimate.

Endpoint data loss prevention (Endpoint DLP), a feature in Microsoft Purview, supports Windows 10 and 11 and now also supports macOS for core DLP capabilities. It allows organizations to monitor and restrict actions like copying sensitive files to USBs, printing, or uploading to unapproved cloud services.

SCI Extract: "Endpoint DLP extends Microsoft Purview Data Loss Prevention to Windows 10, Windows 11, and macOS devices, allowing for monitoring and control of sensitive data usage at the endpoint."

Other platforms like Linux, iOS, and Android are not currently supported for Endpoint DLP

In the Microsoft Purview compliance portal, administrators can tailor the user experience to match the roles and responsibilities of users in the organization. One key feature provided to enable this customization is the “Customize navigation” option.

According to Microsoft’s Security, Compliance, and Identity (SCI) learning paths and SC-series certification materials (especially SC-400 and SC-900), the Customize navigation option in the Microsoft Purview compliance portal is used to add, remove, or rearrange features in the navigation pane. This is especially useful for compliance or security administrators who want to streamline the portal for ease of use or hide sections that are not relevant to their work.

The SCI documentation states:

“The Microsoft Purview compliance portal provides a Customize navigation option that allows admins to personalize the left-hand navigation pane. This feature supports removing unused features or rearranging the order in which services appear, improving navigation efficiency and reducing clutter.”

This setting does not change permissions or access to features but purely controls the visibility and layout for users. The other listed options like Compliance Manager, Policies, and Settings are functional sections of the portal, but only "Customize navigation" is explicitly designed to manage the visual layout and visibility of the features shown in the portal's navigation pane.

For Azure data services such as Azure SQL Managed Instance, Microsoft provides threat detection and protection through Microsoft Defender for Cloud (via Microsoft Defender for SQL). Microsoft documentation states that Defender for Cloud “provides advanced threat protection for your SQL resources,” including Azure SQL Database and Azure SQL Managed Instance, by “continuously monitoring for anomalous activities and potential SQL injection, brute force, and exploitation attempts.” When enabled, the plan “generates security alerts when suspicious activities are detected,” and these alerts can be surfaced in Defender for Cloud, forwarded to Microsoft Sentinel, or integrated with workflows for response. Microsoft Secure Score is a security posture metric, application security groups are for network segmentation in Azure, and Azure Bastion provides secure RDP/SSH over TLS—none of these deliver database-specific threat detection. Therefore, to provide threat detection for Azure SQL Managed Instance, you use Microsoft Defender for Cloud (Defender for SQL).

In Microsoft Defender for Cloud, the Free plan provides continuous security assessment and visibility into your posture via Secure Score and security recommendations. Microsoft explains that the free tier offers “foundational CSPM capabilities,” including recommendations and a security score (Secure score) to help you prioritize hardening tasks. Advanced features—such as vulnerability scanning for VMs (Qualys-based), Just-In-Time (JIT) VM access, and threat protection alerts—require the enhanced/paid Defender plans (for example, Defender for Servers). Consequently, among the listed options, only Secure score is available in the free mode. This score aggregates the effect of recommendations across subscriptions and resources so you can track and improve security posture without enabling any of the paid Defender plans.

Microsoft defines Information Barriers (IB) as policies that “restrict communication and collaboration between specific users or groups” to meet regulatory or conflict-of-interest requirements. In Microsoft 365, IB enforcement is provided across collaboration workloads—most notably Microsoft Teams and, with IB v2, SharePoint and OneDrive—so that users placed in segments that shouldn’t interact are prevented from chatting, meeting, or sharing files with one another. The service “controls who can communicate and collaborate with whom” and applies those controls to Teams chats/channels and SharePoint/OneDrive sites and files so that segment boundaries are honored when users attempt to share or access content.

By contrast, Exchange Online email is not a supported enforcement surface for Information Barriers; IB does not block or route mail. Email restrictions are handled with other capabilities (for example, mail flow rules), not IB. Therefore, in alignment with Microsoft’s SCI guidance: IB does work with Microsoft Teams and with Microsoft SharePoint/OneDrive, but it does not provide policy enforcement for Exchange email.

In Microsoft cloud identity, access to Azure resources follows the classical order of authenticate, then authorize. Microsoft Learn defines the two steps clearly: “Authentication is the process of establishing the identity of a person or service,” while “Authorization is the process of determining what a person or service can do.” In an Azure sign-in, Microsoft Entra ID (formerly Azure AD) first validates the user’s credentials (password, MFA, Conditional Access, device compliance, risk evaluation). Upon success, a security token is issued that proves the user’s identity. Only after this identity is established does Azure proceed to authorization, where the Azure Resource Manager evaluates role-based access control (RBAC) assignments to decide what actions are allowed. SCI guidance emphasizes this sequence for Zero Trust: “Verify explicitly” (authenticate with strong signals) and then “use least privilege access” (authorize by RBAC or Privileged Identity Management). Therefore, when users sign in to the Azure portal, the first step is authentication—verifying who they are. The subsequent step is authorization, which determines what resources and operations they can access based on roles, scope, and policy. This ordering underpins secure identity and access management across Microsoft 365 and Azure.

Microsoft guidance describes Azure Blueprints as the native way to stamp out governed environments consistently across tenants and subscriptions. Microsoft states: “Azure Blueprints enables cloud architects and central information technology groups to define a repeatable set of Azure resources that implements and adheres to an organization’s standards, patterns, and requirements.” It further explains that “Blueprints make it possible to package artifacts, such as role assignments, policy assignments, ARM templates, and resource groups, into a single blueprint definition that can be assigned to your subscriptions.” This is precisely what’s required when you need to deploy Azure resources across multiple subscriptions in a consistent manner—you define a blueprint (with policies, RBAC, templates, and resource groups) and assign it to one or more subscriptions to get uniform, compliant deployments. While services like Microsoft Defender for Cloud and Azure Policy help assess and enforce security and compliance, Blueprints orchestrate multi-artifact deployment and governance at scale from day one of an environment’s lifecycle, ensuring standardization and repeatability across subscriptions.

In Microsoft Defender for Office 365, Threat Trackers (also known as threat analytics in the security portal) surface curated intelligence on prevailing and emerging cyberthreats, giving security teams insight into current campaigns, affected regions, and recommended actions. Threat Explorer (Explorer/Real-time detections) is the investigation workspace that provides near real-time visibility into detected phishing, malware, and other malicious email content, allowing analysts to identify, filter, and analyze recent threats and take remediation actions (e.g., purge messages). Anti-phishing protection is configured via anti-phishing policies and uses machine learning and impersonation settings (user and domain impersonation) to detect and block impersonation attempts and other phishing techniques in Exchange Online. Together, these capabilities map directly to the statements: Trackers = intelligence on active threats, Explorer = real-time analysis and reporting, and Anti-phishing = detection of impersonation.

Multi-factor authentication is a process where a user is prompted during the sign-in process for an additional form of identification, such as to enter a code on their cellphone or to provide a fingerprint scan.

Microsoft’s SCI documentation explains that Information Barriers (part of Microsoft Purview and enforced across Microsoft Teams, SharePoint, OneDrive, and Exchange) are used to “restrict communication and collaboration between specific groups of users to avoid conflicts of interest or to comply with regulatory obligations.” Policies define which segments can communicate and which must be blocked, and they control chat, channel conversations, meetings, file sharing, and e-discovery visibility between the defined segments. Typical scenarios include preventing communication between investment banking and research, or between merger deal teams and the rest of the organization. This is fundamentally different from other features: Sensitivity label policies classify and protect content but do not block who can talk to whom; Customer Lockbox manages Microsoft engineer access to customer data during support; and Privileged Access Management (PAM) limits admin task approvals and elevated operations, not end-user communication. When the requirement is to “restrict communication and the sharing of information between members of two departments,” Microsoft prescribes Information Barriers as the purpose-built capability to enforce those restrictions across collaboration workloads.

Microsoft’s SCI guidance defines the supported passwordless methods in Entra ID (Azure AD). The documentation states: “Microsoft recommends three passwordless authentication options: Windows Hello for Business, FIDO2 security keys, and the Microsoft Authenticator app (phone sign-in).” Windows Hello for Business “replaces passwords with strong two-factor authentication on Windows devices,” allowing users to sign in with a gesture (biometric or PIN) that does not require a password during interactive sign-in. Likewise, “FIDO2 security keys enable users to sign in using an external security key,” providing a standards-based passwordless credential that can work across supported browsers and devices.

By contrast, OATH software tokens (for example, time-based one-time passcodes in an authenticator app) are documented as multifactor verification methods: “OATH software tokens generate time-based codes used for MFA.” These OTP codes serve as a second factor and are not a passwordless primary sign-in method; users typically still enter a password and then the OTP. Therefore: software tokens → No (not passwordless), Windows Hello → Yes, FIDO2 security keys → Yes. This mapping aligns directly with Microsoft’s Entra ID passwordless authentication guidance and the delineation between passwordless sign-in and MFA second-factor methods.

In Microsoft’s security portfolio, Microsoft Defender for Cloud is the service that provides cloud workload protection for Azure and hybrid cloud resources. Microsoft describes it as a “cloud-native application protection platform (CNAPP) that helps strengthen the security posture of your cloud resources and protect workloads across multicloud and hybrid environments.” The service delivers Cloud Security Posture Management (CSPM) and Cloud Workload Protection (CWP) by continuously assessing configurations and protecting workloads such as virtual machines, containers, databases, and storage. Documentation further states that Defender for Cloud “provides threat protection for workloads running in Azure, on-premises, and in other clouds,” giving a single pane to harden resources, detect active threats, and remediate.

By contrast, Azure Monitor focuses on telemetry and observability; the Microsoft cloud security benchmark is a set of prescriptive best practices; and Microsoft Secure Score is an aggregate metric reflecting security posture. None of those deliver the workload protection and active defense capabilities (e.g., recommendations, hardening, and threat detection for servers, containers, and PaaS services) that Defender for Cloud offers. Therefore, the sentence correctly completes as: Microsoft Defender for Cloud provides cloud workload protection for Azure and hybrid cloud resources.

Microsoft’s Zero Trust guidance defines three core principles: “Verify explicitly, use least-privileged access, and assume breach.” In Microsoft’s SCI learning content and Zero Trust overview, the model is described as one that “treats every access attempt as though it originates from an open, untrusted network” and therefore requires explicit verification using all available signals (identity, device health, location, data sensitivity, and anomalies). This directly confirms the first statement as true: Verify explicitly is a guiding principle.

The same guidance states organizations must “assume breach”—designing controls so that if an attacker is already inside, blast radius is minimized through segmentation, Just-In-Time/Just-Enough-Access, continuous monitoring, and rapid detection and response. Microsoft’s Zero Trust materials repeatedly explain to “assume attackers are present” and to “contain and remediate” through defense-in-depth controls, which validates the second statement as true.

Finally, Zero Trust rejects perimeter-based implicit trust. Microsoft clarifies that the model does not rely on a trusted internal network protected by a firewall; instead it “never trusts, always verifies,” continuously enforcing policy regardless of network location (on-premises or internet). Therefore, the statement that Zero Trust assumes a firewall secures the internal network from external threats is false because Zero Trust presumes no inherent safety from being “inside” the network and requires continuous verification and least-privileged access everywhere.

Microsoft 365 Advanced Audit is a capability of the Microsoft Purview audit solution that enhances auditing by adding additional high-value audit events, extended retention (up to one year by default, longer with add-ons), and intelligent insights. Microsoft documentation explains that Advanced Audit provides Exchange-specific events such as “MailItemsAccessed” and “SearchQueryInitiated”, which log when users access mailbox items and when they initiate a search in Exchange (including Outlook on the web). These records include who performed the action, when it occurred, the client/app used, and other metadata that helps investigations and forensics.

Advanced Audit is not a billing tool; billing information is handled separately in Microsoft 365 admin/billing portals and isn’t part of the audit schema. Likewise, audit logs do not expose message content; they capture activity metadata (actor, operation, workload, timestamp, and parameters) rather than the actual body of emails or file contents. The purpose is to improve auditability and investigation without revealing user content. Therefore, statements about viewing billing details or email contents are No, while identifying mailbox search actions (e.g., a user using the Outlook on the web search bar) is Yes, because Advanced Audit includes the SearchQueryInitiated (Exchange) event that records such activity.

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.

Explanation

Azure Active Directory (Azure AD) access reviews enable organizations to efficiently manage group memberships, access to enterprise applications, and role assignments.

In Microsoft Defender for Cloud, the metric that represents the overall security health of your Azure subscription is secure score. Microsoft’s documentation explains: “Secure score provides an aggregated view of your security posture across your subscriptions and resources. It’s based on security recommendations; addressing those recommendations improves your score.” Defender for Cloud calculates secure score by assessing controls and recommendations mapped to standards, then weighting them by risk and importance: “Each recommendation contributes to the secure score. Completing remediation steps increases the score and reduces risk.” This single percentage view lets security teams quickly gauge how well current configurations and protections align with Microsoft’s security best practices and regulatory mappings. Other elements surfaced in Defender for Cloud—like “resource health,” “status of recommendations,” or “completed controls”—are components and statuses that feed into or relate to the scoring model, but the overall subscription security health indicator presented and tracked over time is secure score.

Microsoft 365 Insider Risk Management follows a clear operational flow: Triage → Investigate → Action. Microsoft’s guidance explains that the Alerts dashboard is used first to review and filter alerts, prioritize by severity, and decide what needs deeper review—this is the Triage stage. The documentation describes triage activities as reviewing alert details, applying filters, and determining whether an alert should be escalated for investigation.

When an alert warrants deeper inquiry, analysts move to Investigate, where they create cases, add relevant alerts and users, and examine activity timelines and related signals. Microsoft states that cases are the vehicle for structured investigations, allowing analysts to group evidence and manage workflow from the Case dashboard.

After investigation, organizations proceed to Action, where insider risk controls allow response steps such as sending user policy reminders, escalating to HR or legal, or taking other governance actions. Microsoft describes that actions can include notifying the user with a policy reminder to reduce future risk or applying stronger controls, all of which are part of the response phase.

Accordingly, the correct matches are: Triage → Review and filter alerts, Investigate → Create cases in the Case dashboard, and Action → Send a reminder of corporate policies to users.

In Microsoft’s cloud security terminology, Cloud Security Posture Management (CSPM) is the solution specifically designed to perform continuous security assessments of cloud resources and generate alerts when misconfigurations or vulnerabilities are detected. In Microsoft Defender for Cloud, the CSPM capabilities continuously analyze Azure, multi-cloud, and hybrid resources against built-in security benchmarks and regulatory standards. The platform evaluates configurations, detects insecure settings, missing protections, and exposure paths, then raises security recommendations and alerts so administrators can remediate issues that increase risk.

Microsoft’s security and SCI learning content describes CSPM as providing “continuous assessment, visibility, and guidance to improve the security posture of your cloud environment,” including automatic alerting when high-risk issues or vulnerabilities are found. These assessments are mapped to standards and best practices, helping organizations reduce risk proactively instead of waiting for an active attack.

By contrast, DevSecOps is a practice or methodology, not a specific product. A Cloud Workload Protection Platform (CWPP) focuses on runtime protection of workloads such as VMs, containers, and PaaS services. A SIEM solution (like Microsoft Sentinel) ingests and correlates logs and alerts from many sources but does not itself perform the core security posture assessments of cloud configurations. Therefore, the SCI domain clearly aligns this function with CSPM.

In Microsoft’s Security, Compliance, and Identity guidance, Azure AD Privileged Identity Management (PIM) is the service used to manage, control, and monitor access to important resources in Azure and Microsoft 365. The documentation explains that PIM enables “just-in-time” and “time-bound” activation of privileged roles, requiring users to elevate only when needed and for a limited duration. PIM policies can require approval before a role is activated, enforce multifactor authentication, capture business justification, send notifications, and maintain detailed auditing and access review records. These controls are designed to reduce the risk associated with standing administrative privileges by ensuring that elevation is temporary, approved, and tracked.

By contrast, Windows Hello for Business provides strong, device-bound authentication; Azure AD Identity Protection focuses on detecting and remediating risky sign-ins and users; and Azure AD Access Reviews periodically reattest existing assignments but do not provide the on-demand, approval-based, time-limited activation of roles. Therefore, when the requirement is approval-based, time-bound role activation, Microsoft’s prescribed capability is Azure AD PIM, which delivers just-in-time elevation with approvers, duration limits, and audit/logging to support least privilege and Zero Trust operational practices.

In Microsoft Purview Compliance Manager, the built-in Compliance score and assessments are designed for ongoing, risk-based monitoring of your organization’s compliance posture. Microsoft’s SCI materials describe Compliance Manager as a solution that “helps you track, improve, and demonstrate your compliance posture” by mapping regulations and standards to improvement actions and assessments. The experience is not a one-time or periodic snapshot; it is intended to be continuous. As you implement controls, provide evidence, or when automated tests record results, “your score is updated as you complete actions,” reflecting current progress toward data protection and regulatory requirements.

Assessments in Compliance Manager persist over time and are maintained through continuous evaluation: actions can be automatically tested when supported (for example, configuration-based controls in Microsoft 365) or manually assessed on an ongoing basis by compliance teams. This design enables organizations to prioritize and remediate issues as they arise, rather than waiting for monthly or quarterly reviews. Because of this continuous scoring and reassessment model, Compliance Manager assesses compliance data continually for an organization, providing near real-time insight into control effectiveness and residual risk across standards such as GDPR, ISO 27001, and NIST frameworks.

(CIEM) solution. CIEM is a security technology category that helps organizations manage identity and access permissions across multi-cloud environments, including Microsoft Azure, AWS, and Google Cloud Platform (GCP).

According to Microsoft’s official Security, Compliance, and Identity (SCI) training and documentation (especially relevant in SC-300 and SC-900 learning paths):

“Microsoft Entra Permissions Management is a CIEM solution that provides comprehensive visibility and control over permissions for all identities and resources across multicloud environments.”

Key features of Microsoft Entra Permissions Management as a CIEM include:

Discovery of over-privileged accounts and unused permissions.

Enforcement of the principle of least privilege.

Detailed permissions analytics and reporting.

Support for Azure, AWS, and GCP environments.

This solution is designed to address the growing risk of identity sprawl and permission misuse in cloud platforms, which traditional identity governance or SIEM tools do not address effectively.

Incorrect Options:

CSPM (Cloud Security Posture Management) focuses on cloud misconfiguration, not identity permissions.

SIEM (e.g., Microsoft Sentinel) aggregates logs/events for threat detection, not entitlement visibility.

XDR (e.g., Microsoft Defender XDR) is focused on detection and response across endpoints, identities, and data—not entitlement management.

✅ Therefore, the correct and Microsoft-verified classification is: a cloud infrastructure entitlement management (CIEM) solution.

In Microsoft Entra ID (formerly Azure AD), Managed Identities for Azure resources are the built-in way for an Azure resource to authenticate to other Azure services without storing credentials. Microsoft’s documentation states: “Managed identities for Azure resources provide Azure services with an automatically managed identity in Azure Active Directory.” It further distinguishes the two types and clarifies the one used here: “A system-assigned managed identity is enabled directly on an Azure service instance. When enabled, Azure creates an identity for the instance in Azure AD.” Microsoft also emphasizes the lifecycle binding: “This identity is tied to the lifecycle of that service instance and is deleted when the resource is deleted.” Once enabled, the resource can call Azure services by requesting tokens: “You can use this identity to obtain Azure AD tokens for authentication to services that support Azure AD authentication.”

Because the prompt explicitly says “system-assigned”, the correct completion is managed identity. The other options do not match Microsoft’s definition: a user identity refers to a human user; a service principal is the underlying object applications use but isn’t what Azure terms “system-assigned”; and an Azure AD–joined device pertains to device registration, not resource-to-service authentication. Therefore, the sentence correctly reads: “An Azure resource can use a system-assigned managed identity to access Azure services.”

Microsoft Purview Data Loss Prevention (DLP) is designed to “detect and protect sensitive items” across Microsoft 365 locations, endpoints, and cloud apps. Microsoft explains that Purview DLP policies use sensitive information types, exact data match (EDM), and machine learning–based trainable classifiers to identify content, and then automatically apply protective actions such as blocking or restricting sharing, notifying users with policy tips, auditing, or auto-quarantining/justifying activities. This fulfills the description “use machine learning algorithms to detect and automatically protect sensitive items.” While eDiscovery focuses on legal hold and content discovery, and Communication compliance monitors communications for policy violations (ethics/regulatory scenarios), they are not positioned to broadly and automatically protect sensitive data across services. “Information risks” is not a distinct Purview solution category. Therefore, the Purview capability that leverages machine learning classifiers and automatically enforces protections on sensitive data is Data loss prevention (DLP).

Microsoft Azure Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution.

In Microsoft’s SCI materials, the Solutions catalog is described as part of the Microsoft Purview experience: “The Microsoft Purview compliance portal is the home for solutions to manage your organization’s data security and compliance needs.” Within this portal, Microsoft states that “the Solutions catalog provides a single place to discover, learn about, and set up Microsoft Purview solutions.” The catalog organizes capabilities across compliance domains, for example “Information Protection, Data Lifecycle Management, Data Loss Prevention, Insider Risk Management, eDiscovery, Audit, and Compliance Manager,” and from the catalog “administrators can open setup guides and configuration wizards for each solution.” This positioning makes the Purview compliance portal the correct portal when you are asked where the solution catalog lives.

By comparison, the Microsoft 365 admin center focuses on tenant administration and licensing, the Microsoft 365 Defender portal consolidates threat protection and security operations, and the Microsoft 365 Apps admin center targets Office app management and servicing. None of these are identified as the home of the Purview Solutions catalog. Therefore, the portal that contains the solution catalog is the Microsoft Purview compliance portal.

Biometrics templates are stored locally on a device. Reference:

https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-overview

Microsoft Defender for Office 365 includes Safe Attachments, a protection that “checks attachments in a secure, virtual environment to detect malicious behavior.” In Microsoft’s guidance, Safe Attachments is described as part of the anti-malware pipeline that “routes messages with attachments to a detonation chamber; if no suspicious activity is detected, the message is released to the recipient, and if malicious behavior is found, the attachment is blocked or removed.” Administrators can choose Block, Replace, Dynamic Delivery, or Monitor actions. The Dynamic Delivery option specifically supports the use case in the question: the email body is delivered while the attachment is scanned, and “the attachment is automatically reattached and forwarded to the recipient only when it is determined to be safe.” This capability is unique to Defender for Office 365’s Safe Attachments, not to be confused with endpoint antivirus or identity tools. Defender Antivirus protects Windows devices, Defender for Identity secures on-premises identities, and Defender for Endpoint focuses on endpoint detection and response. Therefore, the Microsoft service you use to scan email attachments and forward them only when clean is Microsoft Defender for Office 365 (Safe Attachments).

Microsoft states that Azure AD Multi-Factor Authentication “adds a second form of verification” to sign-ins and supports multiple verification methods. The documented methods include Microsoft Authenticator app notifications or verification codes, text message (SMS) codes, and phone call verification. In Microsoft’s description, users can approve a push notification in the Microsoft Authenticator app or enter a code from the app; they can receive a text message containing a verification code; or they can answer a phone call to complete the challenge. Email verification and security questions are not listed as supported MFA methods for Azure AD sign-ins and are not valid second factors in Azure AD MFA. Consequently, the correct methods from the options provided are Phone call, Text message (SMS), and Microsoft Authenticator app. These align with Azure AD’s core MFA capabilities used in Conditional Access and per-user MFA to strengthen authentication beyond the password and to meet compliance and security requirements for strong user verification.

 Security defaults require an Azure Active Directory (Azure AD) Premium license. No

 Security defaults can be enabled for a single Azure Active Directory (Azure AD) user. No

 When Security defaults are enabled, all administrators must use multi-factor authentication (MFA). Yes

Microsoft explains that Security defaults are baseline identity protections that are “available to all tenants at no additional cost” and are intended to “help protect your organization from common identity-related attacks.” They are a tenant-wide setting: Microsoft states that security defaults are “either on or off for the entire tenant” and “can’t be customized or targeted to specific users or groups.” If you require per-user or granular targeting, Microsoft directs customers to use Conditional Access policies instead.

A core behavior of security defaults is enforcing MFA: “All users are required to register for Azure AD Multi-Factor Authentication,” and “administrators are required to perform MFA.” In addition, security defaults “block legacy authentication” and apply other baseline requirements, but they do not enable premium features such as Azure AD Identity Protection or PIM. Summarizing the implications for the statements: no premium license is required; you cannot enable security defaults for just one user because the control is global; and when enabled, administrators must use MFA, with Microsoft recommending exclusion only for a break-glass account if necessary.

Microsoft Secure Score in the Microsoft 365 Defender portal aggregates improvement actions across Microsoft security workloads, including Microsoft Defender for Cloud Apps (formerly Cloud App Security). Microsoft states that “Defender for Cloud Apps automatically provides SSPM data in Microsoft Secure Score, for any supported and connected app.” This means Secure Score can surface and recommend actions tied to Cloud App Security/Defender for Cloud Apps, validating statement 1 as Yes. Microsoft Learn

Secure Score also includes peer comparison so organizations can benchmark their progress. The Microsoft documentation explicitly notes: “Compare your score to organizations like yours. There are two places to see how your score compares to organizations that are similar to yours.” This capability appears on the Overview experience in the Defender portal, confirming statement 2 as Yes. Microsoft Learn

Finally, Secure Score recognizes mitigations implemented outside Microsoft tooling. In the official guidance for improvement actions, Microsoft explains the status options “Resolved through third party and Resolved through alternate mitigation,” adding: “You’ll gain the points that the action is worth, so your score better reflects your overall security posture.” Therefore, if you address an improvement action via a third-party product, Secure Score awards the associated points—making statement 3 Yes.

Microsoft Defender for Identity (formerly Azure ATP) is designed to protect on-premises identity infrastructures by analyzing signals from Active Directory Domain Services (AD DS). In Microsoft’s SCI guidance, Defender for Identity is described as a “cloud service that uses sensors installed on your domain controllers to monitor and analyze user activities and information across your on-premises Active Directory.” The sensors “collect authentication, replication, and other security-relevant events and network traffic,” enabling analytics to detect techniques such as Pass-the-Hash, Pass-the-Ticket, Golden Ticket, reconnaissance, lateral movement, and domain dominance. The product’s purpose is to surface advanced threats, compromised identities, and malicious insider actions by continuously profiling and learning from AD DS behavior and security events.

While Defender for Identity integrates with other Microsoft security solutions (for example, Microsoft 365 Defender and Microsoft Defender for Cloud Apps) to enrich investigations, it does not rely on Azure Active Directory (Microsoft Entra ID) signals for its core detections, nor does it collect telemetry from Azure AD Connect itself. Instead, its foundational telemetry source is on-premises AD DS domain controllers via lightweight sensors, which provide the deep authentication and directory-service context required to identify sophisticated identity-based attacks in hybrid environments.

Explanation

In Microsoft’s hybrid identity guidance, Azure AD Connect is the supported tool to bridge on-premises Active Directory Domain Services (AD DS) with Azure Active Directory (Azure AD). Microsoft Learn describes it plainly: “Azure AD Connect is Microsoft’s tool for connecting on-premises directories to Azure AD.” It “synchronizes user, group, and device objects” so cloud identities stay aligned with on-premises accounts and attributes. Azure AD Connect also supports multiple sign-in methods: “password hash synchronization, pass-through authentication, and federation integration.” In other words, you can sync identities and choose how users authenticate to Microsoft Entra ID (Azure AD).

By contrast, Active Directory Federation Services (AD FS) is a federation service used for claims-based authentication; it does not perform directory synchronization. Azure Sentinel (now Microsoft Sentinel) is a cloud-native SIEM/SOAR and is unrelated to identity sync. Privileged Identity Management (PIM) is an identity governance feature for just-in-time privileged access; it does not synchronize identities. Therefore, in a hybrid identity model where the requirement is to sync identities between AD DS and Azure AD, the correct Microsoft-endorsed solution is Azure AD Connect, which “keeps identities in sync between on-premises directories and Azure AD.”

Conditional Access session controls enable user app access and sessions to be monitored and controlled in real time based on access and session policies.

Based on this definition, the best answer for your question is B. enable limited experiences, such as blocking download of sensitive information.

https://learn.microsoft.com/en-us/azure/active-directory/conditional-access/concept-conditional-access-session

Compliance score

In Microsoft Purview Compliance Manager, the Compliance score is the metric that measures an organization’s progress in completing improvement actions that help reduce compliance and data-protection risk. Microsoft describes this score as a quantifiable indicator of your compliance posture across regulatory standards and data-protection baselines. Each recommended improvement action in Compliance Manager is assigned points; completing, testing, and attesting to those actions increases your score. Points are weighted by risk, so implementing controls with greater impact on reducing risk contributes more to the overall score. Microsoft also clarifies that the Compliance score is an operational progress indicator, not a certification or a legal determination of compliance, but it enables organizations to track, prioritize, and demonstrate the implementation of controls across frameworks such as GDPR, ISO/IEC 27001, NIST 800-53, and Microsoft Data Protection Baselines.

By contrast, Microsoft Purview compliance portal reports provide reporting and insights (for example, DLP, Insider Risk, Audit) but do not calculate a unified risk-reduction progress metric. The Trust Center is Microsoft’s public site for transparency about security, privacy, and compliance commitments, and Trust Documents (auditor reports, certifications, and white papers) supply evidence and reference materials. Neither of these provide an in-product, points-based measure of progress—Compliance score does.

In Microsoft Entra ID Protection, risk-based Conditional Access policies use signals such as User risk and Sign-in risk to evaluate potential threats during authentication and identity usage. These are core to adaptive access and identity protection features taught in Microsoft’s SC-300 and SC-900 learning paths.

User risk:

Defined by Microsoft as: “The probability that a specific identity or account is compromised.”

User risk is assessed based on activities and behaviors that indicate the account may have been compromised—such as leaked credentials or atypical user activity over time.

Sign-in risk:

Defined as: “The probability that the authentication request is not performed by the legitimate identity owner.”

Sign-in risk is calculated at the time of authentication based on indicators such as unfamiliar locations, anonymous IP addresses, impossible travel, or malware-linked sign-ins.

These signals help automate access decisions, such as requiring MFA or blocking access, based on real-time risk assessments.

In Microsoft Entra ID (formerly Azure AD), self-service password reset (SSPR) is the feature that explicitly supports email as an authentication method when users need to verify their identity to reset or unlock their password.

According to Microsoft’s identity and access documentation and the SCI learning content, SSPR lets administrators choose which verification methods are available to users, such as mobile phone, office phone, mobile app, security questions, and email. When email is enabled, a verification code can be sent to a registered alternate email address. The user proves their identity by entering this code, which is treated as an authentication step in the SSPR process.

By contrast:

Microsoft Entra Multi-Factor Authentication (MFA) does not support email as an MFA method; it focuses on methods like authenticator apps, phone calls, and text messages.

Microsoft Entra ID Protection detects and responds to risky sign-ins and users but does not provide email-based authentication.

Microsoft Entra Password Protection deals with banned and compromised passwords, not with email verification.

Therefore, the only option in the list that uses email as a supported authentication method is self-service password reset (SSPR).

In Microsoft’s official guidance, the Microsoft Cloud Adoption Framework for Azure (CAF) is described as the end-to-end approach that “provides best practices, documentation, and tools” to help organizations create and implement business and technology strategies for cloud adoption. The framework aggregates field experience from “Microsoft employees, partners, and customers” and offers prescriptive guidance across strategy, planning, readiness, governance, security, and management to ensure a secure and compliant Azure landing zone. Within SCI-aligned materials, CAF is highlighted as the authoritative body of guidance that helps organizations reduce risk by aligning cloud architecture, identity, security, and compliance controls with Zero Trust principles and regulatory needs. It enables teams to map security baselines, identity governance (e.g., using Microsoft Entra and Conditional Access), and compliance controls (e.g., data protection and regulatory mappings) into deployment blueprints and policy-driven guardrails.

By contrast, Azure Blueprints package artifacts (policies, RBAC, templates) for consistent deployments; Azure Policy enforces and audits configuration through policy definitions; and resource locks prevent accidental modification or deletion. While these are important technical controls, the statement in the question explicitly refers to a body of best practices and guidance that assists an Azure deployment end to end—this is precisely the role of the Microsoft Cloud Adoption Framework for Azure.

multi-factor authentication (MFA)

In Microsoft Entra ID (formerly Azure AD), Security defaults are a baseline of recommended identity protections that, when turned on, automatically apply tenant-wide. Microsoft’s guidance explains that security defaults “help protect your organization with preconfigured security settings” and specifically require that “all users register for Azure AD Multi-Factor Authentication.” When enabled, the defaults enforce MFA challenges for users and admins during risky or sensitive operations, and they block legacy authentication protocols that can’t satisfy modern MFA requirements. Microsoft further notes that security defaults “provide basic identity security mechanisms… such as requiring multi-factor authentication for all users and administrators.” These controls are designed to raise the overall security posture without custom policy design, which is ideal for small and medium organizations or any tenant that hasn’t yet implemented Conditional Access. Therefore, when you enable security defaults, MFA is enabled for all Azure AD users, driving strong authentication as the default and reducing account-takeover risk stemming from password-only sign-ins.

Microsoft 365 Information Barriers are compliance policies used “to prevent certain segments of users from communicating or collaborating with each other.” In Microsoft’s guidance, IB policies are designed for scenarios like insider trading restrictions, M&A deal rooms, or research–sales separation, where it’s necessary to block chats, calls, and collaboration between defined user segments. The documentation explains that when IB policies are in place, “users in the blocked segments cannot search, discover, or communicate with each other in Microsoft Teams,” and IB v2 extends these controls to additional collaboration workloads such as SharePoint and OneDrive. By contrast, email restrictions in Exchange Online are addressed through mail flow rules or other Exchange features, not information barriers, and restricting unauthenticated access or external sharing is handled by identity access controls and sharing settings, not IB. Therefore, the specific use case is restricting Microsoft Teams chats (and related collaboration) between certain groups within an organization.

Microsoft Purview Compliance Manager organizes improvement actions into control action subcategories that mirror core security control types used throughout Microsoft Learn’s SCI content: preventative, detective, and corrective. In the SC-900 security fundamentals guidance, Microsoft describes these control types as follows: “Preventive controls are intended to deter or stop an attack from occurring (for example, encryption and access controls). Detective controls are used to discover and detect attacks that are in progress or have occurred (for example, logging, auditing, and monitoring). Corrective controls are used to limit the damage caused by an incident and to return systems to normal operations (for example, configuration changes, incident response, and recovery activities).”

Applying those definitions to Compliance Manager actions: Encrypt data at rest is a preventative control because it deters exposure by protecting data before an event. Perform a system access audit is a detective action because auditing and reviewing access logs are used to discover and detect misuse or anomalies. Make configuration changes in response to a security incident is a corrective action because it remediates and restores the environment after detection, aligning with Compliance Manager’s corrective action guidance. These mappings reflect how Compliance Manager measures completion of improvement actions that reduce compliance risk through the right mix of preventative, detective, and corrective controls.

The Content Search tool in the Security & Compliance Center can be used to quickly find email in Exchange mailboxes, documents in SharePoint sites and OneDrive locations, and instant messaging conversations in Skype for Business.

The first step is to starting using the Content Search tool to choose content locations to search and configure a keyword query to search for specific items.

Microsoft’s identity model highlights four pillars: administration, authentication, authorization, and auditing. In this model, auditing is the capability that records and reports identity-related activities, providing visibility into “who accessed what, when, from where, and how.” SCI-aligned guidance explains that authentication verifies identity and authorization grants permissions, while auditing tracks and logs the resulting access to resources so organizations can investigate activity, satisfy compliance obligations, and detect anomalies. Microsoft services such as Microsoft Entra ID (sign-in logs and audit logs), Access Reviews, Privileged Identity Management (PIM) reports, and Microsoft Purview Audit are explicitly positioned to capture user access events and administrative changes across cloud apps and services. This evidence enables security operations and compliance teams to monitor access patterns, prove regulatory adherence, and respond to incidents. Therefore, when the question focuses on tracking the resources accessed by a user, the pillar that directly addresses this requirement is auditing, not authentication (identity proof), authorization (permission assignment), or administration (lifecycle and configuration).

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."