21 questions that come up again and again in entry-level SOC interviews, what each one is really checking, and what a good answer covers.
1. The basics
1.1 “Confidentiality, integrity, availability.” Pick an attack that hits each one.
What it’s checking: Can you go past the textbook definition.
Short answer: Confidentiality is lost when data gets out to people who shouldn’t see it, like a leaked customer database. Integrity is lost when data is changed without permission, like an attacker editing payment details on an invoice. Availability is lost when people can’t use a system, like ransomware locking file servers or a DDoS taking a website offline.
1.2 People mix up “threat“, “vulnerability” and “risk“. How would you separate them?
What it’s checking: Whether you use security words precisely.
Short answer: A vulnerability is a weakness, such as an unpatched VPN. A threat is someone or something that could exploit it, such as a ransomware gang. Risk is the chance it happens multiplied by how much damage it would do. An unpatched VPN facing the internet with known exploits in the wild is high risk.
1.3 True positive, false positive, false negative: which one would keep you up at night, and why?
What it’s checking: How you think about alert quality.
Short answer: A true positive is a real threat that was correctly flagged. A false positive is an alert on harmless activity. A false negative is a real attack that raised no alert at all. False negatives are the scariest because nobody knows they’re happening. Too many false positives are dangerous too, though: analysts get alert fatigue and start missing the real ones.
2. Networking
2.1 I’ll name a service, you give me the port: DNS, HTTP, HTTPS, SSH, RDP, SMB. Which of those would you hate to see open to the internet?
What it’s checking: Port basics, and whether you know which ones attackers love.
Short answer: DNS 53, HTTP 80, HTTPS 443, SSH 22, RDP 3389, SMB 445. RDP and SMB facing the internet are the big red flags. RDP gets brute-forced constantly and is a common way in for ransomware. SMB has a long history of wormable exploits.
2.2 When would traffic use TCP, and when UDP?
What it’s checking: Protocol fundamentals.
Short answer: TCP sets up a connection with a three-way handshake (SYN, SYN-ACK, ACK) and makes sure data arrives complete and in order. It’s used for web traffic, email and SSH. UDP just sends packets with no handshake and no guarantee, which makes it faster. It’s used for DNS lookups, streaming and VoIP.
2.3 Someone types a web address and hits Enter. Talk me through what happens next on the network.
What it’s checking: Can you connect the pieces into one story.
Short answer: The machine asks DNS for the site’s IP address. It opens a TCP connection to that IP on port 443 and does a TLS handshake to set up encryption. Then it sends the HTTP request and gets the page back. A SOC can see this in DNS logs, firewall or proxy logs, and EDR network events on the endpoint.
3. Investigating alerts
3.1 You get a phishing alert, and the user has already clicked the link. Walk me through your next steps.
What it’s checking: Order of actions and calm judgement.
Short answer: First, find out what happened after the click. Did they enter a password, download a file, or run anything? If credentials were entered, reset the password and revoke active sessions. If something ran, isolate the machine. Then check who else got the same email and pull it from their mailboxes. Block the link or sender, escalate according to the playbook, and write down everything you did.
3.2 A user signs in successfully from a country they’ve never logged in from before. What do you check?
What it’s checking: Telling “unusual” apart from “malicious“.
Short answer: Look for context first: are they travelling, or using a VPN or a cloud service? Check for impossible travel, such as a login from Dublin ten minutes earlier. Check whether MFA was passed and from which device. Then look at what the session did afterwards: mailbox rules, file downloads, new MFA methods. Confirm with the user through a trusted channel and escalate if anything doesn’t add up.
3.3 How do you convince yourself an alert is a false positive before you close it?
What it’s checking: Method, not gut feeling.
Short answer: Understand what the rule is trying to catch, then look at the actual evidence: process, user, host, command line, network traffic. Enrich anything suspicious and compare against normal behaviour for that user or machine. Close it only when you can explain why it’s harmless, and write that reason in the ticket so the next analyst doesn’t have to redo the work.
3.4 Five alerts land at the same time. How do you decide which one to pick up first?
What it’s checking: Prioritisation and communication.
Short answer: Start with severity and with what’s affected. A domain controller or an admin account comes before a regular laptop. Anything happening right now comes before something historical. Signs of spread, like the same activity on several hosts, push an alert up the queue. If you can’t keep up, tell your lead early rather than quietly falling behind.
3.5 You’ve got a suspicious IP, domain or file hash. How do you find out if it’s bad?
What it’s checking: Knowing your enrichment tools and their limits.
Short answer: Check it against threat intelligence sources such as VirusTotal, AbuseIPDB or your company’s own feeds. Check when a domain was registered, since brand-new domains are suspicious. Search your own logs to see where else it appears. A clean result doesn’t prove something is safe, because new infrastructure often hasn’t been reported yet. The behaviour you can see matters more than a reputation score.
5. Frameworks and tools
5.1 SIEM and EDR both get mentioned a lot. What does each one actually do for you?
What it’s checking: Knowing the tools you’ll use every day.
Short answer: A SIEM collects logs from across the company (firewalls, servers, cloud, identity) and correlates them to raise alerts and support searches. An EDR sits on each endpoint and records processes, files and network connections in detail. It can also act, for example by isolating a host or killing a process. The SIEM gives you the wide view and the EDR gives you the deep view on one machine.
5.2 How would MITRE ATT&CK actually help you mid-investigation?
What it’s checking: Using a framework, not just naming it.
Short answer: ATT&CK is a catalogue of real attacker behaviour, organised into tactics (the goal) and techniques (how they reach it). If you map an alert to a technique, you can see where the attacker probably is in the attack and what they’re likely to try next. That tells you where to look and gives everyone a shared language for the incident.
5.3 You spot a credential-dumping tool on a server. What does that tell you about where the attacker is?
What it’s checking: Placing one event in the bigger attack.
Short answer: Credential dumping is post-compromise, under Credential Access in ATT&CK. The attacker already has a foothold and enough privileges to read memory, often admin. They’re probably trying to move to other machines. Isolate the server, treat any credentials used on it as stolen, and look for lateral movement from it.
5.4 You’re handing a case to the next shift. What has to be in that ticket?
What it’s checking: Documentation habits.
Short answer: Which alert or rule fired and when. The hosts, users, IPs and files involved. What you checked and what you found. Your conclusion and why you reached it. What you’ve already done, and what still needs doing. Someone who has never seen the case should be able to pick it up without asking you anything.
6. Behavioural
Use STAR: Situation, Task, Action, Result.
6.1 Out of everything in IT, why a SOC?
What it’s checking: Real motivation.
Short answer: Give a specific reason, not “it’s in demand“. For example, you enjoy working out what happened from clues, or a security incident you saw at work hooked you. Back it up with what you’ve already done about it: home labs, TryHackMe, certifications, security tasks you volunteered for in your current job.
6.2 Tell me about a time you had to explain something technical to someone who wasn’t technical.
What it’s checking: Communication, which you’ll need for every escalation and user call.
Short answer: Choose a real example; helpdesk stories count. Describe the situation, what you needed them to understand, how you explained it (plain language, an analogy, skipping the jargon) and the result, such as the user fixing it themselves or a manager approving a change.
6.3 Tell me about a mistake you made at work and what happened next.
What it’s checking: Honesty and ownership.
Short answer: Pick a real mistake, not a disguised boast. Show that you owned it and raised it quickly, how you fixed it, and what you changed afterwards so it wouldn’t happen again. Interviewers care much more about the last part than about the mistake itself.
6.4 Describe a time you had too much to do and not enough time.
What it’s checking: Staying calm and prioritising under pressure.
Short answer: Describe the situation, how you decided what came first (impact, deadlines, who was waiting), who you kept informed, and how it turned out. If it went badly, finish with what you’d do differently.
Reading answers isn’t the same as giving them
You now know the kind of questions that come up. The real preparation is being asked them live by someone who’s done the job: under a bit of pressure, with follow-ups that push past your first answer and questions you didn’t see coming.
That’s what my mock interview is: 60 minutes run like the real thing, honest feedback at the end, and a written summary within 24 hours telling you exactly what to work on.
Based in Ireland? There are free training routes many people miss. I cover the ones that fit you in your written summary.
Book a mock interview · €99