Lesson 6 of 6 · About 6 minutes
Finding clues in a log file
Learn the concept.
A useful log search answers a specific question. Here you will find failed sign-ins, then read the surrounding records before deciding what the result means.
A search hit is only part of the sequence
Fictional auth.log, October 8, 2026. All times UTC.
- 09:02FAILED · jlee
Source 192.0.2.18
- 09:03FAILED · jlee
Same example source
- 09:04SUCCESS · jlee
Needs context; not proof of who signed in
Read the visualYour search returns two failed sign-ins. What should you do before calling it a breach?
The failures are observations. Surrounding successes, account context, and collection coverage help test explanations.
Search a copy with a clear purpose
In our fictional lab, grep FAILED /var/log/auth.log selects lines containing FAILED. This simulator uses a literal, case-sensitive search; real grep also supports patterns and options.
Keep the surrounding story
A filtered view can hide successful sign-ins and other context. Read the full small sample too. Retain timestamps, account names, source, and outcome when documenting an observation.
Separate observation from conclusion
Two failures followed by a success warrant context. They could reflect a mistyped password or misuse. A short sample does not establish who was at the keyboard or what happened outside the time window.
Put it in context
The sample has failures for jlee at 09:02 and 09:03 UTC, then a success at 09:04 from the same documentation address. You record that sequence and ask whether the activity was expected. You do not label it a confirmed breach.
Make a decision.
Explore the practice space, then answer the check-in below. A correct answer lets you save this lesson to your progress.
YOUR PRACTICE SPACE
Try the idea for yourself.
Enable JavaScript to explore this fictional exercise. The explanation and visual above remain available.
Take this with you.
Filter to find a lead, then widen the view to test what it means.
Explore a career track