How many Troubleshooting Scenario Questions questions are on this page?

This page has 10 Troubleshooting Scenario Questions scenario questions for the XSOAR-Engineer exam, each with detailed explanations and wrong-answer analysis.

How should I approach XSOAR-Engineer scenario questions?

Read the full scenario before looking at the answer options. Identify the constraint or requirement in the scenario, then eliminate options that are generally true but wrong for this specific case. Scenario questions reward careful reading over pattern matching.

← Back to Certified XSOAR Engineer (XSOAR-Engineer) questions

Scenario-based practice

Troubleshooting Scenario Questions

Practise Certified XSOAR Engineer (XSOAR-Engineer) practice questions — original exam-style scenarios covering every exam domain, with detailed explanations, wrong-answer analysis, and common exam traps.

Start full practice test Read exam guide

scenario questions

XSOAR-Engineer

exam code

Palo Alto Networks

vendor

Scenario guide

How to approach troubleshooting scenario questions

These questions describe a network symptom and ask you to identify the root cause or the correct fix. They appear across all certification exams and reward systematic thinking over memorisation. The best candidates follow a consistent troubleshooting framework even under time pressure.

Quick answer

Troubleshooting Scenario Questions questions test whether you can apply the concept in context, not just recognise a definition.

How the topic appears in realistic exam-style scenarios.

Which detail in the question changes the correct answer.

How to eliminate plausible but wrong options.

How to connect the question back to the wider exam objective.

Practice scenarios

Question 1hardmulti select

Full question →

An administrator is troubleshooting an integration that fails to execute inside a Docker container on a Cortex XSOAR engine. Which THREE diagnostic steps or tools can be used to isolate the container execution failure? (Choose three)

A
Review the integration instance debug logs in Settings > Integrations > Instances for detailed Python stderr output.
Reviewing instance debug logs captures Python stderr from the integration's execution inside the Docker container, exposing import errors, missing dependencies or tracebacks that the engine's own logs omit. This directly satisfies the stem's need to isolate container execution failure, since stderr is streamed from the container process to the instance log.
B
Use engine troubleshooting tools or test container execution locally using the Docker CLI on the engine host.
Running the integration's image directly via the Docker CLI on the engine host bypasses XSOAR's orchestration layer, exposing whether the failure lies in the image itself, missing dependencies, or runtime permissions. Engine troubleshooting tools surface container-level logs and status, isolating execution faults from playbook or integration configuration issues.
C
Reinstall the core Linux operating system kernel on the server.
Why it fails: Reinstalling the Linux kernel is a disruptive host-level rebuild that does not expose Docker execution errors and risks breaking the engine. It is tempting because kernel or OS faults can cause container failures, so it would be the right action when logs show host-level instability, not when isolating a single integration's container error.
D
Verify Docker daemon status and connectivity on the host running the engine.
Verifying the Docker daemon status and connectivity confirms the engine host can actually reach the runtime that launches integration containers. If the daemon is stopped, unreachable, or the socket is misconfigured, container execution fails before any integration code runs, isolating the fault to the host layer rather than the integration itself.
E
Modify the PostgreSQL database schema to enable container debugging tables.
Why it fails: PostgreSQL stores XSOAR configuration and incident data; it holds no container runtime state, so schema changes cannot reveal why a Docker execution fails. It is tempting because database inspection is a legitimate diagnostic for integration data issues, and would be correct when investigating corrupted or missing records rather than container startup faults.

Full breakdown with real-world context →

Question 2hardmulti select

Full question →

An administrator is troubleshooting high CPU usage and slow incident search performance on a Cortex XSOAR server. Which TWO actions or tools can be used to diagnose and resolve database-related bottlenecks? (Choose two)

A
Increase the Docker container memory limit for the PostgreSQL database container.
Why it fails: Raising the PostgreSQL container's memory limit addresses resource starvation, not the query, index or maintenance issue causing high CPU and slow searches. It is tempting because memory tuning is a real database remedy, but it would be correct only where the bottleneck is confirmed memory pressure.
B
Delete all historical audit logs directly from the file system to free up database index space.
Why it fails: Deleting audit logs from the file system removes evidence and bypasses the database's own retention and partition management, so it neither diagnoses nor resolves index contention. It is tempting as a quick space-freeing measure, but audit data is purged through supported retention settings, not manual file deletion.
C
Run 'demisto-sdk analyze-db' from the command line interface.
Why it fails: 'demisto-sdk analyze-db' is not a Cortex XSOAR database diagnostic; the SDK analyses content artefacts such as playbooks and integrations. It is tempting because the SDK is a genuine administration tool, but it inspects repository content, not the PostgreSQL instance's query performance or indexes.
D
Query the PostgreSQL 'pg_stat_activity' view to identify long-running or locked queries.
pg_stat_activity exposes active sessions, query states, wait events and lock waits, revealing long-running or blocked queries causing CPU and search slowness. It targets the PostgreSQL layer where the bottleneck resides, unlike application logs or network tools.
E
Review database execution plans using EXPLAIN and ensure proper indexing on custom incident fields used in search filters.
EXPLAIN reveals the query plan, exposing full table scans or missing indexes on custom incident fields used in search filters. Adding indexes on those fields lets the database satisfy filters without scanning every row, directly relieving the CPU load and slow search performance described in the stem.

Full breakdown with real-world context →

Question 3mediummultiple choice

Read the full Ansible explanation →

An engineer is troubleshooting a playbook where a task is skipped unexpectedly. Upon reviewing the task configuration, they notice a condition set in the 'Conditions' tab. What evaluates this condition to determine if the task runs or is skipped?

A
The integration instance health status
Why it fails: Integration instance health determines whether a task's command can execute, not whether its Conditions expression evaluates true; an unhealthy instance causes failure, not silent skipping. It is tempting because connectivity problems visibly disrupt playbooks, and would be correct when a task errors out rather than being skipped.
B
The evaluation of the task's conditional expression against the current Incident Context
Cortex XSOAR evaluates the task's conditional expression against the current incident context at runtime; if the expression resolves false, the task is skipped. This context-driven evaluation, not playbook order or manual input, determines whether the task executes.
C
The system clock and task timeout thresholds
Why it fails: Clock and timeout thresholds govern task scheduling and expiry, not the boolean evaluation of a Conditions tab expression. It is tempting because timing settings do affect whether tasks execute, and would be correct for diagnosing tasks that never start because a timeout elapsed before their condition was checked.
D
The user permissions of the analyst who opened the incident
Why it fails: Analyst permissions control who may view or edit incidents, not the runtime evaluation of a task's Conditions expression. It is tempting because access restrictions can hide tasks from view, and would be correct for explaining why an analyst cannot see or run a task rather than why it was skipped.

Full breakdown with real-world context →

Question 4hardmulti select

Read the full Ansible explanation →

An XSOAR Engineer is troubleshooting a playbook where a custom automation script fails to receive expected arguments. Which THREE diagnostic steps should the engineer perform? (Choose three)

A
Reinstall the underlying operating system and format all storage volumes.
Why it fails: Reinstalling the OS and formatting volumes destroys the XSOAR instance and its data without inspecting script arguments, task inputs, or context. It is tempting because OS reinstallation genuinely resolves corrupted platform-level failures, and would be correct if the entire server were unstable rather than a single script's arguments.
B
Replace the server's network interface card to fix context serialization errors.
Why it fails: Context serialisation is handled by the XSOAR application layer, not the network interface card, so swapping hardware cannot restore missing script arguments. It is tempting because NIC replacement genuinely fixes physical link or packet-loss faults, and would be correct if the playbook failed due to network connectivity rather than argument passing.
C
Check server log files (e.g., demisto.log) for Python tracebacks and error messages.
Server logs such as demisto.log capture Python tracebacks and runtime errors from the automation script, revealing argument-parsing failures or exceptions. Reviewing them exposes the actual execution error, satisfying the need to diagnose why expected arguments never reached the script.
D
Inspect the task's 'Inputs' tab in the playbook editor to verify argument mapping and syntax.
The task's Inputs tab shows exactly which values and syntax are mapped into the script's arguments. Verifying it confirms whether arguments are correctly named and passed, directly diagnosing the mismatch causing the script to receive nothing.
E
Review the War Room or task execution details to see the exact arguments passed at runtime.
Inspecting the War Room entry for the failing task reveals the literal argument string XSOAR passed to the script, exposing mismatches between playbook inputs and the script's declared parameters. This directly satisfies the need to verify runtime arguments rather than assumed configuration.

Full breakdown with real-world context →

Question 5hardmulti select

Full question →

When troubleshooting a feed integration that fails to parse incoming data, which TWO diagnostic steps should an administrator take? Choose 2 answers.

A
Review the integration instance execution logs for raw response errors.
Execution logs capture the raw HTTP response, status codes and parser exceptions for each fetch, revealing malformed fields, unexpected schemas or authentication failures. This pinpoints whether the feed's incoming data or the integration's parsing logic causes the failure.
B
Upgrade the hypervisor running the virtual machine.
Why it fails: Hypervisor upgrades address virtualisation-layer faults, not feed parsing logic; parsing failures stem from mapper, indicator-type or fetch configuration errors. Upgrading is tempting when the VM itself misbehaves, and would be correct for host-level instability, driver bugs or CPU-feature incompatibilities affecting the appliance.
C
Reinstall the entire Cortex XSOAR Linux operating system.
Why it fails: Reinstalling the operating system destroys the appliance and its configuration without addressing the feed's parsing logic, which depends on mapper and indicator-type settings. Reinstallation is tempting as a last-resort fix for corrupted platforms, and would be correct for a damaged OS rather than a misconfigured integration.
D
Change the server's primary network gateway IP address.
Why it fails: Gateway changes alter packet forwarding, not how the integration parses fetched indicators, so parsing errors persist. It is tempting because connectivity faults can block feed retrieval, and would be correct if the feed failed to reach its source rather than failing to parse data already received.
E
Test the feed query response in a test script or check raw JSON payloads.
Inspecting raw JSON payloads or running the feed query in a test script reveals the actual field names and structure returned by the source, exposing mismatches with the integration's parser mappings. This directly satisfies the troubleshooting constraint: confirming whether parsing fails because the incoming data's schema differs from what the integration expects.

Full breakdown with real-world context →

Question 6hardmultiple choice

Full question →

An administrator is troubleshooting an issue where custom incident fields created in XSOAR are not appearing when analysts attempt to edit them in the Incident Info panel. What is the most likely root cause?

A
The user browser cache must be cleared via Settings > Server Configuration
Why it fails: Browser cache affects rendering, not field availability; clearing it cannot make missing custom fields appear. Fields absent from the Incident Info panel are typically not added to the relevant incident type layout, or lack the correct field type and permissions. Layout configuration is the actual mechanism controlling panel visibility.
B
Custom fields are restricted to administrator accounts only by default
Why it fails: Field-level security in XSOAR is governed by role permissions, not an automatic administrator-only restriction, so analysts lacking the relevant role permission simply cannot see or edit the field. It is tempting because role-based access control genuinely does hide fields from certain users, but that requires explicit configuration rather than being a default.
C
The custom fields were created but not added to the layout assigned to that incident type
Incident fields render in the Incident Info panel only when included in the incident type's layout. Creating a field registers it in the schema but does not place it on any layout, so analysts see nothing until it is added to the assigned layout.
D
Custom fields require a server restart before appearing in database schemas
Why it fails: XSOAR applies custom field definitions to the incident schema dynamically on save, so no server restart is needed for them to appear. It is tempting because some self-hosted platforms do cache schema changes until a service reload, but XSOAR's field mapping updates immediately once the field is added to the incident type layout.

Full breakdown with real-world context →

Question 7hardmulti select

Read the full Ansible explanation →

When troubleshooting an issue where an incident fails to trigger a playbook upon creation, which THREE areas should an administrator investigate?

A
Incident Type playbook association settings
Playbooks trigger through the incident type's configured association, so a missing or incorrect playbook link on that type prevents automatic execution at creation. Confirming the association ensures the incident type actually maps to the intended playbook.
B
The BIOS version of the underlying hypervisor host
Why it fails: Hypervisor BIOS firmware has no bearing on playbook triggering, which depends on incident type mapping, enabled playbook status and trigger conditions. It is tempting because firmware faults do cause host-level instability, so BIOS updates are a legitimate step when diagnosing hypervisor crashes or hardware errors.
C
Browser cookie expiration settings in client workstations
Why it fails: Cookie expiry affects only browser session persistence, not server-side incident creation or playbook triggering, which run within the Cortex XSOAR engine. It is tempting because expired cookies do cause authentication failures and odd UI behaviour, so clearing them is a valid fix for login or console display problems.
D
Incoming mapper rules ensuring correct incident type classification
Incoming mapper rules determine the incident type assigned on creation; if classification is wrong, the incident type's playbook association never matches, so no playbook triggers. Verifying mapper output confirms the incident reaches the expected type.
E
Global server playbook automation toggle settings
The global server automation toggle governs whether playbooks run automatically at all; if disabled, incidents are created without triggering any playbook regardless of type associations or mapper rules. Checking this setting rules out a platform-wide suppression.

Full breakdown with real-world context →

Question 8hardmulti select

Full question →

An XSOAR administrator is troubleshooting why a custom dashboard widget is failing to load and returning an error. Which TWO potential causes should the administrator investigate?

A
The user role viewing the dashboard lacks permissions to access the underlying data or indices.
Dashboard widgets query underlying indices through the viewer's role, so missing permissions on those data sources cause load failures. Verifying the role's index and incident access directly addresses the authorisation constraint in the stem, rather than widget code or engine health.
B
The SMTP server port is blocked by a local firewall.
Why it fails: Widget rendering is client-side and queries the XSOAR API and data stores; outbound SMTP is used only for sending mail notifications, so blocking that port cannot break a dashboard widget. It is tempting because firewall port blocking is a common integration failure, and would be correct if email alerts stopped arriving.
C
The Linux kernel swap space on the XSOAR server is configured below 512MB.
Why it fails: Swap space affects memory pressure and general server performance, not the rendering of an individual dashboard widget, which fails on query, permission, or script errors. It is tempting because undersized swap is a documented XSOAR sizing concern, and would be correct if the whole server were unstable.
D
The underlying incident or indicator query contains syntax errors.
Widgets execute their saved incident or indicator query at render time, so malformed syntax in that query returns an error instead of data. Checking the query syntax directly addresses the widget-load failure described in the stem, independently of role permissions.
E
The SSL certificate of the active firewall integration has expired.
Why it fails: Firewall integration certificates affect that integration's commands, not dashboard widget rendering; widget errors stem from widget queries, permissions or saved-search data. Certificate expiry is tempting because expired TLS certificates do break integrations, but that scenario concerns integration execution failures, not dashboard loading.

Full breakdown with real-world context →

Question 9hardmultiple choice

Full question →

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?

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.

Full breakdown with real-world context →

Question 10mediummultiple choice

Read the full Ansible explanation →

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?

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.

Full breakdown with real-world context →

These XSOAR-Engineer practice questions are part of Courseiva's free Palo Alto Networks certification practice question bank. Courseiva provides original exam-style XSOAR-Engineer questions with detailed explanations, topic-based practice, mock exams, readiness tracking, and study analytics.

Troubleshooting Scenario Questions

How to approach troubleshooting scenario questions

Quick answer

Related XSOAR-Engineer topic practice pages

Incident Interactions And Reporting practice questions

Threat Intelligence Management practice questions

Use Case Planning And Development practice questions

Playbook Development practice questions

Planning Installation And Maintenance practice questions

XSOAR-Engineer fundamentals practice questions

XSOAR-Engineer scenario practice questions

XSOAR-Engineer troubleshooting practice questions

Practice scenarios

An administrator is troubleshooting an integration that fails to execute inside a Docker container on a Cortex XSOAR engine. Which THREE diagnostic steps or tools can be used to isolate the container execution failure? (Choose three)

An administrator is troubleshooting high CPU usage and slow incident search performance on a Cortex XSOAR server. Which TWO actions or tools can be used to diagnose and resolve database-related bottlenecks? (Choose two)

An engineer is troubleshooting a playbook where a task is skipped unexpectedly. Upon reviewing the task configuration, they notice a condition set in the 'Conditions' tab. What evaluates this condition to determine if the task runs or is skipped?

An XSOAR Engineer is troubleshooting a playbook where a custom automation script fails to receive expected arguments. Which THREE diagnostic steps should the engineer perform? (Choose three)

When troubleshooting a feed integration that fails to parse incoming data, which TWO diagnostic steps should an administrator take? Choose 2 answers.

An administrator is troubleshooting an issue where custom incident fields created in XSOAR are not appearing when analysts attempt to edit them in the Incident Info panel. What is the most likely root cause?

When troubleshooting an issue where an incident fails to trigger a playbook upon creation, which THREE areas should an administrator investigate?

An XSOAR administrator is troubleshooting why a custom dashboard widget is failing to load and returning an error. Which TWO potential causes should the administrator investigate?

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?