Top SOC Analyst Interview Questions & Answers (2026)

I start with the headers: sending infrastructure, reply-to mismatches, and the SPF, DKIM and DMARC results. Links and attachments go to a sandbox, never opened on my workstation. If it is malicious, I scope it: search the mail platform for every recipient of the same sender, subject or URL, then check proxy and DNS logs to see who actually clicked. I purge the message from all mailboxes and block the sender and URL. For anyone who entered credentials, I reset the password, revoke active sessions, and check for new MFA methods, new inbox forwarding rules and suspicious OAuth app consents, which attackers add for persistence. Then I thank the reporter, and document everything in the ticket.

I use it in three ways. First, for detection coverage: mapping our rules to techniques shows where we are blind, for example strong coverage of initial access but little on lateral movement. Second, during investigations: once I confirm one technique, ATT&CK reminds me what usually comes before and after it, so I look for the related steps instead of stopping at the first finding. Third, for communication: tagging incidents and threat intel with technique IDs gives the team a shared language and lets us spot patterns across incidents. I am careful not to treat coverage of a technique as binary, because one rule rarely detects every way a technique can be performed.

CVSS base scores describe severity, not our risk, so I would layer in more context. First, is it being exploited in the wild: anything on CISA's Known Exploited Vulnerabilities catalog goes to the top. Second, likelihood of exploitation, using something like EPSS. Third, exposure: internet-facing systems and those reachable from user networks beat isolated ones. Fourth, asset criticality: domain controllers, identity systems and systems holding sensitive data first. I also look for compensating controls and for single fixes that close many findings, like one browser or OS update. I would agree that logic with the infrastructure team so the list is defensible, and report what risk remains.

I think in the NIST phases. Preparation: playbooks, logging, tooling and access ready before anything happens, so I know my runbooks and escalation paths. Detection and analysis: triaging alerts, confirming the incident, scoping affected hosts and accounts, and building a timeline. Containment, eradication and recovery: isolating hosts through EDR, disabling accounts and blocking indicators, then removing persistence and restoring clean systems with monitoring. Post-incident activity: a lessons-learned review, which often produces new detections or tuning. NIST's current incident response guidance, SP 800-61 Revision 3, frames this inside CSF 2.0, but the analyst's work still follows that flow. Documentation runs through every phase.

Password spraying is one or a few passwords tried against many accounts, to stay under lockout thresholds, so a per-account failure count misses it. On-prem, I would use 4625 failures and count distinct target usernames per source IP over a window, say 30 to 60 minutes, with failure codes like 0xC000006A for a bad password. In Entra ID sign-in logs, I would do the same with error code 50126 for invalid credentials, also grouping by user agent and source. The high-priority version fires when that pattern is followed by a successful sign-in from the same source. I would baseline normal failure volume first, and exclude known systems like misconfigured service accounts, but document those exclusions.