SC-100 Practice Question: Design solutions that align with security best practices and priorities

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 Office communication application from creating child processes

  Why it's wrong here

  This ASR rule restricts Office communication applications such as Outlook and Skype from spawning child processes, a common vector for phishing payloads and macro-based exploits. The block is based on the process relationship and product behavior, not on the reputation, prevalence, or age of the executable being launched. Therefore, it does not satisfy the question's requirement of a prevalence- or trust-based executable blocking rule.

• ✗

  Block credential stealing from the Windows local security authority subsystem

  Why it's wrong here

  This rule protects the Local Security Authority Subsystem Service (LSASS) from credential-theft techniques such as mimikatz, by blocking suspicious access or code injection into the process. Its enforcement is tied to Windows security features like Credential Guard and focuses on memory and process integrity, not on the prevalence or trustworthiness of executables on disk. Consequently, it addresses a different attack surface than reputation-based executable blocking.

• ✗

  Block untrusted and unsigned processes that run from USB

  Why it's wrong here

  This ASR rule targets execution from USB devices by allowing only signed and trusted processes to run from removable media. The decision hinges on the file's signature and the USB-specific context, rather than on a cloud-delivered prevalence score, age, or a globally trusted list of known-good executables. It mitigates a distinct threat vector, so it does not match the criteria-based executable gating described in the correct answer.

• ✓

  Block executable files from running unless they meet a prevalence, age, or trusted list criteria

  Why this is correct

  This is the exact Microsoft Defender for Endpoint ASR rule that uses cloud-delivered reputation to block executable files that lack sufficient prevalence, are too new (low age), or do not appear on a trusted list. Before allowing the process to run, the endpoint consults Microsoft's reputation service and enforces the decision based on those collective metadata signals. This behavior directly matches the scenario in the question, making it the correct choice.

Go deeper

Related to this question