Lesson 19 · Senior CDC practice

Mock senior CDC interview pack

A retrieval-first mock pack for turning the whole CDC / streaming-ETL course into clear, interview-grade answers you can say under pressure.

Your win: run a realistic senior CDC mock interview on yourself, score your answers honestly, and turn weak spots into a focused review plan.

How to use this page like the strongest lessons

This page works best if you treat it like a real interview instead of a study sheet. Answer first. Then check the points. Then answer again more cleanly. That rhythm matters because recognition is not the same thing as recall.

The earlier CDC lessons are strongest when they keep turning knowledge into action. This mock pack should do the same. It is less about reading and more about proving what you can actually say under pressure.

In plain English Plain English: answer out loud before checking the answer points. Recognition is not recall.

The format

You will run three rounds. Each round is trying to test a different kind of fluency, not just a different topic list.

The answer checklist A strong answer should usually include: (1) the model, (2) the main trade-off or risk, and (3) a repo-grounded consequence or example.

Round 1 · Core CDC model

  1. Why does this repo prefer log-based CDC over polling?
  2. What is the role of a replication slot?
  3. Why are publications managed by SQL migration here?
  4. What is the practical difference between a source and a sink connector?
  5. Why does the sink use upsert?
  6. Why are there three CDC stacks instead of “one pipeline”?
Round 1 · Strong answer points
  1. Log-based CDC. Read committed changes from the WAL in order, capture deletes, and avoid polling load.
  2. Replication slot. Retain WAL until the source connector consumes it, preserving continuity across outages.
  3. Publication by migration. The repo keeps table-replication intent explicit and versioned instead of letting Debezium auto-create it.
  4. Source vs sink. A source captures change into Kafka; a sink applies that change into another system.
  5. Upsert. It makes repeated delivery safe by applying the same logical change idempotently.
  6. Three stacks. Same technique, separate operational deployments: data-sync, KEC warehouse, and lmsdwh.

Round 2 · Safety and operations

  1. Why is source recreation riskier than sink recreation?
  2. What problem does incremental snapshot solve?
  3. Why isn’t at-least-once the full safety story?
  4. What does hephaestus really do?
  5. Why is the delete-guard so important?
  6. What is the real weakness of generated sinks with no DLQ?
Round 2 · Strong answer points
  1. Source risk. A source owns WAL continuity via the slot; a sink is only a derived applier.
  2. Incremental snapshot. Backfill existing rows for new tables without recreating the source connector.
  3. Safety boundary. Replay is safe only because the sink is idempotent, not because transport avoids repeats.
  4. hephaestus. Git-as-desired-state reconcile over live Connect clusters.
  5. Delete-guard. Prevent destructive churn on sources and ksqlDB-owned connectors; only JDBC sinks are safely deletable.
  6. No-DLQ weakness. Poison-record recovery is weaker even though restartability and monitoring exist.

Round 3 · Senior design judgment

  1. Why is schema evolution a pipeline problem, not just a DB migration problem?
  2. When would you choose outbox instead of plain CDC?
  3. How would you review whether a backfill plan is safe?
  4. How would you explain the no-DLQ trade-off honestly?
  5. What makes generated connector fleets operationally valuable?
  6. How would you summarize this repo’s CDC philosophy honestly?
Round 3 · Strong answer points
  1. Schema evolution. One source change can affect event schemas, sink config, destination tables, and warehouse transforms.
  2. Outbox choice. Use it when you need explicit domain-event intent and a cleaner answer to dual-write risk than table replication semantics alone provide.
  3. Safe backfill review. Check slot continuity, source update-vs-recreate choice, publication changes, and incremental-snapshot behavior.
  4. No-DLQ honesty. Operational simplicity is higher, but poison-record recovery and preserved failure evidence are weaker.
  5. Generated-fleet value. Reduce drift, encode intent declaratively, and make git the source of truth for a large connector surface.
  6. Repo philosophy. Use log-based CDC as the system of movement, generated connectors as the scalable config layer, and hephaestus as the reconcile guardrail — while staying honest about at-least-once, no-DLQ gaps, and slot-sensitive operations.

Self-scoring rubric

ScoreMeaning
0I could not explain it without notes.
1I gave fragments, but the answer was incomplete or fuzzy.
2I explained the main idea, but missed the trade-off, risk, or repo consequence.
3I gave a strong, clear answer with model + trade-off/risk + repo consequence.
Recovery map — where to go next Missed core CDC and Debezium? Revisit Lessons 1–4. Missed Connect, sinks, and hephaestus? Revisit Lessons 5–8. Missed transform, warehouse, and operations? Revisit Lessons 9–12. Missed senior judgment? Revisit Lessons 13–18.

Q1. The main rule of this mock pack is…

Retrieval first is what turns recognition into interview recall.
What are the three ingredients of a strong senior CDC answer?
recall, then click to reveal
A clear CDC or streaming model, the important trade-off or failure risk, and a repo-grounded consequence or example.
If you want, I can now run this as a live mock senior CDC interview and grade you answer by answer. Ask me.

Sources. This pack synthesizes the whole course into retrieval practice.