XSOAR-Engineer Practice Test 20 — 15 Questions

Question 1

A security engineer is integrating a new TAXII 2.1 feed into Cortex XSOAR. The feed requires authentication using a client certificate and a private key. After configuring the integration instance with the correct certificate and key, the engineer notices that no indicators are being fetched, and the integration logs show 'SSL certificate verification failed'. The TAXII server uses a self-signed certificate. What should the engineer do to resolve this issue while maintaining security best practices?

Choose an answer to begin — your selection is scored in the full session.

Accepted Answer

Import the TAXII server's self-signed certificate into the Cortex XSOAR trusted certificates store and reference it in the integration.. To securely connect to a TAXII server with a self-signed certificate, the certificate must be imported into Cortex XSOAR's trusted certificates store. This allows the integration to validate the server's identity without disabling SSL verification. The integration instance can then reference the imported certificate. This approach maintains encryption and authentication integrity while resolving the SSL error.

Answer

Generate a new client certificate signed by the TAXII server's CA and use it in the integration configuration.

Answer

Modify the integration's Python code to use 'verify=False' in the requests library calls.

Answer

Disable SSL verification in the integration instance settings by checking 'Trust any certificate'.

Question 2

You need to ensure that a specific playbook task only executes if the incident severity is 'High' or 'Critical'. Where do you apply this filtering logic?

Accepted Answer

In the task's 'Conditions' tab by defining expression rules based on incident severity. The task-level 'Conditions' tab in the Cortex XSOAR playbook editor is the built-in mechanism for conditional task execution. It lets you define expression rules (e.g., using DBot or built-in incident fields like severity) that are evaluated at runtime before the task runs. Setting a condition such as 'severity equals High or Critical' ensures the task only executes for matching incidents without touching the underlying JSON or server config.

Answer

In the playbook JSON file by manually modifying the 'filters' array

Answer

In the server configuration under Incident Types

Answer

By writing a custom pre-processing script for every integration

Question 3

Which TWO actions can an analyst perform within the Incident War Room?

Accepted Answer

Add analyst notes and comments. Option B is correct because the Incident War Room in Cortex XSOAR is a collaborative workspace where analysts document their investigation by adding notes and comments to the incident, keeping the whole team informed. Option E is correct because the War Room CLI allows analysts to run integration commands directly (for example, using the command line to query an integration or execute a configured command) to gather data and take response actions during an investigation. Options A, C, and D are not War Room functions: provisioning cloud VMs, configuring physical firewall port speeds, and updating XSOAR server SSL certificates are infrastructure or administrative tasks performed outside the incident War Room, not analyst actions within it.

Answer

Provision new cloud virtual machines

Answer

Configure physical firewall port speeds

Answer

Update XSOAR server SSL certificates

Question 4

Which THREE types of data can be ingested as threat intelligence indicators in Cortex XSOAR out-of-the-box? Choose 3 answers.

Accepted Answer

File hashes (MD5, SHA1, SHA256). Option A (File hashes — MD5, SHA1, SHA256) is correct because Cortex XSOAR's out-of-the-box indicator types include File, which stores MD5, SHA1, and SHA256 hash values used to match malicious files against threat intel feeds. Option C (IP addresses — IPv4 and IPv6) is correct because the built-in IP indicator type natively supports both IPv4 and IPv6 addresses for reputation lookups and enrichment via integrations. Option E (Domain names and URLs) is correct because Cortex XSOAR ships with separate Domain and URL indicator types that can be ingested directly from threat intel feeds and used in playbook logic. Option B (Local network switch port numbers) is not a supported indicator type — port numbers are network configuration data, not threat indicators, and have no built-in indicator schema. Option D (Employee badge access timestamps) is also not an indicator type; it is physical security/HR telemetry that would require custom content and is unrelated to threat intelligence ingestion.

Answer

Local network switch port numbers

Answer

Employee badge access timestamps

Question 5

An administrator is planning to install a Cortex XSOAR server on a Linux host. The host has 32 GB of RAM and 8 CPU cores. According to best practices, which additional resource should be allocated to ensure optimal performance?

Accepted Answer

At least 500 GB of SSD storage for the database and Docker images.. For a Cortex XSOAR server with 32 GB of RAM and 8 CPU cores, best practices recommend allocating at least 500 GB of SSD storage. This space is needed for the database, Docker images, and logs. Insufficient storage can lead to performance degradation and failures, so proper disk allocation is essential for optimal operation.

Answer

A dedicated GPU for accelerated playbook execution.

Answer

A second network interface for out-of-band management.

Answer

At least 64 GB of RAM to support the Java heap size.

Question 6

A Cortex XSOAR administrator is building a custom dashboard widget that must show the number of open incidents grouped by severity for the current week, updating automatically as incidents change. Which widget configuration should the administrator use?

Accepted Answer

A 'Pie chart' widget with a query filtering open incidents from the current week and grouping by severity.. Dashboard widgets that query incident data can group and count dynamically. A Pie chart with a query scoped to open incidents from the current week and grouped by severity produces the required breakdown and refreshes automatically. Text, Table, and Number widgets either lack dynamic querying, lack grouping, or require manual intervention.

Answer

A 'Text' widget containing a markdown table that lists severity counts, refreshed by a scheduled job.

Answer

A 'Number' widget showing the total count of open incidents, with severity details added in the widget description.

Answer

A 'Table' widget that lists all incidents and relies on the analyst to sort by severity and date manually.

Question 7

During a routine maintenance window, an administrator upgrades a content pack from the Marketplace, which causes several existing playbooks to fail due to a breaking schema change in a custom automation script. What is the fastest method to revert the content pack to the previously working version?

Accepted Answer

Use the Marketplace interface to select the specific content pack and downgrade to the previous stable version.. Cortex XSOAR Marketplace allows administrators to manage installed content pack versions and roll back to previous versions directly from the Marketplace view.

Answer

Delete the content pack folder from the file system and restart the server.

Answer

Run 'demisto-sdk downgrade' from the CLI.

Answer

Restore the entire server from the last nightly database backup.

Question 8

An engineer needs Cortex XSOAR to enrich every newly ingested indicator from an external feed by querying an internal WHOIS service before the indicator is stored, and to block ingestion if enrichment fails. The WHOIS service is exposed through a custom integration. Which approach best meets this requirement?

Accepted Answer

Modify the custom feed integration so it calls the WHOIS integration during fetch and only returns indicators that enrich successfully, discarding failures.. To block ingestion based on enrichment outcome, the validation must occur before indicators are handed to the platform. Embedding the WHOIS call in the custom feed integration's fetch flow and emitting only successfully enriched indicators achieves this. Management rules and reputation commands operate after storage, and the described feed setting does not exist, so those approaches cannot prevent unenriched indicators from being stored.

Answer

Create a threat intel management rule that runs a script calling the WHOIS integration and only permits storage when the call succeeds.

Answer

Enable 'Enrich indicators' in the feed instance settings and set the enrichment timeout to zero so failures abort the fetch.

Answer

Configure the feed integration to run in 'indicator reputation' mode so enrichment is performed by the reputation command automatically.

Question 9

An XSOAR engineer is planning a custom integration fetch-incidents mechanism using REST API polling. The target API uses cursor-based pagination with timestamp markers. How must the integration code store the pagination state between polling intervals to ensure no incidents are missed?

Accepted Answer

Using demisto.getLastRun() and demisto.setLastRun() to persist cursor timestamps between execution cycles.. In XSOAR custom integrations, the fetch-incidents command must persist state between polling cycles to avoid missing or duplicating incidents. The demisto.getLastRun() and demisto.setLastRun() functions are specifically designed for this purpose, storing a JSON object that persists across executions. Using these ensures the cursor timestamp is reliably saved and retrieved, enabling correct incremental fetching.

Answer

Writing the cursor value to a global environment variable in the operating system shell.

Answer

Storing the cursor in the browser local storage of the administrator who configured the instance.

Answer

Hardcoding the timestamp directly into the integration YAML source code.

Question 10

Which THREE configuration settings can be applied to manage indicator lifecycles in Cortex XSOAR? Choose 3 answers.

Accepted Answer

Expiration threshold rules based on last seen time. Option A is correct because Cortex XSOAR indicator lifecycle management lets you define expiration threshold rules that automatically expire or change the status of indicators based on how long it has been since they were last seen (the last seen time), which is a core mechanism for keeping the indicator store current. Option D is correct because analysts can manually override an indicator's reputation or mark it as a false positive, directly changing its lifecycle status and preventing it from triggering future incidents. Option E is correct because XSOAR provides auto-cleanup settings that purge expired indicators from the indicator database on a scheduled basis, removing stale data and reducing noise. Options B and C are not part of indicator lifecycle management: Active Directory group policy synchronization relates to identity/access management, and syslog rotation schedules concern log retention on the logging infrastructure, neither of which controls how indicators expire, are overridden, or are cleaned up in XSOAR.

Answer

Active Directory group policy synchronization

Answer

Syslog rotation schedules

Question 11

Which TWO methods can an administrator use to share a dashboard with other users in Cortex XSOAR?

Accepted Answer

Share with specific user roles. Dashboards can be shared with specific roles or made public to all users.

Answer

Broadcast via Bluetooth pairing

Answer

Publish via public FTP server upload

Answer

Print via thermal receipt printer

Question 12

An analyst wants to view the historical reputation changes of a specific malicious IP address over time. Which tab within the Indicator Details page provides this timeline?

Accepted Answer

Timeline or History tab. The Reputation or History tab in the Indicator Details page displays the audit trail of score updates and source contributions.

Answer

Raw Data tab

Answer

Workplan tab

Answer

Related Incidents tab

Question 13

An organization uses a custom threat feed that updates via an API requiring OAuth2 authentication with token rotation. How should the administrator configure this integration instance?

Accepted Answer

Provide the client ID, client secret, and token URL in the integration instance configuration fields designed for OAuth2.. Cortex XSOAR integration instances support OAuth2 authentication natively through dedicated configuration fields for client ID, client secret, token URL, and scopes. The integration engine handles token acquisition and automatic refresh/rotation, so the administrator should populate these fields rather than embedding credentials in code or managing tokens externally. This is the secure, supported pattern for API integrations requiring OAuth2 with token rotation.

Answer

Hardcode the Bearer token into the integration script source code.

Answer

Write a cron job on the host OS to generate tokens and write them to a shared file.

Answer

Configure a separate incident classification rule to handle authentication headers.

Question 14

An XSOAR architect is planning a playbook for automated malware analysis. The playbook must submit files to a sandbox, retrieve the analysis report, and extract indicators. The sandbox integration may take variable time to return results, and the playbook must avoid blocking other tasks. Which TWO design elements are most appropriate to achieve this? (Choose two.)

Accepted Answer

Configure the sandbox submission task to run asynchronously and use a separate playbook to handle the report retrieval.. Polling with delays and retries, combined with asynchronous submission and separate report retrieval, effectively handle variable sandbox response times without blocking the playbook. These approaches allow the playbook to continue other tasks while waiting for analysis results, ensuring scalability and responsiveness. Other options either block execution, rely on manual intervention, or risk API abuse.

Answer

Set the sandbox integration timeout to a very high value to ensure the report is retrieved in a single call.

Answer

Use a manual task to periodically check the sandbox portal and update the incident when the report is ready.

Answer

Implement a loop that repeatedly calls the sandbox submission command until a report is returned, without any delay.

Question 15

Which log file on a Linux-based Cortex XSOAR server contains the primary application runtime logs (stdout/stderr of the server process)?

Accepted Answer

/var/log/demisto/demisto.log. On a Linux-based Cortex XSOAR server, the primary application runtime logs — including stdout and stderr from the demisto server process — are written to /var/log/demisto/demisto.log. This file captures server startup, integration execution errors, and core application events, making it the first place to check for runtime issues.

Answer

/var/log/postgresql/postgresql.log

Answer

/var/log/messages

Answer

/var/log/nginx/access.log