SC-100 Practice Question: Design security solutions for applications and data

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Create a Microsoft Sentinel automation rule that triggers a playbook to run an Azure Automation runbook to modify the NSG.

  Why this is correct

  Microsoft Sentinel automation rules are designed to invoke playbooks (Logic Apps) in response to security alerts. A playbook can call an Azure Automation runbook, which can programmatically update the NSG to add a deny rule for the compromised VM, quarantining it from network traffic. This is the correct SOAR-based remediation approach because it leverages Sentinel's native alert triggers and Azure Automation's compute capabilities.

• ✗

  Configure a Log Analytics workspace query to run on a schedule and automatically block the VM.

  Why it's wrong here

  A Log Analytics workspace scheduled query (e.g., an alert rule using KQL) is a read-only detection mechanism; it can query security event data but cannot directly execute remediation like blocking a VM. While a scheduled alert can trigger an action group, that action group would still need a runbook or webhook to modify the NSG—the query itself has no ability to mutate Azure resources. Therefore, this option incorrectly implies the query performs the blocking action independently.

• ✗

  Use Azure Policy to audit and automatically remediate non-compliant VMs.

  Why it's wrong here

  Azure Policy is a governance and compliance service that evaluates resource configurations against policy definitions and can remediate drift (e.g., deploy necessary extensions, alter tags), but it is not an incident response tool. It cannot react to a dynamic Sentinel alert about a compromised VM in real time; policies apply continuously to resource states and are not designed to quarantine a VM after a security detection. Thus it fails to address the immediate threat isolation requirement.

• ✗

  Enable Microsoft Defender for Cloud's 'Just-in-time VM access' policy.

  Why it's wrong here

  Microsoft Defender for Cloud's Just-in-time (JIT) VM access is a proactive security control that locks down inbound traffic to management ports and grants temporary access when approved. It only reduces the attack surface but provides no mechanism to automatically isolate or block a VM once it is already detected as compromised by Sentinel. The feature is about granting user access, not about quarantining a host after a breach, so it cannot fulfill the isolation requirement.

Go deeper

Related to this question