Lab Objective

Google Cybersecurity Certificate activity: “Perform a SQL query.” Practice the most basic SQL sentence structure — SELECT … FROM — and use ORDER BY to turn unordered results into a chronological sequence, applied to device-update and login-anomaly scenarios.

Honest result: scored 0/3 on the first pass. Manual row-scanning is exactly as error-prone as it sounds, and that turned out to be the real lesson.

Lab Environment

  • Course: Google Cybersecurity Certificate
  • Database: organization (MariaDB shell)
  • Tables used: machines, log_in_attempts
  • Reconnect command if the shell disconnects: sudo mysql organization

Scenario

Two tasks: figure out which employee devices need updating using the machines table, and investigate log_in_attempts for unusual activity — logins from unexpected countries, or at unexpected hours — the kind of pattern that flags a possibly stolen credential.

Commands Practiced

Command Purpose
SELECT * FROM table; Return every column and row
SELECT col1, col2 FROM table; Return only named columns
ORDER BY column; Sort results by one column
ORDER BY col1, col2; Sort by one column, then break ties with a second

Step 1 - Get the Full Picture of Device Data

SELECT * FROM machines;

Returns all 200 rows and every column: device_id, operating_system, email_client, OS_patch_date, employee_id. Reading a SQL query as a sentence helped it stick: SELECT = which details, FROM = which table, ; = the period that says “run this.”

Narrowing to specific columns:

SELECT device_id, email_client FROM machines;

Third row returned: Email Client 2 (device a305b818c708).

SELECT device_id, operating_system, OS_patch_date FROM machines;

First entry’s patch date: 2021-09-01. The point of pulling OS_patch_date specifically: an old patch date is how you flag a machine that’s actually vulnerable, not just old.

Step 2 - Scan Login Attempts for Unusual Activity

SELECT event_id, country FROM log_in_attempts;

Scanned manually for any country outside expected operating regions (US, Canada, Mexico) — a login from somewhere the organization has no presence is a red flag for credential theft.

SELECT username, login_date, login_time FROM log_in_attempts;

Scanned for logins outside working hours — the classic 3am login on a stolen credential, betting nobody notices a “new login” alert while asleep.

SELECT * FROM log_in_attempts;

All columns, all 200 rows — and manually scanning that many rows by eye to catch two different anomaly types is where the lab (correctly) started to hurt.

Step 3 - Order the Data Into a Timeline

SELECT *
FROM log_in_attempts
ORDER BY login_date;

Sorts every login attempt into date order — the first real step toward a readable timeline instead of a random pile of rows.

SELECT *
FROM log_in_attempts
ORDER BY login_date, login_time;

Adding login_time as a second sort key means SQL sorts by date first, then breaks same-date ties by time — producing a genuinely chronological sequence, not just a date-grouped one.

Honest Result: 0/3 on the First Pass

I did not confirm the multiple-choice answers for the country-scan, the fifth-row username, or the specific first-record-by-date/time questions before the timer ran out — this lab is going back on the list for a retry. What I did confirm directly from the sample output:

  • third row’s email client: Email Client 2
  • first entry’s patch date: 2021-09-01

The rest — whether any login came from Australia, which username sits in the fifth row, which record leads the date-then-time sort — needs a rerun with more care instead of a guess.

Security Takeaways

  1. SELECT * is a starting point, not a habit. Full-table pulls are fine for orientation; real analysis narrows to the columns that answer the question.
  2. ORDER BY is the prerequisite for timeline review. Nothing about login activity looks anomalous until it’s actually in chronological order.
  3. Multi-column ORDER BY resolves ties deliberately. ORDER BY login_date, login_time sorts by date first and only uses time to break same-day ties — the order of columns is the order of priority.
  4. Manual scanning does not scale, and feeling that firsthand is the lesson. 200 rows by eye, twice, for two different anomaly types, is exactly the workload a WHERE filter exists to remove.
  5. A 0/3 is still evidence. It shows precisely where the friction is — reading scanned output carefully under time pressure — and that’s worth logging honestly instead of glossing over.

Where This Applies Beyond the Lab

ORDER BY login_date, login_time is the first move in any real login-anomaly investigation — a SIEM timeline view is doing exactly this sort, just automatically and at a scale no analyst could match by eye. This lab’s low score is the argument for learning WHERE-based filtering next, rather than ever relying on a manual scan again.