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

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

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.

Microsoft states that Security defaults are baseline protections in Azure Active Directory (now Microsoft Entra ID) that “make it easier to help protect your organization from identity-related attacks.” One of the core behaviors is that security defaults “require all users to register for Azure AD Multi-Factor Authentication,” and enforce “multi-factor authentication for all users,” with special emphasis that “administrators are required to do multi-factor authentication.” Security defaults also “block legacy authentication” and add protections for privileged operations, but the universal control that applies to every user is MFA. Importantly, enabling security defaults does not turn on paid capabilities such as Azure AD Identity Protection or Privileged Identity Management (PIM); those are separate, premium features. The baseline is intentionally simple and tenant-wide: require MFA registration, challenge with MFA when risk or sensitive operations are detected, and reduce exposure by disabling legacy protocols. Therefore, when you enable security defaults, multi-factor authentication (MFA) will be enabled for all Azure AD users, aligning with Microsoft’s guidance that security defaults “help protect all organizations by requiring MFA and disabling legacy authentication.”

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.

Microsoft Purview Compliance Manager is a feature in the Microsoft Purview compliance portal that helps you manage your organization’s compliance requirements with greater ease and convenience. Compliance Manager can help you throughout your compliance journey, from taking inventory of your data protection risks to managing the complexities of implementing controls, staying current with regulations and certifications, and reporting to auditors.

Watch the video below to learn how Compliance Manager can help simplify how your organization manages compliance:

Compliance Manager helps simplify compliance and reduce risk by providing:

Pre-built assessments for common industry and regional standards and regulations, or custom assessments to meet your unique compliance needs (available assessments depend on your licensing agreement; learn more).

Workflow capabilities to help you efficiently complete your risk assessments through a single tool.

Detailed step-by-step guidance on suggested improvement actions to help you comply with the standards and regulations that are most relevant for your organization. For actions that are managed by Microsoft, you’ll see implementation details and audit results.

A risk-based compliance score to help you understand your compliance posture by measuring your progress in completing improvement actions.

Microsoft documents Information Barriers (IB) as a Microsoft Purview capability that “restricts communication and collaboration between specific groups of users” across Microsoft 365. The service coverage explicitly includes “Microsoft Teams, SharePoint, OneDrive, and Exchange Online.” In Exchange Online, IB policies “block communication” between segmented users, which includes sending or receiving email and related collaboration, thereby meeting the statement about restricting communication in Exchange.

With IB v2, Microsoft states that policies also apply to SharePoint and OneDrive so that users in different segments are “prevented from accessing sites and content” not permitted by policy. This means a SharePoint Online site can be segmented so that members outside the allowed segments are denied access, satisfying the second statement.

For Microsoft Teams, IB policies “restrict collaboration scenarios such as chats, channel conversations, and file sharing” when participants are in segments that shouldn’t interact. Because Teams file sharing is backed by SharePoint/OneDrive, IB v2 enforcement “prevents sharing and accessing files across restricted segments.” In effect, a user cannot share a file with another user in Teams if an IB policy disallows interaction between their segments.

These behaviors align with SCI guidance that IB policies are designed to reduce conflict-of-interest risk by controlling who can communicate, collaborate, or access content across Microsoft 365 workloads.

In Microsoft’s Security, Compliance, and Identity guidance, multi-factor authentication (MFA) is based on combining independent categories of credentials to verify a user. Microsoft describes the three factor types as: something you know (knowledge), something you have (possession), and something you are (inherence). A password is explicitly categorized as “something you know,” because it relies on a secret the user memorizes and types during sign-in. MFA improves security by requiring two or more of these distinct factors—e.g., a password (know) plus a phone approval or hardware token (have), or a biometric like Windows Hello (are). Using factors from different categories mitigates common attacks such as password spray, credential stuffing, and phishing, because compromising one factor (for example, the password) does not grant access without the second, unrelated factor. Microsoft recommends enabling MFA broadly and pairing passwords with stronger possession or inherence methods to achieve a measurable reduction in account compromise risk. Therefore, in the MFA model used by Microsoft Entra ID (Azure AD), a password is considered something you know.

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

Explanation

Azure AD Password Protection detects and blocks known weak passwords and their variants, and can also block additional weak terms that are specific to your organization.

With Azure AD Password Protection, default global banned password lists are automatically applied to all users in an Azure AD tenant. To support your own business and security needs, you can define entries in a custom banned password list.

 Enabling multi-factor authentication (MFA) increases the Microsoft Secure Score. Yes

 A higher Microsoft Secure Score means a lower identified risk level in the Microsoft 365 tenant. Yes

 Microsoft Secure Score measures progress in completing actions based on controls that include key regulations and standards for data protection and governance. No

Microsoft Secure Score is a measurement of an organization’s security posture in Microsoft 365. The SCI materials explain that Secure Score is calculated from improvement actions such as requiring multi-factor authentication for users, especially administrators. When you configure and enforce MFA, you complete one of these recommended actions, and Secure Score awards points, so enabling MFA directly increases Microsoft Secure Score.

The documentation further states that Secure Score reflects how many recommended security controls you have implemented. A higher score indicates that more recommended controls are in place, which reduces exposure to common threats and therefore represents a lower residual risk level in the tenant. While it is not an absolute guarantee of security, it is an indicator that risk has been reduced compared to a lower score.

The third statement, however, describes the purpose of Microsoft Purview Compliance Manager and its compliance score, which tracks progress against controls mapped to regulations and standards for data protection and governance. Secure Score does not measure alignment with regulatory frameworks; it is focused on technical security configurations and behaviors in Microsoft 365. Therefore, that statement is No.

In Microsoft 365 Defender, security signals from across Microsoft 365 services are raised as alerts. Microsoft’s documentation defines an incident as “a collection of correlated alerts” that represent the end-to-end story of an attack. The incident object aggregates the related signals, entities, and evidence so analysts can triage and remediate holistically rather than handling individual alerts in isolation. Microsoft further explains that incidents “group together related alerts, assets, users, and evidence” to reduce noise and provide context for investigation, and that automated correlation “helps SOCs focus on what matters most” by stitching alerts from Defender for Endpoint, Defender for Office 365, Defender for Identity, and Microsoft Defender for Cloud Apps into one case. Within an incident, analysts see a timeline, impacted assets and users, alert details, and recommended actions, and they can trigger response measures (for example, isolate device, block URL/file, or disable user). This contrasts with events (raw telemetry), vulnerabilities (exposure findings managed by Defender Vulnerability Management), and Microsoft Secure Score improvement actions (posture recommendations). Therefore, in the Microsoft 365 Defender portal, an incident is specifically a collection of correlated alerts, designed to streamline investigation and coordinated remediation across the Microsoft 365 security stack.

Microsoft’s official description of Azure Key Vault in the Security, Compliance, and Identity learning materials states that Key Vault is “a cloud service for securely storing and accessing secrets.” The same guidance clarifies that “a secret is anything you want to tightly control, such as API keys, passwords, or connection strings.” In addition to secrets, Key Vault provides key management: “Azure Key Vault helps safeguard cryptographic keys and secrets used by cloud applications and services.” It further explains that organizations can “generate, import, rotate, disable, and delete keys” and use them for operations such as “encrypt and decrypt, sign and verify, wrap and unwrap.” These excerpts confirm that Key Vault’s core capabilities include the secure storage and lifecycle management of secrets and cryptographic keys.

By contrast, the SCI content makes clear that infrastructure features like Azure DDoS Protection and Network Security Groups (NSGs) are networking/security controls delivered by Azure networking services, not Key Vault. Likewise, ARM templates are deployment artifacts stored in repositories such as Azure Repos or GitHub; Key Vault does not store or manage template files. Therefore, the two correct actions you can perform with Azure Key Vault—aligned with Microsoft’s documentation—are to store (and manage) keys and store (and manage) secrets.

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

In Microsoft Sentinel, automation is delivered through playbooks, which are built on Azure Logic Apps. Microsoft’s Sentinel documentation explains that playbooks “help automate and orchestrate your response to threats” and can be triggered by analytics alerts or incidents to run predefined actions. Typical automated tasks include “enriching alerts with data, blocking IP addresses, disabling users, or creating tickets,” allowing security teams to standardize and speed up their response and remediation processes. Sentinel also uses automation rules to decide when a playbook should run (for example, on incident creation or update), enabling consistent handling of common SOC tasks.

By contrast, the other options are not intended for automation: deep investigation tools are used to investigate incidents and entities; hunting search-and-query tools (built on KQL) are for proactive threat hunting rather than automating responses; and workbooks provide dashboards and visualizations for monitoring and reporting. Therefore, when the requirement is to automate common tasks—such as triggering actions across Microsoft 365 Defender, Azure, or third-party systems—the correct Sentinel capability is playbooks powered by Logic Apps. This aligns with the SCI guidance that emphasizes using Sentinel playbooks to “automate common workflows and response actions” and reduce manual effort while improving consistency and speed in security operations.

Microsoft Secure Score for Devices

Artikel

12.05.2022

3 Minuten Lesedauer

Applies to:

Microsoft Defender for Endpoint Plan 2

Microsoft Defender Vulnerability Management

Microsoft 365 Defender

Some information relates to pre-released product which may be substantially modified before it ' s commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.

To sign up for the Defender Vulnerability Management public preview or if you have any questions, contact us (mdvmtrial@microsoft.com).

Already have Microsoft Defender for Endpoint P2? Sign up for a free trial of the Defender Vulnerability Management Add-on.

Configuration score is now part of vulnerability management as Microsoft Secure Score for Devices.

Your score for devices is visible in the Defender Vulnerability Management dashboard of the Microsoft 365 Defender portal. A higher Microsoft Secure Score for Devices means your endpoints are more resilient from cybersecurity threat attacks. It reflects the collective security configuration state of your devices across the following categories:

Application

Operating system

Network

Accounts

Security controls

Select a category to go to the Security recommendations page and view the relevant recommendations.

Turn on the Microsoft Secure Score connector

Forward Microsoft Defender for Endpoint signals, giving Microsoft Secure Score visibility into the device security posture. Forwarded data is stored and processed in the same location as your Microsoft Secure Score data.

Changes might take up to a few hours to reflect in the dashboard.

In the navigation pane, go to Settings > Endpoints > General > Advanced features

Scroll down to Microsoft Secure Score and toggle the setting to On.

Select Save preferences.

How it works

Microsoft Secure Score for Devices currently supports configurations set via Group Policy. Due to the current partial Intune support, configurations which might have been set through Intune might show up as misconfigured. Contact your IT Administrator to verify the actual configuration status in case your organization is using Intune for secure configuration management.

The data in the Microsoft Secure Score for Devices card is the product of meticulous and ongoing vulnerability discovery process. It is aggregated with configuration discovery assessments that continuously:

Compare collected configurations to the collected benchmarks to discover misconfigured assets

Map configurations to vulnerabilities that can be remediated or partially remediated (risk reduction)

Collect and maintain best practice configuration benchmarks (vendors, security feeds, internal research teams)

Collect and monitor changes of security control configuration state from all assets

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 states that Microsoft Sentinel includes connectors for both Microsoft and non-Microsoft sources. The product overview explains that Sentinel “comes with built-in connectors” for services such as Microsoft 365, Defender, and Azure sources, and also built-in connectors for non-Microsoft solutions like firewalls and other security products. Therefore, the claim that data connectors support only Microsoft services is false.

For visualization and monitoring, the documentation clarifies that “Microsoft Sentinel uses Azure Monitor workbooks to provide rich visualizations of your data.” Workbooks are the native dashboarding framework in Sentinel and can be customized to monitor logs, incidents, and telemetry that Sentinel ingests. Hence, using Azure Monitor Workbooks to monitor data collected by Sentinel is true.

Regarding threat hunting, Microsoft describes the Hunting capability as a proactive feature: “Hunting lets you proactively hunt for security threats,” using Kusto Query Language queries and analytic patterns to find indicators of compromise before alerts are generated. Analysts can run, save, and schedule hunts to uncover suspicious activity that hasn’t yet raised an alert, making the statement about identifying threats before an alert is triggered true.

Microsoft’s identity guidance classifies social identity services (e.g., GitHub, Google, Facebook) as cloud-based identity providers that can be used for external identities with Microsoft Entra ID. In this model, GitHub functions as an IdP using OAuth/OpenID Connect to authenticate users and issue tokens that applications or Entra ID can accept. Federation in Microsoft terms is the trust relationship that allows SSO across organizational boundaries and with multiple identity providers, such as Active Directory Federation Services (AD FS), SAML, or OpenID Connect providers, so users can authenticate once and access multiple apps without repeated sign-ins.

Crucially, SCI materials distinguish roles: an identity provider primarily handles authentication (proving who the user is and issuing claims/tokens). Authorization—deciding what the user can do—is enforced by the application or resource (often using roles/claims from the IdP). Auditing spans multiple planes: the IdP provides sign-in and audit logs, while applications and other services maintain their own activity logs. Therefore, it is incorrect to say a central IdP “manages all modern authentication services” including authorization and auditing; those responsibilities are shared across the identity platform and the relying applications/resources.

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.

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.

In Microsoft Entra Conditional Access, policy evaluation occurs after the user successfully completes first-factor authentication (for example, username + password or Windows Hello for Business key). Microsoft Learn explains that Conditional Access “is the tool used by Azure AD to bring signals together, make decisions, and enforce organizational policies” and that it’s applied “after the first-factor authentication is completed.” Once primary authentication succeeds, Conditional Access evaluates signals like user, device state, location, risk (from Identity Protection), and application, and then enforces controls such as requiring MFA, blocking access, or applying session controls.

This design ensures Conditional Access does not replace primary authentication and is not enforced before or during the initial credential verification. Instead, it adds a second policy decision point that can demand stronger proof (e.g., MFA), restrict access paths, or limit sessions. Therefore, “after” is correct, while “before,” “during,” or “instead of” first-factor authentication are incorrect because Conditional Access relies on the initial sign-in to collect the necessary signals and then applies the configured access decisions and protections.

Microsoft Learn explains that Azure Active Directory (now Microsoft Entra ID) is a Microsoft-managed identity and access management service delivered from the cloud. It does not require you to provision or host infrastructure such as virtual machines; the directory is operated as a service by Microsoft, and tenants are created and administered within Microsoft’s cloud environment. The official learning paths further clarify that administration is performed through the Azure portal (the Entra/Microsoft Entra admin center and Azure portal blades), PowerShell, and Graph—so managing a tenant in the Azure portal is fully supported.

Regarding licensing, Microsoft’s SCI study materials detail that Azure AD/Entra ID is offered in multiple editions (Free, Microsoft 365 apps edition, Premium P1, and Premium P2). Each edition unlocks different capabilities: for example, features like Conditional Access are in Premium tiers; Identity Protection and Privileged Identity Management (PIM) are P2 capabilities. Because capabilities vary by tier, the statement that all license editions include the same features is incorrect.

Putting this together: feature parity across editions is not the case (No); tenant management in the Azure portal is supported (Yes); and you do not need to deploy Azure VMs to host an Azure AD/Entra ID tenant (No).

Within Microsoft Purview, Insider Risk Management is the solution that is explicitly designed to detect activities such as IP theft and data leakage. Microsoft describes it as a compliance solution that correlates many user and system signals to identify potentially malicious or inadvertent insider risks, including leaks of sensitive data and data spillage.

Organizations create Insider Risk Management policies that watch for risky behaviors such as unusual file downloads, copying data to removable media, or sharing sensitive information to external locations. When configured with templates like Data leaks, these policies can use high-severity alerts from Data Loss Prevention (DLP) policies as triggers, so that suspected data-leak events automatically generate alerts and cases for investigation. This workflow lets investigators quickly triage, investigate, and remediate possible data-exfiltration incidents.

The other options serve different purposes. Compliance Manager evaluates and tracks compliance posture against regulations and internal controls, rather than monitoring user behavior for leaks. Communication compliance focuses on inappropriate or non-compliant messages (such as harassment or improper sharing in chats and email). eDiscovery is used to find and preserve existing content for legal or investigative cases, not for proactive detection of leakage as it occurs.

Therefore, the Microsoft Purview solution used to identify data leakage is Insider Risk Management.

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.

Azure AD Identity Protection (now part of Microsoft Entra ID) is the Microsoft service that “automates the detection and remediation of identity-based risks.” It continuously evaluates user risk and sign-in risk using signals such as leaked credentials, atypical travel, unfamiliar sign-in properties, and malware-linked IPs. Microsoft documentation clarifies that Identity Protection “uses adaptive machine learning and heuristics to detect risky behaviors and sign-ins” and enables administrators to configure risk-based policies (for example, require MFA or block access) to automatically respond. It also provides rich investigations through risk reports so security teams can triage and remediate compromised identities. This distinctly differs from other Entra capabilities: Privileged Identity Management (PIM) governs just-in-time privileged access and role activation, while MFA is an authentication method enforced by policies. Because the service that specifically detects risk and applies automated protection based on risk is Azure AD Identity Protection, it is the correct completion for the sentence about identity risk detection and remediation.QUESTION NO: 148 HOTSPOT

Select the answer that correctly completes the sentence.

Answer: < map > < m x1= " 491 " x2= " 699 " y1= " 63 " y2= " 79 " ss= " 0 " a= " 0 " / > < /map >

In Microsoft’s SCI guidance, Insider risk management is a Microsoft Purview capability surfaced and administered from the Microsoft Purview compliance portal. The official description states that Insider risk management “helps you minimize internal risks by enabling you to detect, investigate, and act on risky activities in your organization.” Microsoft further clarifies access and configuration by directing admins to “use the Microsoft Purview compliance portal to configure and manage insider risk policies, alerts, and investigations,” and that you can “go to the Microsoft Purview compliance portal and select Insider risk management” to start. These statements place the feature squarely in the compliance plane—not the Microsoft 365 admin center (tenant-wide service management), not the Microsoft 365 Defender portal (threat protection and incident response), and not Microsoft Defender for Cloud Apps (app discovery and cloud app protection). In the SCI learning path, Insider risk is consistently grouped with Microsoft Purview solutions (Information Protection, DLP, eDiscovery, and Audit), emphasizing compliance workflows, risk indicators, policy tuning, and case management. Therefore, the correct completion of the sentence “Insider risk management is configured from the” is the Microsoft Purview compliance portal, where administrators create policies, review alerts, investigate user activity timelines, and take appropriate remediation actions within a compliance-centric experience.

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

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.

Azure DDoS Protection Standard is a platform-native service designed to mitigate distributed denial of service attacks against Azure-hosted workloads that expose public IP addresses. Microsoft’s guidance explains that DDoS Protection Standard is “enabled on a virtual network” and, once enabled, “automatically protects resources within the virtual network with public IP addresses” (for example, Application Gateway, Azure Load Balancer, and virtual machines). The service is “tuned to the traffic patterns of the protected resources” and provides adaptive real-time mitigation with telemetry and attack analytics.

Critically, the scope of enablement is at the virtual network (VNet) level, not at the resource group level, and it does not apply to Azure Active Directory (Microsoft Entra ID) users or applications, which are identity services rather than network resources. Microsoft’s materials emphasize that by associating a DDoS protection plan to a VNet, you “protect all public IPs assigned to resources in that VNet”, giving layered protection alongside Azure’s always-on basic protections.

Therefore, the only option that correctly completes the sentence is virtual networks, because Azure DDoS Protection Standard is configured on, and provides coverage for, resources inside a VNet that have public endpoints—exactly matching Microsoft’s SCI/Azure security documentation.

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 V Ms (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’s SCI/Learn content describes Azure AD (now Microsoft Entra ID) as a cloud service, not something you install on-premises. The docs state Azure AD is a “cloud-based identity and access management service” that “helps your employees sign in and access resources.” This clarifies the third statement (IAM service) as Yes, and the first statement (on-premises deployment) as No, because the native on-prem directory is Windows Server Active Directory, whereas Azure AD runs in Microsoft’s cloud and can be synchronized with on-prem AD via tools like Azure AD Connect.

Microsoft also explains licensing/availability: the service comes in several editions, and the free/Office 365 tier is included with many suites. The documentation explicitly notes that Azure AD is “included with subscriptions such as Microsoft 365” (formerly Office 365) and provides tenant-wide identity for those services. Therefore, stating that Azure AD is provided as part of a Microsoft 365 subscription is Yes.

In summary: Azure AD/Entra ID is a cloud identity and access management platform; it’s not deployed on-premises, and Microsoft 365 subscriptions include an Azure AD tenant/edition to manage users, groups, apps, and access policies.

Azure Blueprints allow cloud architects and central IT to define a repeatable set of Azure resources and governance artifacts—including Azure Policy assignments, role assignments (RBAC), resource groups, and ARM/Bicep templates—and then deploy them consistently across subscriptions. Microsoft’s guidance describes Blueprints as a way to “orchestrate the deployment of various resource templates and other artifacts” to establish standards, patterns, and compliance for environments at scale. This is distinct from Azure Policy, which evaluates and enforces configuration but does not package multi-artifact environments; Microsoft Sentinel and Defender are security analytics/protection services rather than provisioning frameworks. Thus, for consistent provisioning across multiple subscriptions, the prescribed solution is Azure Blueprints.

Azure Bastion is a managed PaaS service that provides secure and seamless RDP/SSH connectivity to your Azure virtual machines directly from the Azure portal over TLS/HTTPS. SCI and Azure security documentation summarize it as eliminating public IP exposure on VMs by using a fully managed bastion host deployed inside your virtual network. Users connect through their browser and the service brokers the RDP or SSH session, which “protects your VMs from exposing RDP/SSH to the Internet.” Bastion does not provide access to Azure Files, SQL Managed Instance, or App Service; it is specifically built to secure management access to VMs without requiring a VPN or public endpoints. Therefore, the resource type Azure Bastion securely connects to is Azure virtual machines.

When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.

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

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.

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.

Microsoft explains that Conditional Access (CA) evaluates signals and then enforces access decisions using grant and session controls: “Conditional Access policies are enforced after first-factor authentication is completed” and are used to “make access control decisions.” CA policies target users and groups—including administrators—unless explicitly excluded. Microsoft guidance recommends excluding only break-glass accounts: “Customers with Azure AD roles such as Global administrator should have at least one emergency access account excluded from policies.” This means admins are not exempt by default; they are in scope unless you configure exclusions.

CA does not manage directory role assignments; that is handled by role assignment and Privileged Identity Management (PIM). CA’s grant controls focus on access conditions: “Grant access… Require multi-factor authentication” and Microsoft lists a common baseline: “Require multi-factor authentication for all users.” Therefore, CA can require MFA to access cloud apps, but it cannot add users to Azure AD roles.

These statements from Microsoft’s SCI materials confirm the outcomes: Admins are not inherently exempt (No), CA cannot assign roles (No), and CA can force MFA for app access (Yes).

To on-board Azure Sentinel, you first need to connect to your security sources. Azure Sentinel comes with a number of connectors for Microsoft solutions, including Microsoft 365 Defender solutions, and Microsoft 365 sources, including Office 365, Azure AD, Microsoft Defender for Identity, and Microsoft Cloud App Security, etc.

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

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

Onboarding Microsoft Sentinel starts by enabling Sentinel on an existing Log Analytics workspace and then connecting data sources so analytics can operate on ingested security data. Microsoft’s Sentinel onboarding guidance emphasizes that after you add Sentinel to a workspace, you must “connect Microsoft services, non-Microsoft solutions, and custom sources” using built-in data connectors. Microsoft also states that “you need data in your workspace before you can use Microsoft Sentinel’s analytics, hunting, and investigation capabilities.” Features such as custom analytics rules, hunting queries, and incident correlation depend on ingested telemetry from sources like Microsoft Entra ID sign-in logs, Microsoft 365, Defender products, firewalls, and other appliances. Because the question already gives you a Log Analytics workspace (the prerequisite for enabling Sentinel), the first action in the onboarding workflow that unlocks Sentinel’s value is to connect your security sources. Only after data is flowing should you proceed to create analytics rules, hunting queries, and incident processes. Therefore, the correct first step to onboard Microsoft Sentinel is connect to your security sources.

In Microsoft’s SCI guidance, encryption at rest is defined as protecting data when it is stored on a disk or other persistent media. Microsoft describes it as controls that “help safeguard your data to meet your organizational security and compliance commitments by encrypting data when it is persisted,” distinguishing it from protections for data in transit. Within Azure and Microsoft 365, examples include Azure Disk Encryption for IaaS VMs (using BitLocker for Windows and DM-Crypt for Linux), server-side encryption for storage accounts, and Transparent Data Encryption for databases. A virtual machine’s OS and data disks encrypted with BitLocker or DM-Crypt are canonical cases of at-rest encryption because the encryption keys protect the physical media; the data becomes unreadable if the disks are accessed outside the authorized context. By contrast, site-to-site VPN, HTTPS web sessions, and encrypted email protect data in transit—they secure network communications but do not encrypt the data where it is stored. Therefore, among the options provided, encrypting a virtual machine disk is the correct example of encryption at rest in Microsoft’s security model.

In Microsoft 365, the unified audit log retention depends on the audit tier included with the subscription. Current SCI/Compliance documentation states that Audit (Standard)—which is available with Microsoft 365 E3—retains audit records for 180 days. The docs describe that organizations with E3 receive “up to 180 days of audit log retention” for user and admin activities captured in the unified audit pipeline. Longer retention (for example 365 days and beyond with customizable policies) is part of Audit (Premium) features generally associated with E5/E5 Compliance. Because the scenario specifies a Microsoft 365 E3 subscription using the unified audit log and Basic/Standard Audit, the retention period for audit records is 180 days.

No

No

Yes

Microsoft states that Communication Compliance is administered in Microsoft Purview, not the Microsoft 365 admin center. The Learn article shows configuration and policy templates “in the Microsoft Purview portal” and directs admins to “configure Communication Compliance” there, confirming the management plane is the Purview compliance portal, not the M365 admin center.

Regarding supported locations, Microsoft lists the communication channels that policies can inspect: “Microsoft Teams… Exchange Online… Viva Engage… [and] Third-party sources.” SharePoint Online is not listed among supported channels, so SharePoint content isn’t monitored by Communication Compliance policies.

Finally, Communication Compliance includes built-in workflows to address findings. The Learn page explicitly provides a Remediate step: “Remediate Communication Compliance issues you investigate by using the following options:” such as “Notify the user” and “Escalate to another reviewer.” These actions demonstrate that the solution does more than detect; it supports remediation within the Purview portal workflow.

Exact extracts (selected):

“You can choose from the following policy templates in the Microsoft Purview portal.”

“Communication Compliance policies check… Microsoft Teams… Exchange Online… Viva Engage… Third-party sources.”

“Remediate Communication Compliance issues you investigate by using the following options: Notify the user… Escalate to another reviewer.”

In Microsoft 365 Defender (Microsoft 365 security center), Incidents are designed to consolidate and correlate security signals so analysts can see the full scope of an attack. Microsoft’s documentation explains that an incident is “a collection of related alerts that, when viewed together, provide a richer context for the attack and its impact.” The service “automatically groups alerts that are likely to be associated with the same threat activity,” which allows security teams to investigate a single incident rather than many fragmented alerts. Microsoft further notes that incidents “aggregate alerts, affected assets (users, devices, mailboxes), evidences, and entities into one view,” helping analysts triage, investigate, and remediate more efficiently.

This is distinct from other areas in the portal: Reports provide trend and posture reporting; Hunting offers proactive, query-based threat hunting across raw data; and Attack simulator (in Defender for Office 365) is used to run training and awareness simulations (e.g., phishing), not to aggregate real alerts. Therefore, when you need to “view an aggregation of alerts that relate to the same attack” in the Microsoft 365 security center, the correct place is Incidents, which presents the correlated attack story and enables end-to-end response and remediation from a single, consolidated record.

Microsoft 365 Endpoint Data Loss Prevention (Endpoint DLP) extends DLP controls directly to supported desktops. Microsoft states: “Endpoint DLP extends the activity monitoring and protection capabilities of DLP to Windows 10 (and later) devices.” The platform coverage is explicitly broadened to Apple desktops: “Endpoint DLP for macOS enables the same set of DLP capabilities on macOS devices (supported versions) so you can monitor and protect sensitive items across Windows and Mac endpoints.” At the same time, Microsoft clarifies the mobile scope: “Endpoint DLP is supported on Windows and macOS devices.” This means Android is not a supported operating system for Endpoint DLP (mobile data protection on Android uses different controls such as app protection policies via Microsoft Intune and conditional access). Therefore, the correct pairing of operating systems for Endpoint DLP support is Windows 10 and newer, and macOS—not Android. This aligns with Microsoft’s Endpoint DLP platform support guidance and the intended desktop-focused endpoint protections for activities such as file copy, print, upload, and removable media interactions.

In Microsoft’s Security, Compliance, and Identity materials, Customer Lockbox is described as the feature that controls any Microsoft engineer access to your tenant content during support operations. Microsoft states that Customer Lockbox “ensures that Microsoft cannot access your content to perform a service operation without your explicit approval.” It is specifically applicable to Microsoft 365 workloads that store customer data, including “Exchange Online, SharePoint Online, and OneDrive for Business.” When a support case requires elevated access, “a lockbox request is created and routed to the customer for approval or rejection,” and access is only granted if the organization’s authorized admin approves the request within the defined window. The request contains who is requesting access, the reason, the scope, and the duration, and all actions are audited for compliance reporting. This capability aligns with Microsoft’s zero standing access principles by making engineer access time-bound, least-privileged, and customer-approved. By contrast, Information barriers segregate communications between groups, Privileged Access Management (PAM) governs privileged tasks inside Microsoft 365, and Sensitivity labels classify and protect data. Therefore, the feature that “can be used to provide Microsoft Support Engineers with access to an organization’s data stored in Microsoft Exchange Online, SharePoint Online, and OneDrive for Business” is Customer Lockbox.

In Microsoft’s Security, Compliance, and Identity guidance, Microsoft Cloud App Security (now Microsoft Defender for Cloud Apps) integrates with Azure AD Conditional Access to provide Conditional Access App Control. This capability enables organizations to “monitor and control user sessions in real time” by routing traffic through a reverse proxy once a Conditional Access policy is triggered. With session controls, admins can enforce actions such as block, allow with inspection, apply download restrictions, require label application, or limit access to web apps based on context (user, device state, location, risk). SCI learning paths describe that Defender for Cloud Apps works with Conditional Access policies to provide session-based conditional access that “protects data in real time,” giving granular control after authentication while a session is active.

By comparison, Azure AD Privileged Identity Management (PIM) focuses on just-in-time elevation and governance of privileged roles, not real-time in-app session control. Azure Defender (Defender for Cloud) provides cloud workload protection and posture management, not Conditional Access session enforcement. Azure Sentinel (Microsoft Sentinel) is a SIEM/SOAR platform for analytics, hunting, and automation and does not apply Conditional Access session policies. Therefore, the Microsoft product that uses Conditional Access policies to control sessions in real time is Microsoft Cloud App Security (Defender for Cloud Apps).

Microsoft describes hybrid identity as integrating on-premises Active Directory with Microsoft Entra ID (Azure AD) so that “your on-premises identities are synchronized to Azure AD” for a single identity across cloud and on-prem apps. In this model, directory objects (users, groups, and selected attributes) flow from on-premises AD to Azure AD using Azure AD Connect or Cloud Sync; this is the canonical direction for provisioning in hybrid environments. Microsoft further explains that while certain writeback features (such as password writeback, device or group writeback scenarios) are supported, cloud-created users do not automatically sync down to on-premises AD; account provisioning remains authoritative on-prem unless you deploy specific, limited writeback features—there is no default “user account creation from Azure AD to AD DS.” For authentication, Microsoft states that hybrid identity supports cloud authentication (Password Hash Synchronization or Pass-through Authentication) where Azure AD performs the sign-in, or federation with another identity provider (e.g., AD FS or a third-party IdP) where that provider validates credentials and issues tokens to Azure AD. These statements align with Microsoft’s SCI guidance on hybrid identity: on-prem to cloud sync is standard; automatic reverse user sync is not; and authentication can be handled by Azure AD or a federated IdP depending on the chosen sign-in method.

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.

Box 1: Yes

Azure Defender provides security alerts and advanced threat protection for virtual machines, SQL databases, containers, web applications, your network, your storage, and more

Box 2: Yes

Cloud security posture management (CSPM) is available for free to all Azure users.

Box 3: Yes

Azure Security Center is a unified infrastructure security management system that strengthens the security posture of your data centers, and provides advanced threat protection across your hybrid workloads in the cloud - whether they ' re in Azure or not - as well as on premises.

Microsoft 365 Endpoint Data Loss Prevention (Endpoint DLP) extends DLP controls to endpoints. Microsoft documentation describes Endpoint DLP as applying protections on “Windows 10/11 devices” (and, in current guidance, also macOS). The feature monitors and restricts actions like copying to USB, printing, or uploading to the web when sensitive items are involved. Importantly, Microsoft does not document Endpoint DLP support for iOS or Android; those platforms are governed through app protection policies in Intune and Microsoft Defender for Endpoint mobile capabilities, not Endpoint DLP. Given the answer choices provided, the only correct option that aligns with Microsoft’s Endpoint DLP platform support and excludes unsupported mobile OSs is Windows 10 only (noting that Microsoft also supports Windows 11 and macOS today, which are absent from the choices). Therefore, among the listed options, Windows 10 only is the correct selection because Endpoint DLP does not run on iOS or Android.

When you register an application through the Azure portal, an application object and service principal are automatically created in your home directory or tenant.

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.

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