AZ-305 Practice Question: Design identity, governance, and monitoring solutions

Answer analysis

Option-by-option breakdown

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

• ✓

  Use the built-in 'Brute force attack against an Entra ID account' analytics rule in Microsoft Sentinel and connect a playbook to disable the user.

  Why this is correct

  The Microsoft Sentinel built-in analytics rule 'Brute force attack against an Entra ID account' already contains the KQL detection logic needed to identify repeated failed sign-ins and other brute-force indicators in Entra ID sign-in logs. By triggering an automation rule on the alert, you can invoke a Microsoft Sentinel playbook—an Azure Logic Apps workflow—that automatically disables the compromised user account. This provides both automated detection and automated response, satisfying the requirement to use built-in rules whenever possible.

• ✗

  Use Microsoft Entra Identity Protection to detect brute-force and configure a conditional access policy to block sign-ins.

  Why it's wrong here

  Microsoft Entra Identity Protection can flag brute-force-like behavior as risky sign-ins and a Conditional Access policy can block the session or require step-up authentication, but blocking a sign-in does not alter the account's enabled state. Identity Protection lacks the native capability to disable a user account as a remediation action. Therefore, even though detection and blocking are automated, the required outcome—disabling the user—would not be achieved, so this is not an acceptable solution.

• ✗

  Stream sign-in logs to Log Analytics and create a scheduled query that alerts on multiple failures, then manually disable accounts.

  Why it's wrong here

  Streaming Entra ID sign-in logs to Log Analytics gives you raw data, and a scheduled query can alert when an account has many failed sign-ins over a time window. However, the response in this option is manual—an operator must investigate the alert and then manually disable the account—which does not satisfy the requirement for automated response. Additionally, building a custom scheduled query duplicates detection that Microsoft Sentinel already provides in its built-in brute-force analytics rule, making this approach less efficient and not the recommended 'built-in first' pattern.

• ✗

  Create a custom KQL query in Microsoft Sentinel and configure an automation rule to disable the account.

  Why it's wrong here

  A custom KQL query is unnecessary because Microsoft Sentinel includes a built-in analytics rule specifically for detecting brute-force attacks against user accounts, which satisfies the requirement to use built-in rules where possible. This option is tempting because custom KQL queries offer flexibility for unique detection scenarios, and would be correct if the required detection pattern were not already covered by a pre-existing rule in Sentinel.

Go deeper

Related to this question