Manage a security operations environment →easyMultiple Choice

SC-200 Manage a security operations environment Practice Question

You are configuring Microsoft Sentinel to detect potential ransomware activity. The security team wants to be alerted when a single host contacts multiple suspicious domains within a short time. Which analytic rule type should you create?

⚠ Common exam trap

Many candidates confuse NRT rules with scheduled query rules, assuming a scheduled rule can achieve the same low latency by setting a short interval, but scheduled rules still incur a processing delay and cannot match the continuous streaming evaluation of NRT rules.

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

✓

NRT (Near-Real-Time) rule

A NRT (Near-Real-Time) rule is the correct choice because it continuously processes events with a minimum latency of about 1 minute, making it ideal for detecting patterns like a single host contacting multiple suspicious domains within a short time window. Unlike scheduled rules that run on a fixed interval (e.g., every 5 minutes), NRT rules evaluate data as it arrives, enabling rapid detection of multi-event sequences such as DNS queries to known malicious domains.

Answer analysis

Option-by-option breakdown

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

✓
NRT (Near-Real-Time) rule
Why this is correct
A Near-Real-Time (NRT) rule in Microsoft Sentinel evaluates the triggering query every minute with a maximum lookback of 30 minutes, using streaming analytics to preserve event ordering and timing. This enables you to catch rapid sequences of events—such as multiple failed logons immediately followed by a successful authentication—that would be missed by periodic batch processing. NRT rules are specifically engineered for low-latency, time-sensitive detections while still allowing KQL logic to match the exact pattern.
✗
Scheduled query rule
Why it's wrong here
A scheduled query rule runs on a predetermined cadence (for example, every 5 minutes or once per hour) and processes a batch of events from a lookback period, so detection latency is bound by the schedule interval. Because events are collected and analyzed together, the precise sequence and timing of a fast chain may be lost—if the events span two separate run windows, the rule never sees the complete chain. While scheduled rules offer the most flexible KQL capabilities, they are not appropriate for sub-minute or order-sensitive detection scenarios.
✗
Anomaly rule
Why it's wrong here
Anomaly rules in Sentinel leverage machine learning to detect deviations from statistically established baselines, such as an unusual spike in sign-in failures, rather than matching a predefined event sequence. They require training data and produce results based on anomaly scores, so you cannot configure them to look for an exact series of event types with specific timestamps. This makes them unsuitable for identifying a known, rapidly occurring pattern that you can explicitly define with deterministic query logic.
✗
Microsoft security rule
Why it's wrong here
Microsoft security rules are out-of-the-box, predefined rules that automatically ingest and map alerts from Microsoft security products like Microsoft Defender for Cloud, Defender for Endpoint, and Microsoft Entra ID Protection. These fixed templates do not allow you to alter their underlying queries or create a custom detection from scratch, so they cannot capture a bespoke sequence unique to your environment. For any custom pattern, you must build your own rule using NRT, scheduled, or other customizable rule types rather than rely on these rigid templates.

Go deeper

SC-200 Manage a security operations environment Practice Question

Why each option matters

Option-by-option breakdown

Related to this question