Select Two (Multi-Select) Questions

Run a query in the Query Builder to count similar alerts

Why it fails: Running a query to count similar alerts might help assess prevalence, but it does not explain how this specific alert was generated or what data contributed to it. The analyst needs details about the analytics logic and event sequence, which are found in the alert details and causality chain, not in aggregate counts.

Modify the BIOC rule that triggered the alert

Why it fails: The alert source is 'XDR Analytics', not a BIOC. Modifying a BIOC rule would be irrelevant because no BIOC triggered this alert. XDR Analytics alerts are generated by machine learning and behavioral analytics, not by custom BIOC rules. Therefore, this action would not help understand the alert's origin.

Export the raw endpoint logs from the Cortex XDR agent

Why it fails: Exporting raw endpoint logs is not a standard feature in Cortex XDR and would not directly explain how the XDR Analytics alert was generated. The platform provides processed telemetry and analytics details, not raw log export for individual alerts. This action would not efficiently provide the needed context and is not the intended workflow.

Modify the alert's severity to match the incident's severity.

Why it fails: Changing severity does not correlate alerts; it only adjusts the priority. Correlation requires linking alerts based on shared attributes or manual association. Severity is an independent field and does not establish a relationship between alerts or incidents.

Edit the alert's description to include the incident ID.

Why it fails: Editing the description is merely documentation and does not create any technical link between the alert and the incident. The alert would still be separate, and the incident would not include its data. Correlation requires an action that changes the alert's incident association.

Assign the alert to the same analyst who owns the incident.

Why it fails: Assigning an alert to an analyst is not a supported action in Cortex XDR; alerts are not assigned like incidents. Even if it were, assignment does not correlate alerts. The incident's alert list would remain unchanged. Correlation is about linking data, not ownership.

Rebuilding the physical data center facility electrical grid

Why it fails: Rebuilding a data centre's electrical grid is physical facilities work, unrelated to Cortex XDR's identity response actions such as disabling accounts, forcing password resets or revoking sessions. It is tempting because infrastructure remediation matters after destructive incidents, but grid rebuilds belong to facilities recovery, not endpoint or identity orchestration.

Upgrading the BIOS firmware on enterprise routers

Why it fails: Router BIOS firmware upgrades are network hardware maintenance, not an identity-attack response action available in Cortex XDR, which orchestrates account disabling, session revocation and token invalidation. It is tempting because compromised network devices may need firmware patching, but that is device hardening, not active identity incident response.

Local user keyboard layout language

Why it fails: Exception scope in Cortex XDR is defined by process, file, hash, signer, or command-line attributes that the agent actually evaluates; keyboard layout language is never parsed by the agent, so it cannot match any detection. It is tempting because locale settings appear in endpoint inventory, but they serve regional configuration, not exception criteria.

Endpoint CPU temperature threshold

Why it fails: Cortex XDR exceptions match on executable identity, path, hash, signer, or command line; CPU temperature is telemetry from hardware sensors and never feeds detection logic, so no exception can reference it. It is tempting because thermal data appears in endpoint health dashboards, but that is hardware monitoring, not threat-scoping.

BIOS Firmware Update Logs

Why it fails: BIOS logs track hardware flash updates, not user identities.

Display Resolution Configuration Logs

Why it fails: Display resolution settings are endpoint hardware configuration, carrying no authentication, credential or identity telemetry, so they cannot feed ITDR detections. It is tempting because Cortex XDR ingests broad endpoint telemetry, but ITDR specifically requires identity sources such as Entra ID sign-in and audit logs.

Printer Spooler Error Logs

Why it fails: Printer spooler error logs record print-job faults, not authentication or directory events, so they carry no identity telemetry for ITDR correlation. They are tempting because spooler crashes can indicate PrintNightmare exploitation, making them useful for print-service vulnerability detection rather than credential misuse.

Connecting the Broker VM virtual disks to a local USB thumb drive for manual failover

Why it fails: A USB thumb drive is single-attached local storage with no replication or shared access, so it cannot provide failover for Broker VM services across hosts. Local removable media is tempting for quick manual backups, but high availability requires shared or replicated storage accessible to multiple hosts.

Running the Broker VM software directly inside a web browser tab

Why it fails: Broker VM software runs as a virtual appliance on a hypervisor, not inside a browser tab, which offers no persistent service, clustering, or failover capability. Browser access is tempting for convenient management consoles, but it cannot host the Broker VM service itself.

Disable all default Cortex XDR analytics rules to prevent false correlation.

Why it fails: Default analytics rules provide the behavioural baselines and causality chains that stitch alerts into incidents; disabling them removes the correlation inputs entirely. Tuning specific noisy rules is the correct approach. Disabling everything is tempting when false positives overwhelm analysts, but it eliminates the detection foundation rather than refining it.

Set the incident close timeout to 1 minute to speed up alert processing.

Why it fails: A one-minute close timeout ends incidents before related alerts can stitch into them, fragmenting campaigns and skewing scoring. Correlation needs a window matching the attack's tempo. Shortening timeouts is tempting to reduce backlog, but it truncates grouping rather than accelerating legitimate processing.

Manually star every incoming alert to trigger the incident correlation engine.

Why it fails: Starring alerts is a manual triage marker for analyst attention and does not feed the correlation engine, which groups alerts by shared causality chains, entities and timing. Correlation rules must be tuned on those attributes. Starring is tempting as a prioritisation shortcut, but it changes no stitching logic or incident score.

Corporate vehicle fleet GPS tracking logs

Why it fails: Vehicle GPS logs record fleet movements, not workstation activity, so they cannot show local logons, process execution or file access. They are tempting because GPS telemetry is genuine evidence in physical-security or insurance investigations, where proving a vehicle's location at a given time is the actual question.

Office cafeteria refrigerator temperature charts

Why it fails: Refrigerator temperature charts record appliance conditions, containing no authentication, process, or session data tied to the workstation, so they cannot establish local access. It is tempting as an available physical record within the office, but such logs are relevant only to facilities or food-safety investigations, not host compromise.

Office janitorial cleaning supply invoices

Why it fails: Cleaning supply invoices document procurement and vendor billing, holding no logon, session, or file-access artefacts from the workstation, so they cannot show who accessed it locally. It is tempting as a physical record placing staff in the building, but invoices are relevant to facilities or finance audits, not host forensics.

Full memory dump of the PowerShell process

Why it fails: Cortex XDR does not automatically capture full memory dumps of processes as part of alert details. Memory dumps require additional configuration or manual triggering, and they are not a standard data source in the alert view. While memory analysis can be valuable, it is not directly available here, making this option incorrect.

Windows Registry modifications made by the script

Why it fails: While Cortex XDR can capture registry modifications as events, they are not always included in the alert details for a specific PowerShell script execution. Registry changes might be visible in the causality view if the process made them, but they are not a guaranteed data source directly in the alert details. The question asks for data sources available directly in the alert details, and registry modifications are not consistently presented there.

User login history for the account that executed the script

Why it fails: User login history is not part of the Cortex XDR alert details for a process execution. While authentication events can be ingested from external sources, they are not directly linked to the alert details of a PowerShell script. The alert focuses on endpoint activity, not user login data, so this option is incorrect.

All network routers in the enterprise data center are reset.

Why it fails: Quarantine acts on the endpoint file itself, encrypting and isolating it; it never touches network routers, which Cortex XDR does not manage. The tempting confusion is that containment sounds network-wide, and router resets would belong to a separate network-device remediation workflow.

The computer's power supply unit is permanently disabled.

Why it fails: Quarantine operates purely in software on the file, so hardware such as the power supply is untouched and remains functional. The tempting but mistaken idea is that physical disablement guarantees containment, whereas that would require a manual hardware intervention no endpoint agent performs.

The endpoint operating system hard drive is physically wiped clean.

Why it fails: Quarantine encrypts and isolates the specific file on the endpoint, leaving the disk and its data intact; physical wiping is a separate reimaging action. The temptation is that malware removal feels destructive, but wiping the drive would destroy forensic evidence and unrelated user data.

Corporate gym membership roster

Why it fails: A gym roster holds no endpoint forensic data; Cortex XDR surfaces artefacts via the Causality Chain and Timeline views. It is tempting as a plausible-sounding administrative record, yet forensic artefacts require process, file and network telemetry collected by the agent, which a membership list never contains.

Cloud printer ink supply level gauge

Why it fails: A printer ink gauge is not a Cortex XDR view; forensic artefacts appear under the Causality and Timeline tabs. It is tempting only as a distractor resembling a monitoring dashboard widget, but Cortex XDR exposes endpoint telemetry through investigation views, not hardware consumables tracking.

Cafeteria food inventory management sheet

Why it fails: Cafeteria inventory has no relation to endpoint forensics; Cortex XDR presents artefacts in the Causality and Timeline tabs. It is tempting as another internal tracking sheet, but forensic insight demands agent-collected process, registry and network events, not stock counts of food items.

Featured

Why it fails: Featured is a display or promotion attribute, not a lifecycle stage. Lifecycle states reflect investigative progress, such as New, Under Investigation, and Resolved. Featuring is appropriate when an analyst wants to highlight an incident on a dashboard for visibility, not to track its status.

Starred

Why it fails: Starred is a user-applied flag for marking incidents for quick reference, not a lifecycle stage. Lifecycle states track an incident's investigative progress, such as New, Under Investigation, and Resolved. Starring is the right action when an analyst wants to bookmark an incident for later review.

Stitched

Why it fails: Stitched refers to stitching alerts into an incident, a processing action rather than a lifecycle state. Lifecycle states describe where an incident sits in the investigation workflow. Stitching is correct when correlating related alerts from multiple sources into a single incident for unified handling.

Disable all Cortex XDR agent security modules across the entire enterprise

Why it fails: Disabling agent modules enterprise-wide strips behavioural, exploit and malware protection from every endpoint, far beyond excluding one application. It is tempting as a quick fix for false positives, and would fit a controlled test lab where no production telemetry is required.

Remove all file access permissions from the operating system kernel

Why it fails: Kernel file permissions govern operating-system access, not Cortex XDR behavioural analysis, so removing them breaks the host without creating an exclusion. It is tempting as a broad lockdown measure, and would be relevant when hardening a server's filesystem against unauthorised local reads.

Endpoint firewall connection logs recording outbound TCP and UDP flows from user workstations.

Why it fails: Firewall connection logs describe network flows, not identity events. They cannot show who authenticated, whether MFA succeeded, or which tickets were requested. While useful for network-centric investigations, they do not provide the authentication and directory context needed to detect credential abuse, so they are a lower priority than identity-specific telemetry in a hybrid detection strategy.

Print server spooler logs capturing document names and submitting user accounts.

Why it fails: Print spooler logs record document metadata and the submitting account, which has marginal investigative value but no authentication detail. They cannot reveal credential theft, ticket abuse, or risky sign-ins. Prioritizing print logs over directory and cloud identity telemetry would leave the largest identity attack surfaces unmonitored in a hybrid environment.

DHCP lease logs from the internal network recording IP address assignments to endpoints.

Why it fails: DHCP lease logs map IP addresses to devices over time, which can support investigations by resolving addresses to hosts. However, they contain no authentication, credential, or directory information. They cannot detect credential abuse or anomalous sign-ins on their own, making them supplementary context rather than a priority identity telemetry source for the described strategy.

Initiate a full antivirus scan on the endpoints.

Why it fails: A full antivirus scan can detect known malware but does not specifically collect evidence about the PowerShell script's execution or origin. It may generate additional alerts, but it does not provide the detailed command-line or file content needed for analysis. This action is more about detection and remediation than evidence gathering for this specific scenario.

Isolate the endpoints from the network immediately.

Why it fails: Isolating endpoints is a containment action that prevents further spread of malware but does not collect evidence. While it may be appropriate in some cases, the question specifically asks for evidence gathering actions. Isolation could also hinder evidence collection if remote actions are needed, and it does not provide data about the script's origin or impact. Therefore, it is not the correct choice here.

Review the endpoints' Windows Event Logs for PowerShell operational events.

Why it fails: While Windows Event Logs can contain PowerShell operational events, Cortex XDR already ingests and normalizes this data into its own datasets. Directly reviewing Windows Event Logs on the endpoint is redundant and less efficient than using Cortex XDR's built-in tools like XQL. Additionally, remote access to event logs may not be available if endpoints are isolated. Thus, it is not the best action.

Delete inactive data collectors to clear queue clutter

Why it fails: Deleting data collectors removes ingestion sources and creates visibility gaps; it never clears queue clutter or adds metadata. It is tempting because stale collectors appear in management lists, and it would be correct if the task were decommissioning an unused collector rather than customising Incident View metadata.

Enable automatic alert starring for every raw alert

Why it fails: Starring flags individual alerts for analyst attention; it adds no metadata fields to the Incident View. It is tempting because starring does surface alerts in filtered views, and it would be correct if the requirement were triaging raw alerts rather than enriching incident metadata columns.

Change data stitching rules to alter incident grid sorting

Why it fails: Data stitching rules control which alerts group into an incident; they do not change grid sorting or metadata columns. It is tempting because stitching shapes incident composition, and it would be correct if the goal were controlling incident grouping rather than altering the displayed metadata or its ordering.

Require users to download the agent from the Cortex XDR management console and install it themselves

Why it fails: Having users download and install the agent from the management console is a manual process that depends on user action and does not scale. It also may not provide the installation token automatically, leading to failed registrations. This method increases effort and is not suitable for a large, mixed-platform deployment.

Deploy the agent only to endpoints that are on the corporate network and postpone remote users

Why it fails: Restricting deployment to on-network endpoints leaves remote users unprotected and contradicts the requirement to support them. It also delays full coverage and increases risk. This approach does not minimize manual effort for the entire population and fails to meet the planning goal of including remote users.

Send each user an email with the agent installer and installation token, asking them to run it manually

Why it fails: Emailing the installer and token to users relies on manual execution and exposes the installation token to potential misuse. It does not scale well for a large deployment and can lead to inconsistent configurations. This method also lacks central tracking, making it unsuitable for minimizing effort and supporting remote users reliably.

Automated BIOS flashing utility

Why it fails: Automated BIOS flashing utility addresses firmware integrity, not identity threat reporting, so it cannot communicate findings to stakeholders or auditors. It is tempting because firmware attacks are a genuine XDR concern, and such a tool would be the right choice when remediating compromised UEFI or BIOS firmware on managed endpoints.

Live packet generator

Why it fails: Live packet generator captures and replays raw network traffic for troubleshooting or test injection; it produces no stakeholder-facing report or audit artefact. It would suit packet-level forensic replay, not communicating identity threat findings to auditors, which requires case documentation and exportable reporting.

Hard drive partition editor

Why it fails: A hard drive partition editor manages disk volumes and file systems; it produces no identity threat reporting, so it cannot support stakeholder or auditor communication. It is tempting because forensic imaging sometimes precedes investigation, and partitioning tools appear in endpoint toolkits. That role suits disk acquisition or evidence preservation, not conveying Microsoft Entra ID risk findings to compliance audiences.

Office desk relocation requests

Why it fails: Office relocation requests are a facilities-management artefact with no bearing on host or endpoint persistence; Cortex XDR telemetry covers registry run keys, scheduled tasks and services. It is tempting because administrative change records can reveal attacker activity, but that belongs to IT service management, not endpoint persistence detection.

Breakroom coffee machine maintenance schedules

Why it fails: Coffee machine maintenance schedules are facilities data with no host, registry, or account telemetry, so no persistence mechanism can be observed. It is tempting because IoT devices generate logs, and would be correct only if the investigation concerned building-management systems rather than endpoint persistence.

Manually write custom assembly code for every endpoint CPU architecture

Why it fails: Cortex XDR onboarding uses supported agent installers and built-in integrations; hand-writing assembly per CPU architecture is not an administrative setup task. It is tempting because endpoint agents are architecture-specific binaries, and custom code would be correct where no supported agent exists for a platform.

Physically replace all enterprise core switches with Palo Alto Networks firewalls

Why it fails: Cortex XDR onboarding covers tenant configuration, endpoint agent deployment and data source integration; swapping core switches for firewalls is a network refresh unrelated to that scope. It is tempting because Cortex XDR is a Palo Alto Networks product, and firewall deployment would be correct in a network security architecture project.

Disable all cloud logging features to prevent data ingestion

Why it fails: Disabling cloud logging removes the telemetry Cortex XDR needs for detection and analytics, directly contradicting onboarding's goal of ingesting data sources. It is tempting because reducing ingestion volume controls cost and noise, and selective logging reduction would be correct where data volume or licensing is the constraint.