🔍
Triage Judgment Under Volume
A real SOC queue has far more alerts than can all get deep investigation. They're testing whether you can prioritize correctly, not whether you treat every alert identically.
📖
Reading Evidence, Not Guessing
Can you look at a log line or process tree and explain specifically what it shows — versus pattern-matching to "that sounds bad" without being able to justify it?
Knowing when to escalate versus handle it yourself is a core SOC skill — over-escalating floods senior staff, under-escalating misses real incidents.
SOC work lives or dies on case notes — can another analyst pick up your ticket at shift handover and understand exactly where things stand?
Q You have 40 alerts in your queue and 20 minutes before shift handover. How do you prioritize?
A Sort by severity and asset criticality first (a critical alert on a domain controller outranks a medium alert on a test VM), then by anything showing signs of active/ongoing activity versus a stale, already-contained event.
Q An EDR alert fires an IOA for "suspicious PowerShell execution." Walk through how you'd investigate it.
A Look at the full process tree — what spawned PowerShell, what arguments were passed, what it did next (network connection, file write, another process spawn) — a single suspicious-looking line in isolation isn't enough to call it malicious or benign.
Q How do you tell a genuine false positive from an attacker who's just quiet and careful?
A Cross-reference against context — is this expected admin behavior for this host/user, does the timing align with legitimate activity (patch night vs. 3am), and does the destination/behavior match a known benign pattern versus something novel.
Q A vulnerability scan flags a critical CVE on a production server. What's your next step?
A Check whether it's actually exploitable in this environment (exposed to the right network path, the vulnerable service actually running/reachable) before treating the CVSS score alone as the full picture — a finding isn't automatically proof of exploitability.
Q You notice the same low-severity alert firing repeatedly from one host over weeks. What do you do?
A Investigate why it's recurring rather than just dismissing it each time — a repeatedly-triggering low-severity alert can indicate a misconfiguration worth fixing, or early-stage reconnaissance that individually looks harmless.
Q When do you escalate an alert versus handle it yourself?
A Escalate when it involves a critical asset, shows signs of lateral movement or data staging, or is outside your authority to act on (e.g. requires isolating a production server) — otherwise, document and close with clear reasoning.
Q You confirm a host is compromised. What's your immediate action?
A Contain — typically network isolation via EDR — without powering off the machine, which would destroy volatile evidence (memory, active connections) needed for investigation.
Q How do you write a case note so the next analyst on shift can pick it up without re-doing your work?
A State what you found, what you already ruled out (and why), what's still pending, and exactly what the next step should be — vague notes like "looked into it, seems fine" force a full re-investigation.
Q How do you handle a wireless security alert — e.g. a rogue access point detected?
A Confirm it's genuinely unauthorized (not a misconfigured legitimate AP), locate it physically or via signal triangulation if the tooling supports it, and follow the containment process — this often crosses into physical security, not just network.
Q A DR-related alert fires during a scheduled DR drill. How do you avoid a false-alarm panic?
A Check the change/maintenance calendar first before escalating — a well-run SOC cross-references scheduled activity so drills don't trigger unnecessary incident response.
Q Tell me about a time you caught something real that could have been dismissed as noise.
A STAR it: what made the alert look routine at first (Situation), what specifically made you dig further (Action), and the actual outcome (Result) — this question is testing pattern-recognition instinct, not luck.
Q Describe a time you escalated something that turned out to be a false positive.
A Show you're comfortable being wrong when the reasoning was sound at the time — a SOC that punishes reasonable escalations trains analysts to under-report, which is worse.
Q Tell me about handling a high volume of alerts during a busy shift.
A Focus on your prioritization method specifically, not just "I worked through them" — the interviewer wants the decision logic, not the effort.
Q Describe a time you disagreed with a senior analyst's assessment of an alert.
A Show you raised it respectfully with specific evidence, and describe how it was resolved — deferring to seniority without ever voicing a concern is its own red flag in security work.
Q Tell me about a time you had to learn a new tool or platform quickly on the job.
A SOC tooling varies a lot between employers — show a concrete example of ramping up fast on unfamiliar tooling, and what your actual learning process looked like.