Use these as a structure, not a script. An interviewer can tell the difference between a memorized paragraph and an answer you can defend, so rewrite each one in your own words and against your own experience before the loop.
Question 1I start by establishing what the alert actually claims: which detection fired, the entities involved — user, host, process, source and destination — and the exact time window in UTC. Then I set severity from context rather than the rule's static score, because a password-spray hit on a disabled account matters far less than one successful MFA prompt approval on a domain admin. Next I corroborate from a second telemetry source: if the alert came from EDR I check identity, DNS, and proxy logs for the same host and window, since single-source alerts are the ones that most often collapse under scrutiny. Then I commit to a verdict — true positive, benign true positive where the activity really happened but was authorized, or false positive where the logic simply misfired. I write down what I inspected and what I ruled out, not just the conclusion, so the next analyst can audit the reasoning instead of redoing it. Finally I act on the verdict: close with a tuning note, contain, or escalate per the playbook, and I record timestamps carefully because time-to-detect and time-to-respond reporting depends on them. Saying those three verdict categories out loud is worth doing in an interview — it signals you have actually worked a queue rather than read about one.
Back to the listQuestion 2An event is any observation a system records: a login, a process start, a firewall permit. An alert is an event, or a correlation of events, that matched detection logic and was surfaced for review. An incident is a confirmed or high-confidence case of adverse security impact — or a credible attempt at it — that requires a coordinated response, and it usually bundles many alerts and thousands of events under one case. The distinction is operational, not academic: events feed retention and hunting, alerts drive the triage queue and tuning metrics, and incidents open a case with an owner, a lifecycle, and communications obligations. Teams that blur the three end up reporting millions of monthly "incidents" and lose credibility with leadership the first time someone asks what that number means. NIST SP 800-61 draws the same line between an event and an incident, so it is a cheap and accurate reference to cite.
Back to the listQuestion 3A SIEM ingests logs and telemetry from across the estate — endpoints, identity providers, firewalls, proxies, email gateways, cloud control planes, SaaS audit logs — parses and normalizes them into a common schema, and retains them so they can be searched together. On top of that store it runs scheduled queries and correlation rules that raise alerts, and it feeds dashboards, case management, and compliance reporting. Its real value is the join across sources: one Okta sign-in from an unfamiliar ASN proves nothing, but that sign-in followed forty seconds later by an inbox rule creation and an OAuth grant is a story. Day to day I use it for three jobs — pulling context around an alert during triage, hunting for behavior nobody has written a rule for yet, and answering scope questions during an incident. I would also name its failure modes, because interviewers listen for them: a silently broken parser disables every detection built on that field, and ingest cost pressure tends to drop exactly the verbose sources you later need. Naming a platform you have actually used and a query language you can read — SPL in Splunk, KQL in Sentinel or Defender, EQL or Lucene in Elastic — makes the answer concrete rather than generic.
Back to the listQuestion 4First I confirm it is genuinely a false positive rather than benign-looking activity I do not understand yet, by sampling several occurrences across different hosts and users rather than judging from one. Then I find the root cause: usually the logic is too broad — matching a process name instead of a parent-child relationship — or a legitimate business process resembles the attack, such as a backup agent touching every file or a vulnerability scanner touching every port. I fix it at the right layer: add context to the detection (specific parent process, service account, source subnet), or scope an exclusion as narrowly as the platform allows, or downgrade the rule to a hunting feed instead of the live queue. What I do not do is exclude broadly — suppressing an entire host, all of PowerShell, or a whole user group creates a blind spot an attacker can walk straight through, and it will not be revisited on its own. Every exclusion gets an owner, a documented reason, and a review date, because unreviewed suppressions quietly accumulate into an invisible detection gap. I would also track rule precision: if a detection's true-positive rate stays near zero after tuning, retiring it is the honest call, since analyst attention is the scarcest resource in the SOC.
Back to the listQuestion 5ATT&CK is a knowledge base of observed adversary behavior organized into tactics — the objective, such as initial access, credential access, or exfiltration — and the techniques and sub-techniques used to achieve them, like T1059.001 for PowerShell execution. In triage I use it to move from an atomic alert to a hypothesis: if I see credential dumping (T1003) on a host, I immediately look backwards for the execution and initial access that preceded it and forwards for lateral movement. In detection engineering it is how coverage gets expressed — mapping rules to techniques exposes which tactics you are blind in — though I would be careful to say that having a rule mapped to a technique is not the same as detecting it well. It also standardizes vocabulary: writing "T1566.001 spearphishing attachment" in a case is unambiguous across teams, vendors, and threat intel reports. The caveats are worth volunteering: ATT&CK skews post-compromise, coverage heat maps create false confidence, and plenty of real activity does not map cleanly to a single technique. If the interviewer wants depth, mention using ATT&CK Navigator layers to visualize coverage or to plan and score a purple-team exercise.
Back to the listQuestion 6I escalate when evidence crosses a threshold the playbook defines rather than when I personally feel uncertain: confirmed malicious execution on an endpoint, any indication of credential compromise or privileged account misuse, lateral movement, data staging or exfiltration, anything touching crown-jewel systems, and anything I cannot disprove inside my triage time budget. The escalation itself should read as a briefing, not a link dump — what happened, which assets and identities are involved, a UTC timeline, what I have already checked and ruled out, any containment already applied, and the specific thing I need from the next tier. I state confidence explicitly, because "high confidence it is real, low confidence on scope" leads a responder to plan very differently than the reverse. I follow the notification path in the IR plan: tier 2 or the IR lead, then the incident commander, with legal, privacy, and communications pulled in early when regulated data or suspected data loss is in play. I would never sit on something because I fear it is nothing — a fast, well-documented escalation that turns out benign costs far less than a delayed real one. I would also be clear on my own containment authority: what I can do unilaterally, such as isolating a host or revoking sessions, versus what needs an approval.
Back to the listQuestion 7Identity logs first — Active Directory, Entra ID, or Okta — because almost every intrusion touches authentication, and they answer who, from where, with what result, and whether MFA was satisfied. EDR process telemetry is next: process creation with full command lines and parent-child relationships is the highest-value endpoint evidence there is, and it is what turns an alert into a story. DNS and proxy or web gateway logs establish outbound behavior — beaconing intervals, newly registered domains, large uploads — even when the payload itself is encrypted. Email gateway logs matter because phishing remains the most common entry point, and they let you scope who else received the same message. Cloud control-plane logs — AWS CloudTrail, Azure activity logs, GCP audit logs — record the API calls that create persistence, change IAM, or open storage, which endpoint telemetry never sees. Firewall and flow data give the coarse network picture and are useful for scoping lateral movement when host telemetry is missing. The honest caveat is coverage: knowing which of these you actually collect, at what retention, and where the gaps are is more valuable than reciting the list.
Back to the listQuestion 8Traditional antivirus is prevention-first and file-centric: it evaluates files and processes against signatures, hashes, and heuristics and blocks or quarantines what it recognizes as bad. EDR is telemetry-first: an agent continuously records process creation, command lines, module loads, file and registry writes, and network connections, ships that history to a backend, and applies behavioral detection over it. For an analyst the practical difference is investigation and response — EDR gives you the process tree and the command line that antivirus never recorded, plus actions like isolating a host, killing a process, retrieving a file, or opening a remote shell. The philosophies differ too: antivirus assumes it can stop the bad thing, while EDR assumes prevention will sometimes fail and makes sure you can reconstruct what happened afterwards. Modern products blur the line by shipping next-gen antivirus and EDR in the same agent, and XDR extends the same telemetry model across identity, email, and cloud. The closing point I would make is that EDR is only as good as its retention and the team's ability to query it — an EDR nobody investigates with is expensive antivirus.
Back to the listQuestion 9I preserve the original first — the .eml or .msg with full headers, or the report from the built-in reporting button — because a forwarded copy loses the headers I need. Then I read the headers: SPF, DKIM, and DMARC results, whether the Return-Path matches the display From, the received chain and originating infrastructure, and whether the sender domain was registered recently or is a lookalike. Next I analyze the payload safely — links resolved in a sandbox or URL analysis service, attachments detonated in a sandbox rather than opened on my workstation — and I extract the observables: sender addresses, URLs, domains, file hashes. Then I scope it in the mail gateway: who else received the same sender, subject, URL, or attachment hash, and did any of it get delivered rather than quarantined. Then I determine impact — proxy and DNS logs show who actually clicked, and identity logs show whether anyone authenticated to the phishing page, followed by anomalous sign-ins, new inbox rules, MFA registrations, or OAuth grants, which is the pattern of a business email compromise. Containment follows: purge the message from all mailboxes, block the sender, domain, and URL, and if credentials were entered, reset the password, revoke active sessions and tokens, and remove any attacker-created rules or app grants. I close by feeding the observables into blocklists and detections, telling the reporting user what happened so reporting keeps feeling worthwhile, and noting whether a behavioral detection would have caught it earlier.
Back to the listQuestion 10An indicator of compromise is a concrete artifact tied to a specific intrusion — a file hash, a C2 domain or IP, a URL, a registry key, a mutex. A TTP describes behavior at a higher level: the tactic is the adversary's objective, the technique is the general method, and the procedure is the specific way that group implements it. The difference matters because of cost to the adversary: recompiling a binary or rotating a domain is free, but changing how they dump credentials or establish persistence costs them tooling, testing, and retraining. That is the point of David Bianco's Pyramid of Pain — hashes and IP addresses sit at the bottom where detection is cheap and brittle, tools and TTPs sit at the top where detection actually hurts the attacker. Operationally I use both: IOCs give fast, high-precision retro-hunts and blocks the moment an intel report lands, while TTP-based detections survive infrastructure rotation and catch the next campaign from the same actor. The answer that lands in an interview is that you sweep IOCs to establish scope immediately, then convert what you learned into a behavioral detection so the same tradecraft is caught next time.
Back to the listQuestion 11I start from the process tree, because the parent is most of the verdict: winword.exe or outlook.exe spawning powershell.exe is a very different story from a systems management agent or an admin's own console session. Then I read the full command line and decode rather than assume — encoded commands, hidden window and execution-policy bypass flags, and download cradles are strong signals, but base64 alone is used by plenty of legitimate tooling. Next I look at what the process did after it started: outbound connections and whether the destination is rare in our environment, child processes, files written to disk, and persistence-shaped changes such as Run keys, scheduled tasks, or services. Then I check prevalence: the same command line on one host suggests targeted or user-triggered activity, while the same line on two hundred hosts usually means a deployment or a script somebody rolled out. I pull the identity angle in parallel — was the session interactive, is the account privileged, and are there unusual authentication events around the same window. If I can confirm attacker-controlled execution, I isolate the host before finishing the analysis, because containment comes first and forensics continues afterwards on an isolated machine. Then I preserve artifacts and record the observables so the same behavior can be detected earlier next time.
Back to the listQuestion 12A handoff is a structured record, not a passing comment: open cases with their current status and named owner, anything mid-containment, alerts I deliberately left in the queue and why, and any tuning or suppression applied during the shift. I include environmental context that changes how the next shift reads the queue — a change window, an authorized penetration test, a noisy deployment, a maintenance job that fires the same detection every night. I state what the incoming shift is expected to do next and by when, and I transfer ownership explicitly so no case sits unowned across the boundary. I am specific about partial work — "I reviewed the proxy logs for host X but not DNS" — because unstated gaps are how findings get silently dropped. The handoff lives in the case management system rather than only in chat, so it is searchable and auditable when someone reconstructs the timeline weeks later. Where shifts overlap I do a short live sync on the one or two items that genuinely need judgment and let the written record carry everything else. Interviewers ask this because failed handoffs are one of the most common reasons a real incident sits untouched for eight hours.
Back to the list 