All days & topics
Tap any day to open it — past days included, for days you couldn't study. Your last-opened day is remembered on this device. Use the tabs above for Listen, Flashcards, and drills for that topic.
Day 1 — Frameworks + Foundations
Fri Oct 17 · Own the rubric. GCP resource hierarchy, IAM, VPC, PSA vs PSC.
0 of 10 days checked off
Lab & scenarios
Today's practice loop — use all three, every day:
Do the lab in Google Cloud Console / Skills Boost — steps above are the whole assignment. Spoken version: MOCK_PROMPTS.md (paste one scenario into Gemini Live). Model narration: Listen tab, today's episode.
The 4 words they score
Understand → Prepare → Identify a solution → Support your solution.
Behavioral = STAR: Situation (2–3 sentences) → Task (“I owned…”) → Action (longest) → Result (X as measured by Y by doing Z + what you changed so it wouldn't recur).
Listen while you move
12 episodes (E1–E8 study + E9–E12 daily repetition). Play the MP3 (works in the car / Files app) or tap Read aloud to use your phone's voice. After each episode, pause and say the key line out loud — that repetition is the study. New: MOCK_PROMPTS.md (Gemini Live S1–S10) · HANDOFF_NOTE.md (Day 8 drill) · see STUDY_PLAN_V2.md for the persona-improved daily repetition stack.
Front = the cue. Say your answer out loud. Then flip to check. Back (blue) = the answer you should have said.
Scenario drill (6–8 min each)
S1–S10 are the interview set. X1–X4 are extra practice variants. Pick one (or jump from Today's Lab card). Start the timer. Work the 4 steps out loud, checking each off. Only then open the model outline. Spoken-interviewer version: MOCK_PROMPTS.md.
Model outline (open only after your aloud attempt)
Worked examples — your real stories
Source: your Mastercard prep file (real examples) + resume. Behavioral (“Tell me about a time…”) = STAR. Hypothetical (“Your customer reports…”) = Understand → Prepare → Identify → Support. Anything in [brackets] is yours to fill with the real detail — never invent a number. Full text: WORKED_EXAMPLES.md.
Behavioral · STAR (say “I owned…” in Task)
B1 · PX downgrade, SQL tuning — EXPERT · “No obvious solution”
S: A customer's SQL requested a high degree of parallelism (DOP) and was not getting it; the query ran far longer than expected.
T: I owned finding why parallel execution was downgraded, and tuning statement + settings.
A: PX tracing, then the real plan via SQL Monitor / DBMS_XPLAN with PX detail: requested vs granted DOP + downgrade reason. GV$SQL_MONITOR (PX_MAXDOP/PX_INSTANCES + cause, e.g. PARALLEL_SERVERS_TARGET or stale-stats adaptive DOP); V$PX_SESSION / GV$PX_PROCESS_SYSSTAT for what actually ran. Traced to [fill in: resource-manager limits / stale stats / PARALLEL_DEGREE_POLICY=AUTO].
R: Tuned statement + PDB parallel settings; SQL Monitor confirmed full requested DOP, no downgrade; complaint resolved. [Fill in: before/after runtime + prevention guardrail.]
B2 · HA/DR drills that proved failover — HPE/DXC + DATAMARK — EXPERT
S: Two real DR environments needed validated, tested failover. Not architecture on paper.
T: I had to prove the standby could take over inside RTO/RPO targets.
A: Data Guard Broker validated (DGMGRL show configuration / validate database), redo transport + apply lag in tolerance (V$DATAGUARD_STATS), managed switchover (not destructive failover). At DATAMARK: quarterly drill restoring a production-equivalent copy from RMAN + Data Pump on a spare server, measuring real recovery time vs RTO.
R: AM/NS Calvert (steel, onsite lead DBA, HPE/DXC): [fill in: switchover test, RTO/RPO validated, runbook]. DATAMARK: recovery became a proven quarterly procedure, not an assumption. [Fill in: restore time / gap a drill caught.]
B3 · Tooling automation, two teams — Oracle ADB + DATAMARK — EXPERT
S: SOPs, playbooks, and doc lookups for proactive/reactive ops work were manual and scattered.
T: I owned building automated access to the right tool, doc, or playbook per situation.
A: Python + shell automation for ADB-Serverless Ops (SOPs/playbooks/docs), extended to ADB Support: allowed tools, knowledge base, bug lookups, ORA- diagnosis from trace files (ADB-S + ADB-D). At DATAMARK: automated backup/config reporting (Perl/Python/shell).
R: Manual lookup and repetitive diagnostics cut across two teams; DATAMARK got automated backup/config visibility. [Fill in: hours saved/week, engineers using it, or time-to-diagnosis cut.]
B4 · Unblocked a customer inside ADB's guardrails — EXPERT
S: An ADB customer's workload was blocked by the locked-down default config. ADB restricts init parameters by design.
T: I had to resolve it safely inside ADB's supported parameter model. No platform-wide exception.
A: Mapped the issue [fill in: optimizer behavior / parallel degree policy / session limit] to ADB's documented PDB-level modifiable set (ALTER SYSTEM … SCOPE=PDB), verified against Oracle's customizable-parameter list, enabled it for that PDB only.
R: Workload unblocked inside the supported model. No engineering escalation, no platform change. [Fill in: actual parameter + workload + KB entry left behind.]
B5 · Mentoring + brown-bags — KM Coach / Scrum Master (12) — Leadership
S: New ADB Ops and DB Perf/DWH colleagues needed to ramp on deep, poorly documented topics.
T: As Knowledge Management Coach and Scrum Master, I owned the team's collective depth.
A: Direct mentoring plus brown-bags: PX internals, Codex, agentic AI (agents, skills, MCP, closed-loop workflows), turned into practical guidance. “We” for team, “I” for my actions.
R: More self-sufficient team; fewer repeat PX questions; working agentic-AI diagnostic habits. [Fill in: one colleague stuck → independent, or one workflow adopted.]
B6 · Failure: the delete with no WHERE — Rapiditos Bip Bip, first job
S: Fresh out of school, supporting Oracle Financials + PL/SQL interfaces from Retail Management. The accounting manager asked me to delete specific rows from an AP accounting table.
T: I owned that delete. Exactly those rows, safely.
A: Trying to help quickly, I ran delete from ap_…; commit; with no WHERE clause, and committed. Every record, gone. I owned it immediately, went to our DBA, and together we recovered the data from undo with a flashback query (AS OF TIMESTAMP) before the undo window closed.
R: Data recovered, no permanent loss. Lesson kept for 23 years: failures are expected, learning is the job. Since then, every production delete gets: WHERE verified, row count with the same predicate, backup/export of affected rows, and a second pair of eyes before commit.
30 s: “I deleted every row of an AP table, no WHERE clause, and committed. I owned it, recovered from undo with our DBA, and have never run an unguarded production delete again.”
Hypothetical · 4-Step (say the four words)
S1 · Cloud SQL 10× slower — your B1 discipline, translated
Understand: scope, onset, changes, impact. Prepare: instances describe, connections vs max_connections, Query Insights, pg_stat_statements, EXPLAIN (ANALYZE, BUFFERS). Identify: ① connection saturation ② bad query/bloat ③ CPU/IO ④ failover/maintenance. Mitigate first. Support: p95 at baseline 24h; headroom >20%; alert + runbook. Parallel you executed: B1 (requested vs granted DOP).
S2 · Too many connections
Understand: replicas × pool per replica? Prepare: connections vs max_connections, pool/idle config, Proxy logs. Identify: math first (10×50=500 vs 400). IAM → PSA/PSC → Proxy → SSL → limits → pool math. Pooling before tier. Support: <70% at peak for a week; zero errors; budget calculator.
S3 · Objects disappearing
Understand: bucket/prefix, onset, age pattern, versioning, delete rights. Prepare: lifecycle, retention/Bucket Lock, soft delete, versioning, Data Access audit logs. Identify: lifecycle rule → soft-delete confusion → over-privileged SA → retention. Recover via versioning/soft delete. Support: zero unexpected deletions 14 days; delete alerts.
S4 · 403s + slow uploads (two symptoms)
Understand: split it live. Prepare: IAM + Policy Troubleshooter, VPC-SC/org-policy audit logs; key naming, client region. Identify: IAM vs org policy vs VPC-SC; uploads: sequential prefixes, resumable/parallel composite, backoff+jitter. Support: 403s → 0; upload p95 up; runbook.
S5 · Spanner aborts
Understand: key design, write pattern, what changed. Prepare: Key Visualizer, SPANNER_SYS stats, CPU vs guidance, abort rate. Identify: monotonic hotspot → large RW txns → capacity → index hotspot. UUID/bit-reversed + smaller txns first. Support: abort rate + p95 in SLO for a load cycle.
S6 · Firestore index + throttling
Understand: which query, Native/Datastore, new or ramped. Prepare: exact error (index link vs security-rules denial), key pattern. Identify: composite index, then randomized IDs + sharded counters; 500/50/5. Support: zero index errors; ramp test in SLO.
S7 · Bigtable hot tablets
Understand: access pattern, row-key design. Prepare: Key Visualizer, node CPU, hot tablets, row size. Identify: leading key field first; promote device/tenant/user before timestamp. Capacity second. Support: p99 in SLO; even tablet heat.
S8 · Pods can't reach Cloud SQL (humility)
Understand: gap line early, calm. Prepare: kubectl pods/describe/logs/events, sidecar logs, Workload Identity, DB connections, pcap 5432. Identify: DNS → sidecar → WI → DB limit → policy/PSA. No SYN / SYN+RST / retransmits / TLS alert. Name where the platform owner joins. Support: connect rate + connections in budget 24h.
S9 · Migrate 20 TB Oracle (3-min design)
Understand: ask first — pattern, global reach, PL/SQL/RAC/GoldenGate, downtime, license, skills. Prepare: assessment: top SQL + feature inventory. Identify: Cloud SQL vs AlloyDB vs Spanner vs Oracle DB@GC; DMS (migration) + Datastream (CDC subset), DMS ≠ bidirectional GoldenGate. Commit. Support: checksums/row counts, rehearsed cutover, rollback.
S10 · Sev-1, angry customer (your anchor)
Understand: two plans in parallel; I am the single-threaded owner. Prepare: dashboards, logging, change list, rollback/failover options, first update out on cadence. Identify: mitigate first, root cause with Product Eng/SRE in parallel, 30-min known/unknown/next-update. Support: real MTTR, cadence 100%, runbook/KM + 5-line handoff (HANDOFF_NOTE.md). Executed parallels: B3, B4, B2.
Drill order: B1 aloud today (2 min, then 30 s). Day 8: all behavioral at speed + S10 handoff. Day 9: draw S1–S10 unseen. Full text + drill notes: WORKED_EXAMPLES.md.
Code drills — narrate before you edit
Shared-doc round: clarifying questions + test cases, Big-O, malformed input, tradeoffs. The narration is what's scored.
Drill 1 · Log parser — top 5 errors/min + p50/p95/p99
import re, collections
pat = re.compile(r'(\d{4}-\d{2}-\d{2}T\d{2}:\d{2}):\d{2}.*?(ERROR|WARN):(\w+).*?latency=(\d+)ms')
buckets = collections.defaultdict(list)
errors = collections.defaultdict(collections.Counter)
for line in open('db.log'):
m = pat.search(line)
if not m: continue # malformed: skip + count
minute, level, code, lat = m.group(1), m.group(2), m.group(3), int(m.group(4))
buckets[minute].append(lat)
if level == 'ERROR': errors[minute][code] += 1
for minute in sorted(buckets):
lats = sorted(buckets[minute])
pct = lambda p: lats[min(len(lats)-1, int(len(lats)*p))]
print(minute, errors[minute].most_common(5), pct(.5), pct(.95), pct(.99))
Talk track: regex → bucket by minute → Counter → sort for percentiles. O(n log n). Then say the BigQuery version: TIMESTAMP_TRUNC(ts, MINUTE) + GROUP BY + window functions.
Drill 2 · Health check — connections + replica lag
SELECT count(*) FROM pg_stat_activity; SELECT EXTRACT(EPOCH FROM (now() - pg_last_xact_replay_timestamp()));
Alert after 3 consecutive breaches (no flapping). Backoff with jitter — never hammer a sick DB. Run as cron / Cloud Run / Monitoring alert.
Drill 3 · Auditor — flag public buckets & no-backup instances
gcloud storage buckets list --format=json # iamConfiguration.publicAccessPrevention gcloud sql instances list --format=json # backupConfiguration.enabled / PITR
Parse defensively (.get with defaults). This is the JD's “build investigation tools” in Python.
Drill 4 · Buggy client — name all 5 before editing
Cheat sheet
Decision matrix — 30-second answers
| Need | Pick | Trap |
|---|---|---|
| Objects / lake | Cloud Storage | Lifecycle deletes by surprise |
| Managed MySQL/PG/SQL Svr | Cloud SQL | HA = active-standby; replicas ≠ HA; mostly connectivity |
| Hi-perf PG + analytics | AlloyDB | Not “Exadata on GCP” |
| Global, strongly consistent | Spanner | Monotonic keys hotspot |
| Documents, mobile/web | Firestore | Composite indexes; 500/50/5 ramp; sequential IDs |
| Massive wide-column | Bigtable | Row key is everything; single-row atomicity |
| Cache / session | Memorystore | Private-only; watch eviction/memory |
| Analytics over logs | BigQuery | Warehouse — answer by access pattern |
| Stay on Oracle | Oracle DB@GC | Oracle-operated; not GCP-native |
Checklists
Can't connect (Cloud SQL): IAM → PSA/PSC → Proxy/connector → SSL → limits → pool math.
Disappearing objects: lifecycle → retention/Bucket Lock → soft delete → versioning → Data Access audit log.
Hotspot: Key Visualizer → leading key field → UUID / bit-reversed / hash prefix / promote high-cardinality field.
GKE→DB: DNS → sidecar → Workload Identity → DB limit → network policy. Capture: no SYN = local/policy · SYN+RST = refused · SYN+retransmits = path drop · TLS alert = SSL mode.
Gap line — never bluff
Resources (official first)
TSE Prep Guide ·
Database Engineer Learning Path ·
Google Cloud Tech (YouTube) ·
SRE Books (free)
Full day-by-day watch/read/do list: open RESOURCES.md in this folder.