IBM C1000-162 common mistakes
IBM C1000-162 · Understand the traps and how to avoid them.
When asked which offense should be triaged first, candidates pick the offense with the highest magnitude or the newest timestamp instead of the one matching the organization's defined severity/priority criteria.
QRadar shows magnitude, credibility, severity, and relevance as separate contributors, and candidates conflate magnitude (raw event volume/weight) with business priority. They also forget that offense priority is driven by rules and building-block weights configured per deployment, not by a universal ranking.
What to do instead
Before answering, identify which attribute the question ties to prioritization (severity vs. magnitude vs. credibility vs. relevance) and map each to its definition: severity = impact of the event, credibility = likelihood it is real, relevance = weighted combination, magnitude = contribution of contributing rules. Practice reading an offense summary and stating which single attribute would change the triage order and why.
Treats the offense as the unit of investigation and never drills into the contributing events, flows, or the rule that fired, so the proposed next step is generic ("investigate further") rather than specific ("pivot on the source IP in the flow viewer to confirm lateral movement").
Candidates memorize the offense list view and skip the offense detail tabs (Events, Flows, Contributing Rules, Annotations, Notes). Exam items often describe a scenario and ask for the most efficient next investigative action, which requires knowing which tab holds which evidence.
What to do instead
Learn the offense detail layout cold: which tab shows raw events, which shows network flows, which shows the rules and building blocks that contributed, and where annotations/notes live. For each scenario, ask "what evidence do I still lack?" and pick the tab that supplies it.
Confuses the roles of rules, building blocks, and custom rules when designing detection logic, e.g., writing a standalone rule where a building block should feed multiple rules, or expecting a building block to generate offenses on its own.
Building blocks are reusable logic containers that test conditions and return true/false; they do not create offenses by themselves. Candidates who learned rule syntax without the architecture misassign responsibilities and pick answers that break reuse or produce no offenses.
What to do instead
Internalize the hierarchy: building blocks encapsulate testable conditions and can be nested; rules combine building blocks (and tests) and, when they fire, generate offenses. When a question mentions reuse across many rules or centralizing a threshold, the answer usually involves a building block; when it mentions generating an offense or an alert, it involves a rule.
Misreads rule test logic, especially AND/OR nesting and negation, and selects a rule that fires on the wrong condition set (too broad or never fires).
QRadar rule tests are evaluated as a tree; candidates read the flattened text as if it were left-to-right boolean logic and miss that a NOT or an OR higher in the tree changes the whole branch. They also overlook that some tests implicitly apply to the event/flow being evaluated rather than to all accumulated events.
What to do instead
Practice translating nested test trees into plain-language sentences, then back. For each candidate rule, construct two concrete example events: one that should fire and one that should not, and walk the tree manually. Pay explicit attention to negation placement and to whether a test is scoped to a single event or to a time window.
Ignores rule response configuration and threshold/ time-window settings, so the answer describes correct detection logic but the wrong offense behavior (one offense per event instead of an aggregated offense, or a flood of duplicate offenses).
Candidates focus on the test tree and forget the rule's response (what it does when it fires) and its aggregation settings (grouping by a common attribute, time window, and count thresholds). These settings determine whether the rule produces one consolidated offense or many.
What to do instead
When a scenario complains about offense volume, duplicate offenses, or missing aggregation, check the rule's response and its group-by/time-window/threshold configuration before touching the test logic. Memorize the distinction between a rule firing per event and a rule accumulating events into a single offense keyed on a chosen attribute.
Designs a threat hunt as a one-off search for a known bad indicator rather than as a hypothesis-driven hunt with a defined scope, data sources, and success criteria.
Candidates equate threat hunting with IOC searching. Exam scenarios about hunting typically reward structured methodology: forming a hypothesis about adversary behavior, identifying the telemetry that would reveal it, and defining what evidence confirms or refutes it.
What to do instead
Use a repeatable hunt template: hypothesis, required data sources (flows, events, DNS, authentication logs), the query or rule that tests it, expected benign explanations, and the escalation path. When a question asks for the first hunting step, prefer hypothesis and data-availability scoping over jumping to a query.
Picks a hunt technique that the available data cannot support, e.g., proposing DNS-tunnel detection when DNS logging is not ingested, or behavioral anomaly detection without a baseline period.
Candidates answer from general security knowledge without checking what QRadar actually has: which log sources are onboarded, whether flows are collected, and whether enough historical data exists for baselining.
What to do instead
Before choosing a technique, list the data it requires and verify each against the scenario's described log sources and flow sources. If a required source is absent, the correct answer is usually to onboard that source first or to choose an alternative technique that the existing telemetry supports.
Edits or deletes a shared dashboard, saved search, or report owned by another team, or builds a personal view where a shared one is required, causing visibility or permission problems.
Candidates do not distinguish between personal and shared objects, owner versus tenant permissions, and the effect of user roles on dashboard and report administration. They also overlook that deleting a saved search can break dashboards and reports that depend on it.
What to do instead
Learn the object model: personal vs. shared ownership, which roles can create/edit/delete each object type, and dependency relationships between saved searches, dashboards, and reports. When a question involves a change to a shared object, check ownership and role permissions first, and prefer copying rather than editing in place.
Writes an AQL query that returns the wrong aggregation level (e.g., grouping by source IP when the question asks for a count of distinct destinations per source) or misuses time-range and sorting clauses so results are truncated or out of order.
Candidates know individual AQL keywords but not how GROUP BY, DISTINCT, ORDER BY, and the time range interact. They also forget that the search time range is set outside the query text and that result limits can hide the answer.
What to do instead
For each reporting question, state the grain of the answer first (per source? per user? per day?), then choose GROUP BY and aggregate functions to match that grain. Practice writing queries that count distinct values, sort descending, and apply an explicit time range, and verify the limit/offset settings so the top rows are not cut off.
Confuses report and saved-search scheduling behavior, e.g., expecting a scheduled report to reflect real-time data or assuming a saved search runs continuously in the background without a scheduled task.
Candidates do not separate the definition of a search from its execution schedule. Reports and scheduled searches run at configured intervals against a defined time window, and a saved search by itself does not execute until scheduled or run manually.
What to do instead
Memorize the execution model: a saved search is a stored definition, a scheduled search runs it on a timer, and a report formats results for distribution. When a scenario asks why data is stale or missing, check the schedule interval, the query's time window, and whether the scheduled task is enabled before changing the query.