Databricks Certified Data Engineer - Professional
Comments
Loading comments...
Ultimate access to all questions.
To prevent accidental commits to production data, a senior data engineer implemented a policy requiring all development work to use clones of Delta Lake tables. After evaluating both DEEP and SHALLOW CLONE, the team opted for SHALLOW CLONE to create development tables.
Several weeks later, cloned versions of certain Type 1 Slowly Changing Dimension (SCD) tables stop functioning. The transaction logs of the source tables indicate that VACUUM was executed the day before the issue arose.
What explains why the cloned tables are no longer working?
A
Because Type 1 changes overwrite existing records, Delta Lake cannot guarantee data consistency for cloned tables.
B
Running VACUUM automatically invalidates any shallow clones of a table; DEEP CLONE should always be used when a cloned table will be repeatedly queried.
C
Tables created with SHALLOW CLONE are automatically deleted after their default retention threshold of 7 days.
D
The metadata created by the CLONE operation is referencing data files that were purged as invalid by the VACUUM command.
E
The data files compacted by VACUUM are not tracked by the cloned metadata; running REFRESH on the cloned table will pull in recent changes.