Scenario practice questions

A junior analyst responds to an incident and wants to leave a timestamped remark visible to the whole team that explains why a suspicious file was marked benign, without executing any command. Which action in the incident War Room accomplishes this?

Trap 1: Editing the incident's Details field from the incident summary panel

The Details field holds the incident description and is editable, but changes there are not timestamped conversation entries and do not appear as analyst remarks in the War Room. Team members scanning the War Room timeline would not see the rationale. This option fails the timestamped, team-visible remark requirement.

Trap 2: Adding a tag to the incident from the incident header

Tags are short labels used for filtering and grouping incidents, not narrative remarks. A tag cannot convey why a file was deemed benign, and it carries no analyst-attributed timestamped message. While tags are team-visible metadata, they do not fulfill the need for an explanatory note in the conversation.

Trap 3: Running the '!setIncident' command with a custom field for the…

setIncident writes values into incident fields; it does not create a conversational remark in the War Room. The text would live in a field, not in the team-visible timeline, and it requires executing a command, which the analyst was asked to avoid. This does not satisfy the visibility or no-command conditions.

A
Typing the remark into the War Room input box and pressing Enter to post a note
The War Room input box accepts free-text entries that become notes attributed to the analyst with a timestamp. Pressing Enter posts the remark to the shared conversation, making it visible to every team member reviewing the incident. No command execution is involved, which matches the requirement exactly.
B
Editing the incident's Details field from the incident summary panel
Why it fails: The Details field holds the incident description and is editable, but changes there are not timestamped conversation entries and do not appear as analyst remarks in the War Room. Team members scanning the War Room timeline would not see the rationale. This option fails the timestamped, team-visible remark requirement.
C
Adding a tag to the incident from the incident header
Why it fails: Tags are short labels used for filtering and grouping incidents, not narrative remarks. A tag cannot convey why a file was deemed benign, and it carries no analyst-attributed timestamped message. While tags are team-visible metadata, they do not fulfill the need for an explanatory note in the conversation.
D
Running the '!setIncident' command with a custom field for the remark
Why it fails: setIncident writes values into incident fields; it does not create a conversational remark in the War Room. The text would live in a field, not in the team-visible timeline, and it requires executing a command, which the analyst was asked to avoid. This does not satisfy the visibility or no-command conditions.

Question 2easymultiple choice

An administrator is planning to install a Cortex XSOAR server on a physical server running Ubuntu 20.04. The server will be used for a small team of 10 analysts. Which installation method is officially supported and recommended by Palo Alto Networks for this scenario?

Trap 1: Docker Compose deployment

Docker Compose is not an officially supported installation method for Cortex XSOAR server. While Docker is used for engines and integrations, the server itself is typically installed using a native installer or as a virtual appliance. Docker Compose deployments are not recommended for production servers.

Trap 2: Manual compilation from source code

Cortex XSOAR is not distributed as source code for manual compilation. The server is provided as a pre-built package or installer. Manually compiling from source is not supported and would be error-prone. Palo Alto Networks does not provide source code for the server.

Trap 3: Kubernetes Helm chart

A Kubernetes Helm chart is not an officially supported installation method for Cortex XSOAR server. While Cortex XSOAR can be deployed in containerized environments, the server component is not typically installed via Helm. This method is more common for other applications and is not recommended here.

A
Docker Compose deployment
Why it fails: Docker Compose is not an officially supported installation method for Cortex XSOAR server. While Docker is used for engines and integrations, the server itself is typically installed using a native installer or as a virtual appliance. Docker Compose deployments are not recommended for production servers.
B
Manual compilation from source code
Why it fails: Cortex XSOAR is not distributed as source code for manual compilation. The server is provided as a pre-built package or installer. Manually compiling from source is not supported and would be error-prone. Palo Alto Networks does not provide source code for the server.
C
Kubernetes Helm chart
Why it fails: A Kubernetes Helm chart is not an officially supported installation method for Cortex XSOAR server. While Cortex XSOAR can be deployed in containerized environments, the server component is not typically installed via Helm. This method is more common for other applications and is not recommended here.
D
Native installer script
Palo Alto Networks provides a native installer script for Linux-based installations of Cortex XSOAR server. This script automates the installation of dependencies, the server application, and required services. It is the recommended method for installing on a supported Linux distribution like Ubuntu 20.04.

Question 3easymultiple choice

When planning a new XSOAR automation use case for compromised credentials, an engineer must decide whether to automate the entire remediation lifecycle or keep a human-in-the-loop. Which scenario represents the best candidate for fully automated remediation?

Trap 1: Terminating employment status of a suspected insider threat.

Employment termination is an HR and legal decision with contractual consequences, so it cannot be executed autonomously by a playbook. It tempts because insider threats require fast containment, which would justify automated account disablement, not irreversible employment actions.

Trap 2: Deleting primary database backups on suspicion of data exfiltration.

Deleting backups is irreversible and destroys recovery capability, so it demands human authorisation before execution. It tempts because exfiltration is high-severity and urgent, which would justify automated containment such as isolating the host, not destroying data.

Trap 3: Revoking executive internet access during an ongoing ransomware…

Severing executive connectivity during an outbreak risks business-critical operations and needs human judgement about scope. It tempts because ransomware containment is time-sensitive, which would justify automated isolation of confirmed infected endpoints, not blanket revocation of executive access.

A
Disabling an Active Directory user account associated with confirmed malicious activity outside business hours.
Disabling a confirmed-malicious Active Directory account outside business hours suits full automation because the action is deterministic, reversible and time-critical, and no analyst is available to approve it. The confirmed-malicious constraint removes ambiguity, so the playbook can act immediately without human judgement.
B
Terminating employment status of a suspected insider threat.
Why it fails: Employment termination is an HR and legal decision with contractual consequences, so it cannot be executed autonomously by a playbook. It tempts because insider threats require fast containment, which would justify automated account disablement, not irreversible employment actions.
C
Deleting primary database backups on suspicion of data exfiltration.
Why it fails: Deleting backups is irreversible and destroys recovery capability, so it demands human authorisation before execution. It tempts because exfiltration is high-severity and urgent, which would justify automated containment such as isolating the host, not destroying data.
D
Revoking executive internet access during an ongoing ransomware outbreak.
Why it fails: Severing executive connectivity during an outbreak risks business-critical operations and needs human judgement about scope. It tempts because ransomware containment is time-sensitive, which would justify automated isolation of confirmed infected endpoints, not blanket revocation of executive access.

Read the full Ansible explanation →

Question 4mediummulti select

When designing SOC workflows and playbooks in XSOAR, which THREE best practices should an architect follow to ensure maintainability and readability? (Choose THREE)

Trap 1: Hardcode all API authentication tokens directly into every playbook…

Embedding credentials in task descriptions exposes secrets in playbook exports and version history, and forces edits across every task when a token rotates. Credentials belong in integration instances or the credential store. Hardcoding would only suit a throwaway local test with no shared repository.

Trap 2: Combine all enrichment, containment, and reporting steps into a…

One unbranched task defeats reuse, testing and parallel execution, and any failure aborts the whole chain. Playbooks should decompose into sub-playbooks and conditional branches. A single task would only fit a trivial linear action with no enrichment, decision points or containment.

A
Implement error handling and alternative paths (such as timeout or failure branches) for critical integration tasks.
Error handling and alternative paths directly satisfy the maintainability constraint: timeout and failure branches prevent a single integration outage from halting the entire playbook, keeping execution predictable. Explicit branches also document expected failure modes, so later engineers can read and modify the workflow without reverse-engineering implicit behaviour.
B
Hardcode all API authentication tokens directly into every playbook task description.
Why it fails: Embedding credentials in task descriptions exposes secrets in playbook exports and version history, and forces edits across every task when a token rotates. Credentials belong in integration instances or the credential store. Hardcoding would only suit a throwaway local test with no shared repository.
C
Utilize sub-playbooks to modularize complex or repeated workflow logic.
Sub-playbooks isolate repeated or complex logic into reusable, independently testable units, so a change to shared logic is made once rather than duplicated across parent playbooks. This directly satisfies the maintainability and readability requirement by shrinking each playbook's task graph.
D
Combine all enrichment, containment, and reporting steps into a single massive, unbranched task.
Why it fails: One unbranched task defeats reuse, testing and parallel execution, and any failure aborts the whole chain. Playbooks should decompose into sub-playbooks and conditional branches. A single task would only fit a trivial linear action with no enrichment, decision points or containment.
E
Give playbook tasks clear, descriptive names instead of leaving default integration command names.
Descriptive task names replace opaque default integration commands, so reviewers can follow playbook logic without opening each task. This directly satisfies the maintainability and readability constraint in the stem: self-documenting task labels reduce onboarding time and make future edits safer when SOC workflows grow.

Question 5hardmultiple choice

An enterprise XSOAR administrator is planning the deployment of remote engines (DEX - Demisto Execution Engines) across multiple isolated regional network zones. What is the primary architectural purpose of deploying remote engines in this scenario?

Trap 1: To bypass the need for API keys when connecting to external cloud…

Remote engines still require credentials and API keys configured for each integration instance; they route traffic, not authentication. It is tempting because engines sit inside the target network and can reach services the main server cannot, so a scenario involving network-restricted endpoints would be the correct reason to deploy them.

Trap 2: To replace the underlying PostgreSQL database cluster with local…

Remote engines execute integrations and commands within isolated networks; they do not host or replace the central PostgreSQL database, which remains on the main server. It is tempting because engines do cache some data locally, so a deployment needing offline resilience in a disconnected zone would be the correct scenario for local storage.

Trap 3: To provide local graphical user interfaces for regional SOC…

Remote engines are headless execution components with no user interface; analysts access the web console on the main XSOAR server. It is tempting because engines run close to regional infrastructure, so a scenario requiring local processing of sensitive data before forwarding results would be the correct reason for their deployment.

A
To bypass the need for API keys when connecting to external cloud services.
Why it fails: Remote engines still require credentials and API keys configured for each integration instance; they route traffic, not authentication. It is tempting because engines sit inside the target network and can reach services the main server cannot, so a scenario involving network-restricted endpoints would be the correct reason to deploy them.
B
To replace the underlying PostgreSQL database cluster with local SQLite files.
Why it fails: Remote engines execute integrations and commands within isolated networks; they do not host or replace the central PostgreSQL database, which remains on the main server. It is tempting because engines do cache some data locally, so a deployment needing offline resilience in a disconnected zone would be the correct scenario for local storage.
C
To execute integrations locally within isolated network segments and securely relay results back to the central XSOAR server.
Remote engines run integrations inside isolated network segments, reaching internal systems that the central server cannot access directly, then relay results back over an outbound connection. This satisfies the requirement to operate across isolated regional zones without inbound firewall openings.
D
To provide local graphical user interfaces for regional SOC analysts.
Why it fails: Remote engines are headless execution components with no user interface; analysts access the web console on the main XSOAR server. It is tempting because engines run close to regional infrastructure, so a scenario requiring local processing of sensitive data before forwarding results would be the correct reason for their deployment.

Question 6hardmulti select

A Cortex XSOAR administrator is preparing a recurring incident summary for the SOC manager. The manager wants a scheduled delivery that arrives every Monday at 07:00 local time and includes only incidents tagged with the 'VIP' label from the previous week. The administrator plans to use a scheduled report with a filter and must configure the delivery and content options correctly. Which two configurations are required to meet these requirements? (Choose two.)

Trap 1: Configure a War Room entry to trigger the report on demand from a…

Triggering a report from a playbook task is an on-demand mechanism, not a scheduled recurring delivery. The manager requires a predictable Monday 07:00 arrival, which only a scheduled report definition can provide; a playbook-triggered report would depend on incident activity and would not guarantee the cadence.

Trap 2: Set the report output format to CSV instead of PDF for easier…

Changing the output format to CSV affects only how the report is rendered, not when it runs or which incidents it contains. The manager's requirements are about weekly scheduling and VIP-labeled content, so switching to CSV would not satisfy either requirement and may not match the expected summary presentation.

Trap 3: Enable the 'include raw evidence' checkbox on the report template

Including raw evidence would attach files and artifacts to the report, which is unrelated to the manager's need for a filtered weekly summary. It would bloat the PDF and potentially expose sensitive evidence, but it would not affect scheduling or incident filtering for the VIP label.

A
Apply an incident filter that selects only incidents carrying the 'VIP' label within the previous week's date range
The report content must be scoped to VIP-labeled incidents from the prior week, so an incident filter combining the VIP label and a rolling date range is required. Without this filter, the report would include unrelated incidents and fail the manager's content requirement.
B
Configure a War Room entry to trigger the report on demand from a playbook task
Why it fails: Triggering a report from a playbook task is an on-demand mechanism, not a scheduled recurring delivery. The manager requires a predictable Monday 07:00 arrival, which only a scheduled report definition can provide; a playbook-triggered report would depend on incident activity and would not guarantee the cadence.
C
Set the report schedule cadence to weekly and specify Monday at 07:00 as the run time
A scheduled report must have its cadence set to weekly with the day and time specified, otherwise it will not fire at the required Monday 07:00 window. This directly satisfies the manager's delivery requirement and ensures the report runs on the intended schedule for the VIP incident summary.
D
Set the report output format to CSV instead of PDF for easier metric parsing
Why it fails: Changing the output format to CSV affects only how the report is rendered, not when it runs or which incidents it contains. The manager's requirements are about weekly scheduling and VIP-labeled content, so switching to CSV would not satisfy either requirement and may not match the expected summary presentation.
E
Enable the 'include raw evidence' checkbox on the report template
Why it fails: Including raw evidence would attach files and artifacts to the report, which is unrelated to the manager's need for a filtered weekly summary. It would bloat the PDF and potentially expose sensitive evidence, but it would not affect scheduling or incident filtering for the VIP label.

Read the full Ansible explanation →

Question 7hardmultiple choice

An engineer is designing a playbook that must iterate over a list of IP addresses stored in the incident context under the key 'IPs'. For each IP, the playbook should run a reputation check and then add a note to the incident. Which playbook task type should be used to loop over the list and execute the sub-tasks for each item?

Trap 1: Conditional task

A Conditional task evaluates a condition and branches, but it does not iterate over a list. It can only direct flow once per evaluation. To handle multiple IPs, you would need to manually create multiple branches, which is impractical and not dynamic. It cannot loop through a list automatically.

Trap 2: Manual task to select each IP and trigger the sub-tasks

A Manual task requires human interaction for each IP, which is inefficient and defeats automation. It does not automatically iterate over the list. The requirement is to automatically process each IP in a loop, so a Manual task is not suitable.

Trap 3: Standard task with a script that loops internally

While a script could loop internally, it would not allow you to use playbook sub-tasks like reputation checks and note-adding for each iteration. Those actions would need to be coded in the script, duplicating functionality. The playbook's visual workflow and error handling would also be bypassed. The For-each task is the intended construct for this.

A
Conditional task
Why it fails: A Conditional task evaluates a condition and branches, but it does not iterate over a list. It can only direct flow once per evaluation. To handle multiple IPs, you would need to manually create multiple branches, which is impractical and not dynamic. It cannot loop through a list automatically.
B
For-each task
A For-each task iterates over a list and executes its sub-tasks for each item. You can specify the list from context (e.g., ${IPs}) and the loop will run the reputation check and note-adding tasks for each IP. This is the designed way to perform repetitive actions on a collection of items within a playbook.
C
Manual task to select each IP and trigger the sub-tasks
Why it fails: A Manual task requires human interaction for each IP, which is inefficient and defeats automation. It does not automatically iterate over the list. The requirement is to automatically process each IP in a loop, so a Manual task is not suitable.
D
Standard task with a script that loops internally
Why it fails: While a script could loop internally, it would not allow you to use playbook sub-tasks like reputation checks and note-adding for each iteration. Those actions would need to be coded in the script, duplicating functionality. The playbook's visual workflow and error handling would also be bypassed. The For-each task is the intended construct for this.

Question 8hardmultiple choice

An XSOAR engineer is troubleshooting an engine that shows as disconnected in the server UI. The engine host can ping the server, and the server can ping the engine host. The engineer verifies that the engine service is running. Which action should be taken next to diagnose the issue?

Trap 1: Verify that the engine's hostname resolves correctly from the…

The scenario states that the server can ping the engine host, which implies that name resolution is working. Therefore, checking hostname resolution again is redundant and unlikely to reveal the cause. The issue is more likely related to the engine's connection configuration or authentication.

Trap 2: Restart the XSOAR server to clear any temporary glitches.

Restarting the server is a disruptive action that should be avoided until more targeted diagnostics are performed. It may temporarily resolve issues but does not provide insight into the root cause. In a production environment, unnecessary restarts can cause downtime and should not be the first troubleshooting step.

Trap 3: Increase the engine's memory allocation to improve performance.

Memory allocation affects performance but not basic connectivity. A disconnected engine is typically due to network, authentication, or configuration problems, not insufficient memory. Adjusting memory would not address the underlying issue and could mask other symptoms.

A
Verify that the engine's hostname resolves correctly from the server.
Why it fails: The scenario states that the server can ping the engine host, which implies that name resolution is working. Therefore, checking hostname resolution again is redundant and unlikely to reveal the cause. The issue is more likely related to the engine's connection configuration or authentication.
B
Check the engine's logs for connection errors or authentication failures.
The engine logs contain detailed information about connection attempts, including authentication errors, TLS handshake failures, or network timeouts. Since basic connectivity is confirmed, the next logical step is to inspect the engine's logs to identify why the connection is not being established. This action directly targets the most likely causes of a disconnected state.
C
Restart the XSOAR server to clear any temporary glitches.
Why it fails: Restarting the server is a disruptive action that should be avoided until more targeted diagnostics are performed. It may temporarily resolve issues but does not provide insight into the root cause. In a production environment, unnecessary restarts can cause downtime and should not be the first troubleshooting step.
D
Increase the engine's memory allocation to improve performance.
Why it fails: Memory allocation affects performance but not basic connectivity. A disconnected engine is typically due to network, authentication, or configuration problems, not insufficient memory. Adjusting memory would not address the underlying issue and could mask other symptoms.

Read the full Ansible explanation →

Question 9mediummultiple choice

An administrator is troubleshooting a Cortex XSOAR engine that is not processing playbook tasks. The engine appears in the server's engine list as 'Disconnected'. The administrator has verified that the engine service is running and the network allows outbound HTTPS to the server. Which action should the administrator take next to diagnose the issue?

Trap 1: Verify that the engine has inbound access from the server on port…

Engines do not require inbound access from the server; communication is engine-initiated. Checking inbound access is irrelevant and would not explain the disconnection. The administrator already confirmed outbound HTTPS from the engine to the server, which is the correct direction. This option misinterprets the communication model.

Trap 2: Restart the Cortex XSOAR server to re-establish the connection.

Restarting the server is disruptive and unlikely to resolve a single engine's connectivity issue. The problem is isolated to the engine, so server-side actions are not the first step. This approach could cause unnecessary downtime and does not address the root cause. Diagnostics should focus on the engine itself.

Trap 3: Increase the engine's allocated memory and CPU resources.

Resource constraints typically cause performance degradation, not a complete disconnection. While insufficient resources could lead to timeouts, the engine would likely show as connected but slow. The 'Disconnected' status suggests a communication or authentication failure, not a resource issue. Adjusting resources is not the immediate diagnostic step.

A
Verify that the engine has inbound access from the server on port 443.
Why it fails: Engines do not require inbound access from the server; communication is engine-initiated. Checking inbound access is irrelevant and would not explain the disconnection. The administrator already confirmed outbound HTTPS from the engine to the server, which is the correct direction. This option misinterprets the communication model.
B
Restart the Cortex XSOAR server to re-establish the connection.
Why it fails: Restarting the server is disruptive and unlikely to resolve a single engine's connectivity issue. The problem is isolated to the engine, so server-side actions are not the first step. This approach could cause unnecessary downtime and does not address the root cause. Diagnostics should focus on the engine itself.
C
Check the engine's log files for errors related to authentication or certificate validation.
When an engine shows as disconnected despite network connectivity, common causes include authentication failures, expired certificates, or misconfigured engine keys. Reviewing the engine logs (e.g., /var/log/demisto/engine.log) can reveal specific errors such as 'invalid token' or 'certificate verify failed'. This is the logical next step to pinpoint the root cause.
D
Increase the engine's allocated memory and CPU resources.
Why it fails: Resource constraints typically cause performance degradation, not a complete disconnection. While insufficient resources could lead to timeouts, the engine would likely show as connected but slow. The 'Disconnected' status suggests a communication or authentication failure, not a resource issue. Adjusting resources is not the immediate diagnostic step.