Architecture, Deployment, and Initial Configuration
This domain tests deployment topology choices, adding managed hosts, and first-run configuration that makes the pipeline work.
Core rules
- An All-in-One console runs the UI, rules, and Ariel; a distributed deployment separates Event Collectors (receive and parse with DSMs), Event Processors (run rules and store events), Flow Collectors/Processors, and Data Nodes.
- Add a host in Admin > System and License Management > Deployment Actions > Add Host, supplying IP, hostname, SSH key, and component type. The host is not usable until Deploy Changes completes; watch the Deployment Request Queue (drq).
- NTP, forward/reverse DNS, and consistent SSH keys are prerequisites. A console IP change must be reflected in managed-host configuration.
- Initial configuration order: license, network, network hierarchy, log sources, users, then health verification.
Worked example
A new Event Processor is added and the deployment succeeds, but no events appear. The log source is still assigned to the old Event Collector, so the processor has nothing to process. Reassign the log source to the new collector, deploy, and confirm the DRQ is empty. If deployment stalls, read /var/log/qradar.error before retrying.
Traps
- Treating Event Collector and Event Processor as interchangeable: parsing happens on the collector, rules on the processor.
- Assuming Add Host is the finish line; undeployed changes are not active.
- Deploying while DRQ jobs are failed, which leaves a mixed configuration.
- Skipping NTP, which breaks replication, searches, and offense timelines.