IBM QRadar Interview Questions — SIEM Architecture & AQL Answers

① Architecture & components — Console, processors and App Host

Q: Describe the main components of IBM QRadar and their roles.

Model answer: QRadar is built around four component types. The Console is the single management and search UI — it hosts the Offense Manager, the Log Activity and Network Activity tabs, and the AQL search interface, but it does not process events. Event Processors (EPs) are the workhorses: they receive raw log events from log sources, invoke the DSM parser to normalise them, evaluate custom rules, and write events to the Ariel database. Flow Processors (FPs) ingest NetFlow, IPFIX, sFlow and QRadar-generated flows to provide network behaviour visibility alongside events. The App Host is an optional dedicated appliance (or VM) that runs QRadar apps — UBA, the Pulse dashboard, QRadar Assistant — without consuming EP or Console CPU cycles. In an all-in-one lab deployment all roles run on a single appliance; in enterprise, EPs and FPs scale horizontally.

Q: How does an event travel from a firewall log to a QRadar offense?

Model answer: The firewall sends a syslog message to the Event Collector (a lightweight forwarder co-located with an EP or standalone). The collector forwards it to the Event Processor, which runs the matching DSM to parse and normalise fields (source IP, destination IP, port, username, log source type). The normalised event is written to the Ariel event store. Simultaneously, all active Custom Rules are evaluated against the incoming event stream. When rule conditions match (for example five failed logins from the same source in 10 minutes), QRadar creates or increments an Offense in the Offense Manager with a magnitude score (1–10) based on relevance, severity and credibility. Analysts triage offenses, not individual events.

Q: What is the Ariel database and why does QRadar use a time-series store rather than a relational RDBMS?

Model answer: Ariel is QRadar's proprietary high-speed time-series columnar store designed for security event volumes that would overwhelm a row-based relational database. Events and flows are appended in time order and indexed by time window, source IP, destination IP and QID (the QRadar event identifier). This lets AQL range scans across millions of events complete in seconds. The tradeoff is that Ariel is not a general-purpose RDBMS — you cannot do arbitrary JOINs across unrelated tables the way you would in SQL. For cross-dataset enrichment, QRadar uses Reference Sets, Reference Maps and Reference Tables loaded from threat-intel feeds or HR data, which rules can query at correlation time without a JOIN.

Q: What are Reference Sets, Reference Maps and Reference Tables in QRadar?

Model answer: These are QRadar's in-memory lookup structures that rules and AQL can query at real time. A Reference Set is a flat list of values (e.g. a list of known-bad IPs from a threat feed) — rules check 'is the source IP in this set?' A Reference Map is a key→value store (e.g. employee ID → department). A Reference Table is a key→(inner key→value) two-dimensional map (e.g. username → attribute → value). All three can be populated via the QRadar API, the Console UI or a scheduled feed, and they allow context enrichment during rule evaluation without re-parsing log data.

② Log sources, flows & AQL — getting data in and querying it

Q: What log source protocols does QRadar support, and when do you use each?

Model answer: QRadar supports several ingest protocols. Syslog (UDP/TCP/TLS) is the most common — firewalls, Linux servers and network devices push events; use TCP or TLS for reliable delivery. WinCollect is IBM's Windows agent that reads the Windows Security, Application and System event logs and forwards them to QRadar — preferred over WMI because it is far lower overhead on domain controllers. JDBC pulls records from relational databases (e.g. Oracle, MSSQL audit tables) on a schedule — useful when the source cannot push syslog. The Log File Protocol retrieves flat log files from SFTP/FTP servers. REST API and vendor-specific connectors (e.g. Microsoft Graph, AWS CloudTrail) pull cloud and SaaS events. The DSM for each source parses the raw payload into QRadar's Common Event Format (QRadar taxonomy) fields.

Q: What is AQL (Ariel Query Language) and how does it differ from standard SQL?

Model answer: AQL is QRadar's SQL-like query language for the Ariel event and flow stores. The syntax looks familiar — SELECT sourceip, COUNT(*) FROM events WHERE category=5002 GROUP BY sourceip — but several differences catch candidates. Time filtering uses LAST N HOURS/MINUTES or START/STOP epoch timestamps, not SQL date functions. Aggregate functions include UNIQUECOUNT (distinct count), SUM, MIN, MAX and AVG. Queries target named stores: events or flows (not custom table names). Field names follow QRadar taxonomy — sourceip, destinationip, username, qid, category — not the raw syslog field names. There are no cross-store JOINs; instead, use Reference Sets as lookup structures in WHERE clauses.

Q: Write an AQL query to find accounts with more than five failed logins in the last hour, grouped by username.

Model answer: A correct answer looks like: SELECT username, COUNT(*) as fail_count FROM events WHERE category = 5002 AND "Event Name" = 'Authentication Failed' GROUP BY username HAVING COUNT(*) > 5 LAST 1 HOURS. The key points to explain: category = 5002 is QRadar's low-level category for authentication failures; LAST 1 HOURS is the AQL time clause (not a WHERE predicate); HAVING filters on aggregate results just as in SQL; and username must be a mapped QRadar taxonomy field (the DSM must populate it — if the DSM leaves it blank, the query returns null values, which is a common root cause of empty AQL results).

Q: How do you onboard a new log source — say a Palo Alto NGFW — to QRadar?

Model answer: The steps are: (1) In the QRadar Console, go to Admin → Data Sources → Log Sources and add a new log source, selecting Palo Alto PA Series as the Log Source Type (the DSM that ships with QRadar or is installed from the IBM App Exchange). (2) Configure the protocol — typically Syslog UDP/TCP — and set the IP/hostname of the firewall so QRadar knows which incoming syslog source to associate with this log source definition. (3) On the Palo Alto, configure a Syslog Server Profile pointing to the QRadar EP's collector port (514 UDP or TCP). (4) After events arrive, verify them under Log Activity — check that the Log Source column shows 'Palo Alto' (not 'SIM Generic') and that fields like sourceip, destinationip, username and category are populated by the DSM (not blank). A SIM Generic or Unknown log source means the DSM did not match the payload format, which is the most common onboarding failure.

③ Rules, offenses & UBA — correlation and behavioural detection

Q: What is the difference between a Custom Rule and a Building Block?

Model answer: A Custom Rule is a full correlation object: it defines test conditions (AND/OR logic over event properties, counts, time windows, Reference Set lookups) and specifies an action — generate an offense, add an event to an existing offense, log to a certain log source, or dispatch a response. A Building Block has identical condition syntax but has no action and never creates an offense. Its sole purpose is to be a reusable named filter referenced by other rules, avoiding copy-paste logic. For example, a 'Is External IP' Building Block checks whether an IP is outside RFC 1918; multiple rules reference that Building Block instead of each repeating the subnet list. The interview one-liner: Building Block = reusable filter, no action; Custom Rule = same conditions + an action.

Q: Explain the QRadar offense lifecycle from creation to closure.

Model answer: An Offense is created when a Custom Rule fires and its action is 'Create an offense' or 'Assign events to an offense.' QRadar scores it with a magnitude (1–10) that is a weighted composite of relevance (how critical the destination asset is, per the Asset Profile), severity (the rule's configured severity) and credibility (confidence in the log source's data quality). The offense collects correlated events from the same source IP (or username) over its active window. Analysts triage offenses in the Offense Manager: they assign the offense to themselves, mark it Active/Under Investigation, investigate with AQL searches and the Offense Summary, then either close it (with a reason: Resolved, False Positive, No Further Action) or escalate it to a SOAR case. Offenses that receive no new correlated events for the inactive offense timeout (configurable, default 5 days) are automatically closed. Tuning tip: if a rule is generating too many low-quality offenses, increase the event count threshold in the rule conditions or set it to only add events to an existing offense rather than always creating a new one.

Q: What is QRadar User Behavior Analytics (UBA) and how does it score users?

Model answer: QRadar UBA is an app installed on the App Host that adds a machine-learning risk layer on top of QRadar's rule-based correlation. UBA ingests identity data (Active Directory, LDAP, HR feeds) and QRadar events to build a behavioural baseline per user — normal login times, usual source IPs, typical data access patterns. When user activity deviates from baseline — late-night logins, access from a new country, sudden bulk file downloads — UBA assigns an ML-based risk score (0–100) to the user. High-risk users appear in the UBA dashboard. Critically, UBA risk scores are available as a test in Custom Rules: a rule can fire 'offense on brute-force AND user-risk > 70', dramatically reducing false positives compared to a count-only rule. The interview point: UBA adds ML-scored user risk that Custom Rules can consume, bridging behavioural and rule-based detection.

Q: How do you tune a rule that is generating too many false-positive offenses?

Model answer: Start with the data: in Log Activity, run an AQL query to count how many events match the rule's conditions over the past week. Then examine the false-positive offenses — what do the source IPs, usernames or asset tags have in common? Common tuning levers: (1) Raise the event count threshold — change 'more than 3 events' to 'more than 10'. (2) Add exclusions via a Building Block — create a 'Excluded Trusted Scanners' Reference Set and add a negative test 'source IP is NOT in Excluded Trusted Scanners'. (3) Layer an asset criticality condition — only fire when destination asset value is High or Critical. (4) Add a time-of-day constraint — business-hours logins from internal IPs are benign; after-hours are suspicious. (5) If the rule fires on a specific benign log source, add an exclusion for that log source type. Always test the tuned rule in simulation mode (Disable the action, check Log Activity matches) before enabling it live. The gold principle: tune with data, not guesses — let AQL counts guide every change.

④ SOAR & scenarios — automated response and day-2 operations

Q: What is QRadar SOAR and how does it connect to QRadar SIEM?

Model answer: QRadar SOAR (Security Orchestration, Automation and Response — formerly IBM Resilient) is a separate product that provides case management, playbook automation and cross-tool orchestration for incident response teams. The integration works bi-directionally: a QRadar Custom Rule action can automatically open a SOAR case from an offense (via the SOAR app in QRadar), pushing offense details, associated events and asset data into the case. Inside SOAR, a playbook (a defined workflow) can run automatically — for example, enriching an IP via VirusTotal, querying EDR for the endpoint, isolating the host, and notifying the team on Slack. SOAR can also add notes back to the QRadar offense and close it when the case is resolved. The clean split: QRadar SIEM detects and correlates; QRadar SOAR automates the response workflow and manages the case to closure.

Q: Describe how you would respond to a ransomware offense in QRadar end to end.

Model answer: When QRadar fires a high-magnitude ransomware offense (triggered by rules detecting mass file-rename events from endpoint logs plus unusual outbound connections to uncategorised IPs from the same host), the response path is: (1) Triage in Offense Manager — confirm the source IP, the affected asset's criticality, and drill into the offense's associated events. (2) AQL investigation — query events and flows to find all destination IPs the host contacted and all users logged in at that time. (3) Escalate to SOAR — the 'Create SOAR Case' action (or an automatic rule action) opens a SOAR incident. (4) Playbook runs — isolate the endpoint via EDR integration, block the C2 IPs on the firewall via SOAR's network device integrations, and notify the IR team. (5) Close the loop — SOAR updates the QRadar offense with investigation notes and closes it after containment is confirmed. The architecture point: QRadar surfaces what happened and which assets are involved; SOAR orchestrates what to do across every tool in the stack.

Q: How do you manage and upgrade QRadar in a distributed deployment?

Model answer: In a distributed deployment the Console is the central manager — all configuration, rule editing, offense management and user access happens here. Event and Flow Processors are managed agents that phone home to the Console. Patching follows IBM Fix Pack releases; the Console is patched first, then EPs and FPs in sequence, because a Console version must always be equal to or higher than its managed processors. Capacity planning keys on Events Per Second (EPS) — each EP appliance has a licensed EPS ceiling; when approaching it you add an EP and use the routing rules to distribute log sources across EPs. Data retention is configured per-store (events, flows, payloads) in days; raw payloads are the largest store and are often set shorter than event metadata. The QRadar System Health dashboard shows EPS, FPS, queue depths and disk utilisation — the first place to look when analysts report slow searches.

Q: A security analyst says QRadar searches are slow and offenses are delayed. How do you troubleshoot?

Model answer: Start with Admin → System Health to check three metrics: (1) EPS rate — if events per second is near or above the EP's licensed ceiling, the EP is backlogged; distribute load to another EP or reduce noisy log sources. (2) Ariel queue depth — a growing queue means events are arriving faster than the EP can index them; again, check EPS and disk I/O. (3) Disk utilisation — if the data partition is above 85%, Ariel performance degrades; shorten retention or add storage. For search speed specifically, check whether the AQL query is missing a LAST time bound — a query with no time constraint scans the entire Ariel store, which can take many minutes. Advise analysts to always include LAST N HOURS. If the issue persists after ruling out capacity, check for a runaway rule — a rule with no count threshold or time window that fires on every event can flood the rule engine; use the Rule Performance view in the Console to identify high-firing rules.