Troubleshooting practice questions

An administrator is planning to upgrade a Cortex XSOAR deployment from version 6.5 to 6.8. The environment includes a production server and two engines. The administrator wants to minimize downtime and ensure a rollback path. Which upgrade approach should the administrator take?

Trap 1: Skip the backup because Cortex XSOAR upgrades are always…

Assuming upgrades are always reversible is dangerous; some upgrades may include irreversible database schema changes. Skipping a backup removes the ability to roll back. Upgrading engines first is also incorrect because they depend on the server version. A backup is mandatory before any upgrade, and the server should be upgraded first.

Trap 2: Upgrade all engines simultaneously, then upgrade the server, to…

Upgrading engines before the server can cause compatibility issues because engines are designed to work with the server version. The server should be upgraded first. Simultaneously upgrading all engines also increases risk and downtime; if an issue occurs, all engines are affected at once, leaving no fallback. This approach is not recommended.

Trap 3: Upgrade the server and engines simultaneously during a maintenance…

Simultaneous upgrades increase the risk of a failed upgrade with no working components. It also makes troubleshooting difficult because multiple variables change at once. The server should be upgraded first to ensure compatibility, and engines can be upgraded afterward with minimal downtime. This method does not provide a controlled rollback path.

A
Skip the backup because Cortex XSOAR upgrades are always reversible, and upgrade engines first to test compatibility.
Why it fails: Assuming upgrades are always reversible is dangerous; some upgrades may include irreversible database schema changes. Skipping a backup removes the ability to roll back. Upgrading engines first is also incorrect because they depend on the server version. A backup is mandatory before any upgrade, and the server should be upgraded first.
B
Upgrade all engines simultaneously, then upgrade the server, to ensure version compatibility across the board.
Why it fails: Upgrading engines before the server can cause compatibility issues because engines are designed to work with the server version. The server should be upgraded first. Simultaneously upgrading all engines also increases risk and downtime; if an issue occurs, all engines are affected at once, leaving no fallback. This approach is not recommended.
C
Upgrade the server and engines simultaneously during a maintenance window to reduce overall downtime.
Why it fails: Simultaneous upgrades increase the risk of a failed upgrade with no working components. It also makes troubleshooting difficult because multiple variables change at once. The server should be upgraded first to ensure compatibility, and engines can be upgraded afterward with minimal downtime. This method does not provide a controlled rollback path.
D
Perform a full backup, upgrade the server first, then upgrade each engine one at a time, verifying functionality before proceeding.
The recommended upgrade order is to back up first, then upgrade the server, and finally upgrade engines sequentially. This minimizes downtime because the server can be upgraded while engines continue to run (though they may be temporarily disconnected). Upgrading engines one at a time allows verification and rollback if issues arise. This approach aligns with Cortex XSOAR best practices.

Question 2hardmulti select

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)

Trap 1: Reinstall the core Linux operating system kernel on the server.

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.

Trap 2: Modify the PostgreSQL database schema to enable container debugging…

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.

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.

Question 3hardmulti select

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)

Trap 1: Increase the Docker container memory limit for the PostgreSQL…

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.

Trap 2: Delete all historical audit logs directly from the file system to…

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.

Trap 3: Run 'demisto-sdk analyze-db' from the command line interface.

'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.

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.

Question 4mediummultiple choice

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?

Trap 1: The integration instance health status

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.

Trap 2: The system clock and task timeout thresholds

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.

Trap 3: The user permissions of the analyst who opened the incident

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.

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.

Question 5hardmulti select

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)

Trap 1: Reinstall the underlying operating system and format all storage…

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.

Trap 2: Replace the server's network interface card to fix context…

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.

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.

Question 6mediummulti 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 7hardmulti select

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

Trap 1: Upgrade the hypervisor running the virtual machine.

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.

Trap 2: Reinstall the entire Cortex XSOAR Linux operating system.

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.

Trap 3: Change the server's primary network gateway IP address.

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.

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.

Question 8hardmultiple choice

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?

Trap 1: The user browser cache must be cleared via Settings > Server…

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.

Trap 2: Custom fields are restricted to administrator accounts only by…

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.

Trap 3: Custom fields require a server restart before appearing in database…

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.

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.

Question 9mediummulti select

Which THREE configuration settings can be customized in the Cortex XSOAR server configuration file (or Server Configuration UI) to tune system behavior? (Choose three)

Trap 1: The physical RAM allocation size of the host server motherboard

Physical RAM allocation belongs to the host server's hardware or hypervisor settings, outside Cortex XSOAR's configuration file and UI. It is tempting because memory tuning influences performance, and would be correct when provisioning or resizing the host server rather than tuning XSOAR behaviour.

Trap 2: The CPU clock speed of the underlying hypervisor

Hypervisor CPU clock speed is set by the virtualisation platform, not by Cortex XSOAR's server configuration file or UI. It is tempting because CPU resources affect performance tuning, and would be correct when sizing or reconfiguring the underlying hypervisor host itself.

A
HTTP/HTTPS proxy server settings for outbound integration traffic
Outbound integration traffic often traverses a corporate proxy, so the server configuration exposes HTTP and HTTPS proxy host, port, and authentication values. Setting these lets integrations reach external APIs through the approved egress path, tuning system behaviour without editing individual integration code.
B
The physical RAM allocation size of the host server motherboard
Why it fails: Physical RAM allocation belongs to the host server's hardware or hypervisor settings, outside Cortex XSOAR's configuration file and UI. It is tempting because memory tuning influences performance, and would be correct when provisioning or resizing the host server rather than tuning XSOAR behaviour.
C
User session timeout duration for inactivity
The server configuration exposes a session timeout value controlling how long an idle user stays authenticated. Shortening it limits exposure on unattended consoles, while lengthening it reduces re-authentication friction, tuning system behaviour to match organisational security policy.
D
Logging verbosity levels for troubleshooting specific modules
Logging verbosity levels are tunable in the Cortex XSOAR server configuration file and Server Configuration UI, letting engineers raise or lower detail per module. This satisfies the troubleshooting requirement by isolating noisy or failing components without redeploying the server.
E
The CPU clock speed of the underlying hypervisor
Why it fails: Hypervisor CPU clock speed is set by the virtualisation platform, not by Cortex XSOAR's server configuration file or UI. It is tempting because CPU resources affect performance tuning, and would be correct when sizing or reconfiguring the underlying hypervisor host itself.

Question 10hardmulti select

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

Trap 1: The BIOS version of the underlying hypervisor host

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.

Trap 2: Browser cookie expiration settings in client workstations

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.

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.

Question 11hardmulti select

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?

Trap 1: The SMTP server port is blocked by a local firewall.

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.

Trap 2: The Linux kernel swap space on the XSOAR server is configured below…

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.

Trap 3: The SSL certificate of the active firewall integration has expired.

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.

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.

Question 12hardmultiple 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.

Question 13mediummultiple 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.

Question 14easymultiple choice

An administrator needs to review the audit trail of user actions and playbook executions in Cortex XSOAR for a compliance audit. Where can the administrator find this information within the platform?

Trap 1: In the /var/log/demisto/server.log file on the Cortex XSOAR server,…

The server.log file contains application runtime logs such as errors and service messages, not a structured audit trail of user actions and playbook executions. While it can help troubleshoot technical issues, it is not the compliance-oriented audit record. Relying on server.log for an audit would miss user attribution and structured event data available in the built-in Audit Log.

Trap 2: In the Cortex XSOAR Marketplace under the Content Packs tab, which…

The Marketplace is where content packs are discovered, installed, and updated. It does not record user actions, playbook runs, or configuration changes. While pack installation events may appear in audit records, the Marketplace interface itself is not an audit log. Directing an auditor to the Marketplace would not provide the required compliance evidence.

Trap 3: In the incident War Room of each incident, where all user and…

The War Room shows the timeline of a specific incident, including entries, commands, and notes. It is incident-scoped and not a global audit mechanism. Entries can be filtered or hidden, and it does not provide a consolidated, tamper-evident record of platform-wide user actions. For a compliance audit, the War Room alone is insufficient and not the intended audit resource.

A
In the /var/log/demisto/server.log file on the Cortex XSOAR server, which contains the full audit trail.
Why it fails: The server.log file contains application runtime logs such as errors and service messages, not a structured audit trail of user actions and playbook executions. While it can help troubleshoot technical issues, it is not the compliance-oriented audit record. Relying on server.log for an audit would miss user attribution and structured event data available in the built-in Audit Log.
B
In the Settings > Audit Log page, which records user actions, playbook runs, and configuration changes with timestamps.
Cortex XSOAR provides an Audit Log under Settings that captures user activity, playbook executions, and configuration changes with timestamps and user attribution. This is the built-in compliance and troubleshooting resource. It is distinct from incident war rooms and system logs, and it is the correct place to review an audit trail for compliance purposes without accessing the underlying operating system.
C
In the Cortex XSOAR Marketplace under the Content Packs tab, which logs all administrative actions.
Why it fails: The Marketplace is where content packs are discovered, installed, and updated. It does not record user actions, playbook runs, or configuration changes. While pack installation events may appear in audit records, the Marketplace interface itself is not an audit log. Directing an auditor to the Marketplace would not provide the required compliance evidence.
D
In the incident War Room of each incident, where all user and playbook actions are permanently archived.
Why it fails: The War Room shows the timeline of a specific incident, including entries, commands, and notes. It is incident-scoped and not a global audit mechanism. Entries can be filtered or hidden, and it does not provide a consolidated, tamper-evident record of platform-wide user actions. For a compliance audit, the War Room alone is insufficient and not the intended audit resource.