Skip to content

Data Engineer Professional · Domain 5: Cost & Performance Optimization · 15% of the exam

Task 5.4: Apply Change Data Feed (CDF) to expose row-level changes (updates/deletes) for efficient incremental downstream processing.

Enabling the change feed, change types and metadata columns, reading by version or timestamp in batch and streaming, retention, and its limits.

Study it

  • Change data feed for incremental downstream processing

    Lesson coming

Sample questions

Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.

Question 1 · choose 1

A job reads the change data feed of main.sales.orders weekly, from the version after the last one it processed, and merges the rows into a downstream table. The job was broken for 40 days, and now the read fails because those versions are no longer available. The downstream table must become correct again and keep updating incrementally. What should the data engineer do?

  1. ARead the change data feed again from the old starting version, with failOnDataLoss set to false
  2. BUse RESTORE on orders to bring back the missing versions
  3. CTurn change data feed off and on again on orders
  4. DRebuild the downstream table from a full read of orders, then continue from the version current at that read
Show the answer and why
  • ARead the change data feed again from the old starting version, with failOnDataLoss set to false

    Incorrect

    Skipping the error would silently lose the 40 days of changes.

  • BUse RESTORE on orders to bring back the missing versions

    Incorrect

    RESTORE rolls the table back to an older state; it does not recreate removed change records and would discard newer data.

  • CTurn change data feed off and on again on orders

    Incorrect

    A change feed records only changes made after it is enabled.

  • DRebuild the downstream table from a full read of orders, then continue from the version current at that read

    Correct

    Change records are transient and removed with old table versions, so the gap cannot be read; a fresh snapshot and a new starting version restore correctness.

A change data feed is not a permanent record of every change. It is available only within the table's retention window, and versions removed from the log can no longer be read. To recover, reprocess the current state and start a new incremental read from the current version.

Question 2 · choose 1

A job reads a table's change data feed and applies updates downstream. It gets two rows for every updated record. Which rows should it skip to keep only the new values?

  1. ARows with _change_type = 'update_postimage'
  2. BRows with _change_type = 'update_preimage'
  3. CRows with _change_type = 'insert'
  4. DRows with an even _commit_version
Show the answer and why
  • ARows with _change_type = 'update_postimage'

    Incorrect

    The postimage holds the new values that must be applied.

  • BRows with _change_type = 'update_preimage'

    Correct

    The preimage holds the value before the update, and the postimage the value after it.

  • CRows with _change_type = 'insert'

    Incorrect

    Inserts are new rows that must be applied.

  • DRows with an even _commit_version

    Incorrect

    Commit versions identify table versions, not row images.

The change data feed adds _change_type (insert, update_preimage, update_postimage, delete), _commit_version and _commit_timestamp. An update produces a preimage row and a postimage row.

Question 3 · choose 1

An analyst needs all row-level changes of main.sales.orders since version 5, using SQL. Which query returns them?

  1. ASELECT * FROM main.sales.orders VERSION AS OF 5
  2. BDESCRIBE HISTORY main.sales.orders
  3. CSELECT * FROM main.sales.orders WHERE _commit_version >= 5
  4. DSELECT * FROM table_changes('main.sales.orders', 5)
Show the answer and why
  • ASELECT * FROM main.sales.orders VERSION AS OF 5

    Incorrect

    Time travel returns the table as it was, not the changes since then.

  • BDESCRIBE HISTORY main.sales.orders

    Incorrect

    History lists commits, not the changed rows.

  • CSELECT * FROM main.sales.orders WHERE _commit_version >= 5

    Incorrect

    _commit_version exists only in change feed output, not in the table.

  • DSELECT * FROM table_changes('main.sales.orders', 5)

    Correct

    table_changes returns the change data feed from the given version.

table_changes(table, startingVersion) reads the change data feed in batch SQL; in Python, use readChangeFeed with startingVersion.

Question 4 · choose 1

On Databricks Runtime 19, a team wants change data feed on a Unity Catalog managed Delta table without setting delta.enableChangeDataFeed. What does the table need?

  1. ARow tracking, which automatic change data feed relies on
  2. BDeletion vectors disabled on the table first
  3. CBoth legacy and automatic change data feed turned on together
  4. DPartitioning by the date the change was made
Show the answer and why
  • ARow tracking, which automatic change data feed relies on

    Correct

    Automatic change data feed computes changes at read time from row tracking on Delta tables.

  • BDeletion vectors disabled on the table first

    Incorrect

    Deletion vectors are not a requirement to turn off.

  • CBoth legacy and automatic change data feed turned on together

    Incorrect

    Legacy and automatic change data feeds cannot be used together.

  • DPartitioning by the date the change was made

    Incorrect

    Partitioning has nothing to do with the change feed.

Automatic change data feed needs Databricks Runtime 19 or above and a Unity Catalog table in Delta Lake format with row tracking, or Iceberg v3. It needs no per-table property, and it cannot be combined with legacy change data feed.

Question 5 · choose 1

A target table already holds data processed up to version 75 of a source table. A new stream must apply the source's changes from version 76 onward into the same target. How is the stream set up?

  1. AreadChangeFeed with startingVersion 76 and the target's old checkpoint
  2. BA batch read of the source with VERSION AS OF 76
  3. CreadChangeFeed with startingVersion 76 and a new checkpoint location
  4. DreadChangeFeed with startingVersion 0 and a new checkpoint location
Show the answer and why
  • AreadChangeFeed with startingVersion 76 and the target's old checkpoint

    Incorrect

    An existing checkpoint would override the starting version.

  • BA batch read of the source with VERSION AS OF 76

    Incorrect

    That reads one snapshot, not a stream of changes.

  • CreadChangeFeed with startingVersion 76 and a new checkpoint location

    Correct

    A streaming read from a starting version into an existing target needs a new checkpoint location.

  • DreadChangeFeed with startingVersion 0 and a new checkpoint location

    Incorrect

    Starting from version 0 reapplies changes the target already holds.

Change data feed can be streamed with readChangeFeed and a startingVersion. When writing to an existing target, specify a new checkpoint location.

Practice domain 5 →Practice all domains →