Scenario practice questions

Which THREE are valid Windows Autopilot deployment scenarios?

Trap 1: App-driven

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.

Trap 2: Policy-driven

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.

A
Self-deploying
Self-deploying mode provisions devices with no user interaction, using a device-based Microsoft Entra ID join and TPM attestation. This satisfies the scenario's requirement for kiosk and shared-device rollouts where no credentials can be entered, making it one of the three valid Windows Autopilot deployment scenarios.
B
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.
C
User-driven
User-driven mode lets the end user complete OOBE themselves, signing in with their own Microsoft Entra ID credentials so the device joins and enrols automatically. This satisfies the scenario's requirement for a self-service deployment where IT pre-registers hardware but the user triggers provisioning.
D
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.
E
White glove
White glove (pre-provisioning) lets IT pre-stage the device so the time-consuming provisioning happens before the user receives it, then the user completes a short OOBE. This satisfies the scenario's requirement for a deployment mode that reduces end-user wait time.

Question 2easymultiple choice

A company uses Windows Autopilot for user-driven deployments. They want to ensure that during the out-of-box experience (OOBE), users are required to sign in with their Azure AD credentials and the device is automatically enrolled in Intune. Which Autopilot deployment profile setting should be configured?

Trap 1: Set 'Deployment mode' to 'Self-Deploying' and 'Join to Microsoft…

Self-Deploying mode provisions the device with no user credentials at all, so OOBE never prompts for sign-in — directly contradicting the requirement. It is tempting because it also produces a Microsoft Entra joined device enrolled in Intune, and is correct for kiosks or shared devices needing zero-touch provisioning.

Trap 2: Set 'Deployment mode' to 'User-Driven' and 'Join to Microsoft Entra…

Hybrid Microsoft Entra join requires the device to reach a domain controller and an on-premises AD object, so OOBE demands domain credentials rather than cloud sign-in. It is tempting because User-Driven mode is right, but hybrid join suits organisations needing on-premises Group Policy alongside Intune.

Trap 3: Set 'Deployment mode' to 'White Glove' and 'Join to Microsoft Entra…

White Glove pre-provisions the device before it reaches the user, so the technician, not the end user, completes enrolment and OOBE sign-in. It is tempting because it still yields a Microsoft Entra joined, Intune-enrolled device, and is correct when devices must be staged before delivery.

A
Set 'Deployment mode' to 'Self-Deploying' and 'Join to Microsoft Entra ID as' to 'Microsoft Entra ID joined'.
Why it fails: Self-Deploying mode provisions the device with no user credentials at all, so OOBE never prompts for sign-in — directly contradicting the requirement. It is tempting because it also produces a Microsoft Entra joined device enrolled in Intune, and is correct for kiosks or shared devices needing zero-touch provisioning.
B
Set 'Deployment mode' to 'User-Driven' and 'Join to Microsoft Entra ID as' to 'Hybrid Microsoft Entra ID joined'.
Why it fails: Hybrid Microsoft Entra join requires the device to reach a domain controller and an on-premises AD object, so OOBE demands domain credentials rather than cloud sign-in. It is tempting because User-Driven mode is right, but hybrid join suits organisations needing on-premises Group Policy alongside Intune.
C
Set 'Deployment mode' to 'White Glove' and 'Join to Microsoft Entra ID as' to 'Microsoft Entra ID joined'.
Why it fails: White Glove pre-provisions the device before it reaches the user, so the technician, not the end user, completes enrolment and OOBE sign-in. It is tempting because it still yields a Microsoft Entra joined, Intune-enrolled device, and is correct when devices must be staged before delivery.
D
Set 'Deployment mode' to 'User-Driven' and 'Join to Microsoft Entra ID as' to 'Microsoft Entra ID joined'.
User-Driven mode presents the OOBE sign-in page, and Microsoft Entra ID joined makes the device join Microsoft Entra ID and auto-enrol in Intune. Together they satisfy the requirement for credential-based sign-in and automatic enrolment during out-of-box experience.

Question 3easymultiple choice

You need to remotely wipe a lost corporate-owned iOS device that is enrolled in Microsoft Intune. Which action should you perform in the Intune console?

Trap 1: Retire.

Retire removes corporate data and management profiles but leaves personal content intact, so a lost device's data is not erased. It is tempting because it is the standard offboarding action, and would be correct when an employee leaves and the device is being removed from management while retaining personal use.

Trap 2: Delete.

Delete only removes the device record.

Trap 3: Reset.

Reset reinstalls the operating system and clears all data, but it is designed for repurposing or troubleshooting a device, not for a lost device that must be remotely wiped. It is tempting because it erases everything, and would be correct when preparing a recovered device for redeployment.

A
Retire.
Why it fails: Retire removes corporate data and management profiles but leaves personal content intact, so a lost device's data is not erased. It is tempting because it is the standard offboarding action, and would be correct when an employee leaves and the device is being removed from management while retaining personal use.
B
Wipe.
Wipe performs a full factory reset, removing all data, settings, and the management enrolment itself, which satisfies the requirement to remotely erase a lost corporate-owned iOS device. Retire would only remove corporate data and leave personal content intact, so it cannot guarantee the device is cleared.
C
Delete.
Why it fails: Delete only removes the device record.
D
Reset.
Why it fails: Reset reinstalls the operating system and clears all data, but it is designed for repurposing or troubleshooting a device, not for a lost device that must be remotely wiped. It is tempting because it erases everything, and would be correct when preparing a recovered device for redeployment.

Question 4mediummatching

Match each MDM (Mobile Device Management) enrollment method to its typical scenario.

Drag a concept onto its matching description — or click a concept then click the description.

Concepts

Matches

User-owned devices enrolled with user affinity

Company-owned devices assigned to a specific user

Shared or kiosk devices not tied to a user

Zero-touch deployment for new Windows devices

Enroll multiple devices using a shared account

Trap 1: Windows Autopilot: Used for enrolling corporate-owned Android…

Incorrect — Windows Autopilot is designed for Windows devices, not Android. Android Zero Touch is a separate enrollment method.

Trap 2: User-Driven Enrollment: Used for automatically enrolling devices…

Incorrect — User-Driven Enrollment requires user interaction to initiate enrollment. Automatic enrollment without user interaction describes Apple Business Manager or Windows Autopilot.

A
Apple Business Manager: Used for automated enrollment of corporate-owned iOS devices with supervision.
Apple Business Manager (ABM) enables organizations to automatically enroll corporate-owned iOS devices into MDM with supervision and out-of-box setup.
B
Android Enterprise Work Profile: Used for BYOD Android devices to separate work and personal data.
The Work Profile creates a separate container for work apps and data on personally-owned Android devices, preserving user privacy.
C
Windows Autopilot: Used for enrolling corporate-owned Android devices with Zero Touch enrollment.
Why it fails: Incorrect — Windows Autopilot is designed for Windows devices, not Android. Android Zero Touch is a separate enrollment method.
D
User-Driven Enrollment: Used for automatically enrolling devices without user interaction during setup.
Why it fails: Incorrect — User-Driven Enrollment requires user interaction to initiate enrollment. Automatic enrollment without user interaction describes Apple Business Manager or Windows Autopilot.

Question 5easymultiple choice

Your organization uses Microsoft Intune to manage Windows 10 devices. You need to create a compliance policy that requires devices to have a firewall enabled. Which setting should you configure?

Trap 1: Antivirus

The Antivirus setting checks for antivirus protection, such as Windows Defender Antivirus, but does not verify firewall status. It addresses a different security control and would not meet the requirement to ensure the firewall is enabled.

Trap 2: Require a password to unlock mobile devices

This setting enforces a password but does not check firewall status. It is unrelated to the requirement for firewall enablement. Configuring it would not help ensure devices have a firewall enabled, and it might impose unnecessary password policies.

Trap 3: Require BitLocker

Require BitLocker enforces drive encryption but does not check firewall status. It is not relevant to the firewall requirement. Enabling this would add an encryption requirement that is not part of the scenario, potentially causing additional compliance failures.

A
Firewall
The Firewall setting in a Windows compliance policy checks whether the Windows Firewall is enabled on the device. Configuring this setting to 'Require' ensures devices with the firewall disabled are marked non-compliant, directly fulfilling the requirement.
B
Antivirus
Why it fails: The Antivirus setting checks for antivirus protection, such as Windows Defender Antivirus, but does not verify firewall status. It addresses a different security control and would not meet the requirement to ensure the firewall is enabled.
C
Require a password to unlock mobile devices
Why it fails: This setting enforces a password but does not check firewall status. It is unrelated to the requirement for firewall enablement. Configuring it would not help ensure devices have a firewall enabled, and it might impose unnecessary password policies.
D
Require BitLocker
Why it fails: Require BitLocker enforces drive encryption but does not check firewall status. It is not relevant to the firewall requirement. Enabling this would add an encryption requirement that is not part of the scenario, potentially causing additional compliance failures.

Question 6hardmulti select

An organization is planning to implement a zero-trust security model. They need to evaluate the following capabilities in Microsoft 365. Which THREE are essential for a zero-trust architecture? (Choose three.)

Trap 1: Microsoft Entra application proxy

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.

Trap 2: Microsoft Entra Connect sync

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.

A
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.
B
Multi-factor authentication (MFA)
MFA directly enforces zero trust's verify-explicitly principle by requiring a second authentication factor, so a compromised password alone cannot grant access. It satisfies the stem's demand for identity verification at every sign-in, blocking credential-based lateral movement and satisfying conditional access policies that Microsoft Entra ID evaluates per session.
C
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.
D
Device compliance policies
Device compliance policies enforce conditional access by verifying health signals—encryption, OS version, threat protection—before granting resource access. This satisfies zero-trust's "verify explicitly" principle, ensuring only compliant devices reach Microsoft 365 data, regardless of network location.
E
Conditional Access policies
Conditional Access policies satisfy zero-trust's explicit verification requirement by evaluating signals—user identity, device compliance, location and risk—at authentication time, then enforcing grant controls such as multifactor authentication or compliant-device access. This dynamic, per-session enforcement replaces implicit network trust, directly meeting the stem's demand for continuous, context-aware access decisions in Microsoft Entra ID.

Question 7easymulti select

You are planning to deploy Microsoft Defender for Endpoint on Windows 10 devices managed by Intune. Which TWO prerequisites must be met before deploying?

Trap 1: Devices must be joined to Microsoft Entra ID.

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.

Trap 2: Devices must have a third-party antivirus uninstalled.

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.

Trap 3: An Microsoft Entra ID Premium license must be assigned.

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.

A
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.
B
A Microsoft Defender for Endpoint license must be assigned.
Assigning a Microsoft Defender for Endpoint licence to users is mandatory, since the service activates per-user entitlement; without it, onboarding packages deploy but devices remain unlicensed and report no telemetry to the Microsoft 365 Defender portal. This satisfies the stem's prerequisite that licensing be in place before Intune deployment begins.
C
Devices must be enrolled in Microsoft Intune.
Devices must be enrolled in Microsoft Intune so the Defender for Endpoint onboarding configuration can be targeted and delivered. Without Intune enrolment, no management channel exists to push the onboarding package, making enrolment a prerequisite.
D
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.
E
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.

Question 8mediummultiple choice

Your organization uses Microsoft Intune to manage Windows 10/11 devices. You need to ensure that devices are enrolled automatically without user interaction and that the enrollment status page (ESP) is configured to block device use until required apps are installed. What should you configure?

Trap 1: Configure a Group Policy to auto-enroll devices into Intune

Group Policy cannot deliver the Intune enrollment status page, which blocks device use until required apps install; it only handles on-premises domain auto-enrolment. Windows Autopilot deployment profiles configure both zero-touch enrolment and the ESP. Group Policy suits hybrid domain-joined device management.

Trap 2: Configure a device enrollment manager (DEM) account

A device enrollment manager (DEM) account is used for bulk enrollment, allowing one user to enroll many devices, but it requires manual intervention during enrollment and does not provide automatic zero-touch enrollment. DEM supports Windows devices as well as other platforms, so it is not limited to Android/iOS.

Trap 3: Configure co-management with Microsoft Configuration Manager

Co-management splits workloads between Microsoft Configuration Manager and Intune but does not itself perform zero-touch enrolment or present the ESP. Windows Autopilot deployment profiles deliver both. Co-management suits gradually migrating existing Configuration Manager-managed devices to Intune.

A
Configure a Group Policy to auto-enroll devices into Intune
Why it fails: Group Policy cannot deliver the Intune enrollment status page, which blocks device use until required apps install; it only handles on-premises domain auto-enrolment. Windows Autopilot deployment profiles configure both zero-touch enrolment and the ESP. Group Policy suits hybrid domain-joined device management.
B
Configure a device enrollment manager (DEM) account
Why it fails: A device enrollment manager (DEM) account is used for bulk enrollment, allowing one user to enroll many devices, but it requires manual intervention during enrollment and does not provide automatic zero-touch enrollment. DEM supports Windows devices as well as other platforms, so it is not limited to Android/iOS.
C
Configure Windows Autopilot self-deploying mode and an Enrollment Status Page profile
Windows Autopilot self-deploying mode enrols devices with no user credentials, satisfying the zero-touch requirement, since it authenticates via the device's TPM-attested identity rather than an interactive sign-in. Pairing it with an Enrollment Status Page profile blocks device use until assigned required apps install, meeting the stem's gating constraint.
D
Configure co-management with Microsoft Configuration Manager
Why it fails: Co-management splits workloads between Microsoft Configuration Manager and Intune but does not itself perform zero-touch enrolment or present the ESP. Windows Autopilot deployment profiles deliver both. Co-management suits gradually migrating existing Configuration Manager-managed devices to Intune.

Question 9hardmultiple choice

You manage devices with Microsoft Intune and have enabled co-management with Configuration Manager. You need to ensure that Windows Update policies are managed by Intune for all co-managed Windows 10 devices. Which workload slider should you set in Configuration Manager?

Trap 1: Endpoint Protection

Endpoint Protection governs Defender antivirus and firewall policy, not update rings or Windows Update for Business settings. Moving this slider to Intune suits organisations standardising endpoint security agents centrally while leaving update policy in Configuration Manager.

Trap 2: Client Apps

Client Apps governs deployment of applications from Intune or Configuration Manager, not update policy. It is tempting because moving this workload lets Intune deliver Win32 apps to co-managed devices, which is the right choice when application deployment, rather than Windows Update policy, must shift to Intune.

Trap 3: Device Configuration

Device Configuration governs settings delivered through configuration profiles, not update deployment. Windows Update policies sit under the Windows Update workload slider, which must move to Intune for co-managed devices. Device Configuration would be the right slider when you want Intune to manage compliance-adjacent configuration baselines instead of Configuration Manager.

A
Endpoint Protection
Why it fails: Endpoint Protection governs Defender antivirus and firewall policy, not update rings or Windows Update for Business settings. Moving this slider to Intune suits organisations standardising endpoint security agents centrally while leaving update policy in Configuration Manager.
B
Windows Update Policies
Moving the Windows Update Policies workload slider to Intune transfers update policy authority from Configuration Manager to Intune for co-managed devices. This directly satisfies the stem's requirement that Intune manage Windows Update policies across all co-managed Windows 10 devices.
C
Client Apps
Why it fails: Client Apps governs deployment of applications from Intune or Configuration Manager, not update policy. It is tempting because moving this workload lets Intune deliver Win32 apps to co-managed devices, which is the right choice when application deployment, rather than Windows Update policy, must shift to Intune.
D
Device Configuration
Why it fails: Device Configuration governs settings delivered through configuration profiles, not update deployment. Windows Update policies sit under the Windows Update workload slider, which must move to Intune for co-managed devices. Device Configuration would be the right slider when you want Intune to manage compliance-adjacent configuration baselines instead of Configuration Manager.

Question 10easymultiple choice

Your organization uses Microsoft Intune to manage Android devices. You need to ensure that corporate data on these devices is protected in case the device is lost or stolen. You configure a compliance policy that requires device encryption and a device lock screen. However, you also want to be able to selectively wipe corporate data without wiping personal data. What should you do?

Trap 1: Enable remote lock on the device.

Remote lock only secures the device screen; it removes no corporate data and cannot distinguish work from personal content. It is tempting because lock actions address lost-device scenarios, and remote lock would be correct when a device is misplaced but recovery is expected and data removal is not required.

Trap 2: Configure a device compliance policy to wipe the device if…

A compliance-triggered wipe erases the entire device, destroying personal data alongside corporate content, which contradicts the selective requirement. It is tempting because non-compliance actions enforce policy automatically, and full wipe would be correct for corporate-owned devices where no personal data exists.

Trap 3: Use a device configuration profile to enable selective wipe.

A device configuration profile cannot perform selective wipe; that action is delivered through app protection policies, which remove corporate data from managed apps while leaving personal content intact. It is tempting because configuration profiles control device settings, and they would be correct for enforcing encryption or lock-screen requirements.

A
Enable remote lock on the device.
Why it fails: Remote lock only secures the device screen; it removes no corporate data and cannot distinguish work from personal content. It is tempting because lock actions address lost-device scenarios, and remote lock would be correct when a device is misplaced but recovery is expected and data removal is not required.
B
Configure a device compliance policy to wipe the device if non-compliant.
Why it fails: A compliance-triggered wipe erases the entire device, destroying personal data alongside corporate content, which contradicts the selective requirement. It is tempting because non-compliance actions enforce policy automatically, and full wipe would be correct for corporate-owned devices where no personal data exists.
C
Use a device configuration profile to enable selective wipe.
Why it fails: A device configuration profile cannot perform selective wipe; that action is delivered through app protection policies, which remove corporate data from managed apps while leaving personal content intact. It is tempting because configuration profiles control device settings, and they would be correct for enforcing encryption or lock-screen requirements.
D
Assign an app protection policy to the user for the corporate apps.
App protection policies apply at the application layer, enforcing encryption and access controls on corporate data within managed apps. This enables selective wipe of corporate data from those apps while leaving personal data on the device untouched, which device-level compliance policies cannot achieve.

Question 11mediummultiple choice

You have a hybrid Microsoft Entra ID joined Windows 10 device that is co-managed with Configuration Manager and Intune. You want Intune to manage Windows Update for Business settings. Which slider setting should you configure in Configuration Manager?

Trap 1: Move the slider for 'Endpoint protection' to 'Intune'

Endpoint protection covers Defender antivirus, firewall and attack surface reduction policies, not update rings. Windows Update for Business needs the Windows Update slider moved to Intune. Endpoint protection is the correct slider when you want Intune to manage Defender and firewall configuration rather than Configuration Manager.

Trap 2: Move the slider for 'Resource access' to 'Intune'

Resource access controls VPN, Wi-Fi, certificate and email profile delivery, not update policy. Windows Update for Business requires the Windows Update slider, so moving Resource access leaves update settings with Configuration Manager. Resource access is the right slider when Intune should deliver certificates and network profiles to co-managed devices.

Trap 3: Move the slider for 'Device configuration' to 'Intune'

Windows Update for Business settings sit under the Windows Update workload slider, not Device configuration, which governs general device settings such as encryption and platform restrictions. Moving Device configuration to Intune is correct when you want Intune to own those broader device settings instead of Configuration Manager.

A
Move the slider for 'Windows Update policies' to 'Intune'
Shifting the Windows Update policies workload slider to Intune transfers authority for Windows Update for Business settings to Microsoft Entra ID-based MDM, satisfying the requirement that Intune manage them. Configuration Manager retains the remaining co-management workloads, so update policy delivery no longer depends on the Configuration Manager client.
B
Move the slider for 'Endpoint protection' to 'Intune'
Why it fails: Endpoint protection covers Defender antivirus, firewall and attack surface reduction policies, not update rings. Windows Update for Business needs the Windows Update slider moved to Intune. Endpoint protection is the correct slider when you want Intune to manage Defender and firewall configuration rather than Configuration Manager.
C
Move the slider for 'Resource access' to 'Intune'
Why it fails: Resource access controls VPN, Wi-Fi, certificate and email profile delivery, not update policy. Windows Update for Business requires the Windows Update slider, so moving Resource access leaves update settings with Configuration Manager. Resource access is the right slider when Intune should deliver certificates and network profiles to co-managed devices.
D
Move the slider for 'Device configuration' to 'Intune'
Why it fails: Windows Update for Business settings sit under the Windows Update workload slider, not Device configuration, which governs general device settings such as encryption and platform restrictions. Moving Device configuration to Intune is correct when you want Intune to own those broader device settings instead of Configuration Manager.

Question 12hardmulti select

You are preparing infrastructure for Windows Autopilot deployment in a hybrid Microsoft Entra join scenario. You need to ensure that devices can join the on-premises domain and enroll in Intune. Which two components must you configure? (Choose two.)

Trap 1: Device enrollment manager (DEM) account

A DEM account is used for bulk enrollment of devices, typically in scenarios like kiosks or shared devices. It is not used for Autopilot hybrid join. Autopilot hybrid join uses the device's credentials and the Intune connector for Active Directory. DEM accounts are not required and would not facilitate the hybrid join process.

Trap 2: Windows Autopilot deployment profile with 'Convert all targeted…

The 'Convert all targeted devices to Autopilot' option is used to register existing devices with Autopilot, not for hybrid join deployment. While a deployment profile is needed for Autopilot, the conversion option is not required for hybrid join. It is used in scenarios where devices are already deployed and need to be added to Autopilot.

Trap 3: Microsoft Entra Connect with device writeback

Microsoft Entra Connect with device writeback is used to sync on-premises devices to Microsoft Entra ID, but it is not required for Autopilot hybrid join. The Intune connector for Active Directory handles the offline domain join, and automatic enrollment handles Intune enrollment. Device writeback is for other scenarios, such as conditional access with hybrid devices.

A
Device enrollment manager (DEM) account
Why it fails: A DEM account is used for bulk enrollment of devices, typically in scenarios like kiosks or shared devices. It is not used for Autopilot hybrid join. Autopilot hybrid join uses the device's credentials and the Intune connector for Active Directory. DEM accounts are not required and would not facilitate the hybrid join process.
B
Intune connector for Active Directory
The Intune connector for Active Directory is required for hybrid Microsoft Entra join. It enables devices to perform an offline domain join during Autopilot, creating computer objects in Active Directory. Without this connector, devices cannot join the domain automatically, and the hybrid join process fails. It must be installed on a server with domain access.
C
Automatic MDM enrollment in Microsoft Entra ID
Automatic MDM enrollment must be enabled in Microsoft Entra ID to allow devices to enroll in Intune automatically. For hybrid joined devices, this ensures that once the device is joined to Microsoft Entra ID, it is also enrolled in Intune. Without this setting, devices would not be managed by Intune even if they successfully join the domain.
D
Windows Autopilot deployment profile with 'Convert all targeted devices to Autopilot'
Why it fails: The 'Convert all targeted devices to Autopilot' option is used to register existing devices with Autopilot, not for hybrid join deployment. While a deployment profile is needed for Autopilot, the conversion option is not required for hybrid join. It is used in scenarios where devices are already deployed and need to be added to Autopilot.
E
Microsoft Entra Connect with device writeback
Why it fails: Microsoft Entra Connect with device writeback is used to sync on-premises devices to Microsoft Entra ID, but it is not required for Autopilot hybrid join. The Intune connector for Active Directory handles the offline domain join, and automatic enrollment handles Intune enrollment. Device writeback is for other scenarios, such as conditional access with hybrid devices.

Question 13mediummultiple choice

You are the endpoint administrator for Contoso, Ltd. The company uses Microsoft Intune and has a hybrid Microsoft Entra ID environment with an on-premises Active Directory Domain Services (AD DS) domain. You plan to deploy 200 new Windows 11 devices using Windows Autopilot. The devices must be joined to the on-premises AD DS domain and also registered in Microsoft Entra ID. You need to configure the Autopilot deployment profile to support this scenario. What should you do first?

Trap 1: Assign the Autopilot deployment profile to a user group and…

Assigning to a user group and using user-driven mode are valid settings, but they do not address the hybrid join requirement. User-driven mode allows the end user to complete the out-of-box experience, but without specifying hybrid join, the device will not join on-premises AD DS. This option misses the core need to configure the join type, so it is incorrect.

Trap 2: Create an Autopilot deployment profile with the "Convert all…

The "Convert all targeted devices to Autopilot" option is used to automatically register existing devices with the Autopilot service, not to configure the join type for new devices. It does not control whether the device joins on-premises AD DS. Enabling this option would not satisfy the hybrid join requirement and could lead to unexpected registrations of existing devices, which is not the goal here.

Trap 3: Configure the deployment profile to use Microsoft Entra join and…

Microsoft Entra join alone does not meet the requirement of joining the device to on-premises AD DS. It would register the device only in Microsoft Entra ID. While assigning a profile to a device group is necessary for deployment, it does not address the hybrid join requirement. The scenario explicitly requires both AD DS and Microsoft Entra ID registration, so this option is insufficient.

A
Assign the Autopilot deployment profile to a user group and configure the profile to use "User-driven" mode.
Why it fails: Assigning to a user group and using user-driven mode are valid settings, but they do not address the hybrid join requirement. User-driven mode allows the end user to complete the out-of-box experience, but without specifying hybrid join, the device will not join on-premises AD DS. This option misses the core need to configure the join type, so it is incorrect.
B
Create an Autopilot deployment profile with the "Convert all targeted devices to Autopilot" option enabled.
Why it fails: The "Convert all targeted devices to Autopilot" option is used to automatically register existing devices with the Autopilot service, not to configure the join type for new devices. It does not control whether the device joins on-premises AD DS. Enabling this option would not satisfy the hybrid join requirement and could lead to unexpected registrations of existing devices, which is not the goal here.
C
Configure the deployment profile to use Microsoft Entra join and assign the profile to a device group.
Why it fails: Microsoft Entra join alone does not meet the requirement of joining the device to on-premises AD DS. It would register the device only in Microsoft Entra ID. While assigning a profile to a device group is necessary for deployment, it does not address the hybrid join requirement. The scenario explicitly requires both AD DS and Microsoft Entra ID registration, so this option is insufficient.
D
Configure the deployment profile to use Microsoft Entra hybrid join and ensure the device has a line of sight to a domain controller.
Microsoft Entra hybrid join requires the device to authenticate against an on-premises domain controller during the offline domain join process. A line of sight is essential. Configuring the profile for hybrid join is the correct first step because it enables the device to be joined to AD DS and registered in Microsoft Entra ID simultaneously. Without this setting, the device would only be Microsoft Entra joined, not hybrid joined.

Question 14hardmultiple choice

You are preparing infrastructure for Microsoft Intune enrollment of Windows 11 devices. The company uses Microsoft Entra ID and requires that devices automatically enroll in Intune when users join them to Microsoft Entra ID. You also need to ensure that only users in a specific security group are allowed to enroll devices. What should you configure?

Trap 1: Create a device enrollment restriction in Intune that allows only…

Device enrollment restrictions control platform, version, and personal versus corporate ownership, not user group membership for automatic enrollment. Windows Autopilot is a deployment method and does not restrict which users can enroll. This combination does not enforce the requirement that only members of a specific security group can enroll devices.

Trap 2: Configure automatic MDM enrollment in the Microsoft Entra ID…

The mobility (MDM and WIP) settings in Microsoft Entra ID let you define which users can automatically enroll, and you can scope it to a group. However, the Intune Enrollment scope is not a valid construct in that blade; you assign MDM user scope to a group. This option uses an incorrect term, so it does not accurately describe the configuration required.

Trap 3: Configure a Conditional Access policy that requires compliant…

Conditional Access policies control access to cloud apps based on conditions such as device compliance, but they do not govern automatic MDM enrollment or limit enrollment to a particular user group. This approach addresses access control after enrollment rather than the enrollment eligibility requirement described in the scenario.

A
Create a device enrollment restriction in Intune that allows only the security group and enable Windows Autopilot for those devices.
Why it fails: Device enrollment restrictions control platform, version, and personal versus corporate ownership, not user group membership for automatic enrollment. Windows Autopilot is a deployment method and does not restrict which users can enroll. This combination does not enforce the requirement that only members of a specific security group can enroll devices.
B
Configure automatic MDM enrollment in the Microsoft Entra ID mobility settings and assign the Intune Enrollment scope to the security group.
Why it fails: The mobility (MDM and WIP) settings in Microsoft Entra ID let you define which users can automatically enroll, and you can scope it to a group. However, the Intune Enrollment scope is not a valid construct in that blade; you assign MDM user scope to a group. This option uses an incorrect term, so it does not accurately describe the configuration required.
C
Configure a Conditional Access policy that requires compliant devices and assign it to the security group.
Why it fails: Conditional Access policies control access to cloud apps based on conditions such as device compliance, but they do not govern automatic MDM enrollment or limit enrollment to a particular user group. This approach addresses access control after enrollment rather than the enrollment eligibility requirement described in the scenario.
D
Enable automatic enrollment in Intune and set the MDM user scope in Microsoft Entra ID to the security group.
Automatic MDM enrollment is enabled from the Intune portal, and the Microsoft Entra ID mobility settings include an MDM user scope that can be set to a specific security group. Setting the scope to that group ensures only its members are automatically enrolled in Intune when they join devices to Microsoft Entra ID, meeting both requirements.

Question 15mediummultiple choice

You manage Windows 11 devices with Microsoft Intune. A line-of-business MSI app must install only after a Visual C++ redistributable package is present, and the MSI must run with SYSTEM privileges at every device startup regardless of user sign-in. You need to configure the app deployment in Intune. What should you do?

Trap 1: Deploy the MSI as a line-of-business app and configure an Intune…

A line-of-business MSI deployed through Intune installs in system context but provides no native dependency mechanism, and a separate PowerShell script has no guaranteed ordering relative to the MSI installation. The script may run after the MSI or fail silently, so the prerequisite might never be met, making this approach unreliable for the required sequencing.

Trap 2: Deploy the MSI as a line-of-business app and set the app to install…

A line-of-business MSI offers no dependency support, so the redistributable would not be installed first. Setting user context also causes installation to occur only when a user signs in and to run without SYSTEM privileges, directly contradicting the requirement for startup device-level installation with elevated rights.

Trap 3: Create a Windows app (Win32) package, add the redistributable as a…

Supersedence replaces an older app with a newer one; it does not install a prerequisite before the target app, so the redistributable might not be present in time. Also, User install context runs the MSI under the signed-in user's token, which cannot satisfy the requirement to install with SYSTEM privileges at startup before any user signs in.

A
Deploy the MSI as a line-of-business app and configure an Intune PowerShell script to install the redistributable first.
Why it fails: A line-of-business MSI deployed through Intune installs in system context but provides no native dependency mechanism, and a separate PowerShell script has no guaranteed ordering relative to the MSI installation. The script may run after the MSI or fail silently, so the prerequisite might never be met, making this approach unreliable for the required sequencing.
B
Deploy the MSI as a line-of-business app and set the app to install in user context.
Why it fails: A line-of-business MSI offers no dependency support, so the redistributable would not be installed first. Setting user context also causes installation to occur only when a user signs in and to run without SYSTEM privileges, directly contradicting the requirement for startup device-level installation with elevated rights.
C
Create a Windows app (Win32) package, add the redistributable as a supersedence, and set the install behavior to User.
Why it fails: Supersedence replaces an older app with a newer one; it does not install a prerequisite before the target app, so the redistributable might not be present in time. Also, User install context runs the MSI under the signed-in user's token, which cannot satisfy the requirement to install with SYSTEM privileges at startup before any user signs in.
D
Create a Windows app (Win32) package, add the redistributable as a dependency, and set the install behavior to System.
Packaging the MSI as a Windows app (Win32) lets Intune enforce a dependency on the redistributable before installing the MSI, and the install behavior set to System runs the installer with SYSTEM privileges. The dependency ensures ordering, and SYSTEM context satisfies the requirement that installation occur at device level independent of user sign-in, which matches the scenario's startup requirement.

Question 16easymultiple choice

Refer to the exhibit. You are configuring a Windows Autopilot profile. The profile specifies enrollmentType as 'azureAdJoined'. Which scenario does this profile support?

Exhibit

{
  "deviceEnrollmentConfiguration": {
    "@odata.type": "#microsoft.graph.windows10EnrollmentProfile",
    "displayName": "Autopilot Profile",
    "description": "Standard user-driven Autopilot",
    "enrollmentType": "azureAdJoined",
    "language": "en-US",
    "outOfBoxExperienceSettings": {
      "hidePrivacySettings": false,
      "hideEULA": false,
      "userType": "standard",
      "deviceUsageType": "singleUser"
    }
  }
}

Trap 1: Self-deploying mode where no user interaction is required.

Self-deploying mode uses enrollmentType 'selfDeploying', not 'azureAdJoined', so no user interaction is not supported here. It is tempting because both enrol devices without hybrid join, but 'azureAdJoined' requires the user to sign in with Microsoft Entra ID credentials during OOBE.

Trap 2: Hybrid Microsoft Entra ID join with on-premises domain controller.

Hybrid join requires enrollmentType 'hybridAzureADJoin' plus an on-premises domain controller and offline domain join blob, which 'azureAdJoined' does not provide. It is tempting because both involve Microsoft Entra ID, but 'azureAdJoined' joins the device directly to Entra ID only, with no domain controller.

Trap 3: On-premises Active Directory domain join only.

'azureAdJoined' joins the device to Microsoft Entra ID, not on-premises Active Directory, so domain-join-only is unsupported. It is tempting because Autopilot can target domain-joined devices, but that requires enrollmentType 'hybridAzureADJoin' with a domain controller and offline domain join blob.

A
Self-deploying mode where no user interaction is required.
Why it fails: Self-deploying mode uses enrollmentType 'selfDeploying', not 'azureAdJoined', so no user interaction is not supported here. It is tempting because both enrol devices without hybrid join, but 'azureAdJoined' requires the user to sign in with Microsoft Entra ID credentials during OOBE.
B
User-driven deployment with Microsoft Entra ID join.
Setting enrollmentType to azureAdJoined joins the device only to Microsoft Entra ID, not on-premises Active Directory. This matches the user-driven scenario where the primary user receives the device and completes OOBE, satisfying the stem's requirement for a cloud-joined, user-driven Autopilot deployment.
C
Hybrid Microsoft Entra ID join with on-premises domain controller.
Why it fails: Hybrid join requires enrollmentType 'hybridAzureADJoin' plus an on-premises domain controller and offline domain join blob, which 'azureAdJoined' does not provide. It is tempting because both involve Microsoft Entra ID, but 'azureAdJoined' joins the device directly to Entra ID only, with no domain controller.
D
On-premises Active Directory domain join only.
Why it fails: 'azureAdJoined' joins the device to Microsoft Entra ID, not on-premises Active Directory, so domain-join-only is unsupported. It is tempting because Autopilot can target domain-joined devices, but that requires enrollmentType 'hybridAzureADJoin' with a domain controller and offline domain join blob.

Question 17easymultiple choice

A company uses Microsoft Intune to manage devices. They want to ensure that when a device is reported as lost or stolen, the IT admin can remotely wipe the device. Which action should the admin take in the Intune console?

Trap 1: Select the device and choose 'Retire'.

Retire removes company data and management but leaves personal files intact, so it cannot wipe a lost device. It is tempting because Retire is correct when an employee leaves and their personal device must be unenrolled without erasing personal content.

Trap 2: Select the device and choose 'Reset'.

'Reset' restores the device to factory settings but does not protect data on a lost or stolen device, since it can be blocked by the thief or offline. The correct action is a wipe that removes corporate data. Reset is intended for repurposing or troubleshooting a device the organisation still physically controls.

Trap 3: Select the device and choose 'Delete'.

Delete removes only the Intune device record, so no wipe command reaches the lost device. It is tempting as housekeeping for stale or duplicate records, which is the correct scenario for Delete rather than remote data removal.

A
Select the device and choose 'Retire'.
Why it fails: Retire removes company data and management but leaves personal files intact, so it cannot wipe a lost device. It is tempting because Retire is correct when an employee leaves and their personal device must be unenrolled without erasing personal content.
B
Select the device and choose 'Wipe'.
The Wipe action in Intune performs a full factory reset, removing all data and settings from the device. For a lost or stolen device this satisfies the requirement to remotely erase corporate and personal content, preventing data exposure.
C
Select the device and choose 'Reset'.
Why it fails: 'Reset' restores the device to factory settings but does not protect data on a lost or stolen device, since it can be blocked by the thief or offline. The correct action is a wipe that removes corporate data. Reset is intended for repurposing or troubleshooting a device the organisation still physically controls.
D
Select the device and choose 'Delete'.
Why it fails: Delete removes only the Intune device record, so no wipe command reaches the lost device. It is tempting as housekeeping for stale or duplicate records, which is the correct scenario for Delete rather than remote data removal.

Question 18easymulti select

Which TWO are valid methods to enroll Windows devices in Microsoft Intune?

Trap 1: Apple Business Manager

Apple Business Manager enrols iOS, iPadOS and macOS devices via Automated Device Enrolment; it has no Windows provisioning channel. It is tempting because it is a legitimate Intune enrolment method, but only for Apple platforms, so it cannot satisfy a Windows-only requirement.

Trap 2: Android Enterprise

Android Enterprise enrols Android devices through managed Google Play; it provisions no Windows management channel. It is tempting because it is a genuine Intune enrolment method, but it applies only to Android form factors, so it fails a Windows-specific requirement.

Trap 3: Microsoft Entra ID Join

Microsoft Entra ID Join is a device identity state, not an Intune enrolment method; joining alone registers the device in Microsoft Entra ID without creating an MDM enrolment. It is tempting because joined devices can auto-enrol, but the join itself is the prerequisite, not the enrolment mechanism.

A
Apple Business Manager
Why it fails: Apple Business Manager enrols iOS, iPadOS and macOS devices via Automated Device Enrolment; it has no Windows provisioning channel. It is tempting because it is a legitimate Intune enrolment method, but only for Apple platforms, so it cannot satisfy a Windows-only requirement.
B
Manual enrollment using work or school account
Manual work-or-school-account enrolment joins the device to Microsoft Entra ID and registers it with Intune in one user-driven step, satisfying the stem's requirement for a valid Windows enrolment method without requiring Autopilot or bulk provisioning infrastructure.
C
Windows Autopilot
Windows Autopilot enrols devices by binding hardware hash to a Microsoft Entra ID tenant, so the device joins and enrols automatically at out-of-box experience without manual user action. This satisfies the stem's requirement for a valid Windows enrolment method, alongside other supported approaches such as Group Policy or Configuration Manager co-management.
D
Android Enterprise
Why it fails: Android Enterprise enrols Android devices through managed Google Play; it provisions no Windows management channel. It is tempting because it is a genuine Intune enrolment method, but it applies only to Android form factors, so it fails a Windows-specific requirement.
E
Microsoft Entra ID Join
Why it fails: Microsoft Entra ID Join is a device identity state, not an Intune enrolment method; joining alone registers the device in Microsoft Entra ID without creating an MDM enrolment. It is tempting because joined devices can auto-enrol, but the join itself is the prerequisite, not the enrolment mechanism.

Question 19easymulti select

Which TWO are prerequisites for co-management with Microsoft Intune and Configuration Manager? (Select TWO.)

Trap 1: On-premises Active Directory

On-premises Active Directory is not a prerequisite; co-management works with domain-joined, workgroup and Microsoft Entra joined Windows devices provided the Configuration Manager client is installed. It is tempting because Configuration Manager itself requires AD, but co-management enrolment does not depend on it.

Trap 2: Public Key Infrastructure (PKI)

Incorrect. PKI is optional and not a core prerequisite for co-management.

Trap 3: Hybrid Microsoft Entra ID joined devices

Co-management requires Microsoft Entra joined or hybrid-joined devices only for certain workloads; hybrid join is not a prerequisite for enabling the co-management authority itself. It is tempting because hybrid join supports Conditional Access, but device enrolment in Intune and a Configuration Manager client suffice.

A
Devices enrolled in Microsoft Intune
Co-management requires the device to be enrolled in Microsoft Intune so the Intune service can receive policy and workload data alongside Configuration Manager. Without this enrolment, the Configuration Manager client alone cannot hand over workloads, so enrolment satisfies the stated prerequisite.
B
Configuration Manager current branch
Configuration Manager current branch is mandatory because co-management requires the client agent to handle workloads locally while Microsoft Entra ID provides device identity. This satisfies the stem's prerequisite constraint: only current branch builds support the co-management policies and workload sliders that earlier versions lack.
C
On-premises Active Directory
Why it fails: On-premises Active Directory is not a prerequisite; co-management works with domain-joined, workgroup and Microsoft Entra joined Windows devices provided the Configuration Manager client is installed. It is tempting because Configuration Manager itself requires AD, but co-management enrolment does not depend on it.
D
Public Key Infrastructure (PKI)
Why it fails: Incorrect. PKI is optional and not a core prerequisite for co-management.
E
Hybrid Microsoft Entra ID joined devices
Why it fails: Co-management requires Microsoft Entra joined or hybrid-joined devices only for certain workloads; hybrid join is not a prerequisite for enabling the co-management authority itself. It is tempting because hybrid join supports Conditional Access, but device enrolment in Intune and a Configuration Manager client suffice.

Question 20hardmulti select

Which TWO components are required for a successful Windows Autopilot deployment with user-driven Microsoft Entra ID join? (Select two.)

Trap 1: Enrollment Status Page (ESP) configuration.

The Enrollment Status Page is optional; it only controls what users see during provisioning and can block device use until apps install. It is tempting because it appears integral to the out-of-box experience, but user-driven Microsoft Entra join succeeds with just Autopilot registration and a Deployment Profile.

Trap 2: On-premises Active Directory domain join.

On-premises Active Directory domain join contradicts the Microsoft Entra ID join requirement; Autopilot supports either, not both simultaneously. Hybrid Microsoft Entra ID join is tempting because many organisations retain on-premises identities, but that scenario requires the Hybrid Microsoft Entra ID Join deployment mode, not user-driven Entra join.

Trap 3: Microsoft Configuration Manager co-management.

Configuration Manager co-management is optional for Autopilot; user-driven Microsoft Entra join needs only Intune enrolment, Autopilot device registration and the Deployment Profile. Co-management suits organisations managing existing Windows devices with both Configuration Manager and Intune, not this scenario.

A
Enrollment Status Page (ESP) configuration.
Why it fails: The Enrollment Status Page is optional; it only controls what users see during provisioning and can block device use until apps install. It is tempting because it appears integral to the out-of-box experience, but user-driven Microsoft Entra join succeeds with just Autopilot registration and a Deployment Profile.
B
Device registration in the Autopilot service using hardware hash.
Registering the device's hardware hash in the Windows Autopilot service creates the Autopilot device identity, which is mandatory for user-driven Microsoft Entra ID join. Without this record, the device cannot be matched to a deployment profile during OOBE, so the profile's join settings never apply.
C
On-premises Active Directory domain join.
Why it fails: On-premises Active Directory domain join contradicts the Microsoft Entra ID join requirement; Autopilot supports either, not both simultaneously. Hybrid Microsoft Entra ID join is tempting because many organisations retain on-premises identities, but that scenario requires the Hybrid Microsoft Entra ID Join deployment mode, not user-driven Entra join.
D
Windows Autopilot deployment profile in Intune.
A Windows Autopilot deployment profile in Intune defines the join type, naming and out-of-box experience settings. Without it assigned to the registered device, user-driven Microsoft Entra ID join cannot proceed, making it a required component.
E
Microsoft Configuration Manager co-management.
Why it fails: Configuration Manager co-management is optional for Autopilot; user-driven Microsoft Entra join needs only Intune enrolment, Autopilot device registration and the Deployment Profile. Co-management suits organisations managing existing Windows devices with both Configuration Manager and Intune, not this scenario.