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 detects when a user account is created in Azure AD and then within 5 minutes attempts to access a sensitive SharePoint site. What should they use to correlate these two events?

⚠ Common exam trap

Test-takers frequently confuse a Watchlist (used for static lookups) with a correlation mechanism, or mistakenly think Automation rules or Playbooks can perform event correlation, when in fact only KQL queries with joins can correlate multiple events in a single detection rule.

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

✓

KQL query with join on UserId

A KQL query with a join on UserId allows you to correlate two separate tables—such as AuditLogs for user creation and SharePoint access logs—based on a common field (UserId) within a specified time window (5 minutes). This is the standard method in Microsoft Sentinel for creating multi-event detection rules that require temporal correlation between distinct activities.

Answer analysis

Option-by-option breakdown

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

✓
KQL query with join on UserId
Why this is correct
A KQL query with a join on UserId is the correct choice because it directly correlates events from multiple Sentinel tables, such as SigninLogs and AuditLogs, on a common field to detect suspicious patterns. The join operator in KQL supports different join kinds (inner, leftouter, etc.) to capture matching or non-matching records, enabling the security team to define precise detection logic. This alignment between the query's data correlation and the scenario makes it the only option that fulfills the requirement for real-time detection.
✗
Watchlist
Why it's wrong here
Watchlists are static, manually maintained lists of data—such as known malicious IPs, compromised accounts, or high-value assets—that Sentinel uses for enrichment or filtering within queries. They are not designed for dynamic correlation of live event streams; a watchlist can only be referenced as a lookup table, not joined in real time across multiple sources on UserId. Therefore, while watchlists add context to analytics rules, they cannot provide the event-to-event correlation the scenario requires.
✗
Automation rule
Why it's wrong here
Automation rules in Sentinel automate incident management and response processes—for example, assigning severity, adding tags, or triggering a playbook—when an alert is generated. They do not contain detection logic and have no built-in capability to correlate events across data sources; they act solely on the output of an analytics rule. Using an automation rule would not create the desired detection, as it does not analyze query results or perform joins on UserId.
✗
Playbook
Why it's wrong here
Playbooks, built on Azure Logic Apps, execute a series of actions—such as blocking a user, sending email, or resetting credentials—when an alert or incident is created. They are response workflows that operate after detection, not during it. A playbook does not define what events are correlated or how they are joined; it consumes the alert generated by the analytics rule and cannot serve as the primary detection mechanism for the security team.

Go deeper

AZ-500 Manage identity and access Practice Question

Why each option matters

Option-by-option breakdown

Related to this question