A Delta table sets delta.logRetentionDuration to 30 days and keeps the default file retention for VACUUM. After a routine VACUUM run, an analyst queries the table with VERSION AS OF set to a version that was committed twenty days ago. What is the expected outcome?
VACUUM prod.sales.orders;
SELECT * FROM prod.sales.orders VERSION AS OF 118;- AThe query returns the rows as they stood at that version, because the log entry describing the version is retained for the full thirty days.
- BThe query is rejected before execution, because VERSION AS OF can only address versions committed within the past seven days on any Delta table.
- CThe query returns an empty result set, because VACUUM rewrites each historical version of the table so that it contains no rows at all.
- DThe query fails, because VACUUM has removed data files that the twenty-day-old version still references, even though the log entry for that version survives. Correct
Why A is wrong: This is tempting because the log retention setting really is thirty days, but a log entry only lists the data files a version needs; it does not keep those files alive once VACUUM has removed them.
Why B is wrong: Seven days is the default VACUUM file retention rather than a fixed limit on time travel syntax, so this invents a hard rule that Delta Lake does not enforce on the query itself.
Why C is wrong: VACUUM only deletes files that the current version no longer references and never rewrites historical versions, so an empty result would misrepresent what the command does.
Why D is correct: Correct, because time travel needs both the log entry and the data files it points to, and VACUUM deletes unreferenced files older than the retention threshold regardless of log retention.