SOC Analyst Interview Questions 2026

index=auth sourcetype=*ssh* OR sourcetype=*windows* action=failure | bucket _time span=5m | stats count by src_ip, _time | where count > 10 | sort -count Key concepts: bucket _time aggregates events into 5-minute windows, stats count groups by source IP + time bucket, where filters thresholds. Tune threshold (>10) based on environment baseline. Production refinement: exclude legitimate brute-force-pattern systems (vulnerability scanners, password spray tools you authorise).

Optimisation hierarchy: (1) Filter early — most-restrictive index/sourcetype/host first. Splunk performs left-to-right filtering. (2) Use earliest/latest as tight as possible. (3) Avoid wildcards at start of search terms. (4) Use stats over transaction (faster). (5) Use tstats on accelerated data models when possible. (6) Use map-reduce parallelism — index-time fields beat extract-at-search-time. (7) Avoid join — use stats-based correlation instead. Example transformation: 'index=* error' → 'index=app sourcetype=app:error error' is 100× faster.

T1059 = adversary using Bash, PowerShell, cmd.exe, Python for execution. Investigation steps: (1) Get full command line from EDR/Sysmon Event 1; (2) Identify parent process (was PowerShell launched from Word? = malicious; from Sysmon Event 1 ParentImage); (3) Check for encoded commands (PowerShell -EncodedCommand → base64 decode); (4) Check network connections from process (Sysmon Event 3); (5) Check files written (Sysmon Event 11); (6) Hash + reputation check on any artifacts. Sub-techniques: T1059.001 PowerShell, T1059.003 Windows Command Shell, T1059.006 Python — investigation differs slightly per shell.

Cyber Kill Chain (Lockheed Martin, 2011) — linear 7-phase model: Reconnaissance → Weaponization → Delivery → Exploitation → Installation → C2 → Actions on Objectives. Simple, easy to teach, but oversimplified — modern attacks don't follow strict linear paths. MITRE ATT&CK (2013, expanded continuously) — graph-like 14 tactics + 200+ techniques. Reflects how adversaries actually operate (skip phases, parallel attacks, persistence loops). Industry standard since 2018. Use Kill Chain for executive briefings; ATT&CK for technical SOC operations.

NIST IR lifecycle: (1) Preparation — done before incident: tools, runbooks, contacts, comms plan; (2) Detection + Analysis — confirm true positive, scope (1 host vs lateral spread), severity classification; (3) Containment — isolate affected host(s) via EDR, block C2 IPs at firewall, disable affected accounts; (4) Eradication — remove malware, patch initial entry vector; (5) Recovery — restore from clean backup, monitor for re-infection; (6) Lessons Learned — root cause analysis, runbook updates, detection rule additions. Time-criticality matters: aim for containment within 1 hour of confirmation for ransomware.

Multi-source investigation: (1) Active Directory — query event 4740 (account lockout) for source workstation/IP; (2) Filter logs from that workstation — what's authenticating? Could be: cached credentials on phone/Outlook/RDP after password change; service running with old credentials; brute-force attack from compromised host. (3) PowerShell Get-WinEvent or Splunk SPL: index=ad EventCode=4740 user=affected_user | stats count by Caller_Computer_Name. (4) On caller machine: check scheduled tasks, services, drive mappings using old creds. (5) Check for actual brute force: many failed authentications from external IP = compromised user, not just 'forgot password' lockout.

Critical events for SOC analysts: 4624 — successful login (logon type 2=interactive, 3=network, 10=remote interactive/RDP, 4=batch, 5=service). 4625 — failed login. 4634 — logoff. 4647 — user-initiated logoff (interactive). Investigation patterns: 4625 + 4624 from same source = brute-force success. Logon type 10 from external IP = potential RDP attack. Service account 4624 with logon type 3 from unusual source = potential lateral movement. Mastering these event IDs is non-negotiable for any Windows-heavy SOC role.

Alert-driven (reactive): SIEM/EDR generates alerts → analyst investigates → confirms + responds. Most SOC L1 work is alert-driven. Threat hunting (proactive): analyst forms hypothesis ('adversary may have established persistence via WMI subscription') → searches data without preexisting alert → either confirms threat or rules out. Hypothesis-driven hunting is L2/L3 work, not L1. PEAK framework (SANS) for hunting: Prepare, Execute, Act, Knowledge sharing. Most senior SOC roles split time: 60% alert response, 40% hunting + detection engineering.

(1) Hypothesis: 'Adversary may be using PsExec or remote service creation for lateral movement'. (2) Data sources needed: Windows Event Logs (5145 Network Share, 7045 Service Install), Sysmon Event 1 (process creation with psexec.exe / cmd.exe with /sc command), authentication events (4624 logon type 3 from internal IPs). (3) Build SPL: index=win EventCode=7045 OR (EventCode=4624 LogonType=3 src_ip=internal_subnet) | stats count values(EventCode) by src_ip, dest_ip. (4) Identify outliers — workstations rarely host services, unusual lateral connections. (5) Pivot to confirmed positives — investigate full attack chain. (6) Document findings → create detection rule for repeat alerts.

All three are EDR market leaders. CrowdStrike Falcon — strongest threat intelligence + detection efficacy, expensive (typically ₹3-5K/endpoint/year), rich Falcon OverWatch managed hunting. SentinelOne — strong rollback/remediation features, AI-driven detection, mid-tier pricing. Microsoft Defender for Endpoint (formerly ATP) — included with M365 E5 (huge cost advantage for Microsoft shops), tightly integrated with Sentinel + Defender XDR. Bangalore market: CrowdStrike strongest at BFSI + product cos; Defender dominates Microsoft enterprise shops; SentinelOne competitive at mid-market. Skills transfer ~80% across platforms; mastering one + understanding interfaces of others is the hiring optimum.

(1) DO NOT click any links or open attachments. (2) Detonate in sandbox — VMRay, Joe Sandbox, Any.Run for safe analysis. (3) Extract IOCs — sender email, sender IP, URLs, file hashes (SHA-256). (4) Check IOC reputation — VirusTotal, AlienVault OTX, urlscan.io. (5) If malicious confirmed: search inbox for other affected users (potential phishing campaign), block sender domain, retract emails via M365 admin if possible. (6) Update detection — add IOCs to SIEM blocklist, write Sigma rule for similar patterns. (7) User communication — confirm to reporter, wider awareness if campaign. Time-target: 30 minutes from receipt to first action.

SIEM (Security Information + Event Management) — log collection, correlation, alerting. Examples: Splunk Enterprise Security, Microsoft Sentinel, IBM QRadar, Elastic Security. Output: alerts requiring human investigation. SOAR (Security Orchestration, Automation, Response) — playbook automation across tools. Examples: Splunk SOAR (formerly Phantom), Palo Alto XSOAR, IBM Resilient. Output: automated response actions (block IP, disable user, create ticket). Use together: SIEM detects → SOAR auto-triages low-severity alerts → escalates high-severity to humans. SOAR adoption growing fast in 2026 — saves 30-40% L1 analyst time at mature SOCs.

CloudTrail — API call audit log (every action across AWS account, who/what/when/where). Free baseline + paid management/data event variants. GuardDuty — managed threat detection on CloudTrail + VPC Flow Logs + DNS logs. Outputs: alerts for known threat patterns (cryptomining, instance compromise, IAM credential abuse). Security Hub — central aggregation point for findings from GuardDuty, Macie, Inspector, third-party tools. Provides compliance scoring (CIS, NIST, PCI-DSS benchmarks). SOC analyst workflow: Security Hub → triage findings → drill into GuardDuty alert details → use CloudTrail for forensic timeline.

DNS tunneling = encoding data in DNS queries/responses to bypass firewalls. Detection patterns: (1) Unusually long subdomain names (legitimate DNS rarely has 200+ char subdomains): index=dns | eval subdomain_length=len(query) | where subdomain_length > 100. (2) High query volume from single client: index=dns | stats count by src_ip | where count > 1000 (per hour). (3) High entropy in subdomains (random-looking strings): use Splunk MLTK shannon entropy command or custom Python. (4) Unusual record types (TXT, NULL queries from clients): index=dns query_type IN (TXT, NULL) NOT src_ip IN (legit_resolver_list). Tools: Splunk Enterprise Security has DNS analytics; standalone: bandit / Suricata DNS rules; ML option: MLTK anomaly detection on DNS metrics.

Sigma rule (Florian Roth, 2017) — vendor-neutral YAML format for security detection logic. Structure: title, detection logic, log source, level. Example: detect PowerShell EncodedCommand → write once in Sigma → convert to Splunk SPL via sigmac → also convert to Elastic Lucene, QRadar AQL, Sentinel KQL. Why useful: (1) Portable across SIEMs; (2) Community-shared (SigmaHQ GitHub has 3,000+ rules); (3) Standard format for detection-as-code. SOC L2/L3 analysts must be Sigma-fluent. Modern Bangalore SOCs increasingly require detection-as-code skills with Git workflows.

Time-bounded investigation in 30 minutes: (1) Identify what they clicked — pull email from M365, extract URL. (2) Reputation check — VirusTotal, urlscan.io. (3) If credential phishing: did they enter credentials? Check ADFS/M365 sign-in logs for that user — any new sign-ins from unusual IPs/locations? (4) Force password reset + revoke active sessions immediately. (5) Check MFA status — if MFA enabled, attacker can't login with stolen creds (high-confidence containment). (6) Search inbox rules — common attacker action is creating auto-forward rule to exfil emails. (7) Check OAuth grants — attacker may have granted OAuth tokens to bypass password change. (8) Search M365 audit log for any other user activity from attacker IP. (9) Detection improvement — add the URL/domain to blocklist, search org-wide for other clicks.

(1) Identify successful login (event 4624) following multiple failures (event 4625) from same source IP. (2) Check legitimate use — was the user actually working at that time? Pull sign-in logs from M365/ADFS. (3) Geographic anomaly — login from country user has never used before. (4) Velocity check — was there a legitimate login from another country within hours? Impossible travel = compromised. (5) Post-login activity — what did the account do after login? Database queries? File downloads? Email sent to new addresses? (6) Force password reset, revoke sessions, MFA enrollment. (7) Hunt for other accounts brute-forced by same IP — likely campaign, not isolated incident. (8) Detection: write Sigma rule for 'failed authentication burst followed by success from same IP within 5 minutes'.

PCI-DSS — payment card data security standard. SOC implications: cardholder data environment (CDE) requires extra logging, monitoring, daily review of security events. Specific requirements: log retention 1 year (90 days online), file integrity monitoring (FIM), quarterly internal vulnerability scans. ISO 27001 — broader Information Security Management System (ISMS) standard. SOC implications: documented incident response procedure, log review cadence, evidence collection for auditor review. Both require demonstration of SOC operational maturity. SOC L2/L3 roles often involve audit support — being able to walk auditor through 'how did you detect + respond to incident X' is interview gold.

Practical steps: (1) Master 1 SIEM platform deep (typically Splunk for Bangalore SOCs); (2) Earn Splunk Power User Certified or equivalent; (3) Volunteer for night shift incident handling — gets you hands-on with real incidents (not just runbook execution); (4) Document case studies from your investigations — build a portfolio you can reference in L2 interviews; (5) Learn Sigma rule writing + contribute to detection engineering; (6) Master MITRE ATT&CK enough to discuss in interviews; (7) Add a specialisation: cloud (AWS Security Specialty), threat intel, or detection engineering. Realistic timeline: 18-24 months L1 → L2 with focused effort. Faster: 12-15 months if you handle a real major incident well.

Already changing meaningfully. (1) AI-powered triage — UEBA tools (Microsoft Sentinel UEBA, Splunk MLTK, Securonix) auto-prioritise alerts, reducing L1 alert volume 30-40%. (2) AI-assisted investigation — Microsoft Copilot for Security, Anthropic Claude integrations help analysts summarise alerts, write reports faster. (3) Generative AI threats — LLM-generated phishing at industrial scale, AI-powered social engineering. SOCs need new detection patterns. Career advice: (1) Skip 'pure Tier 1 alert triage' as long-term destination; (2) Aim for L2/L3 + detection engineering by year 3; (3) Add AI security skills (OWASP LLM Top 10, MITRE ATLAS) for future-proofing. SOC analysts who augment with AI thrive; those who compete with AI commodify.

STAR format (Situation, Task, Action, Result). Best examples: (1) Lab/training incidents — even from coursework, walk through the technical detail; (2) CTF investigation challenges — TryHackMe SOC L1 path provides real scenario practice; (3) Volunteer/consulting investigations; (4) Personal lab incidents you've simulated. Key elements: technical depth (specific tools, queries, findings), business impact awareness, lessons learned. Avoid: generic answers, claiming experience you don't have. Specificity wins — 'I was investigating a brute-force followed by 4624 from IP X, and noticed Y unusual authentication pattern...' beats 'I responded to many incidents'.

Show structured + respectful approach: (1) Acknowledge their perspective + experience; (2) Present specific data/observation that informs your view; (3) Frame as question, not challenge: 'I noticed X — does that change the analysis?'; (4) If still disagreed, escalate via process (L3 or manager) without bypass; (5) Accept the call as it stands while documenting your concern; (6) Seek post-mortem feedback to learn. Interviewers want to see: independent thinking + collaborative communication + respect for authority but not silent compliance. Avoid: 'I always defer to seniors' (too passive) or 'I'd push back hard' (too combative).

Tier 1 (most useful for SOC roles): (1) Splunk Core Certified User — entry level, free at Splunk Education. (2) Splunk Power User Certified — proves SPL fluency. (3) Splunk Enterprise Certified Admin — system admin focus, better for L3/architect roles. Splunk Enterprise Security Certified Admin — proves Splunk ES (the SIEM product) skills. Tier 2 (specialised): SOAR Certified Admin (for analysts moving toward automation). Cost-benefit: Splunk Power User adds ₹1-2 LPA to fresher salary, takes 8-10 weeks to clear. Best ROI cert in the SOC track. Splunk Enterprise Certified Admin is mid-career relevant (year 2-3+).

Most SOC investigations involve network logs (firewalls, IDS/IPS, NetFlow). Without networking foundations, you can't: (1) Read packet captures effectively (Wireshark requires TCP/IP fluency); (2) Distinguish normal vs anomalous traffic patterns (TCP handshake anomalies, port scans, unusual protocol use); (3) Validate firewall denies (was the deny correct? what would have happened if allowed?); (4) Understand cloud network logs (VPC Flow Logs, Azure NSG flow logs require networking baseline); (5) Investigate lateral movement (internal network paths, remote service access). CCNA-level depth is the minimum bar. SOC L2/L3 roles often expect Network+ or higher.

Strong question categories: (1) Process — 'What's a typical week look like for SOC L1 here? Shift breakdown?'; (2) Tools — 'Which SIEM + EDR platforms do you use? Are there plans to add SOAR?'; (3) Growth — 'What's the typical L1 → L2 timeline at your team? What learning resources are available?'; (4) Tech debt — 'What's the most challenging detection gap your team is working on closing?'; (5) Team culture — 'How does the team handle complex incidents — collaboration patterns?'. Avoid: 'What's the salary?' (already negotiated separately), 'How many vacation days?' (signals wrong priorities). Strong questions show you're hiring them as much as they're hiring you.