XSOAR-Engineer Playbook Development Practice Test 1 — 15 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

Question 11

An engineer needs a playbook task to dynamically select an integration instance based on the incident's source brand. The playbook must not hard-code a single instance name because multiple instances of the same integration exist for different tenants. Which configuration should the engineer use?

Accepted Answer

Set the task's 'Using' field to a dynamic value derived from incident context, such as ${incident.brand}.. The 'Using' field of an integration command task accepts a literal instance name or a dynamic value from context. Setting it to a context path such as ${incident.brand} lets the playbook resolve the correct instance at runtime, supporting multiple tenants without hard-coding. Other approaches either duplicate logic, bypass platform features, or introduce unpredictable instance selection.

Answer

Use a script task to call the integration command directly via the REST API.

Answer

Create a separate playbook for each tenant and trigger them by incident type.

Answer

Leave the 'Using' field empty so XSOAR automatically picks the first available instance.

Question 12

An XSOAR Engineer is building a playbook that processes phishing incidents. They need to call the '!get-ip-reputation' command from a configured integration instance, but the command requires an incident field 'reported_ip' that is populated only after a previous task completes. The engineer wants to ensure the command runs with the correct value. What is the correct way to reference the incident field in the task's arguments?

Accepted Answer

Use the syntax ${incident.reported_ip} in the argument value field.. The correct approach is to reference the incident field using the ${incident.reported_ip} syntax. This ensures the task retrieves the value from the incident context at runtime. Other syntaxes either reference playbook inputs, custom fields incorrectly, or omit the necessary prefix, leading to empty or incorrect values. This is a fundamental technique for dynamic task configuration in XSOAR playbooks.

Answer

Use the syntax ${incident.customFields.reported_ip} in the argument value field.

Answer

Use the syntax ${inputs.reported_ip} in the argument value field.

Answer

Use the syntax ${reported_ip} directly in the argument value field.

Question 13

You are building a playbook that must loop over a list of indicators and run an enrichment command for each one. The number of indicators is unknown at design time and can be up to 500. To avoid overwhelming the enrichment integration and to keep the playbook readable, you want the loop to process the list in fixed-size chunks. Which configuration should you use in the playbook task?

Accepted Answer

Use a 'ForEach' task and enable the 'Batch' option, then set the batch size to the desired chunk size.. The ForEach task with Batch mode is the native way to iterate over a list in groups. By specifying a batch size, the loop body receives a list of items per iteration, so the enrichment command can accept multiple indicators at once. This reduces the number of calls, respects integration rate limits, and keeps the playbook simple because no custom recursion or manual data collection is needed.

Answer

Use a 'ForEach' task with the 'Built-in' loop type and set the 'max iterations' field to 500.

Answer

Use a 'Data Collection' task with a grid field and map each indicator to a row, then process rows one by one.

Answer

Use a 'Conditional' task that checks the list length and then calls a sub-playbook recursively until the list is empty.

Question 14

An XSOAR Engineer is designing a playbook that includes a sub-playbook. The sub-playbook needs to receive input from the parent playbook and return results back. Which TWO configurations are required to pass data from the parent playbook into the sub-playbook and retrieve output? (Choose two.)

Accepted Answer

Define input arguments in the sub-playbook and map them to parent playbook context keys when configuring the sub-playbook task.. To pass data into a sub-playbook, you define input arguments in the sub-playbook and map parent context keys to them when configuring the sub-playbook task. To retrieve results, you configure output mappings in the sub-playbook task to assign sub-playbook context values to parent context keys. These two configurations are essential for bidirectional data flow.

Answer

Add a 'Data Collection' task in the sub-playbook to capture parent context values.

Answer

Enable the 'Share context' option in the sub-playbook settings to automatically merge all sub-playbook context into the parent.

Answer

Use the 'Set' task in the parent playbook to write values directly into the sub-playbook's context.

Question 15

An engineer is building a playbook that calls a sub-playbook to enrich indicators. The sub-playbook sets several context keys under a custom namespace. The engineer wants the parent playbook to access these keys directly without modifying the sub-playbook. Which configuration in the sub-playbook task ensures the sub-playbook's context is merged into the parent incident context?

Accepted Answer

In the sub-playbook task, set 'Context' to 'Current incident' and enable 'Merge context'.. To merge a sub-playbook's context into the parent incident without altering the sub-playbook, the engineer must configure the sub-playbook task to use the current incident context and enable context merging. This setting causes any new or updated context keys from the sub-playbook to be propagated to the parent incident, making them accessible in subsequent tasks. Other options either require sub-playbook changes or do not exist.

Answer

In the sub-playbook task, select 'Use current incident context' and clear 'Private'.

Answer

Set the sub-playbook's 'Outputs' to include the desired keys.

Answer

Enable 'Share context' in the sub-playbook task settings.