Select Two (Multi-Select) Questions

Threat intelligence feeds from third-party providers, which supply indicators of compromise for matching.

Why it fails: Threat intelligence feeds provide indicators such as malicious IPs, domains, and hashes that can be used for matching and enrichment. They do not supply the raw endpoint process, network, or directory authentication events that the scenario requires for correlation. Onboarding a threat intel feed adds context but does not make those event types queryable in XQL.

WildFire sandbox verdicts, which provide file reputation and behavioral reports for submitted samples.

Why it fails: WildFire supplies file verdicts and sandbox behavioral reports, which are useful for file reputation enrichment but do not provide endpoint process execution, network connection, or directory authentication events. Onboarding WildFire does not make those event types queryable, so it does not satisfy the scenario's requirement to correlate process, network, and authentication data.

Cortex Data Lake raw log storage, which retains all ingested logs for long-term query and compliance.

Why it fails: Cortex Data Lake is the underlying storage and query layer that holds ingested data, but it is not itself a data source that generates process, network, or authentication events. The events must first come from the agent or a log integration before Data Lake can store and serve them. Selecting Data Lake does not onboard the required event types.

Automating incident closure in XSOAR

Why it fails: Live Terminal provides an interactive remote shell on an endpoint, so it can run commands and collect artefacts, but it cannot trigger XSOAR playbooks or close incidents; that happens in the Cortex XSOAR incident workspace. It is tempting because Cortex XDR and XSOAR integrate closely, yet incident lifecycle automation is configured through XSOAR playbooks and automation rules, not the endpoint shell.

Modifying firewall policy rules

Why it fails: Live Terminal executes commands on the selected endpoint; firewall policy is managed centrally in the Cortex XDR policy console or on the firewall itself, not through an endpoint shell session. It is tempting because Live Terminal can run scripts that touch host-based firewalls, but modifying enterprise firewall policy rules requires the policy management interface.

Edit the XDM mapping directly in the dataset schema without previewing the source data.

Why it fails: Editing the XDM mapping blindly, without previewing the source data, risks mapping the wrong fields and corrupting downstream detections. Validation requires seeing the parsed output first, so this approach skips the essential verification step and can introduce errors rather than confirm correctness.

Disable all correlation rules that reference firewall data until the new source is confirmed working.

Why it fails: Disabling correlation rules does not validate parsing or mapping; it only removes detection coverage. The administrator needs evidence that fields are mapped correctly, and turning off rules would neither produce that evidence nor address any parsing issue.

Add the source to a production dataset and wait for an incident to be generated before checking field values.

Why it fails: Waiting for an incident is a passive and unreliable validation method, because an incident may not occur or may not exercise the fields of interest. It also risks polluting production data and detections before mapping has been confirmed, which is the opposite of the stated goal.

Use the Cortex XDR - Scan Endpoint command to run a full antivirus scan on the endpoint

Why it fails: A full scan is a detection or remediation action, not containment or evidence collection. It does not isolate the endpoint from the network and may modify system state, potentially contaminating evidence. It does not fulfill the two required goals of network isolation and forensic data collection before remediation.

Use the Cortex XDR - Block File command to delete the malicious executable from the endpoint

Why it fails: Blocking or deleting a file is a remediation action, not containment or evidence collection. It would destroy potential forensic evidence and does not isolate the endpoint from the network. The scenario explicitly requires containment and evidence collection before remediation, so deleting the file is premature and counterproductive.

Use the Cortex XDR - Quarantine File command to move the malicious file to a quarantine folder

Why it fails: Quarantining a file is a remediation step that alters the endpoint state and may remove evidence. It does not isolate the endpoint from the network, nor does it collect forensic data. The playbook must first contain and collect evidence, so quarantining the file at this stage is out of sequence.

Incident display layout

Why it fails: Incident display layout is a UI presentation setting and does not affect playbook engine throughput or latency. Layout configuration is relevant when customising analyst dashboards for triage visibility, not when diagnosing execution duration driven by action complexity and integration response times.

User password length

Why it fails: Password length is an authentication credential attribute and has no bearing on playbook engine execution. Credential strength matters when hardening account policy, not when tuning the concurrency, action count, or API rate limits that determine playbook runtime.

xdr_registry

Why it fails: The xdr_registry dataset tracks registry key modifications. Credential dumping might involve registry changes for persistence, but the primary action of accessing LSASS memory is not captured here. This dataset is not relevant for detecting memory access events associated with credential dumping.

xdr_network

Why it fails: The xdr_network dataset contains network connection events, such as TCP/UDP traffic. While useful for detecting command-and-control or exfiltration, it does not provide information about process memory access. Credential dumping typically involves local memory operations, not network activity, so this dataset is not relevant for the specified detection.

xdr_file

Why it fails: The xdr_file dataset records file system operations like creation, modification, and deletion. Although credential dumping may involve writing a dump file to disk, the core activity is memory access. The xdr_file dataset would not show the memory access events needed to detect LSASS access, making it less suitable for this query.

Automated hardware replacement

Why it fails: XDM governs how security telemetry is modelled and queried; hardware lifecycle management sits entirely outside the schema. It is tempting because XSIAM is a platform, and automated hardware replacement would be relevant to an endpoint management or asset-inventory question rather than one about schema benefits.

Increased endpoint processing speed

Why it fails: XDM normalises and correlates data across sources; it does not accelerate endpoint agent processing, which depends on agent and broker capacity. It is tempting because schema parsing sounds performance-related, and XDM would be the right answer if the question asked about consistent field mapping for cross-source queries.

Reduced storage costs by 90%

Why it fails: XDM unifies field names and parsing across vendors; it does not itself compress or deduplicate telemetry to cut storage by 90%. It is tempting because normalisation removes redundant parsing artefacts, and XDM would be correct if the question asked about querying disparate logs with one consistent field vocabulary.

Changing the server IP address

Why it fails: Changing a server IP address is a network reconfiguration task, not a stage of the Indicator Lifecycle, which tracks indicators through extraction, enrichment, scoring, and expiry in Cortex XSOAR. It is tempting because IPs are common indicators, yet altering an address is remediation activity rather than lifecycle management.

Physical security of the data center

Why it fails: Physical data-centre security protects hardware, not threat indicators; the Indicator Lifecycle covers ingestion, enrichment, deduplication, scoring, and expiry within Cortex XSOAR. It is tempting because physical controls genuinely matter for compliance and on-premises deployments, but they never appear as lifecycle stages in the indicator workflow.

Cortex agent update scheduling

Why it fails: Cortex agent update scheduling controls when endpoint agents receive software upgrades, so it belongs to endpoint management rather than the Unified SOC dashboard's detection, incident and case views. It tempts because update scheduling genuinely matters in Cortex XSIAM deployments, but only when the requirement concerns agent version control, not dashboard capabilities.

Physical security badge tracking

Why it fails: Badge tracking belongs to physical access control systems, not Cortex XSIAM's Unified SOC dashboard, which aggregates endpoint, network and identity telemetry for detection and response. It tempts because XSIAM markets itself as a single pane of glass, but that unification covers cyber telemetry sources only.

Automated code deployment

Why it fails: Automated code deployment is a CI/CD pipeline function, not a Unified SOC dashboard capability, which surfaces alerts, cases and analytics rather than shipping code. It tempts because XSIAM supports automation via playbooks, but those orchestrate response actions, not application deployment.

Employee performance reviews

Why it fails: Incident records surface alerts, assets, and threat intelligence, never HR data; performance reviews live in HR systems with no XSIAM ingestion path. It tempts because incidents do reference user identity and behaviour analytics, so people-related fields appear, but those are risk signals, not review content.

Platform billing history

Why it fails: Incidents aggregate security telemetry, not commercial records; billing history sits in the platform's subscription management, outside the incident schema. It tempts because XSIAM dashboards can show licence and data-ingestion metrics, but those are administrative views, not fields within an individual incident record.

Install a new plugin

Why it fails: Installing a plugin adds platform capability rather than acting on an indicator object, so it cannot set expiry, status or verdict for threat data lifecycle management. It is tempting because plugins extend XSOAR functionality, and would be correct when integrating a new feed or enrichment source into the platform.

Rename the source feed

Why it fails: Renaming a source feed alters feed configuration, not the indicator object itself, so it cannot expire, extend or mark an indicator's lifecycle state. It is tempting because feeds supply the threat data indicators derive from, and renaming would be valid when reorganising feed integrations rather than managing individual indicators.

Change the server OS

Why it fails: Changing the server OS modifies the XSOAR host infrastructure, not an indicator object's lifecycle fields, so no expiry, status or verdict change occurs. It is tempting because server maintenance is a real administrative task, and would be the correct action when rebuilding or upgrading the underlying XSOAR appliance.

Reset the user's password

Why it fails: Cortex XDR's incident page offers response actions such as isolating endpoints or blocking indicators, but password resets belong to identity systems like Microsoft Entra ID. It is tempting because account remediation often accompanies incident response, yet no directory write-back exists here.

Update firewall OS

Why it fails: The incident details page exposes response and investigation actions scoped to the incident, not device firmware management. Updating firewall OS is performed through device management or the firewall's own upgrade workflow, not from an incident record.

GlobalProtect Enterprise

Why it fails: GlobalProtect Enterprise delivers endpoint VPN connectivity and host posture checks, not SOC detection, investigation or response capabilities. It is tempting because it belongs to the same Palo Alto Networks product family and appears in Cortex XDR deployments for traffic enforcement. It would be the correct choice when the requirement is secure remote access rather than security operations tooling.

Panorama Policy Creator

Why it fails: Panorama is the separate management plane for firewalls, not a Cortex SOC capability; Cortex provides XSIAM, XDR and Cortex Data Lake analytics. It is tempting because Panorama does centralise policy across firewalls, so it would be the right answer for managing firewall configuration at scale.

Entire network configuration file

Why it fails: A full network configuration file is static infrastructure documentation, not shift-handover content, which must convey active incidents, ongoing investigations and pending actions between analysts. It is tempting because configuration baselines support troubleshooting, but that belongs in change management or asset records, not a time-bound SOC handover.

Personal employee performance reviews

Why it fails: Performance reviews are an HR management function, unrelated to operational security state transfer between shifts. They are tempting because staff welfare and analyst capability affect SOC coverage, but that is handled through line management, whereas handover reports carry incident status, open tickets and escalation items.

Automated hardware repair

Why it fails: Automated hardware repair restores physical equipment, whereas incident response planning addresses detection, triage, containment and recovery of security incidents. It is tempting because automation genuinely features in mature operations, and would be correct where the requirement covers infrastructure self-healing or device remediation rather than incident handling procedures.

Public relations policy

Why it fails: A public relations policy governs external communications, not the detection, containment, eradication and recovery activities an incident response plan must define. It is tempting because stakeholder and media handling genuinely belongs in crisis communications planning, and would be correct where reputational messaging during a breach is the requirement.

Budget approval workflows

Why it fails: Budget approval workflows are financial governance, not incident response; a mature plan covers detection, triage, containment, eradication, recovery and lessons learned. It is tempting because executive sponsorship and funding do enable SOC capability, but that belongs to programme governance rather than the response plan itself.

The local time zone of the endpoint.

Why it fails: The endpoint's local time zone is host configuration, not a property of the process execution being analysed. It is tempting because timestamps appear throughout the Causality View, but those are normalised event times; inspectable properties cover the process image, command line and related network or file activity.

The total number of files on the disk.

Why it fails: Disk file counts are host inventory data, not properties of a process execution in the Causality View. It is tempting because the view surfaces file-related activity such as created or modified files, but the inspectable properties concern the process itself, its command line and its parent-child relationships.

Local user email drafts.

Why it fails: The collector ingests machine-generated telemetry such as endpoint, firewall, proxy and cloud audit logs; user email drafts are content, not a log type, and are never collected. It is tempting because email security telemetry is ingestible, but drafts are user data, not event records.

Internal coffee machine status.

Why it fails: The collector ingests endpoint, network and cloud security telemetry; appliance status from a coffee machine is not a supported log source. It is tempting because IoT device logs can be security-relevant, but the collector's parsers cover defined endpoint, firewall, proxy and cloud audit formats, not arbitrary device telemetry.

Physical hardware inventory logs.

Why it fails: A Cortex XDR Collector ingests endpoint, network and cloud telemetry such as endpoint event, firewall, proxy and audit logs; hardware inventory is not a supported log source. It is tempting because asset inventory data is security-relevant, but that data belongs in an asset-management or CMDB platform, not the collector pipeline.

Change the server OS

Why it fails: The Work Plan tab tracks incident response tasks, such as assigning an owner, adding a task, or linking an entity; it never provisions or reconfigures infrastructure. Changing a server OS is an Azure compute operation performed through the VM blade or automation runbooks, so it cannot be actioned from this tab.

Add a new incident type

Why it fails: Incident type is a classification attribute set when creating or editing the incident itself, not an action on the Work Plan tab. The Work Plan tab holds tasks and task templates for response steps; adding an incident type belongs to incident configuration or the incident details form.

A local physical tape backup unit.

Why it fails: A tape backup unit is offline storage hardware, not part of Cortex XDR's architecture. Cortex XDR consists of the management console, endpoint agents and broker VM. Tape units belong to backup and recovery planning, not endpoint detection and response deployment.

The local router's ISP connection.

Why it fails: The ISP connection is external network infrastructure, not a Cortex XDR architectural component. Cortex XDR comprises the management console, endpoint agents and broker VM. ISP connectivity would be relevant when troubleshooting WAN reachability, not when describing XDR architecture.

Configure a Behavioral Threat Protection rule to block USB device installation.

Why it fails: Behavioral Threat Protection focuses on detecting malicious process behaviors, not on device control. It cannot be used to allow specific USB devices. Using BTP for this purpose would be ineffective and could cause false positives. Device Control profiles are designed specifically for managing USB and other peripheral devices.

Set the Device Control profile action to 'Report' for all USB devices.

Why it fails: Setting the action to 'Report' would only log USB device connections without blocking them. This does not restrict usage; it merely provides visibility. To block all but specific devices, the action must be 'Block' with exceptions. Reporting is insufficient for enforcing a restrictive USB policy.

Enable the 'Block USB Mass Storage' option in the Malware Profile.

Why it fails: The Malware Profile contains options for scanning and blocking malware, not for granular USB device control. While it may have a setting to block USB mass storage, it does not support exceptions for specific devices. Device Control profiles are the correct feature for allowing specific USB devices while blocking others.