Evidence Review And Response Actions practice questions

Firewall Security Policy rules

Why it fails: Firewall rules govern network layer traffic access, not low-level endpoint API activity.

Email Gateway spam filter logs

Why it fails: Email logs track inbound and outbound message delivery and content inspection.

Cloud Storage bucket policies

Why it fails: Cloud storage policies manage permissions on cloud objects, unrelated to endpoint API monitoring.

Order office catering supplies for the team meeting

Why it fails: Catering supplies are unrelated to incident response; the Incident Details page exposes evidence actions such as isolating endpoints, running scripts, or blocking hashes. Ordering supplies belongs to procurement, not security operations, so it cannot be triggered from this console.

Schedule routine commercial window washing

Why it fails: Window washing is a physical maintenance activity absent from Cortex XDR's evidence review, which exposes host, network and process artefacts with response options. It tempts as an obviously unrelated distractor, and would be correct only within a facilities scheduling tool, not a security incident console.

Calibrate the office thermostat temperature

Why it fails: Thermostat calibration is a facilities task with no connection to Cortex XDR's incident evidence, which offers response actions such as isolating endpoints or blocking indicators. It tempts as an example of an unrelated action, and would be correct only in a building-management system, not a security console.

File Quarantine

Why it fails: File Quarantine moves a malicious file to a secure location to prevent execution, but it does not isolate the endpoint from the network. This action is useful for file-based threats but does not provide network containment, so it fails to meet the scenario's requirement.

Endpoint Isolation

Why it fails: Endpoint Isolation blocks all network traffic, including communication with the Cortex XDR management console, which would prevent further remediation actions. The scenario requires the agent to remain connected, so this action is too restrictive and would hinder the analyst's ability to manage the endpoint.

Terminate Process

Why it fails: Terminate Process stops a specific running process but does not isolate the endpoint from the network. It is a targeted action for a malicious process, not a containment measure for the entire endpoint, so it does not satisfy the need to isolate the compromised machine while keeping management connectivity.

Endpoint Isolation

Why it fails: Endpoint Isolation is a response action that cuts off network communication for an endpoint. While it would stop further connections, it does not provide a way to review past network activity associated with a specific process. The analyst needs to investigate, not contain, so isolation is not appropriate here and would not help correlate process activity with network events.

XQL Query with process and network event joins

Why it fails: XQL can be used to query and join process and network events, but it requires manual query construction and does not automatically provide a visual correlation. While XQL is powerful, the question asks for a capability to correlate process activity with network events, and Causality View is the built-in feature designed for that purpose with less effort and more immediate context.

WildFire Analysis Report

Why it fails: WildFire Analysis Report provides static and dynamic analysis of a file's behavior in a sandbox environment. It can show network connections made by the file during sandbox execution, but it does not show actual network connections made on the endpoint in the context of the parent process. The analyst needs endpoint-specific correlation, not sandbox results.

Schedule a full antivirus scan on all endpoints in the organization.

Why it fails: Scheduling a full antivirus scan is not a direct response action available in the Incident Response view. Cortex XDR does not provide a built-in scheduler for antivirus scans from that view; malware scanning is typically managed through endpoint protection policies or manual scan initiation on individual endpoints.

Block the hash of the PowerShell script using the Block List.

Why it fails: Blocking a file hash is a preventive action typically configured in the Block List policy, not directly from the Incident Response view. The Incident Response view focuses on immediate containment and remediation actions on affected endpoints, not on policy changes.

Modify the Windows Registry to disable PowerShell execution.

Why it fails: While modifying the registry to disable PowerShell is a possible hardening step, it is not a built-in response action directly available from the Cortex XDR Incident Response view. The view provides predefined actions like script execution and containment, not arbitrary registry edits.

Initiate a scan of all endpoints using the Malware profile.

Why it fails: Initiating a scan with the Malware profile will detect malicious files based on signatures and heuristics, but it does not guarantee removal. The scan may report the files as present, but it does not automatically delete them unless configured to do so. This action is more about detection than verification of removal.

Run a query in XQL to check for the file's presence on endpoints.

Why it fails: Running an XQL query can search for events related to the file, such as process executions or file creation, but it does not directly confirm the file's current existence on disk. XQL queries are based on historical telemetry, so they may not reflect real-time file system state. This method is indirect and may miss files that were deleted after the last telemetry update.

Use the 'Retrieve File' action to pull the files from endpoints.

Why it fails: The 'Retrieve File' action allows analysts to download a copy of a file from an endpoint for further analysis. It does not remove the file from the endpoint; it only retrieves it. Therefore, it cannot be used to verify that the file has been deleted. This action is typically used during evidence collection, not remediation verification.

The actor_process_image_name field, which records the executable name of the process that performed the action.

Why it fails: actor_process_image_name identifies the binary that initiated an action, such as cmd.exe or powershell.exe. It describes the process, not the user account. An analyst relying on this field would learn what executed but not who executed it, leaving the identity question unanswered and potentially attributing activity to a service account incorrectly.

The causality_actor_process_image_path field, which shows the full path of the process that originated the causality chain.

Why it fails: This field provides the file path of the root process in the causality chain, which is valuable for understanding execution lineage but contains no account information. It identifies where a binary resides on disk, not who ran it. Using it to determine user context would confuse process identity with user identity.

The action_process_signature_vendor field, which identifies the code-signing vendor of the process that performed the action.

Why it fails: The signature vendor field indicates which publisher signed the binary, such as Microsoft or Adobe. It speaks to trust and integrity of the executable, not to the identity of the user. An analyst who selects this field learns whether the binary is signed but still cannot determine which account launched it.

Agent Settings -> Granular Control

Why it fails: Granular Control under Agent Settings tunes agent behaviour such as protection modules and exclusions, not alert-driven script execution. It is correct when adjusting endpoint agent policy. Response automation for alerts is configured elsewhere in Cortex XDR.

Security Information and Event Management (SIEM) forwarder

Why it fails: A SIEM forwarder only relays logs to external systems; it cannot trigger endpoint scripts. Forwarders are correct when you need to export Cortex XDR events to a SIEM. Automated remediation must be configured within Cortex XDR's own response automation.

Data Collection rules

Why it fails: Data Collection rules govern which endpoint artefacts are gathered for investigation, not alert-triggered script execution. They are correct when you need to define what telemetry is collected. Automation of scripted responses belongs in the response or playbook configuration.

Modify the Agent Settings profile to stop reporting all file execution events.

Why it fails: Suppressing all file execution reporting blinds the agent to every process on the endpoint, not just the benign tool, destroying detection coverage the BIOC rule depends on. It tempts because agent profiles do control telemetry, but that setting is for broad data-collection tuning, not scoped per-rule exceptions.

Disable the BIOC rule globally in the Profiles page.

Why it fails: Disabling the rule globally suppresses detection for all endpoints, removing coverage rather than scoping the exception to the benign tool. It is tempting as the quickest way to stop alerts, and would be correct if the rule were wholly obsolete, but the stem requires targeted exclusion.

Delete the alert from the Incident View to prevent re-triggering.

Why it fails: Deleting an alert removes only that incident record; the BIOC rule re-evaluates the same telemetry on the next execution and raises a fresh alert, so the tool keeps triggering. It tempts analysts clearing noisy queues, but deletion is purely cosmetic incident management, never a persistent exclusion mechanism.

To verify the hardware specifications of the endpoint

Why it fails: Scheduled task evidence exposes the command, trigger and account used to re-establish execution after reboot. Hardware specifications are asset-inventory details, not attacker behaviour. Reviewing endpoint hardware would be the correct task when validating device capability or compatibility, not when tracing persistence in an incident.

To analyze the local user group membership policies

Why it fails: Local group membership concerns privilege assignment on the host, whereas a scheduled task's evidence shows its action, trigger and run-as account, which reveal persistence. Group policy analysis would be the correct focus when investigating unauthorised privilege escalation or account manipulation, not the scheduled task's execution mechanism.

To inspect the network throughput limits of the adapter

Why it fails: Scheduled task evidence reveals persistence: the task's action, trigger and executing account show how the attacker maintains code execution. Adapter throughput limits are network-interface counters, unrelated to task configuration. Examining scheduled tasks would be the correct focus when investigating persistence mechanisms rather than bandwidth or link performance.

Network packet capture (PCAP)

Why it fails: A PCAP shows network traffic on a monitored segment, but cloud sign-in events traverse encrypted TLS to the identity provider, so source geolocation is not recoverable. PCAP suits network-level intrusion analysis; identity alerts need the provider's authentication logs.

Master Boot Record (MBR) analysis

Why it fails: The MBR holds boot code and partition layout on a disk, containing no authentication or geolocation data. MBR analysis suits bootkit or disk-integrity forensics; impossible travel validation needs sign-in records showing source IP addresses and timestamps.

Endpoint memory dump

Why it fails: A memory dump captures process and credential artefacts from one host, not the authentication events recording source IPs and geolocation. It is used for malware or credential-theft investigation; validating impossible travel requires the identity provider's sign-in logs instead.

Disable User

Why it fails: Disable User suspends the account's authentication, which does not sever the compromised host's existing network sessions, so lateral movement continues. It suits revoking a compromised identity's access, not containing an endpoint that must stay reachable for administrative remediation.

Kill Process Tree

Why it fails: Kill Process Tree terminates the malicious process and its children but leaves the endpoint's network interfaces active, so lateral movement is not prevented. It suits stopping active malicious execution, not isolating a host from the network while retaining administrative access.

Quarantine File

Why it fails: Quarantine File isolates a malicious file artefact on the endpoint, not the host's network connectivity, so lateral movement remains possible. It suits containing a known malicious binary pending analysis, not severing an infected host's network access while preserving administrative reach.

Retrieve File

Why it fails: Retrieve File pulls a copy of a file from the endpoint for analysis; it takes no action against running processes. It is tempting because it is a response action within the incident view, and it would be correct when the analyst needs the malware sample preserved for forensic examination.

Block File Hash

Why it fails: Block File Hash adds the hash to a denylist, preventing future execution but leaving the currently running process and its children alive. It is tempting because it addresses the malware, and it would be correct when the goal is preventing reinfection across endpoints rather than terminating an active process tree.

Isolate Endpoint

Why it fails: Isolate Endpoint cuts network communication while leaving processes running, so the malicious process and its children continue executing locally. It is tempting as the strongest containment action, and it would be correct when the priority is stopping lateral movement or command-and-control traffic rather than terminating processes.

Review the Global Protect gateway traffic logs for file downloads.

Why it fails: GlobalProtect gateway logs record VPN session and download metadata, not endpoint file execution or file paths, so they cannot enumerate hosts holding the file. Cortex XQL queries the endpoint dataset for that. Traffic logs would be the right source for tracing network downloads.

Create a new BIOC rule and wait for the file to be executed again.

Why it fails: A BIOC rule only alerts on future executions, so it cannot locate instances already present across endpoints. XQL searches historical endpoint telemetry immediately. Creating detection rules is the correct action when the goal is ongoing monitoring rather than retroactive hunting.

Export the Windows Event logs from a single machine and compare manually.

Why it fails: Exporting one machine's Windows Event logs covers a single host and requires manual comparison, missing the fleet-wide endpoint telemetry XQL queries in one pass. Event logs suit deep host-level forensics on that specific machine, not organisation-wide file hunting.

Action Center

Why it fails: Action Center lists response actions and their statuses, not process lineage. It is tempting because it centralises alert handling, but the process hierarchy is shown in the Causality Chain view. Action Center would be correct when tracking or approving remediation actions taken against an endpoint.

Audit Log

Why it fails: Audit Log records user and system activity for compliance, not endpoint process ancestry. It is tempting because it tracks events chronologically, but the process hierarchy is displayed in the Causality Chain view. Audit Log is correct when investigating who changed a configuration or performed an administrative action.

BIOC Rules Manager

Why it fails: BIOC Rules Manager defines and manages behavioural indicator rules, not the process tree of a specific alert. It is tempting because BIOCs detect the suspicious PowerShell behaviour, but reviewing lineage requires the Causality Chain view. BIOC Rules Manager is correct when authoring or tuning detection logic.

Global Protect Tunnel Inspection

Why it fails: Global Protect Tunnel Inspection examines traffic traversing a VPN tunnel, so it cannot capture volatile memory or process lists from an endpoint. It is tempting because it does provide forensic visibility, but only into network flows; it would be the right choice when investigating threats hidden inside encrypted VPN traffic rather than host artefacts.

Agent Upgrade Schedule

Why it fails: Agent Upgrade Schedule controls when endpoint agents receive software updates; it performs no data collection. It is correct for managing agent version rollout, not for gathering memory dumps or process lists from a remote host.

WildFire Submission Policy

Why it fails: WildFire Submission Policy forwards files to cloud sandboxing for malware verdicts; it cannot pull memory images or process lists from endpoints. It is the right feature for automated file detonation and hash reputation, not live forensic triage collection.

It provides network routing tables for the compromised subnet.

Why it fails: Routing tables describe network topology and are surfaced by network monitoring or flow analysis tools, not by the ATT&CK tab, which maps telemetry to adversary tactics and techniques. It tempts because incident review often involves network context, but ATT&CK mapping addresses behaviour classification, not packet-path data.

It automatically downloads security patches from vendor repositories.

Why it fails: The MITRE ATT&CK tab maps observed activity to adversary tactics and techniques, supporting evidence review; it does not retrieve or install vendor patches. Patch downloading is tempting because Cortex XDR does offer vulnerability and patch management, and that capability would be the correct answer if the question asked how endpoints are remediated rather than how incidents are contextualised.

It lists the hardware warranty status of the affected device.

Why it fails: Hardware warranty data sits in asset-management or vendor-support systems, not in ATT&CK mappings, which tie observed behaviours to adversary tactics and techniques. The tab is genuinely useful for mapping detected activity to known threat-group tradecraft during investigation, but it never reports device service contracts.

Syslog forwarding rules

Why it fails: Syslog forwarding rules export Cortex XDR alerts and events to external SIEM or syslog receivers; they do not configure agent protection behaviour, so no exclusion is applied. They are correct when centralising logs for correlation. Global exclusions belong in the Cortex XDR console's allow list or exception policy.

User Identity mapping rules

Why it fails: User Identity mapping rules associate directory users with endpoint agents for attribution and policy targeting; they do not define file, process or tool exclusions, so the penetration testing tool remains blocked. They are correct for identity correlation. Global exclusions require an allow list or exception policy in the Cortex XDR console.

Local Windows Registry on each endpoint

Why it fails: Editing the local Windows Registry configures only that individual endpoint's agent, so other agents still block or alert on the tool, failing the global requirement. Local configuration suits single-machine troubleshooting. Organisation-wide exclusions must be defined centrally in the Cortex XDR management console and pushed to all agents.

DNS Flushing

Why it fails: DNS flushing clears the local resolver cache, which cannot undo file drops or registry modifications. It is tempting because it is a real remediation step for name-resolution problems, and it would be correct when malware has poisoned DNS entries and the analyst needs to purge cached records.

DHCP Lease Renewal

Why it fails: DHCP lease renewal refreshes an endpoint's IP address configuration and has no mechanism to remove dropped payloads or restore registry keys. It is tempting because it is a legitimate network remediation action, and it would be correct when the issue is stale or conflicting IP addressing rather than malicious file and registry changes.

Static Route Addition

Why it fails: Static route addition alters host routing tables and cannot revert dropped files or registry changes. It is tempting because it is a genuine Cortex XDR response action, and it would be correct when the required remediation is isolating or redirecting network traffic rather than undoing endpoint file and registry modifications.

Disk Encryption status panel

Why it fails: Disk Encryption status reports BitLocker or FileVault compliance per endpoint, exposing no event timeline tied to an account. It is tempting because encryption posture is endpoint-centric and searchable by host, but the requirement is correlating one user's activity across devices, which the Causality View performs.

Agent Health dashboard

Why it fails: Agent Health shows endpoint sensor version, connectivity and operational state, not security events linked to an account. It is tempting because it lists every device, which appears to span multiple endpoints, but it carries no user identity or event chronology; the Causality View provides that correlation.

BIOC Policy editor

Why it fails: BIOC policies define behavioural threat detection rules and their alerting, not per-user event aggregation across endpoints. It is tempting because BIOCs surface the alerts an investigation consumes, but the user-centric timeline spanning multiple devices over seven days comes from the Causality View, not rule authoring.