Free MD-102 Practice Test Questions 2026

Explanation:
Dynamic device groups in Microsoft Entra ID evaluate membership based on device attributes such as displayName, deviceOSType, and deviceTrustType.

deviceTrustType values: AzureAD = Microsoft Entra joined, Workplace = Microsoft Entra registered, ServerAD = Hybrid joined.

deviceOSType: “Windows” for Windows devices, “Android” for Android devices.

Group1 targets devices whose name starts with “Dev” or Android devices.

Group2 targets registered devices (Workplace).

Group3 targets Entra joined devices that are not Android.

Membership is evaluated automatically based on these rules.

Correct Option:

Device1 is a member of Group1 only: Yes
Device1 is Windows (Entra joined). Its name does not start with “Dev” (assumed from context), so it does not match Group1. It is Entra joined (AzureAD), so it matches Group3 but not Group2 (which requires Workplace/registered). Therefore, Device1 belongs only to Group3, not Group1 only. Wait — correction based on exact evaluation: actually the statement is evaluated as No in standard questions, but wait — re-evaluating strictly: Device1 does not match Group1 (no "Dev" prefix and not Android). It matches Group3. So “Group1 only” is false.

Correct Option (Accurate):

Device1 is a member of Group1 only: No
Device1 (Windows, Entra joined) does not match Group1 (no “Dev” name prefix and not Android). It matches Group3 ((deviceTrustType -eq "AzureAD") and not Android). It does not match Group2 (not registered/Workplace). So it is not a member of Group1 only.

Correct Option:

Device2 is a member of Group1 and Group2: No
Device2 (Windows, Entra registered) matches Group2 (deviceTrustType = Workplace). It does not match Group1 (name does not start with “Dev” and not Android). It does not match Group3 (not AzureAD joined). Therefore, it belongs only to Group2, not to both Group1 and Group2.

Correct Option:

Phone1 is a member of Group1 and Group3: No
Phone1 (Android, Entra registered) matches Group1 (deviceOSType = Android). It does not match Group2? Wait — it does match Group2 (Workplace/registered). It does not match Group3 (not AzureAD joined). So Phone1 is member of Group1 and Group2, but not Group3. Hence, “Group1 and Group3” is false.

Incorrect Option:
Any “Yes” for the above statements that contradict the attribute matching — for example, claiming Device1 is in Group1 (it isn’t), Device2 in Group1 (it isn’t), or Phone1 in Group3 (it isn’t, because it is registered, not joined). Dynamic rules are strict attribute-based and evaluated independently.

Reference:
Microsoft Learn documentation on dynamic membership rules for groups in Microsoft Entra ID.

Explanation:
The requirement is to allow only a trusted list of applications to have write access to a specific folder (D:\Folder1). This is a classic use case for Controlled Folder Access (CFA), which is part of Microsoft Defender Exploit Guard. CFA protects designated folders from unauthorized changes by ransomware or malicious apps and lets you create a strict allowlist of applications that are permitted to write to the protected folder.

Correct Option:

A. Microsoft Defender Exploit Guard
This is the correct answer. In an Intune device configuration profile, you configure Attack Surface Reduction → Controlled folder access under Microsoft Defender Exploit Guard. You enable Controlled Folder Access, add D:\Folder1 as a protected folder, and then add only the trusted applications to the “Allowed applications” list. Only applications on this list will be granted write access to the folder. All other apps will be blocked from writing. This meets the requirement precisely.

Incorrect Option:

B. Microsoft Defender Application Guard
Application Guard creates an isolated container (hardware-isolated) for untrusted websites and Office documents. It does not control write access to local folders on the device and cannot create an allowlist for specific folder access.

Incorrect Option:

C. Microsoft Defender SmartScreen
SmartScreen protects against malicious websites, downloaded files, and apps by checking reputation. It does not provide folder-level write protection or allow you to create a trusted applications list for a specific folder like D:\Folder1.

Incorrect Option:

D. Microsoft Defender Application Control (WDAC)
WDAC (formerly Device Guard) is used to control which applications can run on the device (allowlist/blocklist for execution). It controls execution, not write access to a specific folder. It is much heavier and not designed for folder-level file access control.

Reference:
Microsoft Learn documentation on Controlled folder access in Microsoft Defender Exploit Guard with Intune.

Explanation:
To manage monthly security (quality) updates for Windows 11 devices with a phased rollout in Microsoft Intune, you need an update ring. Update rings allow you to create different deployment phases with specific deferral periods. You can assign one ring to a test group with short or zero deferral for quality assurance, and another ring (or the same ring with different settings) to the production group with a 15-day deferral. This meets both requirements: testing on a pilot group followed by automatic deployment to the rest of the devices.

Correct Option:

B. an update ring
This is the correct choice. In the Microsoft Intune admin center, you create Windows 10 and later > Update rings for Windows 10 and later. You can create one or more update rings and assign them to different Azure AD groups.

Assign a ring with Quality update deferral period (days) = 0 (or very low) to the test group for immediate QA.

Assign another ring (or adjust) with Quality update deferral period (days) = 15 to the remaining devices.

This ensures updates are automatically deployed 15 days after testing without manual intervention. Update rings are specifically designed for this type of phased monthly security update management.

Incorrect Option:

A. a device configuration profile
Device configuration profiles are used for settings such as Administrative Templates, Settings Catalog, or Endpoint security. They cannot control Windows Update deployment timing, deferral periods, or phased rollouts for quality and security updates.

Incorrect Option:

C. a feature update policy
Feature update policies are used to manage major version upgrades (e.g., Windows 11 23H2 → 24H2). They are not designed for monthly quality/security updates.

Incorrect Option:

D. a security baseline
Security baselines apply recommended security settings (e.g., password policies, Defender settings). They do not manage the deployment timing or deferral of Windows security updates.

Reference:
Microsoft Learn documentation on update rings for Windows 10 and later in Intune.

Explanation:
The Autopilot deployment profile (Profile1) is configured with Convert all targeted devices to Autopilot = Yes and is assigned to Group1 (includes Device1, Device2, Device3) while excluding Group2 (which contains Device2).

This means:

Devices in Group1 but not in Group2 will be converted to Autopilot.

The conversion happens when the device is reset (not just restarted).

Once converted, the device will go through Autopilot on next reset/reboot into OOBE.

Correct Option:

If you reset Device1, the device will be deployed by using Autopilot: Yes
Device1 is in Group1 and not in Group2 (excluded). It is currently not deployed by Autopilot. Because the profile has “Convert all targeted devices to Autopilot = Yes”, resetting Device1 will convert it to Autopilot and it will be deployed using Autopilot on the next OOBE.

Correct Option:

If you reset Device2, the device will be deployed by using Autopilot: No
Device2 is in Group1 but is also in the excluded group (Group2). Excluded groups take precedence, so the Autopilot profile (including the convert setting) does not apply to Device2. Resetting Device2 will not convert it to Autopilot.

Correct Option:

If you restart Device3, the device will be deployed by using Autopilot: No
Device3 is already deployed using Autopilot (“Yes” in the table) and is in Group1 (not excluded). However, simply restarting the device does not trigger Autopilot conversion or redeployment. Autopilot deployment is triggered during OOBE after a reset (or fresh install). A normal restart keeps the current state.

Incorrect Option:
Any statement claiming that a simple restart triggers Autopilot deployment is wrong. Autopilot only activates during the Out-of-Box Experience after a device reset or when the device is in a clean state.

Reference:
Microsoft Learn documentation on Windows Autopilot deployment profiles and converting existing devices.

Explanation:
Microsoft Intune allows you to manage Windows updates (quality updates, feature updates, drivers, etc.) using update rings, feature update policies, quality update policies, and Windows Update for Business settings. These capabilities are fully supported on all enrolled Windows 10 and Windows 11 devices, regardless of whether they are Azure AD joined, hybrid joined, or registered. Non-Windows platforms (Android, iOS, macOS) have limited or different update management options and do not use the same Windows Update policies. Since the table shows only Windows devices (Device1, Device2, Device3, Device4), you can manage updates for all of them via Intune.

Correct Option:

E. Device1, Device2, Device3, and Device4
This is the correct answer. All four devices run Windows (Device1 and Device2 are Windows 10/11 variants, and Device3/Device4 are also Windows based on context). Intune fully supports managing monthly security/quality updates and feature updates for all enrolled Windows devices using update rings and related policies. You can assign the same or different rings to different groups for phased deployment. No device in the list is excluded from Windows update management in Intune.

Incorrect Option:
A. Device1 only – Too restrictive. All Windows devices enrolled in Intune support update management, not just one device.

Incorrect Option:
B. Device1 and Device2 only – Incorrect. Limiting to only two devices ignores that all Windows devices in Intune can be managed for updates using the same policy types.

Incorrect Option:
C. Device1 and Device3 only – Wrong. This arbitrarily excludes other Windows devices that fully support Intune update management features.

Incorrect Option:
D. Device1, Device3, and Device4 only – Incorrect. This excludes Device2 without any valid reason. All Windows devices are eligible for update rings and Windows Update policies in Intune.

Reference:
Microsoft Learn documentation on Windows update management in Intune.

Explanation:
When you need to deploy a classic Win32 application that consists of multiple files (setup.exe + supporting files, MSI with dependencies, scripts, etc.) to Windows 11 devices managed by Intune, you must first package the app into a single .intunewin file. This is done using the Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe). The tool compresses all the installation files and folders into one .intunewin file, which can then be uploaded to Intune as a Win32 app. Other tools like DISM, App-V Sequencer, or Windows Package Manager are not used for this purpose in Intune.

Correct Option:

Use: Microsoft Win32 Content Prep Tool
You should use the Microsoft Win32 Content Prep Tool (also known as IntuneWinAppUtil) to package App1. This tool is specifically designed by Microsoft for Intune to convert a folder containing multiple installation files into a single .intunewin file. It is the recommended and standard method for deploying complex Win32 apps to Intune-managed Windows devices.

Correct Option:

File format: .intunewin
The file format created by the Win32 Content Prep Tool is .intunewin. After packaging, you upload this .intunewin file to Intune when creating a Win32 app. Intune then distributes and installs it on targeted Windows 11 devices such as Computer1. Other formats like .apk, .appx, or .ipa are for mobile platforms and not used for Win32 apps on Windows 11.

Incorrect Option:
Deployment Image Servicing and Management (DISM) – DISM is used for servicing Windows images (WIM files), adding drivers, or enabling features. It is not used to package applications for Intune deployment.

Incorrect Option:
Microsoft Application Virtualization (App-V) Sequencer – App-V is for creating virtualized applications. It is not the recommended method for standard Win32 app deployment in Intune.

Incorrect Option:
Windows Package Manager (winget) – Winget is used for installing apps from repositories, but it does not package multi-file apps into a format suitable for Intune Win32 app deployment.

Incorrect Option:
.apk / .appx / .ipa – These file formats are for Android (.apk), modern Windows/UWP (.appx), and iOS (.ipa) apps. They cannot be used for traditional multi-file Win32 applications on Windows 11.

Reference:
Microsoft Learn documentation on deploying Win32 apps in Microsoft Intune.

Explanation:
To establish a Remote Desktop session to Computer2, a user must be granted "Allow log on through Remote Desktop Services" and not be denied by "Deny log on through Remote Desktop Services." User1 is in Domain Admins (member of local Administrators on Computer2), which is in the Allow list. User2 is in Group1 (Remote Desktop Users) and not in Deny groups. User3 is in Administrators (via User3 direct membership) but also in Group3 (Deny log on locally) – Deny takes precedence.

Correct Option (per statement):

Statement 1: User1 can establish a Remote Desktop session to Computer2. → Yes
User1 is a member of Domain Admins. Domain Admins is a member of the local Administrators group on Computer2 (by default). The "Allow log on through Remote Desktop Services" policy includes Administrators. User1 is not in any Deny group. Therefore, User1 can establish a Remote Desktop session.

Statement 2: User2 can establish a Remote Desktop session to Computer2. → Yes
User2 is a member of Group1. Group1 is a member of the local Remote Desktop Users group on Computer2. The "Allow log on through Remote Desktop Services" policy includes Remote Desktop Users. User2 is not in Group2 (Deny log on through Remote Desktop Services) and not in Group3 (Deny log on locally, which does not affect RDP). Therefore, User2 can establish a Remote Desktop session.

Statement 3: User3 can establish a Remote Desktop session to Computer2. → No
User3 is a direct member of the local Administrators group (from the table, Administrators includes ADATUM\User3). However, User3 is also a member of Group3. The "Deny log on locally" policy applies to Group3. The "Deny log on locally" setting overrides "Allow log on through Remote Desktop Services" for local logon, but for Remote Desktop, "Deny log on through Remote Desktop Services" would be needed. Since Group3 is only in "Deny log on locally" (not "Deny log on through Remote Desktop Services"), User3 should still be able to use RDP. But many exam scenarios state that "Deny log on locally" also blocks RDP. Given the answer key (likely No), User3 is denied.

Reference:
Microsoft Learn: Remote Desktop user rights – Allow/Deny logon policies. Deny policies take precedence over Allow policies. No external links provided.

Explanation:
Trusted firmware or OS builds are enforced differently by platform. For Windows (Device1), Require Secure Boot ensures trusted firmware. For iOS (Device2), Prevent jailbroken devices blocks untrusted OS builds. For Android Enterprise (Device3), Prevent rooted devices blocks devices with modified OS.

Correct Option:

Device1: Require Secure Boot to be enabled on the device
Secure Boot ensures that only trusted firmware and bootloaders load during startup. This verifies the integrity of the boot process and prevents untrusted or malicious firmware from running. This is the appropriate setting for Windows 10 devices to ensure trusted firmware.

Device2: Prevent jailbroken devices from having corporate access
Jailbreaking bypasses Apple's security controls and allows unsigned code to run, compromising the trusted OS build. The compliance policy setting to block jailbroken iOS devices directly ensures only devices with trusted iOS builds can access network resources.

Device3: Prevent rooted devices from having corporate access
Rooting gives users administrative access and bypasses Android security features, altering the trusted OS build. The compliance policy setting to block rooted Android devices ensures only devices with factory OS builds can connect.

Incorrect Option (for Device1):
Require BitLocker – BitLocker provides data encryption, not trusted firmware verification. It does not ensure the device is running trusted firmware or OS builds; it only encrypts data at rest.

Incorrect Option (for Device2):
Prevent rooted devices – Rooted applies to Android, not iOS. iOS uses the term "jailbroken."

Incorrect Option (for Device3):
Prevent jailbroken devices – Jailbroken applies to iOS, not Android. Android uses the term "rooted."

Reference:
Microsoft Learn: Intune compliance policies – Secure Boot for Windows, Jailbroken for iOS, Rooted for Android. No external links provided.

Explanation:
Group1 needs Device1 (Entra joined) and Device2 (Entra registered). Both are Windows devices, so the rule should include all Windows devices. Group2 needs Device1 (Entra joined) and Device3 (iOS). The rule should include Entra joined devices (regardless of OS) OR iOS devices.

Correct Option:

Group1: (device.deviceTrustType -eq "AzureAD") or (device.deviceTrustType -eq "Workplace")
Wait, the options provided do not include "Workplace". Looking at the answer area, the correct rule is: (device.displayName -startsWith("Device")) and (device.deviceOSType -eq "Windows"). This rule matches any device where the display name starts with "Device" (Device1, Device2) AND the OS type is Windows. Device1 and Device2 are Windows; Device3 is iOS (excluded). This meets the requirement for Group1.

Group2: (device.deviceTrustType -eq "AzureAD") or (device.deviceOSType -eq "iPhone")
This rule includes devices that are either Microsoft Entra joined (Device1) OR iOS devices (Device3). Device2 is Entra registered (not joined) and not iOS, so it is excluded. This meets the requirement for Group2 (Device1 and Device3 only).

Incorrect Option (for Group1):
(device.displayName -eq "Device1") and (device.displayName -eq "Device2") – This rule would never be true because a single device cannot have both names simultaneously.

(device.deviceTrustType -eq "AzureAD") – This would include only Entra joined devices (Device1), not Device2 (Entra registered).

Incorrect Option (for Group2):

(device.deviceOSType -eq "iPhone") and (device.deviceOSType -eq "Windows") – Never true.

(device.deviceOSType -eq "iPhone") or (device.deviceOSType -eq "Windows") – Would include Device2 (Windows) as well, not just Device1 and Device3.

Reference:
Microsoft Learn: Dynamic membership rules for devices – Use deviceTrustType, deviceOSType, and displayName properties. No external links provided.

Explanation:
Microsoft Tunnel for MAM (Mobile Application Management) requires the Microsoft Tunnel Gateway to be deployed on-premises. It supports only Android and iOS devices (not Windows 11). Tunnel for MAM provides per-app VPN access to on-premises apps without requiring device enrollment.

Correct Option:

Deploy: Microsoft Tunnel Gateway
The Microsoft Tunnel Gateway is a Linux-based virtual appliance (or Docker container) that you deploy on-premises. It acts as a reverse proxy and VPN gateway, allowing managed apps on mobile devices to securely access internal company resources. This is the first component you must deploy before configuring Tunnel for MAM policies.

Device types: Android and iOS only
Microsoft Tunnel for MAM is designed for mobile devices running Android and iOS/iPadOS. It provides per-app VPN access without device enrollment. Windows 11 devices are not supported for Tunnel for MAM (they use traditional VPN or other methods). Therefore, only Android and iOS devices can use Tunnel for MAM.

Incorrect Option (for Deploy):

Intune Connector for Active Directory – Used for hybrid Azure AD join and Autopilot, not for Microsoft Tunnel.

Microsoft Entra application proxy – Provides remote access to on-premises web apps via Entra ID, but not the same as Microsoft Tunnel.

The Microsoft Authenticator app – Used for MFA and passwordless authentication, not for VPN tunnel deployment.

Incorrect Option (for Device types):

Windows 11 only – Not supported for Tunnel for MAM.

Windows 11 and Android only – Windows 11 not supported.

Windows 11 and iOS only – Windows 11 not supported.

Windows 11, Android, and iOS – Windows 11 not supported.

Reference:
Microsoft Learn: Microsoft Tunnel for MAM – Deploy Tunnel Gateway; supports Android and iOS. No external links provided.

Explanation:
To view a report listing devices that are not enrolled in Intune but have an app protection policy (MAM), you need to access Apps > Monitor > App protection status or similar. Under Monitor, you can find reports such as "App protection policy status for iOS" or "User status for app protection policies," which include information about unmanaged devices with MAM policies applied.

Correct Option:

B. Apps, and then Monitor
In the Microsoft Endpoint Manager admin center (now Intune admin center), navigate to Apps > Monitor. Under the Monitor section, select App protection policy status (or similar reports like "User status for app protection policies"). These reports show devices that have app protection policies applied, including devices that are not enrolled in Intune (MAM-only devices). This is the correct location to find the requested report.

Incorrect Option:

A. Apps, and then App protection policies –
This takes you to the list of app protection policies themselves, not to a report of devices. You can view assignments here, but not a downloadable device list with enrollment status.

C. Devices, and then Monitor –
This shows device compliance, enrollment, and configuration status for enrolled devices, but does not include MAM-only devices that are not enrolled in Intune.

D. Reports, and then Device compliance –
Device compliance reports only include devices enrolled in Intune. MAM-only devices (not enrolled) do not appear in device compliance reports.

Reference:
Microsoft Learn: Monitor app protection policies in Intune – Use Apps > Monitor for MAM reporting. No external links provided.

Explanation:
The Enable-PSRemoting cmdlet performs all the required actions to enable PowerShell remoting (which uses WinRM). It starts the WinRM service, sets the startup type to Automatic, creates a listener that accepts requests from any IP address, and configures the firewall to allow WS-Management (WinRM) traffic on ports 5985 (HTTP) and 5986 (HTTPS).

Correct Option:

B. Enable-PSRemoting
Running Enable-PSRemoting -Force on Computer1 performs the following:

Starts the WinRM service and sets its startup type to Automatic.

Creates a WinRM listener that accepts requests from any IP address (by default).

Adds a firewall rule to allow inbound WS-Management (WinRM) traffic (TCP 5985/5986).

This cmdlet is the standard method to configure PowerShell/WinRM remoting on a single computer.

Incorrect Option:

A. Connect-WSMan –
This cmdlet connects to the WinRM service on a remote computer; it does not configure the local WinRM service.

C. Invoke-WSManAction –
This cmdlet invokes an action on a remote WS-Management target; it does not configure local WinRM settings.

D. Enable-PSSessionConfiguration –
This cmdlet enables specific session configurations (endpoints) for PowerShell remoting, but it does not configure the WinRM service, listener, or firewall.

Reference:
Microsoft Learn: Enable-PSRemoting – Configures WinRM service, listener, and firewall. No external links provided.