SOC Analyst Interview Prep: Hands-On Log Investigation Scenarios

In a junior SOC interview, almost anyone can recite what a firewall does or what port 443 is for.

Where most candidates stumble is the practical test. The interviewer hands you a snippet of twenty raw syslog or auth.log entries and asks: "Walk me through what happened here."

They want to see three things: 1. Can you identify the attacker vs the victim? 2. Do you understand whether the attack actually worked? 3. What exact steps would you take next to contain the incident?

What it looks like in logs: Dozens or hundreds of failed authentication events in a short window from a single IP, trying usernames like root, admin, test, or guest.

What to look for: Look for the final event in the sequence. Did the status change from "Failed password" to "Accepted password"? If every single event is a failure, it is an unsuccessful spray or brute force. If there is an accepted connection followed by a session opening, you have an active breach.

How to answer: State the source IP, the targeted user, the start and end timestamp, and whether authentication succeeded. Then mention you would immediately block the IP on the perimeter firewall and check for session activity on the destination host.

What it looks like in logs: HTTP GET or POST requests with URL-encoded characters like %27 (single quote), UNION, SELECT, or 1=1 in the query string.

What to look for: Check the HTTP response status code and the response body size. A 403 or 400 usually means a WAF or app filter blocked it. A 500 might indicate an unhandled database error (which the attacker will try to exploit further). A 200 with an unusually large response byte count often indicates data extraction.

How to answer: Explain what parameter was targeted, what payload was injected, and whether the server responded with 200 OK or an error code. Point out that a 200 OK requires inspecting backend database logs or application state to confirm if records leaked.

What it looks like in logs: A web application makes an internal outbound request to 169.254.169.254 (the AWS instance metadata service) or a CloudTrail log shows AssumeRole calls from an unfamiliar external IP address.

What to look for: Check the UserAgent string and the location of the caller. If credentials assigned to an EC2 IAM role are suddenly used from a residential IP or foreign cloud provider, the instance metadata token was stolen.

How to answer: Demonstrate that you understand modern cloud threats, not just 1990s network scans. Mention revoking the active IAM session immediately and enforcing IMDSv2 (session tokens).

Reading about attacks is not enough. You have to write the queries yourself.

Go to the PracticeSIEM cases list, pick three cases with different log formats (Linux auth.log, Apache web logs, and AWS CloudTrail), and work through the questions until you can spot the key indicators in under two minutes.