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?
ARead the change data feed again from the old starting version, with failOnDataLoss set to false
BUse RESTORE on orders to bring back the missing versions
CTurn change data feed off and on again on orders
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.
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?
ARows with _change_type = 'update_postimage'
BRows with _change_type = 'update_preimage'
CRows with _change_type = 'insert'
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.
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?
ARow tracking, which automatic change data feed relies on
BDeletion vectors disabled on the table first
CBoth legacy and automatic change data feed turned on together
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.
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?
AreadChangeFeed with startingVersion 76 and the target's old checkpoint
BA batch read of the source with VERSION AS OF 76
CreadChangeFeed with startingVersion 76 and a new checkpoint location
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.