AZ-500 Manage identity and access Practice Question

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 with entity mapping.

  Why this is correct

  Scheduled query rules are the only listed Sentinel analytics rule type that execute custom KQL directly against Log Analytics workspace tables, so an analyst can write a query that joins storage logs, sign-in logs, and other data sources within a defined lookback window to detect multi-event sequences. Entity mapping is what turns query result rows into normalized alert entities—Account, Host, IP, URL—so Sentinel can enrich the incident, correlate related alerts, and pass machine-readable context to playbooks and investigations. This makes it the correct choice when the SOC needs custom detection logic that matches a specific attack pattern rather than relying on a built-in source alert.

• ✗

  Fusion rule.

  Why it's wrong here

  Fusion rules rely on machine-learning correlation over alerts already generated by Microsoft security products such as Microsoft 365 Defender, Defender for Cloud, and Microsoft Entra ID Protection; they do not query raw workspace data or custom log sources like storage diagnostics. An analyst cannot configure a Fusion rule with custom KQL, entity mappings, or arbitrary table inputs—instead, Fusion automatically recognizes multi-stage attack narratives from alert metadata such as kill-chain phases, severity, timestamps, and shared entities. Because the detection scenario requires querying custom storage logs directly, Fusion is not applicable.

• ✗

  Microsoft Security incident rule.

  Why it's wrong here

  A Microsoft Security incident analytics rule is essentially an incident ingestion pipeline: it subscribes to incidents already produced by upstream Microsoft services and copies them into Sentinel based on filters like service, severity, and incident name, not on a KQL query. It performs no local correlation or custom log analysis because the detection logic lives entirely in the originating Microsoft security product, and it cannot inspect custom tables such as storage account logs or Sysmon for event sequences. This rule type is therefore irrelevant when the analyst needs to author custom multi-event detection logic in Sentinel.

• ✗

  Anomaly rule.

  Why it's wrong here

  Anomaly analytics rules use built-in machine-learning models—such as anomalous sign-in behavior, unusual resource creation, or abnormal data extraction—to learn a statistical baseline from historical Sentinel data and then generate alerts when new activity deviates beyond an expected threshold. They are not query-driven, do not accept custom KQL, and cannot be pointed at arbitrary log sources like storage audit logs to find a specific sequence of correlated events; they also lack the explicit entity mapping used to normalize deterministic pattern matches. For a known multi-event detection scenario, an anomaly rule would only indicate that something is statistically unusual rather than confirm the analyst's exact correlation logic.

Go deeper

Related to this question