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

The Conditional Access grant control "Require app protection policy" allows access only from iOS and Android client apps that have an Intune app protection (MAM) policy assigned to the user. When this control is selected, sign-in attempts from apps without the required policy are blocked, preventing unmanaged copies of Outlook from connecting. "Require approved client app" merely checks that the app is on the approved list but does not verify that a protection policy applies. "Require device to be marked as compliant" applies to device-based MDM compliance, which the scenario does not mandate. Multifactor authentication increases sign-in security but does not enforce the presence of the Intune protection policy.

When multiple Windows update policies apply to the same device, Intune follows a fixed precedence order. An Expedite update policy has the highest precedence, followed by a Feature update policy, and lastly settings in a Windows Update ring. Because the Feature update policy ranks higher than the deferral settings in the Update ring, the device will ignore the 90-day deferral and upgrade to the version specified in the Feature update policy (Windows 11 22H2). There is no policy conflict error, and quality updates continue to install as usual after the upgrade.

Create a configuration profile that uses the Settings catalog. In the profile, configure the imported ADMX settings, assign the profile to the existing Azure AD group, and add an Include filter that targets devices whose operatingSystemVersion is greater than or equal to 10.0.22000. Because Windows 10 builds are lower than 22000, they are excluded automatically, and future Windows 11 builds continue to match the rule. The other options either use the wrong profile type, rely on manual OMA-URI entries, or require changing group membership, none of which is necessary.

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.

After the MDE connector is enabled, Intune can automatically onboard Windows 10/11 devices by deploying an Endpoint detection and response (EDR) configuration profile. Creating and assigning this profile pushes the built-in MDE onboarding policy through the MDM channel, requiring no scripts, packaging, or user prompts. Packaging the onboarding script as a Win32 app or running it through a PowerShell script would work but adds unnecessary steps. A settings catalog profile that only changes unrelated Defender settings or enabling Device Health Attestation does not perform the onboarding action.

Choosing Apps > Catalog and then Add app from catalog launches the Enterprise App Catalog workflow, which contains a curated list of roughly 450 pre-packaged Win32 applications, including 7-Zip. When you add an app from the catalog, Intune imports predefined install and detection settings so you do not need to supply your own package or rules. Although the Enterprise App Management license surfaces new versions in the Updates for Windows (Win32) catalog apps blade, administrators still decide when to add updated versions. The Windows app (Win32), Microsoft Store app (new), and Line-of-business workflows all require either custom packaging or are limited to Store offerings, therefore involve more manual effort in this scenario.

For automatic onboarding, the Defender for Endpoint connection has to be enabled in both services. Turning on the Microsoft Intune connection in the Microsoft 365 Defender portal completes only half of the integration. You must also enable the Microsoft Defender for Endpoint connector in the Intune admin center (Tenant administration > Connectors and tokens > Microsoft Defender for Endpoint). When that connector is set to On and saved, enrolled Windows 10/11 devices automatically onboard to Microsoft Defender for Endpoint. Deploying security baselines, changing telemetry, or installing the legacy Microsoft Monitoring Agent are not prerequisites for this integration and will not by themselves trigger device onboarding.

The Feature update deferral period (days) setting controls how long Windows waits before offering a new feature update. Setting it to 120 postpones feature updates for four months. Leaving Quality update deferral period (days) at 0 lets quality updates download as soon as they are released. The Deadline for quality updates (days) forces installation to complete within a specified number of days-setting it to 3 satisfies the three-day requirement. Enabling Auto reboot before deadline allows Windows to restart automatically outside active hours once the deadline is reached, guaranteeing that the update cycle completes even if users postpone the restart. The other answer choices either defer quality updates, give users control over restarts, or omit the automatic-restart requirement and therefore do not fulfil all stated goals.

When the third-party antivirus product is installed, Microsoft Defender Antivirus must stop active protection yet continue to act as the EDR sensor for Microsoft Defender for Endpoint. This behavior is achieved by enabling Passive mode in a Microsoft Defender Antivirus profile. In passive mode, the Defender engine turns off real-time, scheduled, and on-demand scanning, avoiding conflicts with another antivirus solution, but it still sends telemetry to Defender for Endpoint. Disabling real-time protection or turning off Microsoft Defender Antivirus would either violate platform protection requirements or completely remove the EDR sensor. Periodic scanning keeps Defender active and would cause two engines to run side by side rather than disabling one of them.

Set "Block device use until all apps and profiles are installed" to Yes. This option holds the device at the ESP screen during setup and prevents access to the Windows desktop until Intune has finished installing all Required apps and configuration profiles assigned to the user or the device. The other options do not enforce this block: showing installation progress is cosmetic only, allowing users to reset the device offers a recovery path after failures, and merely targeting the ESP profile to All Devices does not impose any blocking behavior by itself.

In an Endpoint security Antivirus policy for Windows 10 and later, the setting that controls whether users can turn off Microsoft Defender Antivirus real-time protection is Allow users to pause real-time protection. Setting this value to Disabled (sometimes shown as No) keeps real-time protection enabled and prevents all local users, including administrators, from pausing or turning it off. The other options are incorrect:

• Turning on the setting Turn off real-time protection disables the feature completely, which does not meet the requirement.
• Enable intrusion prevention system is an unrelated setting found in firewall, not antivirus, policies.
• Blocking user interface access removes the Microsoft Defender UI but does not stop a local administrator from disabling the service through PowerShell or other tools.

Pre-provisioned deployment (previously called White Glove) lets an IT technician complete device setup, app installation, and policy assignment before the computer is delivered. The device is then resealed so that the end user experiences only a brief sign-in during OOBE. Self-deploying mode is intended for kiosk-style devices with no user sign-in. The two user-driven modes require the full OOBE and install configuration after the user first powers on the device, which does not satisfy the requirement for advance staging.

When the Intune connector for Microsoft Defender for Endpoint is enabled, Windows clients can be onboarded by assigning an Endpoint security "Endpoint detection and response" (EDR) profile. The EDR profile delivers the onboarding configuration through the MDM channel and continues to apply to any future devices in the targeted groups. Running a standalone PowerShell onboarding script or deploying the Microsoft Monitoring Agent are alternative onboarding methods when Intune is not used. A settings catalog profile that only enables MDE-Management does not perform the initial onboarding.

During the device-setup phase of the Enrollment Status Page, Intune installs only apps that run in the system context and that are required for the device or a device-based group. Assigning the Win32 package to a device group that contains the Autopilot devices and choosing the System install behavior ensures the app is processed before the user sign-in screen appears. Apps set to User context or made merely Available are installed later in the user phase or only when the user requests them, so they are not tracked in the device-setup stage.

Android Enterprise dedicated device enrollment is designed for corporate-owned devices that serve a single purpose, such as kiosks or room-scheduling panels. Enrollment is performed with an Intune-generated token delivered through methods like QR code, NFC, or manual entry, rather than by importing hardware identifiers. Dedicated device enrollment automatically locks down system UI access and can block personal Google accounts, meeting all stated requirements. Fully managed enrollment gives each user full device control, corporate-owned work profile maintains a separate personal profile, and personally-owned work profile is BYOD-focused and user-initiated, so none of those meet the scenario.

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.

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 Windows 10 and later feature update failures report is designed to help administrators troubleshoot feature update deployments. It lists each device that did not complete the installation and shows the returned Windows Update error code, allowing you to investigate root causes. The general feature updates report only shows high-level deployment state without per-device error codes. Quality update failures is limited to cumulative (quality) updates, not feature updates, while the update ring deployment status surfaces whether devices are up-to-date or pending but does not expose the detailed error information required.

When you create a Microsoft Tunnel site in Intune, the admin center generates a unique site token. The token is required only once, during initial server registration, and it binds the Tunnel gateway instance to the designated site. The installation script includes a parameter where you paste this token. Supplying the public IP, address pool, or DNS suffix is part of server or VPN configuration but is not required for the registration step, so those choices are incorrect.

The Grace period (days) for auto-restart setting defines how many additional days users have after the quality-update deadline passes before Windows forces a restart. Adjusting this setting to five days provides the requested additional time. Deferral periods determine when the update is offered, notification settings control user prompts, and the maintenance time option only specifies when restarts occur, not how long they are postponed.