Manage identity and access →mediumMultiple ChoiceObjective-mapped

AZ-500 Manage identity and access Practice Question

A security team uses Microsoft Sentinel. They want to create a custom analytics rule that generates an incident whenever a user from a list of known malicious IP addresses attempts to sign in to any Azure AD app. They have imported the IP list into Sentinel using Threat Intelligence. Which rule type should they use?

⚠ Common exam trap

Many exam-takers confuse NRT rules with scheduled queries, assuming 'near-real-time' is always better for threat intelligence matching, but NRT rules lack the ability to join against the ThreatIntelligenceIndicator table, making scheduled queries the only viable option for this use case.

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

✓

Scheduled query rule

A scheduled query rule is the correct choice because it allows you to run a KQL query at a defined interval (e.g., every 5 minutes) to match sign-in events from IP addresses in a Threat Intelligence indicator. This rule type supports alert grouping and incident creation based on the query results, making it ideal for correlating Azure AD sign-in logs with a known malicious IP list imported via Threat Intelligence.

Answer analysis

Option-by-option breakdown

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

✓
Scheduled query rule
Why this is correct
Scheduled query rules are Sentinel analytics rules that execute a KQL query on a fixed cadence (for example, every 5 or 15 minutes) and can create alerts and incidents based on the returned results. They are the only rule type that supports joining against the ThreatIntelligenceIndicator table, and Sentinel provides 'TI map' templates that match entities such as IP addresses, domains, and file hashes from your imported threat intelligence lists. Because the query is fully customizable, you can filter by indicator expiry, excluded IPs, or severity, and the results feed the incident creation workflow.
✗
Near-real-time (NRT) rule
Why it's wrong here
Near-real-time (NRT) rules run every minute to achieve low-latency detection, but they are constrained to a limited set of data sources and KQL functions. In particular, NRT rules cannot reliably query the ThreatIntelligenceIndicator table or perform the multi-table joins that TI mapping requires, so they are unsuitable for matching against imported IP lists. Their sub-minute schedule is optimized for speeding simple alert patterns on high-velocity logs, not for correlating every log event against a frequently updated external indicator feed.
✗
Microsoft Security rule
Why it's wrong here
Microsoft Security rules are pre-built connector rules that create incidents from alerts raised by Microsoft products such as Defender for Endpoint, Defender for Identity, and Microsoft Defender for Cloud. Their detection logic is defined by the source product and by the rule template, and they do not expose a KQL query editor, so you cannot inject your own threat intelligence indicators or custom TI-matching conditions into them. They are ingestion/pipeline rules rather than custom detection rules.
✗
Anomaly rule
Why it's wrong here
Anomaly rules use built-in machine-learning models that establish baseline behavior per entity and raise incidents when observed activity deviates from that baseline (for example, unusual sign-in patterns or abnormal number of alerts). These models score events based on learned statistical patterns, so they are designed to find 'unknown unknowns' and do not support explicit IP list matching against your imported threat-intelligence data. Anomaly rules also have no query editor and are not tied to TI indicator tables.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question