AD3.13 Check My Knowledge

The attacker gets access because the token has valid MFA — No. CA003 checks device compliance independently from MFA. The token is valid but the device isn't compliant.

Access is blocked because the attacker's laptop isn't enrolled in Intune and doesn't meet compliance requirements — the token is useless without a compliant device — Correct. Device compliance is evaluated at sign-in regardless of token validity. The attacker's device fails the check. Access denied.

The attacker is prompted for MFA again — No. The token carries MFA satisfaction. CA001 is satisfied. Only CA003 (device compliance) blocks the access.

Defender for Endpoint detects the anomaly — Requires E5 and MDE. CA003 works on E3 without MDE.

BitLocker encryption — the most important security check — Most important for security but highest blast radius. Deploy it third, not first.

Minimum OS version — ensures devices are patched — High blast radius if devices are behind on updates. Deploy it last.

Firewall enabled — nearly zero blast radius because it's almost always already on — Correct. The firewall check validates the compliance mechanism with virtually no user impact. Once you confirm policies evaluate correctly with a low-risk check, add higher-risk checks incrementally.

All checks simultaneously — comprehensive protection from day one — Maximum blast radius. If 20% of devices fail BitLocker and 10% fail OS version, you have 30% of users locked out on day one.

Exempt their accounts from CA003 — Creates 20 permanent gaps in device compliance.

Block mobile email access entirely — Disproportionate. Creates shadow IT risk (users forward to personal email).

Require them to enroll or lose email access — Forcing personal device enrollment is legally and culturally problematic without a BYOD policy.

Deploy App Protection Policies for Outlook and modify CA003 to accept either device compliance OR app protection — personal devices get MAM-protected email access without enrollment — Correct. App protection encrypts corporate data within the app, restricts copy/paste, and enables remote wipe of corporate data only. The personal device remains personal. Corporate data is protected at the app level.

Check whether a recently installed application (third-party AV, VPN client, or LOB software) disabled Defender real-time protection. Check the Windows Event Log for Defender state changes and the Intune device configuration for conflicting profiles — Correct. The most common cause of unexpected Defender deactivation is a third-party application that disables it during installation (some VPN clients and security tools do this). The event log shows exactly when and why Defender's state changed. If a new application is the cause, either configure coexistence or remove the conflicting application.

The device is compromised — malware disabled Defender — Possible but less likely than a software conflict. Malware that disables Defender is sophisticated and usually accompanied by other indicators. Check for software conflicts first.

Intune has a reporting error — re-sync the device and check again — Worth trying as a first step but don't assume it's a reporting error. If the sync confirms real-time protection is off, investigate the root cause.

Re-enable Defender and move on — Fixes the symptom but not the cause. If a conflicting application disabled Defender, it will disable it again. Investigate and resolve the root cause.

Immediately after creating compliance policies — No. Compliance policies need time to evaluate devices and for you to remediate non-compliant devices before enforcement.

After compliance rate reaches 95%+, report-only data shows minimal impact, break-glass accounts are verified, and BYOD app protection is deployed — on a Tuesday morning with helpdesk on standby — Correct. All prerequisites met, tested, and verified. Enforcement on a weekday morning when you and the helpdesk are available to handle issues in real-time.

During a weekend maintenance window — No. Enforcement should happen during working hours when issues are discovered immediately and you're available to resolve them.

After 100% of devices are compliant — 100% is an unrealistic target. Some devices will always be in grace period (new enrollments, users returning from leave). 95%+ is the practical threshold.

The custom profile is wrong — remove it and use the baseline — The custom profile was working before the baseline was deployed. The baseline introduced the conflict.

The baseline is wrong — remove it entirely — Removing the baseline also removes other security settings it provided. The issue is the overlap, not the baseline itself.

The same setting is configured in both the baseline and the custom profile with conflicting values. The solution is to use one source per setting — either configure the firewall entirely in the baseline OR entirely in a custom profile, not both — Correct. Overlapping settings between baselines and custom profiles produce unpredictable results. Choose one source of truth for each setting. For most environments with existing configurations, custom profiles are safer because you control exactly what's configured.

Update Intune to resolve the conflict — Intune correctly applies both profiles. The conflict is in the configuration, not the software. Resolve the overlap in your configuration.

Secure Score, number of policies created, and hours spent — Inputs and effort metrics, not outcomes. Management cares about results, not activity.

MFA coverage percentage and device compliance percentage — Configuration metrics without business context. Better than Option A but doesn't connect to business risk.

Number of phishing emails received and number of helpdesk tickets — Operational metrics without security outcome. Phishing volume is a threat metric, not a defense metric.

Attacks blocked (142 credential attacks stopped by MFA), phishing caught (47 emails blocked before reaching inboxes), device protection (100% encryption, 97% compliance), and zero security incidents from protected attack vectors — Correct. These are outcome metrics that connect technical controls to business protection. Each metric answers "what did we prevent?" not "what did we configure?" The zero-incident metric is the capstone: all three layers working together producing a measurable security outcome.

Approximately 30-45 minutes per week: Monday 5-min alert check, Monday 10-min sign-in log review, weekly quarantine/submission review, monthly compliance report, quarterly exception review and management report — Correct. The deployment phase (Modules AD1-AD3) required 5-8 hours per week over 6 weeks. The maintenance phase requires 30-45 minutes per week of monitoring plus quarterly reporting. This is the realistic time commitment for sustaining the security controls — and it's the time commitment you request from your manager going forward.

Zero — the controls are automated and don't need monitoring — No. Automated controls catch threats but require human review for false positives, policy updates, exception management, and incident response. "Set and forget" is how security controls drift to ineffectiveness.

Full-time security monitoring — you need a dedicated security analyst — Not at 200 users. A dedicated analyst is justified at scale, but the monitoring cadence for a 200-user tenant fits within 45 minutes per week alongside your existing IT responsibilities.

2-3 hours per day checking every portal — Disproportionate. The structured monitoring cadence (weekly alerts, monthly compliance, quarterly reporting) covers the necessary checks in a fraction of this time.