I85PREP
⌘ K
XSIAM Analyst study materials
XSIAM Analyst study resources

XSIAM Analyst practice questions

One question at a time. Build your XSIAM Analyst understanding.

First 50 of 200 questions. Each one lists the choices, the correct answer, and an explanation. The checker at the top of this page saves progress in this browser when it is available.

Continue in the practice tool above to load more questions, 50 at a time.

Question 1Automation with Cortex XSIAM

In Cortex XSIAM automation, which component is the container that groups related tasks, inputs, and outputs so a workflow can be versioned and reused?

  1. A script library entry
  2. A playbook Correct answer.
  3. A data model
  4. A correlation rule

Explanation

A playbook is the orchestration container: it holds the task graph, typed inputs and outputs, and can be versioned and reused across incidents. Correlation rules and data models belong to detection and normalization rather than orchestration.

Question 2Automation with Cortex XSIAM

An analyst wants a playbook to start automatically whenever a new high-severity incident is created. Which configuration achieves this?

  1. Add the playbook to the script library and reference it from a layout
  2. Enable the playbook inside the data model mapping
  3. Attach the playbook as a trigger to the incident type and severity condition Correct answer.
  4. Schedule the playbook on a recurring job every minute

Explanation

Playbooks run automatically when a trigger matches, and triggers are defined against incident fields such as type and severity. Attaching the trigger to the incident condition makes execution event-driven rather than manual or scheduled.

Question 3Automation with Cortex XSIAM

Which statement best describes the role of inputs in a Cortex XSIAM playbook?

  1. They determine which users may edit the playbook
  2. They store the credentials used by every task automatically
  3. They define the schedule on which the playbook runs
  4. They declare the typed values the playbook expects when it is invoked Correct answer.

Explanation

Inputs form the playbook's typed interface, so callers such as triggers, parent playbooks, or manual runs supply values the tasks consume. Access control and scheduling are separate settings, and credentials are handled by integrations.

Question 4Automation with Cortex XSIAM

A task in a playbook needs the incident ID to query additional context. Where does the task obtain that value at runtime?

  1. From the analyst's browser session cookie
  2. From the incident context available to the playbook during execution Correct answer.
  3. From the integration's server-side configuration file
  4. From a hard-coded constant in the task configuration

Explanation

During execution the playbook has access to incident context, so tasks reference fields such as the incident ID from that context. Hard-coding would break reuse, and browser or server configuration files are not incident data sources.

Question 5Automation with Cortex XSIAM

What is the primary purpose of a conditional task in a Cortex XSIAM playbook?

  1. To pause execution until an analyst approves
  2. To retry a failed integration command automatically
  3. To normalize raw logs before ingestion
  4. To branch execution based on a evaluated expression or task output Correct answer.

Explanation

Conditional tasks evaluate expressions against context or prior outputs and route execution down the matching branch. Retry behavior, manual approval, and normalization are handled by other mechanisms.

Question 6Automation with Cortex XSIAM

An analyst must ensure a playbook waits for human confirmation before isolating an endpoint. Which task type fits this requirement?

  1. A manual task that pauses until an analyst responds Correct answer.
  2. A scheduled recurring job
  3. A conditional task that checks severity
  4. A built-in enrichment task

Explanation

Manual tasks suspend the playbook and present a form or question to an analyst, resuming only after a response. This provides the human-in-the-loop gate required before a disruptive action such as isolation.

Question 7Automation with Cortex XSIAM

Which Cortex XSIAM capability lets analysts run ad-hoc queries against ingested data to support investigations?

  1. Layout rule
  2. Data model rule
  3. Playbook trigger
  4. XQL query Correct answer.

Explanation

XQL is the query language used to search and analyze data ingested into Cortex XSIAM, and it powers investigations and detection logic. Triggers, data model rules, and layout rules serve different purposes.

Question 8Automation with Cortex XSIAM

What does an integration instance represent in Cortex XSIAM automation?

  1. A configured connection to an external system that playbook commands use Correct answer.
  2. A single playbook execution record
  3. A user role with elevated permissions
  4. A normalized field in the data model

Explanation

An integration instance stores the connection parameters and credentials for an external product, and playbook tasks invoke that instance's commands. It is distinct from execution records, schema fields, and roles.

Question 9Automation with Cortex XSIAM

A playbook should only escalate an incident when the file hash is unknown to the organization's allowlist. Which approach implements this correctly?

  1. Query the allowlist and use a conditional task to branch on the result Correct answer.
  2. Isolate the endpoint and then check the allowlist
  3. Disable the trigger and rely on analyst review
  4. Add the hash to the allowlist before evaluating it

Explanation

The check must happen before the decision, so the playbook queries the allowlist and branches on the returned result. Acting first and checking later inverts the logic and could cause unnecessary isolation.

Question 10Automation with Cortex XSIAM

A playbook task calls an integration command that fails intermittently due to timeouts. What is the most appropriate configuration to handle this?

  1. Configure retries with a delay on the task and branch on final failure Correct answer.
  2. Remove the integration instance
  3. Ignore the error and continue to the next task
  4. Convert the task to a manual approval

Explanation

Transient failures are best handled with bounded retries and a delay, then branching to a fallback path if retries are exhausted. Silently continuing hides the failure and manual approval does not address the transient cause.

Question 11Automation with Cortex XSIAM

Which construct allows one playbook to invoke another playbook and receive its outputs?

  1. A sub-playbook task Correct answer.
  2. A correlation rule
  3. A parsing rule
  4. A layout rule

Explanation

Sub-playbook tasks call a child playbook, pass inputs, and expose the child's outputs to the parent for later tasks. The other options are detection, presentation, and ingestion constructs.

Question 12Automation with Cortex XSIAM

An analyst needs the playbook to loop over every returned IP address and enrich each one. Which task behavior supports this?

  1. Iterate over the list and run the enrichment for each element Correct answer.
  2. Run the enrichment once on the first element only
  3. Skip enrichment when more than one address is returned
  4. Join the addresses into a single string and enrich once

Explanation

Iteration runs a task once per element in a list, so each IP address receives its own enrichment and output. Processing only the first element or a joined string would drop per-indicator results.

Question 13Automation with Cortex XSIAM

What is the recommended way to store an API token that a playbook integration uses?

  1. In the incident description field
  2. In a credential field of the integration instance Correct answer.
  3. In a public script library variable
  4. In plain text inside a playbook task comment

Explanation

Sensitive values belong in protected credential fields of the integration instance so they are masked and managed centrally. Embedding tokens in comments, incident fields, or shared script variables exposes them.

Question 14Automation with Cortex XSIAM

A trigger must fire only for incidents of type Malware with high severity. Which trigger configuration is correct?

  1. Match on the analyst's username
  2. Match on incident type equals Malware and severity equals High Correct answer.
  3. Match on the playbook name
  4. Match on any incident regardless of fields

Explanation

Triggers evaluate field conditions, so combining type and severity filters ensures the playbook runs only for the intended incidents. Matching on unrelated attributes would either over-fire or never fire.

Question 15Automation with Cortex XSIAM

During a playbook run, a task produces a list of indicators that later tasks must reference. What is the standard mechanism for passing that data forward?

  1. Store the value in context under a defined key and reference it downstream Correct answer.
  2. Email the value to the SOC distribution list
  3. Write the value to a text file on the analyst's workstation
  4. Re-run the producing task in each later task

Explanation

Task outputs are written to context under keys that later tasks reference, which keeps data flow explicit and reusable. External files, email, and repeated execution are unreliable and break the automation chain.

Question 16Automation with Cortex XSIAM

Which statement about playbook versions and the debugger is accurate?

  1. The debugger modifies production incidents directly
  2. Publishing a draft immediately overwrites all prior run history
  3. Versions cannot be compared after publishing
  4. The debugger can execute a draft version with sample inputs before publishing Correct answer.

Explanation

The debugger lets analysts run a draft playbook with sample inputs and inspect task results without affecting production incidents. Publishing creates a usable version while prior versions and run history remain available.

Question 17Automation with Cortex XSIAM

A team wants a playbook to close incidents automatically only after all enrichment tasks succeed. How should the flow be structured?

  1. Close the incident in the trigger definition
  2. Gate the close task behind conditions that verify each enrichment succeeded Correct answer.
  3. Place the close task first and enrich afterward
  4. Rely on the default incident lifecycle without conditions

Explanation

Conditions must verify successful enrichment before the close task runs, which prevents premature closure of unresolved incidents. Closing first or relying on defaults bypasses the verification.

Question 18Automation with Cortex XSIAM

An analyst wants to reuse a block of tasks across several playbooks without duplicating it. Which feature is intended for this?

  1. A duplicated task in each playbook
  2. A separate data model per playbook
  3. A correlation rule per playbook
  4. A sub-playbook called by each parent Correct answer.

Explanation

Extracting shared logic into a sub-playbook lets multiple parents call the same implementation, so fixes propagate in one place. Duplication invites drift, and correlation rules and data models are unrelated to task reuse.

Question 19Automation with Cortex XSIAM

A playbook must enrich an indicator but continue gracefully if the external enrichment service is unavailable. Which design best satisfies this?

  1. Hard-code the enrichment result
  2. Remove enrichment to avoid any failure
  3. Wrap the enrichment in a branch that handles failure and continues with partial context Correct answer.
  4. Abort the entire incident on the first enrichment failure

Explanation

Handling the failure branch lets the playbook proceed with whatever context is available while recording the gap. Aborting on any failure makes automation brittle, and removing or faking enrichment defeats its purpose.

Question 20Automation with Cortex XSIAM

Which XQL construct would an analyst use inside automation to count how many times a host appeared in authentication failures over the past day?

  1. A trigger that fires on every incident
  2. An integration instance named for authentication
  3. A layout rule that hides the host column
  4. A query that filters authentication failure events, groups by host, and aggregates the count Correct answer.

Explanation

XQL supports filtering, grouping, and aggregation, so grouping authentication failures by host over a time window yields the count. Layout rules, triggers, and instance names do not compute aggregates.

Question 21Automation with Cortex XSIAM

A playbook loops over indicators and calls an external API that enforces a strict rate limit. What is the most robust design?

  1. Disable the integration to avoid the limit
  2. Throttle iterations with a delay and handle rate-limit responses with retry and backoff Correct answer.
  3. Ignore rate-limit errors and continue
  4. Send all requests simultaneously to finish faster

Explanation

Rate-limited APIs require pacing requests and honoring retry-after or backoff signals so calls succeed without being rejected. Parallel bursts worsen throttling, and ignoring errors loses results.

Question 22Automation with Cortex XSIAM

A SOC wants every malware incident to run a standard triage playbook, but only after a custom field named Region is populated. Which design enforces this requirement?

  1. Trigger on the Region field only
  2. Trigger on the incident type plus a condition that Region is non-empty Correct answer.
  3. Trigger manually from the layout
  4. Trigger on the incident type alone and let tasks fail if Region is missing

Explanation

Combining the incident type with a presence check on Region ensures the playbook runs only when both conditions hold. Triggering on type alone risks runs with missing data, and triggering on Region alone ignores incident type.

Question 23Automation with Cortex XSIAM

An analyst observes that a shared sub-playbook returns different output keys depending on which branch executed. What is the best remediation?

  1. Remove all conditional branches from the sub-playbook
  2. Standardize the sub-playbook outputs so every branch sets the same keys Correct answer.
  3. Return outputs only through incident notes
  4. Have each parent playbook guess the key names

Explanation

A sub-playbook contract should expose a stable set of output keys regardless of internal branching, so parents can reference them reliably. Guessing keys or abandoning conditionals creates fragile automation.

Question 24Automation with Cortex XSIAM

A playbook must decide whether to block a domain based on enrichment from three independent sources where at least two must agree it is malicious. Which design implements this correctly?

  1. Block based on the incident severity alone
  2. Block only if all three sources return malicious
  3. Block if any single source returns malicious
  4. Collect all three verdicts and use a condition that requires at least two malicious results Correct answer.

Explanation

The requirement is a majority vote, so the playbook gathers all verdicts and a condition evaluates whether at least two are malicious. Any-source or all-source logic implements different thresholds, and severity alone ignores enrichment.

Question 25Automation with Cortex XSIAM

A playbook that previously ran on every new incident stops firing after a change. Which troubleshooting step is most likely to identify the cause first?

  1. Inspect the trigger conditions and confirm the incident fields still match Correct answer.
  2. Delete and recreate all integration instances
  3. Reset the analyst's UI preferences
  4. Rebuild the data model from scratch

Explanation

When event-driven automation stops firing, the trigger conditions and the fields they evaluate are the first suspect, especially after a configuration change. Rebuilding data models or integrations is disruptive and unrelated to trigger matching.

Question 26Automation with Cortex XSIAM

In Cortex XSIAM automation, which object is the reusable, versioned unit that contains tasks, inputs, and outputs and is executed by a trigger or manually?

  1. An integration instance
  2. A playbook Correct answer.
  3. A layout rule
  4. A dataset schema

Explanation

A playbook is the versioned automation unit that holds tasks, inputs, and outputs and can be launched by a trigger, a parent playbook, or manually. Integration instances only supply connectivity and credentials to commands invoked from tasks, and layouts and datasets belong to the investigation and data layers rather than orchestration.

Question 27Automation with Cortex XSIAM

Which component of Cortex XSIAM automation is responsible for evaluating conditions against an incoming incident and then starting the appropriate playbook?

  1. The trigger Correct answer.
  2. The command
  3. The task
  4. The mapper

Explanation

Triggers define the event conditions, such as incident type and severity, that cause a playbook to run automatically. Tasks are steps inside a playbook, commands are the integration actions those tasks call, and mappers translate raw data into incident fields.

Question 28Automation with Cortex XSIAM

An analyst wants to test a playbook change against a real incident without affecting live incident data or notifying downstream systems. Which capability should the analyst use?

  1. A production trigger with a broader filter
  2. A direct API call to the integration
  3. The playbook debugger with a test incident Correct answer.
  4. A scheduled job on the production tenant

Explanation

The debugger runs a playbook against a selected or synthetic incident in an isolated context so the analyst can inspect task inputs and outputs without mutating the live incident. Broadening a production trigger or running against live data risks side effects such as notifications or containment actions.

Question 29Automation with Cortex XSIAM

Which Cortex XSIAM automation building block lets an analyst define a named, typed value once and reference it from multiple tasks and playbooks?

  1. A playbook input Correct answer.
  2. A layout field
  3. A task comment
  4. A war room entry

Explanation

Playbook inputs (and their parent-level equivalents) define named values that tasks reference, so a value such as a threshold or region can be set once and reused. Comments, war room entries, and layout fields are documentation or display artifacts and are not evaluated as task parameters.

Question 30Automation with Cortex XSIAM

What is the purpose of a task condition (conditional task) in a Cortex XSIAM playbook?

  1. To branch execution based on the result of an expression or a previous task output Correct answer.
  2. To convert an incident into a case automatically
  3. To retry a failed command automatically a fixed number of times
  4. To assign the playbook to a different integration instance

Explanation

Conditional tasks evaluate expressions against inputs or prior task outputs and route the flow down the matching branch. Retry behavior, instance selection, and incident conversion are handled by other settings, not by the branching condition itself.

Question 31Automation with Cortex XSIAM

Which statement best describes the relationship between an integration and a command in Cortex XSIAM automation?

  1. An integration bundles related commands, and each command performs one action against the external product Correct answer.
  2. An integration and a command are the same object with different display names
  3. A command bundles integrations, and each integration performs one action
  4. A command stores credentials, and an integration stores the output schema

Explanation

An integration packages the connection definition plus a set of commands, and each command maps to a specific API operation such as blocking an IP or querying a reputation service. Credentials live on the integration instance, not on the command.

Question 32Automation with Cortex XSIAM

An analyst wants a playbook to run automatically every time a new incident of type Phishing is created. Which configuration achieves this?

  1. A layout that displays Phishing incidents
  2. A task that polls the incidents table on a schedule
  3. A manual run from the playbook editor
  4. A trigger whose incident type condition matches Phishing Correct answer.

Explanation

Triggers are the mechanism that starts playbooks in response to incident creation or update events, so matching on incident type Phishing is the direct configuration. Polling tasks, manual runs, and layouts do not provide reliable automatic execution on creation.

Question 33Automation with Cortex XSIAM

Which construct in a Cortex XSIAM playbook passes a value produced by one task into a later task?

  1. The integration instance name
  2. The playbook description
  3. The incident layout
  4. The task output reference Correct answer.

Explanation

Later tasks reference earlier results through output references, typically expressed as a context path pointing at the producing task. Instance names, layouts, and descriptions carry no runtime data between tasks.

Question 34Automation with Cortex XSIAM

A SOC lead wants a playbook to run only on incidents that already have a populated custom field named AssetOwner. Which trigger condition should be used?

  1. A field-based condition requiring AssetOwner to be non-empty Correct answer.
  2. A time-based condition that fires every hour
  3. A condition on the incident ID being numeric
  4. A condition on the playbook version number

Explanation

Trigger conditions can evaluate incident fields, so requiring the custom field AssetOwner to be populated gates execution until the data exists. Time-based, ID-format, and version conditions have no relationship to field population.

Question 35Automation with Cortex XSIAM

An analyst needs a playbook to iterate over a list of user accounts returned by an enrichment command and run a disable action on each one. Which approach is correct?

  1. Use a conditional task that checks whether the list is empty
  2. Place the disable action once and pass the whole list as a single argument
  3. Create one playbook per account and run them in parallel manually
  4. Use a loop task over the list and place the disable action inside the loop Correct answer.

Explanation

Loop tasks iterate over a collection and execute the nested tasks once per element, which is the supported pattern for per-item actions. Passing the whole list to a single-item command fails, and manual per-account playbooks do not scale.

Question 36Automation with Cortex XSIAM

A playbook task must run only when the previous enrichment returned a score above 70, and otherwise the playbook should continue down a benign path. Which design implements this?

  1. A conditional task with two branches, one for score above 70 and a default branch Correct answer.
  2. A loop task over all scores
  3. A manual approval task on every run
  4. A single task with a retry configured for failures

Explanation

A conditional task evaluates the score and routes the flow to the malicious branch or the default benign branch, keeping both paths explicit. Retries address failures, loops repeat work, and manual approval adds unnecessary human gating.

Question 37Automation with Cortex XSIAM

A playbook must continue after an enrichment command fails so that remaining indicators are still processed. Which task setting should be configured?

  1. Increase the playbook timeout
  2. Disable the trigger temporarily
  3. Set the task to run only once
  4. Mark the task as continuing on error Correct answer.

Explanation

Configuring the task to continue on error lets the playbook proceed to later tasks even when the command fails, which preserves processing of the remaining indicators. Run-once, timeout, and trigger changes do not alter error propagation for that task.

Question 38Automation with Cortex XSIAM

An analyst wants to reuse the same sequence of containment tasks across several playbooks while keeping one maintenance point. Which approach is appropriate?

  1. Store the tasks in a layout and reference the layout
  2. Convert the tasks into a saved query
  3. Copy the tasks into each playbook and edit them separately
  4. Extract the sequence into a sub-playbook and call it from each parent Correct answer.

Explanation

A sub-playbook centralizes the shared task sequence, and each parent calls it and receives its outputs, so a fix is made in one place. Copying tasks creates drift, and layouts and saved queries cannot execute containment actions.

Question 39Automation with Cortex XSIAM

Which mechanism allows a parent playbook to consume a value produced inside a called sub-playbook?

  1. The parent re-runs the sub-playbook until the value appears
  2. The parent reads the sub-playbook description text
  3. The sub-playbook declares outputs that the parent references after the call task Correct answer.
  4. The parent queries the audit log for the value

Explanation

Sub-playbooks expose declared outputs, and the parent references those outputs from the call task's result context. Descriptions, audit logs, and repeated runs are not supported data-passing mechanisms and would be unreliable.

Question 40Automation with Cortex XSIAM

A playbook needs to send a notification only when an incident remains open after a defined waiting period. Which design achieves this?

  1. Insert a timer or wait task before the notification and check incident status afterward Correct answer.
  2. Rely on the trigger to fire again after the waiting period
  3. Send the notification immediately at the start of the playbook
  4. Add a comment task describing the waiting period

Explanation

A timer or wait task pauses the flow, and a subsequent condition checks whether the incident is still open before notifying. Immediate notification ignores the wait, and comments do not affect execution.

Question 41Automation with Cortex XSIAM

An analyst wants to validate that a playbook's output schema matches what downstream tasks expect before publishing a new version. Which practice is most appropriate?

  1. Disable all downstream tasks permanently
  2. Remove the output definitions from the sub-playbook
  3. Publish the version and monitor production incidents for errors
  4. Run the playbook in the debugger and inspect each task's outputs Correct answer.

Explanation

The debugger exposes each task's inputs and outputs, letting the analyst verify that keys and types match what downstream tasks consume before publishing. Publishing first risks production failures, and removing outputs breaks consumers.

Question 42Automation with Cortex XSIAM

A playbook must block an indicator only when a reputation lookup returns a malicious verdict. Which element enforces this constraint?

  1. A comment documenting the policy
  2. A conditional task that checks the verdict before the block task Correct answer.
  3. A second trigger on the block command
  4. A loop task around the block command

Explanation

The conditional task evaluates the verdict and allows the block task to run only on the malicious branch. Loops, comments, and extra triggers do not evaluate the verdict and would allow blocking regardless of reputation.

Question 43Automation with Cortex XSIAM

An analyst needs to call an external enrichment service that enforces a strict per-minute request limit while processing many indicators. Which approach is most robust?

  1. Process indicators in bounded batches with a wait between batches Correct answer.
  2. Skip the enrichment for most indicators
  3. Send all indicators concurrently in a single burst
  4. Retry failed calls immediately in a tight loop

Explanation

Batching with a wait between batches keeps request volume within the service limit while still enriching every indicator. Bursts and tight retry loops trigger rate limiting, and skipping indicators degrades detection quality.

Question 44Automation with Cortex XSIAM

A task returns a list of IP addresses, and a later task must act on the first address only. Which approach is correct?

  1. Use a loop to run the action once per element
  2. Convert the list to a string and pass it unchanged
  3. Pass the entire list to a command that accepts one address
  4. Reference the first element of the list in the later task's parameter Correct answer.

Explanation

Indexing the list and referencing the first element supplies a single value to a single-value command. Passing the whole list or its string form violates the command's expected input, and a loop would act on every address rather than only the first.

Question 45Automation with Cortex XSIAM

A playbook must enrich a domain using three independent reputation sources and block only when at least two report it as malicious. Which design implements this logic?

  1. Block the domain before running any lookups
  2. Run the three lookups, count malicious verdicts, then branch on the count being at least two Correct answer.
  3. Run the lookups and block if any single source reports malicious
  4. Run one lookup and infer the other two verdicts

Explanation

Running all three lookups and counting malicious verdicts lets the flow branch on a threshold of two, which matches the stated policy. Blocking on a single source or before enrichment violates the two-source requirement, and inferring verdicts fabricates data.

Question 46Automation with Cortex XSIAM

A sub-playbook is invoked from several parents, and the parent's downstream task fails because the expected output key is missing. What is the most likely cause?

  1. The trigger filter excludes the incident type
  2. The sub-playbook branch that produces the key did not execute for that input Correct answer.
  3. The parent playbook version number is lower than the sub-playbook version
  4. The integration instance has no credentials configured

Explanation

If the sub-playbook returns different output keys depending on which branch ran, a parent that assumes a key from a non-executed branch receives nothing. Version numbers, credentials, and trigger filters would produce different symptoms, such as connection errors or no execution at all.

Question 47Automation with Cortex XSIAM

A playbook that previously fired on every new incident stops firing after a change. Which troubleshooting step is most informative first?

  1. Add more tasks to the playbook
  2. Increase the playbook timeout value
  3. Review the trigger configuration and its conditions against a recent matching incident Correct answer.
  4. Delete and recreate the integration instance

Explanation

When automatic execution stops after a change, the trigger definition and its conditions are the most likely cause, so comparing them with a recent incident quickly confirms whether the filter no longer matches. Timeouts, extra tasks, and instance recreation address unrelated failure modes.

Question 48Automation with Cortex XSIAM

An analyst must ensure that a containment action is recorded with the incident, the executing playbook, and the task that performed it. Which mechanism provides this traceability?

  1. The war room entries and task-level results associated with the incident Correct answer.
  2. The playbook description field
  3. The integration instance configuration
  4. The dataset retention policy

Explanation

War room entries and task-level results record what ran, which playbook and task executed it, and the outcome, all tied to the incident. Descriptions, instance configuration, and retention policy describe settings rather than execution history.

Question 49Automation with Cortex XSIAM

A playbook must enrich an indicator but continue gracefully when the external service is unavailable, while still flagging the incident for review. Which design best satisfies both requirements?

  1. Ignore the failure and close the incident automatically
  2. Fail the playbook immediately so no further tasks run
  3. Retry indefinitely until the service recovers
  4. Continue on error for the enrichment task and set a flag that a later condition uses to request review Correct answer.

Explanation

Continuing on error keeps the flow alive, and a flag consumed by a later condition routes the incident to review so the gap is visible. Failing immediately halts processing, indefinite retries stall the playbook, and silent closure hides the missing enrichment.

Question 50Automation with Cortex XSIAM

An analyst wants a playbook to run a custom script that parses a proprietary log format and return structured fields to later tasks. Which approach is appropriate?

  1. Add a script task that returns a structured result consumed by downstream tasks Correct answer.
  2. Store the parsing logic in the incident layout
  3. Encode the logic in the trigger condition
  4. Add a comment task containing the parsing logic

Explanation

Script tasks execute custom code and return structured results that later tasks reference, which fits proprietary parsing needs. Comments, layouts, and trigger conditions cannot execute parsing logic or return structured data.