XSIAM-Analyst Practice Test 13 — 15 Questions

Question 1

An analyst notices that a specific Windows server's Cortex XDR agent is consuming unusually high CPU and the endpoint occasionally stops sending telemetry. The analyst suspects a scanning-related performance issue caused by the agent monitoring a large, rapidly changing data directory. Which action should the analyst take to reduce agent overhead while retaining threat detection elsewhere on the server?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Create a malware scanning exclusion for the high-churn data directory path.. The high CPU and telemetry gaps trace to the agent continuously scanning a large, high-churn directory. A path-specific malware scanning exclusion stops that repetitive inspection, lowering CPU load and restoring steady telemetry, while real-time protection continues to guard the rest of the server, balancing performance with detection coverage.

Answer

Move the server to an endpoint group with a lower-frequency scan schedule profile.

Answer

Disable the agent's real-time protection entirely on the server to stop the CPU spike.

Answer

Uninstall and reinstall the agent to clear a corrupted scan cache causing the high usage.

Question 2

During an incident investigation, an analyst needs the playbook to fetch the reputation of every IP address observed in the alert and then act on the results. The number of IPs varies per alert, and the same enrichment and decision steps must run once for each address. Which XSIAM playbook construct should the analyst use to iterate over the dynamic list of IP addresses?

Accepted Answer

A loop task that iterates the enrichment and decision sub-tasks over the list of IP addresses. The requirement is to repeat the same enrichment and decision logic for an unknown number of IP addresses, which is the defining use case for a loop task in Cortex XSIAM playbooks. A loop iterates its enclosed tasks over each element of a list, so every address is enriched and evaluated independently, and the playbook scales automatically with the alert's contents rather than requiring manually duplicated tasks.

Answer

A conditional task that evaluates each IP address against a reputation threshold

Answer

A data collection task that aggregates the IP addresses into a single indicator object

Answer

A manual task that prompts the analyst to enrich each IP address one at a time

Question 3

An analyst is designing a Cortex XSIAM playbook that must pass data between tasks without relying on ad hoc string parsing. Which TWO methods allow a downstream task to consume the output of an upstream task? (Choose two.)

Accepted Answer

Mapping the upstream task's output fields into a context key that the downstream task references.. Downstream tasks consume upstream output either by referencing the task's context key directly or by mapping output fields into named context keys. Both approaches use the playbook context as the transport layer, keeping data structured and available to subsequent tasks. Direct log parsing, manual inputs, and incident-field round trips are not supported patterns for task-to-task data flow.

Answer

Copying the upstream task's output into the incident description field and reading it back with a search.

Answer

Using a playbook input that is manually populated by the analyst after each upstream task completes.

Answer

Reading the upstream task's raw log entry from the automation execution log file.

Question 4

A Cortex XSIAM playbook is triggered by a new incident and runs an isolation task on the affected endpoint. The analyst wants the playbook to pause and require a human to approve the isolation before it executes, because the endpoint belongs to an executive. Which task type should be placed before the isolation task?

Accepted Answer

A manual task that assigns an approval action to a specified analyst or role.. Manual tasks are the XSIAM mechanism for human-in-the-loop control. They halt execution and present an approval or input request to a specified user or role, and the playbook continues only after a response. Placing a manual approval task before isolation satisfies the policy that executive endpoints require explicit human authorization.

Answer

A timer task that waits 30 minutes before continuing automatically.

Answer

A data collection task that asks the analyst to type the endpoint hostname.

Answer

A conditional task that checks the endpoint's owner department.

Question 5

During a playbook run in Cortex XSIAM, an enrichment task that queries an external reputation service returns a large JSON object. A later task needs only the value of the 'reputation' field to decide whether to escalate. What is the most efficient way to make that value available to the later task?

Accepted Answer

Reference the specific context key path produced by the enrichment task in the later task's condition. Task outputs in Cortex XSIAM are stored as structured context, so a later task can reference the exact key path of the reputation field without copying or transforming the whole object. This keeps the condition precise and avoids redundant API calls or file operations. Notes, re-runs, and CSV exports either fail to expose the value to automation or add needless overhead.

Answer

Copy the entire JSON output into a note attached to the incident

Answer

Export the JSON to a CSV file and have the later task read the file

Answer

Re-run the enrichment task and store the result in a new incident field

Question 6

A Cortex XSIAM playbook contains a task that calls an internal ticketing API. The API occasionally returns HTTP 429 when the ticketing system is under heavy load. The analyst wants the playbook to retry the call a few times before marking the task as failed. Which task configuration should be applied?

Accepted Answer

Set the task's retry count and retry interval in the task settings. The ticketing API is intermittently rate-limiting, so the playbook should tolerate transient failures by re-attempting the call. Task-level retry settings specify how many times and at what interval a failed task is re-executed, which is the native mechanism for this. Ending the playbook, extending timeouts, or moving the call to another playbook do not provide controlled retries within the task.

Answer

Move the API call into a separate playbook that runs on a schedule

Answer

Add a conditional task that checks for HTTP 429 and ends the playbook

Answer

Increase the playbook execution timeout so the API has more time to respond

Question 7

A Cortex XSIAM playbook closes incidents automatically after containment. During testing, analysts notice that a playbook launched by one incident also modified a second, unrelated incident because a task output contained a stale incident ID from a previous run. Which playbook design principle should be applied to prevent this cross-incident contamination?

Accepted Answer

Reference incident identifiers only from the current playbook's incident context rather than from stored task outputs.. Cross-incident contamination occurs when a playbook reads identifiers from stored task outputs that may hold values from earlier runs. Sourcing the incident ID from the current execution's incident context guarantees each playbook instance acts only on the incident that triggered it. Global keys and concurrency tuning do not provide that per-run isolation, and hard-coded checks cannot work across unique incident IDs.

Answer

Increase the playbook's maximum concurrent executions to reduce overlap between runs.

Answer

Store the incident ID in a global context key that persists across playbook runs.

Answer

Add a conditional task that verifies the incident ID matches a hard-coded expected value.

Question 8

A Cortex XSIAM playbook includes a task that calls an external threat intelligence API. The API occasionally returns a rate-limit error (HTTP 429). The analyst wants the playbook to retry the call a few times with increasing delays before giving up and continuing with the rest of the playbook. Which configuration on the task best achieves this?

Accepted Answer

Set the task to retry on failure with exponential backoff and a maximum retry count, and configure the task to continue on error after retries are exhausted.. The API returns transient rate-limit errors that can be overcome by retrying with increasing delays. Exponential backoff with a maximum retry count provides those increasing delays and bounds the total attempts. Configuring the task to continue on error after retries are exhausted allows the playbook to proceed with the remaining steps instead of halting. Fixed delays, asynchronous polling, and ignoring errors do not satisfy both the retry and continue requirements.

Answer

Set the task to run asynchronously and poll for the result, with no retry policy configured.

Answer

Set the task to retry on failure with a fixed delay and a maximum retry count, and configure the task to stop the playbook on error.

Answer

Set the task to ignore errors and proceed immediately to the next task without retrying.

Question 9

A Cortex XSIAM analyst wants a playbook to automatically enrich every new high-severity incident with threat intelligence before any analyst reviews it. The enrichment must run without human interaction as soon as the incident is created. Which approach best satisfies this requirement?

Accepted Answer

Configure the playbook to trigger automatically on incident creation and include the enrichment integration tasks in its flow. The requirement is autonomous enrichment at incident creation. Automatically triggering the playbook on incident creation and embedding the enrichment integration tasks in its flow ensures threat intel is gathered immediately without analyst action. Manual runs, daily scheduled scans, and upfront manual confirmation tasks all introduce human dependency or delay and therefore fail the stated requirement.

Answer

Add a manual task at the start of the playbook so an analyst confirms the incident is high severity before enrichment runs

Answer

Create a scheduled job that scans all incidents every 24 hours and enriches any that lack threat intel

Answer

Assign the incident to an analyst queue and rely on the analyst to run the enrichment playbook manually

Question 10

A Cortex XSIAM playbook must process a list of suspicious IP addresses returned by an enrichment task. For each IP, the playbook should query a reputation service and record the verdict. The number of IPs varies per incident. Which XSIAM playbook construct should you use to iterate over the list and run the reputation query for each entry?

Accepted Answer

A loop task that iterates over the list and executes the reputation query task for each element. Because the number of IPs varies and each needs an individual reputation query, a loop task is the appropriate construct. It iterates over the collection and runs the contained query task once per element, aggregating results. A single bulk call, a conditional check, or manual entry cannot reliably repeat the per-IP query for a variable-length list.

Answer

A single automation task that passes the entire list to the reputation service in one call

Answer

A manual task where the analyst copies each IP into the reputation query form by hand

Answer

A conditional task that checks whether the list is empty and otherwise proceeds without iterating

Question 11

A security analyst is handling a new incident in Cortex XSIAM. The incident contains a high-severity alert for 'Suspicious PowerShell Execution' on host FIN-PC-07. The analyst wants to quickly determine the parent process of the PowerShell instance to understand how it was launched. Which XSIAM feature should the analyst use?

Accepted Answer

Causality View. Causality View is the correct tool because it visually maps the process execution chain, allowing the analyst to immediately see the parent process of the suspicious PowerShell instance. This helps determine the initial infection vector, such as a malicious document or script. Other options either require manual querying or provide different types of information not focused on process ancestry.

Answer

Incident Timeline

Answer

Threat Intelligence Platform

Answer

XQL Query Builder

Question 12

An XSIAM analyst is investigating an incident where a user's credentials were likely compromised. The analyst wants to gather evidence of potential credential misuse. Which TWO XSIAM data sources or views should the analyst examine? (Choose two.)

Accepted Answer

Authentication logs from identity providers such as Active Directory or Okta. Authentication logs and endpoint process execution history are the most direct sources for evidence of credential misuse. Authentication logs show anomalous logins, while process history reveals actions taken with the compromised account. Other sources may provide context but are not primary evidence of credential misuse.

Answer

Network flow data showing top talkers by bandwidth

Answer

Email gateway logs for spam and phishing messages

Answer

Firewall logs showing blocked outbound connections

Question 13

A Cortex XSIAM playbook task calls an external service, but the service is intermittently unavailable, causing the task to fail. You want the playbook to attempt the call again a few times before declaring failure, without stopping the rest of the playbook. Which approach should you implement?

Accepted Answer

Build a loop with a counter and a conditional check that retries the call until it succeeds or the counter reaches a limit. Handling intermittent external failures requires deliberate, bounded retry logic. A loop with a counter and a conditional exit attempts the call again a limited number of times, resuming normal flow on success or after exhausting attempts. Assuming unlimited automatic retries, relying on manual retries, or deleting the task all fail to provide controlled, unattended retry behavior.

Answer

Remove the failing task from the playbook so the rest of the flow executes without contacting the external service

Answer

Insert a manual task that asks an analyst to click retry whenever the external service becomes available again

Answer

Rely on the playbook engine to automatically retry every failed task an unlimited number of times

Question 14

An XSIAM analyst is handling a critical ransomware incident. The analyst finishes containment, remediation, and verification, and wants to close the incident with the correct status so that reporting reflects a genuine security event that was resolved. Which incident status should the analyst select?

Accepted Answer

Resolved - True Positive. Closing a verified, remediated ransomware event requires a status that communicates a genuine detection resolved through response. Resolved - True Positive captures both facts: the alert was malicious and the work is done. False positive and duplicate statuses misrepresent the event, while an open status contradicts the completed remediation and distorts lifecycle reporting.

Answer

Resolved - Duplicate

Answer

Resolved - False Positive

Answer

In Progress

Question 15

An analyst is reviewing the XSIAM Analytics page and notices that a specific analytic alert has a status of 'Under Investigation' but is not linked to any incident. The analyst wants to understand why this alert is not appearing in the Incidents view. What is the most likely reason for this behavior?

Accepted Answer

The alert has not yet met the criteria for incident creation based on the incident grouping rules.. Alerts in XSIAM are generated by analytics and are separate from incidents. Incident creation occurs when alerts match incident grouping rules. An alert can be under investigation without being part of an incident. Therefore, the alert will not appear in the Incidents view until it is grouped into an incident by the system or manually promoted. The other options incorrectly attribute the behavior to closure, failed promotion, or alert type.

Answer

The alert was manually promoted to an incident but the promotion failed due to a permissions issue.

Answer

The alert is a standard alert, and standard alerts never appear in the Incidents view unless they are first converted to incident-bound alerts.

Answer

The alert is automatically closed and therefore not visible in the Incidents view.