SecOps-Pro Cortex XSOAR And Automation Practice Test 3 — 15 Questions

Question 1

A playbook task is configured to run on a 'Worker' group. If you see the task stuck in 'Pending' state, what is the most likely cause?

Accepted Answer

No workers are assigned to the specified group. In SOAR platforms like Palo Alto Cortex XSOAR, a playbook task assigned to a specific Worker group (e.g., 'Worker') will remain in 'Pending' state if no active worker is registered to that group. Workers poll the task queue for their assigned group; without a worker, the task cannot be picked up and executed. The 'Pending' state specifically indicates the task is waiting for an available worker in the designated group, not that the task itself is malformed or the system is overloaded.

Answer

The playbook is too large

Answer

The task is not marked as 'Automated'

Answer

The database is locked

Question 2

Which tab in the Incident view provides a real-time, user-friendly summary of the investigation status?

Accepted Answer

Summary. The Summary tab in the Incident view is designed to provide a real-time, user-friendly overview of the investigation status. It aggregates key details such as incident severity, status, assignee, and a timeline of events, giving analysts an at-a-glance understanding without navigating multiple tabs. This aligns with the goal of a quick, high-level summary for efficient incident management.

Answer

Indicators

Answer

Work Plan

Answer

Evidence

Question 3

Where can you view the 'Context Data' for a specific incident?

Accepted Answer

Context Data tab. The context data is visible in the 'Context Data' tab within the Incident view.

Answer

Playbook Editor

Answer

Integration Log

Answer

System Configuration

Question 4

What is the function of a 'Transformer' in a mapper?

Accepted Answer

To modify or format data between source and target fields. Transformers allow you to manipulate or format data during the mapping process from the source to the target incident field.

Answer

To run a secondary playbook

Answer

To change the incident type

Answer

To assign the incident to an analyst

Question 5

If an automation script is taking too long to run, how can you improve its performance?

Accepted Answer

Refactor the script to use batch processing instead of individual API calls. The dominant performance cost in XSOAR automation scripts is usually the number of API calls made to the Cortex XSOAR server or external systems. Refactoring to batch operations — for example using demisto.executeCommand with multiple entries, or the batch endpoints of the underlying API — reduces round-trip overhead and dramatically speeds up execution. This addresses the root cause (I/O latency and per-call overhead) rather than masking it.

Answer

Add more logging to the script

Answer

Change the script language to Java

Answer

Increase the integration timeout limit

Question 6

When designing a custom layout, how do you make a field read-only for specific roles?

Accepted Answer

Use the Field Permissions setting in the Layout editor. In the Layout editor, you can set permissions on individual fields to control which roles have read-only or read-write access.

Answer

Write a script to hide the field

Answer

Use the incident lifecycle stage

Answer

Disable the field in System Settings

Question 7

What happens if a playbook task is configured to 'Continue on error' and the task fails?

Accepted Answer

The playbook proceeds to the next task. When a playbook task is configured with 'Continue on error', a failure of that task does not halt the playbook; execution proceeds to the next task in the flow. This is used for non-critical steps where a failure should be logged but not block the overall response. The error is typically recorded in the task output or war room for later review.

Answer

The incident is closed

Answer

The playbook stops immediately

Answer

The task is automatically retried

Question 8

Which tool in Cortex XSOAR helps you debug a playbook in real-time by stepping through tasks?

Accepted Answer

Playbook Debugger. The Playbook Debugger allows you to run a playbook in a controlled environment, inspecting data at each step.

Answer

System Health Monitor

Answer

Audit Logs

Answer

Integration Debugger

Question 9

Which THREE of the following are valid components of a standard Content Pack?

Accepted Answer

Scripts. A standard Content Pack is a bundled, versioned collection of reusable configuration and automation assets that can be installed into a platform (such as Cortex XSOAR or a similar SOAR/security platform). Option A (Scripts) is correct because automation scripts are a core content-pack component, packaged so they can be executed by playbooks or commands. Option B (Dashboards) is correct because dashboards and widgets are commonly shipped inside content packs to provide prebuilt visualizations and reporting. Option D (Playbooks) is correct because playbooks are the primary automation artifacts distributed in content packs, defining the orchestrated response workflows. Option C (System Logs) is not a component of a content pack; logs are runtime output generated by the platform, not packaged content. Option E (Integration instances) is not a component either; instances are environment-specific configurations created when an integration is enabled, whereas the content pack contains the integration definition itself, not the configured instance.

Answer

System Logs

Answer

Integration instances

Question 10

Which TWO settings are configurable within an Integration Instance?

Accepted Answer

Integration timeout. Within an Integration Instance, the Integration timeout (A) is configurable because each instance defines how long the integration command may run before it is aborted, allowing tuning per instance to match the target system's response characteristics. Proxy settings (C) are also configurable at the Integration Instance level, since an instance can be routed through a specific proxy (or no proxy) to reach an on-prem or external endpoint. Incident retention policy (B) is a system/instance-wide data management setting, not part of an integration instance's configuration. Playbook triggering logic (D) belongs to playbook configuration (triggers, tasks, and conditions), not to the integration instance. Indicator expiration time (E) is governed by indicator type/reputation settings, not by an integration instance.

Answer

Incident retention policy

Answer

Playbook triggering logic

Answer

Indicator expiration time

Question 11

Which TWO methods can be used to pass data from a parent playbook to a sub-playbook?

Accepted Answer

Incident Context. Data is passed to sub-playbooks via defined input mappings or by reading directly from the incident context.

Answer

Hard-coding the context path

Answer

Database injection

Answer

Global variables

Question 12

Which THREE factors influence the performance of playbook execution?

Accepted Answer

Script complexity. Script complexity (A) is correct because the amount and intricacy of the automation logic — number of tasks, conditional branches, loops, and API calls — directly determines how long a playbook takes to execute. The number of active workers (C) is correct because workers are the execution engines that run playbook tasks; more available workers allow tasks to be processed in parallel rather than queued, improving throughput. The number of concurrent tasks (D) is correct because running many tasks simultaneously increases resource contention (CPU, memory, API rate limits), which can either speed up or degrade overall playbook performance depending on capacity. Incident display layout (B) is incorrect because it is purely a UI presentation concern and has no effect on backend playbook execution. User password length (E) is incorrect because it only affects authentication strength and has no bearing on how fast or efficiently a playbook runs.

Answer

Incident display layout

Answer

User password length

Question 13

Which THREE types of tasks can be added to a playbook workflow?

Accepted Answer

Condition task. In a playbook workflow, the three supported task types are Condition, Manual, and Automated tasks. A Condition task (A) is correct because it evaluates a logical expression or check and branches the workflow based on whether the result is true or false, enabling decision logic. A Manual task (C) is correct because it pauses the workflow and requires a human user to perform an action or provide input before the playbook can continue. An Automated task (D) is correct because it executes a predefined script, command, or integration action without human intervention. The remaining options do not belong: a Database cleanup task (B) is not a distinct playbook task type but rather a specific action that could be implemented inside an Automated task, and an Encryption task (E) is likewise not a separate task category but a function that would be performed by an Automated task or script.

Answer

Database cleanup task

Answer

Encryption task

Question 14

Which TWO of the following are true regarding the use of the 'Context' in Cortex XSOAR?

Accepted Answer

Context is the primary way to pass data between playbook tasks. The context is incident-specific and persistent throughout the investigation, and it acts as the primary data exchange mechanism.

Answer

Context data is automatically cleared every 24 hours

Answer

Context only supports string data types

Answer

Context data is shared between different incidents

Question 15

Which THREE actions can be performed from the Incident 'Work Plan' tab?

Accepted Answer

Skip a task. The Incident 'Work Plan' tab is designed to manage the individual tasks that make up an incident's remediation workflow, so option A (Skip a task) is correct because operators can bypass a pending task that is no longer needed or applicable. Option C (Re-run a failed task) is correct because the Work Plan allows retrying a task that did not complete successfully, which is a core remediation action. Option E (View task execution logs) is correct because each task exposes its execution output and logs directly from the Work Plan for troubleshooting. Options B (Change the server OS) and D (Add a new incident type) are not Work Plan actions: changing an OS is an infrastructure/provisioning operation, and adding an incident type is a configuration/administration function, neither of which is performed from the incident's task list.

Answer

Change the server OS

Answer

Add a new incident type