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

Microsoft Defender for Endpoint includes Automated investigation and remediation (AIR) and Attack surface reduction (ASR) as core capabilities. Microsoft’s guidance states that AIR “uses inspection algorithms and playbooks to examine alerts, determine if they are malicious, and then take remediation actions such as stopping processes, quarantining files, and rolling back changes.” It is designed to “reduce the volume of alerts that require analyst attention and to remediate threats at machine speed across your estate,” helping security teams contain and fix issues without manual intervention.

Defender for Endpoint also provides attack surface reduction features to proactively limit exposure. The Microsoft learn materials describe that ASR “helps organizations minimize areas that attackers can exploit,” and includes “attack surface reduction rules, network protection, web protection, application control (Windows Defender Application Control), and controlled folder access.” These controls “block or constrain risky behaviors and common attacker techniques,” thereby preventing many initial compromise and lateral-movement attempts before they generate incidents.

By contrast, transport encryption is a general platform/security baseline capability rather than a specific Defender for Endpoint feature, and shadow IT detection is addressed through Microsoft Defender for Cloud Apps (App discovery), which can use Defender for Endpoint network signals but is not itself a native MDE capability. Therefore, the two correct capabilities of Microsoft Defender for Endpoint are Automated investigation and remediation and Attack surface reduction.

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.

In Microsoft’s Security, Compliance, and Identity portfolio, Microsoft Defender for Cloud Apps (formerly Microsoft Cloud App Security) integrates directly with Microsoft Entra Conditional Access to provide Conditional Access App Control—Microsoft’s real-time session control. Microsoft’s documentation describes this capability as enabling organizations to “monitor and control user sessions in real time” and to “protect downloads, restrict uploads, block copy/paste and print, and apply access or session policies” for sanctioned and unsanctioned applications. The enforcement is achieved through a reverse-proxy session that is invoked by Conditional Access policy decisions, allowing continuous inspection and dynamic controls after authentication.

By contrast, other options in the list do not offer real-time session enforcement via Conditional Access. Azure AD Privileged Identity Management (PIM) focuses on just-in-time role activation, approval workflows, and access reviews for privileged accounts—not session control of app usage. Microsoft Defender for Cloud provides cloud security posture management and workload protection across Azure, multicloud, and hybrid resources—again, not Conditional Access–based user session governance. Microsoft Sentinel is a SIEM/SOAR solution used for ingestion, detection, investigation, and response; it does not apply Conditional Access policies to control user sessions. Therefore, the service that can use Conditional Access policies to control sessions in real time is Microsoft Defender for Cloud Apps through Conditional Access App Control.

Azure Firewall is a managed, cloud-based network security service designed to secure traffic inside and across Azure Virtual Networks. Microsoft describes Azure Firewall as a stateful firewall that “protects Azure Virtual Network resources” by enforcing network and application rules, central logging, and threat intelligence–based filtering. Because it is deployed into a VNet/subnet (often as the hub in a hub-and-spoke), it directly governs East/West and North/South flows to workloads such as Azure virtual machines and platform services reachable through the VNet, using DNAT/SNAT and rule collections. Microsoft guidance highlights capabilities to “centrally create, enforce, and log application and network connectivity policies across subscriptions and virtual networks,” and to filter traffic for peered VNets, branch connections (VPN/ExpressRoute), and internet traffic. These capabilities explicitly map to protecting Azure virtual networks and the VMs and subnets inside them. In contrast, Azure AD users, Exchange Online inboxes, and SharePoint Online sites are SaaS/identity resources protected by Microsoft Entra controls, Exchange/SharePoint security, and Purview/Defender for Office 365—not by a VNet firewall. Therefore, the Azure Firewall–protectable resource types among the options are Azure virtual machines and Azure virtual networks.

Microsoft Entra Conditional Access evaluates signals to make real-time access decisions. Microsoft describes it as bringing “signals together to make decisions and enforce organizational policies,” where administrators choose controls such as Block access, Require multi-factor authentication, Require device to be marked as compliant, or Require hybrid Azure AD joined device. Because MFA is only one of several grant controls, it is incorrect that policies always enforce MFA; they can also simply block, allow, or require other conditions.

Location is a first-class condition. Microsoft states you can define named locations (by countries/regions or IP ranges) and then use them in policy conditions to block or grant access. A common scenario is “Block access from specific locations” or require additional controls when a sign-in originates from an untrusted network. Therefore, Conditional Access can block access to an application based on user location.

Finally, Conditional Access targets users, groups, workload identities, and cloud apps regardless of device join state. Device-related conditions and filters are optional; policies are not limited to “Azure AD-joined devices.” Controls like Require device to be marked as compliant or Require Hybrid Azure AD joined device are only enforced if configured. Hence, Conditional Access does not only affect users on Azure AD-joined devices.

According to Microsoft’s Security, Compliance, and Identity (SCI) documentation and learning paths (specifically SC-900, SC-300, and Azure AD Identity Protection modules):

“Conditional Access policies in Azure AD are the primary method for enforcing access controls based on specific conditions such as user, group, location, device compliance, and application.”

In this case, the organization can configure a Conditional Access policy that targets a specific Azure AD group and requires MFA as a condition before access is granted. The typical policy setup includes:

Assignments: Target users or groups (e.g., “Finance Department Users”).

Cloud apps or actions: Specify which applications or services are protected (e.g., Microsoft 365).

Access controls: Set the control to “Require multi-factor authentication.”

Microsoft’s SCI training materials further state:

“Conditional Access enables administrators to enforce MFA for specific users, groups, or scenarios. It provides flexibility to protect access without enabling MFA globally for all users.”

Other options explained:

Azure Policy (A) applies to Azure resources, not user authentication.

Communication compliance policy (B) monitors message content for compliance violations.

User risk policy (D) is part of Azure AD Identity Protection, enforcing MFA based on detected user risk levels, not group membership.

Therefore, the verified and correct answer is: ✅ C. a Conditional Access policy.

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.

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

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

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

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

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

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 Entra Conditional Access (CA) evaluates signals from the user, device, location, and risk to make access decisions. The platform explicitly notes that CA decisions occur after primary sign-in: “Conditional Access policies are enforced after the first-factor authentication has been completed.” This means a user must successfully present their initial credentials (e.g., password, Windows Hello, FIDO2) before the CA engine evaluates policy logic. Therefore, the statement that CA is evaluated before a user is authenticated is not correct.

Regarding scoping, CA can target ordinary and privileged identities. The assignment options allow administrators to aim policies at users, groups, and directory roles: “You can include or exclude users and groups… [and] include or exclude specific Azure AD directory roles from a Conditional Access policy.” Because Global Administrator is a directory role, policies can be applied to those accounts (with Microsoft’s best-practice guidance to maintain at least one excluded break-glass account to prevent lockout).

For signals/conditions, CA supports device platform filtering. The documented device platform condition states: “This condition is based on the operating system platform of the device… iOS, Android, Windows, macOS (and others).” Administrators commonly use this to require different controls (like MFA or compliant device) based on Android or iOS.

Putting these together:

CA can apply to Global Administrators (Yes).

CA is evaluated after first-factor authentication (No to “before”).

Device platform (e.g., Android/iOS) is a valid CA signal (Yes).

In Microsoft’s Security, Compliance, and Identity guidance, Microsoft Defender for Identity (formerly Azure ATP) is explicitly described as “a cloud-based security solution that leverages your on-premises Active Directory signals to identify, detect, and investigate advanced threats.” The service deploys lightweight sensors on domain controllers to collect and analyze Active Directory (AD) authentication and activity data. Using behavioral analytics and built-in detections, it helps security teams surface indicators of compromised identities, lateral movement, pass-the-ticket/NTLM relay, and other identity-driven attack techniques. Documentation further explains that Defender for Identity “profiles and learns entity behavior,” correlates events, and raises security alerts with investigation timelines and evidence to accelerate incident response in hybrid environments.

This precisely matches the sentence in the prompt: the only Microsoft security product whose core purpose is to use on-premises AD signals to identify, detect, and investigate advanced threats is Defender for Identity. By contrast, Microsoft Defender for Endpoint focuses on endpoint prevention and EDR; Microsoft Defender for Office 365 protects email and collaboration workloads from phishing and malware; and Microsoft Cloud App Security (now Microsoft Defender for Cloud Apps) operates as a CASB for app discovery, control, and session monitoring. Therefore, aligning with SCI study guides and product descriptions, the correct completion is Microsoft Defender for Identity.

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.

Explanation

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

Microsoft’s Conditional Access (part of Microsoft Entra ID) evaluates multiple signals to make access decisions. The official description lists typical signals such as “user or group membership, IP location information, device state, application, and real-time risk.” The device state element explicitly refers to conditions like “compliant or hybrid Azure AD joined devices,” allowing policies that grant or block access—or require extra controls—based on whether a device meets compliance/registration requirements.

Regarding evaluation timing, Microsoft’s guidance states that Conditional Access “policies are enforced after the first-factor authentication is completed.” This means the engine needs the user’s primary sign-in context (who the user is and how they authenticated) to evaluate the conditions and then decide whether to allow, block, or require additional controls. Therefore, the statement that policies apply before first factor is not correct.

Finally, Conditional Access includes grant controls such as “Require multi-factor authentication,” and policies can be scoped to specific cloud apps or actions. As a result, you can target a particular application and require MFA when a user attempts to access it, satisfying application-specific risk mitigation while preserving user productivity.

Microsoft documents describe Microsoft Entra Privileged Identity Management (PIM) as the service that delivers approval-based, time-limited elevation to privileged roles. Official guidance states: “Privileged Identity Management (PIM) enables you to manage, control, and monitor access to important resources in Microsoft Entra ID, Azure, and Microsoft 365.” PIM specifically supports just-in-time and time-bound activations: “PIM provides just-in-time privileged access to Microsoft Entra roles and Azure resources” and “allows you to make access time-bound by setting start and end dates.” It also supports approval workflows: “You can require approval to activate privileged roles, and designate approvers to receive and approve requests.” Additional controls include “require multi-factor authentication to activate, provide a justification, and ticket number,” and auditing: “PIM records all activations and changes for review and alerting.”

By contrast, Microsoft Entra ID Protection focuses on risk detections and automated remediation, not role elevation workflows. Conditional Access enforces access policies at sign-in and session but does not provide approval-based role activation. Access Reviews help you “review and attest to continued access” but do not supply just-in-time elevation. Therefore, the Microsoft Purview/Entra feature that implements approval-based, time-bound role activation is Microsoft Entra Privileged Identity Management (PIM).

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.

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.

In the Microsoft 365 Defender (Microsoft Defender XDR) portal, the Reports area is the feature designed to surface security trends and provide protection status views across workloads, including identities. Microsoft guidance explains that the Reports workspace offers curated dashboards and exportable reports for specific domains (for example, Identities, Email & collaboration, Endpoints), so security teams can review trend lines, coverage/health, and status without running queries. For identities specifically (backed by Microsoft Defender for Identity), the reports include overview dashboards and scheduled/on-demand reports that show items such as identity security posture, open health issues, alert volumes over time, and sensor/coverage status. This aligns with SCI learning paths that distinguish portal areas by purpose: Secure score is a measurement of overall posture and recommended actions, Incidents is for triage and response to individual cases, and Hunting is for ad-hoc, query-driven investigations. When the task is to “view security trends and track the protection status of identities,” Microsoft directs administrators to the Reports > Identities experience in the Defender portal, which provides the built-in, continuously updated visualizations and summaries required for ongoing monitoring.

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

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

Microsoft states that Azure Bastion is a fully managed PaaS service that provides “secure and seamless RDP/SSH connectivity to your virtual machines directly in the Azure portal over SSL” and “eliminates the need to expose public IP addresses on your VMs.” With Bastion, users open the VM blade in the Azure portal and launch an in-browser RDP or SSH session; no separate RDP or SSH client is required because the session is proxied through Bastion using HTTPS/TLS. The platform is designed to be agentless and browser-based, providing connectivity without VPN or jump hosts and enforcing least-exposure by keeping management ports off the internet. While traditional tools such as Remote Desktop Connection or an SSH client are common for direct access, Bastion’s prescribed access method in Microsoft guidance is to initiate the session from the Azure portal. PowerShell remoting is unrelated to Bastion’s web-based brokering. Therefore, to connect to an Azure virtual machine by using Azure Bastion, you use the Azure portal.

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

In Microsoft Sentinel, Logic Apps are used as playbooks for automation and orchestration (SOAR)—to take actions after alerts/incidents occur (notify, enrich, remediate). They are not the component that detects or identifies anomalies; detections come from analytics rules, UEBA (user and entity behavior analytics), Fusion (ML-powered correlation), and anomaly rules. Workbooks are interactive dashboards and visualizations for monitoring and reporting; they don’t correlate alerts. Correlation of alerts into incidents is handled by analytics rules (including alert grouping and Fusion) within Sentinel’s detection pipeline. Finally, Sentinel’s Hunting experience provides KQL-based queries and templates that are mapped to the MITRE ATT&CK tactics/techniques, enabling analysts to explore threats in a framework-aligned way. Thus, automation via Logic Apps ≠ anomaly detection; Workbooks ≠ incident correlation; Hunting tooling does align to MITRE ATT&CK.

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.

Microsoft’s security guidance for hybrid and cloud environments adopts the Zero Trust approach, which explicitly positions identity as the primary boundary for access decisions. Microsoft states that in modern, distributed environments, “the traditional network perimeter is no longer sufficient” and that identity becomes the new security perimeter for protecting access to resources across on-premises and cloud. In Zero Trust, access is granted based on who the user or workload is, the risk of the sign-in, the device health, and the context of the session. Microsoft summarizes this shift as: “Identity is the control plane,” emphasizing that authentication, authorization, and continuous evaluation of trust are enforced through identity-centric controls such as Conditional Access, multifactor authentication, Privileged Identity Management, device compliance, and session controls.

While tools like firewalls and services such as Microsoft Defender for Cloud remain important layers in a defense-in-depth strategy, they are not the primary perimeter in a hybrid model. Because users, devices, and applications operate from anywhere, identity is the consistent, verifiable layer through which policy is enforced for both on-premises and cloud resources. Therefore, in an environment that spans on-premises and cloud, Microsoft recommends treating identity as the primary security perimeter, applying continuous verification and least-privilege access through identity-driven policies.

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.

documents: =

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

In Microsoft’s Security, Compliance, and Identity guidance, the Microsoft Service Trust Portal (STP) is identified as the public destination where Microsoft publishes independent audit reports, compliance certifications, assessment reports, and trust-related documentation for Microsoft cloud services. The documentation explains that the STP provides customers with access to materials such as SOC 1/SOC 2 reports, ISO/IEC certifications, audit summaries, and compliance guides, enabling organizations to evaluate Microsoft’s controls and map them to their own regulatory requirements. The STP is expressly positioned for transparency and due diligence, allowing customers and auditors to review Microsoft’s compliance posture and understand how Microsoft manages security, privacy, and compliance across its cloud platforms.

By contrast, the Microsoft Purview compliance portal is a tenant-admin portal used to configure and manage compliance solutions (e.g., DLP, Information Protection, eDiscovery, Insider Risk, Compliance Manager) within your organization—not a public repository of Microsoft’s audit artifacts. The Microsoft Purview governance portal focuses on data governance and cataloging scenarios. The Azure EA portal is used for Enterprise Agreement billing and usage management. Therefore, the public site for publishing audit reports and other compliance-related information for Microsoft cloud services is the Microsoft Service Trust Portal.

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

access and application control

In Microsoft Defender for Cloud, the capabilities grouped as access and application control are designed to harden Azure virtual machines by limiting both what can access a VM and what can run on it. Microsoft’s documentation explains that Adaptive application controls “help you control which applications can run on your VMs by allowing only known-safe applications,” which directly helps block malware and other unwanted applications. In the same family, Just-in-time (JIT) VM access “reduces exposure to attacks by locking down inbound traffic to your VMs and opening only the required ports, for approved users, for a limited time,” thereby reducing the network attack surface. These capabilities are surfaced in Defender for Cloud recommendations and policies to enforce least privilege at the network edge and on the endpoint execution layer.

By contrast, Cloud Security Posture Management (CSPM) provides continuous assessment and secure-score-driven recommendations but isn’t the control that actively blocks applications or time-bounds inbound access. Container security targets container images and runtimes, and vulnerability assessment identifies software vulnerabilities but doesn’t enforce allow-listing or time-bound access. Therefore, the correct completion is access and application control, which encompasses Adaptive application controls and JIT VM access to protect VMs from unwanted apps and minimize exposed network surface.

Conditional access policies always enforce MFA = NoMicrosoft Entra Conditional Access policies are flexible and do not always require MFA. MFA is one possible control, but policies can enforce other access controls such as requiring a compliant device, blocking access entirely, requiring Terms of Use acceptance, or enforcing session controls.

SCI Extract: “Conditional Access is the tool used by Azure AD to bring signals together, to make decisions, and enforce organizational policies. These policies can require MFA, but it is not mandatory for all policies.”

Block access based on location = YesConditional Access supports location-based conditions using named locations (such as country or IP ranges). Policies can block or allow access based on where the user is signing in from.

SCI Extract: “Administrators can use Conditional Access policies to block or grant access based on user location, using named locations to define trusted or risky areas.”

Only affects Entra joined devices = NoConditional Access applies to all users and devices, including:

Entra-joined,

Hybrid Entra-joined,

Registered devices (via Microsoft Intune or Azure AD),

And even unmanaged (BYOD) devices depending on configuration.

SCI Extract: “Conditional Access policies apply to all users and devices based on selected conditions, not only Microsoft Entra joined devices.”

 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 Entra ID Identity Protection is a risk-based conditional access capability that “automates the detection and remediation of identity-based risks” and enables admins to investigate risky users and sign-ins. SCI guidance explains that Identity Protection evaluates signals such as user risk and sign-in risk, raises risk detections, and can automatically remediate by enforcing actions like password reset or blocking access via risk-based policies. The portal provides rich investigation experiences for risky users, risky sign-ins, and risk detections, allowing security teams to review evidence and confirm/dismiss risks. In addition, identity risk data can be exported through Azure Monitor/diagnostic settings and integrated with SIEM/SOAR tools, enabling “export of risk detections and security alerts to third-party solutions” for correlation and response. Tasks such as configuring external access for partner organizations are handled by B2B collaboration features, and creating/assigning sensitivity labels belongs to Microsoft Purview Information Protection—not Identity Protection. Therefore, the tasks Identity Protection supports are: export risk detection (B), automate detection and remediation of identity-based risks (C), and investigate risks related to user authentication (D).

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.

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

multi-factor authentication (MFA)

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

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

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.

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

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

Compliance score

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

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

In Azure networking, each Network Security Group (NSG) is created with a built-in set of default security rules. Microsoft’s documentation for NSGs explains: “Azure creates several default security rules within each network security group. You can’t remove the default security rules, but you can override them by creating rules with a higher priority.” The rule processing model is priority-based: “Security rules are processed in priority order, with lower numbers processed before higher numbers. Once a rule matches traffic, processing stops.” Because the defaults have relatively low precedence (high priority numbers), an administrator can create an explicit allow or deny rule with a lower priority number to supersede the default behavior.

This is why the correct completion is override rather than copy or delete. You cannot delete the default rules; they remain present to provide baseline behavior (such as denying inbound traffic from the internet by default and allowing virtual network traffic). Instead, you override the defaults by adding your own NSG rules—using lower priority numbers—to achieve the desired access control outcome while preserving Azure’s baseline protections and evaluation logic.

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.

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

eDiscovery

In Microsoft Purview, eDiscovery is the purpose-built compliance solution for legal and investigative workflows. Microsoft’s SCI materials describe eDiscovery as the tool that enables organizations to identify, preserve/hold, collect, review, and export potentially relevant content across Microsoft 365 services. Official guidance explains that eDiscovery (Standard) “provides search, hold, and export capabilities” for content in Exchange, SharePoint, OneDrive, Teams, and more. Another description states that eDiscovery (Premium) helps you “identify, preserve, collect, review, analyze, and export content” for legal matters and internal investigations. These capabilities are designed to support the eDiscovery lifecycle by allowing admins and case managers to: create cases, define custodians and non-custodial data sources, run targeted searches, apply legal holds to prevent data alteration or deletion, perform review and analytics, and export responsive data packages for counsel or regulators.

By contrast, Data Loss Prevention (DLP) protects sensitive information from accidental or inappropriate sharing; Customer Lockbox governs Microsoft engineer access to your data for support; and resource locks protect Azure resources from accidental deletion or modification. Therefore, the Microsoft SCI control that is explicitly used to identify, hold, and export electronic information for an investigation is Microsoft Purview eDiscovery.

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.

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

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

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

Microsoft Entra self-service password reset (SSPR) supports multiple verification methods that users can register and use to prove their identity during a reset. Microsoft’s documentation lists the SSPR methods as: “Mobile app notification,” “Mobile app code,” “Email,” “Mobile phone (text message or call),” “Office phone,” and “Security questions.” Administrators choose which of these are allowed and how many methods are required. During the reset flow, SSPR “prompts the user to verify with the registered methods” before permitting a password change. Notably, certificates and picture passwords are not SSPR verification methods in Microsoft Entra ID. Therefore, among the options provided: a text message to a phone (mobile phone), a mobile app notification (Microsoft Authenticator), and security questions are valid SSPR authentication methods; certificate and picture password are not supported for SSPR. This aligns with SCI learning content that positions SSPR as a user-empowering capability to securely restore access using admin-approved methods without help-desk intervention.

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.

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

Azure Active Directory (Azure AD) is a cloud-based user identity and authentication service. Reference:

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

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 defines defense in depth as a security strategy that uses multiple, reinforcing layers of protection to reduce the chance that a single failure leads to compromise. In Microsoft’s security guidance, defense in depth is described as employing “a series of mechanisms across multiple layers” to protect identities, endpoints, applications, data, and the network. The model spans layers such as identity, perimeter, network, compute, application, and data, with controls at each layer designed to detect, prevent, and contain attacks. Typical Azure/Microsoft 365 implementations include identity protections (MFA, Conditional Access), network controls (Azure Firewall, NSGs), perimeter filtering (WAF, DDoS Protection), endpoint safeguards (Defender for Endpoint), application security (code and runtime controls), and data protection (encryption, DLP, Purview Information Protection). By “placing multiple layers of defense throughout a network infrastructure,” an organization limits blast radius and increases resilience if one layer is bypassed. This contrasts with threat modeling (a design-time analysis technique), identity as the security perimeter (a principle of Zero Trust), and the shared responsibility model (a cloud governance concept). The scenario in the question precisely matches Microsoft’s defense in depth methodology.

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.

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.