MS-102 Practice Question: Manage security and threats by using Microsoft Defender XDR
A security administrator wants to prevent Microsoft Office applications (Word, Excel, PowerPoint) from creating child processes, which is a common technique used by malware to execute malicious code. Which attack surface reduction (ASR) rule should be enabled?
⚠ Common exam trap
It's easy for candidates to confuse 'creating child processes' with 'creating executable content' or 'blocking Win32 API calls,' leading them to choose options that address file writes or macro restrictions rather than the specific process spawning behavior.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Block all Office applications from creating child processes
The ASR rule 'Block all Office applications from creating child processes' (GUID: D4F940AB-401B-4EFC-AADC-AD5F3C50688A) specifically prevents Word, Excel, and PowerPoint from spawning child processes such as cmd.exe, PowerShell, or wscript.exe. This directly mitigates a common malware technique where Office macros or exploits launch malicious executables. The rule is part of Microsoft Defender for Endpoint's attack surface reduction capabilities and is designed to stop process injection and lateral movement without blocking legitimate Office functionality.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Block all Office applications from creating child processes
Why this is correct
This Attack Surface Reduction (ASR) rule, identified by rule GUID 26190899-1602-49e8-8b27-eb1d0a1ce869, specifically targets the parent-child relationship where winword.exe, excel.exe, or powerpnt.exe attempts to launch any secondary executable. By blocking the creation of child processes such as cmd.exe, powershell.exe, or wscript.exe, it directly neutralizes the described macro-based attack chain before the payload can execute. This is the only option among these that was designed to stop exactly this process-spawn behavior.
- ✗
Block executable files from running unless they meet a prevalence, age, or trusted list criteria
Why it's wrong here
This ASR rule, GUID 01443614-cd74-433a-b99e-2ecdc07bfc25, evaluates the executable's reputation, file prevalence, and signing age before allowing it to run, independent of which parent process requested it. An attacker leveraging Office-generated child processes can easily use a legitimate, trusted system binary such as rundll32.exe or mshta.exe, which would pass the prevalence and trust criteria. Because it does not inspect the parent process or the Office-to-child relationship, it will not block the described behavior, and its focus on file reputation makes it an inappropriate defense here.
- ✗
Block Office applications from creating executable content
Why it's wrong here
The ASR rule 'Block Office applications from creating executable content' (GUID 3b576869-a4ec-4529-8536-b80a7769e899) prevents Office apps from writing files such as .exe, .dll, or .scr to disk, which is a common dropper behavior in early-stage malware. The described child-process attack does not require writing any executable file; a macro can call VBA's Shell() function or use WScript.Shell to launch PowerShell directly in memory, so no executable content is created on disk. This rule is specifically about file creation, not process creation, and would not trigger on the described parent-child process invocation.
- ✗
Block Win32 API calls from Office macros
Why it's wrong here
This rule (GUID 92e97fa1-2edf-4476-bdd6-9dd0b4dddc7b) prevents VBA macros from making direct Win32 API calls commonly used for shellcode injection, such as VirtualAlloc, WriteProcessMemory, or CreateRemoteThread, to execute code in another process's memory space. In the described scenario, the attacker is not injecting into an existing process; they are having Office spawn a brand-new child process like cmd.exe via VBA's Shell function or COM objects. Blocking Win32 API calls does not block these higher-level shell commands, because Shell() and WScript.Shell are built-in scripting facilities, not direct Win32 API enumerations. Therefore, this rule addresses in-memory payload execution rather than child process creation.
Go deeper
Related to this question
Learn chapter
Microsoft 365 Tenant Setup
Key term
Attack surface reduction
Attack surface reduction is a set of security practices that minimizes the number of ways an attacker can access or exploit a system by removing unnecessary features, locking down configurations, and controlling software behavior.
Key term
Malware
Malware is any software intentionally designed to cause damage, disrupt operations, steal data, or gain unauthorized access to computer systems.
About these practice questions
This MS-102 question is part of Courseiva's 241-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This MS-102 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the MS-102 exam.