Free practice questions

MD-102 practice questions, with full explanations

75 free MD-102 (Endpoint Administrator) questions, each with the correct answer, a breakdown of why every other option is wrong, a memory hook, and the Microsoft Learn reference. Prefer to be quizzed? Take the interactive MD-102 quiz, which scores you by topic and points you to the guide that fits your weak spots.

Windows Autopilot and Deployment (19 questions)

Go deeper on this topic in Windows Autopilot and Deployment Field Guide.

A device and its signed-in user are each in scope for a different custom Enrollment Status Page (ESP) profile, and a tenant default ESP profile also exists. The deployment is a standard user-driven Autopilot deployment. Which ESP profile applies, and how would that differ in a self-deploying deployment?

Correct answer: A. The highest-priority device-targeted profile applies first; in self-deploying and pre-provisioning flows only device-targeted profiles are evaluated because there is no user.

Intune resolves ESP profiles in order: the highest-priority profile targeted at the device, then (only when there is a user) the highest-priority profile targeted at the user, then the default profile. So in user-driven mode a device-targeted profile takes precedence over a user-targeted one. In self-deploying and pre-provisioning (technician) flows there is no user context, so only device-targeted ESP profiles are evaluated and user-targeted profiles are ignored.

Why the other options are wrong:

  • B. ESP profile selection is by priority (set by dragging profiles in the list) and target type, not by creation date. Self-deploying mode differs precisely because it ignores user-targeted profiles.
  • C. The device-targeted profile, not the user-targeted one, takes precedence in user-driven mode. And in self-deploying mode a device-targeted custom profile still applies if one is assigned; it is not automatically the default.
  • D. The default profile applies only when no other profile is targeted at the device or user. When custom profiles are in scope, they win over the default.

Memory hook: ESP order: device profile first, then user profile, then default. No user (self-deploying/pre-prov) means device profiles only.

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page#prioritize-profiles

After configuring a Windows Autopilot user-driven deployment, an administrator finds that target devices join Microsoft Entra ID during OOBE but never enroll in Intune, receive no deployment profile, and never show the Enrollment Status Page. In the automatic enrollment configuration, MDM user scope is set to None. What is the effect of this setting, and what should it be?

Correct answer: D. With MDM user scope set to None, automatic MDM enrollment never fires, so the device joins Entra ID but is never enrolled in or managed by Intune; set it to Some or All.

The MDM user scope controls automatic MDM enrollment. When it is set to None, automatic enrollment does not occur, so an Autopilot user-driven device joins Microsoft Entra ID (using the user's credentials) and then stops: no Intune enrollment, no profile, no ESP. Setting MDM user scope to Some (scoped to a pilot group) or All lets automatic enrollment proceed. Automatic enrollment requires Microsoft Entra ID P1 or P2.

Why the other options are wrong:

  • A. MDM user scope governs all automatic enrollment, not just BYOD. Autopilot devices do not bypass it; if it is None, even corporate devices will not auto-enroll.
  • B. A missing deployment profile produces a generic OOBE, but the described symptom (Entra join succeeds, then no Intune management at all) is the signature of MDM user scope = None, which disables automatic enrollment entirely.
  • C. MAM (WIP) user scope governs app-level management for personal devices; it does not enroll a device into Intune MDM. For a user in both scopes on a personal device the MAM scope can even take precedence and block MDM enrollment.

Memory hook: MDM user scope None = joins Entra, then stops. Set it to Some or All for Autopilot to enroll.

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/guide

A lab device was provisioned once with Windows Autopilot self-deploying mode. An engineer wipes it and tries to run it through Autopilot again, but provisioning now fails with error 0x80180014. The Autopilot profile and enrollment settings are unchanged. What must the engineer do so the device can be redeployed?

Correct answer: C. Delete the device record in Intune (Devices, then All devices, then select it, then Delete) before redeploying, because a self-deploying or pre-provisioned device can't automatically re-enroll through Autopilot.

A device provisioned with self-deploying mode (or pre-provisioning mode) can't automatically re-enroll through Windows Autopilot. When such a device is reused, reset, or redeployed, it fails with error 0x80180014. The fix is to delete the device record in the Intune admin center (Devices, then All devices, then select the device, then Delete), or use Unblock device on the Autopilot device record, before rerunning the deployment. A separate cause of 0x80180014 is Windows MDM enrollment being blocked by an enrollment restriction.

Why the other options are wrong:

  • A. The 10-minute throttle applies to Autopilot device syncs after import, not to this per-device re-enrollment block. Waiting does not clear 0x80180014.
  • B. The hardware hash and registration are intact and aren't the problem. Re-importing the hash does not clear the one-time enrollment block that self-deploying leaves behind.
  • D. Changing the mode doesn't remove the existing Intune device record that is blocking re-enrollment, and it changes the deployment behavior unnecessarily.

Memory hook: Reused self-deploying/pre-provisioned device fails 0x80180014. Delete its Intune device record first.

Microsoft Learn: https://learn.microsoft.com/autopilot/self-deploying#requirements

A new corporate Windows 11 laptop shipped with many preinstalled OEM manufacturer apps ('bloatware'). An administrator wants an Intune remote action that removes installed apps to clean up the device, while offering the option to keep the signed-in user's files. Which action is designed for this?

Correct answer: C. Fresh Start (optionally with 'Retain user data on this device')

The Fresh Start action removes apps from a managed Windows device, which is specifically useful for removing preinstalled OEM apps that ship on a new PC. Choosing 'Retain user data on this device' keeps the device Microsoft Entra joined, automatically re-enrolls it in MDM at next sign-in, and preserves the user's Home folder while still removing apps and settings. If user data isn't retained, the device returns to a clean OOBE-completed state.

Why the other options are wrong:

  • A. Retire removes company data and unenrolls the device. It doesn't remove preinstalled OEM apps or reinstall a clean Windows state.
  • B. A full Wipe factory-resets everything and removes all apps and (by default) data. It's heavier than needed and doesn't target removing installed apps while optionally keeping user files.
  • D. Autopilot Reset returns the device to its original IT-approved configuration for reassignment. It isn't the purpose-built strip-OEM-apps action and doesn't offer the Fresh Start retain-user-data behavior.

Memory hook: Strip OEM bloatware, optionally keep the user's files = Fresh Start (CleanPC).

Microsoft Learn: https://learn.microsoft.com/intune/device-management/actions/fresh-start

Your organization wants to move a fleet of Microsoft Entra hybrid joined Windows laptops to Microsoft Entra join (cloud-native). A colleague suggests running Autopilot Reset on each device to flip the join type in place. What is the accurate guidance?

Correct answer: A. There is no supported path to convert an existing hybrid joined device to Entra join without a full device wipe, and Autopilot Reset does not support hybrid joined devices

Microsoft states there is no supported process to convert an existing device from hybrid join to Entra join without a Windows reset (full wipe). Additionally, Autopilot Reset does not support hybrid joined devices, so it cannot perform the conversion. The supported approach is a full wipe and re-provision as Entra join.

Why the other options are wrong:

  • B. dsregcmd /leave removes the join state but does not cleanly convert the device to Entra join; a reset and re-provision is required.
  • C. Autopilot Reset does not support hybrid joined devices and cannot flip the join type in place.
  • D. Reassigning an Autopilot profile does not re-join an already-provisioned device; join type is set at provisioning time.

Memory hook: Hybrid to Entra join means wipe and reprovision; Autopilot Reset won't touch hybrid.

Microsoft Learn: https://learn.microsoft.com/intune/solutions/cloud-native-endpoints/entra-join-types

An administrator has assigned two different Windows Autopilot device preparation policies to the same user group. During a user-driven deployment, the administrator needs to predict which policy the device will use. How does Windows Autopilot device preparation resolve which policy applies when a user is targeted by more than one?

Correct answer: A. The policy with the highest priority (highest in the Device preparation policies list, with the smallest number in the Priority column) applies; priority is changed by dragging policies in the list.

When multiple Windows Autopilot device preparation policies are deployed to a user, the policy with the highest priority applies. In the Device preparation policies list the highest-priority policy sits at the top and shows the smallest number in the Priority column, and you reorder policies (changing priority) by dragging them within the list. This is deliberately different from classic Windows Autopilot deployment profiles, where a device that lands in multiple assigned groups receives the oldest-created profile.

Why the other options are wrong:

  • B. Device preparation does not merge policies. A single policy is selected by priority, and only that policy's selected apps and scripts deploy.
  • C. Oldest-created-wins is the conflict rule for classic Windows Autopilot deployment profiles, not device preparation. Device preparation uses an explicit, drag-to-reorder priority list.
  • D. Modification date is not the tiebreaker. Selection follows the priority ordering shown in the Device preparation policies list.

Memory hook: Device preparation = priority list (top wins, drag to reorder). Classic Autopilot = oldest-created profile wins.

Microsoft Learn: https://learn.microsoft.com/autopilot/device-preparation/tutorial/user-driven/entra-join-autopilot-policy#policy-priority

In your Windows Autopilot deployment profile you set "Allow pre-provisioned deployment" to No because you do not want technicians using the pre-provisioning (white glove) flow. During OOBE on a target device, a technician presses the Windows key five times and attempts the pre-provisioning path anyway. What happens?

Correct answer: A. Intune enforces the profile setting and pre-provisioning fails with error 0x80180005

Pressing the Windows key five times at OOBE can invoke the pre-provisioning path, but Intune enforces the "Allow pre-provisioned deployment" setting. When it is set to No, the pre-provisioning attempt fails with error 0x80180005 instead of continuing.

Why the other options are wrong:

  • B. It does not silently fall back to user-driven mode; the pre-provisioning attempt errors out.
  • C. The key shortcut can invoke the path, but the profile setting is enforced and blocks it.
  • D. The five-key shortcut is not gated by ESP assignment; the block comes from the profile setting being No.

Memory hook: Pre-provision set to No means the white-glove attempt dies at 0x80180005.

Microsoft Learn: https://learn.microsoft.com/autopilot/profiles

An administrator configures an ESP profile with 'Install Windows quality updates' set to Yes. The target Windows 11 devices are enrolled but are NOT registered for Windows Autopilot. To which assignment must BOTH the Update Rings policy and the ESP profile be set so quality updates install during OOBE, and which Autopilot scenario cannot install them at all because it does not use the ESP?

Correct answer: D. All Devices; Windows Autopilot device preparation does not support it

For the 'Install Windows quality updates' ESP setting to work on non-Autopilot-registered devices, both the Update Rings policy and the ESP profile must be assigned to 'All Devices'. Additionally, Windows Autopilot device preparation does not use ESP at all, so this setting is not applicable and monthly security updates cannot be installed during OOBE for that scenario.

Why the other options are wrong:

  • A. User-targeted assignments are not supported for the quality update installation feature. The ESP setting documentation specifically requires device-targeted (All Devices) assignment, not user-targeted assignment.
  • B. Self-deploying mode is device-targeted and does support installing quality updates during OOBE, so this option's unsupported-scenario claim is false. Also, for non-Autopilot devices the assignment must be All Devices, not specific groups.
  • C. Windows Autopilot user-driven mode does support the 'Install Windows quality updates' setting when the assignment and configuration requirements are met. The unsupported scenario is Windows Autopilot device preparation, not user-driven mode.

Memory hook: Quality updates during OOBE = All Devices assignment. Device preparation = no ESP = no quality updates.

Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status

During a Windows Autopilot pre-provisioned deployment, a technician completes the technician flow and sees a success screen. The device is resealed and shipped to the end user. The end user powers on the device but reports that several device-targeted apps that were assigned to the device, and should have installed during the technician flow, are missing when they reach the desktop. What configuration change would most directly prevent this outcome?

Correct answer: A. Ensure that the Enrollment Status Page (ESP) is enabled and configured to block device use until all apps are installed.

The technician flow inherits behavior from self-deploying mode and uses the ESP to hold the device in provisioning state. If the ESP is disabled or not configured to block on app installation, the Reseal button can appear before apps finish installing. Microsoft explicitly recommends keeping the ESP enabled for pre-provisioned deployments because the success screen only confirms enrollment success, not completion of app/config installation.

Why the other options are wrong:

  • B. Changing to self-deploying mode would prevent user-account-based deployment entirely and is a different scenario. The pre-provisioned user-driven mode is appropriate here.
  • C. Adding the user to the app-assignment group only affects user-targeted apps delivered during the user flow; it does not explain device-targeted apps missing after the technician flow, where the root cause is the ESP not holding the device until app installation completes.
  • D. 'Allow pre-provisioned deployment' must already be enabled in the Autopilot profile for this scenario to work at all. Enabling it does not address apps missing after the technician flow completes.

Memory hook: ESP is the gate that holds the technician flow until apps land. Drop the gate and the device reseals half-provisioned.

Microsoft Learn: https://learn.microsoft.com/autopilot/tutorial/pre-provisioning/azure-ad-join-technician-flow#technician-flow-tips

An administrator creates an Enrollment Status Page (ESP) profile in Intune with 'Block device use until all apps and profiles are installed' set to Yes and 'Block device use until these required apps are installed' set to Selected with App1, App2, and App3 listed. The device also has App4 assigned but App4 is not in the blocking list. What happens if App4 fails to install during the device setup phase of the ESP?

Correct answer: A. The ESP ignores the App4 failure and the deployment can continue, with App4 installation retried in other flows

The ESP blocking app list filters which apps are tracked as blocking. If App4 is assigned to the device but not included in the 'Selected' blocking apps list, the ESP does not wait for App4 to complete. The deployment can succeed even if App4 fails. Importantly, for some app types (Win32, Microsoft Store, Enterprise app catalog apps), non-blocking apps are not installed during ESP at all and will install after the ESP completes.

Why the other options are wrong:

  • B. Only the apps in the 'Selected' blocking list are required for ESP completion. App4, being outside that list, is not a blocking requirement even though it is assigned to the device.
  • C. Intune does not remove app assignments based on ESP behavior. Assignment targets remain unchanged; the ESP simply does not track non-blocking apps during provisioning.
  • D. The ESP only tracks apps in its blocking list. It does not wait for, or time out on, apps that are assigned to a device but not listed as blocking apps.

Memory hook: ESP blocks on only the list you name. Apps outside that list are invisible to the ESP gate.

Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status

An administrator creates an Enrollment Status Page (ESP) profile and sets 'Block device use until these required apps are installed' to 'Selected,' then adds App1, App2, and App3 to the blocking list. App3 and App4 are both assigned to the device as required apps. What happens during enrollment?

Correct answer: D. The ESP blocks only until App3 installs, because it is the only app in both the blocking list and the device assignment.

When 'Selected' apps are configured as blocking, the ESP uses the blocking app list as a filter against what is actually assigned to the device or user. In this scenario, App1 and App2 are in the blocking list but not assigned to the device, so they are not tracked. App3 is in both the blocking list and assigned as a required app, so the ESP waits for App3. App4 is assigned but not in the blocking list, so in non-pre-provisioning flows with Win32, Store, or Enterprise catalog apps, App4 may not install until after ESP completes.

Why the other options are wrong:

  • A. The ESP does not block on App1 or App2 because they are in the blocking list but are not assigned to the device. The blocking list acts as a filter on the assigned apps, not as a standalone install mandate.
  • B. App4 does get installed, just not necessarily during the ESP blocking phase. In user-driven and self-deploying modes, Win32, Store, and Enterprise catalog apps not in the blocking list install after the ESP completes.
  • C. The 'Selected' blocking list filters which assigned apps the ESP waits for. It does not cause the ESP to wait for apps that are in the blocking list but not assigned (App1, App2), nor does it automatically add all assigned apps (App4) to the blocking requirement.

Memory hook: Blocking list = filter, not a grocery list. ESP only waits for apps that are BOTH in the blocking list AND assigned to the device.

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page#prioritize-profiles

A company is deploying shared kiosk devices using Windows Autopilot. The devices should provision automatically with no user interaction at all (including no language or keyboard selection prompts) when connected via Ethernet. Which Windows Autopilot deployment mode should the administrator choose?

Correct answer: C. Self-deploying mode

Windows Autopilot self-deploying mode requires little to no user interaction. When a device is connected via Ethernet, the entire provisioning process is fully automated with no prompts for language, locale, keyboard, or credentials. This mode is designed for kiosk, digital signage, and shared devices. It requires TPM 2.0 and is only supported with Microsoft Entra join (not hybrid join).

Why the other options are wrong:

  • A. User-driven mode with Entra join still requires the user to enter Microsoft Entra credentials during OOBE. It is not fully automated for shared or kiosk devices with no user.
  • B. User-driven hybrid join requires user credential input and also requires the Intune Connector for Active Directory. It is not designed for zero-touch kiosk provisioning.
  • D. Pre-provisioning (white glove) mode is designed to split provisioning between a technician phase and a user phase, reducing end-user setup time. It is not a fully automated mode for kiosk devices.

Memory hook: Kiosk, no user = self-deploying. TPM 2.0 required. Entra join only.

Microsoft Learn: https://learn.microsoft.com/en-us/autopilot/self-deploying

During a Windows Autopilot self-deploying deployment, a device fails with error 0x800705B4. What is the most likely cause?

Correct answer: B. The device does not have TPM 2.0 support or TPM device attestation failed

Windows Autopilot self-deploying mode uses TPM 2.0 hardware to authenticate the device into the Microsoft Entra tenant without user credentials. If a device does not support TPM 2.0 (including Hyper-V virtual machines with virtual TPMs), the attestation process fails with the 0x800705B4 timeout error. This is a hard requirement for self-deploying mode.

Why the other options are wrong:

  • A. Joining an incorrect tenant would produce authentication or enrollment errors after the attestation phase succeeds, not the 0x800705B4 timeout that occurs during TPM attestation.
  • C. If the Autopilot profile was not assigned, the device would proceed through a standard Windows OOBE rather than failing with 0x800705B4. The profile must be assigned before deployment, but its absence produces a different experience, not this specific error.
  • D. An ESP timeout produces a different error experience and error codes. The 0x800705B4 error specifically occurs during the device attestation phase before ESP is even reached.

Memory hook: 0x800705B4 = TPM timeout. Self-deploying requires real TPM 2.0 - virtual TPMs fail here.

Microsoft Learn: https://learn.microsoft.com/en-us/autopilot/self-deploying

In an Enrollment Status Page profile, an administrator wants that if a tracked app fails during provisioning, the end user is given a button to bypass the ESP and start using the device rather than being forced to reset it. The administrator also wants to raise how long the ESP waits before showing a timeout error. Which two ESP settings should be configured?

Correct answer: D. Set 'Allow users to use device if installation error occurs' to Yes, and increase 'Show an error when installation takes longer than specified number of minutes' above its 60-minute default.

'Allow users to use device if installation error occurs' = Yes gives users the option to bypass the ESP and use the device when an installation fails, as opposed to 'Allow users to reset device if installation error occurs,' which offers a reset instead. The ESP timeout is controlled by 'Show an error when installation takes longer than specified number of minutes,' which defaults to 60 minutes; enter a higher value to allow more time before the timeout error appears. Both are configured on the ESP profile's Settings page.

Why the other options are wrong:

  • A. Setting progress display to No hides the ESP entirely, and a custom message only changes the error text. Neither provides a bypass button or extends the timeout window.
  • B. 'Only show page to devices provisioned by OOBE' and log collection control where the ESP appears and diagnostics, not whether users can bypass on failure or how long the timeout is.
  • C. 'Allow users to reset device if installation error occurs' offers a reset, which is exactly what the admin wants to avoid, and the blocking-app scope does not control the bypass or timeout behavior described.

Memory hook: Bypass-on-failure = 'Allow users to use device if installation error occurs' (Yes). Timeout = 'Show an error when installation takes longer than...' (default 60 min).

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page#create-new-profile

An organization has enabled co-management. Before moving compliance management for the whole fleet to Intune, the team wants to shift the Compliance policies workload to Intune for only a small set of test machines defined by a Configuration Manager collection. On the co-management Workloads tab, which slider setting does this, and what must be defined?

Correct answer: D. Set the workload to Pilot Intune; define the pilot collection on the Staging tab of the co-management properties.

On the co-management Workloads tab, moving a workload slider to Pilot Intune switches that workload to Intune only for the devices in the pilot collection, which you specify on the Staging tab of the co-management properties. Setting the slider to Intune instead switches the workload for all co-managed Windows devices. Pilot Intune is the staged/test setting; Intune is the all-devices setting. Each workload can use a different pilot collection.

Why the other options are wrong:

  • A. Configuration Manager keeps the workload with ConfigMgr (no switch to Intune at all), and co-management pilots use a Configuration Manager collection, not a Microsoft Entra dynamic group.
  • B. Setting the workload to Intune switches it for all co-managed devices, not just a test subset. Piloting to a subset uses Pilot Intune plus a Configuration Manager pilot collection, not an Intune assignment filter.
  • C. Leaving the slider on Configuration Manager doesn't move any authority to Intune. Co-management workload switching is done in the Configuration Manager co-management properties, not solely from the Intune console.

Memory hook: Pilot Intune = switch the workload for the pilot collection (set on the Staging tab). Intune = switch it for all co-managed devices.

Microsoft Learn: https://learn.microsoft.com/intune/configmgr/comanage/how-to-switch-workloads#switch-workloads

A device is a member of two Microsoft Entra security groups, and each group has a different Windows Autopilot deployment profile assigned to it. Neither profile is the tenant default. Which profile does the device receive?

Correct answer: B. The oldest created of the two profiles.

When a device belongs to multiple groups that each have a Windows Autopilot deployment profile assigned, Intune resolves the conflict by applying the oldest created profile. The creation date, visible in the Created field under Essentials on the profile, is the tiebreaker, not the newest profile, group size, or assignment order. This trips up engineers who assume the most recently created profile wins.

Why the other options are wrong:

  • A. This is the common wrong assumption. Autopilot does not prefer the newest profile; the oldest created profile wins the conflict.
  • C. Group membership size has no bearing on Autopilot profile conflict resolution. The deciding factor is which profile was created first.
  • D. A conflict between two assigned profiles does not drop the device to a bare OOBE. Intune deterministically selects the oldest profile.

Memory hook: Two Autopilot profiles collide, the oldest created profile wins. Check the Created date.

Microsoft Learn: https://learn.microsoft.com/autopilot/profiles#windows-autopilot-profile-priority

You want new Autopilot Windows devices to stay locked on the Enrollment Status Page until three specific business-critical apps finish installing, but you do not want the ESP to wait on every other assigned app. Which ESP setting achieves this?

Correct answer: A. Set "Block device use until these required apps are installed if they're assigned to the user/device" and select the three apps (up to 100 can be chosen)

The ESP lets you either block on all apps and profiles, or specify a filtered blocking list via "Block device use until these required apps are installed." You can choose up to 100 apps; the ESP then waits only for the listed apps that are also assigned to the user or device, not for every assigned app.

Why the other options are wrong:

  • B. "Only show page to devices provisioned by OOBE" controls who sees the ESP, not which apps block, and it is not an app list.
  • C. That waits on every assigned app and profile, which is exactly what you are trying to avoid.
  • D. The timeout only controls when an installation error is shown; it does not choose which apps block.

Memory hook: Wait on just some apps? Use the 'required apps' list (up to 100), not 'all apps.'

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page

An administrator sets up Windows Autopilot device preparation. A user-driven deployment completes and users reach the desktop, but none of the apps or PowerShell scripts selected in the device preparation policy are installed, and the devices never appear in the target device security group. Which misconfiguration is the most likely cause?

Correct answer: D. The target device security group is missing the Intune Provisioning Client as an owner, or the group has 'Microsoft Entra roles can be assigned to the group' set to Yes.

Device preparation relies on Enrollment Time Grouping: at enrollment, Intune writes the device into the named static security group so assigned apps, scripts, and policies apply. For this to work, the Intune Provisioning Client service principal (AppId f1346770-5b25-470b-88bd-d5744ab7952c) must be an owner of that group, and the group must have 'Microsoft Entra roles can be assigned to the group' set to No. If the owner is missing or the group is role-assignable, the device never joins the group, so nothing assigned to it is delivered. The admin also needs the 'Enrollment time device membership assignment' RBAC permission.

Why the other options are wrong:

  • A. Device preparation policies are correctly assigned to a user group by design, and the deployment reaching the desktop shows the policy applied. The failure is the device not joining the target group, not a device-group assignment.
  • B. Device preparation deliberately requires no hardware-hash pre-registration. Missing hashes cannot be the cause because hashes are not used in this model.
  • C. Apps for device preparation must be both selected in the policy and assigned to the device security group. But the described symptom, the device never joining the group at all, points to the Enrollment Time Grouping owner or role-assignable misconfiguration, not an app assignment gap.

Memory hook: No apps and device not in group = Intune Provisioning Client not owner, or the group is role-assignable (it must be No).

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/setup-time-grouping

An organization ships Microsoft Entra hybrid join Autopilot devices directly to remote employees who have no corporate network connectivity at first boot. To let these devices complete the on-premises domain join over a VPN, which Autopilot deployment profile setting must be changed, and what companion requirement applies?

Correct answer: C. Set 'Skip Domain Connectivity Check' to Yes, and deploy a supported VPN solution via Intune (not one that uses user certificates or a UWP Store plug-in).

For off-premises Microsoft Entra hybrid join, set Skip Domain Connectivity Check to Yes so provisioning does not fail when a domain controller cannot be pinged. This does not remove the need to reach a DC; it relies on a VPN that Intune deploys and configures before the user signs in. The VPN must be deployable through Intune and cannot be one that uses user certificates or a non-Microsoft UWP VPN plug-in from the Store, because the user context is not established when the connection must be made.

Why the other options are wrong:

  • A. Leaving the setting at No requires direct DC connectivity and fails for a remote device with no LAN or VPN path. That is precisely the scenario the Yes setting plus a VPN addresses.
  • B. Self-deploying mode supports only Microsoft Entra join and no user. It cannot perform a hybrid domain join, so it does not satisfy the requirement to domain-join these devices.
  • D. 'Convert all targeted devices to Autopilot' only registers devices with the Autopilot deployment service. It has nothing to do with domain-controller connectivity during the hybrid join.

Memory hook: Remote hybrid join = Skip Domain Connectivity Check: Yes + an Intune-deployed VPN (no user-cert or UWP VPNs).

Microsoft Learn: https://learn.microsoft.com/autopilot/user-driven#user-driven-mode-for-microsoft-entra-hybrid-join

Intune Application Management (19 questions)

Go deeper on this topic in Microsoft Intune Application Management Field Guide.

You need to push configuration settings (for example, default account setup) to Microsoft Outlook on iOS and Android devices, but many of those devices are personally owned and NOT enrolled in Intune MDM. Which type of app configuration policy must you create so the settings reach unenrolled devices?

Correct answer: A. An app configuration policy with Device enrollment type set to Managed apps.

Managed apps app configuration policies are delivered over the MAM channel and require only that the app is Intune App SDK integrated and has an app protection policy; the device's enrollment state and how the app was delivered do not matter. Managed devices policies use the MDM OS channel and require enrollment.

Why the other options are wrong:

  • B. Managed devices is delivered via the MDM OS channel and applies only to enrolled devices.
  • C. Managed Google Play configuration is Android-only and still targets managed app delivery; it does not cover unenrolled iOS devices.
  • D. Settings catalog device profiles apply only to enrolled/managed devices, not to unenrolled MAM scenarios.

Memory hook: Unenrolled? 'Managed apps' (MAM channel). Enrolled? 'Managed devices' (MDM channel).

Microsoft Learn: https://learn.microsoft.com/intune/app-management/configuration/overview

An administrator manages Apple volume-purchased (VPP) apps in Intune. The Apple Business Manager location token is nearing its one-year expiry. Where in the Microsoft Intune admin center is the existing token renewed, and from where is the replacement token downloaded?

Correct answer: C. Tenant administration, then Connectors and tokens, then Apple VPP tokens; download from Apple Business Manager under Preferences, then Payments and Billing, then Apps and Books, then Content Tokens

VPP/location tokens are managed under Tenant administration, then Connectors and tokens, then Apple VPP tokens. To renew, download a fresh content token from Apple Business Manager (Preferences, then Payments and Billing, then Apps and Books, then Content Tokens), then Edit the existing token's Basics and upload the new file. Each location token is valid for one year. This is a deliberately different location from the ADE enrollment program token, which lives under Devices, then Enrollment, then Apple.

Why the other options are wrong:

  • A. VPP tokens are under Connectors and tokens, but the file comes from Apple Business Manager's Apps and Books, not the Apple Developer portal, and there is no 'Apple Enrollment' connector node for this.
  • B. That path and ABM's Settings, then MDM Servers page are for renewing the ADE enrollment program token, not the VPP/location token.
  • D. The Apple Push Certificates Portal issues the APNs push certificate, not VPP tokens; the App licenses view shows consumption, not a renewal upload point.

Memory hook: VPP/location token = Tenant admin, then Connectors and tokens, then Apple VPP tokens (file from ABM Apps & Books). ADE token = Devices, then Enrollment.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/manage-vpp-apple#renewing-vpp-tokens-or-apple-business-manager-location-token

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: https://learn.microsoft.com/intune/app-management/deployment/manage-vpp-apple#how-are-purchased-apps-licensed

An administrator configures a custom PowerShell detection script for a Win32 (.intunewin) app. On test devices where the app is definitely installed, Intune keeps reporting it as not detected and re-attempts the install, even though the script exits with code 0 and writes the expected string to output. Which script behavior would cause Intune to evaluate the app as 'not installed' despite a 0 exit code and STDOUT output?

Correct answer: B. The script writes data to STDERR; if anything is written to the standard error stream, detection is evaluated as not installed even when the exit code is 0 and STDOUT has data.

The custom detection contract is: the app is 'installed' only when the script exits with code 0 AND writes a string to STDOUT. Critically, if the script writes anything to the STDERR stream, the result is evaluated as not installed even if the exit code is 0 and STDOUT contains data. A stray Write-Error, a non-terminating error, or a warning routed to the error stream silently breaks detection and causes Intune to re-offer the app. Write to STDOUT only.

Why the other options are wrong:

  • A. Microsoft actually recommends encoding the detection script as UTF-8 BOM; that encoding does not cause a not-installed result.
  • C. There is no 60-second detection timeout that flips a passing script to not installed. Writing to STDERR is the documented cause of this exact symptom.
  • D. Write-Output sends data to STDOUT, which is exactly what detection reads. The problem is stray STDERR output, not the use of Write-Output.

Memory hook: Detection = exit 0 + STDOUT. But ANY write to STDERR = not installed. Keep the error stream clean.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/add-win32#step-4-detection-rules

A retailer deploys supervised, user-less iPad kiosks enrolled through ADE. A device restrictions profile blocks the App Store, and no Apple Accounts are signed in on the devices. The admin must push a volume-purchased app to these iPads. Which VPP license type must be used, and why?

Correct answer: B. Device licensing, because it requires no Apple Account or App Store sign-in and installs through the MDM channel

Device licensing ties the license to the device, requires no Apple Account and no App Store sign-in, and installs/updates the app over the MDM channel only - ideal for supervised, user-less kiosks where the App Store is blocked. User licensing requires each end user to sign in with a unique Apple Account (and the ABM invitation itself needs App Store access), so disabling the App Store breaks it. New VPP assignments now default to device licensing.

Why the other options are wrong:

  • A. User licensing needs a unique Apple Account per user and App Store access; these user-less, App-Store-blocked kiosks cannot satisfy that.
  • C. The 'up to five devices per license' limit belongs to user licensing, not device licensing; and user licensing is the wrong choice for App-Store-blocked user-less devices.
  • D. License type materially changes behavior (Apple Account requirement, install channel, migration rules), not just reporting.

Memory hook: No Apple ID, no App Store, MDM-only push = Device licensing. User licensing = 1 Apple Account, up to 5 devices.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/manage-vpp-apple#how-are-purchased-apps-licensed

An administrator adds an app with the 'Microsoft Store app (new)' type and assigns it as Available in user context to a group of Microsoft Entra registered (workplace-joined) Windows devices. When users click Install in Company Portal, they receive 'Requirements Not Met.' Which change resolves this, and what component delivers this app type?

Correct answer: B. Set the install behavior to System context; Microsoft Store app (new) deployments are delivered by the Intune Management Extension using Windows Package Manager (winget)

On Microsoft Entra registered devices, the install behavior for a Microsoft Store app (new) must be System context; a user-context Available assignment returns 'Requirements Not Met.' The Microsoft Store app (new) type is winget-backed and requires the Intune Management Extension on the device (plus at least two processor cores and network access to the Store and its CDN). Microsoft Entra joined devices do not have the user-context restriction.

Why the other options are wrong:

  • A. Microsoft Store for Business is retired and was replaced by the Microsoft Store app (new) type. The new type is delivered via the IME and winget, not a simple direct MDM push, so this does not fix the issue.
  • C. User context is supported for UWP apps on Microsoft Entra joined devices. The root cause here is specifically that Microsoft Entra registered devices need System context; Required versus Available is not the problem.
  • D. The fix is to use System context, not to change the join type. Microsoft Entra joined devices work in user context too; only Microsoft Entra registered devices require System context. Hybrid join is unnecessary.

Memory hook: Store app (new) = winget + IME. Entra registered device? Use System context or you hit 'Requirements Not Met.'

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/add-microsoft-store#microsoft-store-uwp-apps

An admin assigns a Windows line-of-business (MSIX) app as Available for enrolled devices and targets a device group. Enrolled users report the app never appears in the Company Portal. What is the most likely cause?

Correct answer: B. For this app type, Available assignments are only valid when targeting user groups, not device groups.

For almost all app types and platforms, Available assignments are only valid when assigned to user groups, not device groups (Win32 apps are the notable exception that can target either). Because this MSIX LOB app was assigned Available to a device group, it will not surface in the Company Portal.

Why the other options are wrong:

  • A. Available apps do appear in the installed Company Portal app for user-targeted assignments; the website is not the only surface.
  • C. Static versus dynamic group type is irrelevant; the issue is user versus device targeting for the Available intent.
  • D. Reinstalling Company Portal does not change the fact that Available-to-a-device-group is not honored for this app type.

Memory hook: Available = users. Devices need Required. (Win32 is the exception that does both.)

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/assign-groups

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: https://learn.microsoft.com/microsoft-365-apps/updates/servicing-profile

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: https://learn.microsoft.com/intune/device-security/microsoft-tunnel/mam#prerequisites

You're troubleshooting a failed Win32 app installation directly on a managed Windows client. The Intune Management Extension logs are in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. Which log file is dedicated to Win32 app deployment activity (downloads, applicability, installs, and detection)?

Correct answer: D. AppWorkload.log

AppWorkload.log is the log dedicated to Win32 app deployment activities on the client - app check-ins, installs, applicability, and detection. It lives in the IntuneManagementExtension\Logs folder alongside the other IME logs and is the primary file for diagnosing a failed Win32 install locally.

Why the other options are wrong:

  • A. HealthScripts.log tracks remediation/health script executions (proactive remediations, custom compliance), not Win32 app installs.
  • B. AgentExecutor.log tracks PowerShell script executions deployed by Intune, not Win32 app deployment.
  • C. ClientHealth.log tracks the health of the Intune Management Extension (SideCar) agent, not app install activity.

Memory hook: Win32 install trouble? Read the AppWorkload.

Microsoft Learn: https://learn.microsoft.com/intune/device-management/tools/management-extension-windows#intune-management-extension-logs

You deploy the Microsoft 365 Apps for Windows 10 and later suite using the configuration designer. Target devices still have an older MSI-based Office installation. In the app suite settings you set Remove other versions to Yes. What is the effect on targeted devices?

Correct answer: D. All existing MSI (Windows Installer) versions of Office are removed from the device, including Office apps you did not select for installation.

Remove other versions uninstalls every MSI-based Office product on the device, not just the apps chosen in Configure App Suite. The sweep is deliberate: a Microsoft 365 Apps (Click-to-Run) install will not succeed while pre-existing MSI Office apps are present.

Why the other options are wrong:

  • A. It targets MSI Office versions, not existing Click-to-Run installs.
  • B. Removal is not scoped to the selected apps; it removes every MSI Office app on the device.
  • C. Shared computer activation is a licensing feature for multi-user devices and is unrelated to MSI removal.

Memory hook: 'Remove other versions' nukes ALL MSI Office, not just what you selected.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/add-microsoft-365-windows

A user installs Outlook on a personal, unenrolled Android phone. The administrator has assigned an Android app protection policy to that user, but the App protection status report shows nothing for the user and no PIN or data controls ever appear in the app. What is the most likely reason?

Correct answer: B. The Microsoft Intune Company Portal app is not installed; on Android it is required to deliver app protection policies even without enrollment

On Android, much of the app protection functionality is built into the Company Portal app, which acts as the broker that retrieves and delivers policy from the Intune service. Device enrollment is not required, but the Company Portal app is always required. Without it installed, no app protection policy reaches the device and the status report stays empty for that user.

Why the other options are wrong:

  • A. App protection policies require an Intune license, not Microsoft Entra ID P2. Licensing tier is not the gap here; the absent Company Portal app is.
  • C. Enrollment is not required for app protection policies (that is the whole point of MAM without enrollment). The missing piece is the Company Portal broker app, not enrollment.
  • D. Microsoft Defender for Endpoint is used for Mobile Threat Defense and Tunnel scenarios. It is not the required broker for delivering app protection policies on Android.

Memory hook: Android + app protection = Company Portal must be installed, even with no enrollment. It's the policy broker.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/protection/overview#app-protection-experience-for-android-devices

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: https://learn.microsoft.com/en-us/mem/intune/protect/microsoft-tunnel-mam

A Windows laptop is a member of two Microsoft Entra device groups. Using the same app object, a design app is assigned as Required to the first group and as Uninstall to the second group. There are no other assignments for this app. What does Intune do on this device?

Correct answer: B. The app is installed, because when Required and Uninstall conflict for the same app, Intune resolves to Required

A single group cannot carry two intents, but a device that is a member of two groups with different intents produces a documented resolution. In Intune's app-intent conflict matrix, Device Required plus Device Uninstall resolves to Required (the same is true for User Required plus User Uninstall). Required wins over Uninstall, so the app is installed. Intent is resolved before any assignment filter is evaluated.

Why the other options are wrong:

  • A. Uninstall does not universally beat install. Uninstall only wins over Available (for example, User Available plus User Uninstall resolves to Uninstall). Against Required, Required is the winning intent.
  • C. There is no install/uninstall thrash. Intune settles on a single winning intent (Required) rather than oscillating between the two assignments.
  • D. Conflicting intents do not cancel out. Intune applies a deterministic resolution from its conflict matrix; here that resolution is Required, so the app installs.

Memory hook: Required beats Uninstall; Uninstall only beats Available. Intent is decided before any filter runs.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/assign-groups#how-conflicts-between-app-intents-are-resolved

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: https://learn.microsoft.com/intune/app-management/deployment/add-win32#step-4-detection-rules

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: https://learn.microsoft.com/intune/app-management/deployment/add-win32

An organization deploys Microsoft 365 Apps to Windows devices through Intune. Occasionally the Enrollment Status Page hangs during app installation when Microsoft 365 Apps is deployed using the 'Microsoft 365 Apps (Windows 10 and later)' app type alongside other Win32 apps. What is the recommended solution to prevent ESP hangs?

Correct answer: C. Deploy Microsoft 365 Apps to Intune using the Win32 app type instead of the Microsoft 365 Apps app type

Microsoft documentation specifically notes that the ESP can hang when Microsoft 365 Apps is deployed using the 'Microsoft 365 Apps (Windows 10 and later)' app type and another Win32 app is being tracked by ESP at the same time, because both use TrustedInstaller and simultaneous installations conflict. The recommended workaround is to deploy Microsoft 365 Apps via Intune using the Win32 app type, which avoids the installer conflict and prevents the ESP hang.

Why the other options are wrong:

  • A. Removing Microsoft 365 Apps from the ESP blocking list would allow the ESP to complete without waiting for M365 Apps, but the apps might not be installed before the user reaches the desktop. This is a workaround that sacrifices the provisioning guarantee, not the recommended fix.
  • B. Deploying via a PowerShell script would bypass normal app tracking and remove it from ESP monitoring, but it introduces complexity and is not the documented recommended approach for this specific problem.
  • D. Increasing the ESP timeout delays the failure but does not resolve the underlying TrustedInstaller conflict between the LOB/M365 app type and Win32 apps. The timeout approach does not prevent the hang.

Memory hook: M365 Apps + Win32 + ESP hang = fix by using Win32 app type for M365 Apps too. Same installer type, no conflict.

Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status

An administrator opens the Managed Google Play iframe in the Intune admin center, searches for a public app, chooses Approve, and syncs. Days later, users on Android Enterprise personally owned work profile devices report the app never appears in their work Play Store, even after multiple device syncs. The app shows as approved in the iframe. What did the administrator miss?

Correct answer: C. The app must be assigned to a group in Intune; only apps that have been assigned show up in the Managed Google Play store for the end user.

Approving an app in Managed Google Play only makes it available for management; it does not deploy it. Only apps that have been assigned to a user or device group in Intune show up in the Managed Google Play store on the device. Approval without an assignment is a silent no-op from the user's perspective. The fix is to create an assignment (Available or Required) for the app and sync.

Why the other options are wrong:

  • A. Personally owned work profile devices do surface assigned apps in the work Play Store. Changing the enrollment type is unnecessary and unrelated to the missing assignment.
  • B. The Managed Google Play connection is one-time and one-to-one; an approval persists and does not require reconnecting. The missing element is the assignment, not the connector.
  • D. Private/LOB publishing is for in-house apps scoped to the tenant; a public store app does not need to be republished as private, and doing so would not fix a missing assignment.

Memory hook: Approve makes it manageable; Assign makes it visible. No assignment, no icon in the work Play Store.

Microsoft Learn: https://learn.microsoft.com/intune/app-management/deployment/add-managed-google-play#assign-a-managed-google-play-app-to-android-enterprise-personally-owned-and-corporate-owned-work-profile-devices

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: https://learn.microsoft.com/intune/app-management/protection/ref-settings-ios#data-protection

Intune Device Management and Enrollment (19 questions)

Go deeper on this topic in Microsoft Intune Device Management and Enrollment Field Guide.

After enabling Endpoint analytics and assigning the Intune data collection policy to a Windows device, an admin still does not see that device in the Startup performance report. Which requirement most likely explains the delay?

Correct answer: D. The device must be restarted after data collection is enabled, and it can take up to 25 hours to appear in the report.

Devices configured for data collection must be restarted to fully enable analytics, and it can take up to 25 hours after that before the device shows in the Device performance tab. The minimum for a meaningful score is 5 devices, and boot/sign-in events are retained for 29 days.

Why the other options are wrong:

  • A. 29 days is the boot/sign-in event retention window, not a required run-in period before appearing.
  • B. The threshold is 5 reporting devices for a meaningful score, not 50; a single configured device can still appear.
  • C. Entra joined, hybrid joined, and co-managed devices are all supported; hybrid join is not required.

Memory hook: Restart + up to 25 hours to show; 5 devices for a score; 29-day event retention.

Microsoft Learn: https://learn.microsoft.com/intune/endpoint-analytics/troubleshoot

An administrator configures an Intune compliance policy for Windows devices that requires the device to be at or below a 'Low' machine risk score using Microsoft Defender for Endpoint integration. A device has medium-level threats detected. What is the compliance status of this device?

Correct answer: B. Noncompliant, because medium-level threats exceed the Low threshold

When the Intune compliance policy is set to 'Low' for the machine risk score, the device is evaluated as compliant only if it has no threats or only low-level threats. A device with medium-level threats exceeds the Low threshold and is marked as noncompliant. When combined with a Conditional Access policy that requires device compliance, the noncompliant device will lose access to corporate resources automatically.

Why the other options are wrong:

  • A. The 'Low' setting means only low or no threats are acceptable. Medium-level threats are above the Low threshold and result in a noncompliant status, not a compliant one.
  • C. Microsoft Defender for Endpoint reports threat levels (Clear, Low, Medium, High) to Intune. Intune uses all of these levels for compliance evaluation, not just High and Critical.
  • D. When a Conditional Access policy requires device compliance, a noncompliant device loses access to the targeted cloud apps automatically based on the CA policy evaluation. Access is not retained pending manual action.

Memory hook: Low threshold = only No threat or Low threat passes. Medium threat = noncompliant. CA does the rest automatically.

Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/protect/compliance-policy-create-windows

Two Settings Catalog device configuration profiles are assigned to the same Windows device. Each configures the identical setting, but to different values. What does Intune do with that setting?

Correct answer: C. The setting is not applied to the device; Intune flags the conflict and an admin must resolve it manually.

When two configuration profiles set the same setting to different values, the setting is not applied - Intune shows the conflict and you must resolve it manually. This is different from compliance policies (where the most restrictive value wins) and different from ESP profiles (which use priority).

Why the other options are wrong:

  • A. 'Most restrictive wins' is the rule for two conflicting compliance policies, not for two configuration profiles.
  • B. Configuration profiles have no priority ranking that auto-resolves a per-setting conflict; only some object types (like ESP profiles) use priority.
  • D. Intune doesn't silently force the OS default; the setting simply stays in conflict and unapplied.

Memory hook: Two configs fight = nobody wins (setting unapplied); two compliance fight = strictest wins.

Microsoft Learn: https://learn.microsoft.com/intune/device-configuration/troubleshoot-device-profiles#conflicts

An administrator needs to run a targeted query against an enrolled Windows device in Intune to check whether a specific registry key is present. Which remote action supports this scenario?

Correct answer: C. Run device query using KQL

The 'Run a device query using KQL' remote action in Intune allows administrators to query device properties, installed software, registry values, and other attributes on individual Windows devices using Kusto Query Language (KQL). This is part of the Microsoft Intune Advanced Analytics capability included in the Intune Suite.

Why the other options are wrong:

  • A. Rotate BitLocker recovery key triggers a fresh key rotation and backs up the new key to Entra or Active Directory. It has no querying capability.
  • B. Update Microsoft Defender security intelligence pushes an on-demand definition update to the device. It does not support custom queries against device state.
  • D. Sync device forces the device to check in with Intune to receive policies and report status. It does not execute custom queries against device data.

Memory hook: Run device query = interrogate the device live with KQL. Sync delivers policy; query asks questions.

Microsoft Learn: https://learn.microsoft.com/intune/advanced-analytics/device-query

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: https://learn.microsoft.com/intune/fundamentals/filters/troubleshoot

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: https://learn.microsoft.com/intune/device-security/compliance/configure-noncompliance-actions#available-actions-for-noncompliance

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: https://learn.microsoft.com/intune/device-enrollment/android/setup-corporate-work-profile#set-up-android-enterprise-corporate-owned-work-profile-device-management

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: https://learn.microsoft.com/intune/device-configuration/settings-catalog/configure-admx-templates-windows

A company issues corporate-owned Android 13 phones that employees may also use for personal apps, with work and personal data kept in separate profiles. The admin enrolls them as Android Enterprise corporate-owned devices with a work profile (COPE). A junior technician proposes provisioning them by typing the afw#setup identifier or by tapping an NFC tag during setup. What should the admin tell the technician?

Correct answer: D. Neither afw#setup nor NFC is supported for COPE on Android 11 and later; use QR code, Google Zero Touch, or Knox Mobile Enrollment instead.

For corporate-owned work profile (COPE) devices, the afw#setup (DPC identifier) method and NFC provisioning are only supported on Android 8-10; they are not available on Android 11 and later. On Android 11+ COPE devices the supported provisioning methods are QR code, Google Zero Touch, and Knox Mobile Enrollment. The afw#setup identifier is a fully managed-only method and cannot be used for COPE provisioning at all.

Why the other options are wrong:

  • A. afw#setup and NFC are not universally valid for COPE. Google removed both for corporate-owned work profile provisioning on Android 11 and later.
  • B. COPE is specifically designed to keep work and personal data separate on a corporate-owned device that allows personal use. It is the correct model; only the provisioning method choice is wrong.
  • C. The afw#setup (DPC identifier) method supports full device management provisioning only and cannot be used for COPE on Android 11 devices, so it does not work for COPE on Android 13.

Memory hook: COPE on Android 11+ = QR, Zero Touch, or KME only. afw#setup and NFC died at Android 10 for COPE.

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/android/setup-corporate-work-profile#set-up-android-enterprise-corporate-owned-work-profile-device-management

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: https://learn.microsoft.com/intune/fundamentals/setup-mdm-authority#coexistence

A company is rolling out Conditional Access that requires devices to be marked compliant. During a review, the security team notices that some enrolled devices that have never been assigned any compliance policy are still being treated as compliant and are gaining access. Which tenant-wide setting explains this, and what is its default value?

Correct answer: C. 'Mark devices with no compliance policy assigned as,' default Compliant.

The tenant-wide compliance policy setting 'Mark devices with no compliance policy assigned as' defaults to Compliant, meaning any device that has never received a compliance policy is treated as compliant for Conditional Access purposes. Microsoft recommends switching it to Not compliant once policy coverage is solid, so that only confirmed-compliant devices gain access. It lives under Endpoint security, then Device compliance, then Compliance policy settings.

Why the other options are wrong:

  • A. The compliance status validity period (default 30 days) controls how long a device can go without reporting compliance before it is treated as noncompliant. It is a real tenant setting, but it is not why an unassigned device is counted as compliant.
  • B. The setting exists, but its default is Compliant, not Not compliant. Not compliant is the recommended hardened value that an admin must explicitly select.
  • D. The CA grant control enforces compliance for access, but it is not a default-off setting that causes unassigned devices to be treated as compliant. The compliant-by-default behavior comes from the Intune tenant-wide compliance policy setting.

Memory hook: No policy = Compliant by default. Flip it to Not compliant before you trust CA.

Microsoft Learn: https://learn.microsoft.com/intune/device-security/compliance/overview#compliance-policy-settings

In Endpoint analytics, the Startup performance report shows a tenant startup score. How is the startup score derived, and what does a status of "Insufficient data" indicate?

Correct answer: C. It is a weighted average of the boot score and the sign-in score; "Insufficient data" means fewer than the required 5 devices are reporting.

The startup score is a weighted average of the boot score and the sign-in score, expressed 0 (poor) to 100 (excellent). A status of "Insufficient data" means there are not enough devices reporting - currently at least 5 devices are required for a meaningful score.

Why the other options are wrong:

  • A. Work from anywhere is a different report, and Windows 11 is not required to produce a startup score.
  • B. Application reliability and battery health are separate Endpoint analytics reports, not the startup score.
  • D. The score is expressed 0-100, not raw seconds; hard-disk vs SSD is a separate insight, not the cause of Insufficient data.

Memory hook: Startup = Boot + Sign-in (weighted); fewer than 5 devices = Insufficient data.

Microsoft Learn: https://learn.microsoft.com/intune/endpoint-analytics/startup-performance

You must build an automated nightly job that pulls the full device-compliance dataset out of Intune into an external SIEM as CSV or JSON, with no one clicking in the portal. Which approach is the current, supported way to export the report?

Correct answer: A. POST to https://graph.microsoft.com/beta/deviceManagement/reports/exportJobs with a reportName such as "DeviceNonCompliance", poll the job until its status is completed, then download the CSV/JSON from the returned url.

Intune reports that were migrated to the modern reporting infrastructure are exported through a single top-level Graph endpoint: POST deviceManagement/reports/exportJobs with a reportName (for example DeviceNonCompliance). You then GET the job by id until status is completed and download the compressed CSV/JSON from the url field. This is the documented, automatable path.

Why the other options are wrong:

  • B. The managedDevices entity returns device objects, not the reporting export dataset; it is the wrong API and would require heavy client-side reconstruction of the report.
  • C. Actions for noncompliance send notifications/marks (email, mark noncompliant), they do not export a report dataset.
  • D. The exportJobs Graph API exists specifically so reports can be exported programmatically, with no admin center clicks required.

Memory hook: Reports leave Intune through one door: POST exportJobs, poll, download.

Microsoft Learn: https://learn.microsoft.com/intune/device-management/reports/export-graph-apis

A company co-manages Windows devices with Configuration Manager and Microsoft Intune. The endpoint team wants to evaluate Intune compliance policy on only a 50-device subset before moving everyone, while Configuration Manager keeps managing compliance for all other devices. In the co-management properties, which configuration achieves this?

Correct answer: B. Set the Compliance policies workload slider to Pilot Intune and specify the test collection on the Staging tab.

Each co-management workload (including Compliance policies) has its own slider. The Pilot Intune setting switches that workload only for the devices in the pilot collection you designate on the Staging tab; every other device continues to be managed by Configuration Manager. This is exactly the staged-pilot pattern Microsoft prescribes before flipping a workload to Intune for everyone.

Why the other options are wrong:

  • A. The Intune setting switches the workload for ALL co-managed Windows devices, not a subset; an Entra group assignment doesn't limit which tool holds the workload authority.
  • C. Leaving sliders on Configuration Manager means Intune never becomes the compliance authority, and an Intune filter can't change which management tool owns a workload.
  • D. Device configuration is the wrong workload and wouldn't move compliance authority; switching Device configuration also drags Resource Access and Endpoint Protection along with it.

Memory hook: Pilot Intune = pilot collection (Staging tab); Intune = everybody.

Microsoft Learn: https://learn.microsoft.com/intune/configmgr/comanage/how-to-switch-workloads

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: https://learn.microsoft.com/intune/configmgr/comanage/workloads

An employee is leaving the company and returning to their personal, BYOD-enrolled iPhone. IT must remove the corporate email profile, the VPN and Wi-Fi profiles, managed apps and their data, and unenroll the device from Intune, but must not touch the user's personal photos, personal apps, or reset the phone. Which Intune remote action should be used?

Correct answer: C. Retire

The Retire action removes company data (managed apps and their data, email/VPN/Wi-Fi and certificate profiles, and configuration) and unenrolls the device from Intune, while leaving personal data intact. It is the correct action for BYOD offboarding. The action takes effect the next time the device checks in with Intune.

Why the other options are wrong:

  • A. Fresh Start is a Windows 10/11-only action used to remove installed apps (often to clear OEM bloatware). It does not apply to an iPhone.
  • B. Deleting the Entra device record removes the identity object but does not, by itself, cleanly remove the managed apps, profiles, and company data from the device. Retire is the action that removes company data and unenrolls.
  • D. Wipe restores the device to factory settings and removes all data and settings, including the user's personal photos and apps. That is inappropriate for a personally owned device being returned to its owner.

Memory hook: Retire = take back company data, leave personal alone. Wipe = factory reset everything.

Microsoft Learn: https://learn.microsoft.com/intune/device-management/actions/retire

An administrator is configuring Windows LAPS in Intune. The devices are Microsoft Entra joined (not hybrid joined). Which backup directory must be selected in the LAPS policy, and what prerequisite must be completed in Microsoft Entra before the backup will work?

Correct answer: A. Select 'Azure Active Directory (cloud)'; enable LAPS in Microsoft Entra device settings

For Microsoft Entra joined devices (cloud-only join), the LAPS backup directory must be set to the cloud option (Microsoft Entra ID). Additionally, LAPS must be explicitly enabled in Microsoft Entra under Identity, then Devices, then Device settings, then 'Enable Local Administrator Password Solution (LAPS)'. Hybrid joined devices do not require this step, but pure Entra join does.

Why the other options are wrong:

  • B. On-premises Active Directory backup requires the device to be domain-joined. A Microsoft Entra joined device is not joined to an on-premises AD domain, so this backup destination is incompatible.
  • C. The Intune Connector for Active Directory is required for Autopilot hybrid join scenarios, not for LAPS with Entra-joined devices. It is not a prerequisite for cloud-based LAPS backup.
  • D. On-premises AD backup cannot function for a Microsoft Entra joined device that has no on-premises domain relationship. Selecting the cloud backup directory is the correct path.

Memory hook: Entra join + LAPS = cloud backup. But first flip the LAPS switch in Entra device settings.

Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/protect/windows-laps-overview

To stop employees from enrolling home PCs, you create a device platform restriction that blocks personally owned Windows devices. A field technician reports that choosing "Set up for work or school" in Windows Settings on a new corporate laptop and signing in fails with error 80180014. Which enrollment method would let that corporate laptop enroll despite the personal-Windows block, without weakening the restriction for everyone?

Correct answer: A. Enroll the device through Windows Autopilot

When personal Windows enrollment is blocked, Intune only permits Windows enrollments that are pre-authorized as corporate. Windows Autopilot (and GPO / Configuration Manager co-management auto-enrollment) count as corporate enrollments, so an Autopilot-registered device is not blocked. The manual Settings-based "Set up for work or school" path is treated as personal and is blocked with error 80180014.

Why the other options are wrong:

  • B. The manufacturer restriction is Android-only; marking a Windows device corporate requires corporate identifiers (manufacturer/model/serial), not a model allow-list on this policy.
  • C. Using a personal Microsoft account does not make the device corporate; it remains blocked.
  • D. The "Join Microsoft Entra ID" flow from Windows Settings is still classed as a personal enrollment and is blocked (error 80180014).

Memory hook: Personal-Windows block? Autopilot (or GPO/co-management) is the corporate passcard.

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/restrictions

An organization has a stock of previously used corporate iPads that are NOT registered in Apple Business Manager. IT must enroll them as supervised corporate devices with user affinity (so each iPad is associated with its assigned user and can use the Company Portal). A Mac with USB cables is available. Which Apple Configurator enrollment method meets these requirements, and what preparation is mandatory?

Correct answer: B. Setup Assistant enrollment; it wipes each device and requires the device serial numbers to be imported into Intune and assigned to the enrollment profile beforehand.

Apple Configurator offers two modes. Setup Assistant enrollment wipes the device, produces a supervised device, and supports user affinity (and therefore Company Portal) - but it requires the device serial numbers to be pre-imported into Intune and assigned to the enrollment profile before the device connects. Direct enrollment does not wipe the device and needs no serial numbers, but it only supports enrollment without user affinity and does not support Company Portal, so it cannot satisfy the 'supervised + user affinity' requirement. A Mac running Apple Configurator 2 with a USB connection to each device is required.

Why the other options are wrong:

  • A. Direct enrollment only supports enrollment without user affinity and does not support Company Portal, so it fails the user-affinity requirement regardless of serial-number handling.
  • C. Setup Assistant enrollment does wipe the device and support user affinity, but importing the serial numbers into Intune and assigning them to the policy is mandatory, not optional.
  • D. Direct enrollment does not wipe the device and needs no serial numbers, but it produces a userless, unsupervised enrollment with no Company Portal - the opposite of what is required.

Memory hook: Configurator Setup Assistant = wipe + supervised + user affinity + preloaded serials. Direct enrollment = no wipe, no serials, NO user affinity, no Company Portal.

Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/apple/setup-configurator-ios

Intune Endpoint Security and Updates (18 questions)

Go deeper on this topic in Microsoft Intune Endpoint Security and Updates Field Guide.

You manage Microsoft Defender Antivirus exclusions exclusively through Intune and want those exclusions to also be protected by tamper protection so a local administrator can't remove them. Besides meeting the minimum Defender platform version and onboarding to Defender for Endpoint, which additional setting must you configure on the devices?

Correct answer: A. Set DisableLocalAdminMerge to true (enabled).

For antivirus exclusions to be tamper-protected, exclusions must be managed in Intune (or Configuration Manager) only, the device must run a supported Defender platform, and DisableLocalAdminMerge must be enabled so local exclusion lists don't merge with the org-managed policy.

Why the other options are wrong:

  • B. Tamper protection scope controls which devices receive tamper protection, not whether exclusions are protected from tampering.
  • C. AllowLocalPolicyMerge is the opposite intent; allowing local merges defeats exclusion tamper protection.
  • D. LSA protection guards credentials in the LSASS process; it has nothing to do with tamper-protecting antivirus exclusions.

Memory hook: Protect exclusions: kill the merge - DisableLocalAdminMerge = true.

Microsoft Learn: https://learn.microsoft.com/defender-endpoint/manage-tamper-protection-intune#tamper-protection-for-antivirus-exclusions

You want Delivery Optimization peering to work between branch-office devices that sit on different subnets and behind different NATs, restricting peers to a specific group you define with a Group ID. Which DODownloadMode value must you configure?

Correct answer: D. 2 - HTTP blended with peering across a private group.

Download mode 2 (HTTP blended with peering across a private group) is the mode that uses a Group ID, and its peering crosses NAT boundaries - exactly what's needed to peer devices on different subnets/domains that share the same Group ID. The Group ID source setting even requires Download mode be set to mode 2.

Why the other options are wrong:

  • A. Mode 3 peers across the internet by public IP address, not restricted to your defined Group ID.
  • B. Mode 1 peers only behind the same NAT, so it won't peer devices across different NATs and subnets.
  • C. Mode 100 (Bypass) disables Delivery Optimization peering and uses BITS instead.

Memory hook: Group ID needs Group mode = DODownloadMode 2.

Microsoft Learn: https://learn.microsoft.com/windows/deployment/do/waas-delivery-optimization-reference#download-mode

Your organization runs an isolated network where Intune can't complete the service-to-service connection to Microsoft Defender for Endpoint. You still need to onboard the Windows devices to Defender for Endpoint using an Intune Endpoint detection and response (EDR) policy. In the EDR profile, how should you set the 'Microsoft Defender for Endpoint client configuration package type'?

Correct answer: D. Select "Onboard" and paste the contents of the WindowsDefenderATP.onboarding blob.

When the Intune-Defender connection isn't established, the EDR profile can't use 'Auto from connector.' For disconnected environments you choose 'Onboard' and supply the WindowsDefenderATP.onboarding blob content manually.

Why the other options are wrong:

  • A. Offboarding blobs remove devices from Defender for Endpoint; they don't onboard, and 'Auto from connector' still requires the connection.
  • B. 'Auto from connector' only works when the service-to-service connection exists; without it, that option can't retrieve the package.
  • C. Antivirus policy configures Defender AV settings; it doesn't onboard devices to Defender for Endpoint. Onboarding is done by the EDR policy or onboarding package.

Memory hook: No connector? Paste the blob: 'Onboard' + WindowsDefenderATP.onboarding.

Microsoft Learn: https://learn.microsoft.com/intune/device-security/microsoft-defender/configure-integration#onboard-devices

An organization wants Windows Hello for Business enabled only for a specific pilot group of users, not for every device that enrolls. An administrator notices the tenant-wide Windows Hello for Business policy (under Devices, then Windows, then Windows Enrollment) is set to enabled. What is the recommended approach, and why?

Correct answer: A. Disable Windows Hello for Business in the tenant-wide enrollment policy and enable it instead with a targeted policy (for example, an Account protection or Settings catalog policy) assigned to the pilot group, because the tenant-wide policy applies to all devices and only at enrollment time.

The tenant-wide Windows Hello for Business policy applies to all devices enrolling in Intune and is evaluated only at enrollment time; later changes to it don't reach already-enrolled devices. Because of this, the common pattern is to set the tenant-wide policy to Disabled and then enable Windows Hello for Business through a targeted policy (Account protection policy, Settings catalog, security baseline, or identity protection template) assigned to a specific security group. Targeted policies apply after enrollment and refresh on normal policy intervals, giving you group-level control.

Why the other options are wrong:

  • B. Maintaining per-user exclusions on an all-devices, enrollment-time policy is unmanageable and still leaves it applying at enrollment. Disabling the tenant-wide policy and targeting a group is the designed approach.
  • C. Conditional Access governs access to resources; it does not provision Windows Hello for Business or override the enrollment-time policy. Enablement is done through Intune device/account-protection policy, not CA.
  • D. Windows Hello for Business can be targeted to specific groups using Account protection, Settings catalog, security baseline, or identity protection policies applied after enrollment.

Memory hook: Tenant-wide WHfB = all devices, enrollment-time only. Disable it, then target the pilot group with an Account protection / Settings catalog policy.

Microsoft Learn: https://learn.microsoft.com/windows/security/identity-protection/hello-for-business/configure#configure-windows-hello-for-business-using-microsoft-intune

You create a Windows driver update policy set to 'Automatically approve all recommended driver updates' with a 7-day deferral. A targeted device currently runs display driver version 5; the OEM's newest recommended version is version 4. What happens on that device?

Correct answer: A. Nothing - Windows Update only installs a driver newer than the one already installed, so it will not downgrade to version 4

Windows Update installs an approved driver only when its version is newer than what is already on the device, so version 4 is never offered to a device running version 5. The 7-day deferral is the distractor: it delays automatically approved recommended drivers, but an update that will never be offered has nothing to defer.

Why the other options are wrong:

  • B. The 7-day deferral applies to auto-approved recommended drivers, so nothing would install immediately even if it were newer.
  • C. Approval alone does not force installation; a version older than the installed driver is not offered.
  • D. The policy is not rejected; the older recommended version simply is not offered to that already-newer device.

Memory hook: Drivers only go up; Windows Update never rolls a driver back.

Microsoft Learn: https://learn.microsoft.com/intune/device-updates/windows/configure-driver-update-policy

A team onboards Windows clients to Microsoft Defender for Endpoint through the Intune EDR policy and confirms the devices now appear in the Microsoft Defender portal's device inventory. They then build an Intune compliance policy using "Require the device to be at or under the machine risk score" plus a Conditional Access policy that blocks noncompliant devices. In testing, the risk-based rule never marks any device noncompliant, even on a device with active malware. The organization licenses Microsoft Defender for Endpoint Plan 1. What is the cause?

Correct answer: C. The machine risk score is produced by endpoint detection and response (EDR), which is a Defender for Endpoint Plan 2 capability; Plan 1 onboards devices but does not generate the risk signal that compliance and Conditional Access need.

Defender for Endpoint Plan 1 provides next-generation protection, attack surface reduction, device control, endpoint firewall, and network protection, but not endpoint detection and response (EDR). The machine risk score used by the "Require the device to be at or under the machine risk score" compliance setting is an EDR-derived signal, which is a Plan 2 capability. With P1, devices onboard and appear in the Defender portal, but no risk score is produced, so the compliance rule has nothing to act on and Conditional Access never sees a noncompliant result. Plan 2 (included in Microsoft 365 E5 / Windows E5) is required for the device-risk-to-compliance flow.

Why the other options are wrong:

  • A. Devices onboarded via the Intune EDR policy are fully onboarded; re-running a GPO onboarding script does not add a risk score. The risk score requires Defender for Endpoint Plan 2 regardless of onboarding method.
  • B. The machine risk score compliance setting is supported on both Microsoft Entra joined and hybrid joined Windows devices. Join type is not the blocker; the missing EDR/risk capability under Plan 1 is.
  • D. Conditional Access consumes the Intune compliance result and does not require Microsoft Entra ID P2 to honor a Defender-driven compliance state. The gap is the absent risk signal, which is a Defender Plan 2 feature.

Memory hook: P1 onboards and shows the device; the risk score is EDR = P2. No P2, no machine risk score for compliance or CA to act on.

Microsoft Learn: https://learn.microsoft.com/office365/servicedescriptions/microsoft-365-service-descriptions/microsoft-365-tenantlevel-services-licensing-guidance/microsoft-defender-service-description#microsoft-defender-for-endpoint

Three separate Intune Antivirus (endpoint security) policies each define a different set of Microsoft Defender Antivirus file path exclusions, and all three are assigned to the same device. What is the resulting behavior on that device?

Correct answer: A. The exclusions are combined into a single superset, and all exclusions from the three policies apply.

Defender Antivirus exclusion settings (Excluded Paths, Excluded Processes, Excluded Extensions) support policy merge, so Intune evaluates all applicable policies and combines their exclusions into a single superset delivered to the device. The most-secure / last-modified / none tiebreakers apply only to settings that do not support policy merge.

Why the other options are wrong:

  • B. No policy delivered is the outcome for non-mergeable settings that cannot be resolved, not for mergeable exclusions.
  • C. Most secure wins is the resolution for non-merge settings, not for mergeable exclusions.
  • D. Last modified wins is a tiebreaker for non-merge settings, not for exclusions that merge into a superset.

Memory hook: Exclusions merge into a superset - paths, processes, extensions.

Microsoft Learn: https://learn.microsoft.com/intune/device-configuration/endpoint-security/antivirus#policy-merge-for-settings

An administrator must silently enable BitLocker on Microsoft Entra joined Windows 11 devices used by standard (non-administrator) users, with no BitLocker wizard prompts at all. In the Endpoint security Disk encryption (BitLocker) profile, which combination of settings achieves silent enablement for standard users?

Correct answer: A. Require Device Encryption = Enabled; Allow Warning For Other Disk Encryption = Disabled; Allow Standard User Encryption = Enabled

Silent BitLocker requires Require Device Encryption = Enabled and Allow Warning For Other Disk Encryption = Disabled - the third-party-encryption warning prompt is what breaks the silent flow. Once that warning is disabled, the Allow Standard User Encryption setting becomes available and must be Enabled so the RequireDeviceEncryption policy triggers for standard (non-admin) users. Any startup-authentication requirement (PIN or startup key) forces user interaction and must be left Blocked for silent enablement.

Why the other options are wrong:

  • B. Requiring a TPM startup PIN forces the user to interact at boot, which is incompatible with silent enablement. Require Device Encryption must also be Enabled, not Not configured.
  • C. Requiring a startup key forces user interaction (inserting a USB key), breaking the silent flow, and the third-party encryption warning must be Disabled, not Enabled.
  • D. Leaving Allow Warning For Other Disk Encryption = Enabled keeps the confirmation prompt, which breaks silent enablement. Without Allow Standard User Encryption enabled, standard (non-admin) users also will not trigger encryption.

Memory hook: Silent BitLocker = Require Encryption ON + Warning for other encryption OFF + Allow Standard User Encryption ON. Any startup PIN or key = not silent.

Microsoft Learn: https://learn.microsoft.com/intune/device-configuration/endpoint-security/encrypt-bitlocker-windows#configure-silent-bitlocker-encryption

A Windows device managed by Endpoint Privilege Management receives two elevation rules that both match the same executable: a device-targeted rule with elevation type Automatic, and a user-targeted rule with elevation type Deny. When the signed-in user launches the file, what happens?

Correct answer: A. The user-targeted Deny rule wins and the file is blocked from running elevated.

When multiple elevation rules match one application, EPM resolves them so that rules with elevation type Deny always take precedence, and rules deployed to a user take precedence over rules deployed to a device. Both factors point to the Deny rule here, so the elevation is denied.

Why the other options are wrong:

  • B. Device rules do not win; user rules take precedence over device rules, and Deny outranks Automatic regardless.
  • C. A Deny rule blocks elevation; it does not silently auto-elevate the file.
  • D. Reverting to default client behavior is how EPM handles conflicting elevation settings policies, not two rules matching one app.

Memory hook: Deny always wins; user beats device.

Microsoft Learn: https://learn.microsoft.com/intune/epm/deployment-planning#epm-policies

An administrator creates an Intune Windows driver update policy and selects "Automatically approve all recommended driver updates," expecting every driver Windows Update can offer to install without review. Later they find that several available driver updates for the assigned devices are sitting with a status of "Needs review" and are not installing. Why?

Correct answer: B. In an automatic-approval policy, only recommended driver updates are auto-approved; any non-recommended ("other") driver updates are added with a "Needs review" status and must be manually approved before they can install.

A driver update policy set to "Automatically approve all recommended driver updates" auto-approves only the recommended (latest OEM-required) driver versions. Every other applicable driver version is placed on the policy's "other drivers" list with a status of "Needs review," and an admin must explicitly approve those before Windows Update can install them. Automatic approval also applies a deferral period to the auto-approved recommended drivers. So it is expected that non-recommended drivers wait for manual approval even in an automatic policy.

Why the other options are wrong:

  • A. Driver update policies work alongside update rings; client install behavior such as restarts and notifications is still governed by Windows Update client/ring settings. A ring does not place drivers in "Needs review"; that status comes from the driver policy's approval model.
  • C. This is reversed. Recommended drivers are the ones auto-approved in an automatic policy; the non-recommended ("other") drivers are what require manual approval.
  • D. "Needs review" is a normal status for non-recommended drivers in an automatic policy and does not indicate the policy failed to save. Automatic approval does not install every available driver immediately.

Memory hook: Automatic approval = recommended drivers only. "Other" drivers still land in Needs review and wait for your click.

Microsoft Learn: https://learn.microsoft.com/intune/device-updates/windows/configure-driver-update-policy#create-windows-driver-update-policies

You are building a Conditional Access "Filter for devices" rule that must also apply to devices which were never registered in Microsoft Entra ID (for example, personal, unmanaged machines). Which statement correctly describes how Entra evaluates the filter and how you should write the rule so unregistered devices are included?

Correct answer: C. Entra evaluates filters using device authentication; for unregistered devices all device properties are null, so use a negative operator (for example device.extensionAttribute1 -ne "SAW") so the configured rule still applies.

Microsoft Entra uses device authentication to evaluate filter rules. A device that is unregistered does not exist in the directory, so all of its device properties are treated as null. A positive operator only matches devices that exist and match, so the recommended way to target unregistered devices is a negative operator - the configured filter rule then applies to them.

Why the other options are wrong:

  • A. Unregistered devices are not in the directory and have no trustType at all; Workplace denotes Microsoft Entra registered devices.
  • B. Filters can target unregistered devices via negative operators; Device state is deprecated and should not be reintroduced.
  • D. Entra evaluates device identity from the directory via device authentication, not by reading a TPM; positive operators match only existing directory objects.

Memory hook: Unregistered = null properties; negative operators still bite, positive operators miss.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/concept-condition-filters-for-devices

You deploy a Windows feature update policy in Intune to control the exact Windows 11 version on a group of devices. The same devices are also assigned an update ring whose Feature update deferral period is 60 days. Devices aren't upgrading on the schedule you expect. What should you change so the feature update policy governs the upgrade timing?

Correct answer: D. Set the update ring's Feature update deferral period to 0 days.

When a device is targeted by both a feature update policy and an update ring, Microsoft guidance is to set the ring's Feature update deferral period to 0 so ring deferrals don't delay the feature update the policy controls. Client-side behaviors (restart, deadlines, active hours) still come from the ring. The 60-day ring deferral is what's holding back the policy-driven upgrade.

Why the other options are wrong:

  • A. Feature update policies and update rings can coexist; you simply align the ring's feature deferral to 0.
  • B. Rollout options control the policy's own gradual timing, but the ring's 60-day deferral is the blocker; pausing the ring stops feature updates entirely.
  • C. Raising the deferral to 365 days makes the delay far worse.

Memory hook: Feature policy in charge? Zero out the ring's feature deferral.

Microsoft Learn: https://learn.microsoft.com/intune/device-updates/windows/manage-feature-updates#plan-feature-update-deployments

In an Intune Attack surface reduction endpoint security policy, one specific ASR rule (Block executable content from email client and webmail) generates false positives for a single line-of-business updater, while every other ASR rule works cleanly. You want to exclude that updater's file path from only that one rule, without weakening any other rule. Which setting do you use?

Correct answer: C. Add the path under ASR Only Per Rule Exclusions, which appears for the individual rule once it is set to a mode.

When an ASR rule is set to Audit, Block, or Warn, an ASR Only Per Rule Exclusions section appears for that individual setting, letting you scope an exclusion to that single rule. The global Attack surface reduction only exclusions list, by contrast, applies to every ASR rule on the device.

Why the other options are wrong:

  • A. An Allow IoC is matched by hash and applies globally rather than being scoped to one rule and path as required.
  • B. A Defender Antivirus folder exclusion removes the path from antivirus scanning; it is not scoped to a specific ASR rule.
  • D. The global Attack surface reduction only exclusions list applies to all ASR rules, which is broader than the single-rule scope required.

Memory hook: Per-rule exclusion appears only after you pick a mode.

Microsoft Learn: https://learn.microsoft.com/intune/device-configuration/endpoint-security/attack-surface-reduction#attack-surface-reduction-profiles

An organization wants to reduce internet bandwidth consumption when distributing Windows Update content to branch offices. Administrators want devices at each branch to share update content with each other over the local network. Which Intune setting addresses this requirement?

Correct answer: A. Configure Delivery Optimization download mode to allow peer-to-peer sharing on the local network

Delivery Optimization is a cloud-managed downloader that allows Windows devices to share update content with each other (peer-to-peer) in addition to downloading from internet sources. Configuring the download mode to share within the local network (LAN) allows branch devices to get content from peers behind the same NAT, significantly reducing external bandwidth usage for Windows Update, Microsoft 365 Apps updates, and other supported content types.

Why the other options are wrong:

  • B. Active hours restrictions control when Windows can restart after updates, not where the update content is downloaded from. They do not reduce bandwidth consumption.
  • C. Feature Update policies lock devices to a specific Windows version to prevent major OS upgrades. They do not address bandwidth consumption for update distribution.
  • D. The Enrollment Status Page controls the device setup experience during provisioning, not ongoing update bandwidth management.

Memory hook: Delivery Optimization = peer download. Devices share with each other so only one has to pull from the internet.

Microsoft Learn: https://learn.microsoft.com/en-us/windows/deployment/do/waas-delivery-optimization

Microsoft Entra registered devices (workplace-joined) are present in a tenant alongside Microsoft Entra joined and hybrid joined devices. An administrator wants to use Intune Feature Update policies, Quality Update policies, and Driver Update policies to manage all Windows devices. Which device join type is NOT supported by these update policy types that use the Windows Autopatch backend?

Correct answer: D. Microsoft Entra registered (workplace-joined) devices

Feature Update policies, Quality Update policies, and Driver Update policies in Intune are orchestrated by Windows Autopatch. Microsoft's documentation explicitly states that Microsoft Entra registered devices (workplace-joined, also known as WPJ) are not supported for any policy type that uses the Windows Autopatch backend. For these devices, update management is limited to Windows Update client policies and Update ring policies only.

Why the other options are wrong:

  • A. Devices enrolled via Windows Autopilot user-driven mode are typically Microsoft Entra joined or hybrid joined. The join type, not the enrollment method, determines Autopatch eligibility.
  • B. Microsoft Entra hybrid joined devices meet the prerequisites for Windows Autopatch-based update policies and are supported for all three update policy types.
  • C. Microsoft Entra joined devices are fully supported for Feature Update, Quality Update, and Driver Update policies through the Windows Autopatch backend.

Memory hook: WPJ (registered only, no join) = no Autopatch policies. Joined devices (Entra or hybrid) = full update policy support.

Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/protect/windows-update-for-business-configure

A legacy Conditional Access policy uses the "Device state" condition to exclude Microsoft Entra hybrid joined and compliant devices. Microsoft flags this condition as deprecated. Which condition replaces it, and how do you express "hybrid joined" and "compliant"?

Correct answer: C. Use "Filter for devices" with the trustType and isCompliant properties (for example device.trustType -eq "ServerAD" and device.isCompliant -eq "True").

The Device state condition is deprecated in favor of Filter for devices, which supports the system-defined properties trustType and isCompliant. trustType "ServerAD" denotes a Microsoft Entra hybrid joined device, and isCompliant "True" denotes a compliant device, so the filter reproduces the old logic with more granularity.

Why the other options are wrong:

  • A. Device state and Filter for devices cannot be used together, and Device state is deprecated.
  • B. Device platforms filters by operating system, not by join state or compliance status.
  • D. trustType and isCompliant are built-in system-defined filter properties; you do not need extensionAttributes for join state or compliance.

Memory hook: Device state is dead - Filter for devices: trustType=ServerAD is hybrid, isCompliant=True is compliant.

Microsoft Learn: https://learn.microsoft.com/entra/identity/conditional-access/concept-conditional-access-conditions

You want standard users to be able to run a specific administrative tool elevated, but only after an Intune administrator reviews and approves each individual request. Which Endpoint Privilege Management elevation type meets this requirement?

Correct answer: D. Support approved

The Support approved elevation type requires an Intune admin who holds the extra approval permission to approve each submitted elevation request before the user can run the file elevated.

Why the other options are wrong:

  • A. User confirmed only requires the user to acknowledge (optionally justify or authenticate); no admin approval is involved.
  • B. Elevate as current user runs under the user's own account after authentication, with no admin approval.
  • C. Automatic elevates silently with no prompt and no approval step.

Memory hook: Support approved = admin signs off on each request.

Microsoft Learn: https://learn.microsoft.com/intune/epm/manage-support-approvals

You need to turn on tamper protection for your Intune-managed Windows devices using an endpoint security Antivirus policy. Which profile contains the Tamper protection setting?

Correct answer: C. Windows Security experience

In Intune, tamper protection is configured in an Antivirus policy using the Windows platform and the 'Windows Security experience' profile, where you set Tamper protection (device) to On in the Defender section.

Why the other options are wrong:

  • A. The Microsoft Defender Antivirus profile configures scanning, real-time protection, and cloud settings, not the tamper protection toggle.
  • B. The exclusions profile defines paths and processes to exclude from scanning; it doesn't contain tamper protection.
  • D. Defender Update controls manage security intelligence and platform update behavior, not tamper protection.

Memory hook: Tamper protection = Antivirus policy, then the Windows Security experience profile.

Microsoft Learn: https://learn.microsoft.com/defender-endpoint/manage-tamper-protection-intune