CCNA Respond to security incidents Questions

Checking the domain controller's Security event log for Event ID 4769 is the correct validation step because this event records every Kerberos service ticket request. In a Golden Ticket attack, the attacker uses a forged TGT to request service tickets, so Event ID 4769 entries will show anomalies such as unusual encryption types (e.g., RC4 when AES is expected), unexpected service names, or client IP addresses that don't align with normal behavior. These anomalies confirm that a forged ticket is being presented.

Bulk downloading many files from a host, especially under a security alert, strongly indicates that an attacker is collecting and removing sensitive data. This aligns with the MITRE ATT&CK exfiltration technique (TA0010), where data is transferred out of the environment via HTTP/S, cloud storage, email, or removable media. The volume and pattern of file downloads make data exfiltration the most reasonable and supported conclusion.

The Microsoft Defender XDR connector streams incidents and alerts from Defender XDR into Microsoft Sentinel, automatically creating matching incidents. Enabling it is the minimum configuration; analytics rules or playbooks are unnecessary for the sync itself.

Once the analyst determines the alert is a false positive, the correct remediation is to re-enable the user account by setting accountEnabled back to true in Microsoft Entra ID, restoring the user's access to Entra ID-protected resources. After making that change, the incident should be closed with classification 'False positive' and a comment documenting that the suspension was erroneous. These two steps together restore service and provide accurate reporting for tuning the analytics rule that caused the false trigger.

Isolation severs the endpoint's network connectivity while preserving its volatile memory and forensic artefacts, immediately halting lateral spread and encryption across the estate. This containment step directly satisfies the stem's requirement for a recommended first response action in Microsoft Defender XDR before eradication or recovery begins.

Investigation is the mandatory first step because Microsoft Defender for Cloud enriches AKS container alerts with the full attack story, affected pod and container identities, MITRE ATT&CK tactics, and associated entities. Opening the alert details lets you confirm whether the activity is a true positive, determine its severity and blast radius, and identify which subsequent containment or remediation action is safe. Proceeding before reviewing these details risks an incorrect response, which is why all other options are premature.

This retrieves all recipients who received the same email from the same sender and subject.

Closing the incident with the classification 'FalsePositive' is the correct remediation because it formally resolves the incident, records that the detected activity was not malicious, and preserves the audit trail. In Microsoft Sentinel, this action updates the incident status to 'Resolved', stores the classification and closing reason in the incident record, and can trigger automation or analytics rule tuning to reduce future false positives.

Microsoft Defender for Office 365 is the correct tool because it natively monitors email flow and protects Exchange Online through threat policies, URL detonation, and attachment sandboxing. It exposes rich hunting telemetry in Threat Explorer, such as email delivery outcomes, URL click verdicts, and user-reported phishing submissions, along with the ability to trace a message's complete path. This direct visibility into the phishing email's origin, targeting, and verdicts makes it the proper investigative surface for a phishing incident. It may later inform pivots to other Defender workloads, but initial triage belongs here.

This option is correct because it exactly matches the rule's configuration: Access is Deny, Direction is Inbound, Source is 10.0.0.5, and Destination is Any. When the Azure Firewall processes inbound packets, any traffic with a source IP of 10.0.0.5 will be dropped before reaching any internal resource. The 'Any' destination ensures the denial applies to all internal IP addresses, ports, and protocols, making this the accurate interpretation of the rule's intent.

Revoking refresh tokens immediately invalidates the attacker's existing sessions, preventing token renewal and further access to SharePoint Online. This satisfies the containment constraint by cutting off persistent access tied to the compromised account, since access tokens alone expire quickly but refresh tokens sustain the intrusion.

The 'When incident is updated' trigger is the correct lifecycle hook because it fires on any change to an incident's properties, including a severity change. Adding a condition that severity equals High ensures the playbook only proceeds for incidents that are or have been set to High, satisfying the requirement. This is the recommended pattern: keep the condition in the automation rule so the playbook is only invoked when the condition is true.

Initiating device isolation from Microsoft Defender XDR contains the threat while the device stays online, satisfying the minimal-disruption constraint. Network isolation blocks all traffic except Defender XDR communication, so the user's session persists and the C2 channel is severed without wiping or powering off the endpoint.

The 'Collect investigation package' action in Microsoft Defender for Endpoint is the correct choice because it automatically assembles a ZIP file containing forensic data from the device, including registry entries, event logs, loaded modules, network connections, and running processes. This artifact is specifically designed for deep investigation and can be downloaded by the analyst for offline analysis. It is a built-in response action that captures the full evidentiary picture needed to determine the scope and origin of the incident.

make_set() is a KQL aggregation function that constructs an array of unique values from a specified column, grouped by one or more key columns. When correlating alerts in a ransomware investigation, you can use make_set(AlertTitle) with a summarize by Account or Hostname to gather all distinct alert names that fired for that entity. This creates a concise, ordered set of alert titles that reveals the sequence or combination of malicious activities, such as initial access and data encryption. It is therefore the correct choice for aggregating alert titles to support correlation analysis.

Resetting the user's password changes the credential so the stolen password is no longer valid for authentication, while revoking sessions through Microsoft Entra ID invalidates any refresh tokens and access tokens the attacker may have obtained. This directly severs the attacker's ability to continue using the compromised account, including mailbox access and other applications. It is the proper immediate containment action for a credential-phishing incident.

Threat Explorer is the correct tool because it is a security hunting and investigation engine built into Microsoft Defender for Office 365 that provides queryable access to email message data and user click activities. It includes a dedicated URL view that reports each click on a Safe Links-protected URL, the identity of the user who clicked it, the verdict applied, and the client app used, with the ability to filter by time, user, and threat type. This makes it ideal for investigating a potential phishing click and correlating it with email delivery and threat intelligence.

Initiating Full isolation from the device's action menu in Microsoft Defender XDR is the correct response because it immediately blocks all network traffic to and from the compromised device except for communication with the Defender for Endpoint service. This keeps the sensor and cloud command channel alive, allowing remediation actions like antivirus scans and collected forensic packages to be delivered. It is a policy-driven, reversible action that prevents ransomware from spreading laterally or reaching command-and-control while preserving your ability to investigate and respond.

Isolation immediately cuts the device's network connectivity, halting any further command-and-control communication or payload download from the malicious IP. This contains the true-positive compromise before lateral movement or additional payloads occur, satisfying the requirement for a first containment step.

Playbooks are Logic Apps triggered by Microsoft Sentinel automation rules, enabling an automated response that calls firewall APIs to block the IP. This satisfies the requirement to block the unapproved external address automatically upon incident creation.

KAPE is specifically designed for live incident response: it collects targeted artifacts such as browser history, prefetch files, registry hives, and recently accessed documents directly from the running system while preserving their timestamps and metadata. Its output is organized and can be processed with timelines, and its operation avoids installing persistent software or altering core system files, so the evidence collection is faster and less intrusive than full disk imaging. By running KAPE during the incident, you capture volatile and semi-volatile evidence that would be lost after a reboot or shutdown, which is why it is a valid live collection method.

Playbooks are Logic Apps workflows that can call external REST APIs, handle API keys via secure inputs, and post results back to the incident as comments, tags, or entities. Automation rules can trigger a playbook automatically when an incident is created, matching the requirement for automatic enrichment on matching incidents. This combination provides the required no-touch, repeatable enrichment using the external threat intelligence platform.

This is the correct approach because an automation rule in Microsoft Sentinel can be configured to trigger immediately upon incident creation and invoke a playbook. The playbook, built in Azure Logic Apps, uses the Microsoft Defender for Endpoint connector's 'Isolate machine' action to send an isolation command to the device. This provides a fully integrated, automated response that directly ties Sentinel's incident detection to the prescribed containment action, without manual intervention or custom script execution.

Threat intelligence connectors are purpose-built data connectors that pull indicators from external sources—such as TAXII feeds, Microsoft Defender Threat Intelligence, or third-party platforms—directly into the normalized ThreatIntelligenceIndicator table. Once ingested, Sentinel automatically enables matching and correlation across analytics rules and detections. This is the correct mechanism for automatically importing and operationalizing TI feeds.

Opening the device timeline reveals the full process tree, parent-child relationships and command lines behind the encoded PowerShell. This lets the analyst confirm whether the activity is genuinely malicious before containment, satisfying the need for immediate triage evidence.

Blocking the recipient domain on the email gateway is an appropriate containment action because it immediately halts the active data exfiltration channel by rejecting any further outbound messages destined for that domain. This measure is applied at the transport layer, so it stops the bleeding without deleting any previously sent evidence, and it preserves the ability to later analyze the full extent of the breach while preventing additional data loss.

Initiating a live response session from the Microsoft 365 Defender portal opens a secure, interactive remote shell to the device, allowing an analyst to execute built-in and custom commands to collect registry keys, running processes, network connections, and specific files into an evidence package. It is the correct choice for immediate forensic triage because it provides direct, time-sensitive access to volatile artifacts without relying on automated detection. The session is fully audited and can be used to run live response scripts or collect suspicious binaries for further analysis.

Reviewing the user's activity log in Defender for Cloud Apps is the foundational step for incident investigation. It provides forensic detail such as exact timestamps, source IP addresses, user agents, and the number of files downloaded, allowing you to compare this behavior against the user's baseline and organizational anomalies. This evidence is required to determine whether the downloads constitute a real exfiltration threat or are an outlier caused by a legitimate business task.

Creating a playbook that invokes a firewall API (via Azure Logic Apps) to block the offending IP is a direct containment action. It severs the attacker's communication path to your environment at the network boundary, without affecting the legitimate user's ability to sign in. This is the immediate, low-disruption response that stops the ongoing brute-force attempts from that source.

Automation rules trigger on incident creation and can filter by tactics and severity, then invoke a playbook. The playbook performs the assignment and posts the Teams notification, satisfying both the triage routing and alerting requirements without manual intervention.

Selective isolation limits outbound and inbound communication to the Defender for Endpoint service channel and permits live response, so you can still run commands to gather forensic artifacts while the attacker is cut off from command-and-control and lateral movement. This matches the requirement to isolate the device yet retain live response capability. You can later release the device from isolation once remediation is verified.

Joining DeviceNetworkEvents on DeviceId and filtering RemoteIP to 203.0.113.1 correlates the existing results with endpoint network telemetry, satisfying the requirement to identify which devices communicated with that IP. DeviceNetworkEvents records inbound and outbound connections per device, so the join surfaces the missing device context.

Disabling the user account via the Microsoft Graph API (PATCH /users/{id} with accountEnabled set to false) immediately prevents the user from authenticating and blocks new token issuance. This identity-level control stops the attacker from accessing any Microsoft 365 resources and is a strong containment measure. Because it also prevents legitimate use, it is often reserved for confirmed compromises and is followed by investigation and remediation.

Disabling the user account in Microsoft Entra ID is the most effective immediate containment step because it blocks all new token issuance and denies sign-in for every application that trusts Entra ID as the identity provider. This cuts off the attacker's access to Microsoft 365, Azure, and any federated SaaS apps using the account. You should also reset the user's password and revoke tokens after disabling, but the disable itself stops the attack in progress.

A Defender for Endpoint indicator with action 'Block' blocks the malicious IP or domain on all onboarded endpoints immediately through Network Protection, regardless of where the devices connect.

The email entity page in Microsoft Defender XDR aggregates the full message body, headers, attachments and related alerts for a specific email, giving the analyst the complete content needed for phishing triage. It is reached from the incident graph or Explorer, unlike the summary views that only show metadata.

Custom detection rules in Microsoft Defender XDR are built with KQL queries over the advanced hunting schema (such as DeviceProcessEvents or DeviceNetworkEvents) and allow you to set automatic response actions directly, including 'Isolate device' as a triggered action. When the query matches a device, the rule natively instructs the Defender for Endpoint sensor to isolate that machine immediately, which is exactly the capability the scenario requires. This is the only option that both detects a suspicious behavior and executes a device-level containment action without relying on external automation.

The Azure Monitor Agent uses data collection rules to gather Windows or Linux security events and performance counters from the VM, forwarding them to the Log Analytics workspace that Microsoft Sentinel ingests. This supplies the telemetry analysts need during incident response.

Automation rules in Microsoft Sentinel are the native orchestration mechanism that can trigger on incident creation (or status change) and execute a playbook. A playbook built in Azure Logic Apps can include the 'Add tag' action from the Sentinel connector, which appends the desired tag to the incident. This directly satisfies the requirement by applying the tag automatically, and it is the documented method for enriching incidents with custom labels because analytics rules and watchlists lack this capability.

A full antivirus scan is an available device response action in Microsoft Defender for Endpoint, running alongside quick scan to detect and remediate malware on the compromised endpoint. It supports containment and eradication without isolating the device or requiring manual intervention.

In the context of a Sentinel incident, external sharing on SharePoint sites is a common data exfiltration vector when accounts are compromised. Removing external sharing permissions—via the SharePoint admin center or PowerShell cmdlets like Set-SPOTenant -SharingCapability—immediately revokes external users' ability to access shared links, cutting off the attacker's current path to exfiltrate data. This is a direct containment action at the data plane, and it is crucial to perform before or alongside user-level blocking to stop exfiltration that has already been enabled.

Microsoft Sentinel permits analysts to classify incidents as False Positive, meaning the alert was triggered but represents no genuine malicious activity. It is one of the platform's built-in classification values used to close incidents and tune analytics rules.

AzCopy transfers data directly into Azure Blob Storage over HTTPS, satisfying the requirement to securely upload forensic artefacts from an unmanaged Linux host. Because the server lacks Microsoft Defender for Endpoint, the built-in live response collection is unavailable, so a manual script paired with AzCopy provides the supported upload path.

Resetting the compromised user's password and revoking all active sessions directly invalidates the stolen credentials—making any cached NTLM hashes, Kerberos TGTs, or delegating artifacts unusable for further authentication. Revoking active sessions (e.g., forcing sign-out or invalidating refresh tokens) ensures that any already-established remote sessions are terminated immediately, rather than waiting for ticket expiry. This stops lateral movement regardless of which workstation the attacker is using or which network path they choose, because the root cause—compromised identity—has been remediated.

Collecting an investigation package from a device is a legitimate Defender for Endpoint response action that bundles the device's relevant forensic artifacts—such as the registry, running processes, network connections, and memory information—into a zip file for offline analysis. It is initiated through the device's action menu, and the package is stored in secure storage for the analyst to download. This action is complementary to isolation and is used to gather evidence without requiring a live remote-command channel to the device.

The Entities tab on the incident page aggregates and displays every entity that Microsoft Sentinel extracted from the alert data, such as user accounts, hostnames, IP addresses, URLs, and file hashes. Each entity is presented with its type, name, and a link to its full investigation details, allowing you to pivot directly to related incidents and actions. This dedicated, structured view is the appropriate place to identify all entities associated with the incident.

This is correct because the query combines two key conditions: an account-level condition (the account is disabled) and an activity-level condition (a high count of sign-in attempts from the same source IP within a window). Repeated, high-frequency authentication attempts against disabled accounts are a hallmark of a brute-force attack, where an adversary tries many passwords against a known username without realizing the account has been deactivated. The query's aggregation by IP address and its threshold on the number of attempts filters out ordinary, low-volume failures and isolates a sustained, suspicious pattern.

Adding an indicator of compromise (IoC) in Microsoft 365 Defender with the action 'Alert and block' or 'Block' immediately prevents the malicious process from running on any onboarded device. This indicator can be a file hash, signing certificate, or other process attribute, and the block is enforced by the Defender for Endpoint sensor in real time. Unlike scanning, this is a proactive, organization-wide prevention control that stops execution before or during launch.

Suspending the user account in Microsoft Entra ID is the correct immediate containment action because it revokes the user's ability to sign in and access SharePoint, stopping all further downloads at once. Defender for Cloud Apps can trigger this governance action natively, integrating with Entra ID to disable the account. This aligns with incident response best practices, prioritizing containment of a likely data exfiltration before investigation.

Adding the URL as a custom threat indicator with the action 'Alert and block' creates an immediate, environment-wide deny for that address. Defender for Endpoint enforces URL/domain indicators through Windows Defender SmartScreen and network protection, so any onboarded endpoint attempting to reach the URL is blocked before the response, not after. This targeted action stops further downloads without broad disruption to legitimate PowerShell or other workloads.

Running a playbook that uses the Microsoft 365 Defender connector is the correct approach because this connector exposes a 'Disable mailbox' remediation action designed for incident response scenarios. When triggered from a Microsoft Defender XDR incident, the playbook can execute this action directly against the affected user's mailbox in Exchange Online, immediately preventing further access and exfiltration. This precisely satisfies the requirement to disable the mailbox as a containment step.

DeviceFileEvents is correct because this table records file system operations such as creation, modification, renaming, and deletion. Ransomware encrypts files by writing encrypted content, often renaming them with new extensions and creating ransom notes, all of which generate file events. Security analysts can query this table for patterns like mass FileModified events from a single process or unusual file extension changes, making it the primary source for directly identifying encryption activity.

The incident graph in Microsoft Defender XDR provides a visual representation of the attack timeline and relationships between entities such as users, devices, and emails. It helps analysts understand the scope and progression of an attack across multiple workloads. This is the correct feature for the described requirement.

The incident investigation page is the unified surface in Microsoft Defender XDR where you review the attack story, alert timeline, impacted entities, and evidence, and from which you can run response actions such as soft-deleting emails or isolating devices. It aggregates signals from Defender for Office 365, Exchange Online Protection, and other workloads, exactly matching the need to investigate and remediate this phishing incident in one place.

Microsoft Defender for Cloud Apps logs in Sentinel, specifically the CloudAppEvents table, provide a centralized, enriched record of user activities across cloud applications, including SharePoint Online file downloads. Each event includes the actor, target file, action, source IP, timestamp, and risk indicators. Because the analyst is investigating a Defender for Cloud Apps alert, these logs allow direct correlation of the file-download activity to the reported incident without relying on separate audit consoles.

Blocking the file hash with Microsoft Defender for Endpoint is the correct immediate containment because it targets the exact malicious artifact that triggered the incident. Defenders can add the SHA-256 hash as a custom file indicator in the Microsoft 365 Defender portal, which instructs the endpoint sensor to block execution and sometimes prevent the file from being written to disk, across all enrolled devices. This is non-disruptive to user productivity, reversible once the threat is confirmed eliminated, and aligns with the automatic response capabilities in Microsoft Sentinel when connected to a playbook. Because the file is the vector, a file-level block nullifies the attack regardless of how the file arrives in the future.

Creating an automation rule that triggers when an incident is created with severity High and runs the playbook is correct because automation rules are Microsoft Sentinel's native, event-driven mechanism for incident lifecycle automation. The rule evaluates the incident immediately on creation, checks the severity condition, and executes the playbook via the Actions pane, passing the complete incident context. This approach is consistent, auditable, and ensures that every High-severity incident triggers the playbook without relying on alert-level logic or custom polling.

In Microsoft Sentinel, running a KQL query in the Logs blade against the Alert table is the correct way to search for all alerts involving a specific IP address. For example, you can execute a query like `Alert | where TimeGenerated > ago(30d) | where Entities contains "10.0.0.5"` to return every alert where that IP appears in the entity list, enabling a thorough historical investigation. The Alert table stores all alerts generated by analytics rules and data connectors, making it the authoritative source for answering whether an IP is associated with prior alerts. This read-only query provides immediate, actionable evidence without altering detection or response configurations.

Connecting the Log Analytics workspace to external tools via the Log Analytics Query API is a valid data-retrieval method because it allows external applications, such as custom scripts or third-party SIEM/BI solutions, to send KQL queries over HTTPS and receive the query results in JSON format. The API supports large result sets with batching/pagination, making it suitable for pulling data out of Sentinel's underlying workspace for analysis or integration. This is one of the canonical approaches to retrieving Microsoft Sentinel data externally.

Connecting to the VM and installing the missing updates directly resolves the configuration issue identified by Microsoft Defender for Cloud. This action applies the required patches, bringing the system into compliance with the security baseline and eliminating the known vulnerabilities. It is the immediate and definitive remediation for a recommendation that reports missing updates.

Threat Explorer is the dedicated email-trace and forensics tool in Microsoft 365 Defender, purpose-built for investigating malicious mail across Exchange Online and Microsoft Defender for Office 365. It supports near real-time searches and filters by sender, recipient, subject, message ID, detection technology, delivery status, and header data, and it can even display email headers for detailed verification. Because it lets analysts immediately pivot from search results to remediation actions such as soft-deleting from mailboxes, it is the correct surfacing feature for phishing email investigation.

Sentinel stores and queries timestamps in UTC, while Windows event logs record event time in the machine's local time zone. When an analytics rule uses a local-time field (such as EventTime or TimeCreated) for the where clause, events occurring in the last few minutes of the lookback window can be shifted outside the UTC-based query boundary, so the rule misses them even though they occurred within the intended hour. The fix is to convert time fields to UTC (e.g., using `datetime_utc()` or comparing against UTC datetime literals) or rely on `TimeGenerated`, which is always UTC.

Initiating a live response session from Microsoft Defender for Cloud provides a remote interactive shell to the VM, allowing you to run commands, inspect running processes, collect forensic artifacts, and terminate suspicious processes in real time. Live response is specifically designed for ad-hoc investigations where you need immediate, hands-on visibility. This is the appropriate action when you have identified a specific process and need to examine it directly.

Blocking known malicious file hashes through indicators of compromise directly satisfies the containment requirement by preventing execution of identified ransomware binaries across endpoints. Custom file-hash indicators in Microsoft Defender XDR enforce immediate prevention, halting lateral spread while investigation continues, and this deterministic, signature-based control is a recognised containment step.

Reviewing the user's sign-in logs in Microsoft Entra ID is the correct first step because these logs contain the authenticated IP address, exact timestamp, and geolocation data needed to corroborate the anomalous travel activity. This source of truth allows you to verify whether the second sign-in actually occurred from the reported location and whether it was a legitimate authentication. It provides the required evidence to decide whether further action is warranted.

Changing an incident's status to 'Closed' is a valid and common incident-management action in Microsoft Sentinel. The status lifecycle includes New, In Progress, and Closed, and closing an incident indicates that it has been resolved and requires no further action. When closing, you must choose a classification (such as True Positive or False Positive) and optionally a reason, which helps preserve metadata for reporting and auditing purposes.

Soft delete moves the malicious messages to the Recoverable Items folder, removing them from the user's inbox while retaining them for investigation or restore. This satisfies remediation directly from the Microsoft 365 Defender portal without permanent data loss.

The Attack story timeline in Microsoft Defender XDR provides a chronological view of alerts, events, and entities associated with an incident, allowing you to see which users interacted with the phishing emails and when. It aggregates evidence across workloads, helping you quickly assess the scope and sequence of the attack without manually correlating alerts.

The `IdentityLogonEvents` table, which aggregates logon activities primarily from Microsoft Entra ID, does not utilise a field named `ResultType` for indicating logon outcomes. Instead, this table typically uses `LogonResult` (e.g., "Success", "Failed") or `ActionType` to categorise events. Consequently, filtering on a non-existent `ResultType` field will cause the KQL query to return no results, even if numerous failed logon attempts are present within the `IdentityLogonEvents` data.

The device has been isolated from the network. This correctly interprets the 'IsolationStatus' value of 'Isolated'. Isolation is a containment action that severs the device's network connectivity to prevent an active threat from communicating with command-and-control servers or moving laterally to other hosts. The only traffic usually allowed while isolated is limited communication with the Defender for Endpoint service, allowing admins to monitor or reverse the isolation if needed.

Azure Firewall Manager centrally orchestrates firewall policies and applies them consistently across multiple Azure Firewall deployments, including hub and spoke architectures. By creating a Network rule (or Application rule) with a Deny action for the malicious IP address and assigning that policy to all firewalls managed under Firewall Manager, you enforce the block at the perimeter immediately and globally. This approach is the most efficient because a single policy change propagates everywhere, eliminating the need to touch each firewall individually.

The Microsoft Entra sign-in logs record which Conditional Access policies applied, whether MFA was satisfied, and the authentication method used, directly explaining why MFA was bypassed. Reviewing this event first satisfies the need to investigate the discrepancy before changing policy or revoking sessions.

The 'Block file' action in Microsoft Defender for Endpoint (MDE) adds the file's SHA-256 hash to the organization's custom threat intelligence indicators, which are enforced by the MDE cloud block list. This preventive control immediately prevents the file from executing on any device onboarded to MDE, including future instances of the same hash. It is a tenant-wide action and does not require the original device to remain connected, as the block is propagated through the cloud.

In Microsoft Sentinel, when you select a user entity in an incident, you can perform entity actions such as 'Disable user' and 'Revoke sessions' directly from the investigation graph or entity pane. These actions integrate with Microsoft Entra ID to immediately contain the threat. This is the fastest way to respond without leaving Sentinel.

The rule's conditions combine incident creation, High severity, Microsoft Defender for Endpoint as the detection source, and 'Malware' in the title. All must match simultaneously, so the playbook fires only when every condition is satisfied on a newly created incident.