An L1 interview mostly checks whether you know the definitions — what is a firewall, what is a false positive, what does SIEM stand for. An L2 interview checks something different: can you actually think under pressure, correlate signals across multiple log sources, make a defensible judgment call with incomplete information, and communicate that decision to people who aren’t analysts. That’s why almost every serious L2 interview leans on scenario-based questions instead of definition questions.
This post collects the scenarios that come up again and again in Security Analyst L2 interviews, with answers structured the way a strong candidate would actually give them — not textbook definitions, but a repeatable thought process you can adapt to whatever scenario you’re actually asked.
How to structure your answers in an L2 interview
Before the scenarios themselves, one tip that matters more than any individual answer: interviewers are grading your process, not just your conclusion. A useful default structure for almost any incident-style answer is:
Identify → Investigate → Contain → Escalate/Communicate → Document.
Say your assumptions out loud, ask a clarifying question if the scenario is genuinely ambiguous (real interviewers respect this — it’s what you’d do on the job), and don’t be afraid to say “I’d check X first, and depending on what I find, I’d branch to Y or Z.” That branching logic is exactly what separates an L2 answer from an L1 one.
1. Alert flood at the start of your shift
Scenario: You start your shift and find 40 unresolved alerts in the SIEM queue, ranging from low to critical severity. The shift-change handover note says two of them are already being investigated. Where do you start?
Answer: First, read the handover notes and open tickets properly — duplicating work someone else already started wastes time and creates confusion. Then triage the remaining alerts using consistent criteria rather than working top-to-bottom: severity, whether the affected asset is business-critical or externally facing, and whether the rule is a known-noisy one that usually turns out benign. Clear the obvious known-noisy false positives quickly so they stop competing for attention, surface anything that looks like a real critical finding immediately rather than waiting until it’s “your turn” to look at it, and only then work systematically through what’s left. The goal is to demonstrate triage judgment, not brute-force speed.
2. True positive or false positive: encoded PowerShell on a finance workstation
Scenario: Your EDR fires an alert for an “encoded PowerShell command” on a finance department workstation. How do you determine whether it’s a true positive?
Answer: Start by decoding the base64 command to see what it’s actually doing — a legitimate scheduled task or backup agent can look suspicious until you read the actual payload. Check the parent process: PowerShell spawned from explorer.exe is very different from PowerShell spawned from winword.exe right after a document was opened. Check the user and login context (is this normal working hours for this user?), any network connections the process initiated, and run the file/script hash through VirusTotal or similar. Finally, correlate with SIEM logs for the same host around the same time — if the decoded command is reaching out to an unfamiliar external IP or domain, that’s a strong signal it’s real. Only after that chain of checks would I call it a true or false positive with confidence.
3. Suspected VPN brute-force followed by a successful login
Scenario: A correlation rule fires: 50 failed VPN login attempts from a single external IP within 10 minutes, followed by one successful login. Walk through your response.
Answer: First confirm the rule isn’t misfiring by checking the raw logs. Then identify whether this is targeted at one account or spraying across many — that changes the story. The successful login after 50 failures is the part that matters most: check whether the login’s source geography and timing are plausible for that user (impossible-travel logic), because a success right after a brute-force burst is a strong indicator the account is now compromised, not just “attacked.” I’d treat the account as compromised until proven otherwise: force a password reset, kill active sessions, and block the source IP at the firewall/VPN gateway. Then hunt for post-auth activity from that session — new mailbox rules, unusual file access, lateral movement attempts — because the real damage, if any, happened after that successful login, not during the failed attempts. Escalate to IR, notify the account owner and their manager, and feed the source IP to your threat intel blocklist.
4. Employee reports a suspicious “invoice” email
Scenario: An employee forwards you a suspicious email with an attachment claiming to be an invoice. How do you investigate it?
Answer: Check the headers first — SPF/DKIM/DMARC results, whether the sender domain matches the display name, and whether the reply-to address is different from the sender. Detonate the attachment and any links in a sandbox (a tool like Any.Run or a similar analysis environment) rather than opening it on a real endpoint. Search mail gateway logs to see if other employees received the same email, and check EDR/proxy logs for that file hash or URL to see if anyone already clicked or opened it. If someone did, isolate that host, force a credential reset for that user, and hunt the environment for the same indicators — hash, domain, sender. Block the sender, domain, and hash at the email gateway and proxy, send a short awareness note to staff who received it, and document the full timeline in the ticket, including what confirmed it as malicious.
5. Ransomware indicators on a server
Scenario: EDR reports mass file renames consistent with encryption, plus a vssadmin delete shadows command, on a production server. What do you do immediately?
Answer: This is a “act first, ask questions in parallel” scenario. Isolate the host from the network immediately through EDR — don’t power it off, since that destroys memory evidence that’s valuable for forensics later. Alert your IR lead and manager right away, even before you’ve fully confirmed scope; ransomware indicators this specific don’t need more validation before escalation. In parallel, identify what else the compromised account/process touched — shared drives, other hosts, backup servers — because ransomware rarely stays on one machine and you need to know how far to isolate. Check that your backups themselves weren’t also touched or are on a segment that could be reached. Preserve logs and evidence for the investigation, and keep communicating status at a steady cadence to stakeholders even when there’s nothing new — silence during a ransomware event causes its own problems. Decisions like paying a ransom are never an individual analyst’s call; your job is containment, evidence, and clear escalation.
6. Repeated small DNS queries from one host (possible tunneling)
Scenario: A threat intel feed flags a domain, and your firewall logs show one host making small DNS TXT record queries to that domain every 60 seconds. How do you assess this?
Answer: That periodicity and record type is a classic DNS tunneling/beaconing pattern, so I’d treat it as suspicious from the start rather than waiting for more confirmation. Check the domain’s reputation and registration age — a domain registered days ago with no real content is a strong signal. Correlate the queries with EDR to identify exactly which process on the host is generating them, and look for other command-and-control indicators around the same timeframe, like irregular TLS certificates or unusual outbound connections. I’d isolate the host, capture a packet capture if the tooling allows it before isolating (useful for later analysis), extract the domain and any related indicators as IOCs, block the domain at DNS and the firewall, and then hunt across the rest of the environment for the same domain or query pattern — beaconing rarely stays on a single host once you look.
7. One workstation RDPing into five other machines
Scenario: Logs show one workstation initiating RDP sessions to five other machines within a few minutes — not normal behavior for that user. How do you respond?
Answer: First check whether this is a real user account or a service account, and whether there’s a legitimate reason — a scheduled patching job, for instance. If there isn’t an obvious explanation, this looks like lateral movement, so I’d check the relevant logon events (event ID 4624 with logon type 3 or 10, and 4648 for explicit credential use) for signs of pass-the-hash or pass-the-ticket activity. I’d contain by disabling the source account and isolating the originating host, then check every machine it touched for signs of persistence — new scheduled tasks, new services, new local accounts. This gets escalated as probable lateral movement rather than treated as an isolated alert, and I’d loop in the network team early since containment may need to happen at the switch level, not just at the endpoint.
8. A noisy correlation rule is burying real alerts
Scenario: A “multiple failed logins” rule is generating 200+ alerts a day, almost all from a legacy application with broken retry logic, and it’s drowning out real alerts. As an L2, what do you do?
Answer: This is exactly the kind of judgment call that separates L2 from L1 — an L1 would keep escalating each one; an L2 is expected to fix the underlying problem. I’d first confirm the pattern really is benign: same source account or application every time, consistent behavior over a long period, no anomalous success-after-failure pattern. Then I’d tune the rule rather than just muting it blindly — exclude the specific known account/application, or adjust the threshold, or add a correlation condition that still catches a genuine brute-force pattern from the same source. I wouldn’t make this change unilaterally: I’d document the justification, set a review/expiry date on the exception, and get sign-off from the SOC lead, since detection tuning affects coverage for everyone. After the change, I’d monitor to confirm the noise actually dropped without losing real detection capability.
9. A junior analyst escalates a vague “critical malware” ticket
Scenario: An L1 analyst escalates a ticket to you labeled “critical malware,” but the ticket has almost no detail and it’s unclear whether it’s actually critical. How do you handle it — both the technical side and the L1?
Answer: I wouldn’t dismiss it or push it back without looking — I’d quickly verify the severity myself using the available data. If it turns out to be lower severity than tagged, I wouldn’t just downgrade it and move on; I’d use it as a short coaching moment, walking the L1 through the specific signals I used to reach a different conclusion so they calibrate better next time. If it genuinely is critical, I’d take it forward without making the L1 feel blamed for escalating cautiously — erring toward escalation is the right instinct for a junior analyst, even when it turns out to be lower severity. This question is really testing whether you can support and develop less experienced analysts, not just whether you can triage alerts yourself.
10. A P1 incident and three SLA-bound tickets at the same time
Scenario: You’re actively working a P1 incident when three low-severity tickets are about to breach their SLA. How do you manage both?
Answer: The P1 stays the priority — a security incident in progress outweighs an SLA clock. But I wouldn’t just ignore the tickets either: I’d take a couple of minutes to quickly triage them, and if any can be closed as known-benign, I’d do that immediately. If I genuinely can’t get to them, I’d delegate to another available analyst if one exists, and proactively tell my shift lead or manager that the SLA breach is happening because of the active P1 — that transparency matters, both to protect yourself and because SLAs should reasonably flex around a real incident, but only if the right people know why. I’d document the reasoning for the delay in each ticket rather than leaving it unexplained.
11. Possible insider data exfiltration before a resignation
Scenario: A DLP alert shows an employee copied 5GB of customer data to a USB drive at 11pm, and HR data shows they’re resigning in two weeks. What do you do?
Answer: This one needs to be handled carefully and discreetly. First, verify the alert is accurate — real data, the employee’s own device, not a shared account. Check whether this volume of data access is normal for their role, and whether there are other unusual indicators around the same time, like access to systems outside their normal scope or logins at unusual hours. What I wouldn’t do is confront the employee myself or make assumptions about intent in the ticket — insider cases are as much an HR/Legal process as a technical one, so I’d escalate immediately through the organization’s insider-threat process, preserve every relevant log with proper chain of custody (this can end up in a legal proceeding), and document only the objective facts, not speculation about motive.
12. What to do with a new threat intel IOC
Scenario: Threat intel shares a new IP address linked to a known APT group. What’s your workflow as an L2?
Answer: I wouldn’t just add it to a blocklist and move on — I’d enrich it first: check its reputation across multiple sources (VirusTotal, AlienVault OTX, IBM X-Force, Cisco Talos), and look at historical passive DNS/WHOIS data for context. Then I’d retro-hunt: search firewall, proxy, and DNS logs across the retention window to see whether that IP has ever actually appeared in our environment. If it has, that becomes a real incident and gets the full IR treatment. If it hasn’t, I’d still proactively add it to the blocklist/watchlist and document it in the threat intel platform with context — source, confidence level, and associated TTPs — so it’s useful for correlation the next time something related comes in. This shows you think about threat intel proactively, not just as another alert source.
13. Mapping an attack chain to MITRE ATT&CK
Scenario: During an investigation you find this chain: a phishing email delivered a macro-enabled document, the macro launched PowerShell, PowerShell downloaded and executed a payload, the payload created a scheduled task for persistence, and the attacker then attempted to dump credentials from LSASS. Map this to MITRE ATT&CK.
Answer: Initial Access — T1566 Phishing. Execution — T1204 User Execution (opening the macro) and T1059.001 Command and Scripting Interpreter: PowerShell. Persistence — T1053 Scheduled Task/Job. Credential Access — T1003.001 OS Credential Dumping: LSASS Memory. I’d also mention why this matters beyond naming techniques correctly: mapping to ATT&CK standardizes how the incident gets reported, highlights which detections and controls need strengthening (in this case, macro execution policy and LSASS protection), and gives you a common language to describe the incident to other teams and to leadership.
14. Writing a five-line executive summary
Scenario: After closing a moderate-severity incident, your manager asks for a five-line summary for leadership. What do you include?
Answer: What happened, in plain language with no jargon. The impact and scope — which systems or data were affected, and what that means for the business, not the technical details. The root cause, in one line. What was done about it and the current status. And finally, what’s being recommended to prevent it from happening again. Leadership doesn’t need CVE numbers or MITRE technique IDs in that summary — they need to understand the business risk and have confidence the situation is contained. Knowing how to translate a technical investigation into that language is a skill interviewers specifically look for at L2, since L1 rarely has to do it.
15. Coordinating with the network team during containment
Scenario: You’ve identified a compromised host that needs to be isolated at the switch level, not just through EDR, because it may have network-level persistence. The network team doesn’t report to you. How do you get this done quickly?
Answer: This is really a communication question wearing a technical costume. I’d reach out through whatever the organization’s incident communication channel is (a bridge call, an incident channel, whatever’s standard), state the urgency and the technical justification clearly and calmly, and hand over exactly the identifying details they need to act fast — MAC address, switch port, IP, VLAN — so there’s no back-and-forth delay. I’d follow up to confirm the isolation actually took effect rather than assuming it did once I’ve asked, and I’d document who authorized and executed the containment and when, since that timeline matters for the incident report afterward. Getting this kind of cross-team cooperation quickly, under pressure, without direct authority over the other team, is exactly the kind of thing L2 interviews are trying to probe for.
Final tips for your L2 interview
A few things that consistently separate strong L2 answers from L1-level ones: show your reasoning, not just your conclusion — interviewers are listening for the “why,” not just the “what.” It’s fine to say “I don’t know that specific tool, but here’s how I’d find out” rather than guessing. Ask a clarifying question if a scenario is genuinely ambiguous, the same way you would on a real shift. And where you can, connect your answer back to something you’ve actually done — a real triage decision, a rule you tuned, an incident you helped close — because concrete experience is far more convincing than a memorized framework.
If you’re working toward an L2 role and want structured, hands-on practice with these exact scenarios — alert triage, SIEM correlation, incident response workflows — rather than just reading about them, the Security Operation Center course on this site walks through them with real labs.