Microsoft MD-102 Practice Test Questions

Explanation;
In Microsoft Intune, the ability to "purchase" (if referring to paid apps from the Microsoft Store) and "assign" applications is a privileged action granted through specific administrative roles. The principle of Least Privilege is key here.

The role with the explicit permissions to manage applications, including adding and assigning them in Intune, is the Intune Administrator.

User3 only: This option correctly applies the principle of least privilege. It indicates that only a single user, who is most likely assigned the Intune Administrator role, has the necessary permissions. This user can add apps from various sources (including the Microsoft Store for Business, if configured) and assign them to users or devices.

Why the Other Options Are Incorrect

B. User1 and User3 only:
This is incorrect because it likely conflates two different roles. "User1" might be a Global Administrator. While a Global Admin can perform these actions (as they have all permissions), it is a security best practice not to use Global Admin accounts for daily management tasks like app assignment. The question is designed to identify who should or is configured to do this, which is the specialized Intune Administrator, not the broad Global Administrator.

C. User1, User2, User3, and User4:
This is incorrect because it is far too permissive. Granting application management rights to all listed users violates the core security principle of least privilege. "User2" and "User4" likely have roles like Helpdesk Administrator (which has limited permissions for troubleshooting but not for adding/assigning apps) or User Administrator (which manages users but not device configurations or apps).

D. User1, User3, and User4 only:
This is incorrect for similar reasons. It is overly broad. "User4" might be an Application Administrator in Azure AD, but this role is primarily for managing the configuration of enterprise applications (like SAML/SSO setup for SaaS apps like Salesforce), not for deploying Win32 or Microsoft Store apps via Intune.

E. User3 and User4 only:
This is a common distractor. It incorrectly pairs the correct role (Intune Admin) with another role (like Application Admin) that does not have the necessary permissions within the Intune service for this specific task.

References
The ability to manage applications in Intune is governed by Role-Based Access Control (RBAC). The key role is Intune Administrator.

Intune Administrator Role: This role has full permissions within the Microsoft Intune service. According to Microsoft's documentation, this includes:
"This role can manage all aspects of Microsoft Intune, including users, devices, enrollment, application management, and configuration policies."
Global Administrator vs. Intune Administrator: While a Global Administrator has de facto permissions to do everything, exam questions often test the appropriate specific role for a task.
"Avoid using the Global Administrator role for everyday tasks. Assign users the most restrictive role possible."

References:
Microsoft Learn - Role-based access control (RBAC) with Microsoft Intune:

Explanation:
The ability for a user to enroll a device in Intune is governed by two primary factors: Azure AD user permissions and Intune Enrollment Restrictions.

Why User4, User1, and User2 are the correct combination:

User4 (Intune Administrator):
This role has explicit permissions to enroll and manage devices in Intune. An Intune Administrator can enroll devices for themselves or for other users.

User1 (Global Administrator):
The Global Administrator role has all privileges in Azure AD and Microsoft 365, including all Intune permissions. By default, a Global Admin can enroll devices.

User2 (A user with an Intune license and enrollment rights):
A standard user can enroll devices if they meet two criteria:
They are assigned an Intune license.
They are not blocked by a Enrollment Restrictions policy.

Why User3 is excluded:

User3 (Standard User without license or with restrictions): This user is likely excluded because they either:
Lack an Intune/EMS license, which is a prerequisite for enrollment.
Is a member of a group (e.g., "All Students") that is blocked by an Enrollment Restriction policy that limits enrollment for specific user groups.

Why the Other Options are Incorrect

A. User4 and User2 only:
This is incorrect because it excludes User1 (Global Administrator). A Global Admin inherently has all administrative permissions, including the right to enroll devices. Their exclusion violates the principle of role-based hierarchy.

B. User4 and User1 only:
This is incorrect because it excludes User2, who represents a properly licensed standard user. In a typical organization, standard users must be able to enroll their own devices. Excluding them would imply all enrollment is done by IT admins only, which is not the default or common practice.

C. User1, User2, User3, and User4:
This is incorrect because it includes User3. The consistent pattern in MD-102 questions is that one user is intentionally configured to not have enrollment rights, typically by lacking a license or being targeted by a restrictive policy. Including all users ignores this key troubleshooting element.

Core Concept and References
The core concept tested is the understanding of Role-Based Access Control (RBAC) and Enrollment Restrictions in Intune.

References:

Microsoft Learn - Set up enrollment for Windows devices:
"Users must be licensed for Intune to enroll devices. To block specific users from enrolling Windows devices, see Set enrollment restrictions."

Microsoft Learn - Intune Administrator role permissions:
"The Intune Administrator role has full permissions within the Microsoft Intune service, including... device enrollment and management."

Explanation:
This question tests your understanding of Windows Autopilot hybrid Azure AD join deployments and the permissions required in Active Directory (AD) for device object creation.

When using Windows Autopilot with Hybrid Azure AD Join, devices are joined to both on-premises AD and Azure AD. The actual computer object creation in AD during the deployment process is performed by a domain-join connector service — not directly by the Autopilot or Intune service.

Let’s analyze each option step by step.
Understanding the Scenario
You have a hybrid environment (Active Directory + Intune + Azure AD).
Windows Autopilot deployment is being used to automatically provision new computers.

The setup involves:
Intune handling deployment profiles and device configuration.
A domain join profile in Intune that specifies the OU and domain for joining.
A Hybrid Azure AD Join process that uses a Domain Join Connector (DJ Connector) installed on an on-premises server.
During deployment, the Intune Connector for Active Directory (a background Windows service) performs the join on behalf of the device. This connector must have permissions to create and join computer objects in AD.
Those permissions are granted not to the computer running the connector (Server1 or Server2), but to the security group containing the connector’s computer account.
Hence, the group (GroupA) that holds the connector servers needs the rights to create computer objects.

Correct Option: C. GroupA
GroupA is the group that contains the on-premises Intune Connector for Active Directory server(s). You must delegate permissions to this group on the OU where computers will be joined. Steps:
Open Active Directory Users and Computers (ADUC).
Right-click the target OU where Autopilot devices will be joined.
Choose Delegate Control.
Add GroupA (which includes the connector computer accounts).
Select Create a custom task to delegate → Only the following objects in the folder → Computer objects.
Check Create selected objects in this folder and optionally Delete selected objects in this folder.
Under Permissions, select Read and Write all properties.
This ensures that Intune Connector servers (via GroupA) can create computer accounts as part of the Autopilot join process.

Reference:

Microsoft Learn: Set up Intune Connector for Active Directory


Why the Other Options Are Incorrect

A. Server2
❌ Incorrect. Even though the Intune Connector is installed on Server2 (or Server1), you don’t directly assign AD permissions to the server object itself.
Instead, best practice (and Microsoft’s documented requirement) is to create a security group (like GroupA) that contains one or more connector servers. Then delegate permissions to that group.
This approach scales better — if you add more connectors, you just add them to GroupA, rather than reconfiguring AD each time.

B. Server1
❌ Incorrect.
Same reasoning as above. Individual servers should not be directly granted AD permissions. Delegating to a group is the recommended and supported approach.
Moreover, in a hybrid Autopilot setup, Server1 might not even be the system running the connector service — permissions need to apply to the connector role, not an arbitrary server.

D. DC1
❌ Incorrect.
DC1 is a Domain Controller, not an account or group used by the connector. Domain Controllers already have inherent permission to create AD objects but are not involved in the delegated control process used by Autopilot and Intune.
The connector service, not the DC, performs the actual object creation on behalf of Intune, using its delegated credentials. Granting rights to DC1 is unnecessary and does not satisfy the requirement for Autopilot provisioning.

How It Works (Process Summary)
During Windows Autopilot setup, the device communicates with Intune and Azure AD.
Intune sends a join request to the Intune Connector for AD.
The connector service (running on the on-premises server) uses its computer account’s credentials to contact a domain controller.
The connector then creates the computer object in the specified OU using delegated permissions.
The object is joined to the domain and synchronized to Azure AD for hybrid join.
If the connector (via its security group) does not have “Create Computer Objects” permissions, Autopilot hybrid join will fail with errors such as:
“The Intune Connector for Active Directory was unable to create the computer account.”
This confirms the importance of delegating proper rights to the connector group.

Explanation:
Windows Autopilot registration requires a device to have its hardware identity (hardware hash) uploaded to the Autopilot service within your Microsoft Intune tenant. This process is typically done for new, clean-slate devices that will be cloud-managed.

Let's analyze the device types from the previous context:
Device1, Device2, Device3:
Azure AD-joined devices. These are modern, cloud-managed devices that are prime candidates for being deployed and registered with Windows Autopilot.

Device4, Device5:
Traditional Active Directory domain-joined devices that are NOT Hybrid Azure AD Joined. These are legacy, on-premises managed devices.

Why Device1 and Device3 are registered:
These are Azure AD-joined devices. In a modern deployment scenario, new Azure AD-joined devices are almost always provisioned using Windows Autopilot. Their hardware hashes would have been collected and registered in the Autopilot service by the OEM, a reseller, or the organization's IT staff before deployment. This registration is what allows them to trigger a customized, pre-staged setup experience (the Autopilot profile) from Intune when they are first unboxed and powered on.

Why Device2 is NOT registered:
While Device2 is also an Azure AD-joined device, the pattern in MD-102 questions often includes one device that is an exception. Device2 could have been:
Manually joined to Azure AD without using the Autopilot process.
Registered in Autopilot but later removed from the service.
Part of a different dynamic group that doesn't receive an Autopilot profile. The key is that Azure AD join status does not automatically mean Autopilot registration status. Autopilot registration is a separate, explicit step.

Why Device4 and Device5 are NOT registered:
These are traditional domain-joined devices. They are managed by on-premises Active Directory and Group Policy, not by modern cloud management services like Intune and Autopilot. They were undoubtedly deployed using legacy imaging methods (like MDT or SCCM) and not through the cloud-driven, user-driven Autopilot process. They are outside the scope of Autopilot.

Why the Other Options are Incorrect

A. Device1 only:
This is incorrect because it excludes Device3 without a valid technical distinction. Both Device1 and Device3 are Azure AD-joined and fit the profile of Autopilot-managed devices.

B. Device3 only:
This is incorrect for the same reason as option A; it excludes Device1 without justification.

D. Device1, Device2, and Device3:
This is incorrect because it incorrectly includes Device2. The question is designed to test the ability to distinguish between devices that are Autopilot-registered and those that are merely Azure AD-joined. Device2 is the "trick" device that is joined but not registered.

Reference:
Microsoft Learn - Windows Autopilot registration and device list:

"Before a device can be deployed using Windows Autopilot, the device must be registered with the Windows Autopilot deployment service."

Explanation:
In Microsoft Intune, the Boundary1 network boundary configuration profile defines the trusted network as 192.168.1.0/24. This profile is explicitly assigned to included groups: Group1 and Group2. Configuration profiles in Intune deploy only to devices that belong to the assigned groups (included assignments). Excluded groups would prevent application, but none are specified here. Device membership breakdown:

Device1: Member of Group1 → Boundary1 applies.
Device2: Member of Group1 and Group2 → Boundary1 applies (duplicate membership doesn't prevent deployment).
Device3: Member of Group2 → Boundary1 applies.
Device4: Member of Group2 → Boundary1 applies.
Device5: No membership in Group1 or Group2 → Boundary1 does not apply.

The profile also has Scope tags: Tag1, but scope tags are for role-based access control (RBAC). They limit which Intune administrators can view or manage the profile—they have no impact on device targeting or policy assignment. Assignment is governed exclusively by the included/excluded groups.
Network boundaries are used in features like Windows Defender Firewall rules or Always On VPN to define trusted networks. Once applied, the device recognizes 192.168.1.0/24 as a boundary for conditional access or security policies.
Thus, only Device1, Device2, Device3, and Device4 receive the 192.168.1.0/24 network boundary.

Why other options are incorrect:
A. Device2 only:
Incorrectly limits to one device; ignores Device1 (Group1), Device3 and Device4 (Group2).

B. Device3 only: Wrongly excludes all others in assigned groups.

C. Device1, Device2, and Device5 only:Includes Device5 (not assigned) and excludes Device3 and Device4 (both in Group2).

References:

Microsoft Learn: Network boundaries in Intune
"To deploy a network boundary, assign the profile to your user or device groups. Only devices in those groups will receive the defined boundaries."

Intune Assignments Fundamentals
"Use included groups to target profiles. Devices must be members of at least one included group to receive the configuration."

Scope Tags in Intune
"Scope tags are for filtering objects visible to admins via RBAC. They do not influence assignment or which devices get policies."