Refer to the Exhibit Practice Questions

Telemetry is set to 1 - Basic

Why it fails: The deployed value maps to a different telemetry level than 1 - Basic, so this outcome is wrong. It tempts because 1 - Basic is the common default, but the exhibit's OMA-URI value determines the actual applied level.

The policy applies to users, not devices

Why it fails: Custom OMA-URI policies in Microsoft Intune target devices, so device assignment succeeds. It tempts because many configuration profiles are user-scoped, but OMA-URI settings under the Policy CSP are device-context and cannot be delivered to user scope.

The policy fails because value 0 is not allowed

Why it fails: Value 0 is valid for this telemetry setting, so the policy applies rather than failing. The option tempts because some OMA-URI nodes accept only 1–3, making 0 a common validation error; here the schema permits 0, so rejection does not occur.

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 compliance policy has been removed from these devices.

Why it fails: An elapsed grace period timestamp reflects the compliance policy still being assigned and evaluated; it does not indicate policy removal. Removing a policy would leave the device without that compliance state entirely. The timestamp specifically marks when grace expired, making the device noncompliant and blocked.

The devices are still within the grace period and can access resources.

Why it fails: A grace period expiration timestamp in the past means the grace period has already ended, so the device is fully noncompliant and blocked from conditional-access-protected resources. The option is tempting because grace periods do permit access, but only until that timestamp passes, not after.

The devices were recently remediated and are now compliant.

Why it fails: A past grace period expiration indicates the device remained noncompliant beyond its grace window, not that remediation succeeded. Recently remediated devices report a compliant state, not an expired grace timestamp. The expired timestamp signals continued noncompliance and blocked access.

The BitLocker setting is not supported on Windows 11.

Why it fails: BitLocker is fully supported on Windows 11, so an unsupported-setting claim cannot explain a compliant result. It is tempting because unsupported settings do surface as non-compliant or error states, but here the policy simply omits the BitLocker requirement rather than rejecting it.

The policy was not saved correctly due to a syntax error.

Why it fails: A syntax error would cause the cmdlet to fail outright, so no policy would exist and the device would not report compliant against it. It is tempting because malformed commands do silently create partial policies, but the stem shows the policy was created and evaluated.

The device does not have a TPM chip, which is required for BitLocker, but the compliance policy does not check TPM.

Why it fails: A missing TPM prevents BitLocker from encrypting, yet the policy still reports compliant because it never evaluates TPM or encryption state. It is tempting because TPM is genuinely required for BitLocker, but the policy's omission of that check is the actual cause.

It requires a password that meets the minimum length but no complexity

Why it fails: deviceDefault inherits the platform's own password policy, which on Windows 10 typically enforces length and complexity, so it does not merely impose a minimum length. The option is tempting because some platforms do default to length-only rules, and would be correct where the OS baseline specifies no complexity requirement.

It does not require a password at all

Why it fails: deviceDefault does not waive the password requirement; it defers to the device's existing policy, so a password is still expected. The option is tempting because a permissive default sounds plausible, and would be correct only if the setting were explicitly configured to allow passwordless access.

It requires a password that contains at least one number and one letter

Why it fails: deviceDefault inherits whatever the device's own policy enforces rather than mandating a specific character mix, so it does not guarantee letters plus numbers. The option is tempting because complexity rules commonly appear in baselines, and would be correct if the policy explicitly selected a complexity requirement.

It requires a reboot for the setting to take effect.

Why it fails: Reboot requirements are not what this baseline setting defines; its effect concerns scan behaviour. It is tempting because many Intune security baseline settings do need a restart to apply, but that is a general deployment characteristic, not the specific effect of this scheduled-scan configuration.

It enables real-time protection for scheduled scans.

Why it fails: Real-time protection is a distinct Defender setting controlling continuous monitoring, not a property of scheduled scans. It is tempting because both appear under the same antivirus baseline group, but this setting alters when scheduled scans run rather than enabling real-time protection, which is configured separately.

It disables scheduled scans when the device is in use.

Why it fails: The baseline setting governs scan scheduling behaviour, not whether scans are suppressed during use; disabling scans while the device is active is a separate configuration. It is tempting because scheduled-scan options sit together in the same Defender policy area, but this setting's effect concerns scan timing rather than suspending them.

bitLockerEncryptionMethod set to aes256

Why it fails: This just sets the encryption algorithm.

passwordRequired set to true

Why it fails: This is about device password, not BitLocker.

bitLockerDisableWarningForOtherDiskEncryption set to true

Why it fails: When true, the warning is disabled and BitLocker can enable even if other encryption exists.

To output the device names of all Windows devices.

Why it fails: The script selects device objects rather than projecting the displayName property, so it returns full records, not a names-only output. It tempts because device names are the obvious field to inspect, and adding a Select-Object displayName projection would be correct when a names-only listing is required.

To list devices that are registered in Autopilot.

Why it fails: The script queries Intune managed devices, not the Autopilot device identity collection, so it cannot list Autopilot-registered devices. It tempts because both surfaces describe Windows hardware, and querying the Autopilot device identities endpoint would be correct when auditing which devices are registered for Autopilot deployment.

To update the enrollment type of all Windows devices.

Why it fails: The script filters and reads device objects; it issues no update or patch call, so no enrollment type changes. It tempts because Autopilot and enrollment data appear in device records, and such a script would be correct if it invoked an update on the enrollment configuration rather than only querying devices.

Windows Update is configured to defer updates.

Why it fails: The OMA-URI in the exhibit does not correspond to the Windows Update deferral nodes, so update deferral behaviour is unaffected. Deferring updates would use the Policy CSP Update area with DeferFeatureUpdatesPeriodInDays; this custom policy configures a different setting entirely.

Windows Defender is disabled.

Why it fails: The configured OMA-URI and value do not map to the Defender policy area, so Defender's real-time protection state remains as configured elsewhere. Disabling Defender would require the Policy CSP Defender node with the appropriate value; this policy targets an unrelated setting.

Cortana is enabled.

Why it fails: The OMA-URI path and value in the exhibit target a different policy area than Cortana, so applying it leaves Cortana's state unchanged. A Cortana configuration would use the Policy CSP AllowCortana node under the Search area; this custom policy does not address that node.

The ESP policy is configured to track progress for Autopilot only, but the device is not using Autopilot.

Why it fails: If ESP tracked Autopilot only and the device were not Autopilot-enrolled, the page would not appear at all, so it could not stall on 'Installing apps'. It is tempting because ESP scope settings genuinely determine whether the page is displayed during provisioning.

The user attempted to retry the setup and it was blocked.

Why it fails: A blocked retry would surface an explicit retry-denied message, not an indefinite hang on 'Installing apps'. It is tempting because ESP does expose retry controls, and blocking retries is a genuine configuration used to force devices back through full provisioning.

The device reset on failure is enabled, causing a reset loop.

Why it fails: Device reset on failure restarts a failed deployment rather than leaving it hanging on 'Installing apps'; it triggers only after an error, not during a stalled app install. It is tempting because reset-on-failure is a real ESP setting used to recover failed Autopilot deployments automatically.

The devices are running a non-Windows OS.

Why it fails: The cmdlet lists managed Windows devices, so the returned records are Windows; a non-Windows OS would not appear in this filtered result. It is tempting because OS mismatch can cause noncompliance, but the query scope already excludes other platforms, leaving policy configuration as the likely cause.

The devices have not synced recently.

Why it fails: The exhibit shows lastSyncDateTime is recent, so the devices have checked in and the noncompliant state reflects a failing compliance policy rule, not stale data. It is tempting because unsynced devices do report stale compliance, and it would be correct if the timestamps were days or weeks old.

The admin lacks permissions to view compliance details.

Why it fails: Insufficient admin permissions would hide compliance detail from the portal, but Microsoft Graph returned the noncompliant state and recent sync timestamps, so the data is visible and the cause lies in policy evaluation. It is tempting because role-based access control genuinely restricts reporting, and it would be correct if the cmdlet returned authorisation errors or empty results.

allowStorageCard set to false

Why it fails: allowStorageCard governs access to removable storage such as SD cards and USB drives, so it cannot block Bluetooth peripherals. It is tempting because removable-media restrictions are common in hardened Windows 11 baselines, and a blocked USB device can superficially resemble a Bluetooth failure.

allowCopyPaste set to false

Why it fails: allowCopyPaste controls clipboard sharing between apps or devices, which has no bearing on Bluetooth radio or pairing. It is tempting because clipboard restrictions appear in the same data-protection policy families, and users losing input capability may describe any peripheral as unresponsive.

allowCamera set to false

Why it fails: allowCamera disables the device camera; it does not affect Bluetooth stacks or HID peripherals. It is tempting because camera-blocking settings sit alongside other device restrictions in the same policy, so it looks like a plausible culprit when hardware stops working.

The firewall rule is for outbound traffic, not inbound.

Why it fails: RDP is initiated by the client connecting to the target, so the target requires an inbound allow rule on TCP 3389; an outbound rule governs traffic leaving the device and cannot admit the session. Outbound rules would be the right control when restricting what the protected device may reach externally.

The malware actions are blocking RDP traffic.

Why it fails: Malware actions such as quarantine or block execute only after detection, and they target malicious files rather than the RDP listener or its port. Such actions would be the right response when a known threat is identified. Nothing in the scenario indicates malware is present or that RDP traffic is being filtered.

The firewall rule 'Allow RDP' is configured to allow traffic.

Why it fails: A rule configured to allow RDP permits the traffic, so it cannot explain the connection failure; the exhibit must show a blocking condition instead. Allow rules are the correct configuration when the requirement is to permit remote administration, so this option describes the intended state rather than the fault.

The policy is waiting for user approval

Why it fails: Intune device configuration profiles require no user approval step; assignments apply automatically once targeted. Pending reflects the device not having checked in or reported yet. User approval gates exist for app protection or access requests, which is where awaiting consent would be the accurate description.

The policy assignment failed due to a conflict

Why it fails: Conflicts surface as a distinct error state, not Pending, because Intune resolves or flags them explicitly. Pending simply means the device has not yet reported back on the assignment. Conflict reporting is what you would investigate when two profiles set the same setting to different values.

The policy has been successfully applied

Why it fails: Pending signifies the assignment has not yet reached a terminal state, so the profile has not been applied. Successfully applied assignments report Succeeded. Pending is expected immediately after targeting a device that has not yet checked in, which is when you would confirm deployment rather than assume completion.

Access is blocked because the OS version is below the warning level

Why it fails: Access is not blocked because the OS version meets the minimum requirement.

Access is allowed with a warning to update the app and OS

Why it fails: A warning is not issued because the device's versions are below the warning level, not at or above it.

Access is blocked because the app version is below the warning level

Why it fails: Access is not blocked because the app version meets the minimum requirement.