🔄 Topic

Two Google Cybersecurity Certificate SQL labs today: filtering with WHERE and LIKE, then plain SELECT/FROM and sorting with ORDER BY. Small syntax, but the framing is the point — every query was tied to a security scenario, not just a database exercise.

🎯 Goal

Move from "I can write a SELECT statement" to "I know which SELECT statement answers a security question" — filtering machines that need updates, employees in sensitive departments, and login activity worth a second look.

🛠 What I Did

I worked through both labs against a MariaDB organization database.

Main areas covered:

used DESCRIBE on machines and employees to understand column names and types before writing a single query — a table of contents before reading the book
filtered machines with WHERE operating_system = 'OS 2' to find devices due for an update, out of 200 total machines
filtered employees with WHERE department = 'Finance' and 'Sales' to find who needed a confidential-handling notice posted to their office
used WHERE office = 'South-109' to trace a single reported issue to one employee, then widened it with LIKE 'South%' to catch every office in that building
ran SELECT * FROM machines and SELECT * FROM log_in_attempts to get full pictures of device and login data before narrowing anything
practiced ORDER BY login_date, login_time to turn a pile of login events into a chronological sequence, the first step toward spotting anomalies in it
scanned login country and time columns manually for out-of-region or off-hours activity — the manual version of what a WHERE clause or a SIEM rule would automate later

🔗 Key Cybersecurity Connections

Every query mapped to a real analyst task: WHERE operating_system = 'OS 2' is vulnerability triage — finding machines that share an exposure so they can be patched together. WHERE department = 'Finance' is scoping a privacy or compliance action to the right population. LIKE 'South%' is incident scoping — one broken machine reported, a whole building's worth of exposure found. And ORDER BY login_date, login_time is the first move in any login-anomaly hunt: nothing looks unusual until it's in order.

The manual-scanning task mattered specifically because it was tedious on purpose — 200 rows by eye is a lesson in why WHERE country != 'USA' exists, not just a syntax drill.

🔍 Investigation Questions

Which machines share an operating system that needs patching?
Which employees belong to a department that needs a targeted notice?
Does a single reported issue actually affect a wider group?
Are any login attempts coming from unexpected countries?
Do login times cluster in working hours, or does something stand out at 3am?

🚨 Detection Opportunities

Analyst habits this maps to:

unpatched-OS clustering via WHERE, to prioritize update campaigns
LIKE-pattern scoping to widen a single report into its full blast radius
country and time-of-day filters as first-pass anomaly triage on login data
ORDER BY as a prerequisite for any manual timeline review
DESCRIBE-first discipline before querying a table you don't fully know yet

Example:

project=sql-fundamentals
signal=off_hours_or_out_of_region_login
risk_area=credential_compromise
triage=order_by_date_time_then_filter_by_country_and_hour

🧭 MITRE ATT&CK Techniques

Possible mappings for the scenario being practiced:

T1078 — Valid Accounts (the login-anomaly scenario is exactly this: stolen credentials used from an unexpected place or time)

🗺 Visual Investigation Diagram

DESCRIBE the table
    ↓
SELECT the columns that matter
    ↓
WHERE narrows to the population in question
    ↓
LIKE widens a single report to its full scope
    ↓
ORDER BY turns a pile into a timeline
    ↓
Manual scan (today) → automated filter (next)

⚠ Challenges

The second lab was the harder one and it showed — I scored 0/3 on the first pass. Scanning 200 rows by hand for a country that isn't the US, or a username in a specific row, is exactly as error-prone as it sounds, and that friction is the lesson: this is precisely the task a WHERE clause exists to remove.

📚 What I Learned

I learned that SQL fluency for security work isn't about clever queries, it's about asking the right narrow question of the data — and that manual scanning, done badly today, makes the case for filtering better than any explanation would.

➡ Next Steps

Retry the second lab and get comfortable with WHERE-based anomaly filters instead of manual scanning
Practice combining WHERE and LIKE with ORDER BY in one query
Move toward aggregate functions (COUNT, GROUP BY) for the "how many" questions instead of counting rows by eye
Keep tying every new SQL keyword to a specific analyst task, not just syntax

🧠 Reflection

A 0/3 on manual scanning is a better lesson than a clean pass would have been — it made the case for filters more convincingly than the course text did.

🧩 Lessons Learned

What worked

Tying every WHERE and LIKE clause to a specific security scenario instead of memorizing syntax.

What broke

Manual scanning of 200 login rows on the second lab, scored 0/3 on the first attempt.

Why it broke

Human eyes are bad at exactly the pattern-matching task SQL filters exist to automate.

Fix / takeaway

Feel the pain of manual scanning once, then never do it again — that's what WHERE is for.

📈 Skill Progression Context

This supports my cybersecurity progression because SQL filtering and sorting are the entry point to every log-analysis and SIEM query I'll write later — today was the foundation, badly scored and well learned.

😄 TL;DR

Learned to filter, pattern-match, and sort a database — and manually scanning 200 rows made the case for WHERE better than any lecture could.