Cortex XSIAM practice questions

Incident response playbooks

Why it fails: Playbooks are for remediation, not data parsing.

Dashboard widgets

Why it fails: Dashboards are for visualization, not data ingestion pipelines.

Agent Policy Profiles

Why it fails: Agent Policy Profiles govern endpoint agent behaviour, such as malware protection and scanning, not server-side log parsing. They are tempting because they configure data collection on endpoints, but normalisation occurs in Cortex XSIAM's Broker VM parsing rules and data model mappings, so inspecting agent profiles cannot resolve unparsed logs.

Cortex Collector Pro

Why it fails: Cortex Collector Pro is not a valid XSIAM component name.

Cortex Agent Relay

Why it fails: The Agent Relay manages agent communication, not log ingestion.

XSIAM API Gateway

Why it fails: The API Gateway is for programmatic access, not log ingestion.

Data Ingestion menu

Why it fails: The Data Ingestion menu configures log sources and ingestion pipelines, not endpoint connectivity. It is correct when onboarding or troubleshooting data feeds, but endpoint registration status is shown in the Endpoints view, not ingestion settings.

Incident Response console

Why it fails: The Incident Response console manages cases, alerts and investigations, not endpoint connectivity state. It is the correct place when triaging a security incident, but endpoint registration and health are surfaced in the Endpoints view under Inventory.

System Logs

Why it fails: System Logs record platform and audit events for troubleshooting, not live endpoint connection state. It is the right destination when investigating configuration changes or errors, whereas connected endpoint status appears in the Endpoints inventory page.

Data Ingestion Pipeline

Why it fails: This is for bringing data in, not sending it out.

XQL Export Tool

Why it fails: While XQL can export results, Log Forwarding is the architectural feature for streaming.

Incident Export API

Why it fails: This is for incidents, not raw log data streaming.

Data ingestion filter

Why it fails: Filters would drop logs, not trigger alerts.

Playbook incident trigger

Why it fails: Playbooks act on existing incidents, they don't generate alerts from raw logs.

Dashboard alert threshold

Why it fails: Dashboards do not trigger alerts.

Physical asset location

Why it fails: Asset location is not part of a detection rule.

Database schema index

Why it fails: This is system-managed, not a rule component.

Physical hard drive wiping

Why it fails: This is not a function of the agent.

Automatic software installation

Why it fails: The agent is for security, not software deployment.

Changing system BIOS passwords

Why it fails: This is outside the agent's scope.

dataset = xdr_data | filter actor_effective_username = "svc_backup" and action_remote_port = 445 | fields action_remote_ip | limit 100

Why it fails: This query lacks the `dedup` stage, so it will return every connection event, including many duplicates for the same destination IP. The analyst would have to manually sift through repeated entries to find unique hosts. Additionally, the `limit` stage arbitrarily caps results at 100, which may exclude relevant hosts if there are many connections. It also does not restrict the timeframe to 24 hours.

dataset = xdr_data | filter actor_effective_username = "svc_backup" and action_remote_port = 445 | comp count() by action_remote_ip

Why it fails: The `comp` stage is used to compute aggregations, such as counting events per destination IP. While this would show how many times each IP was contacted, it does not directly return the unique list of destination IP addresses. The analyst would get a count per IP, but the requirement is to identify all unique hosts, not their connection frequencies. This adds unnecessary complexity and does not match the goal.

dataset = xdr_data | filter actor_effective_username = "svc_backup" and action_remote_port = 445 | fields action_remote_ip | distinct action_remote_ip

Why it fails: The `distinct` keyword is not a valid XQL stage; XQL uses `dedup` for deduplication. Attempting to use `distinct` will result in a syntax error, and the query will fail to execute. The analyst would not get any results. The correct approach is to use `dedup` to achieve unique values. This option is a common misconception for those familiar with SQL.

Syslog collector

Why it fails: A syslog collector is used to receive logs over the syslog protocol, but the custom application writes JSON to a local file, not to syslog. While the Broker VM can act as a syslog server, that would require the application to send syslog messages, which is not the case here. Therefore, it is not the correct component for this scenario.

XQL query engine

Why it fails: The XQL query engine is a backend component used for searching and analyzing data within Cortex XSIAM. It does not run on the Broker VM and is not involved in log collection or forwarding. Configuring it on the Broker VM would not enable ingestion of custom application logs.

Cortex XDR agent

Why it fails: The Cortex XDR agent is installed on endpoints to collect endpoint telemetry, not to ingest custom application logs from a Linux server. While it provides valuable endpoint data, it does not read arbitrary log files or forward them to XSIAM; that role belongs to the log collection components on the Broker VM.

Add the `comp` stage before the `fields` stage to extract the remote IP and port from the raw event.

Why it fails: The `comp` stage is used for computing new fields from existing ones using functions like `concat` or `format_string`. It does not extract nested or unmapped fields from raw event data. The remote IP and port are already structured fields in the network event schema, so `comp` is unnecessary and would not resolve the missing columns in this scenario.

Change the `fields` stage to `alter` and manually rename `action_remote_ip` and `action_remote_port` to match the schema.

Why it fails: The `alter` stage modifies or renames existing fields but does not add fields that are absent from the event. If the fields are not present in the event schema or are named differently, renaming will not surface them. This approach assumes the fields exist under a different name, which is not the case here.

Add a `limit` stage to restrict the number of returned rows, which forces XQL to populate all available fields.

Why it fails: The `limit` stage restricts the number of rows returned but does not affect which fields are populated or available. Missing fields remain missing regardless of row count. This option misinterprets the purpose of `limit`, which is purely for result set size control and has no impact on field extraction or schema mapping.

| bin _time span=5m

Why it fails: The 'bin' clause is used to group events into time buckets, which is useful for aggregation. However, it is not the primary clause for defining the overall time window of a correlation rule. The time window for the rule's search is typically set in the rule configuration, not within the XQL query itself. While 'bin' can be used for time-based aggregations within the query, it is not essential for defining the rule's time window.

| limit 1000

Why it fails: The 'limit' clause restricts the number of results returned by a query. It is often used to prevent overwhelming the system or to focus on a sample of events. However, it is not essential for defining the logic of a correlation rule. The rule's detection logic is based on conditions and time windows, not on an arbitrary result limit, which could actually cause the rule to miss events if set too low.

| sort by _time

Why it fails: The 'sort' clause is used to order events, typically by timestamp. While sorting can be useful for certain analyses, it is not essential for defining a correlation rule's logic. The correlation engine processes events as they arrive and uses the 'window' clause to group them, so explicit sorting is not required for the rule to function correctly.

Create a custom dashboard widget that displays incidents by severity and queue.

Why it fails: A dashboard widget is for visualization and monitoring, not for automating enrichment or routing. It does not perform any actions on incidents. While useful for oversight, it does not contribute to the automation logic, so it is not a required configuration for the described scenario.

Configure an incident type with a severity field and map it to a queue using the incident field mapping settings.

Why it fails: Incident types and field mappings define the structure and display of incidents but do not automatically route them to queues. Routing requires a playbook or assignment rule. While severity mapping is useful, it alone does not trigger enrichment or queue assignment, so it is not a required configuration for the described automation.

Enable the Threat Intelligence Management add-on and subscribe to a feed.

Why it fails: While enabling threat intelligence feeds provides data for enrichment, it is not a configuration required to automate enrichment and routing. The playbook must still query the feed and act on the results. Subscribing to a feed alone does not route incidents or trigger enrichment tasks, so it is not a required step for the automation described.

The 'action_local_ip' field is already mapped from another source field.

Why it fails: XDM fields can be mapped from multiple source fields, and conflicts are typically resolved by priority or last-write-wins logic. Having another source field mapped to the same XDM field would not prevent this new mapping from working. Therefore, this is not a likely cause of the mapping failure.

The XDM mapping rule for 'action_local_ip' is disabled.

Why it fails: XDM mapping rules are typically enabled by default and are global. Disabling a specific mapping rule would affect all data sources, not just this one. Since the administrator is configuring a new source, it is more likely that the issue is specific to this source's configuration rather than a global mapping rule being disabled.

The 'src_ip' field is not included in the dataset's schema.

Why it fails: In Cortex XSIAM, the dataset schema is flexible and can accommodate new fields. The absence of a field in the schema would not prevent it from being parsed and mapped; instead, the schema would be updated dynamically. Therefore, this is not the likely cause of the mapping failure.

Single value widget

Why it fails: A single value widget displays one aggregate number, such as a total count, but cannot show a breakdown by severity or a trend over time. It would not satisfy either the severity breakdown or the seven-day trend requirement. This widget is useful for headline metrics, not for the multi-category and time-series views described.

Text widget

Why it fails: A text widget displays static or templated text and does not render data visualizations such as counts by category or time-series trends. It cannot fulfill the requirement to show incident counts by severity or an alert trend. Text widgets are used for annotations or instructions, not for the data-driven components requested.

Gauge widget

Why it fails: A gauge widget shows a single value against a threshold or target range, which is unsuitable for a severity breakdown or a seven-day trend. It cannot represent multiple categories or a time series. While useful for capacity or SLA tracking, it does not meet the requirements for the incident severity count or the alert trend.

To replace the need for network security

Why it fails: The XSIAM Agent collects endpoint telemetry and executes response actions; it cannot substitute for network security controls such as firewalls, IDS or segmentation, which inspect traffic the agent never sees. It is tempting because XSIAM correlates network and endpoint signals centrally, but that is analytics, not enforcement.

To store all log data locally on the host

Why it fails: The agent streams endpoint events to Cortex XSIAM for correlation and detection rather than retaining them locally as the system of record. Local-only log storage describes host-based logging or a SIEM forwarder buffer, not the agent's cloud-analytics delivery function.

To manage firewall rules on the local host

Why it fails: The XSIAM Agent collects endpoint telemetry and forwards it for analytics; it does not configure host firewall policy, which is enforced by the endpoint's own firewall or management tooling. Firewall rule management belongs to dedicated host firewall administration, not the XSIAM agent's telemetry role.

SQL

Why it fails: Cortex XSIAM's investigation queries use XQL, its native query language, not SQL; SQL syntax and functions will not parse against XSIAM datasets. SQL is tempting because it is the familiar standard for relational databases, and would be correct when querying a conventional SQL-backed data warehouse.

SPL

Why it fails: SPL is Splunk's query language and is not natively parsed by Cortex XSIAM, so it cannot interrogate the dataset directly. It is tempting because SPL is widely known from Splunk environments and many SOC analysts arrive with that syntax already in hand.

KQL

Why it fails: KQL is Microsoft's language for Sentinel, Defender and Azure Data Explorer, not Cortex XSIAM's native query interface. It is tempting because KQL is common in Microsoft-centric SOCs and its pipe-based syntax superficially resembles XQL, leading analysts to assume portability.

Live Dashboard Preview

Why it fails: Live Dashboard Preview renders streaming telemetry in real time, so it cannot replay stored historical records through a rule. It is genuinely useful for confirming that a rule fires on live traffic as it arrives, but validating logic against past events requires the rule simulation capability instead.

Playbook Debugger

Why it fails: The Playbook Debugger steps through automation actions and their inputs, not detection logic against stored events. It is the right tool for diagnosing a failing playbook run, but simulating a detection rule over historical log data needs the rule simulation feature, which replays past events through the query.

XQL Query Builder

Why it fails: XQL Query Builder constructs and runs queries against datasets; it does not execute a detection rule's logic over historical data to test whether it would fire. The rule-testing or simulation capability is what the scenario needs. Query building is for ad-hoc hunting and investigation, not validating detection behaviour.

Detection Rules

Why it fails: Detection Rules define the logic that generates alerts; they do not hold the automated response execution logic. Automation is configured in playbooks, which trigger on alerts and run response actions. Detection Rules are tempting because they are where the phishing alert itself is defined.

XQL Search Filters

Why it fails: XQL search filters query and correlate ingested data for detection and investigation; they do not execute response actions. They are tempting because phishing alerts are surfaced through XQL-based rules, but the execution logic for automated response lives in playbooks, which XQL filters cannot invoke.

Data Ingestion Pipeline

Why it fails: The data ingestion pipeline normalises and parses incoming logs before they reach detection; it holds no playbook or automation logic. It is tempting because phishing alerts originate from ingested email data, but automated response execution belongs in playbooks triggered by alert rules, not in ingestion.

Alert Suppression Lists

Why it fails: Suppression lists hide or drop matching alerts entirely, removing them from the analyst queue rather than merging correlated alerts into one case. It is tempting because suppression visibly cuts alert volume, and would be correct where known benign detections must be silenced without further investigation.

Query Aggregation

Why it fails: Query aggregation combines results within a single query execution, not correlated alerts across detections into one incident. It is tempting because the word aggregation suggests consolidation, and would be correct where the aim is summarising events in one dataset for reporting or dashboarding.

Notification Thresholds

Why it fails: Notification thresholds govern when and how often alerts are dispatched, not how related alerts are grouped into one actionable item. It is tempting because thresholds directly reduce noise volume, and would be correct where the goal is limiting repeated notifications for the same recurring condition.

XQL Global Variables

Why it fails: XQL global variables store reusable query values for hunting and dashboards; they are not a threat-intelligence repository, so the correlation engine never consumes them as indicators. It is tempting because global variables are genuinely referenced across XQL queries, and they would be correct if the requirement were parameterising repeated hunting queries rather than feeding indicators.

Data Ingestion Mapping

Why it fails: Data Ingestion Mapping parses and normalises incoming raw logs into XSIAM datasets; it does not register indicator sources, so the correlation engine cannot match against the feed. It is tempting because ingestion configuration is genuinely required for log-based data, and it would be correct if the task were onboarding a new log source rather than a threat-intelligence feed.

Detection Rule Editor

Why it fails: The Detection Rule Editor builds analytics from ingested events, not external indicator feeds, so a custom feed defined there never reaches the correlation engine's indicator matching. It is tempting because detection rules do drive correlation, and it would be correct if the requirement were authoring a behavioural rule against existing telemetry rather than importing third-party indicators.