SOC Analyst L1 Interview Questions: Evidence Guide

Why source freshness matters in SOC preparation

Security guidance changes. NIST published SP 800-61 Revision 3 in April 2025 and states that it supersedes Revision 2. Revision 3 positions incident response within Cybersecurity Framework risk-management activities. A preparation page that still presents Revision 2 as the current authority can teach stale framing even if some operational ideas remain useful.

ATT&CK also evolves. MITRE's live T1059 page identifies Command and Scripting Interpreter under the Execution tactic and lists platform-specific sub-techniques. Microsoft separately documents the meaning and fields of Windows security events. Those primary sources are stronger for technical claims than an unattributed interview list.

No primary source defines one universal SOC L1 interview. Employers use different telemetry, tooling, escalation rules, operating systems, and risk tolerances. The questions below are therefore reasoning drills. They are not represented as questions asked by every employer.

Alert-triage questions

What is the difference between an alert and an incident?

An alert is a signal produced by a rule, model, control, user report, or other detection source. It indicates that conditions matched, not that malicious activity has been proven. An incident is an occurrence that the organisation handles through its incident-management process based on evidence, impact, policy, and risk.

In an interview, avoid saying that you would immediately close or contain every alert. First state what the detection observed and what it did not observe. Check data completeness, entity identity, time, source, expected administrative activity, and nearby events. Then explain the evidence needed to classify the activity and the authority required for response.

How would you triage repeated failed logons?

Begin with the event contract and environment. Microsoft documents event 4625 as a failed logon. Examine the target account, source address or workstation when populated, destination host, logon type, status and substatus, authentication package, timing, and whether attempts are distributed across accounts or systems. Correlate successful logons and account changes where available.

Form multiple hypotheses. The pattern could reflect a user error, stale service credentials, a scheduled task, a device retaining an old password, a scanner, password spraying, or targeted guessing. Seek evidence that distinguishes them. A later successful session from the same source may change urgency, but it does not by itself prove compromise.

Do not invent a threshold such as a fixed count inside a fixed time window. The useful threshold depends on baseline volume, account sensitivity, source reputation, authentication flow, known automation, and false-positive cost. State how you would tune and review it using the organisation's own data.

What context makes a successful logon suspicious?

Microsoft documents event 4624 as creation of a logon session on the accessed machine. The event includes fields such as target account, logon type, authentication package, process information, source network address when available, and whether the token is elevated. Microsoft also explains that field population varies with authentication context and protocol.

A successful logon becomes interesting through context, not its event number alone. Compare the account, device, network source, logon type, time, privilege, preceding failures, subsequent process activity, and known work pattern. An expected service logon and an unexpected remote interactive session do not carry the same meaning. Label missing telemetry instead of silently treating it as benign.

What does a logoff event prove?

Microsoft documents event 4634 as completion of a logoff for an account. It can help delimit a session when correlation fields align. It does not prove that all processes stopped, that no persistence exists, or that the preceding activity was legitimate.

A good answer explains correlation. Match the appropriate account and logon identifier where available, consider the host and logon type, and review activity within the session. Do not join events merely because their timestamps are close.

MITRE ATT&CK questions

What does a T1059 alert mean?

MITRE ATT&CK defines T1059 as Command and Scripting Interpreter under the Execution tactic. Its sub-techniques cover different interpreters and platforms, including PowerShell, Windows Command Shell, Unix Shell, Python, JavaScript, and others listed on the live ATT&CK page.

A T1059 mapping says that observed behaviour relates to use of a command or scripting interpreter. It does not say that every interpreter launch is malicious. Administrators, applications, deployment systems, and users may invoke interpreters legitimately. The analyst must examine the exact sub-technique, parent and child processes, command line, user, host role, signature or provenance, timing, network connections, file activity, and neighbouring alerts.

How would you investigate a suspicious interpreter launch?

Start with the detection's raw evidence. Preserve the process record and command, identify the parent, user, integrity or privilege context, host, and start time, and note whether logging truncated or redacted any arguments. Compare the process chain with expected software and administrative workflows.

Then expand scope. Look for related script or file creation, downloads, encoded or obfuscated content, credential access, persistence changes, network connections, remote execution, and the same indicators on other hosts. ATT&CK can help name relevant behaviours, but it should not replace evidence or become a checklist of conclusions.

Choose response according to confidence, impact, and authority. An analyst may need to escalate before isolating a critical server. If containment is authorised, preserve enough evidence to support later analysis and document what access or business function the action may disrupt.

What is the difference between a tactic and a technique?

In ATT&CK, a tactic represents the adversary's goal or reason for an action, while a technique describes how an adversary may achieve a goal. T1059 is a technique associated with Execution. Its sub-techniques make the behaviour more specific to an interpreter or platform.

In an interview, map only what the evidence supports. A command interpreter launch may justify a T1059 mapping. It does not automatically prove initial access, persistence, privilege escalation, or lateral movement. Add those mappings only when corresponding behaviour is observed.

Incident-response questions

How would you structure an incident-response answer using current NIST guidance?

NIST SP 800-61 Revision 3 is a Cybersecurity Framework community profile for incident response. It explains that incident-response recommendations and considerations should be incorporated throughout cybersecurity risk-management activities to improve preparation, detection, response, and recovery.

For an interview scenario, structure the answer around decisions and evidence:

• confirm what was observed and whether telemetry is trustworthy;
• assess affected identities, hosts, data, services, and business impact;
• preserve relevant evidence and maintain an auditable timeline;
• coordinate with the people who own containment and business decisions;
• select containment that is proportionate and authorised;
• remove the cause or persistence only after scope is understood enough to avoid destroying evidence or triggering avoidable harm;
• restore safely, monitor for recurrence, and record lessons that improve controls and readiness.

This is not a verbatim NIST checklist. It is a practical answer structure consistent with integrating response into risk management. Consult the publication itself for organisational implementation.

What would you do with a confirmed malicious endpoint alert?

Even when malicious activity is confirmed, scope and impact may not be. Identify the affected host, user, process tree, observed payload or command, network activity, persistence, credentials exposed, and related systems. Preserve the evidence needed for the incident team and any legal or regulatory process that applies.

Containment might include host isolation, account restriction, blocking an indicator, or stopping a process, but the right action depends on authority, system criticality, attacker visibility, and business consequence. State whom you would notify and why. After eradication and recovery, verify expected service, watch for recurrence, and update detections or controls based on confirmed findings.

When should an L1 analyst escalate?

Escalate when the event exceeds your authority, playbook, access, technical depth, or risk tolerance, or when impact and uncertainty demand a broader decision. Examples include privileged identities, sensitive systems, suspected lateral movement, material data exposure, an active threat, unavailable evidence, or containment with meaningful business impact.

An escalation should carry useful evidence: alert identifier, time window, affected entities, raw observations, queries or pivots performed, hypotheses considered, known impact, unresolved questions, and recommended next action. Do not bury uncertainty, and do not claim a root cause that has not been established.

Detection and SIEM questions

How would you explain a detection query in an interview?

Describe the data source and why it can observe the behaviour. Name the event fields, grouping keys, time treatment, filters, exclusions, and output. Explain what the query detects, what it misses, and which legitimate behaviours may match. If the query uses a threshold, explain how the environment supplies and reviews that value.

The exact syntax depends on the employer's platform and schema. Memorising a vendor-specific query with placeholder field names can be misleading. A stronger answer writes syntax against a stated schema, then validates it with known matching and non-matching data.

How would you tune a noisy alert?

First determine whether noise comes from the rule, bad data, missing context, a known business process, or a detection whose intended scope was never defined. Sample true and false positives, preserve representative examples, and identify which fields reliably separate them.

Prefer narrow, explainable changes. Enrich with asset role, identity type, approved administrative source, or expected schedule when the data is trustworthy. Avoid a broad exclusion that hides the behaviour everywhere. Back-test the change, monitor its effect, document accepted blind spots, and keep a way to review excluded activity.

How would you handle missing telemetry?

Say explicitly what cannot be concluded. Check whether collection failed, the source never emitted the field, retention expired, time is misaligned, parsing failed, or access is restricted. Use another data source only if it observes the needed behaviour independently.

Absence of an event is not automatically evidence that the activity did not occur. Record the visibility gap, its effect on confidence, and the owner who can restore or improve collection.

Phishing and user-report questions

How would you triage a reported phishing message?

Preserve the original message and headers according to organisational procedure. Identify sender and reply paths, authentication results, recipient scope, links, attachments, message identifiers, delivery time, and whether anyone interacted. Use safe analysis controls rather than opening unknown content on a normal workstation.

Search for related delivery across the environment and for subsequent authentication, process, network, or mailbox activity. Distinguish a suspicious message from confirmed credential theft or code execution. Response may involve message removal, domain or URL controls, account protection, endpoint work, and user communication, but each action should follow evidence and authority.

Common weak answers

• A fixed failed-logon threshold with no environment. State what data and risk decision would set the threshold.
• An ATT&CK technique treated as proof of compromise. ATT&CK names behaviour; evidence and context determine disposition.
• An obsolete NIST revision presented as current. Revision 3 supersedes Revision 2.
• Immediate containment with no authority or impact check. Explain urgency, decision ownership, evidence preservation, and business consequence.
• A list of event IDs with no fields or correlation. Show how account, host, logon type, process, source, and session context change meaning.
• A confident root cause from one alert. Separate observation, hypothesis, corroboration, and confirmation.
• Tool names substituted for reasoning. Explain the data, query logic, limitations, and next decision.

Sources and verification boundary

• https://csrc.nist.gov/pubs/sp/800/61/r3/final
• https://attack.mitre.org/techniques/T1059/
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4624
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4625
• https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4634

These primary sources support the incident-response, ATT&CK, and Windows-event claims above. They do not establish a universal interview process, salary, cutoff, question count, promotion timeline, or mandatory SIEM product. Verify employer-specific requirements in the current job description.