XSOAR Architecture and Deployment
This domain tests whether you can reason about XSOAR's runtime pieces and how deployment choices affect availability, performance, and upgrades - not whether you can recite a hardware bill of materials.
Core components
- The application server serves the web UI and REST API, runs the playbook engine, and schedules jobs. In Cortex XSOAR 8 the execution work is split onto separate engines that run integration and script containers.
- MongoDB is the system of record: incidents, context, indicators, users, and installed content. Production and HA deployments use a replica set, normally three members.
- Elasticsearch provides the index behind incident and indicator search. It is a derived copy, not the source of truth; a lagging index delays search results but does not lose incidents.
- RabbitMQ carries inter-service messaging in multi-server deployments, so HA is not just two app servers behind a load balancer.
- Every integration instance and script runs in a Docker container built from a pinned image. Python dependencies are baked into the image through the requirements file, not installed on the host.
Deployment models
On-premises, customer-managed cloud, and vendor-managed differ mainly in who owns upgrades and scaling. Content arrives as packs from the Marketplace, and configuration backups capture content and settings, not the MongoDB data files.
Worked example
A team wants zero-downtime upgrades on-premises. Reasoning: a single server with a local database has no HA path, so the design needs a three-member MongoDB replica set, a load balancer over at least two application servers, RabbitMQ, and a multi-node Elasticsearch cluster. Engines must also have network routes to every system the integrations touch.
Traps that cost marks
Assuming Elasticsearch is the database, expecting host-level pip installs to change container behaviour, and treating a configuration backup as a full data backup.