The hard set (6 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.
Contoso currently manages mobile devices with Basic Mobility and Security for Microsoft 365, so the tenant's MDM authority shows "Office 365." Contoso buys Intune licenses and wants to move only the sales team to Intune while every other user stays on Basic Mobility and Security. What is the correct approach?
Correct answer: B. In the Intune admin center, add the Intune MDM authority to enable coexistence, then assign Intune licenses (and pre-staged Intune policies) to the sales team so their devices switch to Intune management
Basic Mobility and Security coexistence is enabled by adding the Intune MDM authority. Once coexistence is on, each user's management authority is decided by their license: assigning an Intune license (with Intune policies staged first to avoid losing settings) moves that user's devices to Intune on next check-in, while unlicensed users remain on Basic Mobility and Security.
Why the other options are wrong:
- A. Coexistence explicitly lets Intune and Basic Mobility and Security run side by side; you do not have to turn off Basic Mobility and Security.
- C. The MDM authority can never be set back to "Unknown," and coexistence is a per-user model, not a tenant-wide flip.
- D. You must add the Intune MDM authority first to activate coexistence; assigning licenses alone with the authority left at "Office 365" does not enable the switch.
Memory hook: Coexistence = add Intune authority, then the license picks the winner per user.
Microsoft Learn: Setup MDM authority
An Intune compliance policy is created for Windows devices with the default 'Mark device noncompliant' action unchanged. A Conditional Access policy is also configured to block access to Exchange Online for noncompliant devices. A user's device falls out of compliance. When does Conditional Access block the user's Exchange Online access?
Correct answer: C. Immediately, because the default 'Mark device noncompliant' action is set to 0 days.
When a compliance policy is created, the 'Mark device noncompliant' action is automatically included with a default schedule of 0 days, meaning the device is marked noncompliant immediately when noncompliance is detected. Conditional Access evaluates compliance status, so access is blocked immediately upon the device being marked noncompliant. A grace period only applies if an administrator manually changes the schedule from 0 to a positive number of days.
Why the other options are wrong:
- A. Seven days is not the default for compliance policies. The default schedule for 'Mark device noncompliant' is 0 days (immediate). Seven days appears in other contexts such as the delay before EPM components are removed when EPM is disabled.
- B. The retire action is a separate, optional noncompliance action that can be added to a policy. Conditional Access does not depend on the retire action; it acts on the compliance status, which is set immediately by the default action.
- D. There is no automatic 24-hour grace period built into compliance policies. The default is 0 days (immediate). Any grace period must be explicitly configured by an administrator.
Memory hook: Default = 0 days = immediate noncompliant mark = Conditional Access blocks right away. Change the schedule to add a grace period.
Microsoft Learn: Configure noncompliance actions
On co-managed Windows devices, an admin creates and assigns a Settings Catalog device configuration profile in Intune, but the settings never apply. In the co-management properties, the Device configuration workload slider is set to Configuration Manager, while the Compliance policies and Windows Update policies sliders are set to Intune. What is the most likely reason the Settings Catalog profile isn't applied?
Correct answer: C. Settings Catalog policies are governed by the Device configuration workload slider, which is still set to Configuration Manager.
A Settings Catalog policy is controlled by the Device configuration workload slider regardless of what settings it contains - the trap is expecting the policy's content to decide which workload governs it. That slider still points to Configuration Manager, so Intune is not the device-configuration authority for these devices and the profile is ignored. Moving the Device configuration workload to Intune (or Pilot Intune for that collection) resolves it.
Why the other options are wrong:
- A. Settings Catalog fully supports co-managed devices once the Device configuration workload is on Intune.
- B. The Client apps workload governs app deployment, not whether device configuration profiles apply.
- D. The Compliance policies workload governs compliance policies; it has no bearing on device configuration profiles.
Memory hook: Settings Catalog rides the Device Configuration slider - no matter what's inside it.
Microsoft Learn: Workloads
In a tenant on the current Intune release, an admin opens Devices, then Configuration, and tries to create a new Administrative Templates profile under Templates for Windows, but the profile type is deprecated and read-only. Where should they now configure these ADMX-backed Windows settings?
Correct answer: B. In the Settings catalog, which now includes the Administrative Templates (ADMX) settings built in
Starting with the December 2024 (2412) service release, the standalone Administrative Templates profile type under Templates is deprecated and read-only. The ADMX-backed settings are now available inside the settings catalog, built in with no download or OMA-URI required.
Why the other options are wrong:
- A. OMA-URI custom profiles are unnecessary because these ADMX settings are now built into the settings catalog.
- C. A GPO manages on-premises/domain-joined devices, not the cloud MDM ADMX settings applied to Intune-managed devices.
- D. Attack surface reduction is a specific Microsoft Defender feature area, not the home for general ADMX Administrative Template settings.
Memory hook: Administrative Templates moved into the settings catalog; the old node is read-only.
Microsoft Learn: Configure admx templates Windows
A Windows configuration profile (PolicyA) is assigned to three device groups: GroupA's assignment uses a filter in Include mode, GroupB's assignment uses a different filter in Exclude mode, and GroupC's assignment uses no filter. A device belongs to all three groups and matches the rules of the Exclude filter. Does PolicyA apply to that device?
Correct answer: D. No - Exclude mode has the highest precedence (over No filter and over Include), so the matched device is excluded
For assignment filters, Exclude mode takes precedence over No filter, which takes precedence over Include. Because the device matches an Exclude-mode filter, it is dropped from the assignment and no further filter evaluation is performed, so PolicyA does not apply.
Why the other options are wrong:
- A. No filter wins over Include, but Exclude wins over No filter, so the exclude assignment prevails over GroupC.
- B. Include has the lowest precedence; it loses to both Exclude and No filter.
- C. A matched Exclude filter definitively excludes the device; the outcome is not an ambiguous default-apply.
Memory hook: Filter precedence: Exclude beats No filter, and No filter beats Include.
Microsoft Learn: Troubleshoot
An administrator sets up Android Enterprise corporate-owned work profile (COPE) enrollment and creates an enrollment profile that produces an enrollment token and QR code. The admin schedules an annual reminder to renew the token, assuming it expires yearly like the Apple ADE and VPP tokens. Which statement is correct?
Correct answer: D. Corporate-owned work profile enrollment tokens do not expire automatically; they only stop working if an admin revokes them
Android Enterprise corporate-owned work profile enrollment tokens do not expire automatically; the annual-renewal reflex the admin is applying belongs to Apple, whose ADE and VPP tokens each expire after one year. If an admin revokes a COPE token, its profile is hidden from the active list, though you can still view it by filtering for Inactive policy states. Separate gotcha: the afw#setup and NFC enrollment methods for COPE are only supported on Android 8-10, not Android 11 and later.
Why the other options are wrong:
- A. The COPE token isn't tied to the managed Google Play connection's lifetime; it simply doesn't auto-expire.
- B. The 365-day annual expiry applies to the Apple ADE enrollment program token and VPP tokens, not to the Android COPE enrollment token.
- C. There is no automatic 90-day expiry on COPE enrollment tokens; that value doesn't apply here.
Memory hook: COPE enrollment token = no auto-expiry (dies only on revoke). Apple ADE/VPP tokens = yearly renewal.
Microsoft Learn: Setup corporate work profile
