Select Two (Multi-Select) Questions

Upgrade server operating system

Why it fails: Operating system upgrades are executed by patch-management or endpoint tooling, not by the Incident WorkArea action menu, which launches playbooks, integrations and incident-field updates. It is tempting because remediation playbooks can invoke endpoint agents, yet the menu itself cannot upgrade an OS directly.

Format physical hard drives

Why it fails: Formatting physical hard drives is a hardware-level operation performed outside Cortex XSOAR; the Incident WorkArea action menu only triggers playbook tasks and integrations against incident records. It is tempting because destructive disk operations appear in some forensic workflows, but those run via endpoint agents, not the incident action menu.

An attached compiled binary file for Windows execution

Why it fails: Playbooks orchestrate tasks via integrations and scripts, not compiled binaries; attaching a Windows executable is neither required nor recommended for organisation-wide publishing. It is tempting where endpoint actions need custom code, but that belongs in an integration or script, not a playbook artefact.

Hardcoded passwords for external API integrations stored in plain text

Why it fails: Hardcoded plain-text credentials violate security best practice; publishing requires credentials stored in the Credentials store or integration instances instead. It is tempting when a playbook must authenticate to an external API, but secrets belong in protected credential fields, never embedded in the playbook itself.

Analyzing the server's physical power supply status LEDs

Why it fails: Power supply LEDs report hardware state, not playbook execution. They are used during physical datacentre checks to confirm a server has power. The audit trail lives in the incident War Room and task-level results, so this option cannot expose task history.

Inspecting the client browser's DNS cache settings

Why it fails: A browser DNS cache maps hostnames to IP addresses; it holds no playbook records. It is consulted when troubleshooting name resolution failures. Task execution history is surfaced through the incident War Room and the task results pane, not client-side DNS state.

Reviewing the local SMTP mail server queue

Why it fails: An SMTP queue holds outbound mail awaiting delivery, unrelated to playbook task auditing. Administrators inspect it to diagnose mail flow problems. Execution history is recorded in the incident's War Room entries and task outputs, which this option does not access.

Administrator operating system login passwords

Why it fails: Indicator Details surfaces threat context like verdicts, tags and related indicators, never administrator credentials, which Cortex XSOAR does not store or display. It is tempting because credential exposure is a common investigation finding, and such data would be correct within a credential-leak incident's evidence.

Raw BIOS serial numbers of the XSOAR server

Why it fails: Indicator Details shows threat-intelligence fields such as reputation, associated campaigns and related incidents, not server hardware identifiers. It is tempting because asset inventory data appears in endpoint context, and BIOS serials would be correct when viewing a host's system information.

Physical GPS coordinates of the threat actor

Why it fails: Indicator Details surfaces enrichment such as reputation, associated campaigns and WHOIS data; GPS coordinates of a threat actor are not a stored field. It is tempting because geolocation of infrastructure appears in some enrichment, but actor physical location is never derived.

Writing custom C++ kernel modules for memory parsing

Why it fails: Kernel modules parse memory at a low level, whereas a JSON threat feed is handled entirely in userspace by the integration's Python code and mapper. Kernel work is tempting for performance-critical parsing, but indicator mapping needs declarative field mapping, not C++ memory parsing, which XSOAR neither requires nor supports.

Modifying the XSOAR source code repository

Why it fails: Custom indicator mapping is configured through the XSOAR mapper and integration parameters, not by editing the platform's source code, which breaks supportability and upgrades. Source modification is tempting when a feed's schema appears unsupported, yet the correct approach is a custom integration or mapper definition within supported extension points.

Configuring hardware load balancers for the feed server

Why it fails: Load balancers address traffic distribution and availability, not the parsing and field-mapping logic that a non-standard JSON feed requires. Hardware is tempting when feed ingestion is slow or unreliable, but mapping depends on integration configuration and mapper rules, so load balancing does nothing for indicator extraction.

Kernel panic crash dumps

Why it fails: Crash dumps are system failure logs, not dashboard elements.

Raw Docker container logs

Why it fails: Docker logs are administrative items, not dashboard UI elements.

BIOS configuration utilities

Why it fails: BIOS utilities are hardware-level interfaces.

Active database connection pool size

Why it fails: Database connection pool size is an internal performance metric, not incident context, so it never appears in the incident header. Such metrics belong in system health monitoring. The header instead surfaces fields like severity, owner, type and occurrence time that analysts use to triage the incident itself.

CPU temperature of the XSOAR server

Why it fails: Server CPU temperature is infrastructure telemetry, not incident data, so it is not shown in the incident header. Hardware monitoring belongs in the platform's health dashboards. The header displays incident-level fields such as severity, status, owner and creation time that drive triage and assignment.

SSL certificate expiration date of the remote mail server

Why it fails: A remote mail server's certificate expiry is unrelated to the incident record, so it cannot appear in the header. Certificate monitoring belongs in dedicated infrastructure tooling. The header shows incident attributes like severity, owner, type and timestamps that analysts need when triaging the case.

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.

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.

Permanently disabling all external network connections during any alert

Why it fails: Playbooks execute defined response actions such as isolating a host or blocking an indicator, not blanket severing of all external connectivity on every alert. It is tempting because containment is a playbook task, but permanent global disconnection would halt business operations and is never an automated default.

Eliminating the need for any human oversight in security operations

Why it fails: Playbooks automate repetitive investigation and response tasks, but analysts still review, approve and handle exceptions; full autonomy is neither delivered nor desirable. It is tempting because automation reduces manual effort, yet human oversight remains essential for judgement calls and accountability.

Replacing all SIEM databases with flat text files

Why it fails: Playbooks orchestrate and enrich data across existing tools; they do not store or replace SIEM databases, and flat text files cannot support correlation or retention requirements. It is tempting because playbooks do handle artefacts, but the SIEM remains the system of record for log storage and search.

HTML email template designer

Why it fails: An HTML email template designer formats outbound notification emails; it neither extracts nor enriches indicators from feeds. It is tempting because XSOAR does send analyst notifications, but that belongs to communication workflows, whereas investigating feed indicators requires indicator extraction and enrichment features.

Global LDAP user directory sync

Why it fails: LDAP directory sync imports user accounts for identity mapping and role assignment, not indicator investigation. It is tempting because XSOAR does sync directories for RBAC, but that supports access management; examining threat-feed indicators instead needs indicator extraction and enrichment against reputation sources.

Automatic hypervisor backup scheduling

Why it fails: Hypervisor backup scheduling protects virtual machines; it has no role in indicator enrichment or investigation. It is tempting because Cortex XSOAR does integrate with infrastructure tooling, but that integration serves automated response playbooks, not threat-feed indicator analysis, which relies on indicator extraction and enrichment.

Compiling Python source code into machine bytecode

Why it fails: Conditional tasks branch playbook flow on task outputs, incident fields or scripts; they never compile Python into bytecode, which is the Python runtime's job. Bytecode compilation tempts because custom automation scripts are written in Python, but that occurs inside script tasks or integrations, not conditional branching configuration.

Directly modifying firewall access control lists without commands

Why it fails: Conditional tasks evaluate conditions to route execution; they hold no device credentials or firewall API integration, so ACLs cannot be altered from them. Direct ACL editing tempts as a response action, yet it belongs in a firewall integration command or dedicated task, not the conditional task's condition settings.

SQL JOIN statements

Why it fails: The search bar accepts its own query language over incident fields, not relational SQL against joined tables. It is tempting for analysts familiar with databases, but XSOAR's incident store is not exposed as SQL tables, so JOIN syntax cannot filter the WorkArea.

Regular expressions evaluated against raw disk sectors

Why it fails: The Incident WorkArea search bar parses structured query syntax against incident fields, not raw disk sectors, which XSOAR never exposes there. It is tempting as a forensic-sounding filter, but regular expressions apply to field values, not storage blocks, so this cannot match incidents.

Bash pipe commands

Why it fails: The Incident WorkArea search bar interprets XSOAR's query syntax, not shell pipelines; Bash pipes require an operating-system shell and file streams. It is tempting for engineers comfortable with command-line tooling, but no shell executes inside the search bar, so pipe commands cannot filter incidents.

Engines store a copy of the Cortex XSOAR incident database for offline access.

Why it fails: Engines do not store the incident database; they are stateless execution workers. The incident database resides on the server. Engines only receive tasks and return results, so they do not provide offline access to incidents. This statement is incorrect.

Engines can only run Docker-based integrations and cannot execute scripts directly on the host.

Why it fails: Engines execute integrations within Docker containers, but they can also run scripts that are part of automations. The statement that they cannot execute scripts directly is false; they handle both Docker-based integrations and script execution as directed by the server. Thus, this option is incorrect.

Engines automatically synchronize playbooks and integrations from the server and can execute them without server connectivity.

Why it fails: While engines receive playbooks and integrations from the server, they require connectivity to the server to receive tasks and report results. They cannot operate fully offline; they depend on the server for orchestration. Therefore, this statement is false.

The 'Add Indicators' command, which inserts new indicators into the database from external sources.

Why it fails: The 'Add Indicators' command imports indicators into Cortex XSOAR from external sources; it is an ingestion path, not an export path. It moves data inward, so it is the opposite of what the team needs when sharing indicators with a partner or pushing them to a SIEM. Relying on it would not transmit any indicator data outward, leaving the external systems without the intended indicators.

The 'Delete Indicators' command, which removes indicators after they are shared.

Why it fails: The 'Delete Indicators' command removes indicators from the Cortex XSOAR database, which is a lifecycle management action, not an export mechanism. It does not transmit indicator data to any external system, so it cannot satisfy the requirement to share indicators with a partner's TAXII server or push them to a SIEM. Using it would only reduce the local indicator set without delivering anything outward.

The 'Get Indicators' command, which retrieves indicators from the database for review.

Why it fails: The 'Get Indicators' command is for retrieving and displaying indicators from the Cortex XSOAR database, typically for review or use within playbooks. It does not produce an export file or push data to an external system in a format the partner or SIEM can consume. Using it would only surface indicator data inside the platform, so it does not fulfill the requirement to share indicators externally.

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.

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.

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.

Active Directory domain controller synchronization schedules.

Why it fails: Layout customisation in Cortex XSOAR covers incident fields, tabs and related-incident tables; Active Directory synchronisation schedules belong to directory integration configuration and never appear in the layout editor. It tempts because AD integration does populate user data, but it would be correct when configuring an integration instance's fetch and sync parameters.

Direct kernel-level memory dump inspectors.

Why it fails: Incident layout customisation exposes fields, tabs and sections for analyst data entry; kernel-level memory dump inspectors are forensic collection tooling, configured through integrations and playbooks, not layouts. It tempts because investigations do capture memory artefacts, but it would be correct when building a forensic acquisition task inside a playbook.

Embedded firewall policy modification wizards.

Why it fails: Embedded firewall policy modification wizards are not a configurable layout component in Cortex XSOAR; layouts expose fields, tabs and sections drawn from incident data. Such wizards belong to firewall management products, so they would suit a firewall orchestration playbook, not analyst data-entry efficiency.

3D-Scatter

Why it fails: 3D-Scatter is not among the native widget types Cortex XSOAR offers for custom dashboards; its chart library supports 2D types such as pie, bar, line and column. It is tempting because 3D scatter plots exist in general BI tools, and would be the right pick if the question concerned a full analytics platform rather than XSOAR's built-in widget set.

Heatmap-Matrix

Why it fails: Cortex XSOAR provides no native heatmap-matrix widget; its built-in types are bar, line, pie, table, gauge and number charts. It is tempting because heatmaps effectively show event density across two dimensions, and would be correct in a platform such as Kibana, not XSOAR's widget set.

Directly modifying the underlying OS kernel parameters

Why it fails: Sub-playbooks orchestrate integrations and tasks through the XSOAR automation engine; they cannot alter host OS kernel parameters. It is tempting because playbooks can run scripts, but those scripts execute within containerised integration environments, not with kernel-level control over the underlying operating system.

Compiling the sub-playbook into a native binary executable file

Why it fails: Cortex XSOAR sub-playbooks are reusable automation units invoked from parent playbooks; there is no compilation step producing a native binary. It is tempting because playbooks execute code-like logic, but sub-playbooks run interpreted within the XSOAR engine, not compiled into standalone executables.

'CompileToMachineCode' to convert context into native x86 assembly

Why it fails: Cortex XSOAR context expressions expose string and list transformers such as split, join, replace and filter; no transformer compiles context into x86 assembly, and playbooks run interpreted automation rather than native code. It would be tempting to anyone confusing transformation with compilation, which belongs to build toolchains, not XSOAR.

'EncryptDatabase' to secure SQL storage

Why it fails: XSOAR transformers manipulate context data in memory; none encrypts SQL storage, and database encryption is handled at the platform or SQL layer, not inside playbook expressions. It would be tempting when seeking to protect sensitive incident data at rest, which is a storage-administration concern rather than a context transformer.

Active incident war room chat logs from the development environment.

Why it fails: War room chat logs are runtime incident data generated in the development tenant, not pack content, and cannot be exported or reinstalled. It is tempting because playbook tasks post to war rooms, but retaining chat history is a tenant data-retention concern, not a packaging requirement.

Local analyst user account credentials and password hashes.

Why it fails: Credentials and password hashes are environment-specific secrets and must never travel inside a Content Pack; integrations authenticate through per-tenant instance configuration instead. It is tempting because playbooks reference accounts, but a pack destined for one isolated lab tenant with pre-shared service accounts would legitimately embed such references.