Select Two (Multi-Select) Questions

Maximum passcode age (days).

Why it fails: Password expiration is not part of the requirement.

Allow simple passcode.

Why it fails: Allowing simple passcode would weaken security, not enforce strength.

Extract the hardware hash from the device BIOS

Why it fails: Hardware hash is not stored in BIOS.

Use Microsoft Intune to generate the hardware hash from the device serial number

Why it fails: Intune cannot generate hardware hash.

Use Windows Configuration Designer to create a provisioning package that captures the hardware hash

Why it fails: WCD does not capture hardware hash.

Device configuration profile

Why it fails: Device configuration profiles set device settings but do not define compliance rules.

Device compliance policy

Why it fails: This is the same concept as Option B (compliance policy for Microsoft Intune) and is not a separate component.

App protection policy

Why it fails: App protection policies protect app data at the application level but do not evaluate device compliance.

Web link

Why it fails: Web link is not one of the two iOS/iPadOS app types in Intune; those are store apps and line-of-business apps (plus built-in and web apps on other platforms). It is tempting because web links can be published as apps, but that applies to managed web apps, not the iOS/iPadOS deployment types the question asks for.

Windows app (Win32)

Why it fails: Win32 apps deploy .intunewin packages to Windows 10/11 devices via the Intune Management Extension; iOS/iPadOS devices cannot execute them. This is the right app type for Windows endpoint management. iOS/iPadOS deployment instead uses iOS store apps and iOS line-of-business apps.

Android Line-of-business app

Why it fails: Android line-of-business apps target Android devices through managed Google Play or APK deployment; Intune assigns them to Android enrolment profiles, not iOS/iPadOS. It is correct when enrolling Android Enterprise devices. iOS/iPadOS deployment uses iOS store apps and iOS line-of-business apps.

App-driven

Why it fails: Windows Autopilot deployment modes are user-driven, pre-provisioning, and self-deploying; app-driven is not a valid scenario. It is tempting because applications are assigned during enrolment, and app-driven provisioning would be correct when describing application deployment via Intune rather than the Autopilot deployment mode.

Policy-driven

Why it fails: Windows Autopilot deployment modes are user-driven, pre-provisioning (white glove), and self-deploying; policy-driven is not one of them. It is tempting because Intune policy configures Autopilot profiles, and policy-driven enrolment would be correct when describing configuration management rather than the deployment scenario itself.

Product code

Why it fails: Product code is an MSI detection rule, not a Win32 app requirement; Intune wraps the .intunewin file and needs install/uninstall commands plus detection rules. It is tempting because product code identifies installed MSI applications for detection, and would be correct when packaging a line-of-business MSI with the Intune agent.

Dependencies

Why it fails: Dependencies are optional; Intune installs them only when the app requires other software first. They tempt because dependency chains matter for complex app packaging, and specifying them is correct when a Win32 app cannot function without prerequisite components already deployed.

Reissue the user's Microsoft 365 license from the admin center.

Why it fails: Licensing governs service access, not policy assignment; a licensed user with a correctly targeted device still receives policy. Reissuing is tempting when a user cannot sign in or Intune reports an unlicensed state, but the device is enrolled and reporting compliance, so licensing is not the failing dependency.

Reset the device's enrollment state via the Company Portal.

Why it fails: Resetting enrollment state removes the device's Intune and Microsoft Entra ID registration, forcing re-enrolment and wiping work data; it does not deliver the missing policy. It tempts when a device is stale or duplicated, where re-enrolment genuinely fixes sync. Here the device already reports compliance status, so the management channel is intact.

Run Invoke-Command to remotely execute gpupdate /force.

Why it fails: gpupdate /force refreshes Group Policy from on-premises domain controllers; it has no effect on Intune MDM policy, which arrives via the MDM channel and the Intune Management Extension. It tempts on hybrid-joined devices where Group Policy and Intune coexist, but the stem concerns Intune policy delivery specifically.

Change the primary user of the device

Why it fails: Autopilot reset retains the existing primary user assignment and does not reassign ownership; changing the primary user is done separately in Intune. It is tempting because reset is used when handing devices between users, and reassigning the primary user would be correct for that handover task.

Reinstall Windows 11 from scratch

Why it fails: Autopilot reset removes user data, apps and settings, then reapplies the existing Windows installation and Autopilot profile; it does not wipe and reinstall the OS image. It is tempting because the device returns to a clean state, but a full reinstall requires a fresh provisioning or reimaging method.

Remove the device from Microsoft Intune

Why it fails: Autopilot reset keeps the device enrolled in Microsoft Intune and Entra ID, reapplying management after the reset; it does not remove the device record. Removal is tempting because reset sounds like deprovisioning, and would be correct when retiring or repurposing a device.

Apple Push Notification service certificate (for iOS)

Why it fails: APNs is required for iOS management but not for automatic enrollment of all platforms.

Configuration Manager (for co-management)

Why it fails: Configuration Manager is not required for automatic enrollment.

Network share access

Why it fails: Network share access is not a Win32 app detection rule type; Intune supports MSI product code, file or folder existence, registry key, and custom PowerShell script detection. It is tempting because many packaged apps read configuration from UNC paths, but detection must evaluate the endpoint itself, not a remote share's reachability.

Check that the processor is at least 1GHz with 1 core.

Why it fails: Windows 11 requires a 1GHz or faster processor with two or more cores on a compatible 64-bit SoC, so a single core fails the requirement. It is tempting because 1GHz with one core was the Windows 10 baseline, and would be correct when checking Windows 10 compatibility rather than Windows 11.

Check that the device has at least 32GB of storage.

Why it fails: Windows 11 requires 64GB or more of storage, so 32GB fails the minimum hardware requirement. It is tempting because 32GB was the Windows 10 minimum for 32-bit installations, and would be the correct figure when validating older Windows 10 devices rather than Windows 11 upgrade readiness.

Microsoft Entra application proxy

Why it fails: Application Proxy publishes on-premises web apps for remote access, but zero-trust verification depends on Conditional Access evaluating signals at each request, which proxy publishing alone does not enforce. It is tempting because it does support remote access, yet it is the correct choice for exposing internal apps without a VPN.

Microsoft Entra Connect sync

Why it fails: Directory synchronisation populates identities into Microsoft Entra ID; zero-trust decisions require Conditional Access policies evaluating per-request signals, which sync itself does not perform. It is tempting because hybrid identity underpins many deployments, and it would be correct when the requirement is synchronising on-premises accounts to the cloud.

Configure a Conditional Access policy

Why it fails: Conditional Access does not affect policy delivery.

Reset the user's password

Why it fails: User credentials do not affect policy delivery.

Review the app protection policy assignment

Why it fails: App protection policies are for app data, not device policy delivery.

Deploy a line-of-business app

Why it fails: Deploying a line-of-business app installs software through the Intune management extension; it is configuration delivery, not a remote action against a device. It is tempting because app deployment is performed in the Intune admin center and is the correct choice when you need to distribute required applications to Windows 11 endpoints.

Create a VPN profile

Why it fails: A VPN profile is a configuration payload delivered by Intune, so it provisions settings rather than performing a remote action on a device. It is tempting because VPN profiles are created in the Intune admin center and target Windows 11 devices, making them the right choice when you need to distribute connection settings, not act remotely.

Assign a compliance policy

Why it fails: Compliance policies are assigned to users or device groups to evaluate settings and report state; they do not push configuration or execute remote actions on a device. Assignment targets devices, not live sessions. It is tempting because compliance results drive Conditional Access, which is a legitimate governance scenario, but not remote management.

Devices must be joined to Microsoft Entra ID.

Why it fails: Devices can be domain-joined, workgroup, or Microsoft Entra ID-joined; Intune management is the actual requirement. Microsoft Entra ID join is needed for conditional access and co-management identity scenarios, which is why it is tempting here, but it is not a Defender for Endpoint prerequisite.

Devices must have a third-party antivirus uninstalled.

Why it fails: Defender for Endpoint runs alongside third-party antivirus in passive mode, so removal is unnecessary. Uninstalling competing antivirus is the correct step when enabling active real-time protection conflicts, not for onboarding, which is why this distractor appears plausible.

An Microsoft Entra ID Premium license must be assigned.

Why it fails: Defender for Endpoint onboarding requires an Intune or Configuration Manager licence and supported Windows build, not Microsoft Entra ID Premium. That licence tier governs conditional access and identity protection features, so it is the right prerequisite for those scenarios, not endpoint deployment.

Reset a user's password.

Why it fails: Password reset is done in Entra ID.

Manage on-premises Active Directory objects.

Why it fails: Intune does not manage on-premises AD.

Assign Microsoft 365 licenses to a user.

Why it fails: License assignment is done in the Microsoft 365 admin center.

Change the enrolled user

Why it fails: The enrolled user (primary user) is assigned during enrolment and cannot be changed through an Intune remote device action. It is tempting because reassigning a device between users is a real administrative need, and would be correct in a question about device enrolment or Autopilot redeployment.

Change the device name

Why it fails: Intune does not provide a remote action to rename a managed device; the name is set at enrolment or changed on the device itself. It is tempting because other remote actions such as restart, wipe and retire exist, and renaming would be correct in a question about what administrators can change in the device record.

Join the device to Microsoft Entra ID manually.

Why it fails: Autopilot performs the Microsoft Entra join automatically during the out-of-box experience, so joining manually beforehand is unnecessary and can conflict with the profile. It is tempting because Entra join is the end state, but the required preparation is capturing the device hash and assigning a deployment profile.

Enable BitLocker encryption on the device.

Why it fails: BitLocker encryption is configured through Intune policy after enrolment, not as a prerequisite action during Autopilot preparation. It is tempting because Autopilot deployments do enable BitLocker, but that occurs post-provisioning; the preparation steps concern registering the hardware hash and assigning the profile.

Upgrade the device to the latest Windows 10 version.

Why it fails: Autopilot requires a supported Windows 10 build, but upgrading to the latest version is not one of the two preparation actions; the hardware hash registration and profile assignment are. It is tempting because newer builds support more Autopilot features, yet the device need only meet the minimum supported version.

Uninstall the app from the affected devices and reassign it as Required.

Why it fails: Uninstalling may not resolve the underlying issue and could cause data loss.

Reassign the app to the device group with a different assignment type.

Why it fails: Assignment type is already Required; changing it is not necessary.

Run gpresult /r on a device to confirm the app assignment policy is applied.

Why it fails: Group Policy is not used for Intune-managed devices.

Set default web browser

Why it fails: Default browser is set via settings catalog, not device restrictions.

Set battery saver threshold

Why it fails: Battery saver settings are not in device restrictions.

Configure Windows Update for Business settings

Why it fails: Windows Update settings are in update ring profiles.