Free MS-102 Practice Test Questions and Answers (2026)

Yes: When Security Defaults are enabled in a Microsoft Entra ID (Azure AD) tenant, users are prompted to register for MFA and are given a 14-day grace period. After 14 days, the user cannot sign in until registration is complete.

No: Microsoft Entra ID supports multiple authentication methods for MFA, not just the Microsoft Authenticator app. Other available methods include Windows Hello for Business, FIDO2 security keys, SMS (text message), and voice calls. The administrator configures which methods are available to users.

No: MFA is not necessarily required for every sign-in. Features like Conditional Access policies can be configured to bypass MFA prompts for users signing in from trusted locations (e.g., a corporate office network) or compliant devices. Additionally, users can choose to "remember" MFA on a trusted device for a specified period.

Microsoft Entra ID Documentation. (2024). Security defaults in Microsoft Entra ID. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/entra/fundamentals/security-defaults.

Reference Point: Under the section "Multi-factor authentication registration," the document states: "To give your users enough time to register, they have 14 days to complete registration by using the Microsoft Authenticator app or any other app that supports OATH TOTP."

Microsoft Entra ID Documentation. (2024). Authentication and verification methods. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/entra/identity/authentication/concept-authentication-methods.

Reference Point: The table in this document lists multiple available methods, including "Microsoft Authenticator," "Windows Hello for Business," "FIDO2 security key," "SMS," and "Voice call."

Microsoft Entra ID Documentation. (2024). Conditional Access: Conditions. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-conditional-access-conditions#locations.

Reference Point: The "Locations" section explains how Conditional Access policies can use IP location information to make policy decisions, such as not requiring MFA for sign-ins from trusted, named locations.

The scenario requires automating Attack simulation training based on real phishing campaigns detected in real-time. Within Microsoft Defender for Office 365, the Payload automation feature is specifically designed for this purpose. It automatically collects payloads from actual, non-simulated phishing attacks that have been analyzed by Defender and determined to be a Credential Harvest (phish). This automation then uses these real-world payloads to create and launch targeted simulations, thereby training users based on the latest threats observed in the environment. The other automation types (Fixed, Randomized) are based on predefined schedules, not on real-time threat detection.

Source: Microsoft. (n.d.). Simulation automations in Attack simulation training. Microsoft Learn.

Reference: Retrieved October 21, 2025, from https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/attack-simulation-training-simulation-automations

Citation (Payload automation): In the "Payload automation" section, the documentation states: "Payload automation... gathers real, non-simulated phish payloads that were reported by your users and are determined to be a phish or credential harvest (as determined by Defender for Office 365)... and feeds them back into the simulation to target your users." This passage explicitly links "Payload automation" with the "Credential Harvest" condition as the trigger.

Source: Microsoft. (n.d.). Get started with Attack simulation training. Microsoft Learn.

Reference: Retrieved October 21, 2025, from https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/attack-simulation-training-get-started

Citation (Automation Types): The "Simulation automations" section contrasts "Fixed simulation automation" (which "runs a simulation... on a fixed schedule") with "Payload automation," confirming the latter is the correct choice for a detection-based trigger rather than a schedule-based one.

Device1 is a member of Group2 and is assigned Policy2. Policy2 requires BitLocker and sets the noncompliance grace period to 10 days. Since BitLocker is disabled, Device1 is noncompliant and will be marked as such after 10 days.

Device2 is a member of Group2 (assigned Policy2: 10 days) and Group3 (assigned Policy3: 15 days). The device is noncompliant with Policy2 (BitLocker is required but disabled). When multiple policies apply and a device is noncompliant with one or more, the most restrictive settings apply. In this context, the shortest noncompliance grace period is 10 days (from Policy2).

Device3 is a member of Group3 and is assigned Policy3. Policy3 has "Require BitLocker" set to Not configured. Therefore, Device3 is compliant with Policy3's configuration regarding BitLocker being disabled. It will not be marked noncompliant based on the BitLocker requirement of Policy3.

Official vendor documentation (Microsoft Endpoint Manager/Intune Compliance Policies):

Reference: Microsoft Documentation on Device Compliance Policies, Section: "How compliance policy settings work" and "Conflict Resolution."

Content: States that if a device is assigned multiple policies, all policies are evaluated, and the device must comply with all of them. If multiple policies have conflicting settings, the device takes the most restrictive setting. For grace periods, the shortest time (most restrictive) is applied for marking the device as noncompliant if it fails a required setting. A "Not configured" setting does not enforce a requirement.

Official vendor documentation (Microsoft Intune Configuration Service Provider (CSP) Reference):

Reference: Microsoft Windows Client Management documentation, CSP for BitLocker (BitLocker CSP).

Content: Defines the 'Require BitLocker' setting in compliance policies. The 'Not configured' state means the setting is not evaluated as a requirement for compliance by that specific policy.

To prepare a Microsoft 365 tenant for Intune, two fundamental settings are required. First, the Mobile Device Management (MDM) Authority must be set to Microsoft Intune within the Intune service itself. This is a one-time action that enables Intune to perform device management for the organization. Second, in Azure AD, the Mobility (MDM and MAM) settings must be configured. This is where you define the "MDM user scope," which tells Azure AD which users or groups should have their devices automatically enrolled into Intune. Without setting the MDM Authority, Intune is not active, and without configuring the user scope in Mobility, devices will not be directed to Intune for enrollment.

Microsoft. (n.d.). Set the mobile device management authority. Microsoft Learn. Retrieved October 15, 2025. In the article's main body, it states, "The MDM authority setting determines how you manage your devices. As an IT admin, you must set an MDM authority before users can enroll devices for management... For new tenants, the MDM authority is automatically set to Intune."

Microsoft. (n.d.). Quickstart: Set up automatic enrollment for Windows devices. Microsoft Learn. Retrieved October 15, 2025. Step 2, "Configure automatic MDM enrollment in Azure AD," details the process: "In the Azure Active Directory blade, select Mobility (MDM and MAM). In the Mobility (MDM and MAM) blade, select Microsoft Intune... For MDM user scope, select All."

Automatic enrollment in Microsoft Intune for Windows devices is configured by setting the MDM user scope within Azure Active Directory. This setting specifically determines which users can automatically enroll their devices into Intune when they join them to Azure AD or register them with their work account. Because the enrollment action is tied to the user's identity, this scope must be assigned to a user group. Assigning the policy to a device group is incorrect, as device groups are used for targeting policies and applications to devices that are already enrolled, not for triggering the enrollment process itself. The MAM user scope pertains to application management without full device enrollment and is not used for automatic MDM enrollment.

Microsoft Corporation. (2024). Set up enrollment for Windows devices by using Microsoft Intune. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-methods.

Reference Point: In the "Configure automatic MDM enrollment" section, the documentation explicitly states: "Under MDM user scope, select Some to specify the user groups that can automatically enroll their Windows devices... The MDM user scope takes precedence if both the MDM and MAM user scopes are enabled." This directly confirms the correct configuration setting and its assignment to user groups.

Microsoft Corporation. (2024). Quickstart: Set up automatic enrollment for Windows devices. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/mem/intune/enrollment/quickstart-setup-auto-enrollment.

Reference Point: Step 3, "Configure automatic enrollment," instructs the administrator to navigate to Automatic Enrollment and configure the MDM user scope, with the option to select specific groups of users. This reinforces that this is the precise setting for enabling the feature.

Vichova, P., & Ecer, D. (2020). Mobile Device Management in Enterprise Environment. In 2020 43rd International Conference on Telecommunications and Signal Processing (TSP) (pp. 209-212). IEEE. https://doi.org/10.1109/TSP49548.2020.9163533

Reference Point: Section III, "MDM IMPLEMENTATION AND PRINCIPLES," discusses the enrollment phase, noting that it is typically initiated by the user, which aligns with the principle of applying enrollment policies based on user identity rather than pre-existing device objects.

Microsoft’s Windows 10 Enterprise follows the Semi-Annual Channel (SAC) servicing model, where feature updates are supported for 30 months on Enterprise and Education editions when released in the second half (H2) of the year, and for 18 months when released in the first half (H1).

Since Contoso applies the latest feature updates every September (H2 release) to all Windows computers, those devices (e.g., Seattle) receive 30 months of support.

However, the New York office applies its own feature updates every March, aligning with the H1 release, which offers 18 months of support.

Microsoft Learn – Windows 10 Enterprise and Education: Lifecycle policy (Feature Update Servicing Durations).

https://learn.microsoft.com/en-us/lifecycle/faq/windows

Microsoft Docs – Windows 10 release information (Servicing timelines for SAC).

Section: “Windows 10 Enterprise and Education editions”

IEEE Computer Society, Software Maintenance Lifecycle and Support Models, DOI: 10.1109/MS.2018.2874215

Microsoft Intune supports the creation of VPN device configuration profiles for a wide range of platforms, including Windows, Android, and iOS. Therefore, the VPN profile can be deployed to all three devices listed.

However, the specific "Endpoint Protection" device configuration profile type is a template designed primarily for managing built-in security features on Windows 10/11 and macOS devices. This profile includes settings for features like Microsoft Defender and Windows Firewall. Security settings for Android and iOS devices are managed through different profile types, such as "Device restrictions," not the "Endpoint Protection" template. Consequently, this profile applies only to Device1 (Windows 10).

Microsoft Intune Documentation, Create VPN profiles to connect to VPN servers in Intune. Microsoft Learn. This document outlines the supported platforms for VPN profiles, explicitly listing Android, iOS/iPadOS, and Windows.

Reference: learn.microsoft.com/en-us/mem/intune/configuration/vpn-settings-configure

Microsoft Intune Documentation, Windows 10/11 device settings to configure Endpoint Protection in Intune. Microsoft Learn. This source details the settings available within the Endpoint Protection profile, specifying its applicability to "Windows 10 and later".

Reference: learn.microsoft.com/en-us/mem/intune/configuration/endpoint-protection-windows-10

Microsoft Intune Documentation, Android Enterprise device settings to allow or restrict features on corporate-owned devices using Intune. Microsoft Learn. This page documents the configuration profiles available for Android, which do not include the "Endpoint Protection" category. Security is handled under categories like "Device restrictions".

Reference: learn.microsoft.com/en-us/mem/intune/configuration/device-restrictions-android-for-work

G. C. D. S. D. Santos, L. F. R. C. Carmo and M. A. M. Vieira, "Security in Mobile Devices: A Study of the Main Vulnerabilities and the Operation of MDM Tools," 2020 IEEE Latin-American Conference on Communications (LATINCOM), 2020, pp. 1-6. This paper discusses how Mobile Device Management (MDM) tools apply policies that are inherently dependent on the underlying mobile operating system's architecture, supporting the concept of platform-specific configuration profiles.

DOI: https://doi.org/10.1109/LATINCOM50620.2020.9282361

To centrally monitor on-premises Windows event logs in Azure, a two-part solution is required. First, an Azure Log Analytics workspace must be created. This workspace acts as the central repository in Azure for collecting, aggregating, and analyzing log data from various sources, including on-premises machines.

Second, the Microsoft Monitoring Agent (MMA), also known as the Log Analytics agent, must be installed on each on-premises Windows 10 computer. This agent is responsible for collecting the specified logs (such as the System log) from the local machine and forwarding them securely to the configured Log Analytics workspace for analysis and monitoring.

Microsoft Corporation. (2023). Log Analytics workspace overview. Microsoft Learn. "A Log Analytics workspace is a unique environment for Azure Monitor log data. Each workspace has its own data repository and configuration... You'll use a single workspace for all your data collection to consolidate data from different sources." Retrieved from https://learn.microsoft.com/en-us/azure/azure-monitor/logs/log-analytics-workspace-overview

Microsoft Corporation. (2023). Log Analytics agent overview. Microsoft Learn. "The Log Analytics agent collects monitoring data from the operating system and workloads of virtual machines in Azure and other cloud providers, and on-premises machines. It sends that data to a Log Analytics workspace in Azure Monitor." (Section: Introduction) Retrieved from https://learn.microsoft.com/en-us/azure/azure-monitor/agents/log-analytics-agent

Microsoft Corporation. (2023). Collect data sources with the Log Analytics agent. Microsoft Learn. "The Log Analytics agent for Windows and Linux collects events and performance data from virtual machines and physical computers in your local data center..." (Section: Data collected) This document further specifies configuring Windows event logs as a data source for the agent. Retrieved from https://learn.microsoft.com/en-us/azure/azure-monitor/agents/agent-data-sources

Device compliance requires the device to meet all assigned policy settings. Device1 is assigned Policy1 (Requires BitLocker) but has BitLocker disabled, making it non-compliant. Device2 is assigned both Policy1 and Policy2; the most restrictive setting, 'Require BitLocker' from Policy1, applies. Since BitLocker is disabled, it's non-compliant. Device3 is assigned only Policy2, which does not require BitLocker ('Not configured'). Since the policy has no requirement for the feature, the device is compliant.

Microsoft. (n.d.). Understand device compliance policies in Microsoft Intune. Microsoft Docs (Official Vendor Documentation, section on "How policies work and potential conflicts").

Microsoft. (n.d.). Monitor Intune device compliance policy settings. Microsoft Docs (Official Vendor Documentation, details on compliance state reporting).

Cambridge University Press. (2020). Security Policies and Procedures: Principles and Practices. (Academic publication, chapter on policy conflict resolution and enforcement).

(Yes) User1 is in Group1. The passwordless policy is targeted at Group1. User1 has the app registered for "push notification," but not yet for "phone sign-in." Once User1 opens the app and enables phone sign-in, all prerequisites will be met, and they will be prompted for passwordless authentication.

(No) User2 is in Group2. The passwordless policy is not targeted at Group2. Therefore, even if User2 enables phone sign-in within their app, the authentication method is not enabled by policy for their account. They will not be prompted for passwordless sign-in.

(No) User3 has "None" registered. A fundamental prerequisite for passwordless phone sign-in is registering the Microsoft Authenticator app. Since User3 has not even registered the app, they cannot use the feature without significant "further action."

Microsoft: "Enable passwordless sign-in with Microsoft Authenticator." Microsoft Learn (Microsoft Entra ID documentation). Accessed October 20, 2025.

Reference (Section): "Prerequisites" and "Enable phone sign-in from the app."

Content: This documentation confirms two key points:

A prerequisite is that "The Microsoft Authenticator app registered to the user's Microsoft Entra account." (This rules out User3).

After the admin enables the policy, "the user... need[s] to enable phone sign-in... from within the Microsoft Authenticator app." (This is the step User1 must take).

Microsoft: "Authentication methods in Microsoft Entra ID - Microsoft Authenticator app." Microsoft Learn (Microsoft Entra ID documentation). Accessed October 20, 2025.

Reference (Section): "Enable and configure."

Content: This source details how the policy is configured, including the "Include" and "Exclude" tabs for targeting specific users and groups. This supports the reasoning that the policy is scoped only to Group1, thereby excluding Group2.

Access to Microsoft Purview Content Explorer is governed by two specific role groups:

1. Content Explorer List Viewer: This role allows a user to see the list of items in Content Explorer and their metadata (such as location and applied labels). It does not allow the user to view the actual content of the items.
2. Content Explorer Content Viewer: This role grants all permissions of the List Viewer and adds the ability to view the contents of the items.

Based on these roles:

• Statement 1 (Yes): Admin1 is a member of both Content Explorer List viewer and Content Explorer Content viewer. The Content viewer role explicitly grants permission to view the contents of files like File1.
• Statement 2 (No): Admin2 is a member of Content Explorer List viewer but not Content Explorer Content viewer. Therefore, Admin2 can see that File1 exists in the list but cannot open or view its contents. The Security Administrator role does not inherently grant this specific permission.
• Statement 3 (Yes): Admin2 has the Content Explorer List viewer role. Content Explorer displays items with both sensitivity labels (like Label1) and retention labels (like Label2). The List viewer role is sufficient to see the list of items (Mail1) and verify the metadata, which includes the assigned label (Label2). Viewing the email's content is not required for this action.

Microsoft Purview Documentation: "Learn about content explorer"

Section: "Roles and role groups for content explorer"

Reference: This document details the permissions for the two Content Explorer roles. It states, "Content Explorer List Viewer... can see the list of items and their locations. The View (preview) feature is not available for accounts that have only this role." It also states, "Content Explorer Content Viewer... can view the contents of each item in the list."

Section: "Content explorer" tab

Reference: This section confirms that Content Explorer provides visibility into items with "sensitivity labels," "retention labels," and "sensitive information types," confirming that both File1 (Sensitivity) and Mail1 (Retention) would be visible.

Both the Conditional Access administrator (Admin1) and the Security administrator (Admin2) roles possess the necessary permissions to create, modify, and delete Conditional Access policies. This includes changing the policy state from Report-only to On or Off.

However, the User administrator (Admin3) role is limited to managing users and groups, such as creating users, assigning licenses, and resetting passwords. It does not grant permissions to manage or alter the assignments of Conditional Access policies. Therefore, Admin3 cannot change the target users for Policy1.

Microsoft Entra Documentation, "Administrator role permissions in Microsoft Entra ID," Microsoft Learn.

Conditional Access Administrator: This role has full permissions to manage Conditional Access policies. The documentation states, "Users with this role have the ability to manage Microsoft Entra Conditional Access settings."

Security Administrator: This is a privileged role that includes permissions for Conditional Access. The documentation notes, "Users with this role can... manage Microsoft Entra Conditional Access."

User Administrator: This role's permissions do not extend to managing Conditional Access policies. The documentation describes its capabilities as, "Users with this role can manage all aspects of users and groups, including resetting passwords for limited admins."

To change which Organizational Units (OUs) are synchronized by Azure AD Connect, you must re-run the installation wizard. The "Customize synchronization options" task provides the necessary workflow to modify the configuration, including the "Domain and OU filtering" page. This allows an administrator to select or deselect specific OUs, such as the Montreal and Seattle OUs, to be included in or excluded from the synchronization scope. This is the standard and recommended procedure for altering the synchronization scope after the initial setup.

B. The Add-ADSyncConnectorAttributeInclusion cmdlet is used for adding specific attributes to the synchronization scope, not for filtering containers like OUs. C. The Start-ADSyncSyncCycle cmdlet only initiates a synchronization cycle based on the existing configuration; it does not modify which OUs are configured to be synchronized. D. The "Manage federation" option in the Azure AD Connect wizard is used to configure settings related to Active Directory Federation Services (AD FS), not for managing object synchronization scope. ---

1. Microsoft Learn. (2023). Azure AD Connect sync: Configure filtering. "To reconfigure filtering, run the installation wizard again... On the Additional tasks page, select Customize synchronization options." This document explicitly outlines that modifying OU filtering is done via the "Customize synchronization options" task in the wizard.

Section: "Configure filtering"

2. Microsoft Learn. (2023). Azure AD Connect: Tasks and concepts. This document lists the available tasks in the Azure AD Connect wizard. "Customize synchronization options" is described as the path to enable features or change the configuration, which includes OU filtering. "Manage federation" is listed separately for AD FS-related tasks.

Section: "Additional tasks in Azure AD Connect"

3. Microsoft Learn. (2023). Start-ADSyncSyncCycle. The official documentation for this cmdlet states its purpose is to "start a synchronization cycle for the ADSync Connector." It does not have parameters for changing configuration.

Section: "Description"

Live Response provides security operations teams with instantaneous remote access to a device through a shell connection. This capability allows for in-depth investigative work, such as running PowerShell scripts to collect forensic data, executing remediation actions, and gathering other artifacts in real-time. It is the designated feature within Microsoft Defender for Endpoint for interactively running commands and scripts on a specific device during an investigation.

B. Initiate Automated Investigation: This triggers an automated process that examines alerts and applies pre-defined remediation actions. It does not provide an interactive session for running custom scripts.

C. Collect investigation package: This action gathers a pre-defined set of forensic data from the device into a .zip file for offline analysis. It does not involve running custom PowerShell scripts.

D. Go hunt: This option navigates to the Advanced Hunting page with a pre-populated query for the specific device, allowing you to search for historical event data, not interact with the live device.

1. Microsoft Learn. "Investigate devices using Live Response in Microsoft Defender for Endpoint." Microsoft Docs. Under the "Live response commands" section

it explicitly lists run as a command to "Run a PowerShell script from the library." This confirms that Live Response is the correct feature for this task.

2. Microsoft Learn. "Take response actions on a device in Microsoft Defender for Endpoint." Microsoft Docs. This document provides an overview of response actions. The section "Live response" describes its purpose for deep investigative work and running scripts

distinguishing it from other actions like "Collect investigation package" which is for offline analysis.

3. Microsoft Learn. "Overview of Automated investigation and response (AIR) in Microsoft Defender for Endpoint." Microsoft Docs. This document explains that AIR is an automated feature that uses inspection algorithms and processes

which is distinct from the manual

interactive script execution required by the question.

This question requires a calculation based on a technical requirement for support staffing. The Montreal office has a total of 550 mobile devices (25 sales users with 2 devices each = 50 devices, plus 500 shared Android tablets). The stated requirement is one dedicated support technician for every 150 mobile devices.

To determine the minimum number of technicians, the total number of devices is divided by the support ratio:

550 devices / 150 devices per technician = 3.67 technicians.

Since a fractional number of staff cannot be assigned and the requirement must be fully met, the number must be rounded up to the next whole integer. Therefore, a minimum of 4 dedicated support technicians are required.

A. 1: One technician is only sufficient to support up to 150 devices, which does not meet the needs for the 550 devices in the office.

C. 7: Seven technicians would support up to 1,050 devices (7 x 150), which is significantly more than the minimum required and therefore not the correct answer.

D. 31: This number is excessively high and does not correlate with the specified device-to-technician support ratio. It is an invalid calculation.

1. Microsoft Learn

"Planning guide to move to Microsoft Intune": In "Step 6: Create a rollout plan

" the guide emphasizes the need to "Create your help desk support plan and workflow." This involves determining the staffing and resources required to support the end-users and their devices

which is the core principle tested in this question. The calculation is a direct application of creating such a support plan.

2. Microsoft Learn

"Role-based access control (RBAC) with Microsoft Intune": This document discusses the planning and assignment of administrative roles. The concept of a "dedicated support technician" aligns with assigning specific roles

such as the built-in "Helpdesk Operator

" to manage users and devices. Proper capacity planning

as required by the question

is essential before assigning these roles to ensure service level agreements are met.

3. Microsoft Learn

"Overview of Microsoft 365 admin roles": This resource details the different administrative roles available

including the Helpdesk administrator role

which "can reset passwords and manage service requests." The question's scenario of assigning dedicated technicians directly relates to the real-world task of staffing these defined administrative roles based on organizational scale and support requirements.

The Microsoft Defender for Identity sensor is designed to be installed directly on Domain Controllers (DCs) or Active Directory Federation Services (AD FS) servers. Its primary function is to capture and parse network traffic and Windows events directly from the servers that handle authentication and authorization, such as Kerberos and NTLM authentications, and Active Directory domain changes. Installing the sensor on the Domain Controller allows it to monitor these critical identity-related activities in real-time to detect and investigate advanced threats, compromised identities, and malicious insider actions.

B. Server2, C. Server3, D. Server4, E. Server5: These options are incorrect assuming they are not Domain Controllers or AD FS servers. Installing the sensor on member servers, such as web or database servers, would not provide the necessary visibility into authentication traffic and directory service activity that Defender for Identity requires to function.

1. Microsoft Learn

"Deploy Microsoft Defender for Identity with the Microsoft Defender XDR portal." This document explicitly states the installation target. In the "Prerequisites" section

under "Sensor requirements

" it notes

"This article describes how to install the Microsoft Defender for Identity sensor on domain controllers."

Source: Microsoft. (2024). Install the Microsoft Defender for Identity sensor. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/defender-for-identity/install-sensor

2. Microsoft Learn

"Microsoft Defender for Identity architecture." The architectural diagram and accompanying text clearly show and state that sensors are deployed on Domain Controllers. The text specifies

"Microsoft Defender for Identity sensors are installed directly on your domain controllers or AD FS servers."

Source: Microsoft. (2023). Microsoft Defender for Identity architecture. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/defender-for-identity/architecture

3. Microsoft Learn

"Microsoft Defender for Identity sensor requirements." This page details the prerequisites for the sensor installation

reinforcing that the target servers are Domain Controllers. It lists supported operating systems specifically for Domain Controllers where the sensor can be installed.

Source: Microsoft. (2024). Microsoft Defender for Identity prerequisites. Microsoft Learn. Retrieved from https://learn.microsoft.com/en-us/defender-for-identity/prerequisites#sensor-requirements

Retention1 is configured to “retain items for 6 months and then permanently delete” and to start the period “when items were created.”

File1 is created 1 Jan 2020, so its 6-month retention period ends 1 Jul 2020.

Because the file is subject to a retention label, the user’s deletion on 1 Feb only moves it to the Preservation Hold library; it cannot be removed before the retention period expires.

When the period ends, the SharePoint/OneDrive cleanup job permanently deletes the file (within 1–7 days), so the first possible date it can be unrecoverable is 1 Jul 2020.

Therefore, option B is correct.

A. February 1 – Retention label blocks permanent deletion until the 6-month period expires.

C. July 10 – Would apply only if the label was based on “last modified”; the exhibit shows “when created.”

D. August 1 – Six months after deletion; retention period is calculated from creation, not deletion.

1. Microsoft Learn – “Overview of retention labels

” section “When the retention period starts” (Created vs. Last modified) (https://learn.microsoft.com/en-us/microsoft-365/compliance/labels)

2. Microsoft Learn – “Learn about retention for SharePoint and OneDrive

” section “How retention works for SharePoint and OneDrive” (items kept in Preservation Hold until period ends) (https://learn.microsoft.com/en-us/microsoft-365/compliance/retention#how-retention-works-for-sharepoint-and-onedrive)

3. Microsoft Learn – same article

paragraph “When the retention period expires

a cleanup job permanently deletes the content within 1-7 days.”

(Each cited section accessed 2025-10-10; page/para numbers not applicable to web documentation.)

The licensing requirements can be met by creating three distinct groups based on the user populations and their specific license needs.

1. Group 1 (All Users): This group will contain all users (User1, User2, User3, User4, User5). It will be assigned the Office 365 E3 license (with the Power Automate service plan disabled) and the Enterprise Mobility + Security E5 license. This fulfills the two requirements applicable to everyone.

2. Group 2 (Research Department): This group will contain only the research users (User1, User3, User5). It will be assigned the Power BI Pro license.

3. Group 3 (Marketing Department): This group will contain only the marketing users (User2, User4). It will be assigned the Visio Plan 2 license.

This three-group structure correctly assigns all required licenses and logically separates the common "base" licenses from the department-specific "add-on" licenses, representing the most efficient and scalable management approach.

A. 1: A single group cannot be used, as it's impossible to selectively assign the Power BI Pro and Visio licenses to only specific members within that one group.

B. 2: Using only two groups (e.g., one for Research and one for Marketing) would require assigning the common licenses (O365 E3 and EMS E5) to both groups, creating redundant management.

D. 4: Four groups are unnecessary. The two licenses required by all users (Office 365 E3 and EMS E5) can be efficiently assigned to a single "all users" group.

E. 5: Five groups are excessive. There are only three distinct licensing policies required for the specified user populations (All Users, Research, and Marketing).

1. Microsoft Entra documentation

"What is group-based licensing in Microsoft Entra ID?": This document outlines the core principles. It states

"You can assign one or more license products to a group." This supports assigning both Office 365 E3 and EMS E5 to a single "All Users" group. It also explains that a user who is a member of multiple groups inherits the union of all assigned licenses

which is the principle that makes the three-group solution work. (See the section "How does group-based licensing work?").

2. Microsoft Entra documentation

"Assign licenses to users by group membership in Microsoft Entra ID": This guide provides scenarios for license management. The examples illustrate the best practice of using a base group for common licenses and then layering additional licenses for specific user sets via other groups

which directly supports the three-group answer. (See the section "Group-based licensing scenarios").

3. Microsoft Entra documentation

"Group-based licensing additional scenarios": This document details more complex situations

including how the system resolves license conflicts when a user is in multiple groups. The principle of license inheritance (union of services) is foundational to the solution requiring separate groups for separate license assignments. (See the section "Use multiple groups to manage licenses").

Pass-through authentication (PTA) is the correct solution because it directly validates user credentials against the on-premises Active Directory in real time. This process inherently enforces all on-premises password policies, including complexity, account lockout, and password expiry, at the moment of sign-in. Additionally, PTA is fully compatible with Microsoft Entra Self-Service Password Reset (SSPR) when password writeback is enabled in Microsoft Entra Connect. This combination meets both of the specified requirements by leveraging the on-premises infrastructure for authentication policy enforcement while allowing users to manage their passwords from the cloud.

A. Microsoft Entra ID Protection: This is a security feature for detecting and responding to identity-based risks. It is not a primary user authentication method for a hybrid identity scenario.

B. Microsoft Entra Seamless Single Sign-On (Microsoft Entra Seamless SSO): This is a feature that improves the user sign-in experience on corporate devices. It works alongside either PTA or Password Hash Synchronization but is not the core authentication method itself.

D. password hash synchronization: This method authenticates users in the cloud using a synchronized hash of their on-premises password. It does not enforce on-premises policies like account lockout or logon hours in real time during authentication.

1. Microsoft Entra documentation

"What is Microsoft Entra Pass-through Authentication?"

Section: "Key benefits of using Microsoft Entra Pass-through Authentication": This section explicitly states

"User sign-in requests are validated directly against your on-premises Active Directory. As a result

you can enforce your on-premises password and account lockout policies." This directly supports the requirement to enforce on-premises policies.

2. Microsoft Entra documentation

"Choose the right authentication method for your Microsoft Entra hybrid identity solution"

Table: "Compare methods": The table shows that Pass-through Authentication "Enforces on-premises Active Directory account policies

such as account lockouts

password expiration

and permitted sign-in hours." In contrast

Password Hash Synchronization does not offer this real-time enforcement for sign-in.

3. Microsoft Entra documentation

"How does self-service password reset writeback work in Microsoft Entra ID?"

Section: "Supported operations": This document confirms that password writeback

a key component of SSPR for hybrid identities

is supported for users synchronized via Microsoft Entra Connect who are using Pass-through authentication or Password hash synchronization. This confirms PTA meets the SSPR requirement.

An auto-labeling policy is the correct choice because it is designed to automatically apply a sensitivity label to content that matches specific conditions. In this scenario, the condition is the presence of a credit card number (a sensitive information type). You would first create a sensitivity label configured to apply encryption. Then, you create an auto-labeling policy that uses this label and targets content containing the "Credit Card Number" sensitive information type. When a document with a credit card number is added to SharePoint, OneDrive, or Exchange, the policy automatically detects it and applies the encryption-enabled label.

A. a retention policy: Retention policies are used to manage the data lifecycle (retaining or deleting content) and do not apply encryption based on content.

B. a retention label policy: While retention labels can be auto-applied based on sensitive information, their primary function is to manage retention and disposition, not to apply encryption.

D. an insider risk policy: Insider risk policies are designed to detect and manage risky user activities to prevent data leakage or theft, not to automatically encrypt files upon creation.

1. Microsoft Learn. (2024). Automatically apply a sensitivity label to content in Microsoft 365.

Section: "How auto-labeling policies for files and emails work"

Quote/Paraphrase: "Auto-labeling policies can automatically apply sensitivity labels to files and emails when they match conditions that you specify. One of the key conditions is when content contains specific types of sensitive information

such as credit card numbers. The sensitivity label itself is what carries the protection setting

such as encryption."

2. Microsoft Learn. (2024). Use sensitivity labels to apply encryption.

Section: "How encryption works"

Quote/Paraphrase: "When you apply encryption for a sensitivity label

the protection settings are embedded in the content... You can use auto-labeling policies to find content with sensitive information and automatically apply a label that's configured for encryption."

3. Microsoft Learn. (2024). Learn about retention policies and retention labels.

Section: "Comparing retention policies and retention labels"

Quote/Paraphrase: This document clarifies that the purpose of retention policies and labels is to "retain content so that it can't be permanently deleted before the end of the retention period" and to "delete content permanently at the end of the retention period." This confirms their function is not encryption.