The hard set (7 questions)
The hardest MD-102 questions this guide publishes, none of them repeated from the placement quiz above: the answer first, why every other option is wrong, and the Microsoft Learn page behind it. The practice book for this exam holds the full bank.
A 32-bit line-of-business app is packaged as a Win32 app and set to install in system context. It installs to C:\Program Files (x86)\Contoso and writes keys to HKLM\SOFTWARE\WOW6432Node\Contoso, but Intune keeps reporting it as 'not installed' and re-attempts the install every IME cycle. The file and registry detection rules point to C:\Program Files\Contoso and HKLM\SOFTWARE\Contoso. What is the root cause and fix?
Correct answer: C. The detection rules evaluate in 64-bit context (the default), so they look in the 64-bit paths and never match the 32-bit install locations; set 'Associated with a 32-bit app on 64-bit clients' to Yes on the file and registry detection rules.
On a 64-bit client, file and registry detection rules default to 64-bit context, so %ProgramFiles% resolves to C:\Program Files and the registry rule reads the native hive, neither of which is where a 32-bit installer writes (C:\Program Files (x86) and WOW6432Node). The install succeeds, detection never matches, and Intune re-offers the required app about every 24 hours. Set 'Associated with a 32-bit app on 64-bit clients' to Yes on the file and registry detection rules so they evaluate the 32-bit locations. The install context (system versus user) is unrelated.
Why the other options are wrong:
- A. The roughly 24-hour re-offer is the mechanism causing the repeated attempts, not a self-heal. Detection never passes until the rule targets the 32-bit locations.
- B. File and registry detection rules can detect 32-bit apps; you just point them at the 32-bit context. An MSI product code is one option, not a requirement, and here the app writes to WOW6432Node, which the 32-bit toggle handles.
- D. System context is fully supported for 32-bit installers and is correct for a machine-wide install. Switching to user context would not fix a detection rule that is looking in the wrong (64-bit) paths.
Memory hook: 32-bit app, 64-bit detection default = looks in the wrong Program Files/hive forever. Flip 'Associated with a 32-bit app on 64-bit clients' to Yes.
Microsoft Learn: Add win32
An administrator uses the Microsoft 365 Apps admin center to manage Microsoft 365 Apps. They want to ensure that a specific update channel is enforced and that users cannot change the channel themselves. What is the correct approach using the tools available in the Microsoft 365 Apps admin center?
Correct answer: D. Use Cloud update (servicing profiles) in the Microsoft 365 Apps admin center: assign the target Microsoft Entra groups to the Current or Monthly Enterprise profile to set and enforce the update channel.
The Microsoft 365 Apps admin center includes Cloud update (previously surfaced as servicing profiles), which lets administrators enforce an update channel and control update timing for Microsoft 365 Apps. It is assigned by Microsoft Entra group and takes priority over other update-management tools on the device, so local or user channel settings cannot override it. This is the purpose-built channel-enforcement path inside the Microsoft 365 Apps admin center.
Why the other options are wrong:
- A. App configuration policies with key-value pairs target managed apps through the Intune MAM SDK. They are used for configuring app behavior settings, not for controlling the Microsoft 365 Apps update channel. Channel management is handled through servicing profiles or device policies.
- B. Configuring channel settings through the Intune Settings catalog or CSP is a valid alternative approach, but the question specifically asks about the Microsoft 365 Apps admin center as the management tool. Within that tool, servicing profiles are the correct mechanism.
- C. Using the ODT with a configuration.xml to set the channel is a deployment-time operation. Redeploying configuration.xml to existing devices is operationally complex and does not integrate with the ongoing management capabilities of the Microsoft 365 Apps admin center.
Memory hook: Channel enforcement in the Microsoft 365 Apps admin center = Cloud update (servicing profiles). Assign the Entra group and the channel sticks.
Microsoft Learn: Servicing profile
A company uses Apple User Enrollment (BYOD with a Managed Apple Account) for personal iPhones and wants VPP apps to appear in Company Portal for those users. The administrator assigned the VPP apps using the default license type. Users on User Enrollment devices report the assigned apps never appear in Company Portal, while the same apps install fine on the company's supervised, MDM-enrolled iPads. What is the cause?
Correct answer: B. The VPP assignments use device licensing (the default), and device-licensed apps are not supported on User Enrollment devices; Company Portal shows only user-licensed apps on User Enrollment, so reassign the app with user licensing.
New VPP assignments default to device licensing. Device licensing is not supported on Apple User Enrollment devices, and Company Portal does not show device-licensed apps on User Enrollment devices; only user-licensed apps can be installed there. The supervised iPads accept device-licensed apps, which is why they work. To reach the User Enrollment users, reassign the app with user licensing so each user consumes a license under their Managed Apple Account. Do not assign both device and user licenses to the same user or device.
Why the other options are wrong:
- A. The intent (Required versus Available) is not the issue; device-licensed apps simply do not surface on User Enrollment devices regardless of intent. The license type is the problem.
- C. User Enrollment does support VPP apps, but with user licensing. Falling back to iOS store apps would reintroduce the Apple ID prompt and is unnecessary.
- D. The Business versus Education account type of the token does not govern User Enrollment support; the licensing model (device versus user) does.
Memory hook: User Enrollment shows user-licensed VPP apps only. Device-licensed apps are invisible there. Default is device, so switch to user for UE.
Microsoft Learn: Manage vpp apple
A company uses Microsoft Tunnel for Mobile Application Management (MAM) to give unenrolled iOS devices secure access to on-premises resources. A developer's line-of-business iOS app needs to use the Tunnel VPN connection. What integration is required in the iOS app itself to support Tunnel for MAM?
Correct answer: A. The app must integrate the Intune App SDK for iOS and the Tunnel for MAM SDK for iOS, plus use MSAL
For an iOS line-of-business app to use Microsoft Tunnel for MAM, it must integrate the Intune App SDK for iOS, the Tunnel for MAM SDK for iOS, and use the Microsoft Authentication Library (MSAL) for authentication. Additionally, a Microsoft Entra app registration is required. These SDK integrations allow the app to establish the per-app VPN connection through the Tunnel gateway on unenrolled devices.
Why the other options are wrong:
- B. The Intune App Wrapping Tool adds MAM capabilities to apps that cannot be recompiled with the SDK. However, Tunnel for MAM for iOS specifically requires the Tunnel for MAM SDK integration - the App Wrapping Tool does not add VPN tunnel capability.
- C. Apple Automated Device Enrollment (ADE) is a device enrollment method for corporate-owned iOS/iPadOS devices. Tunnel for MAM is designed for unenrolled (BYOD) scenarios and does not require ADE.
- D. Publishing to the Apple App Store and having a Microsoft-verified certificate are not requirements for Tunnel for MAM. The app can be distributed through Intune as a line-of-business app without App Store publication.
Memory hook: Tunnel for MAM iOS = Intune App SDK + Tunnel for MAM SDK + MSAL. Three integrations, no enrollment needed.
Microsoft Learn: Microsoft tunnel MAM
An administrator deploys an iOS app protection policy (APP) and sets 'Send org data to other apps' to 'Policy managed apps.' A user on an enrolled iPhone attempts to open a Word document attachment in the Intune-managed Outlook app and then share it to an unmanaged third-party app. What is the expected behavior?
Correct answer: D. The data is transferred to the unmanaged app but Intune encrypts it, making it unreadable in the unmanaged app.
When 'Send org data to other apps' is set to 'Policy managed apps' on an enrolled iOS device, users may still be able to transfer content via Open-in or Share extensions to unmanaged apps through iOS native mechanisms. However, Intune encrypts the transferred data so that unmanaged apps cannot read it. The document content is protected even if the transfer mechanism allows the file to land in an unmanaged app.
Why the other options are wrong:
- A. The setting 'Policy managed apps' does not block the share sheet UI entirely on enrolled devices. iOS Open-in/Share mechanisms can still expose sharing options. To filter the share sheet to display only policy-managed apps, the 'Policy managed apps with Open-In/Share filtering' option is required, and both source and destination apps must use Intune SDK v8.1.1 or later.
- B. While the device is enrolled, the APP setting 'Policy managed apps' restricts data transfer. The data is not freely accessible in unmanaged apps; Intune encrypts it so the receiving app cannot read the content.
- C. iOS does support Intune SDK-level sharing controls. The Intune SDK for iOS implements Open-in/Share filtering and data encryption capabilities on top of iOS native controls.
Memory hook: Policy managed apps = data can move but arrives encrypted. Unmanaged apps get an unreadable file. 'Encrypted but transferred.'
Microsoft Learn: Ref settings iOS
A Win32 app uses a custom PowerShell detection script. The script exits with code 0 and writes the string Detected to STDOUT, but it also writes a warning line to STDERR. In AppWorkload.log the app is reported as not installed and Intune keeps retrying the install. What is causing detection to evaluate as not installed?
Correct answer: C. Any data written to STDERR causes detection to evaluate as not installed, even when the exit code is 0 and STDOUT has data.
For a custom detection script, the app is detected only when the script exits with code 0 AND writes to STDOUT AND writes nothing to STDERR. If any data is written to STDERR, the result is evaluated as not installed regardless of the STDOUT output and the zero exit code.
Why the other options are wrong:
- A. Detection requires exit code 0 (plus STDOUT data), not exit code 1.
- B. Intune does not match a specific STDOUT string; any STDOUT data (with exit 0 and no STDERR) counts as detected.
- D. Signature checking is optional (the Enforce script signature check setting); unsigned scripts still run and can detect.
Memory hook: Detection = exit 0 + STDOUT + silence on STDERR. One STDERR line = not installed.
Microsoft Learn: Add win32
A security team wants to use Microsoft Tunnel for Mobile Application Management (MAM) to provide BYOD Android devices with access to on-premises resources without enrolling those devices in Intune. Which license is required in addition to a standard Microsoft Intune Plan 1 subscription?
Correct answer: A. Microsoft Intune Plan 2 or Microsoft Intune Suite
Microsoft Tunnel for Mobile Application Management (MAM) is an Intune Suite add-on capability. It requires Microsoft Intune Plan 2 or Microsoft Intune Suite as an add-on license beyond the base Intune Plan 1. Standard Intune Plan 1 alone is insufficient. The base Microsoft Tunnel (for enrolled MDM devices) is included in Intune Plan 1, but extending Tunnel to unenrolled MAM devices requires the additional Plan 2 or Suite license.
Why the other options are wrong:
- B. Microsoft Defender for Endpoint Plan 2 is not required to license Microsoft Tunnel MAM. On Android, the Defender for Endpoint app is used as the VPN client app for Tunnel MAM, but having Defender for Endpoint Plan 2 as a separate license is not the requirement for Tunnel MAM itself.
- C. Microsoft 365 E3 includes Intune Plan 1 but not Intune Plan 2 or the Intune Suite. Microsoft 365 E3 alone does not provide the Tunnel MAM capability.
- D. Microsoft Entra ID P2 adds features such as Identity Protection and Privileged Identity Management but is not a licensing requirement for Microsoft Tunnel MAM. Tunnel MAM is an Intune-specific add-on, not an Entra feature.
Memory hook: Tunnel MAM = Intune add-on = needs Plan 2 or Suite. Plan 1 gets you basic MDM Tunnel only.
Microsoft Learn: MAM
