Planning Installation And Maintenance practice questions

tar -czvf /backup/xsoar.tar.gz /var/lib/demisto

Why it fails: A raw tar of /var/lib/demisto captures files while the database and services are live, producing an inconsistent archive that can omit in-flight incident writes. It is tempting because tar is a familiar general-purpose archiving tool, and it would be correct for backing up static directories or log files that are not being concurrently modified.

pg_dump demisto > backup.sql

Why it fails: pg_dump exports only the PostgreSQL database, so playbook files, integrations and configuration stored outside the database are omitted, and it is not the vendor-recommended mechanism. It is tempting because pg_dump is the standard PostgreSQL backup utility, and it would be the right choice for capturing a standalone database with no accompanying application state.

XSOAR Web UI > Settings > Maintenance > Export Snapshot

Why it fails: The Maintenance Export Snapshot produces a support-oriented diagnostic bundle rather than a restorable backup of incident history, playbooks and configuration. It is tempting because it is an official in-product export, and it would be appropriate when gathering logs and system state for Palo Alto support to troubleshoot a fault.

Upgrade all components simultaneously using the orchestrated installer.

Why it fails: Upgrading every node at once takes the whole HA cluster offline, so no server remains to serve requests during the upgrade — defeating the zero-downtime requirement. It is tempting because the orchestrated installer is genuinely designed for single-node or lab deployments where brief downtime is acceptable.

Upgrade secondary servers first, then the primary server, and lastly the engines.

Why it fails: Upgrading secondaries before the primary leaves the primary running older code and engines mismatched, breaking HA failover and API compatibility during the window. It is tempting because secondary-first is standard for many clustered systems, but XSOAR requires engines and the primary updated in a defined sequence.

Upgrade the engines first, then secondary servers, and finally the primary server.

Why it fails: Upgrading engines before the servers leaves them pointing at an older broker schema, so the HA pair cannot fail over cleanly. Engines-first is tempting because they are stateless and easy to restart, but zero-downtime requires the primary and secondary servers updated before engines.

demisto.engine.memory.limit

Why it fails: This parameter governs engine memory behaviour rather than the JVM heap ceiling, so raising it will not stop out-of-memory crashes during heavy ingestion. It is tempting because its name suggests memory control, but the JVM maximum heap is set through the server's Java memory configuration, not this engine setting.

incident.ingestion.buffersize

Why it fails: This parameter controls how many incidents are buffered during ingestion, not the JVM heap ceiling, so it cannot prevent out-of-memory crashes. It is tempting because ingestion volume drives the problem, but the question asks which setting caps Java heap size, which this does not.

python.max.worker.memory

Why it fails: This parameter caps memory for individual Python integration scripts, not the JVM heap, so it cannot resolve the out-of-memory crash. It is tempting because it is a memory-related server setting, but the correct control is the Java heap parameter (for example Xmx/JVM memory configuration) governing the Cortex XSOAR server process.

Incidents > Audit Trail

Why it fails: The incident audit trail tracks changes made to specific incident fields, not integration execution streams.

Dashboards > Server Metrics

Why it fails: Server Metrics graphs CPU, memory and disk usage of the Cortex XSOAR hosts, not integration run history. It is tempting because it is the only built-in monitoring view, but it would be the right place to diagnose infrastructure resource exhaustion, not API timeouts or integration execution errors.

Settings > Advanced > System Health

Why it fails: System Health reports component status and connectivity for services such as the database and message queue, not per-integration execution history. It is tempting as the diagnostics area, but it would be the right place to confirm whether a platform service is degraded rather than to trace API timeouts.

Dashboards > Container Health

Why it fails: Container Health reports CPU, memory and disk usage of running containers, not the Docker image tags or versions pulled for integrations. It is tempting because the name implies image visibility, but active image versions appear under Settings > Integrations > Instances or the marketplace installation details.

Incidents > Management > Containers

Why it fails: The Containers page under Incidents lists running container instances tied to incident investigation, not the image versions configured for integrations. It is tempting because it does display Docker containers, but those are execution artefacts rather than the integration image registry data.

Settings > About > System Information

Why it fails: System Information reports server build, licence and platform details, not the Docker image tags assigned to each integration. It is tempting as a general version-lookup location, yet integration image versions are exposed through the Integrations page's Docker image column instead.

Configured inside the PostgreSQL database connection string

Why it fails: A PostgreSQL connection string carries database host, credentials and options; it is never consulted by integration containers when building TLS trust stores, so the private CA remains untrusted. It is tempting because connection strings do hold certificate-related parameters for database TLS, which would matter if the failing connection were to PostgreSQL rather than the internal API.

In the host operating system's /etc/pki/ca-trust/source/anchors/ directory only

Why it fails: Cortex XSOAR integrations run inside Docker containers with their own trust stores, so a certificate placed only in the host's anchors directory is never read by those containers. The CA must be added to the containers' trust store. Host-level installation suits non-containerised services on that host.

Inside each individual integration's Python script code

Why it fails: Embedding the CA certificate in each integration's Python code bypasses the system trust store, so every other integration and any library performing verification still fails. The certificate belongs in the containers' trust store. Hardcoding suits a single bespoke script that pins one certificate.

server.max.threads

Why it fails: server.max.threads controls general HTTP request threads, not Python script execution workers.

integration.concurrency.limit

Why it fails: No such parameter exists in Cortex XSOAR server configuration; concurrency for Python integrations is governed by the Docker worker pool, not an integration.concurrency.limit key. It is tempting because the name describes the desired effect, but setting it changes nothing. It would be correct only if XSOAR exposed a per-integration thread cap, which it does not.

docker.container.pool.size

Why it fails: docker.container.pool.size sets how many Docker containers are pre-created and available, not the maximum concurrent execution threads per Python script. Raising it adds workers but does not cap runaway scripts. It would be the right lever when container startup latency, rather than thread exhaustion, limits throughput.

Disable the integration for all users except Tier 2 via server configuration keys.

Why it fails: Server configuration keys apply globally, not granularly per integration instance by user role.

Place the integration inside a restricted playbook folder.

Why it fails: Playbook folder permissions do not restrict direct integration command execution from the CLI or war room.

Modify the integration Python code to check the logged-in user's username.

Why it fails: Hardcoding user checks in code is insecure and violates RBAC best practices.

Via the demisto-sdk registry-login command

Why it fails: demisto-sdk is a developer tool and does not manage live server registry credentials.

In the individual integration instance settings under API Key

Why it fails: Integration instance settings store service API keys, not container registry credentials.

Inside the demisto.conf configuration file on the Linux host file system

Why it fails: demisto.conf does not store Docker registry credentials.

Disable scheduled tasks on all secondary servers via crontab.

Why it fails: XSOAR manages scheduled tasks internally via the application database, not OS crontabs.

Configure a shared Redis cache for job locking.

Why it fails: Cortex XSOAR uses PostgreSQL for state locking, not an external Redis cache.

Set each secondary server to 'Read-Only Mode' in the server configuration.

Why it fails: Read-only mode prevents user writes, but job execution requires specific cluster role configurations.

Incidents > Configuration > Version Control

Why it fails: Version control is managed in Settings, not under Incidents.

Dashboards > Git Sync

Why it fails: Git sync is not managed from the Dashboards menu.

Settings > About > Repository Settings

Why it fails: Repository settings for Git are configured as an integration instance, not under About.

Drop the PostgreSQL temporary tables using psql.

Why it fails: Manually dropping tables bypasses XSOAR application logic and corrupts database referential integrity.

Restart the demisto service with the '--purge-cache' flag.

Why it fails: The demisto service does not accept a --purge-cache flag.

Execute 'rm -rf /var/lib/demisto/tmp/*' directly from the Linux shell.

Why it fails: Deleting active temporary working files while the application runs can cause runtime errors and file handle locks.

Stop all inbound email fetching and incident ingestion streams

Why it fails: Halting ingestion prevents new incidents and playbook runs from writing to the database mid-upgrade, but it is not required preparation; upgrades proceed with ingestion active. Administrators stop ingestion only for maintenance windows where data consistency during migration matters, not as a standard pre-upgrade step.

Uninstall all third-party marketplace content packs to prevent schema conflicts

Why it fails: Marketplace content packs are supported across major upgrades and uninstalling them removes detection content and integrations; conflicts are handled by checking compatibility instead. It is tempting because pack incompatibility can cause errors, and removal would be correct only for a pack the vendor explicitly flags as unsupported on the target version.

Re-initialize the PostgreSQL database schema from scratch

Why it fails: Re-initialising the PostgreSQL schema destroys all incident, playbook and indicator data, so it cannot precede an in-place major version upgrade. It is tempting because a clean schema genuinely resolves migration failures between incompatible database versions, and would be right when rebuilding a lab or recovering a corrupted, disposable instance.

server.jvm.garbage.collection.interval

Why it fails: Garbage collection is managed automatically by the JVM and is not a standard ingestion throttling parameter.

docker.max.container.lifespan

Why it fails: Container lifespan does not control incident ingestion rates.

Settings > Integrations > Server Version

Why it fails: There is no Server Version menu under Integrations.

Checking the Apache HTTP server header response

Why it fails: Cortex XSOAR runs on its own embedded HTTP server framework, not Apache.

The server file system path /var/lib/demisto/VERSION

Why it fails: Version information is not stored in a plain text file at that path.

Disable database transaction logging (WAL) to save disk space.

Why it fails: Disabling WAL logging violates database integrity requirements and prevents point-in-time recovery.

Manually export every incident into PDF format using browser print functions.

Why it fails: Manual PDF exports are unscalable and impractical for enterprise compliance archiving.

demisto-sdk init

Why it fails: The demisto-sdk init command initializes a new content repository or a new integration/script. It does not interact with an existing server to export content. Therefore, it cannot be used to back up custom scripts and integrations from a running Cortex XSOAR instance.

demisto-sdk upload

Why it fails: The demisto-sdk upload command uploads content from a local directory to a Cortex XSOAR server. It is used for pushing changes to the server, not for backing up existing content. Using this would not export custom scripts and integrations from the server.

demisto-sdk backup

Why it fails: The demisto-sdk backup command is not a valid command in the Demisto SDK. The SDK provides commands like demisto-sdk download for pulling content, but backup is not one of them. This command would fail and not produce the required backup of custom scripts and integrations.

A Cortex XSOAR engine cluster with each engine assigned to a different tenant

Why it fails: Engines are used for remote execution and load distribution, not for tenant isolation. Assigning engines per tenant does not isolate incidents, playbooks, or user management. Tenant separation is handled at the server level via Account Management, so this option does not meet the requirements.

A single Cortex XSOAR server with all tenants sharing the same incident database and role assignments

Why it fails: Sharing the same incident database and role assignments does not provide tenant isolation. Users from one tenant could potentially access another tenant's incidents or configurations. This violates the requirement for strong isolation and independent user management, so it is incorrect.

Multiple independent Cortex XSOAR servers, one per tenant, with no shared infrastructure

Why it fails: Deploying separate servers per tenant achieves isolation but is operationally heavy and not the intended multi-tenant model. Cortex XSOAR natively supports multi-tenancy on a single server, so this approach adds unnecessary cost and management overhead. It is not the recommended solution for the stated requirements.

Take a snapshot of the virtual machine hosting the Cortex XSOAR server and proceed with the upgrade.

Why it fails: A VM snapshot only captures the server's disk state, not the external PostgreSQL database or Elasticsearch cluster. Since these components are external, a VM snapshot would not provide a complete rollback point. The upgrade might modify the external databases, and without their backup, data loss could occur.

Export all incidents to a CSV file using the Cortex XSOAR API and store it on a network share.

Why it fails: Exporting incidents to CSV does not capture the full database schema, configurations, or system state. This method is insufficient for a complete rollback and would not restore the system to its pre-upgrade state. The upgrade process requires a full backup of the PostgreSQL database and Elasticsearch indices, not just incident data.

Disable all integrations and playbooks, then upgrade; the system will automatically create a restore point.

Why it fails: Cortex XSOAR does not automatically create a restore point during upgrades. Disabling integrations and playbooks may reduce load but does not protect data. A manual backup is required to ensure rollback capability. Relying on an automatic restore point is incorrect and could lead to irreversible data loss.

A copy of the Cortex XSOAR server's database

Why it fails: The engine does not require a copy of the server's database. It operates by receiving tasks and playbook instructions from the server and executing them locally. The database remains on the server, and the engine communicates via a secure channel without needing direct database access.

A license file for the engine

Why it fails: Cortex XSOAR engines do not require a separate license file. Licensing is handled at the server level. The engine is an extension of the server and does not need its own license to operate. Therefore, a license file is not required for engine-server communication.

A valid API key generated on the Cortex XSOAR server

Why it fails: An API key is used for authenticating API requests, but the engine does not use an API key to communicate with the server. Instead, it uses a secure tunnel established during initial configuration. API keys are typically for external integrations or automation scripts, not for engine-server communication.