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.
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. Full text: WORKED_EXAMPLES.md.
Your ADB home turf — the two most common Oracle Cloud (ADB) issues
ADB #1 · Performance & tuning (DB or SQL) → powers S1, S5, Q5
Your most frequent ADB work: AWR/ASH/SQL Monitor, execution plans, wait events, PX behavior, stats and plan stability (B1 is the proof story). Say it translated: “Same instinct — top SQL, waits, contention — on GCP the telemetry is Query Insights + pg_stat_statements + EXPLAIN (ANALYZE, BUFFERS), and Key Visualizer for Spanner/Bigtable hotspots.” Ranked habit: resource math first (connections, granted vs requested DOP), plan second, settings third, capacity last.
ADB #2 · Connectivity → powers S2, S4, S8
Your second most frequent ADB pattern: client → network → auth → service, layer by layer, with evidence at each layer (listener/TCPS and wallet discipline on OCI; on GCP: IAM → PSA/PSC → Auth Proxy/connector → SSL mode → connection limits → pool math). pcap discriminator: no SYN = local/policy, SYN+RST = refused, retransmits = path drop, TLS alert = SSL mode. Never guess the layer — name the test that separates them.
Behavioral · Full STAR stories (tap a story to open all 4 parts)
B1 · PX downgrade, SQL tuning — EXPERT · “No obvious solution”
Trigger: “Complicated technical problem, no obvious solution” / “Diagnose a slow query.”
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. [EXAMPLE — adjust: ~45 min → ~6 min at full DOP (~85% faster) + prevention guardrail. Replace with yours.]
B2 · HA/DR drills that proved failover — HPE/DXC + DATAMARK — EXPERT
Trigger: “HA/DR initiative” / “Validate DR actually works.”
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
Trigger: “Built a tool” / “Automation at scale” / Leadership.
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. [EXAMPLE — adjust: lookup ~30→5 min, ~15 engineers across two teams. Replace with yours.]
B4 · Unblocked a customer inside ADB's guardrails — EXPERT
Trigger: “Difficult blocker, no obvious solution” / “Customer down, constrained platform.”
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
Trigger: “Made the team better” / “Mentor or develop engineers.”
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. [EXAMPLE — adjust: colleague stuck on PX → independent within a quarter. Plus: Exceeds Expectations every Oracle appraisal since 2018. Replace example with yours.]
B6 · Failure: the delete with no WHERE — Rapiditos Bip Bip, first job
Trigger: “Tell me about a time you failed at work.” Own it in the first sentence.
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.
Interviewer questions · peers, conflict, influence, mobilize
Take your time on hypotheticals. Clarify before diving in. Talk the interviewer through your thinking like a coworker. Follow-ups mean depth wanted, not a wrong answer.
Q1 · Peers + cross-functional teams (empathy, teach, understand)
“Empathy first: I explain it the way I'd want it at 2 a.m. in an incident. At Oracle I coordinate across ADB Operations, Development, Networking, Infrastructure, Broker, and Control Plane — no authority over most, so clarity is the currency: crisp reproduction, business impact, one owner, kept cadence. As KM Coach I turn lessons into runbooks; as Scrum Master for 12 I unblock rather than direct. We for team outcomes; I for my actions.” Proof: B5, B3.
Q2 · Conflict with someone you work with (STAR)
S: [your real case — Engineering pushback on a product fix works]. T: “I owned getting us to a decision without burning the relationship.” A: Listen, let them finish. Restate their position until they agree you've heard it. “That's fair pushback — help me see the part I'm missing.” Evidence, not volume: reproduction + impact. Agree the cheapest test and the decision rule before running it. R: [fix shipped / decision + prevention written into the case/KB]. Never blame. Never “as I already said.”
Q3 · Influence teammates (3 strategies, each proven)
① Evidence over opinion — measured reproduction, customer impact (B1 discipline). ② Make it reusable — runbook, tool, or brown-bag so adoption beats resistance (B3, B5). ③ Cadence + single-threaded owner — people follow a kept update rhythm (every 30 min: known/unknown/next). Line: “I don't need to own the decision. I need the evidence in the room and one owner for the outcome.”
Q4 · Mobilize others (communication + decision-making)
“Single-threaded owner — me, if I raised it. A decision stated out loud, with the metric that would change it. Updates on a fixed cadence whether or not there's news, so nobody chases me. Then the write-up: decision, evidence, prevention, in the case/KB.” Proof: S10 shape on real sev work; Scrum Master for 12 under ambiguity.
Q5 · Complicated technical problem, no obvious solution (official prompt)
Use B1 (PX downgrade). Backup: B4 (ADB guardrails). Both really happened, both end with prevention. Do not invent a GCP story for this one.
Q6 · Hypothetical: satisfaction 80% → 90%, no new resources (4-Step)
Understand: “Give me just a minute to collect my thoughts.” Which measure? Which segment? Timeframe? What do the dissatisfied 20% actually say? No answers → state assumptions (post-case survey, one product area, one quarter). Prepare: existing — survey verbatims by case type, reopen/repeat rate, first-response and cadence adherence; historic — monthly trend; new, free — hand-audit low-scoring cases, code every verbatim by cause. “Same instinct as AWR: find the top waits.” Identify: weigh faster first response vs kept cadence vs killing the top repeat-case cause with runbooks vs earlier escalation. Commit: “My recommendation is: fix the top two detractor causes — missed updates and repeat issues — with a kept-cadence rule and a runbook for the top repeat case.” Support: weekly satisfaction, reopen rate, cadence spot-checks on the 80→90 path. If cadence rises and satisfaction doesn't, re-audit. The gain stays because it's a system, not a campaign.
Drill order: B1 aloud today (2 min, then 30 s). Day 8: all behavioral at speed + S10 handoff. Day 9: draw S1–S10 unseen. Q2 needs your real conflict case filled in before Day 9. Q6 in 4 minutes, no notes. 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
Drill 5 · SQL / BigQuery patterns (translated to TSE work)
| Pattern | Say it as TSE work | Key SQL |
|---|---|---|
| GROUP BY + HAVING count | Engineers/cases with >1 reopen | GROUP BY … HAVING COUNT(DISTINCT …) > 1 |
| Worked in ALL groups (division) | Instances present in every region/day | HAVING COUNT(DISTINCT grp) = (SELECT COUNT …) |
| Rank within group | Top errors per minute / per instance | RANK() OVER (PARTITION BY … ORDER BY …) |
| Median / percentile | p50/p95/p99 latency from logs | APPROX_QUANTILES(lat,100)[OFFSET(95)] |
| Latest row per key | Current status per instance/page | ROW_NUMBER() OVER (… ORDER BY ts DESC) + filter =1 |
| Cumulative with reset | New cases per day, monthly reset | SUM(…) OVER (PARTITION BY month ORDER BY day) |
| Overlapping ranges | Overlapping maintenance/incident windows | Self-join on start < other_end AND end > other_start |
| Set difference | Instances missing backups today | BigQuery EXCEPT DISTINCT (Oracle: MINUS) |
| Weighted median (summary buckets) | Median searches/case from pre-aggregated counts | Expand by bucket counts; cumulative SUM(num) OVER to the halfway row |
| Troubleshoot a given query | “This query is wrong/slow — find it” (narrate first) | Join fan-out? Missing filter? Wrong GROUP BY grain? Then plan: EXPLAIN |
| Concepts in one line each | ACID · indexes · joins · normalization | ACID = safe transactions. Index = faster reads, costlier writes. JOIN = combine on keys. Normalize to remove redundancy; denormalize deliberately for reads. |
Drill: pick one row, say the BigQuery version of the Day 7 log parser (TIMESTAMP_TRUNC(ts, MINUTE) + GROUP BY + window), then write it timed. Denormalization in one line: trade storage/redundancy for read speed — say the tradeoff, don't just define it.
Drill 6 · Reading/debugging code — Python, Shell/Bash, PL/SQL (JD phrasing)
Method for every exercise: read it aloud line by line → predict what it does → find the bug → name risk, fix, and test. Never edit first.
| Lang | Exercise (read/debug, timed) | Planted bug to find |
|---|---|---|
| Python | Log parser variant: counts errors but drops the last minute bucket | Bucket flushed only on minute change; final bucket never printed. Fix: flush after loop. |
| Python | Health-check poller that hammers a sick DB every second | No backoff/jitter, no consecutive-breach rule. Fix: 3 breaches + exponential backoff with jitter. |
| Bash | for f in $(ls *.log); do grep ERROR $f; done in a log dir | Word-splitting on filenames with spaces + unquoted var. Fix: glob + "$f", or find -print0. |
| Bash | Health script: psql -c 'select 1' || echo down with password in the script | Hardcoded secret + no timeout. Fix: env/Secret Manager, PGCONNECT_TIMEOUT, statement timeout. |
| PL/SQL | Cursor loop committing inside the loop every row | Commit-in-loop (slow, partial state, ORA-01555 risk). Fix: bulk collect + FORALL, single commit. |
| PL/SQL | EXCEPTION WHEN OTHERS THEN NULL; in a migration block | Swallowed exception hides every failure. Fix: log SQLERRM + raise; same bug class as the Python client. |
| Read-only | Java JDBC/Hikari stack trace + Node driver retry snippet | Read for: pool exhausted vs auth vs timeout. Name the layer; don't rewrite their code. |
Daily (3 h; 4–5 h Oct 23–26): one Drill 6 row aloud + one timed write. Extra close-day hours go to mocks and reading/debugging, not new facts.
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.