XSOAR-Engineer Playbook Development — 10 Questions

Question 1

An engineer is writing a playbook expression to filter a list of endpoints from context. They want to return only the endpoints where the 'OS' field equals 'Windows'. Which built-in transformer syntax is correct?

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

Accepted Answer

Using the 'Val' transformer with a conditional expression like 'val.OS == \'Windows\''. The grep transformer or filter syntax using jq-like syntax or XSOAR built-in transformers is used. Specifically, the 'Access' or 'Filter' transformer with condition syntax is applied.

Answer

${Endpoints.OS(val == 'Windows')}

Answer

${Endpoints | filter(OS == 'Windows')}

Answer

${Endpoints.[?(OS == 'Windows')] }

Question 2

An engineer has configured a Loop Task in a playbook to iterate over a list of 50 IP addresses. To prevent the playbook from timing out or overwhelming the external API, the engineer needs to execute batches of 10 items concurrently. Where is this concurrency setting configured?

Accepted Answer

In the Loop tab of the specific playbook task properties drawer. In XSOAR loop task configurations, the concurrency or batch size can be defined under the task's Loop configuration settings to control parallel execution limits.

Answer

In the playbook-level JSON file under the 'canvas' properties

Answer

In the integration instance settings for the executed command

Answer

In the global server configuration (Server Settings -> Incidents)

Question 3

You need to ensure that a playbook task execution fails gracefully if the underlying integration command returns an error, allowing the playbook to continue down an alternative error-handling path. Which setting must you configure on the task?

Accepted Answer

Set 'Continue on error' under the task's Error Handling tab. By configuring the 'On error' setting of a task, an engineer can dictate whether a failure stops the playbook, continues, or routes down a specific error branch.

Answer

Enable 'Skip task if empty' in the Task Details

Answer

Wrap the command in a try-except Python wrapper inside the playbook UI

Answer

Add a Post-processing script that catches exceptions

Question 4

An XSOAR Engineer is configuring a playbook task and needs to reference the output of a previous task named 'Get Incident Details'. Which syntax is correct to access the 'ID' key from that task's output context?

Accepted Answer

${GetIncidentDetails.ID}. Task outputs are stored in the Incident Context using the naming convention ${TaskName.Key}. Therefore, ${GetIncidentDetails.ID} correctly retrieves the ID from the specified task.

Answer

${incident.GetIncidentDetails.ID}

Answer

${task.GetIncidentDetails.ID}

Answer

$GetIncidentDetails[ID]

Question 5

An engineer has completed building a new playbook and wants to test it on a live incident without affecting production data. What is the recommended method to test playbook modifications?

Accepted Answer

Run the playbook on a test incident in an XSOAR test environment or development instance. Engineers can test playbooks on existing test incidents or use the Playground feature within an incident to run specific tasks or playbooks safely.

Answer

Export the playbook as a zip file and import it into a dashboard widget

Answer

Delete the old playbook and publish the new one directly to production

Answer

Enable 'Debug Mode' in server configurations and restart the service

Question 6

An engineer is utilizing the 'Set' task to manipulate context data. They want to clear an existing context key named 'MaliciousIP' entirely so subsequent tasks do not read stale data. How should this be configured in the Set task?

Accepted Answer

Set the value of 'MaliciousIP' to 'null' or leave the value field empty while checking the overwrite option.. To clear or overwrite a context key, you can assign an empty value or use specific context clearing methods provided by built-in automation helpers like ClearContext.

Answer

Run a bash command via integration to purge the Redis database.

Answer

Rename the playbook to force a context reset.

Answer

Delete the task and recreate the playbook canvas from scratch.

Question 7

Which visual indicator on a playbook task in the canvas signifies that the task is configured as a starting point (the entry point) of the playbook?

Accepted Answer

A green play/start icon or specific start node shape. The start task in an XSOAR playbook is typically represented as a distinct starting node connected to the first execution step.

Answer

A dashed border around the task box

Answer

A red exclamation mark badge

Answer

A padlock symbol in the corner

Question 8

Which THREE actions can be performed using the Loop task configuration in a Cortex XSOAR playbook? (Choose three)

Accepted Answer

Iterate over a list of items stored in the incident context. Option B is correct because the Loop task in a Cortex XSOAR playbook is designed to iterate over a list of items (for example, an array stored under a context key such as ${incident.items}) and run its sub-tasks once per element. Option D is correct because the Loop task configuration exposes settings for batch size and concurrency, allowing parallel iterations to be throttled so that only a defined number run simultaneously. Option E is correct because the Loop task supports an exit/stop condition evaluated against the context, enabling the loop to terminate early when a specified expression becomes true. Option A is not a Loop task capability; generating PDF incident reports requires separate tasks or integrations, not the loop configuration. Option C is invalid because no playbook task can directly alter the core XSOAR database schema, which is managed by the platform itself.

Answer

Automatically convert all looped outputs into PDF incident reports

Answer

Directly modify the core XSOAR database schema during each iteration

Question 9

An engineer is troubleshooting a playbook where a task fails intermittently because an upstream integration command takes too long to return data. Which THREE configuration options or features can the engineer use to handle this timeout issue effectively? (Choose three)

Accepted Answer

Use asynchronous task execution where supported so the playbook continues while the command runs in the background.. Option A is correct because asynchronous task execution (e.g., Ansible's async/poll or Cortex XSOAR's async commands) lets the playbook continue running while the long-running integration command executes in the background, preventing the timeout from blocking the workflow. Option C is correct because task-level timeout settings let the engineer define how long a task may run before it fails gracefully or branches to an alternate path, directly addressing intermittent slow upstream responses. Option E is correct because retry settings automatically re-execute a task that fails or times out, which is an effective mitigation for intermittent latency in upstream integrations. Option B is not appropriate because increasing global server CPU allocation via the CLI is a resource-scaling action, not a timeout-handling feature, and does not guarantee the upstream command returns faster. Option D is not appropriate because modifying the incident type layout only changes the UI display and hides slow tasks without resolving the underlying timeout failure.

Answer

Increase the global server CPU allocation via the CLI.

Answer

Modify the incident type layout to hide slow tasks.

Question 10

An XSOAR Engineer is building a playbook with a conditional task that should route incidents to different branches depending on severity. The engineer wants the condition to evaluate a custom incident field named 'impactlevel' that contains a string value. Which of the following is the correct way to reference this field in the task's condition expression?

Accepted Answer

incident.customFields.impactlevel. The correct reference is 'incident.customFields.impactlevel' because custom incident fields are nested under the 'customFields' object within the incident context. This path allows the condition to accurately read the string value and evaluate it. Other variations either miss the required 'incident' root or incorrectly assume a different structure, leading to evaluation failures.

Answer

customFields.impactlevel

Answer

incident.impactlevel.value

Answer

incident.impactlevel