Refer to the Exhibit Practice Questions

Automatically resolve incidents related to malware

Why it fails: This rule is not performing a status change to 'Resolved' on incidents. In Microsoft Sentinel, an automation rule's action can change the incident status (for example, set to Active, New, or Closed), but the action configured here is 'Run playbook,' which invokes a Logic App workflow. Additionally, the rule's condition is narrowly scoped to alert titles containing 'Malware'—not all incidents that are merely 'related to malware'—so the wording overstates both the trigger scope and the action type.

Automatically close incidents with 'Malware' in the title

Why it fails: The rule does not have a 'Close incident' action; closing an incident requires changing its status to 'Closed' and typically supplying a classification and classification reason. The configured action is to execute a playbook, not to modify the incident state at all. Also, the condition is based on the alert title containing 'Malware' at incident creation time, not on the incident title itself, so 'incidents with Malware in the title' misstates the condition.

Create a playbook for malware alerts

Why it fails: The automation rule does not create a Logic App or define a playbook; playbooks are authored separately in Azure Logic Apps and then referenced by an automation rule's 'Run playbook' action. Creating a playbook requires designing a workflow with connectors and triggers, which is outside the scope of the automation rule configuration shown. Thus, 'create a playbook' confuses the rule's execution action with the development of the automation artifact itself.

To investigate a new type of attack pattern

Why it fails: The KQL query references a specific, known alert type—it filters on a fixed alert name (e.g., 'Suspicious process executed') and then aggregates counts. Investigating a new attack pattern requires exploratory searches across raw event tables with pattern detection or baseline anomaly analysis, not a rule‑bound alert aggregation. Because the query starts from a predetermined detection name, it can only shed light on variations of a known behavior, never on unreported or novel attack techniques.

To identify which accounts are associated with the most incidents

Why it fails: The query groups and counts alerts by account, not incidents; incidents are the correlated, triaged case entities that may bundle multiple alerts. To rank accounts by incident count you would need to join SecurityIncident with SecurityAlert, group by the affected account through entity mapping, and then count incident IDs. This query operates entirely on the alert table (or similar), so it can never produce an incident-centric view, nor does it include the correlation logic that distinguishes incidents from raw alerts.

To find accounts that have generated false positive alerts

Why it fails: The query does not incorporate any field that records alert classification, such as triage status, rep, or analytics rule's false-positive tuning. It merely calculates the number of suspicious process alerts per account over the last 7 days; a high count could indicate legitimate admin activity or a compromised user, indistinguishable from false positives. To find false positives you would need to inspect the actual process execution details (e.g., path, command line) and compare against customer-approved software baselines or look at the 'remediation' and 'status' columns in the incident/alert tables.

It assigns the incident to the SOC team.

Why it fails: The automation rule shown contains no 'Assign owner' action, which is the specific action that would set the incident's owner to the SOC team. Without that action, the rule cannot perform any ownership assignment. Changing the status to 'Active' does not implicitly assign an owner; owner assignment requires an explicit action in the rule definition.

It suppresses the incident if it is a false positive.

Why it fails: There is no 'Suppress incident' action in this automation rule, nor do automation rules support suppressing incidents as a built-in action. Suppression in Microsoft Sentinel is typically configured at the analytics rule level (e.g., stopping and re-running an alert) or handled by a playbook that closes the incident as a false positive. Since the rule only changes the incident status, it cannot suppress anything, and a status of 'Active' actually keeps the incident visible for investigation.

It creates a task in the incident for investigation.

Why it fails: The rule does not include a 'Create task' action. Microsoft Sentinel automation rules can create investigation tasks for analysts, but that requires the specific action type 'Create task' with a task title and description. This rule's only visible action is 'ChangeStatus,' so it does not add any tasks to the incident.

The device is healthy and has no issues.

Why it fails: The device is healthy and has no issues. This is incorrect because the IsolationStatus field in the Defender for Endpoint output reports network containment state, not the overall security posture or health assessment. A device can be completely healthy yet isolated as a precaution, or compromised while still showing 'Not isolated' if no containment action has been taken. Thus, this option conflates a specific network action with a general health evaluation.

The device is currently being scanned for malware.

Why it fails: The device is currently being scanned for malware. This is misleading because a malware scan is an on-demand or scheduled remediation activity, whereas isolation is a network restriction measure designed to sever a device's communication with the rest of the environment. The 'Isolated' status indicates that an admin or automated response action has contained the device, not that any scanning process is running. Therefore, observing an isolation state gives no indication whether a scan is in progress; these are independent capabilities of the platform.

The device is not isolated and is fully connected.

Why it fails: The device is not isolated and is fully connected. This option is the exact opposite of what the output shows. The displayed 'IsolationStatus' value is 'Isolated', meaning the device has been intentionally cut off from the corporate network, blocking all inbound and outbound traffic except limited communication with Defender for Endpoint cloud services. A fully connected device would have a status of 'NotIsolated' or possibly 'PendingIsolation' if a disconnect action is still being applied.

When an incident is updated with severity High.

Why it fails: This trigger is configured for incident creation, not for incident updates. The condition block is evaluated only when a new incident is created, and the playbook will not fire when an existing incident subsequently has its severity changed to High. The update action would require a separate automation rule or trigger configured for incident update events, which this exhibit does not use.

When an alert is generated with severity High.

Why it fails: This playbook triggers on the Incident entity, not on Alert entities. While alerts can generate incidents, the trigger condition directly inspects the incident's severity property, not the severity of any underlying alert. Even if an alert arrives with High severity, the incident creation must also have High severity for this playbook to run, and the trigger itself is not bound to the alert creation event.

When any incident is created.

Why it fails: The trigger condition narrows the scope to incidents whose severity is exactly High. Therefore, not every incident creation will trigger the playbook; only those with the High severity property will match. Incidents created with Low, Medium, or Informational severities will not pass the condition and will not invoke the playbook.

A Schedule section with frequency and period

Why it fails: A standalone Schedule section with frequency and period is not a deployable resource type. In an Azure Resource Manager template, schedule settings are strictly a property nested inside a valid alert rule resource such as Microsoft.Insights/scheduledQueryRules or Microsoft.OperationalInsights/workspaces/savedSearches/schedules. Without that parent resource, the ARM deployment has no resource type to validate or create, so the schedule values are meaningless and the template will fail. You cannot deploy a frequency and period by themselves; they must be attached to a resource that understands them.

An IncidentConfiguration section

Why it fails: IncidentConfiguration is a nested property of a Microsoft.Insights/scheduledQueryRules resource, not a standalone deployable unit. It controls whether Microsoft Sentinel creates incidents from the alerts generated by that specific scheduled query rule. Because the exhibited template lacks the parent alert rule resource entirely, adding an IncidentConfiguration section leaves the deployment engine with no resource to host it. In short, you are configuring incident behavior for a rule that does not exist in the template, so the deployment will not succeed.

A Query property with a valid KQL

Why it fails: The KQL query is already present in the exhibited template, so adding another Query property with a valid KQL expression is redundant and does not address the missing alert scheduling layer. A well-formed query can identify anomalous data, but it cannot trigger a notification unless a schedule resource or a scheduled query rule references it. In this template, the saved search already contains the correct query; what is absent is the recurrence mechanism that executes the query on a timer. Therefore, adding a query property does not provide the required resource and will leave the template invalid or incomplete.

Change the matchingMethod to 'AnyAlert'.

Why it fails: AnyAlert is a valid matchingMethod value in the groupingConfiguration, but it instructs Sentinel to combine every alert that occurs within the lookbackDuration into one incident regardless of entity similarity. This is the opposite of reducing grouping and would make the SOC even more likely to see a single incident containing many unrelated alerts. Because the objective is to prevent alerts from being grouped together, AnyAlert fails to meet the requirement.

Set 'reopenClosedIncident' to true.

Why it fails: The reopenClosedIncident property controls what happens when a new alert fires and a matching incident has already been closed, not whether alerts are combined when the incident is first created. Setting it to true would cause Sentinel to reopen a closed incident that matches the grouping criteria, but that presupposes grouping is still active and that the alert has been assigned to that existing incident. It does nothing to stop multiple alerts from being bundled into the same incident during the original grouping pass.

Change the lookbackDuration to PT0H.

Why it fails: Changing lookbackDuration to PT0H does not disable grouping, it only narrows the time window within which alerts are evaluated for consolidation. Even with a zero-second lookback, Sentinel can still group alerts that share the exact same occurrence timestamp or that arrive in the same processing batch because the groupingConfiguration remains enabled. To achieve one incident per alert, you must disable grouping itself rather than simply shrinking the lookback window.

All actions execute successfully: task created, playbook runs, incident owner set to SOC-Tier1.

Why it fails: The action sequence in Microsoft Sentinel executes top to bottom, so the task creation and playbook trigger do complete, but the incident-owner modification cannot succeed because 'SOC-Tier1' is neither a user principal name nor an object ID in Microsoft Entra ID. Sentinel's owner property only accepts valid Entra ID identities, and arbitrary strings such as a team name or display name are rejected. Therefore, the claim that all three actions succeed is false.

The rule fails to run because the actions are not in valid JSON format.

Why it fails: The rule is not invalid JSON; the payload parses correctly and the automation engine accepts it before runtime execution. The 'owner' value is a semantic error, not a syntax error — valid JSON with an invalid owner string causes a runtime failure only when the modify action attempts to resolve the identity. Thus the rule does run, but this option mischaracterizes the failure mode as a JSON formatting issue.

The playbook runs first, then the task is created, then the incident is modified.

Why it fails: Automation rule actions execute in the explicit order of the actions array — here the shown configuration lists task creation first, then playbook, then incident modification — so the playbook does not run first. The stated order would occur only if the actions were rearranged in the rule, which is not the case in the exhibit. Because the sequence is enforced by the rule's action list, this option contradicts the actual execution flow.

The user account has been disabled

Why it fails: A disabled user account in Microsoft Entra ID is marked with accountEnabled=false, which blocks all sign-in attempts. The exhibit displays risk-related attributes such as riskLevel and riskState, but no account status field or evidence that the account was disabled. Risk detection and account enablement are independent properties, so being flagged as at risk does not imply the account is disabled.

The user account triggered a Sentinel analytics rule

Why it fails: The riskLevel and riskState fields shown in the exhibit are native properties of Microsoft Entra ID Protection, which continuously evaluates user and sign-in risk. Microsoft Sentinel analytics rules generate alerts or incidents with rule identifiers and associated attack tactics, which are not present here. The absence of any Sentinel artifact indicates that the risk flags originate from Entra ID Protection, not from a Sentinel analytics rule trigger.

The user account has been confirmed compromised

Why it fails: In Microsoft Entra ID Protection, riskState 'atRisk' denotes that suspicious activity has been detected but the account is not yet confirmed as compromised. A confirmed compromise would be represented by a riskState of 'confirmedCompromised' or a riskDetail indicating high-confidence breach activity. Therefore, the atRisk flag alone does not support a confirmed compromise verdict.

Groups alerts into one incident if any entity matches.

Why it fails: The incident creation rule specifies entitiesMatchingMethod as All, not Any. With All, every entity in the alert must match the corresponding entities of a previous alert within the lookback window for the alerts to be grouped. Choosing Any would group alerts that share only one entity, which can incorrectly merge unrelated events that happen to involve a common IP or user.

Creates a separate incident for each alert.

Why it fails: This is wrong because the configuration has groupingEnabled set to true, meaning alerts are intentionally consolidated into incidents rather than each alert becoming its own incident. If separate incidents per alert were desired, grouping would be disabled and each alert would generate a unique incident. The presence of a 5-hour lookback and entity matching rules shows that alert grouping into a single incident is active here.

Suppresses alerts for 5 hours after the first alert.

Why it fails: Incorrect: suppression is disabled (suppressionEnabled: false), so no alert suppression is occurring. The 5-hour window is the lookback duration used for grouping alerts based on matching entities, not a suppression period. Suppression would instead prevent new incidents for the same type of alert after an incident is resolved, which is not how this rule is configured.

The triggerOperator and triggerThreshold are misconfigured.

Why it fails: The triggerOperator and triggerThreshold in a scheduled analytics rule define when an alert is fired based on the query's result count. Here, GreaterThan with a threshold of 0 is exactly correct—it means 'create an alert if there is at least one failed sign-in count,' which matches the brute-force detection intent. This configuration has no bearing on incident grouping; the alert fires properly every time the condition is met. The problematic behavior occurs later, when multiple alerts are (or are not) merged into incidents.

The KQL query is missing a join to include more data.

Why it fails: The KQL query here already performs a summarize count on failed sign-in events, which is sufficient to produce the alert condition. Adding a join would only pull in additional data sources or enrich the result set, but it would not alter how Sentinel aggregates alerts into incidents. Incident grouping is governed exclusively by the 'Incident settings' tab in the rule configuration, not by the query's shape or content. Therefore, the missing join is irrelevant to the reported symptom of duplicate incidents.

The severity is set to High, which prevents incident updates.

Why it fails: Severity is an alert/incident metadata attribute that drives triage priority and reporting, but it has no influence on incident grouping or update behavior. Setting a rule to High simply labels the generated incidents as High; it does not disable the ability to append subsequent alerts to an existing incident. Whether a new incident is created or an existing one is updated depends entirely on the grouping settings (e.g., whether 'group related alerts into a single incident' is enabled and which entities are used). The High severity setting is therefore not the cause of separate incidents.

The playbook resource ID is incomplete.

Why it fails: The playbook resource ID in the exhibit is actually a fully qualified Azure resource path for a Logic App workflow. Even if a portion of the ID were truncated, the automation rule would still evaluate its conditions and trigger the action—only then would the playbook invocation fail due to the invalid reference. Thus an incomplete ID is not the reason the rule never runs; the condition mismatch is what prevents the rule from firing at all.

The trigger type should be 'AlertCreated' instead of 'IncidentCreated'.

Why it fails: Automation rules in Microsoft Sentinel are exclusively event-driven by incident lifecycle events such as 'When incident is created' or 'When incident is updated'; there is no 'AlertCreated' trigger type for automation rules. The 'AlertCreated' concept applies to legacy playbook triggering or analytics rule automation, not to the rule shown. Therefore, leaving the trigger as IncidentCreated is correct and changing it to AlertCreated would be syntactically impossible in this context.

The rule order is set to 1, which is too low.

Why it fails: The order property in an automation rule defines its priority relative to other rules, with lower numbers executing earlier. Setting the order to 1 ensures this rule runs first when multiple automation rules exist—it in no way suppresses execution. Since the rule's issue is that its condition never matches the initial incident state, the order value is irrelevant to why the rule fails to trigger.

The rule will change the severity of the incident to Medium

Why it fails: The rule does not contain any action that modifies the incident's severity. Although High severity appears in the rule, it is used as a condition parameter to match incoming incidents rather than as a value to be assigned. Automation rules can change severity via an 'Update incident' action, but that action is not present here.

The rule will assign the incident to the SOC manager

Why it fails: No ownership or assignment action is defined in this automation rule. The rule's only action is to run a playbook, so it cannot assign the incident to the SOC manager. Assignment would require an explicit 'Assign to' action or a playbook step, neither of which is part of the rule as shown.

The rule will run the playbook when a new alert is created

Why it fails: The trigger for this automation rule is on incident creation, not on alert creation. In Microsoft Sentinel, incidents and alerts are distinct objects: alerts are raw findings, while incidents are collections of related alerts. This rule's condition evaluates the incident's severity property, and it will only run when an incident is created—not when a new alert is generated.

Multiple MFA denial events from a single user.

Why it fails: MFA denial events are represented by distinct Microsoft Entra ID error codes such as 500121 (authentication method required) or 500133 (claim in token is missing or invalid), not by 50057. These denials occur only after the user successfully authenticates their password, whereas a disabled account is rejected before any MFA challenge is issued. Because the query filters specifically on ResultType 50057, it would not capture MFA denial events.

Brute force attacks against Microsoft Entra ID accounts using invalid passwords.

Why it fails: Invalid password attempts trigger ResultType 50126, which indicates a failed primary authentication due to incorrect credentials. In contrast, 50057 means the account exists but is administratively disabled, so even a completely correct password would not allow sign-in. A brute-force attack using guessable passwords would almost exclusively produce 50126 events, not the disabled-account error code this query targets.

Brute force attacks from a single IP address against multiple accounts.

Why it fails: While a single source IP attacking many accounts is a common brute-force pattern, this query's identifying power comes from ResultType 50057, not from the source IP. Brute force attempts against active accounts typically fail with 50126 (bad password) or 50053 (account locked), and only disabled accounts produce 50057. The query groups by user and IP to aggregate results, but the underlying condition is account state, so it cannot be characterized as a general brute-force detection.

Create a workbook in Azure Monitor

Why it fails: The ARM template snippet specifies 'Microsoft.OperationalInsights/workspaces/savedSearches', which deploys a saved search inside an existing Log Analytics workspace. Azure Monitor workbooks are defined as 'Microsoft.Insights/workbooks' and are used for interactive dashboards and visualizations, not for storing query definitions. Therefore, this option incorrectly identifies the resource type in the template.

Create an analytics rule in Microsoft Sentinel

Why it fails: Creating an analytics rule in Microsoft Sentinel would require a resource of type 'Microsoft.SecurityInsights/alertRules' (or 'Microsoft.SecurityInsights/alertRules/scheduled') with properties such as queryFrequency, queryPeriod, and triggerOperator. The snippet's resource type is 'savedSearches', which is a Log Analytics workspace resource, not a Sentinel analytics rule. Analytics rules actively run queries to generate incidents, whereas a saved search merely stores a query in the workspace.

Create a data connector in Microsoft Sentinel

Why it fails: A data connector in Microsoft Sentinel is deployed using resource types like 'Microsoft.SecurityInsights/dataConnectors' and configures ingestion from sources such as Microsoft Entra ID, Office 365, or AWS CloudTrail. The snippet represents 'Microsoft.OperationalInsights/workspaces/savedSearches', which does not enable any data ingestion or connectivity. Saved searches only store KQL queries within a Log Analytics workspace, so this option misidentifies the purpose of the resource in the template.