Cybersecurity Analyst Interview Questions and Answers
A security analyst interview is mostly one question asked six ways: here is something suspicious, what do you do first? The candidates who struggle are rarely short on knowledge. They start acting before they have established what they are looking at, and the panel hears it immediately.
Quick Answer
- Work out which seat you are interviewing for. Monitoring, incident analysis and detection get different questions under one title
- Triage answers are scored on order: validate, context, still live, spread, then decide
- Containment and eradication are separated on purpose. Collapse them and the follow-up catches you
- Name frameworks precisely. ATT&CK is tactics and techniques, not a maturity score
- The behavioural questions are about escalation under uncertainty — wrong loudly versus right silently, at 3am, alone
Which Seat You Are Interviewing For
Job titles here compress badly. "Security Analyst" covers a monitoring seat that works a queue all shift and a detection role that never opens one, and plenty of postings say Tier 1 while describing Tier 2 work. Three tells: a queue or shift cover means monitoring; scoping and on-call incident ownership means Tier 2; rules, tuning or a query language means detection.
| Seat | What the interview digs into | The answer that sinks it |
|---|---|---|
| Tier 1 / monitoring | Triage order, escalation criteria, ticket content, handover | Definitions with no order of operations behind them |
| Tier 2 / incident analysis | Scoping, host and log analysis, containment calls, evidence | Reaching for containment before establishing scope |
| Tier 3 / detection engineering | Writing and tuning detections, data sources, what a rule misses | Talking about tools where the question was about telemetry |
| Incident responder / on-call owner | One incident end to end, stakeholder pressure, handover | A story made of events, with no decisions in it |
| SOC lead | What you would change about a queue you inherited | Metrics with no decision attached |
Triage: The Order Is the Answer
"Walk me through how you would triage this" is the load-bearing question of a SOC interview, and it is not asking for steps. It is asking for a sequence, and for the reasoning behind it. An answer that opens with an action — "I would isolate the host" — and one that opens with a check sit a level of seniority apart.
- Confirm the alert is telling the truth. Open the raw event, not the summary — a detection titled "Credential Dumping Detected" often means a command line contained a string that also appears in a credential-dumping tool.
- Establish the asset and the identity. Criticality and account ownership move priority far more than the severity field: the same alert on a build agent and on a domain controller are two tickets with two clocks.
- Establish whether it is live. Process still running, session still open, connection still up? "Happening now" outranks "higher severity, finished last Tuesday", and severity fields do not encode that.
- Establish spread. Does the same command line, indicator or account appear elsewhere, and in what window? Tier 1 candidates skip this, and it decides whether you hold a ticket or an incident.
- Decide, and write down why — because the next analyst inherits your conclusion, not your reasoning.
They also listen for what you do when the data cannot answer the question. Naming the gap and requesting the log source is correct analyst behaviour, and an uncommon answer. Guessing is the common one.
Containment, Eradication and the Question Between
These words get separated on purpose, because candidates collapse them and the collapse is expensive in real life.
| Phase | The goal | What it looks like | Their follow-up |
|---|---|---|---|
| Containment | Stop it getting worse | Isolate the host, disable the account, revoke live sessions and refresh tokens, block a domain or hash | "What does isolating cost you?" |
| Eradication | Remove the adversary's access | Delete the implant, remove persistence — scheduled tasks, services, run keys, OAuth grants — close the way in, rotate exposed credentials | "How do you know you got all of it?" |
| Recovery | Return to service without reinfecting | Rebuild rather than clean, restore to a known-good point, watch the asset with extra detection | "Watching for what, and for how long?" |
Containment destroys evidence and tips your hand: isolating a host kills volatile state you may want and tells the adversary they have been seen. Often that is the right trade, but not automatically, and the senior answer names the trade-off and then names who owns the call — usually an incident commander, not the analyst who found it. Eradicating before scoping is the other classic error: clean host A while host B still has a foothold, and reusing it is the cheapest next move available.
The credential step is the one candidates forget. A password reset that does not invalidate existing sessions, refresh tokens or application passwords leaves exactly the access it was meant to remove. Say that unprompted and you will likely be the only candidate that day who did.
Expect the trap version: "you isolated the host and deleted the malware — is it over?" No: persistence may sit on assets nobody has looked at, harvested credentials are still valid wherever they are accepted, and the access path is open until someone closes it.
The Frameworks You Will Be Asked to Name
MITRE ATT&CK
ATT&CK is a knowledge base of adversary behaviour, organised as tactics — what the adversary is trying to achieve — with techniques and sub-techniques underneath describing how. The Enterprise matrix currently lists fifteen tactics, Reconnaissance to Impact, and two are recent: in v19, released April 2026, the long-standing Defense Evasion tactic (TA0005) was renamed Stealth, for behaviour that hides by looking normal, while a new tactic, Defense Impairment (TA0112), covers techniques that break or disable defensive tooling outright. Nobody will fault you for saying "defense evasion", but knowing why the two were split says you read release notes — which for a detection role is the job.
MITRE ATT&CK Enterprise tactics, attack.mitre.org — content v19.2, released 6 August 2026; Stealth (TA0005, previously Defense Evasion) and Defense Impairment (TA0112, created 14 April 2026) as listed there. Checked 26 September 2026.
What lands badly is a coverage percentage: a count of techniques with a rule attached is not a measure of what an adversary could do in your environment. Talk instead about the techniques where you had no data source at all.
NIST SP 800-61
Be precise about which edition you mean. Revision 2, the Computer Security Incident Handling Guide from August 2012, is the source of the four-phase lifecycle everyone quotes: preparation; detection and analysis; containment, eradication and recovery; post-incident activity. It was withdrawn in April 2025 and superseded by Revision 3, which reframes incident response as a Cybersecurity Framework 2.0 Community Profile; NIST's own framing is that all six CSF 2.0 Functions play a part in incident response.
NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management: A CSF 2.0 Community Profile, April 2025, superseding SP 800-61 Rev. 2 (August 2012), withdrawn 3 April 2025 — csrc.nist.gov.
Most interviewers still mean the four phases, so answer with them and add one sentence about Revision 3. Name the Cyber Kill Chain too and expect "how is that different from ATT&CK?" — the safe distinction being that ATT&CK catalogues observed behaviours rather than a sequence you walk in order.
Detection Engineering Questions
Detection questions come verbally, with no console, and the interviewer wants a shape: the behaviour, the data source, the baseline, the logic, what it misses. This is where "I have used Splunk" is least useful as an answer.
Strong — behaviour first, honest about the gap
"The behaviour is group enumeration from a host with no business doing it. The data source is process creation with the full command line — Windows event 4688 with command-line auditing on, or the equivalent EDR process event — plus directory-service query logging if we have it. The baseline matters more than the rule: on a helpdesk workstation this is a Tuesday, on a finance laptop it is not, so the asset group belongs in the condition. What it misses is anything that does not shell out, since the same enumeration through an LDAP or .NET call leaves no net.exe behind — so I would want a directory-query detection alongside it, and say so rather than claim one rule covers the technique."
Every detection interview has a noisy-rule question, and the wrong answer is any version of turning it off. They want narrowing: find what made the benign cases benign — one service account, a parent process path, a scheduled window — exclude that and only that, record why, attach a review date. Then say the uncomfortable half out loud: every exclusion is a hole, and one nobody reviews is permanent.
If the posting mentions detection-as-code, the conversation goes there. Sigma is an open, vendor-agnostic YAML format for log-based detections, converted into the query language of whichever platform you run, so you can discuss logic without leaning on one vendor's syntax. That a rule went through a pull request, a review and a test case is worth more than naming the platform.
Sigma — an open signature format for log events; rules written in YAML, converted into platform-specific SIEM queries. github.com/SigmaHQ/sigma.
SIEM, EDR and SOAR Without the Vendor Trap
Overclaim and you will be asked to describe a workflow you have never run; undersell and a screener filters you first. Answer in categories, then place yourself honestly inside them.
- SIEM — central collection, normalisation, correlation, search and retention of logs. The interesting question is never "which SIEM"; it is "an alert should have fired and did not — why?" The answer that impresses is boring: check the log source is still shipping and no parser broke, before questioning the rule.
- EDR — host-level telemetry (process, file, registry, module and network activity from the endpoint's own point of view) plus response actions such as isolating a host. Questions turn on the gap between what the network saw and what the host did.
- SOAR — automation of enrichment, ticketing and standard containment steps. Asked what you would automate: enrichment and evidence collection freely, and a human in the loop for anything that takes a person or a system offline.
Then say what you have actually done. "I have written searches and worked the queue; I have not onboarded a log source" is a strong Tier 1 answer and a credible Tier 2 one.
One Scenario, Answered Badly and Well
Scenarios carry more weight here than in most technical hiring, because the job is largely deciding from incomplete evidence on a clock.
"It is 02:10. EDR raises a suspicious-PowerShell alert on a laptop belonging to someone in Finance, in their local small hours. The command line is base64-encoded. You are on the queue alone and the Tier 2 on-call is asleep. What do you do?"
Weak — action before understanding
"I would isolate the machine straight away and escalate to Tier 2, then run an antivirus scan and reset the user's password to be safe."
It isolates a finance laptop mid-close without establishing that anything happened, treats a scan as an analysis step, preserves nothing, and hands Tier 2 a blank page.
Strong — same tools, different order
"First I decode the command line, because base64 is not evidence on its own; plenty of legitimate management tooling encodes commands. Then the parent process, which is most of the answer — Word or Outlook spawning PowerShell is a different incident from a management agent doing it. Then whether it is still running, and whether it made outbound connections and to where. Then I search the estate for that command line over the past week: on two hundred hosts it is almost certainly a management script, on one host it is not."
"If it decodes to a download-and-execute from an external host and the parent is a mail or document application, that is containment territory — isolate through EDR while keeping the management channel, disable the account and revoke its live sessions and refresh tokens, and preserve the process tree and volatile artifacts before anyone reboots anything. Then I wake Tier 2 with a written scope: what fired, what I confirmed, what I could not. If instead it matches a known internal script with the right parent, I close it as a benign true positive and write up the tuning."
The second answer is not more knowledgeable, and it can end in the same containment. The difference is order, plus two things the weak answer never mentions: a decision about what to preserve, and an escalation that arrives with a scope attached.
Note where that scenario came from: one responsibility line. "Monitor EDR alerts across corporate endpoints and escalate per the on-call runbook" produces the 02:10 question, the parent-process follow-up and the escalation-scope follow-up, in that order. Identity tooling in the same posting would produce a token-theft scenario; a cloud platform, an exposed key; a phishing-volume line, a mailbox rule. Our guide to preparing from the job description covers pulling those lines apart.
The Behavioural Questions That Differ Here
The panel is not checking whether you collaborate well. It is checking whether you will make a call you are unsure about, at an hour when nobody is watching, and then tell someone senior something they do not want to hear.
- "Tell me about a time you escalated something that turned out to be nothing." Not a confession — they are checking you will escalate under uncertainty at all. Answer with the criteria you used, and with what you changed afterwards: usually attaching a confidence level, so the person you woke knows how hard to run.
- "Tell me about something you missed." What you missed, how it was caught, what changed in the process. "I am more careful now" is not an answer; "we added the log source that would have shown it, and a check at handover" is.
- "How do you work an incident at 3am when you are the only one on?" They want a written order of operations and a threshold for waking someone — ideally a time box, after which you escalate with what you have.
- "A senior engineer does not believe their server is compromised." Analysts spend their careers delivering inconvenient conclusions on partial evidence. Answer with the evidence you would show, what you would ask them to check themselves, and the point at which you stop persuading and escalate.
These want a STAR-structured delivery with one adjustment: the Result is what changed in the process, not what happened to the incident. Note too that offensive questions arrive turned around in a defensive interview — not "how would you do this", but "what would this look like in the logs". If a previous round went badly with no explanation, our breakdown of why interviews fail covers the reasons candidates rarely hear.
Frequently Asked Questions
What questions are asked in a cybersecurity analyst interview?
Three clusters. Triage: walk me through how you would handle this alert. Incident response: how far did it spread and how do you know. Detection: how would you detect this behaviour, and what would your rule miss. The behavioural questions focus on escalation under uncertainty, on-call, and telling people things they do not want to hear.
What is the difference between containment and eradication?
Containment stops the incident getting worse — isolating a host, disabling an account, revoking live sessions, blocking a domain. Eradication removes the adversary's access: deleting implants, removing persistence, closing the way in, rotating exposed credentials. Containment buys time; eradication ends it. Eradicating before you have scoped the incident is how it comes back.
How do I answer "how would you triage this alert"?
Give an order, not a list. Confirm the alert fired for the reason it claims by reading the raw event. Establish the asset and the user. Establish whether the activity is still live. Establish whether it appears anywhere else. Then decide — close, tune or escalate — and say what made you decide.
What is a benign true positive?
A false positive means the detection was wrong: the activity it reported did not happen. A benign true positive means the detection was right and the activity was authorised — the admin really did run that command. They close differently, and only one is a reason to change the rule. Interviewers use the difference to spot real queue experience.
How much MITRE ATT&CK do I need to know for a SOC interview?
Enough to use it correctly: tactics are what the adversary is trying to achieve, techniques are how. Be able to map an alert you have worked to a technique and say which data source would catch it. Avoid quoting a coverage percentage — a count of techniques with a rule attached is not a measure of what an adversary could do.
How should I answer a question about a SIEM or EDR I have not used?
Name the category, describe what you have actually done, and mark your own confidence. "I have written searches and worked the queue, I have not onboarded a log source" is a strong Tier 1 answer and a credible Tier 2 one. Overclaiming fails on the second follow-up, when they ask you to describe the workflow.
What should I ask at the end of a SOC analyst interview?
Ask about the shape of the work: how the rota is covered overnight, roughly how many alerts reach a human per shift, who you wake at 3am and by what route, whether handover is written, and whether analysts can change detections or must file a request. Asking these signals you have run a queue.
Next Steps
You do not need another hundred security definitions. You need your posting, an evening, and five answers you can still defend when the panel keeps pulling.
If the first conversation is a recruiter call, our phone screen guide covers that stage, and final round interview questions covers what changes once the technical bar is cleared.
Related resources: Software Engineer Interview Questions | Prepare Using the Job Description | STAR Method Complete Guide