XSIAM-Analyst Automation And Playbooks Practice Test 5 — 15 Questions

Question 1

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?

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

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 2

You are troubleshooting a Cortex XSIAM playbook that unexpectedly stopped executing after a script task returned an error. You want to understand how the playbook engine handles task-level errors so you can design more resilient flows. Which TWO statements accurately describe how task errors and playbook continuation behave in Cortex XSIAM? (Choose two.)

Accepted Answer

Error information from a failed task, such as the error message, is available in the task result and can be referenced by later tasks in the playbook.. Cortex XSIAM lets you define error paths so a failing task can route the playbook to alternate handling instead of stopping, and failed tasks still expose error details in their results for downstream tasks to consume. Automatic fixed retries are not a guaranteed engine default, and immediate total termination is not the only behavior. Together, configurable error paths and accessible error details are what enable resilient playbook design.

Answer

By default, when a task fails, the entire playbook run is immediately terminated and no subsequent tasks execute.

Answer

Once a task fails, the playbook cannot reference any output from that task anywhere later in the run under any configuration.

Answer

A failed task always automatically retries the exact same task a fixed number of times before the playbook moves on.

Question 3

A playbook loops over a list of forty endpoints and runs an isolation command on each. Midway through, the integration returns a rate-limit error on one endpoint. The team wants the playbook to log the failure for that endpoint and continue processing the remaining endpoints rather than aborting the entire run. Which configuration achieves this?

Accepted Answer

Set the isolation task's execution mode to continue on error so the loop proceeds to the next item while recording the failure.. Setting the task to continue on error lets the loop skip past a failed endpoint while capturing the failure in logs, so all remaining endpoints are still processed. This is the standard pattern for bulk operations where individual failures should not halt the workflow. Timeout changes, outer conditionals, and assumed automatic retries do not address per-item failure tolerance inside a loop.

Answer

Wrap the entire loop in a single conditional task that checks whether any endpoint failed before continuing.

Answer

Increase the integration instance's timeout value so the rate-limit error does not occur during the loop.

Answer

Reduce the loop batch size to one and rely on the playbook engine to retry failed iterations automatically.

Question 4

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 5

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 6

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 7

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 8

An analyst wants to reuse the same sequence of enrichment, scoring, and notification tasks across five different playbooks without duplicating the logic in each. Which XSIAM construct should be used to achieve this reuse?

Accepted Answer

A sub-playbook that encapsulates the shared tasks and is called from each parent playbook, receiving inputs and returning outputs.. Sub-playbooks are designed for exactly this reuse pattern, encapsulating a sequence of tasks behind a defined input and output interface that parent playbooks invoke as one step. This keeps logic centralized so updates propagate to all callers. Scheduled jobs, global inputs, and monolithic scripts do not provide inline, context-aware task-sequence reuse with native logging and error handling.

Answer

A global playbook input that stores the task sequence as a reusable variable referenced by all five playbooks.

Answer

A scheduled job that runs the shared sequence on a timer and writes results to a shared list variable.

Answer

A custom automation script that reimplements every task's API calls in code and is called from each parent playbook.

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 invokes a sub-playbook to perform malware analysis on an uploaded file. The sub-playbook can return a verdict of malicious, suspicious, or benign, and the parent playbook must take different response actions for each. How should the parent playbook consume the sub-playbook's result to drive those branching actions?

Accepted Answer

Read the sub-playbook's returned output and evaluate it in conditional tasks that route to each response path.. When a parent playbook invokes a sub-playbook, the sub-playbook returns outputs that the parent can reference. Evaluating the returned verdict in conditional tasks lets the parent route to distinct malicious, suspicious, or benign response paths. Manual inspection, global context keys, and error signaling are all unsuitable because they either break automation, risk cross-incident leakage, or conflate valid verdicts with failures.

Answer

Set the sub-playbook to raise an error for any verdict other than benign so the parent's error handler runs.

Answer

Configure the sub-playbook to write the verdict into the parent's global context key.

Answer

Inspect the sub-playbook's War Room entries manually and then run the parent playbook again.

Question 11

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 12

A security team wants a Cortex XSIAM playbook to run automatically the moment a new high-severity incident is created, without any analyst clicking a button. Which configuration makes the playbook start on its own when the incident is generated?

Accepted Answer

Attach the playbook to the incident type so it triggers automatically when a matching incident is created. Automatic, event-driven execution in Cortex XSIAM comes from binding a playbook to an incident type, so creation of a matching incident immediately launches the playbook with no human involvement. The other mechanisms either distribute, display, or periodically poll, none of which start the playbook at the instant the incident is generated, which is what the scenario requires for immediate automated response.

Answer

Add the playbook to a dashboard widget that refreshes whenever a new incident appears

Answer

Create a scheduled job that launches the playbook every minute to check for new incidents

Answer

Publish the playbook to the marketplace so subscribers receive it and run it on new incidents

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 analyst is writing a Cortex XSIAM playbook in which a task's output must be passed to a later task that sits on a different branch of the workflow. The later task cannot see the value because it is not a direct descendant of the producing task. What should the analyst do to make the value available where it is needed?

Accepted Answer

Write the value into the incident context so the downstream task can reference the shared key. Playbook task outputs are scoped to the producing task's branch and its descendants, so a task on an unrelated branch cannot resolve them directly. Writing the value into incident context removes that scoping restriction because context is shared across the entire playbook run, letting any task on any branch reference the stored key. This is the supported way to pass data across divergent workflow paths.

Answer

Move the downstream task into the same branch as the producing task and rerun the playbook

Answer

Increase the task's execution timeout so its output has time to propagate to other branches

Answer

Convert the producing task into a manual task so its output persists across branches

Question 15

A Cortex XSIAM playbook must contain a task that only runs when the alert severity is Critical, while the surrounding tasks run for every incident. The analyst wants the playbook to skip that single task cleanly for non-critical incidents and continue with later tasks rather than stopping the branch. Which mechanism should be used?

Accepted Answer

Add a conditional task before the block so only critical incidents enter the branch containing the task. The need is to execute one task only under a specific condition while allowing the rest of the playbook to proceed normally for all incidents. A conditional task placed before the gated block evaluates alert severity and routes only critical incidents into the branch containing that task; everyone else follows the default path and continues. This cleanly skips the task without stopping the workflow.

Answer

Wrap the task in a loop that iterates over critical incidents only and exits immediately otherwise

Answer

Set the task to optional so that failures inside it are ignored for non-critical incidents

Answer

Configure the task to run only when its input resolves, relying on an empty input for non-critical incidents