SOC Analyst Interview Questions and Answers: Model Answers From Tier 1 to Tier 3

SOC interviews test whether you can reason from an alert to a decision under time pressure, yet most question lists online test only definitions. This guide gives the questions hiring panels ask at Tier 1, Tier 2 and Tier 3, with model answers that show the depth expected at each level, plus scenario walk-throughs, the Windows event IDs and ATT&CK techniques candidates are expected to know, and a scoring rubric for interviewers. Answers are vendor-neutral: they describe what to look for and why, not which console button to press. It is for candidates preparing for security operations centre roles and for SOC managers who want a consistent, fair interview. General interview preparation, CVs and offers are covered in the Cyber Security Interview Preparation Guide; the role itself in the SOC Analyst Career Guide.

Key takeaways

• Reasoning beats recall. Panels score how you get from an alert to a decision: what you check first, what would change your mind, and when you escalate.
• Depth rises by tier. Tier 1 answers triage and validate; Tier 2 scopes and contains; Tier 3 hunts, builds detections and explains trade-offs to leadership.
• Know a short list cold. Logon types, key Windows event IDs, common ATT&CK techniques and the incident lifecycle in NIST SP 800-61 Rev. 3 come up in almost every technical round.
• Identity is now the main battleground. Expect scenarios on password spraying, MFA fatigue, Kerberoasting and stolen tokens or service account credentials, not only malware.
• Say what you would not do. Good answers mention evidence preservation, false positive checks and the limits of your authority before acting.

What each tier is tested on

Tier 1 questions and model answers

1. Walk me through how you triage a new alert.

Model answer: "First I read what the rule is meant to detect and check the alert is not a duplicate of an open case. Then I validate it: is the host, user or account real and in scope, and does the raw event match the rule logic? I add context: asset criticality, the user's normal behaviour, recent changes, threat intelligence on any indicators. Then I decide: false positive with a reason recorded, benign true positive, or suspicious, which I escalate with a timeline and the evidence I checked. I note what I did not check." This maps to triage and validation in NIST CSF 2.0 RS.MA-02.

2. What is the difference between event 4624 and 4625, and what is a logon type?

Model answer: "4624 is a successful logon and 4625 a failed one, logged on the machine where the session is created. The logon type tells you how: 2 interactive at the console, 3 network such as a file share, 4 batch, 5 service, 10 remote interactive over RDP, 11 cached interactive. A service account showing logon type 2 or 10 is worth questioning because services should not log on interactively." See How to detect interactive logons by service accounts.

3. You see 200 failed logons in ten minutes. What do you check?

Model answer: "The shape matters. Many failures against one account suggests brute force or a misconfigured service with an old password; one or two failures each against many accounts from the same source suggests password spraying (ATT&CK T1110.003). I look at the 4625 status codes: 0xC000006A is a bad password for a valid account, 0xC0000064 is a non-existent user, which can mean enumeration. Then the key question: is there a success from the same source afterwards? A 4624 after the failures changes this from noise to a likely compromise."

4. What is the difference between an event, an alert and an incident?

Model answer: "An event is anything observable, such as a logon. An alert is an event or pattern a rule flagged as possibly adverse. An incident is declared when adverse events meet the organisation's defined criteria (CSF DE.AE-08) and needs a coordinated response. Not every alert becomes an incident, and the criteria should be written down so analysts are consistent."

5. A user reports a phishing email. What do you do?

Model answer: "Get the original message with headers, not a forward. Check sender authentication results (SPF, DKIM, DMARC), the reply-to, links and attachments in a sandbox or by reputation, never by opening them on my workstation. Then search for other recipients of the same message, check whether anyone clicked or entered credentials, and if so treat it as an account compromise: reset, revoke sessions, review sign-ins and mailbox rules. Then purge the message from mailboxes." See the Phishing Incident Response Playbook.

6. What is a false positive, and how do you avoid closing a real one?

Model answer: "A false positive is an alert where the rule fired but the activity is not what the rule describes. A benign true positive is the activity the rule describes, but authorised, such as an admin running a scanner. I record the evidence for closing, not just the verdict, and I flag rules that produce repeated false positives for tuning rather than silently closing them."

7. Explain TCP versus UDP and name ports you would expect to see.

Model answer: "TCP is connection-oriented with a handshake and delivery guarantees; UDP is connectionless. DNS uses 53 (UDP and TCP), HTTPS 443, SSH 22, RDP 3389, SMB 445, Kerberos 88, LDAP 389 and LDAPS 636. What matters in the SOC is the unexpected: SMB from a workstation to the internet, RDP exposed externally, or DNS to a resolver that is not ours."

8. When do you escalate?

Model answer: "When the evidence meets the escalation criteria in our runbook, when a privileged or service account is involved, when I see signs of spread to a second host, or when I cannot rule out a true positive within the triage time. I escalate early with what I know and what I do not know, rather than late with a perfect write-up." See the SOC Runbook Template.

Tier 2 questions and model answers

9. How do you scope an incident after confirming one compromised host?

Model answer: "Build a timeline from first known bad activity. Identify accounts used on the host and where else they logged on (4624 with logon types 3 and 10 across hosts), processes created (4688, with command line logging enabled through the 'Include command line in process creation events' policy), network connections from EDR or flow logs, and persistence. Pivot on every indicator: hashes, domains, accounts. Scope is complete when new pivots stop finding new hosts or accounts, not when I run out of time."

10. When would you contain immediately, and when would you watch?

Model answer: "Contain immediately when there is active harm or high risk: ransomware behaviour, data leaving, a domain admin or cloud admin credential in use. Watching can make sense for a contained, low-privilege foothold when full scoping matters, because a partial containment tips off the attacker and they move. That is a decision for the incident lead with the business owner, not one I make alone, and I record why."

11. What evidence do you preserve before isolating a host?

Model answer: "Volatile data first if the process allows it: memory, running processes, network connections, logged-on sessions. Then disk or triage collection, relevant logs and EDR telemetry. I record who collected what and when, and hash the outputs. Isolation through EDR usually keeps the host reachable for collection, which is better than pulling the cable."

12. What is Kerberoasting and how would you detect it?

Model answer: "An attacker with any domain account requests service tickets for accounts with service principal names and cracks them offline to recover the service account password (T1558.003). On domain controllers, event 4769 records service ticket requests. Signals are one account requesting tickets for many services in a short time, and tickets issued with RC4 (encryption type 0x17) where AES (0x11 or 0x12) is expected. Prevention is long random passwords or group managed service accounts, and removing unneeded SPNs." See How to find and retire Active Directory service accounts with SPNs.

13. A cloud access key is used from a country you do not operate in. Walk me through it.

Model answer: "Identify which identity owns the key and who owns that identity. Check what API calls were made: reads of secrets, new users or keys created, role changes, data access. If anything is outside the identity's normal pattern, disable the key and rotate it, then hunt for persistence such as new keys or roles the attacker created. Find where the key leaked from, often code, CI logs or a developer machine, and look for other secrets in the same place." See the Cloud Incident Response Guide.

14. How do you write an incident update for executives?

Model answer: "Lead with impact and status in two sentences: what is affected, whether it is contained, what we need from them. Then the timeline, actions taken, next update time. No jargon, no speculation presented as fact, and a clear line between confirmed and suspected."

Tier 3 questions and model answers

15. How do you start a threat hunt?

Model answer: "With a testable hypothesis based on intelligence or a gap: for example, 'an attacker is using valid cloud accounts (T1078.004) from residential proxy ranges'. I define the data needed, check it exists and is complete, run the analysis, and end with one of three outcomes: found activity, found nothing with confidence, or found a visibility gap. Every hunt should leave behind a detection, a documented negative, or a logging fix." See the Identity Threat Hunting Guide.

16. How do you design and test a new detection?

Model answer: "Start from the behaviour, not the tool: which ATT&CK technique, which data source shows it, and what normal looks like. Write the rule, ideally in a portable format such as Sigma, test it against a simulation of the behaviour and against a week of production data to estimate the false positive rate, then document triage steps and an owner. Detections are code: version control, peer review, and regular retesting." See the Detection Engineering Guide and Sigma Rules Guide.

17. How would you measure ATT&CK coverage honestly?

Model answer: "A rule mapped to a technique is not coverage. I count a technique as covered only when a rule has been tested against an emulation of that technique in our environment and fired. I weight by techniques relevant to our threat model, and I report gaps in data sources separately from gaps in rules."

18. Alert volume is overwhelming the team. What do you change?

Model answer: "Measure first: top rules by volume and their true positive rate. Tune or retire noisy rules, add context enrichment so analysts decide faster, automate repeatable steps such as indicator lookups, and group related alerts into one case. Raising thresholds blindly is the wrong fix because it hides the low-and-slow activity."

19. How do you detect misuse of non-human identities?

Model answer: "Machine identities behave predictably, which is an advantage. Baseline each service account, token or key by source, time, API calls and target. Alert on deviations: interactive logons, new source networks, use outside the pipeline, new permissions granted, or a credential used after it should have been rotated. The hard part is ownership: you need to know who to call." See the Detection Engineering for Non-Human Identities Guide.

Scenario walk-throughs panels use

Two public cases make useful practice. In the Uber breach, an attacker with a contractor's password used repeated MFA prompts until one was accepted, then reached other employee accounts. In the Okta support system breach, service account credentials saved in an employee's personal browser profile let an attacker read support files containing customer session tokens, and a customer detected the misuse first. Ask yourself in each case: which alert would have fired, and what would you have done in the first 30 minutes?

Windows event IDs candidates should know

See the Windows Event Log Guide for collection and retention.

Behavioural questions

• "Tell me about a time you made a mistake on an investigation." Panels want ownership, what you changed afterwards, and no blame on others.
• "Describe a disagreement with another team during an incident." Show how you used evidence and escalation rather than argument.
• "How do you handle a night shift with a backlog?" Prioritise by severity and asset criticality, communicate the backlog at handover, flag rules driving it. See the SOC Shift Handover Template.
• "How do you keep current?" Name specific habits: reading incident reports, working through public labs, writing up what you learn.

How to prepare

1. Learn the fundamentals list: TCP/IP and common ports, Windows logon and process events, Kerberos and NTLM basics, email authentication, the incident lifecycle in NIST SP 800-61 Rev. 3.
2. Practise reasoning aloud. Take a public incident write-up and talk through triage, scope and containment in five minutes.
3. Write a query. Be ready to filter, aggregate and join log data in any query language; panels care about logic more than syntax.
4. Know ten ATT&CK techniques well rather than fifty by name: how each shows up in logs and how you would confirm it.
5. Prepare three stories about investigations, mistakes and teamwork, each with a clear outcome.
6. Prepare questions for them: alert volume per analyst, escalation paths, tooling ownership, training time and how detections are tested.

For hiring managers: a scoring rubric

Use the same scenarios and rubric for every candidate at a tier, score independently before discussion, and avoid trivia about one product's interface.

Framework mapping

Common failure patterns

• Reciting tools: naming platforms without explaining what the data shows and why it matters.
• No hypothesis: "I would check the logs" without saying which logs, which fields and what result would mean what.
• Containment without authority: describing shutting down a production server alone, with no mention of the incident lead or business owner.
• Ignoring identity: treating every scenario as malware when the panel's scenario is a valid account or token being misused.
• Overclaiming: inventing an answer instead of saying "I do not know, here is how I would find out". Panels mark honesty up.

Practitioner checklist

• Learn logon types and the seven event IDs in the table above.
• Practise a five-minute triage of a real public incident aloud.
• Be able to explain password spraying, MFA fatigue and Kerberoasting with detection signals.
• Know the incident lifecycle and CSF 2.0 language for respond and recover.
• Write one detection rule and test it in a home lab.
• Prepare three behavioural stories with outcomes.
• Prepare questions about alert volume, escalation and detection testing.
• Interviewers: use fixed scenarios and a written rubric for each tier.

Standards and references

• NIST: SP 800-61 Rev. 3 Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• MITRE ATT&CK: Kerberoasting
• MITRE ATT&CK: Password Spraying
• Microsoft Learn: 4624 An account was successfully logged on
• Microsoft Learn: 4625 An account failed to log on
• Microsoft Learn: 4769 A Kerberos service ticket was requested
• Microsoft Learn: 4688 A new process has been created

Related NHI Mgmt Group resources: SOC Analyst Career Guide · Cyber Security Interview Preparation Guide · SOC Guide · Detection Engineering Guide