17 SOC analyst interview questions and answers

Treat the sequence as a hypothesis of account compromise, not proof. Confirm that failures and success concern the same identity, application and relevant time window; shared proxies can make unrelated users appear together. Examine authentication results, MFA details, device context and session activity after success. Compare with approved access patterns without treating familiar locations as automatically safe. Password mistakes are plausible, but unexpected privilege changes or downloads raise concern. Preserve the events and escalate proportionately. Revoke sessions or restrict the account only under documented authority, balancing rapid interruption against locking out legitimate business access.

Worked example: In an owned identity lab, deliberately mistype a test account password before signing in correctly. Expect failures followed by success; compare device and session context to explain why the sequence alone does not establish compromise.

1. Preserve the alert and underlying authentication events with timestamps and time zones.
2. Match identity, application, source and session fields; inspect MFA and device context.
3. Review subsequent account changes and resource access, recording visibility gaps.
4. Escalate with confidence and scope; apply only authorised session or account restrictions.

Common mistake: Blocking a shared source IP immediately can disrupt many users while leaving an attacker's existing authenticated session active.

Follow-up: Which post-login activity would make you escalate this sequence even when MFA succeeded?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• Microsoft Entra sign-in logsLiving vendor documentation

An encoded PowerShell argument hides readable text but is not inherently malicious; administrators also use encoding for reliable transport. Preserve the command line, process tree, user and timestamps before analysis. Decode text without executing it in an approved analysis environment; PowerShell's EncodedCommand commonly represents UTF-16LE text. Investigate what the decoded instructions attempt, then correlate parent processes, network activity and file changes. An Office parent increases suspicion but is not conclusive. Isolate only within documented authority when evidence warrants it. Isolation can interrupt operations and collection, so explain the urgency and evidence-preservation trade-off.

Worked example: On an owned lab VM, generate an encoded command that only prints a fixed message. Expect an encoded argument in available process telemetry, then decode it as text and compare the harmless intent with the alert.

1. Preserve EDR details, the command line and process ancestry.
2. Decode as inert text in an approved environment; never execute unknown content.
3. Correlate endpoint changes and network connections around the execution time.
4. Scope matching activity across authorised assets and request proportionate containment.

Common mistake: Pasting decoded content into a shell executes the evidence and may compromise the analyst workstation or destroy useful artefacts.

Follow-up: How would missing command-line telemetry change your investigation and confidence?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base
• Microsoft Windows: event 4688Audit policy and field availability matter

First, capture the account, time, destination and original message while immediately escalating the reported credential exposure. Preserve the .eml; inspect Received headers from the trusted mail boundary and check SPF, DKIM and DMARC alignment. Authentication passes do not prove benign content. Second, use the approved identity-response playbook to reset credentials, revoke supported sessions and review MFA methods; password resets alone may not invalidate every token. Third, scope sign-ins, mailbox rules, consent grants and other recipients. Targeted blocking may help, but broad blocks can disrupt shared services. Do not delay urgent authorised identity protection for exhaustive header analysis.

Worked example: Use a synthetic .eml containing a link to https://login.example.test in an isolated mail lab. Expect header analysis to identify authentication claims and trust boundaries, but not to establish whether submitted credentials were subsequently misused.

1. Record exposure details, preserve the original message and escalate promptly.
2. Apply authorised credential and session protections; review newly registered authentication methods.
3. Investigate sign-ins, mailbox changes and other recipients; block only within approved scope.

Common mistake: Treating DMARC pass as a safety verdict ignores compromised senders and attacker-controlled domains that correctly authenticate their own mail.

Follow-up: What would you check if suspicious mailbox activity continued after the password reset?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• Microsoft Entra sign-in logsLiving vendor documentation

Verify whether the alert measures sent bytes, total traffic or an estimate; an apparent upload can reflect aggregation errors. Identify the host, user, process, destination and transfer window, then compare with approved backups and normal activity. Correlate packet fields and timing with endpoint and proxy logs rather than relying on destination reputation. Encrypted captures generally cannot reveal transferred content. If S3 objects are involved, examine configured CloudTrail data events for GetObject activity; standard Event history does not supply those reads. Preserve evidence and request authorised containment when justified, balancing possible data loss against interrupting legitimate transfers.

Worked example: Transfer a synthetic file between two owned lab VMs using 192.0.2.10 and 192.0.2.20 on an isolated network. Expect packet timing and byte counts to align approximately with endpoint activity, allowing for protocol overhead.

1. Validate traffic direction, units, timestamps and asset identity.
2. Correlate packet or flow observations with endpoint processes and approved schedules.
3. For relevant S3 access, check data-event availability, caller identity, source IP and object history.
4. Document uncertainty, scope related activity and escalate any containment request.

Common mistake: Calling every overnight transfer exfiltration ignores scheduled work; calling every recognised cloud destination safe ignores attacker-controlled storage accounts.

Follow-up: What can you conclude if network telemetry shows an upload but endpoint process attribution is unavailable?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• Amazon S3 security best practicesLiving vendor documentation
• AWS CloudTrail: management and data eventsLiving vendor documentation

Prioritise by potential impact, evidence of active compromise, asset exposure and urgency, not simply arrival order or vendor severity. Link related alerts into a case while preserving distinct evidence; apparent duplicates may show expansion across hosts. An actively misused test account with production privileges can outrank an unverified alert on a critical server. Assign owners, flag capacity limits early and give a review time for deferred work. CVSS describes vulnerability severity, not incident priority by itself. Faster handling requires shortcuts, but those shortcuts should be documented triage decisions rather than silent dismissal of lower-ranked alerts.

Worked example: In a tabletop queue, compare a verified privileged session takeover with repeated blocked scans against an isolated test server. Expect the takeover to receive earlier attention because credible access and business impact outweigh raw alert volume.

Common mistake: Sorting only by the SIEM severity label hides differences in confidence, exposure, privileges and the consequences of delayed action.

Follow-up: What new evidence would cause you to move a deferred alert to the top of the queue?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Answer with your actual experience, including its limits. If you have not used a SIEM, say so and explain a proposed learning exercise rather than inventing a deployment. For genuine work, describe the data source, parsing, detection hypothesis, query logic, validation and one limitation. Distinguish a dashboard that displays events from a rule that creates actionable alerts. Explain what evidence supported the result, not merely which interface you opened. A narrow, reproducible lab is easier to defend than a broad claim, although it does not demonstrate production scale, operational ownership or real incident response.

Worked example: If you genuinely completed an owned Windows lab, describe the events you collected and a rule you tested. Otherwise present that same exercise as a plan, with expected observations rather than claimed results.

Common mistake: Claiming a production deployment from a tutorial makes follow-up questions difficult and misrepresents the experience you can actually demonstrate.

Follow-up: Which field mapping or collection gap most affected your actual work, or would you test first in your proposed lab?

• NIST Cybersecurity Framework 2.0Final · February 2024
• Microsoft Windows: event 4688Audit policy and field availability matter

Start with priority business risks and the investigations the SOC must support. Identity, endpoint, email and network logs commonly provide complementary views, but their order depends on assets and existing visibility. Validate timestamps, retention, parsing and collection health before declaring coverage. In Azure, AzureActivity covers subscription control-plane activity such as role-assignment writes; Entra AuditLogs and SigninLogs cover different directory and authentication evidence. For AWS, management events do not replace S3 object-level data events. Broader ingestion improves context but increases cost and sensitive-data exposure, so select purposeful sources and verify that expected test events actually arrive.

Worked example: In an authorised cloud lab, perform a subscription role change and a test sign-in. Expect evidence in separate logging streams, not one universal activity table; record any export or permission requirements before querying.

Common mistake: Assuming cloud activity logs include every sign-in and object read creates blind spots that dashboards may conceal rather than reveal.

Follow-up: How would you prove that S3 object reads are visible rather than merely assuming CloudTrail is enabled?

• NIST Cybersecurity Framework 2.0Final · February 2024
• AWS CloudTrail: management and data eventsLiving vendor documentation
• Microsoft Entra sign-in logsLiving vendor documentation

Begin with a testable hypothesis: which observable behaviour suggests a threat, and which legitimate activities resemble it? Specify required fields, grouping keys, time windows and expected analyst action. Validate collection and replay authorised benign and suspicious test cases before deployment. Sigma can express portable detection intent, but backend conversion still requires field and logic checks. Tune using representative observations rather than an arbitrary baseline period. Make exclusions narrow, owned and reviewable. Lower noise can also suppress real attacks, so assess missed test cases alongside alert usefulness and retain a rollback path when changing the rule.

Worked example: In an isolated lab, compare a documented administration script with a synthetic unusual PowerShell launch. Expect both to exercise parts of the rule; use the differences to justify scoped conditions rather than excluding PowerShell entirely.

Common mistake: Excluding every administrator or service account reduces noise by removing precisely the identities attackers may exploit for privileged access.

Follow-up: How would you test whether a new exclusion suppresses an attacker using an approved administration account?

• NIST Cybersecurity Framework 2.0Final · February 2024
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

Log correlation links observations using identities, devices, sessions, network attributes and time to test a shared explanation. A new sign-in, a forwarding-rule change and unusual downloads may support an account-compromise hypothesis, but the sequence is not proof by itself. Check timestamp normalisation, clock skew and whether identifiers genuinely refer to the same actor. Shared IPs and reused account names can create false joins. Correlation adds context that individual events lack, but wider time windows increase accidental matches. Record both supporting evidence and alternative explanations, and state which missing sources prevent a stronger conclusion.

Worked example: Create synthetic identity, mailbox and download records for one test user in an offline dataset. Expect matching session identifiers to strengthen the relationship; then add a second user behind the same IP to expose weak joins.

Common mistake: Joining events solely on a public IP can merge unrelated users behind shared gateways and manufacture a convincing but false storyline.

Follow-up: Which correlation key would you prefer over source IP, and what limitations would it still have?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• Microsoft Entra sign-in logsLiving vendor documentation

Useful Security events include 4624 for successful logons, 4625 for failed logons, 4672 for special privileges, 4688 for process creation, 4720 for account creation, 4768/4769 for Kerberos ticket activity and 1102 for Security log clearing. Event 7045, service installation, belongs to the System log. Interpret fields and host roles, not numbers alone: 4624 type 3 indicates network logon, while type 10 indicates RemoteInteractive. Event 4688 requires appropriate audit configuration; command-line inclusion needs additional policy and can expose sensitive arguments. More logging improves visibility but increases storage and access-control requirements, and missing events do not establish inactivity.

Worked example: On an owned Windows VM, enable the relevant process-creation auditing and launch a harmless command. Expect 4688 only when configured correctly; compare records before and after command-line inclusion to observe the additional detail.

Common mistake: Searching only the Security channel for 7045, or assuming 4688 always contains command lines, can produce misleading negative findings.

Follow-up: How would you distinguish an activity that did not happen from one that auditing failed to record?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• Microsoft Windows: event 4688Audit policy and field availability matter

User and entity behaviour analytics compares current activity with historical patterns, peer groups or other behavioural models to highlight deviations. It can reveal unusual access by otherwise valid credentials, but an anomaly is not a verdict and some attacks resemble ordinary work. Examine contributing events, baseline quality, role changes and service-account behaviour before escalating. New users, seasonal workloads and sparse logs can weaken the model. Behavioural monitoring also raises privacy and access-governance considerations. UEBA adds context beyond static rules, but it needs explainable investigations, suitable data and continued tuning rather than unquestioned reliance on a risk score.

Worked example: Use a synthetic lab dataset where a test user normally accesses one application, then accesses a new one. Expect an anomaly only if the model uses that feature; an approved role change provides a benign explanation.

Common mistake: Treating a high behavioural score as confirmed compromise bypasses evidence review and can penalise legitimate changes in working patterns.

Follow-up: How would you investigate an anomalous download by a user who recently changed teams?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

L1 commonly handles initial monitoring, evidence checks, playbook triage and escalation, while L2 commonly investigates broader scope, correlates sources and improves detections. These are organisational conventions, not universal permissions. Either tier may execute a pre-approved response, and either may need approval for disruptive action. Explain ownership through the team's responsibility matrix, escalation criteria and incident commander rather than assuming L2 controls every incident. Specialisation helps distribute work, but rigid boundaries can delay response if handoffs lose context. A useful development goal is stronger investigation reasoning supported by verifiable practice, not a claim to authority based on title.

Worked example: In a tabletop exercise, assign L1 to verify a suspicious sign-in and L2 to scope related sessions. Expect the written playbook, not seniority alone, to determine who may disable the test account.

Common mistake: Assuming promotion to L2 automatically authorises host isolation or account suspension confuses technical responsibility with the organisation's approved response permissions.

Follow-up: What would you do if containment seemed urgent but your role lacked permission to perform it?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

A good escalation restates the detection claim, records verification, explains contextual severity and requests a specific next decision. Include affected identities and assets, timestamps with time zones, evidence references, collection gaps, scope and actions already approved or completed. Separate observation from inference and explain why fix, defer, accept or false-positive handling is proposed. Acceptance of residual risk belongs to the designated risk owner, not an analyst acting alone. Concise summaries accelerate decisions, but excessive compression can hide uncertainty. Preserve detailed evidence behind controlled references rather than attaching confidential material to public tools or broadly accessible tickets.

Worked example: For a synthetic alert, write: unusual test-account sign-in verified; mailbox audit export unavailable; no containment performed; request identity-team session review. Expect another analyst to understand the evidence gap and next owner without repeating initial checks.

Common mistake: Writing only 'suspicious IP, please investigate' transfers uncertainty without the evidence, scope or decision request needed for an efficient handoff.

Follow-up: How would you communicate high potential impact when your confidence in compromise is still low?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2

Security orchestration, automation and response connects systems through repeatable workflows that gather context, manage cases and sometimes execute approved actions. It helps with structured enrichment and evidence collection when inputs, permissions and error handling are understood. Automated decisions still inherit stale data, parser errors and unsafe assumptions. Use least-privilege integrations, audit trails, human approval for consequential actions and tested rollback or recovery paths. Repeated execution should not create duplicate damage. Automation speeds consistent work, but a flawed playbook can spread mistakes faster than a person; keep uncertain interpretation and high-impact decisions under appropriate oversight.

Worked example: In a sandbox with synthetic alerts, build a workflow that adds asset ownership and opens a case without blocking anything. Expect missing ownership data to trigger a review path rather than an automatic containment decision.

Common mistake: Connecting an untested enrichment verdict directly to automatic account disabling can turn a data-quality problem into a widespread operational outage.

Follow-up: What should the playbook do if its enrichment service times out after a containment request has already been submitted?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• AWS IAM security best practicesLiving vendor documentation

Restate what the rule claims and inspect the underlying event before researching labels or technique names. Verify collection, fields, timestamps and asset context, then identify what evidence would confirm or weaken the hypothesis. Consult approved documentation and internal history without uploading confidential artefacts to public services. For files, preserve metadata and use an authorised analysis environment; never execute unknown samples on a workstation. Time-box research according to potential impact and escalate unresolved uncertainty. Learning independently improves understanding, but prolonged investigation can delay necessary response. Close as false positive only when evidence supports that outcome, not because the alert is unfamiliar.

Worked example: Use an unfamiliar synthetic service-installation alert in an owned Windows lab. Expect review of the System event, service path and approved change record to clarify the activity without executing any unknown service binary.

1. Restate the claim and preserve the alert with its underlying events.
2. Validate fields, time, asset context and detection prerequisites.
3. Check approved references and internal cases; gather evidence for competing explanations.
4. Assign contextual severity and escalate, or document a supported disposition.

Common mistake: Searching the alert name and copying the first verdict substitutes someone else's context for verification of your own underlying evidence.

Follow-up: What minimum evidence would you include when escalating before you fully understand the detection?

• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

Choose measures that support decisions: detection delay, acknowledgement and containment times, case ageing, escalation quality and rule-level usefulness. Define each clock and denominator, because incident start times may be unknown and averages can hide severe delays. Review distributions and case samples rather than rewarding fast closure alone. ATT&CK mappings describe technique relationships, not proven detection coverage or a complete compliance checklist. Test whether relevant telemetry and analytics work against authorised scenarios. Measurement helps identify bottlenecks, but targets can encourage premature closure or under-reporting. Pair operational numbers with evidence quality, missed detections and business-impact review.

Worked example: Compare two synthetic case queues: one closes quickly with unsupported verdicts, while the other documents scope and actions. Expect closure time alone to favour the weaker process; sampled evidence review reveals the missing quality dimension.

Common mistake: Counting mapped ATT&CK techniques as effective coverage ignores unavailable telemetry, untested logic and attacker variations outside the rule's assumptions.

Follow-up: How would you measure containment time when the incident start time and the first successful control action are uncertain?

• NIST Cybersecurity Framework 2.0Final · February 2024
• NIST SP 800-61 Rev. 3: Incident ResponseFinal · April 2025; supersedes Rev. 2
• MITRE ATT&CK version historyv19.2 shown at review; living knowledge base

Describe habits you actually use, or clearly frame your answer as a proposed approach if you lack shift experience. Start with a structured handover covering active incidents, deferred alerts, pending approvals and monitoring failures. Alternate queue checks with focused work according to team procedures, and take permitted breaks to maintain attention. Use checklists for consequential actions and request a second review when fatigue or uncertainty affects judgement. Quiet periods can support documentation, but not at the expense of coverage. Consistency improves reliability; the trade-off is avoiding a rigid routine that prevents immediate response to a developing incident.

Worked example: In a tabletop handover, record one unresolved test alert, its evidence gap, owner and next review time. Expect the incoming analyst to explain the next action without relying on an informal conversation or memory.

Common mistake: Claiming you never become tired discourages escalation and hides a human limitation that shift procedures should explicitly help the team manage.

Follow-up: How would you hand over an unresolved high-impact alert when your shift ends and the next analyst is delayed?