If any of these felt shaky, the concept guides will fix that: the SIEM architecture guide covers the pipeline, and the SIEM tools guide covers how products differ. Then practise expressing detections on the labs.
Interview prep
SIEM interview questions, platform-agnostic.
These questions test whether you understand SIEM as a concept, independent of any one product. They come up for SOC analyst and SIEM engineering roles alike. Answer them well and you show you can move between tools rather than depending on a single console.
Fundamentals
Do you know what a SIEM is for?
In one sentence, what does a SIEM do?
It centralises log data from across an environment, normalises it, runs detections to find suspicious patterns, and surfaces the results as alerts, dashboards, and reports. The follow-up is usually to expand each stage — collection, normalisation, correlation, output — so know that pipeline cold.
Why normalise data instead of searching raw logs?
Because the same idea — a user, a source address, an action — appears under different names in every vendor's logs. Normalising maps them into common fields so one detection works across many sources. Without it you would rewrite the same logic per device and coverage would silently fragment.
What is the role of retention in a SIEM?
Retention decides how far back you can investigate and report. Too short and you cannot prove what happened during an incident or meet compliance needs; too long and storage cost balloons. Setting retention is one of the central design trade-offs, often tiered by data importance.
Use cases & correlation
Can you turn a threat into a detection?
What is a correlation rule? Give an example.
A correlation rule joins multiple events into a meaningful pattern. For example: many failed logins followed by a success from the same source, followed by access to a sensitive resource. Any one event is unremarkable; together they suggest a compromised account. The skill is knowing which combinations signal trouble.
How would you build a use case for detecting brute-force attacks?
Define the behaviour (a threshold of failed authentications per account or source in a window), decide the data source (authentication logs), write the detection, then test it against real data to set a threshold that catches attacks without flooding analysts. Finish by documenting how an analyst should respond when it fires.
Tuning & metrics
Can you keep a SIEM healthy?
A detection is generating too many false positives. What do you do?
Look at what the false positives have in common — a service account, a scanner, a normal business process — and refine the rule to exclude that legitimate behaviour, ideally with an allowlist rather than by weakening the core logic. Re-test, and document why the exclusion is safe so the next analyst understands it.
What metrics show a SOC is working well?
Common ones are time to acknowledge and time to resolve alerts, the false-positive rate, and detection coverage against a framework like MITRE ATT&CK. The point of metrics is to drive improvement, not to look busy — a good answer notes that you watch trends rather than chase a single number.
Go deeper