25 SOC Analyst Interview Questions with Sample Answers

Prepare for a SOC analyst interview by practising how you investigate an alert, explain your evidence and decide what to do next. You'll also need the network, identity and operating-system fundamentals that make those decisions possible.

The questions below cover technical knowledge, investigation scenarios and communication, with extra follow-ups for experienced roles. The sample answers and log exercise are illustrative practice material. Adapt them to your own experience and the job description; they're not a list of questions supplied by a particular employer.

Choose the questions that fit your interview

For a junior or L1 role, start with the fundamentals and the scenarios. Practise finding the right evidence, writing useful notes and recognising when you need help. For an experienced role, add examples of improving detections, investigating across systems and handling uncertainty during an incident. Tier names vary between employers, so check the responsibilities rather than relying on the title.

Read the question, hide the answer and say your response aloud. Then check whether you explained what you would examine and how the findings would affect your decision. A list of tools is less useful than an example of what you would do with one.

If you're still choosing a role, compare the responsibilities in current SOC analyst jobs. Our SOC analyst career guide also covers the broader career path.

Technical SOC analyst interview questions

1. What does a SOC analyst do?

A SOC analyst reviews security signals, investigates suspicious activity and helps the organisation respond. That includes understanding the affected user or system, checking related evidence, recording a conclusion and escalating or taking response actions within the team's procedures.

For an interview answer, connect that work to a concrete example: “If an alert flags a suspicious sign-in, I'd examine the authentication result, device, source and related activity before deciding whether it needs escalation.” Then explain which parts you've done in a job, a course or a lab.

The business impact matters too. Unauthorised access threatens confidentiality, altered records threaten integrity, and a disrupted service threatens availability. An analyst's priorities should reflect what is at risk.

2. What's the difference between an event, an alert and an incident?

An event is an observable occurrence, such as a login attempt. An alert brings activity to an analyst's attention because it matches detection logic or another warning condition. An incident involves a security impact or threat that meets the organisation's incident criteria.

One incident can generate many alerts, and an alert doesn't establish the whole incident by itself. You might investigate a failed-login alert and find a forgotten service-account password. Or you might find a successful unauthorised login that needs a coordinated response. Explain the evidence that separates those conclusions.

3. How do SIEM, EDR and SOAR work together?

You could explain the connection like this: “I'd use the SIEM to understand related activity, the EDR to examine the endpoint, and an approved automation to collect context or route the case.” Product boundaries overlap; Microsoft's EDR and XDR explanation also describes how these capabilities fit together.

Be ready for IDS versus IPS as a follow-up. Intrusion detection identifies suspicious activity; intrusion prevention can also attempt to stop it. Neither a network sensor nor a host sensor provides complete visibility on its own. NIST's IDPS guide covers both approaches.

4. What are true positives, false positives and false negatives?

If the question means detecting malicious activity, a true positive correctly identifies it. A false positive flags benign activity as malicious, while a false negative misses malicious activity.

Check what the detection was designed to identify. A rule for encoded PowerShell might correctly detect an approved administrative command. Some teams call that a benign true positive: the behaviour occurred, but the investigation found no malicious activity. Distinguish that from a parser or rule error that reported something which didn't happen.

A useful answer explains the consequence: false positives consume investigation time; false negatives leave activity undetected. Closing more alerts doesn't, by itself, show better detection.

5. How do TCP and UDP differ, and what is the TCP handshake?

TCP provides an ordered byte stream with mechanisms for reliable delivery. UDP sends datagrams without providing TCP's connection setup, ordering or retransmission guarantees; an application can implement additional mechanisms itself. See the TCP specification and UDP specification.

The usual TCP connection setup is SYN, SYN-ACK, ACK. In an investigation, you could use connection state and the surrounding traffic to distinguish an attempted connection from an established one.

Know familiar port associations, such as SSH on 22 and HTTPS on 443, but don't treat the port number as proof of the application or its intent. Explain how you'd confirm what the traffic represents.

6. Why are DNS logs useful in an investigation?

DNS resolves names to records, including addresses. A resolver can answer from cached information or obtain an answer through other name servers. RFC 1034 describes these concepts.

DNS records can help you ask which device queried a domain, when it did so and whether other devices queried it too. You would then correlate that with endpoint and network activity. A lookup alone doesn't prove that a connection succeeded or that a file was downloaded.

For a domain with unusual-looking labels, explain what else you'd need: the querying process, frequency, normal application behaviour and subsequent connections. First establish which resolver and endpoint data the organisation collects; don't assume your search covers every lookup.

7. What's the difference between hashing, encryption and encoding?

Encoding changes how data is represented. Base64, for example, is reversible without a secret and doesn't make a command confidential.

Encryption uses a cryptographic process to protect data, with decryption recovering the original using the appropriate key. A cryptographic hash produces a digest and is designed to make recovering an input from that digest computationally infeasible. NIST provides definitions for encryption and hash functions.

For a SOC example, a file hash can help you look for an identical file in other places or compare it with intelligence. A hash that isn't in a reputation service doesn't prove the file is safe. Explain what other behaviour you'd inspect.

8. Which logs would you examine on Windows or Linux?

Choose logs according to the question. For authentication, start with the relevant operating-system or identity-provider records. For execution, look for process telemetry and available command-line details. Then check application, network or service logs for related activity.

On Windows, event 4624 records a successful logon, while 4625 records a failed logon. Inspect the account, source, computer, timestamp and logon type. A network logon isn't the same as a person signing in at the keyboard.

On Linux, the available journal, authentication, audit and application records depend on the distribution and configuration. State that you'll verify auditing, collection and retention. Missing search results aren't evidence that an event never occurred.

9. How would you use MITRE ATT&CK?

Use ATT&CK to describe observed adversary behaviour and identify useful investigation or detection questions. For example, T1059.001 covers PowerShell abuse for execution. That mapping gives the team a shared reference; it doesn't prove every PowerShell process is malicious.

Similarly, password spraying involves trying a small set of passwords across multiple accounts. A burst of failures against one account doesn't establish that pattern. Explain the behaviour you observed before assigning a technique, and don't use a technique ID to claim you know the attacker.

10. How would you describe incident response?

“I'd validate and scope the activity, communicate with the response lead, carry out authorised containment, and support investigation, recovery and learning from the incident. The order and urgency depend on active harm and the organisation's plan.”

If the interviewer asks about NIST, be aware that SP 800-61 Revision 3, published in April 2025, superseded Revision 2. It places incident response within the Cybersecurity Framework 2.0, with preparation supported by wider risk-management activities and incident handling across Detect, Respond and Recover.

You can still discuss containment, eradication and recovery as practical activities. Explain how you'd apply the organisation's process rather than reciting an older diagram as the only current model.

Scenario-based SOC analyst interview questions

For each scenario, say what the supplied evidence establishes, what remains uncertain and what you would check next. If the interviewer introduces evidence of active harm, adjust your urgency. Investigation and urgent response may need to proceed together.

11. Failed logons are followed by a success. What do you investigate?

Practise with this simplified, fictional log extract. All timestamps are UTC, all rows are from server FILE-02, and the addresses are documentation examples.

“I'd investigate the failures and success for svc_reports from the same source, but these rows don't establish compromise. I'd identify the source device and service owner, inspect failure codes and check for a password rotation or scheduled task. I'd also examine activity associated with the successful logon and search a wider time window.”

The analyst_demo row involves a different account and source. Its proximity in time doesn't prove it's related. Type 3 means a network logon; type 10 indicates a remote interactive logon. Use the relevant session identifiers and host evidence where available, and don't join unrelated events merely because they're close together.

If the service owner confirms an authorised password update and the subsequent activity matches the expected report job, that supports a benign explanation. An unfamiliar device, unexpected privileges or unexplained file access increases concern and gives you a reason to escalate. The next question is what happened after authentication, not simply whether a success exists.

12. An employee reports a payroll email. How do you investigate it?

Imagine an email asks a payroll coordinator to open a shared document and sign in again. The displayed sender looks familiar, but the employee is unsure about the request.

“I'd preserve the message and inspect its headers, sender and reply-to addresses, links and attachments using approved analysis tools. I'd check who received it and whether anyone interacted with it. If someone entered credentials, I'd involve the identity-response team and review subsequent sign-ins and mailbox activity.”

Microsoft's phishing investigation playbook provides a useful checklist for recipient scope, user interaction and related account activity.

SPF checks whether the sending server is authorised for the envelope-sender domain. DKIM uses a domain's cryptographic signature to verify signed message content. DMARC adds alignment with the visible From domain, using SPF or DKIM, along with policy and reporting.

These are email-authentication mechanisms, rather than content-safety verdicts. A pass doesn't make a message trustworthy, and a failure alone doesn't settle the investigation. Microsoft's email-authentication guidance explains why other signals still matter. Don't open a suspicious link in your normal browser or upload confidential messages to a public analysis service without approval.

13. EDR flags an encoded PowerShell command. Is it malicious?

“Encoding alone isn't enough to decide. I'd inspect the full process chain, account, command line, file paths, network activity and detection details. I'd compare the activity with approved scripts or changes. If I decode a command for analysis, I'd treat it as data and avoid executing it.”

Then distinguish intent from outcome. An attempted download blocked by a control is different from a payload that ran, created persistence and contacted another host. A familiar parent process or a signed executable also doesn't settle the case.

You don't need to name every possible artifact. Pick evidence that answers the question: what initiated the command, what it tried to do, what succeeded and which other systems could be affected.

14. A user signs in from an unfamiliar country. What do you check?

First verify whether the sign-in succeeded, the timestamps and the available device, application and authentication details. Compare previous activity and known corporate VPN infrastructure. Microsoft documents how identity-risk detections use travel and other signals; geographic distance is a reason to investigate, not an identity verdict.

“I'd review the related session and account activity, including changes or resource access after the sign-in. I'd verify any travel or VPN explanation through an established channel. A passed MFA challenge would be one piece of evidence, not my only basis for closing the alert.”

State what would alter your conclusion. A known managed device and verified VPN explanation can support legitimate use. Unexpected account changes or unexplained access require further investigation even if the user is travelling.

15. Several endpoints show possible ransomware activity. What comes first?

“I'd notify the incident-response lead immediately, identify the affected systems and act under the ransomware playbook to limit spread. If my role permits endpoint isolation, I'd use the approved control and verify its result; otherwise I'd urgently request that action from the responsible team.”

Microsoft's ransomware response guidance emphasises prompt containment while investigation continues. Explain how you'd preserve relevant evidence and communicate affected accounts, devices and services without delaying action against active harm.

Avoid making a universal promise to shut down every system or begin wiping devices. A business-critical service needs coordination, and destructive cleanup can remove evidence. Recovery decisions belong within the incident process, with the appropriate owners involved.

16. A large upload triggers a possible data-exfiltration alert. How do you respond?

“I'd validate the source, destination, time and transfer result, then establish what data was involved and whether the destination and transfer were authorised. I'd check the account and endpoint activity around the upload and compare it with normal work or a documented migration.”

Volume alone doesn't establish exfiltration. A small transfer containing sensitive information can matter more than a large approved backup. Likewise, an attempted transfer blocked by a control isn't the same outcome as completed data loss.

If evidence indicates active unauthorised transfer, explain how you'd escalate and seek or perform authorised containment. Separate what you can demonstrate about data access or transfer from what you still need to establish about intent.

17. You have several alerts and limited time. How do you prioritise?

Explain the factors you'd use: active harm, affected service or identity, business impact, evidence strength, scope and the team's response requirements. Look for alerts that belong to the same incident instead of treating every notification as a separate case.

For example, an unexplained privileged-account session affecting a critical service can deserve attention before many blocked attempts against a low-impact asset. The exact order depends on the supplied evidence.

“I'd tell the lead what needs immediate attention, which work is waiting and where I need coverage. If a lower-severity alert revealed evidence of compromise, I'd reassess its priority.” Don't promise to finish every investigation alone or close an uncertain case just to reduce the queue.

Experience and communication questions

18. Tell me about yourself and why you want this SOC role.

Connect your background to the work in the advertised role. A short structure is your current experience, one relevant example and why this position is the next step.

You can practise with: “My background is in [your field]. In [a real project, job or course], I worked on [relevant task], which involved [specific evidence or decision]. I'm applying because this role includes [responsibility from the description] and I want to develop [relevant capability].”

Replace every bracket with something true. A lab can be a useful example, but identify it as a lab. Don't turn study time into claimed production SOC experience.

19. Describe an investigation or project you've worked on.

Choose an example you can explain beyond its title. Describe the initial question, the evidence you examined, the conclusion you reached and one limitation. Be clear about what you personally did if it was a team exercise.

For a lab, you could discuss how you compared a suspicious login with endpoint records, or why an initial hypothesis didn't fit the evidence. Only use that example if you completed such work. An interviewer can ask about the fields, timestamps or searches you used.

Bring a sanitised report or diagram when appropriate. Remove secrets, personal information and confidential employer material, and get any necessary permission before sharing workplace evidence.

20. What if you haven't used our SIEM, or don't know the answer?

Say what you haven't done, then explain the relevant experience and how you would verify the unfamiliar detail.

“I haven't used that platform in production. In my lab I used another tool to filter authentication events by account and time. I'd check your data schema and product documentation, test a small search against known events, and ask a colleague to review it before relying on it during an incident.”

For an unfamiliar concept, ask a clarifying question and separate what you know from what you would look up. Avoid claiming that a search, an AI answer or a remembered command is correct without checking it.

21. How would you explain an incident or hand it to the next shift?

A handoff should let someone continue the work without reconstructing it from scattered messages. State the current assessment, evidence, actions, unresolved questions and next owner. Use consistent timestamps and distinguish a hypothesis from a confirmed finding.

For the fictional log exercise above, a practice handoff could read:

Assessment: Unresolved authentication activity for svc_reports on FILE-02. Compromise is not established.

Evidence: Three failures from 192.0.2.40 between 09:14:01 and 09:14:08 UTC, followed by a successful network logon at 09:15:12. The separate analyst_demo remote logon has not been linked to this activity.

Actions: Reviewed the supplied extract. No containment action taken in this exercise.

Next checks: Identify the source device and service owner, confirm recent credential changes, review the successful session's activity and expand the search window. Assign the case to an analyst and agree the next update time.

For a nontechnical colleague, begin with the impact and next action: “We're checking whether this account was used as expected. We haven't established unauthorised access. The investigation is continuing, and the next update will cover the account owner's confirmation and related activity.”

22. Tell me about a mistake, disagreement or a difficult shift.

Use a real example and explain your own actions. The situation-task-action-result structure can help, provided you spend enough time on what you did and learned.

For a mistake, explain how you noticed it, corrected it and reduced the chance of recurrence. For a disagreement, describe the evidence you compared and how you reached or escalated the decision. For workload pressure, explain prioritisation and communication.

Don't invent a security incident to make the answer sound impressive. A truthful example from IT support, customer service or study can demonstrate accountability and teamwork. Be equally honest about shift availability and any constraints.

Follow-up questions for experienced SOC analysts

23. How would you tune a noisy detection without hiding attacks?

“I'd review a defined sample of alerts, identify the rule's intended behaviour and separate parsing errors from legitimate activity that matches the logic. Then I'd propose a narrow change and test it against both known benign and relevant malicious examples before deployment.”

Explain how you'd check the change after rollout and reverse it if it loses useful coverage. An exception should have a reason, scope and review point. Excluding an entire department because its activity is noisy can hide the very behaviour the team needs to see.

Avoid reporting alert-volume reduction as the whole result. Discuss investigation effort alongside whether the rule still detects its intended behaviour.

24. What do you do when the SIEM has no relevant logs?

“I'd first check the search window, timezone, query and permissions. Then I'd verify whether the source generates the event, whether collection is enabled and healthy, whether parsing or filtering changed, and whether the data is still retained.”

Use a known event or source record to test the path where you can. Check another authorised data source for corroboration, such as endpoint telemetry or the identity provider, while recording the visibility gap.

An empty result can reflect missing telemetry, an incorrect query or genuinely absent activity. Explain which possibilities you've eliminated. If you can't establish coverage, don't present “nothing found” as proof that the environment is clean.

25. How would you propose a threat hunt or automate part of an investigation?

Start with a testable question and the evidence needed to answer it. For example: “I want to examine whether an account is accessing systems outside its usual administrative scope.” Define the accounts, time window, relevant records and normal activity you will compare.

For automation, begin with a bounded task such as collecting context or preparing a case summary. Explain input validation, permissions, failure handling and how an analyst verifies the output. If an action can disrupt an account or device, discuss the team's required approval and response process.

The same standard applies to AI-assisted work: check factual claims and source events, keep sensitive data within approved systems, and distinguish generated suggestions from verified findings.

Questions to ask the employer

Use the interview to understand the job you'll be doing. Choose the questions that the conversation hasn't already answered:

• Which investigations would I handle independently, and when would I escalate?
• How are shifts, overnight coverage, handoffs and on-call work organised?
• What training, shadowing and feedback would I receive during onboarding?
• Which logs and tools are available, and where does the team have visibility gaps?
• How does the team judge a good investigation and review detection quality?
• What would you want the person in this role to be able to do after three months?

Ask for examples where possible. “What happens when an analyst can't resolve an alert before the end of a shift?” gives you more detail than asking whether the team is supportive.

A practical preparation plan

Across a week, use the first two sessions to review the job description and explain the fundamentals aloud. Spend the next two on the log, phishing and endpoint scenarios, changing one fact each time to see whether your conclusion changes. Then write a short handoff and rehearse two truthful experience examples.

Finish with a mock interview: ask someone to choose questions without telling you which ones are coming, or shuffle your own question list. Check where you jumped to a conclusion, named a tool without explaining its use, or left the next action unclear. Revisit those answers before adding more topics.

If you're applying now, open a few current SOC analyst roles and match your preparation to their responsibilities. You can also browse roles tagged entry-level, checking each employer's experience and location requirements before applying.