SOC Analyst Interview Questions

"I started on an IT help desk, resetting passwords and fixing laptops. The tickets I enjoyed most were the odd ones, like a user whose account kept locking out, where I had to dig through logs to find an old phone still trying a stale password. That's basically detective work, and I realised security operations is that all day. I did a security certification, then built a small lab with a SIEM and a couple of Windows machines so I could attack them and watch what the logs showed. I want a SOC rather than, say, compliance or pentesting because I like being the one who sees the attack first and decides what it means. It's also the best place I know to learn fast, because you see so many different incidents."

"I know a lot of the queue is noise, and that some weeks you'll close the same kind of alert fifty times. I'm fine with that, partly because I've done shift work before and I know how to keep my sleep and routine steady. What keeps me going is that every so often one of those routine-looking alerts is real, and the analyst who stayed careful is the one who catches it. I also see false positives as a job to fix, not just to put up with. If I close the same noisy alert over and over, I'd rather write up why and suggest a tuning change, so the team gets time back for real investigations."

"I set up a small lab on my own laptop: a domain controller, one Windows client with Sysmon on it, and a free SIEM collecting both. Then I ran simple attacks against it, like a password spray and an encoded PowerShell download, and tried to find them in the logs the way a SOC would. The biggest lesson was how much depends on logging being switched on. My first spray barely showed up because I hadn't enabled the right audit policy, and the Windows process creation events had no command lines until I turned that setting on. I've also worked through blue team practice challenges where you get a packet capture or a set of logs and have to answer what happened. Those taught me to build a timeline before jumping to a conclusion."

"Tier 1 is the front line. They watch the alert queue, check each alert against the playbook, close the false positives with a clear reason, and escalate anything that looks real with their findings written up. Tier 2 takes those escalations and investigates properly: how far it spread, which accounts and hosts are involved, and what containment is needed. They usually lead the response for a normal incident. Tier 3 is the most experienced group. They hunt for threats no alert caught, build and tune detections, and handle malware analysis or forensics. Not every SOC splits it this neatly, and smaller teams blur the lines. I'd expect to start at Tier 1, and I'd try to write escalations good enough that Tier 2 never has to redo my work."

"For remote access, it's 22 for SSH, 3389 for RDP and 5985 or 5986 for WinRM. I'd be suspicious of RDP or SSH open to the internet, or RDP between two ordinary workstations, since that's rarely normal. Inside a Windows network, 445 is SMB, 88 is Kerberos and 389 is LDAP. One laptop suddenly talking SMB to dozens of machines looks like lateral movement or ransomware spreading. 53 is DNS, and attackers hide in it, so a host sending lots of long, random-looking subdomains to one domain could be tunnelling. 80 and 443 carry most web traffic, so I look at where it goes, how regular it is and how much data leaves. And 25 is SMTP: a normal workstation sending mail directly on 25 is a red flag, because only mail servers should."

"A SIEM pulls logs from everywhere, like domain controllers, firewalls, EDR, email and cloud, and parses them into common fields so a user name or IP means the same thing across sources. That gives us one place to search history during an investigation and to keep logs for as long as the business needs. The part that makes it a detection tool is correlation. A correlation rule links events that are weak on their own. One I like: many failed logins against different accounts from one source, followed within a short window by a successful login from that same source. Failed logins alone happen all day, and a success alone is normal, but together they suggest a password spray that worked. The alert then carries the source, the account that got in and the time window."

"First I'd pull a week or two of hits and group them. Usually most of the noise comes from a few sources, say a patching tool running PowerShell on every machine at night. Then I'd write the narrowest exception I can, like that exact signed binary from its install path calling a known script, rather than excluding the whole server or everything PowerShell does, because attackers love hiding inside trusted tools. Before it goes live I'd run the new logic against past data and any past true positives or a test attack, to confirm the real cases still fire. If the rule is still noisy but valuable, I might lower its severity or feed it into a risk score instead of paging on every hit. Every exception gets a note: why, who agreed, and a date to look at it again."

"I'd start with identity, because nearly every attack uses an account at some point. That means domain controller security logs and cloud sign-in and audit logs, including MFA events. Next would be endpoints, ideally EDR alerts and key telemetry, because that's where malware and hands-on-keyboard activity show up. Then the edges: VPN and firewall logs for who's coming in and what's going out, plus DNS or web proxy logs, which are great for spotting command and control and phishing clicks. Email security logs would be high on the list too, since phishing is such a common start. To control cost, I'd be picky about noisy events, like dropping verbose firewall allow logs for internal traffic, and store raw logs somewhere cheaper for investigations. Then I'd check coverage against our top attack scenarios, not just tick off sources."

"For every phishing report, we used to look up each link and attachment hash by hand in a few reputation services and paste the results into the ticket. It took ten minutes per email and we had dozens a day. I wrote a small script, later turned into a SOAR playbook, that pulled the indicators out of the reported email, checked them automatically and added a summary to the ticket. I deliberately kept it to gathering information. It never deleted emails or blocked anything on its own, because a wrong automatic block could stop real business mail. An analyst still pressed the button for those actions after reading the summary. Triage time for a phishing report dropped to a couple of minutes, and we used the time to properly check who had clicked."

"I'd start with the alert itself: which host, which user, the time, and the full command line. The parent process matters a lot. PowerShell launched by a management agent is very different from PowerShell launched by Word or Outlook. If the command is encoded, I'd decode it and see what it does, like downloading something or reaching out to a domain. Then I'd look at the process tree and network connections in the EDR, check any domain or hash against threat intel, and see what the user was doing around that time, for example opening an email attachment. I'd also search whether the same command ran on other machines. If it's clearly a known admin script, I close it with the evidence. If it's an Office app spawning a download cradle, I'd contain the host per the playbook and escalate with a short timeline."

"I'd get the original email with full headers, not just the forward, because forwarding can lose details. In the headers I'd compare the display name, From and Return-Path, look at Reply-To, and read the authentication results for SPF, DKIM and DMARC. Then I'd look at the link in a sandbox or a URL reputation service, never by clicking it on my own laptop. If it's a fake login page, that's credential phishing. Next is scope: a message trace to see everyone who got the same email, then proxy or DNS logs to see who actually visited the link. For anyone who did, I'd check sign-in logs for odd logins after that time. Then clean up: remove the email from all mailboxes, block the sender and domain, and for anyone who entered a password, reset it and revoke their sessions."

"I wouldn't start at the top of the list and work down. First I'd sort by severity and by what's affected, so anything on a domain controller, an admin account or a server that faces the internet comes first, along with anything that suggests active compromise, like ransomware behaviour or a login from a spray. Then I'd look for groups. Often a big pile comes from one cause, like a new software rollout tripping the same rule on a hundred machines, and I can check a sample, confirm it's one benign cause and close them together with one clear note. If I found something serious, I'd escalate or call the on-call person right away rather than keep clearing noise. At the end of the shift I'd flag why the queue built up, so the rule or the staffing can be looked at."

"A steady, regular check-in like that is what command and control beaconing often looks like, but plenty of normal software does it too, like update checkers or licence services. So I'd first look at the domain: how old it is, its reputation, who registered it, and whether lots of machines across the company talk to it, which would point to legitimate software. I'd look at the queries themselves too. Long, random-looking subdomains can mean data is being tunnelled over DNS. Then the key step is finding which process is making the requests, using EDR. If it's a signed updater from a vendor we use, I'd close it with that evidence. If it's an unknown executable in a user's temp folder, I'd isolate the host, collect the file and escalate."

"We got an alert about a process reading LSASS memory on a workstation, and I'd never worked one before. I knew LSASS holds credentials, so I treated it as serious while I learned. I looked it up in ATT&CK, which lists it under credential dumping, and read which legitimate tools also touch LSASS, like some security products. Then I checked the process in the EDR. It was an unsigned tool running from a user's downloads folder, launched from a command prompt the user had opened, which didn't fit any legitimate use. I asked a senior analyst to sanity-check me, then isolated the host per the playbook. It turned out to be a curious developer testing a tool, but we reset their credentials anyway. I wrote a short playbook section so the next analyst had a head start."

"An indicator of compromise is a piece of evidence that something bad happened, like a known malware hash, a command and control IP, a domain or a registry key the malware creates. An indicator of attack is about behaviour, what the attacker is doing, like Word spawning PowerShell that then downloads a file, or a process reading LSASS memory. Hashes lose value fast because the attacker only has to change one byte to get a completely new hash, and IPs and domains are cheap to swap as well. That's the idea behind the Pyramid of Pain: the higher you detect, towards tools and techniques, the more it costs the attacker to change. So I'd use IOCs for quick sweeps when intel comes in, and lean on behaviour-based rules for detection that keeps working."

"ATT&CK groups attacker behaviour into tactics, which are the goals like initial access or lateral movement, and techniques, which are how they do it. For example, T1059 is command and scripting interpreter, and PowerShell is its sub-technique, T1059.001. In an investigation I use it as a checklist for what to look for next. If I've found credential dumping, I know lateral movement is a likely next step, so I go looking for new remote logons from that account. Beyond single cases, it's useful for coverage: we mapped our detection rules to techniques and found we had almost nothing for persistence through scheduled tasks, so that went on the detection backlog. And when an intel report says a group uses certain techniques, I can check straight away whether we'd see them."

"I'd agree the feed could be useful, but ask to test it before it pages anyone. Big raw feeds often include shared hosting IPs, content delivery networks and old entries that were bad months ago, and matching on those would flood the queue. So I'd load it in a quiet mode and run it against the last couple of weeks of logs to see how many hits it gives and how many look real. Then I'd filter it: drop well-known shared ranges, age out entries past a sensible date, and prefer ones with context about the threat. The best use is often enrichment, adding a tag to an alert so the analyst sees it, and only alerting on high-confidence matches or matches alongside other suspicious behaviour. I'd take those numbers back to my manager with a clear proposal."

"The ones I use most are logon events. 4624 is a successful logon and 4625 a failed one, and the logon type field matters: type 2 is someone at the keyboard, type 3 is over the network, like a file share, and type 10 is RDP. 4672 shows a logon that got special privileges, so it points to admin accounts. 4688 is process creation, which is gold for seeing what ran, but only if auditing is on, and command lines need their own setting. For account changes, 4720 is a new user and 4728 or 4732 means someone was added to a security group, which is worth checking for admin groups. For tampering, 1102 means the security log was cleared. For persistence, 7045 in the System log is a new service, and 4698 is a new scheduled task."

"Traditional antivirus mainly checks files against known bad signatures and blocks them. It gives you a yes or no at one moment. EDR records what happens on the machine over time: which process started which, the command lines, network connections, and file and registry changes. That lets it alert on behaviour, like Excel launching PowerShell, and it lets me go back and build a timeline after the fact. For response, the action I'd use most is network isolation, which cuts the machine off from everything except the EDR console so I can keep investigating without the attacker spreading. I'd also kill a malicious process, quarantine a file, pull files or memory for analysis, and search every endpoint for the same hash or command line. The SIEM gets alerts from EDR, but the detail and the response live in the EDR."

"Clearing the security log on a domain controller in the middle of the night is one of the loudest signs of an attacker covering their tracks, so I'd treat it as high priority. Event 1102 tells me which account did it. I'd check how that account logged on, from which machine, and whether it normally administers domain controllers. I'd quickly check for an approved change or maintenance at that time, and ask the admin team if needed. The good news is that if the logs were already being sent to the SIEM, we still have what happened before the clear, so I'd look back at that account and host for new services, scheduled tasks, group changes or remote logons. If there's no clear innocent explanation, I'd escalate it as an incident straight away, because an attacker with that access may control the whole domain."

"The classic model comes from NIST's incident handling guide. First is preparation: playbooks, logging, tools and knowing who to call before anything happens. Then detection and analysis, which is where a SOC analyst spends most of the day, working out whether an alert is a real incident and how serious it is. Next comes containment, eradication and recovery. Containment stops the spread, like isolating a host or disabling an account. Eradication removes the cause, such as the malware and any persistence the attacker set up, and recovery brings systems back and watches them closely. The order matters, because if you rebuild a machine before you know how the attacker got in, they just walk back in. Last is post-incident activity: the review, the report and the changes to rules and playbooks, which loops back into preparation. SANS describes the same work as six steps."

"That pattern is a password spray: one or two passwords tried across lots of accounts, so no single account locks out. The one success is what matters most, because it means an attacker may now have a working account. I'd first check that login: which account, from where, whether MFA was involved, and whether it's a service or admin account. Then, following the playbook, I'd get the password reset, revoke the account's active sessions and check that no new MFA method or mail forwarding rule was added. Next I'd look at everything that account did after the login, like mailbox access, file downloads or new logons to other machines. I'd block the source IP, search for the same activity from other IPs, and escalate to Tier 2 with a timeline, because a working login means this is an incident, not just an alert."

"I'd take a very quick look to make sure it's not a false positive, like a backup or sync tool renaming lots of files. If I see a process I don't recognise renaming and rewriting files quickly, maybe with ransom notes appearing, I'd isolate the laptop through EDR straight away, as long as the playbook allows it, which it usually does for ransomware. An interrupted presentation is embarrassing, but ransomware reaching file shares could stop the whole company. At the same time I'd tell my lead and ask someone to reach the executive or their assistant, so they hear it from us in plain words and get a spare laptop. I'd keep the machine powered on so memory is kept, then check whether the same process or hash has appeared on other hosts."

"I'd tell my lead and whoever is running the incident right away, even if it's embarrassing, because that alert might show the attacker was in a week earlier than we thought, and that changes how far back we have to look. I'd share the original alert, my notes and exactly why I closed it. Then I'd help with scoping from that earlier date. Once things are under control, I'd look honestly at why I missed it. Maybe I relied on the alert title, or the playbook said that pattern was usually benign. Then I'd suggest a concrete change, like adding a check to the playbook or tuning the rule so the real version stands out. Most SOCs would much rather hear about a miss from you than find it later themselves."

"At my last company, a rule fired for a user signing in from a new country. We got those daily because of travel, so it looked routine. What made me look harder was that ten minutes later the same account created an inbox rule forwarding any email with the word invoice to an outside address. That's classic business email compromise. The proxy logs showed the user had visited a fake login page that morning, just before the foreign sign-in. Following our playbook, I had the password reset, revoked their sessions, removed the forwarding rule and blocked the phishing domain. Then I searched for anyone else who had visited that page and found one more account, which we handled the same way. Afterwards we added a rule for new external forwarding rules, which had been a gap."

"The one I remember best was after a phishing campaign where two accounts were compromised. It had two audiences, managers who wanted to know how bad it was, and engineers who needed the details. So I opened with a short summary: what happened, which accounts, that we had no evidence of data leaving, and that it was contained. Then a timeline, every event with a timestamp in UTC and where it came from, like mail logs or sign-in logs. After that the scope, the indicators we blocked and how the attacker got in. I kept facts and guesses apart, writing 'we have no evidence of' rather than 'nothing happened'. I ended with the actions taken, what was still open with owners, and two lessons, one of which became a new detection rule."

"I escalated a server making outbound connections to an IP in a hosting range we didn't normally talk to, late in the evening. The server team said it was their new monitoring tool and asked me to close it. I didn't want to argue on a hunch, so I asked which tool and checked the process making the connections in the EDR. It was a signed agent, but the destination didn't match that vendor's documented addresses. I shared that one fact with the team and asked if they could confirm it with the vendor. It turned out the vendor had added a new region that wasn't in their docs yet, so the traffic was fine. I was wrong about the threat, but the server team updated their records and we added the new range to our allowlist with a note, so it was still worth raising."

"In my first SOC role, handovers were a quick chat and a few lines in a chat channel. One night I inherited an alert marked 'watching' with no notes on what to watch for. I spent an hour redoing the previous analyst's work, and the user had logged off by the time I understood it. After that I suggested a short handover template in the ticket system: open cases with their status, what was checked, what the next step is and who's waiting on what, plus anything unusual in the environment, like a planned change. It took a couple of minutes per shift. The team agreed to try it, and within a few weeks people stopped messaging the previous shift to ask what they meant."

"I think the biggest danger in a SOC is the tenth identical alert of the day, because that's when you close it without reading. So I keep a few fixed habits. I never close anything on the title alone. I always check the user, the host, the parent process or source, and what happened just before, even if it takes an extra minute. When I notice I'm closing the same alert over and over, I treat that as a signal to raise a tuning request instead of just getting faster at it. I also like teams where people spot-check each other's closed tickets now and then, without blame, because a second pair of eyes catches the habits you can't see in yourself. And I take my breaks properly, especially on nights."

"To me, a healthy SOC is one where people raise a miss or a doubt as soon as they have it, because in security a hidden mistake gives the attacker more time. That only happens if a missed detection is treated as a gap in our rules, playbooks or staffing, not as someone's personal failure. I also like teams that share what they learn: a short review of interesting cases each week, playbooks people actually update, and seniors happy to look over a newer analyst's shoulder on a strange alert. My part is simple. I own my own misses out loud, I write up anything unusual I work on so others can learn from it, and when a newer analyst asks a basic question, I answer it properly, because I remember asking the same things."