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

Setting the rule state to Audit allows Microsoft Defender to generate event ID 1121 when a process attempts to read LSASS memory, but it does not stop or modify the process. Block would immediately prevent the action, Disable (or Not configured) turns the rule off and records no events, and Warn silently blocks actions and can still interfere with workflows. Therefore, Audit is the correct choice when you need to measure potential impact without enforcement.

To load third-party ADMX templates by using the ADMXInstall configuration service provider (CSP), you start with a Custom profile for Windows 10 and later. Inside the profile you add a String OMA-URI setting whose path begins with ./Vendor/MSFT/Policy/ConfigOperations/ADMXInstall and whose value is the Base64-encoded content of the ADMX (and corresponding ADML) file. After the template is ingested you can create additional OMA-URI entries or use Administrative Templates to configure the Chrome policies. Device restrictions and Settings Catalog profiles cannot call the ADMXInstall CSP directly, so a Custom profile is required for the initial ingestion step.

Remote Help permissions are controlled through Intune role-based access control. Two granular permissions exist: "View screen" and "Take full control". To allow screen viewing without the ability to control the device, you must give helpers a role that includes only the "View screen" permission. The built-in Help Desk Operator role includes "Take full control", Remote Help settings do not provide a toggle to restrict control, and registry changes for legacy Remote Assistance do not affect the cloud-based Remote Help app.

To make Google Play content available in Intune, the tenant must first be connected to Managed Google Play by signing in with a Google account and authorizing Intune. This registration creates the Managed Google Play enterprise and allows Intune administrators to browse, approve, and sync public store apps directly from the console. Uploading APKs is only required for custom or line-of-business apps, not for public store apps. Apple Business Manager is unrelated to Android deployment, and Windows Package Manager integration affects Windows Store apps, not Android.

Hybrid Azure AD join keeps each computer joined to the on-premises Active Directory while also registering the device in Microsoft Entra ID. Because the computer account remains in the domain, users authenticate with the same domain credentials and can reach on-premises resources exactly as before. The cloud registration lets Intune automatically enroll the device and evaluate compliance so Conditional Access can enforce policy.

Azure AD join would require disjoining the machine from the on-premises domain, breaking traditional sign-in and resource access. Azure AD registered only creates a per-user registration and would require separate user-initiated Intune enrollment; therefore it does not meet the requirement for a seamless, fully managed domain-credential experience across the fleet.

A provisioning policy that uses an organization-owned network requires an Azure network connection (ANC). The ANC defines the target Azure virtual network, Active Directory join type, and connectivity settings. Intune validates the ANC and displays a status of Ready only after all connectivity and permissions checks pass. Provisioning policies that reference your network cannot be created-or will fail-until at least one ANC exists and is in the Ready state. Uploading a custom image, configuring self-service settings, or creating an Enrollment Status Page are optional tasks that do not satisfy this specific prerequisite.

The servicing profile (now referred to as Cloud Update) in the Microsoft 365 Apps admin center is designed to automatically deliver the most recent Monthly Enterprise Channel build to a selected set of devices. You can scope the profile to a specific device group, configure an update deadline (for example, two days) to control how quickly devices must install the new build, and use the built-in rollback capability to revert the devices to one of the previous builds if issues are detected. Inventory filtering and health dashboards only report status, the Office cloud policy service manages application settings, and Windows Update for Business rings do not control Microsoft 365 Apps update delivery.

When Intune processes a policy assignment, it first evaluates group targeting and then applies any configured filters. The device.deviceOwnership property in Intune filters returns either "Company" for corporate-owned devices or "Personal" for bring-your-own devices. A filter rule that selects devices where device.deviceOwnership equals "Company" ensures that the script runs only on corporate-owned devices. The other properties shown do not reliably distinguish ownership: enrollmentProfileName can vary, trustType indicates Azure AD join state, and operatingSystemSKU identifies the Windows edition instead of ownership.

Bulk remote actions are initiated from the Bulk device actions wizard, which is accessed by navigating to Devices > All devices and then selecting Bulk device actions. From the wizard you choose Windows as the platform, select Rotate BitLocker key, and then pick the target devices or device groups. Selecting devices individually, using the Endpoint security console, or deploying a PowerShell script through a configuration profile will not start the bulk Rotate BitLocker key action in one step.

An inbound rule that uses Action = Block prevents the computer from accepting matching traffic. Because SMB uses TCP port 445 on the destination computer, the rule must specify Local port 445 with Protocol = TCP. Applying the rule only to the Private and Public profiles ensures that traffic is still allowed when the device is on its Domain profile. The other options are incorrect because they either allow the traffic, target the wrong port field, or apply the rule to the Domain profile as well.

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.

For apps on unenrolled (MAM-only) devices, Intune delivers the tunnel connection details through an App configuration policy that targets managed apps. When the policy is assigned to the users, Microsoft Defender for Endpoint (which hosts the Tunnel client on Android) receives the site ID and other connection settings. Outlook, as an Intune-managed app, detects these settings and automatically sends its traffic through Microsoft Tunnel. A device configuration VPN profile is used only for enrolled devices, and neither compliance policies nor app protection policies carry the tunnel connection metadata required by the client.

For MAM-only scenarios, Microsoft Tunnel does not rely on the Company Portal or a dedicated Tunnel client. Instead, the Microsoft Defender for Endpoint (MDE) app contains an integrated VPN component that acts as the Tunnel client on both Android and iOS. Intune delivers an app configuration policy to the Defender app that supplies the connection settings, after which the protected apps can route traffic through the Tunnel. Company Portal is only required for device-enrollment scenarios, Microsoft Authenticator is unrelated to VPN connectivity, and Microsoft Edge alone cannot establish a Tunnel connection.

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.

Cloud trust removes the need to issue user or device certificates, so no Public Key Infrastructure is required. It uses Kerberos Cloud Trust between Azure AD and Windows Server 2016 or later domain controllers, and Windows Hello for Business is available almost immediately after a user signs in.

Key trust does not use a certificate registration object, but it still relies on an enterprise PKI to issue Kerberos authentication certificates to domain controllers and can suffer provisioning delays while the msDS-KeyCredentialLink attribute synchronizes.

Certificate trust explicitly depends on PKI-issued authentication certificates for users.

Deploying only FIDO2 security keys is a separate passwordless sign-in method and not a Windows Hello for Business trust model.

Hybrid Microsoft Entra join allows a Windows client to be joined to the on-premises Active Directory domain and automatically registered in Microsoft Entra ID. Because the computer account exists in both directories, users receive on-premises Group Policy processing while gaining cloud single sign-on and the ability to be enrolled in Intune for modern management. A cloud-only Microsoft Entra join removes the computer from the on-premises domain, so Group Policy would no longer apply. Microsoft Entra registration is intended for personally owned or workgroup devices and does not support domain Group Policy or full device management. A workgroup-joined computer, even if later registered, would still lack domain GPO processing. Therefore, hybrid join best meets all stated requirements.

Automatic MDM enrollment for Windows 10/11 relies on an Azure AD Premium capability. Each user whose device should be enrolled must have a license that includes Microsoft Entra ID Premium (P1 or P2). Without that license, a device that is Azure AD-joined will not trigger MDM auto-enrollment, even if the Intune service is set as the MDM authority and the MDM user scope is configured.

Incorrect answers:

• An Intune Administrator role is not required for the end user; only appropriate licenses are needed.
• Having Windows 11 Enterprise does not influence automatic enrollment; Pro and Enterprise editions are both supported.
• A bulk enrollment token is used only for provisioning large numbers of iOS or Android devices, not for automatic enrollment of Windows devices that are being Azure AD-joined.

The Provision desktop devices wizard is designed for bulk setup of Windows PCs that are not yet managed. It exposes options to configure Azure AD join and automatic MDM enrollment so that, when the .ppkg file is applied during OOBE, the device joins the specified tenant and registers with Intune without user input. The Advanced provisioning wizard gives access to every runtime setting but lacks the streamlined Azure AD join/MDM pages; Factory provisioning is intended for OEM imaging, and there is no Security baseline wizard in Windows Configuration Designer. Therefore, using the Provision desktop devices wizard is the correct choice.

An iOS/iPadOS app configuration policy for managed devices is processed only on devices that are enrolled in Intune (managed devices). This lets you push granular app settings, such as the Outlook S/MIME certificate hash, exclusively to company-owned devices. A managed-apps policy would also reach personal, unenrolled devices that run Outlook under app protection, while a device restrictions policy cannot target per-app settings, and an app protection policy governs data protection rather than configuring application-level settings.

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.