Free Microsoft MD-102 Practice Test Questions MCQs

Explanation:
The first requirement is to filter enrollment by platform and OS version—this is done via Enrollment restrictions, which block unapproved devices. The second requirement needs user-driven group mapping during enrollment, which is the purpose of Device categories (users pick a category that auto-adds the device to a corresponding Azure AD group).

Correct Option:

For “Ensure that only devices that have approved platforms and versions can enroll” → Enrollment restrictions
Enrollment restrictions allow you to set platform configuration, including blocking personally owned devices or specifying allowed OS versions (e.g., Android 8,9 and iOS 11,12). This is the standard control for device admission based on platform/version criteria.

For “Ensure devices are added to Azure AD groups based on a selection made by users during enrollment” → Device categories
Device categories let you define categories (e.g., “Sales,” “Engineering”) that users pick during enrollment. The device is then automatically added to the corresponding Azure AD group, enabling targeted policy and app deployment.

Incorrect Option:
Android enrollment / Apple enrollment / Windows enrollment – These are just enrollment workflow entry points, not settings that enforce version approval or dynamic user-driven group mapping. They cannot fulfill either requirement alone without restrictions or categories.


Corporate device identifiers – Used to pre-identify corporate-owned devices by serial number/IMEI to mark them as corporate, not to block OS versions or prompt users for group selection during enrollment.

Device categories – Incorrect for the first requirement because categories do not filter or block devices based on OS/platform version; they only assign groups post-enrollment based on user choice.

Enrollment restrictions – Incorrect for the second requirement because restrictions block or allow enrollment based on platform, ownership type, or version—they do not involve user selection for Azure AD group membership.

Reference:
Microsoft Learn: MD-102 – Manage device enrollment in Microsoft Intune. Topics include "Create enrollment restrictions" and "Create device categories and group mapping." No external links provided per your request.

Explanation:
Conditional Access enforces compliance by evaluating device risk signals from Defender for Endpoint. This requires an Intune connection (formerly Microsoft Defender for Endpoint integration) in Intune. Preventing suspicious scripts is achieved via Attack Surface Reduction (ASR) rules, specifically the "Block JavaScript or VBScript from launching downloaded executable content" rule.

Correct Option:

Enforces compliance: Intune connection
The Intune connection (Defender for Endpoint integration) must be enabled in Intune to allow Conditional Access policies to evaluate device risk levels (low/medium/high). Without this connection, Defender signals cannot be used for compliance enforcement. This is configured in Endpoint Manager under Endpoint security > Microsoft Defender for Endpoint.

Prevents suspicious scripts: An attack surface reduction (ASR) rule
ASR rules include specific rules designed to block malicious or suspicious scripts (e.g., JavaScript, VBScript, PowerShell obfuscated scripts) from executing. The rule "Block JavaScript or VBScript from launching downloaded executable content" directly addresses script-based attacks. ASR rules are configured in Intune as part of endpoint security policies.

Incorrect Option:

A device restriction policy – Device restriction policies control device features (camera, Bluetooth, app store) but do not enforce Defender compliance via Conditional Access nor block suspicious scripts. They focus on general device behavior, not script execution or risk-based compliance.

A security baseline – Security baselines apply recommended configuration settings for Windows or Defender, but they do not directly enforce Conditional Access compliance. While baselines include some ASR rules, the question asks for the specific feature to prevent scripts (ASR rule is the direct answer), and baselines are not required for the compliance requirement.

Reference:
Microsoft Learn: MD-102 – Configure Microsoft Defender for Endpoint integration with Intune for Conditional Access. ASR rules documentation for script blocking. No external links provided.

Explanation:
Client1 is on a public network. By default, Enable-PSRemoting blocks remote access on public networks for security. The -SkipNetworkProfileCheck parameter allows PSRemoting on public networks but still applies local subnet restrictions by default. The requirement to accept connections from local subnet only is already enforced automatically when using this switch.

Correct Option:

D. Enable-PSRemoting -SkipNetworkProfileCheck
This command enables PowerShell remoting on public network profiles by skipping the network profile check. Importantly, it still enforces the default firewall rule that allows incoming WinRM traffic only from the local subnet (not any remote subnet). This exactly matches the requirement: remoting enabled, but restricted to local subnet only.

Incorrect Option:

A. Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
This changes the firewall rule to accept WinRM traffic from any remote address, not just the local subnet. This violates the requirement to restrict connections to the local subnet only and creates a significant security risk on a public network.

B. Set-PSSessionConfiguration -AccessMode Local
This restricts PowerShell remoting to local sessions only (disables remote access entirely). This would prevent any remote PowerShell remoting connections, contradicting the requirement to enable remoting (even if restricted to local subnet).

C. Enable-PSRemoting -Force
On a public network, this command fails because PowerShell remoting is blocked for public network profiles by default. The -Force parameter does not override this restriction. The command would error, and remoting would remain disabled.

Reference:
Microsoft Learn: Enable-PSRemoting cmdlet documentation. The -SkipNetworkProfileCheck parameter allows remoting on public networks while maintaining local subnet firewall restrictions. No external links provided.

Explanation:
To inject drivers by make/model without PnP detection or selection profiles, you must modify the Preinstall phase (specifically the "Inject Drivers" task) and configure it to use a folder path based on task sequence variables. The Set Task Sequence Variable task is required to define the folder location containing the drivers before the injection occurs.

Correct Option:

Phase that you must modify in the deployment task sequence: Preinstall
The Preinstall phase contains the "Inject Drivers" task. This phase runs after partitioning but before OS installation. Modifying driver injection here ensures that matching drivers are available during Windows Setup's driver scan phase, avoiding reliance on PnP detection or selection profiles.

Task that you must use to specify which folder contains the drivers: Set Task Sequence Variable
You must set the variable DriverGroup001 to a value like Windows 11 x64\%Make%\%Model% before the "Inject Drivers" task. This tells MDT exactly which folder path to use for driver injection, bypassing PnP detection and selection profiles entirely.

Incorrect Option:

Phase: Install – The Install phase occurs after Windows is installed. Injecting drivers here would be too late for hardware detection during OS setup and would not match the requirement for pre-installation driver availability.

Phase: Validation – The Validation phase runs before the task sequence starts (checking network, disk space, etc.). It does not contain driver injection tasks and is not used for modifying deployment behavior during OS deployment.

Task: Gather – The Gather task collects variables but does not specify folder paths for drivers. It cannot define where the driver injection task should look for make/model-specific drivers.

Task: Inject Drivers – This task performs the actual driver injection but does NOT specify which folder contains the drivers. It relies on variables (e.g., DriverGroup001) set by a previous task. Using this alone without variable configuration will default to PnP detection or selection profiles.

Task: Validate – The Validate task checks requirements (e.g., BIOS mode, disk size) and has no role in specifying driver folder paths or controlling driver injection behavior.

Reference:
Microsoft Documentation: MDT – "Configure Driver Injection Without Selection Profiles Using DriverGroup001." Also covered in MD-102 study guide under "Deploying Windows using MDT." No external links provided.

Explanation:
Log Analytics workspaces using the Windows Event Log data source collect events based on log type (Application, System, Security) and event types (Error, Warning, Information, Audit Success, etc.). Since the workspace is configured to collect all available events from Windows event logs with no filtering, every event listed—regardless of computer or event ID—will be collected.

Correct Option:

E. 1, 2, 3, and 4
Event 1 (Application, Success) is collected because Application log is enabled and "Success" is included when no filters are applied. Event 2 (System, Information) is collected from the System log. Event 3 (Security, Audit Success) is collected from the Security log. Event 4 (System, Error) is also collected from the System log. The configuration collects all events across all logs from all connected computers.

Incorrect Option:

A. 1 only –
Incorrect because events 2, 3, and 4 are also collected. The workspace does not filter by computer name, event ID, or type when configured to collect "all available events."

B. 2 and 3 only –
Incorrect because it omits event 1 (Application log) and event 4 (System Error). Both logs are enabled for collection without restriction.

C. 1 and 3 only –
Incorrect because it excludes events from the System log (2 and 4). System logs are explicitly included in the "all available events" configuration.

D. 1, 2, and 4 only –
Incorrect because it excludes event 3 from the Security log. Security logs are collected by default when "all available events" is selected, including Audit Success events.

Reference:
Microsoft Learn: Log Analytics agent – Windows event log data sources. "Collect all events" includes Application, System, and Security logs with all event types (Error, Warning, Information, Audit Success, etc.) from all connected computers. No external links provided.

Explanation:
To target noncompliant devices specifically, you must use the Filter for devices condition with a rule using the device.isCompliant property. Setting device.isCompliant eq false ensures Policy1 only applies to devices that are noncompliant with Intune compliance policies. Other options do not filter based on compliance status.

Correct Option:

B. Filter for devices under Conditions
The Filter for devices setting allows you to create device-based rules using device properties. By adding a filter with the expression device.isCompliant eq false, the policy will only apply to devices that are marked as noncompliant in Intune. This is the precise method for targeting based on compliance status.

Incorrect Option:

A. Device platforms under Conditions –
This filters by operating system (Windows, iOS, Android, etc.), not by compliance status. It cannot distinguish between compliant and noncompliant devices on the same platform.

C. Target resources –
This defines which cloud applications or actions the policy applies to (e.g., Microsoft 365 Exchange Online). It does not filter based on device compliance status.

D. Grant –
The Grant control specifies what access requirements must be met (e.g., require MFA, require compliant device). It controls what happens after conditions are met, not which devices the policy applies to.

E. Session –
The Session control enables limited experiences within an app (e.g., app-enforced restrictions, sign-in frequency). It does not filter which devices are targeted by the policy.

Reference:
Microsoft Learn: Conditional Access – Device filter (Preview) for targeting devices using device.isCompliant property. Also covered in MD-102: Implement compliance policies and Conditional Access. No external links provided.

Explanation:
The requirement is to enforce that access to corporate data occurs only from MAM-capable apps. This is an access control decision based on app protection status, not device compliance. Conditional Access policies evaluate app protection status as a grant control, blocking access if the app does not support MAM or lacks an app protection policy.

Correct Option:

B. a Conditional Access policy
Conditional Access can use the grant control "Require app protection policy" which ensures that the client app (on Android) is MAM-capable and has received an app protection policy before granting access to corporate data. This directly meets the requirement without requiring device enrollment or compliance checks.

Incorrect Option:

A. an app configuration policy –
App configuration policies supply settings to managed apps (e.g., server URLs, account info). They do not enforce access conditions or block unmanaged apps from accessing corporate data.

C. a device configuration profile –
Device configuration profiles manage device settings (Wi-Fi, VPN, restrictions) but do not enforce that access must come from a MAM-capable app. This requires device enrollment, which may not exist for all Android devices.

D. a device compliance policy –
Device compliance policies check device health (OS version, encryption, etc.) and require device enrollment. They do not evaluate whether the app itself supports MAM or has an app protection policy applied.

Reference:
Microsoft Learn: Conditional Access – "Require app protection policy" grant. Also MD-102: Implement app protection policies and Conditional Access for MAM scenarios. No external links provided.

Explanation:
Preventing clipboard sharing is a device/resource redirection setting, found under Device and Resource Redirection. Enforcing Network Level Authentication (NLA) is a security setting, found under Security. Both nodes are located within Remote Desktop Session Host. No other nodes contain these specific policies.

Correct Option:

Node 1: Device and Resource Redirection
This node contains the policy "Do not allow clipboard redirection." Enabling this policy prevents users from sharing clipboard contents between the local computer and the remote desktop session, meeting the first requirement.

Node 2: Security
This node contains the policy "Require user authentication for remote connections by using Network Level Authentication." Enabling this policy ensures that users must authenticate via NLA before establishing a full Remote Desktop session, meeting the second requirement.

Incorrect Option (other nodes shown in the image):

Connections – Controls RDP connection limits and keep-alive settings, not clipboard redirection or NLA.

Licensing – Manages Remote Desktop licensing (per-user/per-device) and license server configuration, unrelated to clipboard or authentication.

Printer Redirection – Controls printer redirection in RDP sessions, not clipboard sharing or NLA.

Profiles – Manages Remote Desktop user profile paths and settings, not relevant to the requirements.

RD Connection Broker – Configures load balancing and redirection in a Remote Desktop farm, not applicable for standard Windows 11 computers.

Remote Session Environment – Controls visual experience (wallpaper, font smoothing) and session behavior, not clipboard or NLA.

Session Time Limits – Configures idle session timeouts and disconnection settings, unrelated to clipboard or NLA.

Temporary folders – Controls temporary folder usage per session, not relevant to the requirements.

Reference:
Microsoft Learn: Group Policy for Remote Desktop Services – "Do not allow clipboard redirection" under Device and Resource Redirection. "Require user authentication for remote connections by using NLA" under Security. MD-102: Configure Remote Desktop settings via Group Policy. No external links provided.

Explanation:
Device groups in Defender for Endpoint are evaluated in rank order (lowest number = highest priority). Computer1 has domain adatum.com and OS Windows 10. Without a tag, it matches Group3 (domain equals adatum.com) and Group4 (domain adatum.com + OS Windows 10). Group4 has a more specific rule but lower rank, so Group3 applies. Adding tag "demo" makes it match Group1 and Group2, but Group1 has higher rank.

Correct Option:

Computer1 will be a member of: Group3 only
Computer1 matches Group3 (domain adatum.com) and Group4 (domain adatum.com AND OS Windows 10). However, Group3 has rank 3 and Group4 has rank 4. Since rank order determines membership (lower rank wins), Computer1 becomes a member of Group3 only. Group5 requires name starting with "COVP" – not satisfied.

If you add the tag demo to Computer1, Computer1 will be a member of: Group1 and Group2 only
With tag "demo," Computer1 matches Group1 (tag=demo AND OS=Windows 10) and Group2 (tag=demo). Group1 has rank 1, Group2 has rank 2. Both are higher priority than Group3 (rank 3). The device becomes a member of both Group1 and Group2 because Group1's rule is satisfied (OS matches) and Group2 is also satisfied. Group3 and Group4 are overridden due to lower rank.

Incorrect Option (for first question):
Group4 only – Incorrect because Group3 has a higher rank (3 vs 4), so Group3 takes precedence despite Group4 having a more specific rule.

Group5 only – Incorrect because Computer1's name does not start with "COVP."

Group3, Group4, and Group5 only – Incorrect because only Group3 applies; Group4 is overridden by rank, and Group5 does not match.

Incorrect Option (for second question – with tag demo):

Group1 only – Incorrect because Group2 (tag=demo) is also satisfied and has rank 2, so the device belongs to both Group1 and Group2, not just Group1.

Group2 only – Incorrect because Group1 is also satisfied and has a higher rank (1), so both apply.

Group1, Group2, Group3, Group4, and Group5 – Incorrect because Group3 and Group4 are overridden by higher rank groups (1 and 2), and Group5 still does not match the name condition.

Reference:
Microsoft Learn: Microsoft Defender for Endpoint – Device groups and rank order evaluation. Rules are processed from lowest rank number to highest; first matching group determines membership, but devices can belong to multiple groups if higher-rank groups also match. No external links provided.

Explanation:
When deploying an application with multiple installation files via Intune, you must first package the files into a .intunewin format using the Microsoft Win32 Content Prep Tool. This tool compresses all installation files into a single package that Intune can process for Win32 app deployment. Uploading raw multiple files directly is not supported.

Correct Option:

A. Prepare the contents of App1 by using the Microsoft Win32 Content Prep Tool
Intune requires Win32 apps with multiple source files to be packaged into a .intunewin file. The Microsoft Win32 Content Prep Tool (IntuneWinAppUtil.exe) creates this package by compressing all installation files, specifying setup command line, and generating a catalog file. This packaged file can then be uploaded to Intune for deployment.

Incorrect Option:

B. Create an Android application package (APK) –
APK files are for Android apps only, not for Windows 11 devices. This is completely unrelated to deploying App1 to Windows devices via Intune.

C. Upload the contents of App1 to Intune –
Intune does not accept raw multiple installation files directly. You must first package them into a .intunewin file. Uploading without packaging will result in an error or unsupported format.

D. Install the Microsoft Deployment Toolkit (MDT)
MDT is used for operating system deployment and imaging, not for packaging or deploying Win32 applications through Intune. This is an unrelated tool for a different purpose.

Reference:
Microsoft Learn: Add, assign, and monitor a Win32 app in Microsoft Intune – "Prepare the Win32 app content" section. Microsoft Win32 Content Prep Tool is required for packaging apps with multiple installation files. No external links provided.