Microsoft 365 Endpoint Administrator Associate Practice Test (MD-102)

Device enrollment platform restrictions let you block enrollment of personally owned devices on a per-platform basis. By creating a restriction that blocks the "Personally owned" category for Windows (MDM) and assigning it to the relevant user group, users can still enroll corporate-owned Windows devices, and enrollments for Android and iOS remain unaffected. The other options either do not exist in Intune or would not selectively block only personal Windows devices.

Azure AD join (now called Microsoft Entra join) is designed for corporate-owned Windows devices that are not required to be domain-joined. During the out-of-box experience the device can join Microsoft Entra ID directly and, if automatic MDM enrollment is configured, it is simultaneously enrolled in Intune. Azure AD-joined devices fully support Windows Hello for Business and do not need persistent connectivity to an on-premises Active Directory.

Azure AD registration suits personally owned (BYOD) devices because only the user identity, not the device, is joined. Hybrid Azure AD join still relies on domain join and therefore requires network access to a domain controller during provisioning. A traditional on-premises domain join combined with Intune enrollment likewise mandates domain controller connectivity, which the branch office lacks.

The maximum number of devices that a user can enroll is controlled by the Enrollment device limit restrictions policy found under Devices > Enroll devices > Enrollment device limit restrictions. Editing (or creating) this policy and setting the limit to five enforces the per-user ceiling. Platform-based restriction policies, automatic enrollment settings in Microsoft Entra ID, or compliance policies do not cap the number of devices a user may bring under management.

In Windows Autopilot self-deploying mode, the device performs a Microsoft Entra (Azure AD) join and is automatically enrolled in Intune without any user sign-in. Because no user account is involved, the device is not Microsoft Entra registered, and because it never contacts an on-premises domain controller it cannot be hybrid joined or domain-joined. Therefore, the resulting identity state is Microsoft Entra joined.

Hybrid Microsoft Entra join extends an already domain-joined Windows device into Microsoft Entra ID. The computer account remains in Active Directory, so existing Group Policy continues to apply, while the device also registers in Entra ID to provide cloud authentication and enable Intune compliance evaluation or MDM enrollment. A pure Microsoft Entra join requires the device to leave the on-prem domain, eliminating Group Policy processing. Microsoft Entra registration is intended for personal or workgroup-joined devices and does not give full device identity needed for SSO and compliance. Enrolling Configuration Manager co-management without a hybrid join does not itself create an Entra ID device identity, so it cannot satisfy the requirement for cloud SSO and conditional access.

Windows LAPS stores the local administrator password on the Microsoft Entra device object when the backup directory is set to Azure AD. The ability to read that password requires the microsoft.directory/deviceLocalCredentials/password/read permission. Of the default roles, Cloud Device Administrator and Intune Administrator include this action, but Cloud Device Administrator is the more narrowly scoped, device-focused role. Assigning this role lets technicians retrieve LAPS passwords without the wide-ranging permissions of Intune Administrator or Global Administrator. Security Reader lacks the required permission, so it cannot show the passwords.

The technician must be assigned an Azure AD role that grants permission to read the per-device password property that LAPS writes to Microsoft Entra ID. The purpose-built Local administrator password reader role provides exactly this permission and nothing more. Adding the role takes immediate effect and does not require a new password rotation on the device. Roles such as Intune Help Desk Operator lack the necessary directory permission, while forcing a rotation or recreating the profile will not change the technician's authorization to read the existing secret.

Azure AD join (now called Microsoft Entra join) is intended for organization-owned Windows devices when no on-premises Active Directory exists. It requires users to sign in with their Microsoft Entra ID accounts and, when automatic MDM enrollment is configured in Microsoft Entra ID, the join process can enroll the devices into Intune for management.

Azure AD registered targets personally owned (BYOD) devices where the primary sign-in is a local or personal Microsoft account, so it does not satisfy the requirement to restrict sign-in to corporate Entra ID accounts.

Hybrid Azure AD join relies on on-premises Active Directory domain-joined computers synchronizing to Entra ID; because the organization lacks an on-premises AD, it is not applicable.

Workgroup membership with only MDM enrollment would allow Intune management, but users would still sign in locally and not exclusively with Entra ID credentials, so it does not meet the single sign-on requirement.

The Grant control "Require device to be marked as compliant" checks the device state supplied by Intune. If the device is compliant, access is allowed; if the device is not compliant, access is denied. None of the other grant controls evaluate Intune compliance. "Require multi-factor authentication" enforces MFA but ignores compliance. "Require hybrid Azure AD joined device" validates join state, not compliance. "Require password change" forces a credential reset but likewise does not use compliance information.

The classic line-of-business (LOB) MSI app type only allows a single MSI file and cannot accept additional files such as .mst transforms. By first running IntuneWinAppUtil.exe, you can wrap the MSI and the transform into a single .intunewin file. That package is then imported by choosing the Windows app (Win32) app type, which supports multiple installation files, custom command-line parameters, and larger package sizes. Store, web link, and LOB app types do not meet the requirement to include the transform file.

Filters let you refine an assignment to a subset of devices in the target group. Creating a filter with a rule such as (device.deviceModel -contains "Surface" and device.deviceOSVersion -ge "10.0.22000") and choosing the Include mode causes the profile to apply only to devices that match those properties. Dynamic groups or scope tags would require changing the assignment or rely on separate administration steps, and using the Exclude mode would remove Surface devices instead of targeting them.

Using the %RAND:x% variable lets Intune append a random alphanumeric string whose exact length is defined by the value of x. A prefix of EMP- is four characters long, so specifying %RAND:5% produces names that are 4 (prefix) + 5 (random string) = 9 characters, well under the 15-character limit and meeting the requirement for a five-character suffix. The plain %RAND% variable defaults to six characters, which would not meet the exact-length requirement. %SERIAL% substitutes the full hardware serial number, which can easily push the name past 15 characters. %RAND:12% would exceed the limit because the total length would be 4 + 12 = 16 characters.

The Replace action overwrites the membership of the specified local group with the principals you define. When the policy is applied, any existing members that are not listed in the policy are removed and only the listed members remain. Add (Update) merely appends new members while keeping existing ones. Remove deletes only the accounts you specify but leaves any others intact. Sequencing an Add followed by a Remove would still leave accounts that were never targeted for removal. Therefore, configuring the Replace action meets the requirement that only the built-in Administrator and the HelpdeskAdmins group remain members of the local Administrators group.

Zero-touch enrollment for Android Enterprise dedicated devices is designed for large-scale, hands-off deployments. In Intune you create a zero-touch configuration that generates a provisioning JSON file containing the enrollment token and DPC extras. This JSON is uploaded to the Google Zero-touch portal and assigned to the hardware so that, when each device is first powered on, it automatically contacts Google, receives the configuration, and enrolls in Intune as a dedicated device. A QR code deployment (option using a QR code) still requires a technician to scan the code on every device. Device administrator enrollment is legacy and discouraged for new deployments. Apple Automated Device Enrollment applies only to iOS and macOS devices, not Android.

Help Desk Operator is designed for front-line support staff. The role grants remote device actions such as wipe, retire, sync, remote lock, passcode reset, and rename, but does not include permissions to create, update, or delete policies or profiles. Policy and Profile Manager and Endpoint Security Manager allow policy modifications, and Read Only Operator cannot perform remote actions.

Because Contoso does not have AD CS and wants the fastest deployment path, they should use the cloud Kerberos trust model. Cloud Kerberos trust lets hybrid-joined devices authenticate to on-premises resources by retrieving a Kerberos ticket from a Windows Server 2016 (or later) domain controller after the user signs in with the Windows Hello for Business key that Azure AD validates. Certificate trust requires an AD CS public key infrastructure, and key trust needs a certificate registration authority, making both unsuitable given the constraints. Virtual smart cards are a different credential technology and are not a Windows Hello for Business trust model.

The grace period before a device is marked non-compliant is configured in the compliance policy itself. In the compliance policy wizard (or policy Properties), select Actions for noncompliance, add the action Mark device noncompliant, and set the schedule to five days. Evaluation frequency, Conditional Access settings, and device restriction profiles do not provide a per-policy grace-period timer, so they cannot deliver the required five-day remediation window.

Azure AD join is designed for organization-owned Windows devices when no on-premises Active Directory infrastructure is required. Devices join directly to Microsoft Entra ID, receive an Azure AD primary refresh token, and support SSO to Microsoft 365 cloud resources both on and off the corporate network. They can also be automatically enrolled into Intune for management.

Azure AD registered devices are primarily personal or BYOD scenarios and do not provide an Azure AD primary sign-in, so they lack seamless SSO for desktop sign-on. Hybrid Azure AD join requires the devices to be first joined to an on-premises AD domain, which the remote office will not have. Simply joining the devices to a local AD domain and then enrolling into Intune likewise depends on on-premises AD and therefore does not meet the stated constraints.

The Help Desk Operator role is designed for front-line support staff. It grants read-only access to device and user objects and allows a limited set of remote actions, including Remote lock and Passcode reset. It does not permit wiping, retiring, or deleting devices, nor does it provide permission to create or modify policies. Read-Only Operator cannot perform any remote actions, while Policy and Profile Manager and Endpoint Security Manager both allow creation or modification of policies, exceeding the required scope.

In a cloud-only environment, Windows Hello for Business uses key trust on Microsoft Entra-joined devices. The key pair created during provisioning is registered with Microsoft Entra ID, allowing the user to authenticate with the private key without relying on on-premises domain controllers or a certificate authority.

Certificate trust requires Active Directory Certificate Services, and cloud (Kerberos) trust requires hybrid identity with Windows Server domain controllers, so neither fits the scenario. Devices that are only Entra ID-registered are not eligible for Windows Hello for Business deployment.