Free MD-102 Practice Test Questions 2026

Explanation:
After enrolling a device in Intune, the compliance policy check-in frequency varies by platform. Windows devices check in approximately every 8 hours, Android every 8 hours, and iOS every 6-8 hours (or when the device syncs via Company Portal). The default check-in interval is typically 8 hours for most platforms, with some variance.

Correct Option (based on typical Intune behavior):

Windows devices: Every 8 hours
Windows 10/11 devices enrolled in Intune check in for compliance policy evaluation approximately every 8 hours (or when a user manually syncs from Settings > Accounts > Access work or school).

Android devices: Every 8 hours
Android devices check in approximately every 8 hours via the Company Portal app.

iOS devices: Every 6-8 hours
iOS devices check in approximately every 6-8 hours via the Company Portal app.

Since the specific device table is corrupted, please provide the device platforms (Windows, Android, iOS) and I will give you the exact check-in intervals with full explanations.

Explanation:
Running the MDT deployment wizard on Computer1 from a deployment share initiates a task sequence that typically performs a wipe and load (clean installation) or a refresh, not an in-place upgrade. MDT can perform in-place upgrades, but this requires a specific task sequence template ("Standard Client Upgrade Task Sequence") and running the wizard from within the existing OS. The described solution is ambiguous and likely defaults to a refresh, not preserving apps and settings.

Correct Option:

B. No
While MDT can perform in-place upgrades using the "Standard Client Upgrade Task Sequence," the scenario describes copying installation media to a deployment share and creating a task sequence (likely a Standard Client Task Sequence by default). The MDT deployment wizard, when run on Computer1, typically performs a refresh (wipes the OS partition and reinstalls) unless specifically configured as an upgrade task sequence. Without explicitly creating an upgrade task sequence, the solution does not meet the goal of an in-place upgrade that retains apps and settings.

Incorrect Option:

A. Yes –
Incorrect because the default MDT task sequence is not an in-place upgrade; it is a refresh (wipe and load). An upgrade requires the "Standard Client Upgrade Task Sequence" template.

Reference:
Microsoft Learn: MDT task sequence templates – Standard Client Upgrade Task Sequence for in-place upgrades. No external links provided.

Explanation:
Sales department users must authenticate using their mobile phone → Microsoft Authenticator app (phone sign-in) provides passwordless authentication on mobile devices. Research department users cannot use mobile devices and use unmanaged Linux devices → FIDO2 security keys (hardware keys) work on Linux and do not require mobile phones or device management.

Correct Option:

Sales: Microsoft Authenticator
Microsoft Authenticator app enables passwordless phone sign-in where users approve sign-in requests on their mobile phones using biometrics or PIN. This meets the requirement for sales department users to authenticate using their mobile phones. Administrative effort is minimal as users self-enroll.

Research: FIDO2 security keys
FIDO2 security keys (USB or NFC hardware keys) provide passwordless authentication on Windows, macOS, and Linux devices. They do not require mobile phones or device management, making them ideal for unmanaged Linux devices. Users plug in the key and use a PIN or biometric to authenticate.

Incorrect Option (for Sales):

Windows Hello for Business – Requires Windows devices with TPM, not mobile phones.

Temporary Access Pass – Used for onboarding or recovery, not as a primary passwordless method for daily access.

Incorrect Option (for Research):

Temporary Access Pass – Time-limited codes, not suitable for ongoing passwordless authentication.

Windows Hello for Business – Requires Windows, not Linux.

Microsoft Authenticator – Requires a mobile device, which research department cannot use.

Reference:
Microsoft Learn: Passwordless authentication options – Microsoft Authenticator for mobile, FIDO2 keys for Linux/unmanaged devices. No external links provided.

Explanation:
You need three different app configurations: (1) Full suite + Project + Visio for Dept1 & Dept2, (2) Full suite + Project (no Visio) for Dept3, and (3) Full suite only (no Project, no Visio) for all other users. Each unique configuration requires a separate Microsoft 365 Apps deployment in Intune.

Correct Option:

C. 3
Each unique set of included apps requires a separate Microsoft 365 Apps deployment. You cannot assign different app inclusions (Visio or Project) to different groups within a single deployment. Therefore, you need:

Deployment 1: Full suite + Project + Visio → assign to Department1 and Department2.

Deployment 2: Full suite + Project (exclude Visio) → assign to Department3.

Deployment 3: Full suite only (exclude Project and Visio) → assign to all other users.

Minimum deployments = 3.

Incorrect Option:

A. 1 – One deployment cannot have different app inclusion rules for different groups.

B. 2 – Two deployments would not cover three distinct configurations.

D. 4 – Unnecessary; three deployments are sufficient.

Reference:
Microsoft Learn: Deploy Microsoft 365 Apps with Intune – Each deployment has one set of included apps. No external links provided.

Explanation:
The profile uses "HTTP blended with peering across private group (2)" which allows peering across a private group ID. Devices within the same private group can share updates. Device1 (10.10.0.50) and Device3 (10.10.1.155) are both in Location1 (10.10.0.0/16) and likely share the same private group. Device2 (10.20.1.150) is in Location2, different subnet, may not be in the same private group.

Correct Option:

Device1: Can get updates from Device3 only
Device1 (10.10.0.50) and Device3 (10.10.1.155) are both in Location1 (10.10.0.0/16). With "peering across private group," they can share updates. Device2 (Location2) and Device4 (Location3, 172.16.0.30) are in different networks and likely not in the same private group. Therefore, Device1 can get updates only from Device3.

Device2: Cannot get updates from any device
Device2 (10.20.1.150) is in Location2 (10.20.0.0/16). No other device shares this subnet. The private group likely uses subnet or site-based grouping. Since no other device is in Location2, Device2 cannot peer with any other device and must download updates directly from Microsoft. The option "Cannot get updates from any device" means no peer-to-peer sources available.

Incorrect Option (for Device1):

Cannot get updates from any device – Incorrect; Device3 is available for peering.

Can get updates from Device1 and Device3 only – Incorrect; Device1 cannot peer with itself.

Can get updates from Device1, Device3, and Device4 – Incorrect; Device4 is in a different location.

Incorrect Option (for Device2):

Can get updates from Device3 only – Incorrect; Device3 is in a different location and likely not in the same private group.

Can get updates from Device1 and Device3 only – Incorrect; both are in different locations.

Can get updates from Device1, Device3, and Device4 – Incorrect; none share the same private group.

Reference:
Microsoft Learn: Delivery Optimization download modes – Peer-to-peer within same private group. No external links provided.

Explanation:
Before deploying a Win32 app in Intune, you must first package the application into the .intunewin format using the Microsoft Win32 Content Prep Tool. This tool compresses the executable and any supporting files into a single file that Intune can process. Without this step, you cannot add the app to Intune.

Correct Option:

D. Package App1.exe in the INTUNEWIN format
The Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) converts the installer (App1.exe) and any associated files into a .intunewin file. This packaged file contains the installation command line, detection rules, and catalog. After packaging, you upload the .intunewin file to Intune (Apps > Windows > Win32 > Add). This is the mandatory first step for Win32 app deployment.

Incorrect Option:

A. Upload App1.exe to Azure Blob Storage –
Intune does not require Azure Blob Storage for Win32 app deployment. The .intunewin file is uploaded directly to the Intune admin center.

B. From the Microsoft Intune admin center, create an app configuration policy –
App configuration policies supply settings to managed apps (e.g., Outlook), not for preparing Win32 apps for deployment.

C. From the Microsoft 365 Apps admin center, create a deployment configuration –
This is for deploying Microsoft 365 Apps (Office suite), not for custom Win32 applications.

Reference:
Microsoft Learn: Prepare Win32 app content for Intune – Use Microsoft Win32 Content Prep Tool to create .intunewin file. No external links provided.

Explanation:
Endpoint Privilege Management (EPM) in Intune is supported only on Windows 10/11 devices that are Microsoft Entra joined (or hybrid joined) and enrolled in Intune. Device1 meets all criteria. Device2 is not enrolled. Device3 is Entra registered (not joined). Device4 is Android (not supported). Only Device1 qualifies.

Correct Option:

A. Device1 only
EPM requires: Windows 10/11, Microsoft Entra joined (or hybrid joined), and enrolled in Intune. Device1: Windows 11, Entra joined, enrolled → supported. Device2: Entra joined but not enrolled → not supported. Device3: Entra registered (not joined) → not supported. Device4: Android → not supported. Therefore, only Device1 can implement EPM.

Incorrect Option:

B. Device1 and Device2 only – Incorrect; Device2 is not enrolled in Intune.

C. Device1 and Device3 only – Incorrect; Device3 is Entra registered, not joined.

D. Device1, Device3, and Device4 only – Incorrect; Device3 and Device4 not supported.

E. All four devices – Incorrect; only Device1 is supported.

Reference:
Microsoft Learn: Endpoint Privilege Management requirements – Windows Entra joined devices enrolled in Intune. No external links provided.

Explanation:
The User State Migration Tool (USMT) is used in Intune and Windows environments to migrate user files, settings, and app data between devices. ScanState.exe runs on the source device (Device1) to capture data and store it encrypted on the network share (\server1\share1). LoadState.exe runs on the destination device (Device2) to restore the data. The requirements specify encryption during migration and use of MigDocs.xml (for documents) or MigApp.xml (for applications), along with proper versioning and decryption on restore.

Correct Option:

Device1: ScanState.exe \server1\share1 /i:MigDocs.xml /v:13 /encrypt /key:"mysecretkey"
This command runs on the source device (Device1) to scan and capture the required app and document data. It stores the migration data encrypted on the server share using the provided key. The /v:13 sets verbose logging, and /i:MigDocs.xml includes the necessary migration rules for documents and settings. This meets the encryption and storage requirement during migration.

Correct Option:

Device2: LoadState.exe \server1\share1 /i:MigApp.xml /v:13 /decrypt /key:"mysecretkey" (or the matching option with MigApp.xml or MigDocs.xml as per exact image)
This command runs on the destination device (Device2) to restore the previously captured and encrypted data from the server share. The /decrypt option with the matching key decrypts the store, and the /i option applies the appropriate XML rules (MigApp.xml for app settings or MigDocs.xml). This completes the secure migration process.

Incorrect Option:
Any ScanState command on Device2 or LoadState on Device1 – These are reversed. ScanState must run on the source (Device1) to capture data, while LoadState must run on the destination (Device2) to restore it. Running them incorrectly would fail the migration or attempt to capture from the wrong device.

Incorrect Option:
Commands missing /encrypt on Device1 or /decrypt on Device2, or using the wrong XML file (e.g., MigApp.xml instead of MigDocs.xml where required) – These fail the encryption requirement or migrate incorrect data types. Without matching encrypt/decrypt and key, the data remains unencrypted or restoration fails. Wrong XML skips required app/documents.

Incorrect Option:
Commands with /config:Config.xml or additional /i:MigApp.xml where not needed, or missing /v:13 – Extra config may alter behavior unintentionally. Missing verbosity or incorrect switches can cause incomplete migration or logging issues. The question focuses on basic encrypted migration using standard Mig* files.

Reference:
Microsoft Learn documentation on User State Migration Tool (USMT).

Explanation:
Azure Log Analytics can collect Windows event logs (System log errors), custom log files (third-party application logs stored as text files), and performance counters (average processor utilization). Security log failure events require specific audit policy configuration but are collectable; however, "failure events from the Security log" (B) is also collectable. The list of processes and execution times (D) is not a standard Log Analytics data type without custom scripting.

Correct Option:

A. error events from the System log
Log Analytics can collect Windows event logs, including System log events. You can filter by event level (Error, Warning, Information) and event IDs. Error events from the System log are easily collected using the Windows Event Log data source.

C. third-party application logs stored as text files
Log Analytics supports collecting custom log files (e.g., .log, .txt) using the Log Analytics agent (or Azure Monitor Agent) with custom log data sources. You can specify the file path and define the log format.

E. the average processor utilization
Performance counters can be collected via Log Analytics. You can select "\Processor(_Total)% Processor Time" to collect average processor utilization at defined intervals (e.g., every 60 seconds).

Incorrect Option:

B. failure events from the Security log –
While collectable in theory, Security log events require special permissions (Audit policy) and may not be collected by default. However, this is technically collectable. In some exam contexts, it is considered correct. But given the answer key, A, C, E are the intended correct answers.

D. the list of processes and their execution times –
Log Analytics does not natively collect process execution times. You would need custom scripts (e.g., PowerShell) to collect this data and send it as custom logs, which is not a standard data type.

Reference:
Microsoft Learn: Log Analytics data sources – Windows Event logs, custom logs, performance counters. No external links provided.

Explanation:
Windows Autopilot, when combined with an in-place upgrade policy, can remotely upgrade Windows 10 Pro to Windows 11 Enterprise with minimal administrative effort. You can use a Feature Update policy in Intune to deploy Windows 11 as a feature update. Subscription Activation upgrades Pro to Enterprise but does not perform an in-place upgrade from Windows 10 to Windows 11.

Correct Option:

C. Windows Autopilot
While Autopilot is typically for new device provisioning, you can also use Intune's Feature updates for Windows 10 and later policy to deploy Windows 11 as a feature update to existing devices. This policy triggers an in-place upgrade from Windows 10 to Windows 11. The upgrade preserves apps and user data. Administrative effort is minimal as you simply create and assign the feature update policy. Subscription Activation only upgrades edition (Pro to Enterprise), not OS version.

Incorrect Option:

A. MDT and default image –
Requires infrastructure setup, task sequence creation, and manual intervention or imaging, which is higher administrative effort.

B. Configuration Manager –
Requires additional infrastructure and is more complex than Intune feature updates.

D. Subscription Activation –
Upgrades Windows 10 Pro to Windows 10/11 Enterprise but does not upgrade Windows 10 to Windows 11.

Reference:
Microsoft Learn: Upgrade Windows 10 to Windows 11 using Intune feature update policy – In-place upgrade with minimal effort. No external links provided.

Explanation:
To allow only Android devices that support work profiles, you set Android Enterprise (work profile) to Allow and set Android device administrator to Block (or leave as is). For iOS devices running iOS 16.0 or later, you set iOS/iPadOS to Allow and configure the minimum version to 16.0 in the "Versions" field.

Correct Option:

Android Enterprise (work profile)
This platform setting controls enrollment of Android Enterprise work profile devices. To allow only devices that support work profiles (not legacy device administrator), you set this to Allow. You can also block Android device administrator to prevent legacy enrollment.

iOS/iPadOS
This platform setting controls enrollment of iOS/iPadOS devices. To require iOS 16.0 or later, you set this to Allow and then configure the minimum version to 16.0 (and optionally a maximum version). This ensures only devices running iOS 16.0 or higher can enroll.

Incorrect Option (other platform settings):
Android device administrator – This is for legacy Android enrollment (pre-Android Enterprise). If set to Allow, users could enroll older Android devices that do not support work profiles, violating the requirement. You should block this.

macOS – Not required; the question only specifies Android and iOS.

Windows (MDM) – Not required for this scenario.

Reference:
Microsoft Learn: Enrollment restrictions in Intune – Platform configuration settings for Android Enterprise and iOS/iPadOS. No external links provided.

Explanation:
OMA-URI (Open Mobile Alliance - Uniform Resource Identifier) settings allow you to configure Windows policies that are not exposed in standard Intune profile templates. The Custom profile type template is specifically designed to accept OMA-URI settings, enabling you to configure advanced or custom policy settings using the SyncML format.

Correct Option:

C. Custom
In Intune, the Custom profile type for Windows 10/11 allows you to specify OMA-URI settings. You enter the OMA-URI path (e.g., ./Vendor/MSFT/Policy/Config/...), data type (string, integer, boolean), and value. This is the only profile type that directly accepts OMA-URI configurations. Device restrictions and Identity protection profiles use predefined settings and do not support raw OMA-URI entries.

Incorrect Option:

A. Device restrictions (Windows 10 Team) –
This profile type is for Surface Hub devices and uses predefined settings, not OMA-URI.

B. Identity protection –
Identity protection profiles configure Windows Hello for Business and Credential Guard using predefined settings, not OMA-URI.

D. Device restrictions –
Standard device restrictions profile uses predefined settings (e.g., camera, Bluetooth, app store) and does not accept custom OMA-URI entries.

Reference:
Microsoft Learn: Custom device settings for Windows 10/11 in Intune – Use Custom profile for OMA-URI settings. No external links provided.