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

documents: =

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

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

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

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

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

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

Box 1: Yes

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

Box 2: No

Basic Audit retains audit records for 90 days.

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

Box 3: yes

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

In Microsoft’s hybrid identity model, organizations keep their authoritative identities in Active Directory Domain Services (AD DS) and surface those identities in Microsoft Entra ID (Azure AD). Microsoft guidance explains that hybrid identity is implemented by synchronizing on-premises directory objects (users, groups, and selected attributes) into Azure AD using Azure AD Connect or Cloud Sync. Azure AD Connect is explicitly documented as the Microsoft tool that establishes and maintains synchronization between AD DS and Azure AD and is therefore used to implement hybrid identity—hence statement 1 is Yes. Hybrid identity does not require two Microsoft 365 tenants; the standard design is one Azure AD tenant connected to one or more on-premises AD forests, so statement 2 is No. For users to authenticate to Microsoft cloud resources with their on-premises identity, Azure AD must have a corresponding cloud identity object, which is achieved by directory synchronization; sign-in can then be handled by cloud authentication (Password Hash Synchronization or Pass-through Authentication) or by federation (e.g., AD FS). Because these sign-in options depend on synchronized identities being present in Azure AD, statement 3 is Yes. This aligns with SCI guidance that hybrid identity = synchronized identities + a chosen authentication method (PHS/PTA or federation).

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

In Microsoft’s Security, Compliance, and Identity learning content and product documentation, Intune administration is performed in the dedicated Intune portal that, for exam and study-guide purposes, is referred to as the Microsoft Endpoint Manager admin center. Microsoft explains that “Microsoft Intune is a cloud-based service that focuses on mobile device management (MDM) and mobile application management (MAM)” and that “administrators manage Intune in the Intune (Endpoint Manager) admin center, where you configure device enrollment, compliance, apps, and endpoint security.” The admin experience consolidates device, app, and policy management, including device compliance policies, configuration profiles, app protection policies, software update rings, and endpoint security baselines, all from this portal.

By contrast, the Azure Active Directory admin center (Microsoft Entra admin center) is designed for identity and access tasks (users, groups, roles, Conditional Access), not full device/app management. The Microsoft 365 compliance center is focused on data governance and risk (DLP, information protection, eDiscovery, audit), while the Microsoft 365 security center/Defender portal is for security operations and threat protection. Therefore, when the sentence states, “You can manage Microsoft Intune by using the…,” the correct completion—aligned with Microsoft SCI study materials—is Microsoft Endpoint Manager admin center, the portal intentionally built for Intune device and app lifecycle management.

 Compliance Manager tracks only customer-managed controls. No

 Compliance Manager provides predefined templates for creating assessments. Yes

 Compliance Manager can help you assess whether data adheres to specific data protection standards. No

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

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

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

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

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

Box 1: No

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

Box 3: Yes

In Microsoft Defender for Endpoint, attack surface reduction (ASR) is described as the first defensive layer in the protection stack, and Network protection is a core ASR capability. Microsoft’s documentation states that “Attack surface reduction provides the first line of defense in the stack.” It further explains that these capabilities are designed to reduce opportunities for compromise before malware can run or persistence can be established. Within ASR, Microsoft specifically defines Network protection as a feature that “helps reduce the attack surface of your devices from Internet-based events.” Microsoft also clarifies how it works: “It prevents employees from using any application to access dangerous domains that may host phishing scams, exploits, and other malicious content on the Internet.”

Because the question asks for the feature in Defender for Endpoint that delivers the first line of defense by reducing the attack surface, the applicable ASR capability is Network protection. It proactively blocks access to known malicious IPs, domains, and URLs, shrinking the exploitable surface area and thereby reducing risk before an attack can execute. By contrast, automated investigation and automated remediation act after detections to contain and fix issues, and advanced hunting is an analyst-driven, query-based detection and investigation tool—not an attack-surface–reduction control. Hence, Network protection is the correct choice.

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.

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

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.

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

https://docs.microsoft.com/en-us/azure/active-directory/privileged-identity-management/pim-configure

Privileged Identity Management provides time-based and approval-based role activation to mitigate the risks of excessive, unnecessary, or misused access permissions on resources that you care about. Here are some of the key features of Privileged Identity Management: Provide just-in-time privileged access to Azure AD and Azure resources Assign time-bound access to resources using start and end dates Require approval to activate privileged roles Enforce multi-factor authentication to activate any role Use justification to understand why users activate Get notifications when privileged roles are activated Conduct access reviews to ensure users still need roles Download audit history for internal or external audit Prevents removal of the last active Global Administrator role assignment

Yes

NO

NO

YES - As an administrator, you can lock a subscription, resource group, or resource to prevent other users in your organization from accidentally deleting or modifying critical resources. The lock overrides any permissions the user might have.

NO - The most restrictive lock in the inheritance takes precedence.

NO - If you delete a resource group with a locked resource, the portal UI will give you an error and no resources are deleted.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/management/lock-resources?tabs=json

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

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.

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

In Microsoft Entra ID (Azure AD), Conditional Access is the policy engine that evaluates signals about the user, device, app, and session to determine whether to grant access and under what conditions. Microsoft’s guidance explains that Conditional Access is “the tool used by Azure AD to bring signals together, make decisions, and enforce organizational policies.” In device-centric scenarios, Conditional Access integrates with Microsoft Intune device compliance so you can enforce controls such as “Require device to be marked as compliant” or “Require approved client app” before granting access to corporate resources like Microsoft 365 and Azure apps. This allows organizations to block or limit access from unmanaged or noncompliant devices, and to allow access only from devices that meet your compliance policies (encryption, OS version, jailbreak/root status, etc.).

By contrast, Network Security Groups (NSGs) filter traffic at the virtual network/subnet/NIC level and are not identity-aware; Privileged Identity Management (PIM) governs just-in-time elevation and access reviews for privileged roles; and resource locks prevent accidental deletion or modification of Azure resources. Therefore, the Azure AD feature specifically designed to restrict access by Intune-managed device state and enforce device-based access conditions to corporate resources is Conditional Access.

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.

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

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

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

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.

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

 Microsoft Defender for Cloud can detect vulnerabilities and threats for Azure Storage. Yes

 Cloud Security Posture Management (CSPM) is available for all Azure subscriptions. Yes

 Microsoft Defender for Cloud can evaluate the security of workloads deployed to Azure or on-premises. Yes

Microsoft Defender for Cloud provides both workload protection and posture management. For Azure Storage, the Defender plan (Microsoft Defender for Storage) offers threat detection such as anomalous access, malware scanning, and sensitive-data threat alerts, while the CSPM guidance in Defender for Cloud flags misconfigurations that create vulnerabilities (for example, public blob access, weak TLS settings). CSPM capabilities—secure score, recommendations, and baseline assessments—are available to all Azure subscriptions (foundational CSPM), giving every tenant visibility into security posture without requiring a premium add-on for basic posture features. Beyond Azure, Defender for Cloud supports hybrid and multicloud: using Azure Arc and the Defender for Servers plan, it can onboard and assess on-premises servers and resources in other clouds, applying recommendations, security assessments, and threat protections across those environments. Collectively, these capabilities confirm that Defender for Cloud can detect storage-related threats and posture weaknesses, CSPM is broadly available to Azure subscriptions, and the service evaluates workloads running in Azure or on-premises.

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.

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.

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

In Microsoft Sentinel, playbooks are the feature that integrates with Azure Logic Apps to automate response. Microsoft’s documentation describes them as “collections of procedures that can be run from Microsoft Sentinel in response to an alert” and clarifies that “playbooks are built on Azure Logic Apps” providing a workflow engine and a gallery of connectors to other Microsoft and third-party services. Playbooks can be triggered automatically from analytics rules or manually from incidents and alerts, enabling orchestration such as assigning owners, creating tickets, disabling accounts, blocking IPs, or posting to collaboration channels. The platform emphasizes that the Logic Apps foundation gives security teams a visual designer, managed connectors, and run history to track execution and outcomes. In short, Sentinel uses playbooks to “automate and orchestrate responses to alerts and incidents”, reducing mean-time-to-respond and standardizing actions across your SOC. Other Sentinel components serve different purposes: analytic rules detect threats, hunting queries aid proactive investigation, and workbooks provide dashboards and visualizations. Therefore, the correct completion is: Microsoft Sentinel playbooks use Azure Logic Apps to automate and orchestrate responses to alerts.

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

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

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

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

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

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

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

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.

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

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

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

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.

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

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

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.

In the Microsoft 365 security center (now Microsoft 365 Defender), incidents are used to triage and investigate threats across the tenant. Microsoft’s security documentation explains that “an incident is a collection of related alerts” that are automatically correlated to give analysts a single, end-to-end view of an attack. Within each incident, the portal surfaces impacted assets such as devices, users, mailboxes, and applications, enabling responders to quickly identify which endpoints are affected by a given alert and to take response actions (isolate device, collect investigation package, run AV scan, etc.). This design allows security teams to move beyond individual alerts and instead work a consolidated investigation that lists affected devices in the incident’s Evidence & Response/Assets sections, complete with alert timelines and device details.

By comparison, Secure Score measures the organization’s security posture and recommendations; policies are configuration/enforcement objects (e.g., Defender or compliance policies) and are not the investigative view for alerts; classifications relate to information protection labeling rather than alert investigation. Therefore, to identify devices that are affected by an alert, you use the Incidents experience in Microsoft 365 Defender, where correlated alerts show the devices involved alongside the entities and evidence connected to the threat.

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

Explanation

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

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

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

The SCI documentation states:

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

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

Azure AD Privileged Identity Management (PIM) provides just-in-time privileged access to Azure AD and Azure resources

Microsoft’s SCI learning content describes the Microsoft 365 Defender portal as a unified security operations experience that surfaces security posture and active threats on a card-based dashboard. In the overview of the portal, Microsoft explains that the home page “presents key security information in dashboard cards,” and that among these cards are summaries that highlight risky entities such as “Users at risk” and “Devices at risk.” These cards provide quick, actionable visibility for analysts by aggregating detections and exposure data across Microsoft Defender services (for identities and endpoints). The guidance emphasizes that the portal “correlates signals across identities, endpoints, email, and applications” and that security teams can use the dashboard cards to pivot directly into incidents and investigations from “Users at risk” or “Devices at risk” to take containment or remediation actions.

By contrast, Compliance Score is part of Microsoft Purview Compliance Manager, not the Microsoft 365 Defender portal; Service Health and User Management are functions of the Microsoft 365 admin center. Therefore, the cards you’ll find on the Microsoft 365 Defender portal that match the choices provided are Users at risk and Devices at risk.

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.

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

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

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

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.

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.

Microsoft Entra Access Reviews are designed to help organizations regularly validate and right-size access. Microsoft’s documentation explains that access reviews can target group memberships, enterprise app assignments, Azure AD roles, and Azure resource roles (via Privileged Identity Management), allowing reviewers to assess whether users, service principals, or groups should retain access to Azure resources—confirming the first statement. Access Reviews support automation: you can configure a review to “Auto-apply results”, so when the review ends, users who were denied or not reviewed are automatically removed from the group, application assignment, or role—validating the second statement. Finally, Access Reviews are a Premium P2 capability (now Microsoft Entra ID P2) alongside PIM and advanced identity governance. They are not included in all service plans; tenants require the appropriate P2 licenses for reviewers and users in scope—therefore the third statement is No.