Hard Difficulty Questions

Threat analytics

Why it fails: Threat analytics publishes intelligence reports about emerging threats; it configures no automated investigation or response behaviour. It is tempting because it is a Defender XDR feature relating to threats, and would be correct when researching an active campaign to decide manual remediation steps.

Device inventory

Why it fails: Device inventory merely lists onboarded devices and their health; it exposes no setting that turns on automatic investigation and response. It is tempting because it is where devices appear, and would be the right place when checking onboarding status or excluding a device from automated actions.

Alert queue

Why it fails: The alert queue only lists and triages generated alerts; it holds no toggle that enables automated investigation and response. It is tempting because alerts are the visible output of detection, and reviewing them is the correct task when manually triaging incidents rather than configuring automation.

To enroll a new device that was not purchased through an OEM.

Why it fails: Autopilot Reset is for devices already enrolled via Autopilot.

To change a device from Microsoft Entra ID joined to Hybrid Microsoft Entra ID joined.

Why it fails: Autopilot Reset does not change the join type.

To deploy a custom Windows image to a device.

Why it fails: Autopilot Reset uses the built-in recovery, not custom images.

Configure a compliance policy to mark the device as noncompliant.

Why it fails: Compliance policies trigger actions like blocking, not data removal upon unenrollment.

Configure a remote lock action.

Why it fails: Remote lock only locks the device, it doesn't remove data.

Configure a full wipe action.

Why it fails: Full wipe removes all data (corporate and personal).

Ensure the device has internet connectivity.

Why it fails: Network issues would affect all policies.

Check that the script is digitally signed.

Why it fails: Script signing is required if the execution policy is restricted.

Verify that the device is in the correct security group.

Why it fails: Group assignment is correct.

%windir%\temp\MdmEnrollment.log

Why it fails: This logs MDM enrollment but not provisioning package details.

%windir%\Panther\setupact.log

Why it fails: This logs Windows setup, not provisioning.

Event Viewer under Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider

Why it fails: This is a provider, not a single log file.

The devices are not joined to Microsoft Entra ID.

Why it fails: Entra ID join is not required for BitLocker policy.

The BitLocker policy is configured only for Windows 11 Enterprise devices.

Why it fails: The scenario does not mention edition restriction.

The devices are running Windows 10 instead of Windows 11.

Why it fails: BitLocker works on Windows 10 as well.

It sets the Windows Update for Business ring to that version.

Why it fails: The setting defines the minimum OS build a device must run to be marked compliant; it does not configure update rings. Update rings are tempting because they also reference versions, but they belong to Windows Update for Business policies that schedule and defer feature updates, not to compliance evaluation.

It requires the device to be on a specific feature update.

Why it fails: The `osMinimumVersion` setting enforces a floor on the OS build number, not a specific feature update; a device on any later build still passes. It is tempting because feature-update control is a genuine compliance need, and it would be the right choice when the requirement is to pin devices to one exact Windows release.

It forces the device to update to that version.

Why it fails: Compliance policies only report and conditionally block access; they never push updates to devices. Forcing installation is the role of update rings or feature update policies in Microsoft Intune, which is why the wording misleads.

The device is low on storage

Why it fails: Storage would show an error, not just fail silently.

The app is available but not required

Why it fails: The app is assigned as required, so user acceptance is not needed.

The device has offline files enabled

Why it fails: Offline files are unrelated.

Use a 'Quality update deferral period' of 48 hours and a 'Feature update deferral period' of 60 days in a Windows 10 update ring.

Why it fails: Deferral periods are configured in days, not hours, so a 48-hour value is invalid and cannot enforce the 48-hour deadline. Hour-based deferral suits scenarios needing sub-day granularity, but Windows Update for Business rings only accept whole-day quality update deferrals.

Set the 'Update notification level' to '2 - Disable all notifications' and configure active hours.

Why it fails: Disabling notifications and setting active hours controls when devices reboot, not when updates are offered or installed, so the 48-hour deadline is unenforced. This configuration suits managing user disruption in kiosk or shift-worker scenarios, not meeting a security-update SLA.

Configure a 'Quality update deferral period' of 2 days and a 'Feature update deferral period' of 60 days.

Why it fails: A two-day quality update deferral delays updates by 48 hours before installation begins, so the 48-hour deadline is missed. Day-based deferral is correct when the requirement allows several days of staging, but here it breaches the mandated 48-hour window.

Android Enterprise corporate-owned fully managed devices

Why it fails: These give full control over the entire device, not separation.

Android Enterprise corporate-owned dedicated devices

Why it fails: These are for kiosk-style devices, not for personally-owned devices.

Android Enterprise corporate-owned work profile

Why it fails: This is for corporate-owned devices, not personally-owned.

The deferral settings are too long.

Why it fails: Deferral affects timing, not whether updates are offered.

The update ring is assigned to the correct device group.

Why it fails: The update ring is configured.

The devices are compliant with the compliance policy.

Why it fails: Compliance is separate from update delivery.

Create a security group in Microsoft Entra ID and manually add devices with high threat

Why it fails: Manual management is not dynamic and not recommended.

Create a device group in Microsoft Defender for Endpoint and assign it to a compliance policy

Why it fails: MDE machine groups cannot be assigned to Intune compliance policies.

Create a dynamic device group in Microsoft Intune using a rule based on threat level

Why it fails: Intune does not support dynamic groups based on MDE threat level.

Modify the Conditional Access policy to require device compliance.

Why it fails: Conditional Access does not control threat level.

Configure the 'Machine risk score' in Defender for Endpoint.

Why it fails: The risk score is used by Intune, but the compliance policy setting controls the threshold.

Whitelist the specific threats in Defender for Endpoint.

Why it fails: Whitelisting is not available for compliance.

The user manually changed the setting after the policy applied.

Why it fails: Intune policies should reapply on next sync.

Windows Defender is blocking the policy application.

Why it fails: Windows Defender does not block configuration policies.

A conflicting Group Policy object is overriding the Intune policy.

Why it fails: Group policies can override, but this is less likely than assignment issue.

Add the device to a hybrid Microsoft Entra ID join profile.

Why it fails: Hybrid join is for on-premises AD integration, not needed here.

Modify the Autopilot deployment profile to set 'Join to Microsoft Entra ID as' to 'Microsoft Entra ID registered'.

Why it fails: That would cause the issue.

Modify the enrollment restrictions to block personally owned devices.

Why it fails: This does not affect the join type.

BitLocker is not enabled on the device.

Why it fails: The exhibit shows bitLockerEnabled: true, and the device has it enabled.

Secure Boot is not enabled on the device.

Why it fails: The exhibit shows secureBootEnabled: true, and the device has it enabled.

The firewall is not enabled on the device.

Why it fails: The exhibit shows activeFirewallRequired: true, and the device has it enabled.

The policy does not include iOS as a device platform.

Why it fails: iOS should be included but that alone doesn't explain all devices.

The Grant control is set to 'Require one of the selected controls' instead of 'Require all'.

Why it fails: The grant control should be 'Require device to be marked as compliant'.

The policy is not scoped to all users.

Why it fails: User scope is not the issue; the policy should apply to all users.

Devices are noncompliant and blocked from receiving updates

Why it fails: Noncompliance doesn't prevent updates; it may affect access.

Devices are not enrolled in Intune

Why it fails: If assigned, devices are enrolled.

Devices are not connected to the internet

Why it fails: If some devices are affected, connectivity is unlikely the cause for all.

Device compliance policy

Why it fails: Compliance policies do not enforce passcode requirements; they only report compliance.

Device configuration profile (custom)

Why it fails: Custom profiles are for settings not available in built-in profiles.

App protection policy

Why it fails: App protection policies manage data within apps, not device-level passcode.

The TPM is not initialized.

Why it fails: TPM issues would prevent encryption, but protection off indicates suspension.

The device has a recovery password protector but no TPM protector.

Why it fails: A recovery password protector alone still permits protection to be On; its presence does not produce 'Protection Off'. It is tempting because recovery password protectors are a normal BitLocker configuration, and this arrangement would be valid where TPM is unavailable and a password protector is used instead.

The device uses a different encryption method (e.g., XTS-AES 256 vs AES 128).

Why it fails: The encryption algorithm (XTS-AES 256 versus AES 128) does not govern whether BitLocker protection is active; 'Protection Off' means protectors are suspended or absent regardless of cipher. It is tempting because cipher strength is a genuine BitLocker setting, and it would matter when configuring encryption method via Intune disk encryption policy.