Microsoft SC-900 Microsoft Security Compliance and Identity Fundamentals Exam Practice Test

You can use an Azure network security group to filter network traffic to and from Azure resources in an Azure virtual network. A network security group contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources. For each rule, you can specify source and destination, port, and protocol.

< Device identity can be stored in Azure AD. → Yes

 A single system-assigned managed identity can be used by multiple Azure resources. → No

 If you delete an Azure resource that has a user-assigned managed identity, the managed identity is deleted automatically. → No

From Microsoft Entra ID (Azure AD) device documentation: Azure AD holds device objects for registration and join states. The docs state that device identities are maintained in Azure AD: “Azure AD device objects represent registered and joined devices so they can be managed and secured.” and “Devices can be Azure AD registered, Azure AD joined, or hybrid Azure AD joined.” These statements confirm that device identity is stored in Azure AD, so the first item is Yes.

Regarding managed identities: Microsoft’s description of system-assigned managed identity explains, “The identity is created in Entra ID and is tied to the lifecycle of that Azure resource.” and “Only that resource can use this identity.” Because a system-assigned identity is unique to a single resource and cannot be shared, the second statement is No.

For user-assigned managed identity, the documentation says, “A user-assigned managed identity is a standalone Azure resource.” and “It can be assigned to one or more Azure service instances and is managed independently.” Additionally, “When you delete the Azure resource, the user-assigned identity is not deleted.” Therefore, deleting a resource does not automatically delete the user-assigned identity, making the third statement No.

Microsoft’s Azure networking services have distinct roles that map directly to the statements in the prompt. Azure Firewall is a stateful, cloud-native network security service that explicitly supports Source NAT (SNAT) and Destination NAT (DNAT) to control and translate traffic flows. In Microsoft’s description, Azure Firewall “provides network address translation (SNAT/DNAT) and filtering for inbound and outbound traffic,” making it the correct match for NAT services.

Azure Bastion is designed to deliver “secure and seamless RDP and SSH connectivity to your virtual machines directly from the Azure portal over TLS” without exposing a public IP on the VM. This aligns precisely with secure Remote Desktop connectivity to Azure virtual machines.

Network security groups (NSGs) are Azure’s built-in mechanism for traffic filtering. Microsoft explains that an NSG “contains security rules that allow or deny inbound network traffic to, or outbound network traffic from, several types of Azure resources” and that rules can be applied to subnets or to individual network interfaces (NICs) on a virtual network. Therefore, NSGs are the right choice for traffic filtering applied to specific network interfaces.

Together, these mappings reflect Azure’s layered network security model: NSGs for rule-based filtering at NIC/subnet, Azure Firewall for centralized stateful inspection and NAT, and Azure Bastion for secure, browser-based RDP/SSH access.

Microsoft defines hybrid identity as enabling a common identity across on-premises and cloud by integrating your directory services. Microsoft Learn states: “Hybrid identity is achieved by integrating your on-premises Active Directory with Azure Active Directory.” This integration is delivered through the synchronization and optional federation capabilities that connect AD DS to Azure AD so users can access both on-premises and cloud resources with one identity.

To implement this integration, Microsoft’s tooling is explicit: “Azure AD Connect is the Microsoft tool designed to meet and accomplish your hybrid identity goals.” Azure AD Connect (now Microsoft Entra Connect) synchronizes users, groups, and optionally passwords or hashes to Azure AD, providing the foundation for hybrid scenarios such as single sign-on and seamless sign-in.

Regarding tenants, Microsoft’s identity platform clarifies that “A Microsoft 365 organization is associated with a single Azure AD tenant.” Therefore, a hybrid identity deployment does not require two Microsoft 365 tenants; it typically links a single Azure AD (Microsoft Entra ID) tenant with one or more on-premises AD DS forests. In summary, Azure AD Connect enables hybrid identity, hybrid identity is the synchronization/integration of AD DS with Azure AD, and it does not necessitate multiple Microsoft 365 tenants.

The Microsoft Service Trust Portal contains details about Microsoft's implementation of controls and processes that protect our cloud services and the customer data therein.

Assessments

In Microsoft Purview Compliance Manager, assessments are the core components used to track compliance with groupings of controls from specific regulations, standards, or requirements.

According to official Microsoft Security, Compliance, and Identity (SCI) learning content, particularly within the SC-400 and SC-900 certification tracks, the role of assessments is explicitly defined as:

“Assessments in Compliance Manager help you track, implement, and improve compliance with requirements from standards and regulations. Each assessment maps to a specific regulation or control framework, such as ISO 27001, NIST, GDPR, or HIPAA, and includes a set of controls and recommended improvement actions.”

Further extracted content from SCI documentation confirms:

“An assessment is used to measure your compliance posture against a particular regulation or standard. It includes control mappings and provides insight into what’s in place and what still needs to be addressed to meet the compliance goals.”

The other options in the dropdown — Templates, Improvement actions, and Solutions — serve different functions:

Templates provide a blueprint for creating assessments.

Improvement actions are actionable steps generated within assessments.

Solutions in Microsoft Purview refer to bundled capabilities like Insider Risk Management, Information Protection, etc.

Therefore, to track compliance with groupings of controls from a specific regulation or requirement, the correct and Microsoft-verified term is "Assessments."

Microsoft Defender for Identity (formerly Azure Advanced Threat Protection, also known as Azure ATP) is a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats, compromised identities, and malicious insider actions directed at your organization.

 An external email address can be used to authenticate self-service password reset (SSPR). → Yes

 A notification to the Microsoft Authenticator app can be used to authenticate self-service password reset (SSPR). → Yes

 To perform self-service password reset (SSPR), a user must already be signed in and authenticated to Azure AD. → No

For Microsoft Entra self-service password reset (SSPR), users must register one or more authentication methods that can later be used when they forget their password or are locked out. Microsoft’s end-user guidance states that an email address option lets users configure “an alternate email address that can be used without requiring your forgotten or missing password,” and that this method is available only for password reset. In practice, this alternate address is typically a personal or external email (for example, Gmail), so using an external email to authenticate SSPR is valid.

SSPR can also use the Microsoft Authenticator app as an authentication method. Microsoft documents that Authenticator push notifications, including number matching, are supported for several scenarios, explicitly listing self-service password reset (SSPR) among them. This means a push notification to the app on the user’s device can be used to verify identity during SSPR.

Finally, SSPR is designed for situations where the user cannot sign in. Official SSPR process descriptions explain that users start from the “Can’t access your account?” or password-reset page, provide their username, and then use their registered methods to prove identity. They do not need to be already authenticated to Azure AD; SSPR exists precisely to recover access when sign-in fails.

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.

Security Center

In Microsoft’s Security, Compliance, and Identity guidance, encryption is described as the control that “converts data into a form that cannot be understood by anyone who does not possess the appropriate decryption key.” In the Microsoft Purview Information Protection (sensitivity labels with encryption) documentation, Microsoft explains that when encryption is applied to a file, “only authorized users and services that present the correct keys and usage rights can open and use the content,” and that access is enforced even if the file is moved outside the organization. Azure Rights Management (part of Microsoft Purview) further states that encryption “protects data at rest and in transit by using keys so that only permitted identities can decrypt and use the information.”

This aligns precisely with the sentence: encrypting a file makes the data readable and usable to viewers that have the appropriate key (and unreadable to those who do not). By contrast, archiving organizes or preserves data for long-term storage; compressing reduces file size without controlling access; and deduplicating removes redundant copies to save space. None of these provide the key-based, identity-bound access control described in Microsoft SCI materials. Therefore, the correct completion is Encrypting.

In Microsoft Azure, an NSG consists of ordered security rules evaluated by priority. The Azure documentation specifies that every rule includes identifying metadata and must be uniquely named within the NSG: “Each security rule has a name that is unique within the network security group.” Rule evaluation is deterministic: “Security rules are processed in priority order… once a rule matches traffic, processing stops.”

Azure creates several default security rules in every NSG to provide a safe baseline. These defaults are protected: “You can’t remove the default security rules, but you can override them by creating rules with a higher priority.” This means deletion of default rules is not allowed; administrators add custom rules with lower priority numbers to supersede the defaults as needed.

Regarding protocols, NSG rules can target specific L4/L3 protocols. The platform guidance states that the rule Protocol field supports TCP, UDP, ICMP, or Any: “For Protocol, specify TCP, UDP, ICMP, or Any.” Therefore, configuring rules to check TCP, UDP, or ICMP traffic types is fully supported.

Putting this together: (1) unique rule names are required (Yes), (2) default rules cannot be deleted (No), and (3) NSG rules can indeed be configured for TCP/UDP/ICMP (Yes). These behaviors align with Azure’s prescribed NSG design and management model used across Microsoft Security, Compliance, and Identity learning content.

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.

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.

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 Purview, eDiscovery (Standard) (formerly Core eDiscovery) provides case management, holds, searches, and export. Microsoft describes that eDiscovery (Standard) lets investigators “search across Microsoft 365 data sources and export the results,” including options to export native files, email to PST, and CSV reports for further review. It uses the same Content search engine and supports selecting locations such as **Exchange Online mailboxes, Microsoft 365 Groups, Teams, SharePoint sites, OneDrive accounts, and Exchange public folders,” enabling organization-wide discovery that includes public folders.

Integration for end-to-end legal review from Microsoft Purview Insider Risk Management is specifically aligned to eDiscovery (Premium) (formerly Advanced eDiscovery). Insider Risk cases provide actions like “Send to eDiscovery (Premium)” to create a review set and apply advanced processing, analytics, and review workflows. Those advanced integrations (review sets, analytics, legal hold communications) are not features of eDiscovery (Standard). Therefore: exporting results (Yes), Insider Risk integration (No, as it targets eDiscovery Premium), and searching Exchange Online public folders (Yes) are the correct evaluations based on the Microsoft Security, Compliance, and Identity study materials for Purview eDiscovery capabilities.

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’s shared responsibility guidance explains that the customer’s responsibility decreases as you move from on-premises to SaaS. In an on-premises datacenter, “you own the whole stack—applications, data, runtime, middleware, OS, virtualization, servers, storage, and networking.” With IaaS, the cloud provider operates the physical datacenter and virtualization, while “you’re responsible for configuring and managing the guest OS, network controls, identity, applications, and data.” With PaaS, the provider operates more of the stack so that “the cloud provider manages the platform (OS, middleware, and runtime) and you focus on your applications and data.” Finally, with SaaS, responsibility is minimized for customers because “the service provider manages the application and underlying infrastructure; customers primarily manage identity, data, and access/usage.”

These Microsoft Learn statements map directly to the requested order—from most customer responsibility (on-premises) to least (SaaS)—with IaaS and PaaS in between, reflecting the progressive shift of operational and security controls from the customer to the cloud provider as the service model moves up the stack.

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.

The Compliance score in Microsoft Purview Compliance Manager is a measurement tool that evaluates an organization’s progress toward meeting data protection and regulatory compliance requirements. It is specifically designed to help organizations reduce risks related to data governance, privacy, and compliance with various standards such as GDPR, ISO 27001, NIST 800-53, and Microsoft Data Protection Baselines.

According to Microsoft’s official documentation on Compliance Manager, the Compliance score “helps organizations track, improve, and demonstrate their compliance posture by providing a quantifiable measure of compliance with regulations and standards.” Each action within Compliance Manager contributes a certain number of points to the overall score. These points are weighted based on risk, meaning that actions with a greater impact on reducing compliance risk contribute more significantly to the total score.

The score is not an absolute measure of legal compliance but rather an indicator of progress toward implementing recommended controls and risk-reducing actions. Microsoft emphasizes that Compliance score “assists organizations in identifying areas of improvement, prioritizing compliance tasks, and maintaining an auditable record of their compliance activities.”

By contrast, Microsoft Secure Score measures security posture related to identity, device, and application protection, while Productivity Score evaluates collaboration and technology experience. Thus, the metric that specifically assesses data protection and regulatory compliance progress is the Compliance score in Microsoft Purview Compliance Manager.

In Microsoft Purview (Microsoft 365 compliance), a retention policy applied to a SharePoint site keeps content for the specified period (e.g., 1 year) even if users delete it. Items are retained and recoverable until the retention period expires, meeting your preservation requirement.

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

In Microsoft Purview Compliance Manager, improvement actions are categorized by control type to reflect how they reduce risk and contribute to your compliance score. Microsoft’s SCI guidance explains that preventative controls are safeguards that “prevent a security or compliance incident from occurring by enforcing protections in advance (for example, enforcing encryption of data at rest and in transit, access restrictions, and configuration baselines).” This directly aligns with the task “Use encryption to protect data at rest”, which is a classic prevention mechanism intended to stop unauthorized disclosure before it can happen.

The guidance also states that detective controls are measures that “identify, log, and surface anomalous or non-compliant activities so they can be investigated and addressed (for example, continuous monitoring, alerting, audit logging, and analytics).” This maps to “Actively monitor systems to identify irregularities that might represent risks”, because the goal is to detect suspicious behavior or drift as it occurs.

By comparison, corrective controls are used to “remediate issues and restore a desired state after a problem is discovered (for example, patching, incident response, or configuration correction).” No corrective action is described in the two listed tasks, so Corrective is not selected. This mapping reflects how Compliance Manager classifies actions that contribute points to the compliance score based on their risk-reducing impact.

In Microsoft Sentinel, automation of routine or repetitive SOC tasks is delivered through playbooks. Microsoft’s Sentinel guidance defines playbooks as “collections of procedures that can be run from Microsoft Sentinel in response to an alert or incident.” They are “built on Azure Logic Apps” and enable teams to “automate and orchestrate responses to threats” such as enriching incidents, opening tickets, notifying responders, quarantining entities, or blocking indicators. The documentation further clarifies that automation rules can “trigger playbooks automatically based on analytics alerts or incident conditions,” allowing consistent, scalable actions without manual intervention. By contrast, workbooks provide “data visualization and reporting” for analysis; hunting search-and-query tools (built on KQL) are used to “proactively hunt for threats”; and deep investigation tools assist analysts during incident investigation. Therefore, when the goal is to automate common tasks—for example, sending incident notifications, enriching with threat intelligence, or creating tickets in ITSM—the correct capability in Microsoft Sentinel is playbooks, because they encapsulate repeatable response procedures and can be executed automatically via automation rules or manually from incidents, alerts, or entities.

Box 1: Yes

The MailItemsAccessed event is a mailbox auditing action and is triggered when mail data is accessed by mail protocols and mail clients.

Box 2: No

Basic Audit retains audit records for 90 days.

Advanced Audit retains all Exchange, SharePoint, and Azure Active Directory audit records for one year. This is accomplished by a default audit log retention policy that retains any audit record that contains the value of Exchange, SharePoint, or AzureActiveDirectory for the Workload property (which indicates the service in which the activity occurred) for one year.

Box 3: yes

Advanced Audit in Microsoft 365 provides high-bandwidth access to the Office 365 Management Activity API.

Microsoft’s identity platform (Microsoft Entra ID, formerly Azure AD) supports built-in and custom directory roles. The official guidance states that you can “create your own custom roles to grant permissions for management of Microsoft Entra resources,” and those roles consist of specific role permissions that you select to tailor least-privilege administration. The documentation also lists Global administrator (formerly Company Administrator) as a built-in role that “has access to all administrative features” and can delegate role assignments, reset passwords for all users, and manage identity settings across the tenant. Regarding assignments, Microsoft is explicit that role assignment is many-to-many: administrators can “assign one or more roles to a user,” and the user’s effective permissions are the union of the privileges from all assigned roles. Consequently, (1) creating custom roles is supported (Yes), (2) Global administrator is indeed a defined Azure AD/Microsoft Entra role (Yes), and (3) a user being limited to only one role is incorrect (No) because multiple role assignments to the same user are permitted and commonly used to implement least privilege and separation of duties.

Box 1: Yes

Azure AD supports custom roles.

Box 2: Yes

Global Administrator has access to all administrative features in Azure Active Directory. Box 3: No

Microsoft Entra ID (formerly Azure Active Directory) is a cloud-based directory and identity platform. In Microsoft’s SCI materials, Entra ID is described as “Microsoft’s cloud-based identity and access management service that helps your employees sign in and access resources,” underscoring that it’s not deployed on-premises; instead, organizations can synchronize or federate with on-premises Active Directory using tools like Entra Connect. The same documentation explains that Entra ID is included with Microsoft 365 subscriptions, providing tenant identity services for apps such as Exchange Online, SharePoint Online, and Teams. Core capabilities listed include authentication, single sign-on (SSO), Conditional Access, device registration, and application access management, all of which classify Entra ID as an identity and access management (IAM) service. Thus: (1) on-premises deployment — No (it’s cloud-native), (2) provided with Microsoft 365 — Yes (a directory is created for each tenant), and (3) IAM service — Yes (it delivers identity, access, and governance controls used across Microsoft cloud services).

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.

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.

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.

In Microsoft identity and access scenarios, federation is explicitly defined as a mechanism to create trust between autonomous organizations so that identities authenticated in one can be accepted by another. Microsoft describes this as: “Federation is a collection of domains that have established trust.” In a federation, “this trust relationship lets each organization accept the other’s user authentication” and enables access to resources without the need to duplicate user accounts or require separate credentials. Within Azure AD/Microsoft Entra and AD FS guidance, Microsoft further explains that federation enables “claims-based access across security boundaries” and “allows users to access applications in a partner organization using their existing credentials.” These statements underline that the purpose of federation is to establish a trust relationship across identity providers or directories, not to provide multi-factor authentication, synchronize accounts, or build network tunnels. MFA is an authentication strength that can be applied on top of federated sign-in, user account synchronization is handled by services like Microsoft Entra Connect (Azure AD Connect), and VPNs provide network connectivity, not identity trust. Therefore, the completion that aligns with Microsoft SCI documentation is that federation establishes a trust relationship between organizations.

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 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’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 identity terminology, authentication is the step that proves who the user is when they attempt to sign in. Microsoft Learn defines it plainly: “Authentication is the process of proving the identity of a user, device, or service.” By contrast, “Authorization is the process of determining what a user, device, or service can do.” During sign-in to Microsoft Entra ID (formerly Azure AD), “the identity provider validates credentials and, upon successful authentication, issues tokens that applications use to grant access.” Microsoft further explains the available methods: “Microsoft Entra ID supports multiple authentication methods, including passwords, multi-factor authentication, FIDO2 security keys, certificate-based authentication, and federated authentication.”

Auditing and administration are not the mechanisms that verify identity at sign-in. Auditing “records security-relevant events for investigation and compliance,” while administration “refers to configuring and managing identities, access policies, and settings.” Therefore, in the sentence “When users sign in, _____ verifies their credentials to prove their identity,” the correct completion is authentication, because it is the control that validates the user’s credentials and establishes identity before any authorization decisions are made.

In Microsoft Defender for Cloud (formerly Azure Security Center), Secure score is defined as “a measurement of an organization’s security posture; the higher the score, the lower the identified risk.” Microsoft states that Defender for Cloud provides security recommendations that “help you harden your resources and increase your secure score.” Among these recommendations is “Apply system updates” for virtual machines—Microsoft describes it as ensuring that “machines should have the latest security updates installed”, and completing this action adds points to your secure score because it remediates a vulnerability class (missing patches).

Defender for Cloud also supports wide scope evaluation: you can “view and manage the secure score across subscriptions and management groups,” allowing organizations with multiple Azure subscriptions to see an aggregated and per-scope score and track improvement actions consistently.

Identity protections are part of Defender for Cloud’s recommendations as well. Under the Azure Security Benchmark controls, Defender for Cloud includes the recommendation that “MFA should be enabled on accounts with owner permissions on your subscription.” Implementing this MFA control earns secure-score points because it mitigates high-impact identity risks.

Therefore, applying system updates (Yes), evaluating across multiple subscriptions (Yes), and enabling MFA (Yes) all increase or contribute to an organization’s secure score in Azure Security Center/Defender for Cloud.

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

Microsoft documents describe Azure Bastion as a managed PaaS jump-host that’s deployed inside a virtual network to provide secure remote access: “Azure Bastion is deployed in your virtual network and provides seamless RDP and SSH connectivity to your virtual machines directly in the Azure portal over SSL.” The platform design is per-VNet, with the limit stated as: “One Bastion host can be deployed per virtual network,” ensuring a single managed entry point for that network. Connectivity is delivered using the native protocols while avoiding public exposure: “Bastion enables RDP and SSH sessions… without requiring a public IP on your virtual machines, using TLS (port 443).” Access is brokered through the web experience: “You connect to the VM directly from the Azure portal using your browser,” which provides an HTML5 client for RDP/SSH. These statements collectively validate that (1) deployment is one Bastion per VNet, (2) it provides secure user connections by using RDP (and SSH), and (3) it provides a secure connection to an Azure VM via the Azure portal, aligning with Zero Trust principles by eliminating inbound RDP/SSH exposure on public IPs.

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.

Microsoft Defender for Office 365 is the Microsoft 365 solution designed to protect users from threats delivered through email and collaboration workloads. SCI training material explains that Defender for Office 365 protects Exchange Online, Microsoft Teams, SharePoint Online, and OneDrive for Business by detecting and blocking malware, phishing, and other advanced attacks that use messages and shared content as the delivery channel.

A key capability is Safe Links, which specifically protects against malicious URLs. When a user receives an email, Teams chat message, or channel post that contains a hyperlink, Safe Links scans and rewrites that URL. At the moment the user clicks, the link is checked again; if it is identified as malicious or leads to a known phishing or malware-hosting site, access is blocked and a warning page is shown. This time-of-click protection is emphasized in Microsoft’s security documentation as a primary defense against weaponized links in email and collaborative communications.

By comparison, Microsoft Defender for Identity focuses on detecting identity-related threats in on-premises Active Directory, Defender for Endpoint protects devices and endpoints, and Defender for Cloud Apps secures SaaS applications and shadow IT. None of these are the primary solution for blocking malicious links in email, chats, and channels. Therefore, the correct choice is Microsoft Defender for Office 365.

In Microsoft identity and access management terminology, federation refers to the establishment of a trust relationship between identity providers, which enables single sign-on (SSO) across different organizations or platforms.

According to the Microsoft Security, Compliance, and Identity (SCI) learning path, particularly in the SC-900 and SC-300 certifications, the following definition is provided:

“Federation is a means of establishing trust between two identity systems. This trust allows users from one domain to access resources in another domain without needing to authenticate again, typically using SAML, WS-Federation, or OAuth protocols.”

This concept is essential in cross-organization SSO scenarios, such as enabling users from one enterprise (or identity provider) to authenticate with services hosted in another, using existing credentials.

SCI documentation further states:

“Single sign-on (SSO) between multiple identity providers is enabled through federation protocols, which delegate authentication and allow token-based identity propagation across systems.”

The other options are not accurate in this context:

Integration is a vague term and not specific to SSO configuration.

Password hash synchronization and pass-through authentication are Azure AD authentication methods used for hybrid identity with on-premises AD, not for federating with external identity providers.

✅ Therefore, SSO configured between multiple identity providers is best classified as an example of federation.

In Microsoft identity architecture, federation establishes trust between different identity providers to enable single sign-on (SSO) across organizational and platform boundaries. Microsoft Learn explains that federation uses standards such as SAML, WS-Federation, and OpenID Connect/OAuth 2.0 so a user can authenticate with their home identity provider and obtain tokens that are accepted by a relying party (the application or service). This trust relationship lets organizations share identities securely without copying passwords or synchronizing credentials, providing a seamless sign-in experience across multiple systems and clouds.

By contrast, Active Directory Domain Services (AD DS) and a domain controller provide on-premises directory and authentication services primarily within a single Windows domain/forest using Kerberos/NTLM, not cross-provider SSO on their own. Microsoft Entra Privileged Identity Management (PIM) manages just-in-time, approval-based elevation for roles and does not deliver SSO capabilities. Therefore, the technology explicitly intended to provide SSO across multiple identity providers is federation.

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 Insider Risk Management is designed to identify, investigate, and act on risky activities by internal users—for example data exfiltration, data theft, policy violations, and user sentiments/signals that may indicate insider risk. SCI documentation explains that Insider Risk policies analyze signals such as file downloads, copying to USB, sharing to personal cloud, printing, or anomalous activity following events like performance warnings or resignation notices. Because it focuses on insider behaviors, it is not used to detect external threat vectors like phishing scams; those are addressed by Microsoft Defender for Office 365 and related anti-phishing protections—hence statement 1 is No. The solution is accessed in the Microsoft Purview (formerly Microsoft 365) compliance center under Insider risk management, where admins configure policies, alerts, and workflows—so statement 2 is Yes. Finally, its core purpose includes detecting and investigating potential data leaks by disgruntled or departing employees, using built-in policy templates (e.g., Data theft by departing employee, Data leaks), making statement 3 Yes.

Sensitivity labels can apply content markings (headers, footers, and watermarks) to documents and emails, and can also enforce encryption and access controls. When configuring a label, you can specify the watermark text, size, and placement so that protected content is visibly marked according to your organization’s policy.

In the Microsoft Cloud Adoption Framework (CAF) for Azure, the methodology is organized into sequential stages that guide an organization from initial intent through operations. Microsoft describes the flow as: “Strategy → Plan → Ready → Adopt → Govern → Manage.” The guidance explains that before building landing zones or preparing environments (Ready), organizations should complete the Strategy and Plan work. Microsoft states that the framework “helps you create and align your business strategy, define business outcomes, and justify cloud adoption” in the Strategy stage; then, in Plan, you “translate that strategy into an actionable adoption plan, rationalize portfolios, and prepare a cloud adoption backlog.” Only after these two stages does the Ready phase occur, where you “prepare your cloud environment (landing zone) to host the workloads.”

Additionally, CAF emphasizes that Govern and Manage are ongoing disciplines that operate alongside and after adoption rather than preceding Ready: “Govern and Manage provide iterative guardrails and operational baselines that evolve as you adopt more workloads.” Therefore, the two phases addressed before the Ready phase are Define Strategy and Plan, aligning with Microsoft’s prescribed order and intent of the Cloud Adoption Framework methodology.

In Microsoft’s Security, Compliance, and Identity learning content for Microsoft Defender for Cloud, the service is described as providing ongoing posture management and threat protection. The official description states that Defender for Cloud “continuously assesses your resources to identify security misconfigurations and weaknesses” and “continuously discovers and evaluates resources” across your subscriptions. The recommendations and secure-score updates are produced as the platform “continuously analyzes your environment using security policies and analytics,” surfacing issues the moment they’re detected and mapping them to remediation guidance. This continuous assessment model underpins Defender for Cloud’s cloud security posture management (CSPM) capability and ensures that newly created or modified resources are evaluated without waiting for a scheduled job. By design, there is no fixed interval (such as hourly, every 15 minutes, or daily) required to trigger assessments—policy-driven evaluation and data collection run as changes occur and signals are received. Therefore, the sentence “Microsoft Defender for Cloud assesses Azure resources ____ for security issues” is correctly completed with continuously, reflecting Microsoft’s emphasis on persistent, real-time security posture evaluation rather than periodic scans.

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.

In Microsoft guidance, network segmentation and isolation are core security principles. Azure virtual networks (VNets) are “a fundamental building block… that enable isolation and segmentation of resources,” and multiple VNets are commonly used to separate environments, business units, or security boundaries. This aligns with Zero Trust and SCI guidance that recommends isolating workloads to reduce blast radius and to apply least privilege and policy-based controls per boundary. Microsoft also emphasizes governance alignment, stating that enterprises should structure Azure resources so that policies, RBAC, and compliance requirements can be applied at appropriate scopes (management group, subscription, resource group, or network boundary). Deploying multiple VNets supports these goals by enabling per-environment policy assignment (for example, dev/test vs. production), differentiated security controls (such as NSGs, ASGs, and firewalls), and independent address spaces to prevent overlap across organizations or regions. Options A and D are not primary drivers: budgeting is handled at subscription/resource group scopes rather than VNet count, and a single VNet can already host and connect many resource types; creating multiple VNets is therefore primarily about governance and isolation that reduce risk and enforce organizational policies.

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.

 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 Cloud App Security (now Microsoft Defender for Cloud Apps) is Microsoft’s CASB that “discovers and controls shadow IT,” integrates with identity and endpoint signals, and enforces data protection in SaaS and custom apps. SCI materials describe three core use cases relevant here: (1) Discovery and control of shadow IT by analyzing network logs and app usage, rating risk, and applying governance—matching A. (2) Protect sensitive information hosted anywhere in the cloud via policies such as DLP, information protection label awareness, and integration with apps through API connectors—matching C. (3) Prevent data leaks to noncompliant apps and limit access to regulated data using Conditional Access App Control and session controls that can block download, apply protections, or monitor in real time—matching E. In contrast, secure connections to Azure virtual machines are provided by Azure Bastion, not the CASB (eliminating B), and pass-through authentication to on-premises apps is delivered by Azure AD features such as Azure AD Application Proxy or PTA (not Cloud App Security), eliminating D.

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.

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

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

Microsoft’s sensitivity labels (Microsoft Purview Information Protection) support user-driven labeling: “Users can manually apply sensitivity labels to files and emails” and organizations can also configure automatic or recommended labeling. This confirms that end users are permitted to choose a label themselves when policy allows. Microsoft also clarifies the cardinality for items: “A document or email can have only a single sensitivity label applied to it at a time.” Therefore, applying multiple sensitivity labels to the same file is not supported (labels are mutually exclusive on a given item). In addition to classification, labels can enforce protection and visual markings: “When you configure a sensitivity label, you can add protection settings such as encryption and content marking (headers, footers, and watermarks).” Word, Excel, and PowerPoint honor these content markings, so a label can automatically stamp a watermark on a Word document while embedding the label metadata for persistent protection. Together, these authoritative statements from Microsoft’s SCI documentation establish the correct responses: Yes (manual application), No (only one label per file), and Yes (labels can apply watermarks).

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

In Microsoft’s Security, Compliance, and Identity (SCI) learning content, Multi-Factor Authentication (MFA) is defined as requiring more than one verification method during sign-in. Microsoft states: “Multi-factor authentication (MFA) requires two or more verification methods” and Azure AD (Microsoft Entra ID) MFA “works by requiring two or more of the following: something you know (password), something you have (trusted device or token), something you are (biometrics).” The SCI fundamentals also explain that MFA strengthens authentication beyond a single password by combining distinct factor types, noting that “strong authentication uses at least two different factors to verify identity.”

When you enable Azure AD MFA, a user must successfully present two factors from those categories to complete the authentication—commonly a password (something you know) plus a second factor such as Microsoft Authenticator approval, a FIDO2 security key, SMS/voice code, or Windows Hello (something you have/are). This is the core of Azure AD’s risk-based and conditional access controls, which can require MFA based on conditions or risk signals. Therefore, the number of factors required after enabling Azure AD MFA is two, aligning with Microsoft’s definition and implementation of multi-factor authentication in Entra ID.

Microsoft’s Identity Protection provides risk-based detections and automated policies—not group management. Microsoft Learn explains that Identity Protection “uses detections to identify potential vulnerabilities affecting your organization’s identities” and exposes user risk and sign-in risk for policy decisions. It does not support adding users to groups by “risk level”; group membership is handled by static or dynamic rules based on directory attributes, while risk is a transient signal surfaced to policies.

Identity Protection includes specific detections such as “Leaked credentials”, where Microsoft’s threat intelligence finds credentials “on the dark web or other dumps,” and flags the affected account as risky. This directly confirms the ability to detect whether credentials have been exposed publicly.

For enforcement, Identity Protection policies and Conditional Access can require stronger authentication when risk is present. The documentation states that you can configure policies to “require multi-factor authentication for sign-ins assessed as risky” and use Conditional Access conditions like User risk or Sign-in risk with the grant control Require multi-factor authentication. Thus, Identity Protection signals can invoke MFA based on risk, but they do not place users into groups.

Biometrics templates are stored locally on a device. Reference:

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