Check Your Knowledge

Test your understanding of the parallel run, cutover patterns, and rollback safety net before moving on to Unity Catalog and the privilege migration.

  1. Why is a parallel run’s window typically set to at least 30 days rather than just a few days? A. 30 days is a regulatory requirement B. It guarantees the window crosses at least one full month-end close, the highest-complexity workload most likely to surface bugs a normal day never exercises C. Databricks clusters need 30 days to warm up D. Oracle licenses are billed in 30-day increments

  2. What role does the reconciliation engine from the previous section play during the parallel run? A. It is disabled during the parallel run to save compute B. It runs nightly at full production volume, accumulating the audit-table evidence that a business sponsor ultimately relies on for the go-live decision C. It only checks schema, not row-level data D. It replaces the need for a financial close test

  3. Why does Lakeflow Jobs’ explicit task-dependency DAG often surface close-sequencing bugs that a legacy scheduler didn’t? A. Lakeflow Jobs runs faster than the legacy scheduler B. Legacy schedulers often encode sequencing as an implicit timing assumption rather than a declared dependency, so a downstream task can start before an upstream one has actually finished C. Lakeflow Jobs cannot run SQL tasks D. The legacy scheduler doesn’t support retries

  4. What is the main tradeoff of choosing big-bang cutover over phased cutover? A. Big bang is always cheaper in total compute cost B. Big bang finishes fastest but puts the entire business at risk simultaneously if a missed defect surfaces, with no smaller blast radius to contain it C. Phased cutover cannot be reconciled D. Big bang requires fewer Unity Catalog grants

  5. In the soft cutover, why are the read-only and read-write stages never combined into one event? A. Combining them is technically impossible in Databricks B. Read-only proves the read path works in isolation before the write path – where a bug risks losing a real transaction, not just showing a stale report – is trusted with anything C. Read-only stages are required by Unity Catalog D. Combining them would violate Delta Lake’s schema enforcement

  6. Why is decommissioning legacy (stage 3) the hardest of the three soft-cutover stages to reverse? A. It’s technically identical to stage 2 and carries the same risk B. It happens last, after read-only and read-write have already built a track record, and unwinding it means resurrecting a system deliberately being retired or archived C. Decommissioning is fully automated and cannot be paused D. Oracle cannot be restarted once frozen

  7. What distinguishes a real trust gate from just a green reconciliation dashboard? A. A trust gate requires defined criteria, evidence, a named business owner, and a recorded date – an accountable decision, not just a passing metric nobody has staked their name on B. A trust gate is a Databricks-native feature with no manual component C. A green dashboard is sufficient on its own to advance a cutover stage D. Trust gates only apply to the final decommission stage

  8. Why is SHALLOW CLONE (rather than production tables) recommended for rehearsing a rollback? A. Shallow clones cannot be queried B. It creates a cheap, metadata-only snapshot that lets the team practice the rollback procedure without any risk of mutating real production data C. Shallow clones are required for Lakeflow Jobs to run D. Shallow clones automatically fix any rollback errors

  9. What is the “cutover gap,” and why does it matter for rollback planning? A. The gap between Oracle and Databricks feature parity, irrelevant to rollback B. The window of writes Databricks has accepted as system of record that don’t yet exist in Oracle – it has to be measured, since a longer gap makes for a harder rollback C. The time difference between Oracle and Databricks cluster time zones D. The number of tables not yet migrated

  10. Why must the merge backfill used to close the cutover gap be idempotent? A. Idempotency improves query performance B. A rollback decision is often made under pressure, exactly the situation where a script might be re-run by someone unsure the first attempt succeeded – a non-idempotent backfill would duplicate rows on a second run C. Idempotent operations are required by Unity Catalog governance D. MERGE INTO only works on idempotent tables

Answer Key

  1. B – The 30-day window exists specifically to force at least one full month-end close through the parallel run, not to satisfy an arbitrary duration.
  2. B – The nightly reconciliation job keeps running through the parallel window at production scale, and its accumulated audit table is the evidence base for the go-live call.
  3. B – Legacy schedulers often rely on unwritten timing assumptions between jobs; an explicit DAG makes each dependency a declared, enforced condition.
  4. B – Big bang trades speed for risk concentration – everything moves and is exposed to defects at once, with no smaller wave to contain a problem.
  5. B – Isolating the read path removes one whole category of risk before the write path, where a bug means a lost transaction rather than a stale report, is trusted with production data.
  6. B – Stage 3 happens only after two prior stages have built confidence, and reversing it means bringing back a system that was deliberately retired.
  7. A – A trust gate requires an accountable, named, dated, evidenced approval – not just an engineer’s read of a dashboard.
  8. B – Shallow clone gives a cheap, isolated snapshot to rehearse against, with zero risk to the real production table.
  9. B – The cutover gap is the unreplicated write window once Databricks is system of record, and its size directly determines how hard the rollback backfill will be.
  10. B – A rollback executed under pressure is likely to be re-run; idempotent MERGE INTO logic prevents that re-run from duplicating data.

| ← Previous: Backfill and Rollback Pre-Testing | Next: Unity Catalog and the Privilege Migration → | |:—|—:|


Back to top

Independent, self-authored Databricks companion notes.

This site uses Just the Docs, a documentation theme for Jekyll.