SC-900 Practice Question: Describe the capabilities of Microsoft security solutions
Your organization uses Microsoft Sentinel as its SIEM. You need to create an analytics rule that detects when a user account is created in Azure AD and then, within 10 minutes, that same account is used to grant admin consent to an application. You have a KQL query that joins AuditLogs and SigninLogs. However, the rule is generating too many false positives. You need to refine the query to reduce false positives. What should you do?
⚠ Common exam trap
Watch out — candidates often think widening the time window or simplifying the query will reduce false positives, but in reality, these changes either increase noise or break the correlation logic, whereas excluding known legitimate accounts directly addresses the root cause of false alerts.
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
✓
Add a condition to exclude accounts that are known admin accounts or service accounts.
Known admin or service accounts are often used for legitimate, automated admin consent grants, which can trigger false positives. By excluding these accounts from the detection logic, the rule focuses on anomalous behavior from non-privileged accounts, reducing noise while preserving the core detection of suspicious account creation followed by admin consent grant.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Change the rule to alert on every admin consent grant event regardless of account creation.
Why it's wrong here
This approach would generate an overwhelming number of alerts, as legitimate applications often require admin consent for permissions to access organizational data. Many SaaS applications and internal tools routinely request and receive admin consent during their setup or updates, making it a common and necessary operation. Alerting on every instance without context would desensitize security teams to actual threats by burying them in noise.
- ✗
Remove the join with SigninLogs and only use AuditLogs.
Why it's wrong here
Removing the join with SigninLogs would eliminate crucial contextual information regarding user authentication attempts immediately preceding or coinciding with the admin consent grant. The SigninLogs provide details like IP address, device information, and authentication method, which are vital for establishing temporal correlation and identifying suspicious login patterns associated with the consent grant. Without this correlation, the ability to detect sophisticated attacks involving compromised accounts granting illicit consent is significantly diminished.
- ✓
Add a condition to exclude accounts that are known admin accounts or service accounts.
Why this is correct
This solution directly addresses the issue of excessive false positives by allowing legitimate administrative and service accounts to perform necessary admin consent grants without triggering alerts. By explicitly excluding these known, authorized entities, the rule focuses on detecting anomalous or unauthorized consent grants from potentially compromised user accounts or malicious actors. This targeted approach significantly reduces alert fatigue, enabling security analysts to concentrate on high-fidelity alerts that indicate actual threats.
- ✗
Increase the time window from 10 minutes to 30 minutes.
Why it's wrong here
Increasing the time window from 10 minutes to 30 minutes would broaden the correlation scope, making it more likely to link unrelated events and generate false positives. A wider window increases the probability of legitimate sign-ins being temporally associated with routine admin consent grants, even if they are not causally related to a malicious activity. This dilutes the precision of the detection rule, making it harder to identify truly suspicious sequences of events indicative of an attack.
Go deeper
Related to this question
Learn chapter
Core Security Concepts
Key term
User
A user is any person, system, or device that interacts with an IT service, resource, or identity system, typically authenticated through credentials and authorized to perform specific actions.
Key term
User account
A user account is a digital identity that allows a person to access a computer system, network, or application with specific permissions and settings.
About these practice questions
This SC-900 question is part of Courseiva's 1,250-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SC-900 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SC-900 exam.