Security Analyst interview questions, with worked answers

How to use these questions

Many questions are small cases. Think out loud: say what you would check, in which order and why, and what would change your mind. Interviewers care more about a calm, ordered approach than about naming every tool. Where you have done it before, add a short real example without confidential details.

What a security analyst is expected to know

• Tools: a SIEMSearch and correlate logs in a SIEM, tune detection rules, and tell a real alert from noise. to search logs and handle alerts, and EDRRead what an endpoint tool saw on a laptop or server, isolate a machine, and collect evidence. to see and act on endpoints.
• Systems: networkingProtocols, ports, DNS, proxies and firewalls well enough to read network logs and traffic., WindowsWindows events, Active Directory and group policy: where most office attacks leave traces. and Active Directory, LinuxFind your way on a Linux server: processes, users, logs and what an attacker would change., and cloud logs from platforms such as AzureCloud sign-in and activity logs, identity risks and the security settings of a cloud tenant..
• Method: incident handlingRun an incident from first alert to closure: contain, communicate, recover and record. and incident response, threat intelligenceUse reports on attackers and their methods to decide what to look for and what to block. and the MITRE ATT&CK framework, a public catalogue of attacker techniques.
• Automation and evidence: some PythonShort scripts to parse logs, call tool interfaces and automate repeated steps of triage. or PowerShellRead attacker scripts and write small ones for Windows checks and evidence collection., and the basics of digital forensicsPreserve and examine evidence from disks, memory and logs so that the findings hold up later..
• People: clear notes and callsWrite an incident note that a manager understands and an engineer can act on, under time pressure. during an incident.

The tools are named in ads side by side and none is a must everywhere: Splunk, Microsoft Sentinel, QRadar or Elastic as SIEMs, CrowdStrike, SentinelOne or Microsoft Defender on endpoints, and Wireshark for network captures. What interviewers test is how you think with them.

Alerts, triage and first response

Walk me through how you triage an alert from the SIEM.

What they check: an ordered method, not a guess.

Short answer: "A security operations centre, the SOC, gets many alerts, so triage means deciding quickly how serious each one is. I read what the rule detected, check the user, device and time, look for related events before and after, and compare with what is normal for that user. Then I close it as harmless with a reason, or open an incident and escalate."

The full answer: Context decides: the same sign-in from abroad is normal for a travelling salesperson and alarming for a server account. Record every step, so the next analyst sees why you decided as you did. If the rule fires often for harmless reasons, note it for tuning.

A weak answer: "I close it if the user is in IT." Follow-up: "The alert is for the CEO's account at three in the morning." Say what you check first.

How do you deal with false positives without missing real attacks?

What they check: that you tune rules carefully and measure the effect.

Short answer: "A false positive is an alert that fires on harmless activity. I find the pattern behind the noise, then narrow the rule with an exception that is as small as possible, such as one service account on one server, and I check afterwards that the rule still catches the attack it was written for."

The full answer: Too many false positives cause alert fatigue, and then real alerts get missed. Tuning should be reviewed by a second person and recorded. Removing a rule completely is the last option.

A weak answer: "I turn the noisy rules off." Follow-up: "Your exception hides an attacker who uses that service account." Say how you would notice.

A user reports a phishing email and admits they clicked the link. What do you do?

What they check: a full phishing response, quickly.

Short answer: "I thank the user, then check what the link did: a fake sign-in page or a download. If they entered a password, I reset it and end their sessions; if something was downloaded, I check the laptop in the EDR and isolate it if needed. Then I search for the same email in other mailboxes and remove it, and block the sender and the link."

The full answer: Check the sign-in logs for use of the account after the click, from new places or devices. Each indicator of compromise, a trace of the attack such as an address, a domain or a file fingerprint, goes into the blocklists and into a search across all logs.

A weak answer: "I tell the user to be more careful." Follow-up: "Ten people got the same email and three clicked." Say how you would scale the response.

The EDR flags ransomware-like behaviour on a file server at night. What are your first steps?

What they check: speed, containment and escalation.

Short answer: "Ransomware encrypts files and spreads, so minutes matter. I isolate the server through the EDR, escalate at once to the incident lead or on-call manager, and look for the account and machine that started it. I do not switch the server off, because memory may hold evidence."

The full answer: Check other machines for the same behaviour, disable the account used, and protect the backups. Follow the playbook and keep a timeline from the first minute; it will be needed for recovery and possibly for reports to authorities.

A weak answer: "I wait for the morning team." Follow-up: "Isolating the server stops the night production run." Say who decides.

When do you escalate an alert, and to whom?

What they check: that you know your limits and your SOC's tiers.

Short answer: "Many SOCs work in tiers: tier one checks alerts, tier two investigates, tier three handles major incidents and hunting. I escalate when the playbook says so, when I see signs of real compromise, when important systems or data are involved, or when I am unsure. Early escalation is cheaper than a late one."

The full answer: A good escalation says what was seen, what was checked, what was done and what is needed, in a few lines. Know the paths for after-hours escalation before you need them.

A weak answer: "Only when I am sure it is an attack." Follow-up: "You escalated and it was harmless." Say whether that was a mistake.

Playbooks, intelligence, logs and hunting

What is a playbook, and how would you improve one that analysts keep skipping?

What they check: that process serves the analyst, not the reverse.

Short answer: "A playbook is a written set of steps for a type of incident, such as phishing or a lost laptop. If people skip it, it is too long, out of date or does not match the tools. I would ask the analysts which steps they skip and why, cut it to what matters, and automate the repeated lookups."

The full answer: Test a playbook in a short exercise before an incident tests it for you. Keep an owner and a review date on each one.

A weak answer: "I would remind them to follow it." Follow-up: "Automation could close some alerts with no human." Say where you would allow that.

How do you use threat intelligence and the MITRE ATT&CK framework in daily work?

What they check: that intelligence leads to action.

Short answer: "Threat intelligence tells me which attackers and methods matter to our sector. MITRE ATT&CK, a public catalogue of attacker techniques, lets me map our detections to those methods, see where we have no coverage, and describe an incident in shared terms."

The full answer: A feed of indicators is useful only if it is relevant and fresh; methods change less often than addresses. Use reports on recent campaigns to start hunts and new rules.

A weak answer: "We import every feed we can find." Follow-up: "Which technique would you add a detection for first?" Explain how you would choose.

Which log sources matter most, and what would you do if one stopped sending?

What they check: that you know where attacks leave traces.

Short answer: "Identity and sign-in logs, endpoint data from the EDR, email, firewall and proxy logs, cloud activity logs and the logs of key servers. A source that stops sending is itself an alert: it may be a broken connector or an attacker covering tracks, so I check both and tell the owners."

The full answer: Watch the volume of each source over time. Know which detections depend on which logs, so a gap can be judged quickly.

A weak answer: "We collect everything." Follow-up: "The budget allows half your log volume." Say what you would keep.

How do you hunt for threats that the tools did not alert on?

What they check: curiosity with a method.

Short answer: "Threat hunting starts from a question, such as whether attackers use a known technique in our network. I search the logs for its traces, look at unusual behaviour around it, and either find something or turn the search into a new detection rule."

The full answer: Write each hunt down: the question, the data, the result. A hunt that finds nothing still improves the rules and shows where logs are missing.

A weak answer: "I scroll through the logs." Follow-up: "You find an old admin account that signs in weekly." Say what you do.

A critical vulnerability is published for a product we use. What is the SOC's part?

What they check: the line between finding attacks and fixing weaknesses.

Short answer: "Patching belongs to the system owners, but the SOC helps: we find where the product runs, watch for signs of exploitation, add detections if the vendor or intelligence gives indicators, and check whether we were attacked before the patch."

The full answer: Work with the vulnerability management team on priority: exposed to the internet and actively exploited goes first. Keep watching after patching, because attackers may already be inside.

A weak answer: "That is not our job." Follow-up: "The system cannot be patched for a month." Say what you would watch.

Evidence, cloud, handover and reporting

How do you preserve evidence for forensic analysis?

What they check: care with evidence that may be needed later.

Short answer: "I collect the most volatile data first, such as memory and running processes, then disk images and logs, with times and hashes, and record who handled what. I work on copies and keep the originals untouched, because forensic findings may be used in court or by insurers."

The full answer: Know the tools your team uses for collection and the limits of your role; large cases often go to specialists. Clocks matter: note time zones in every record.

A weak answer: "I reboot the machine to clean it." Follow-up: "The laptop belongs to a manager who wants it back today." Say what you would say.

What would you look for in cloud and identity logs after a suspicious sign-in?

What they check: that you follow an attacker beyond the first event.

Short answer: "I check where and from which device the sign-in came, whether the second factor was passed or bypassed, and what the account did next: new mail rules, new app consents, access to files or changes to other accounts. In the cloud I look for new keys, roles or resources."

The full answer: Identity is often the real perimeter now. Disable or reset the account if needed, revoke sessions and tokens, and check for persistence that would let the attacker come back.

A weak answer: "If the password was right, it was the user." Follow-up: "The user is on holiday." Say what that changes.

How do you hand over an open incident at the end of your shift?

What they check: that nothing is lost between people.

Short answer: "I write a short handover: what happened, what we know and do not know, what was done, what is pending and who is waiting for what. If it is serious I hand over in a call as well, and I stay until the next person has taken it."

The full answer: A shared incident record with a timeline is better than notes in chats. Keep the same structure every time so nobody has to guess.

A weak answer: "They can read the tickets." Follow-up: "The next shift is short of people." Say what you would do.

After an incident, how do you run a lessons learned review?

What they check: learning, not blame.

Short answer: "Soon after closing, the people involved go through the timeline: what happened, how we detected it, what slowed us, what worked. We agree a few actions with owners and dates, such as a new rule, a missing log or a playbook change, and follow them up."

The full answer: Ask how detection could have been earlier and containment faster. Share a short version with the wider company where it helps others spot the same thing.

A weak answer: "We close the ticket and move on." Follow-up: "The cause was a mistake by a colleague." Say how you write that up.

How do you write an incident report for management, and why do reporting deadlines matter for your notes?

What they check: clear writing and awareness of the rules around incidents.

Short answer: "The report starts with what happened, the impact, what was done and what is still open, in plain words, then the timeline and details. The law may give the company only hours or days to report a serious incident, so exact times and facts in my notes help the people who decide."

The full answer: In the EU, the NIS2 directive asks firms it covers for an early warning within a day and the GDPR for personal data breaches within seventy-two hours where feasible; other places have their own clocks. The analyst does not decide whether to report, but the record makes a correct decision possible. This is not legal advice.

A weak answer: "I copy the technical logs into the email." Follow-up: "Management asks whether customer data was taken, and you do not know yet." Say how you answer.

How would you measure whether a SOC is getting better?

What they check: a senior view of the whole team.

Short answer: "I look at the mean time to detect and the mean time to respond, how many alerts turn out real, how much of the attacker playbook our rules cover, and how often incidents repeat. I also watch the analysts' workload, because tired people miss things."

The full answer: Numbers can be gamed: closing alerts fast is not the same as closing them well. Sample closed alerts for quality, and run exercises to test the team on a realistic attack.

A weak answer: "Number of tickets closed per analyst." Follow-up: "Leadership wants one figure for security." Say what you would offer.

Your CV for these questions

Each job on your CV invites the questions above: which tools, which incidents, what you found and what changed. Give those stories a line each, written so a SOC lead wants to hear more:

Check your CV against a security analyst job you want with the free score; any area it finds thin is the one to rehearse first, with a real case told without confidential details.