MD-102 - Manage and Maintain Devices (28% of the exam) - Section 2.2

Plan and implement device configuration profiles for Windows, Android, Apple and specialty devices.

Create device configuration profiles for Windows, including imported ADMX templates and Group Policy analytics, and for Android, iOS, iPadOS, macOS and specialty devices such as Teams Rooms, HoloLens 2 and Zebra. Target profiles precisely by using assignment filters and enrollment time grouping.

settings catalogADMX importGroup Policy analyticsassignment filtersenrollment time groupingspecialty devices

Practice question for this objective

Free sampleManage and Maintain Devicesmedium

A Windows Autopilot device preparation policy is planned so that a set of applications and configuration profiles reaches a new device while it is still being provisioned. The policy names a Microsoft Entra security group for enrollment time grouping. What does naming that group achieve?

AIt builds a dynamic device group whose membership rule matches the Autopilot group tag recorded for the device, so the device is picked up the next time that rule is evaluated across the tenant.
BIt gives the person signing in membership of the named group for the length of provisioning, so the policies assigned to that group as user targeted settings apply before the desktop is handed over.
CIt takes the place of the status page shown during provisioning, so the device is held at that stage until the apps assigned to the named group have reported an installed state back to Intune.
DIt adds the device to the named group as part of enrolment, so the apps and policies assigned to that group are targeted at the device during provisioning rather than after membership catches up later. Correct

Enrollment time grouping puts the device into a named security group during enrolment so device targeted apps and policies apply while provisioning is still running. Targeting anything at a brand new device depends on the device object being a member of a group that carries the assignment, and membership that is worked out after the fact arrives too late to be installed during provisioning. Enrollment time grouping closes that window by adding the device to the security group named in the device preparation policy as part of enrolment itself, so Intune already sees the device as in scope for everything assigned to that group when it reaches the provisioning stage. The group is a specific assigned group named in the policy, which is why no membership rule has to run first.

Why A is wrong: Tempting because group tags and dynamic rules are the older way of sorting Autopilot devices, but waiting for a rule to be evaluated is the delay this feature exists to remove, and the group named here is an assigned one.

Why B is wrong: Tempting because provisioning does end with a user signing in, but the grouping acts on the device object rather than the user, and no temporary membership is granted to an account.

Why C is wrong: Tempting because blocking on app installation is genuinely part of the provisioning experience, but that behaviour is configured separately, and the grouping decides only what is targeted at the device.

Why D is correct: Correct. Intune places the device in the named group while enrolment is running, which makes anything assigned to that group applicable to the device in time for the provisioning stage to install and apply it.

See more MD-102 practice questions, answers explained.

Exam traps in Manage and Maintain Devices

Answers that look right on this material and are not. Each one is a distractor from a different question in the MD-102 bank for this domain.

Register the hardware identity of each laptop with the Windows Autopilot service before it is issued, because a device preparation policy is matched to a device by the hardware identity held by the service in the same way as a deployment profile.
Why it is wrong: Hardware identity registration is the familiar prerequisite for classic Autopilot, so carrying it across is a natural mistake. It is wrong because device preparation deliberately removes that step: the device is identified at the moment it enrols rather than from a registration uploaded in advance.
It applies the settings held in the uploaded object to the Microsoft Entra joined devices in the tenant, so the domain policy keeps taking effect after those devices stop contacting a domain controller.
Why it is wrong: Tempting because the point of the exercise is usually to keep a working configuration alive after a move to cloud management, but analytics only reads the uploaded file and changes nothing on any device.
The definition files are copied into the local policy definitions folder on each enrolled device, so an administrator signed in to the device can set the values in the Local Group Policy Editor.
Why it is wrong: Tempting because ADMX files are normally read by a policy editor, but the import serves the Intune console rather than the local editor, and the settings are delivered as managed policy instead of being left for someone to set by hand.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.