Data-Engineer-Associate - Troubleshooting, Monitoring, and Optimization (10% of the exam) - Section 6.4

Understand the features of Liquid Clustering and predictive optimization.

Explain how liquid clustering replaces static partitioning and Z-ordering, how clustering keys can be changed without rewriting the table, and how predictive optimization runs OPTIMIZE and VACUUM automatically on Unity Catalog managed tables.

liquid clusteringclustering keyspredictive optimizationOPTIMIZEVACUUM

Practice question for this objective

Free sampleTroubleshooting, Monitoring, and Optimizationmedium

A platform team currently maintains a nightly Lakeflow Job whose only work is to run OPTIMIZE and VACUUM across a schema of Unity Catalog tables. The schema holds both managed tables and several external tables registered over a partner storage path. The team is considering enabling predictive optimization for the schema instead. Which two statements about predictive optimization are correct? (Select TWO.)

AIt rewrites the clustering keys of each table whenever the query patterns against that table shift, so the team never has to consider which columns to cluster on.
BIt runs maintenance operations including OPTIMIZE and VACUUM on eligible tables automatically, so the team no longer needs to schedule those statements in a job of its own. Correct
CIt applies to every table the workspace can see, including tables that still live in the legacy workspace Hive metastore, which lets the team retire the job in one step.
DIt covers Unity Catalog managed tables, so the external tables in this schema still need their maintenance scheduled by the team rather than being handled for them. Correct
EIt removes the need for any file retention setting, because it keeps every historical data file so that time travel to any past table version continues to work.

Predictive optimization automates Delta maintenance such as OPTIMIZE and VACUUM, and covers Unity Catalog managed tables rather than external or legacy metastore tables. Predictive optimization decides when maintenance operations are worth running and executes them on the team's behalf, which is why a hand written maintenance job becomes redundant for the tables it covers. Its eligibility is scoped to Unity Catalog managed tables, so external tables in the same schema keep needing scheduled maintenance.

Why A is wrong: Tempting because the feature is described as predictive, but its job is to schedule maintenance operations, not to decide a table's clustering keys for the team.

Why B is correct: Running the file compaction and file cleanup operations on the team's behalf, at times it judges worthwhile, is exactly what the feature is for.

Why C is wrong: This overstates the scope: predictive optimization is a Unity Catalog feature, and tables in the legacy workspace Hive metastore are outside it.

Why D is correct: Eligibility is limited to managed tables, so a schema mixing managed and external tables is only partly covered and the external ones remain the team's responsibility.

Why E is wrong: It is tempting to assume automation makes retention moot, but the feature runs VACUUM, which removes files beyond the retention threshold rather than keeping them all.

See more Data-Engineer-Associate practice questions, answers explained.

Exam traps in Troubleshooting, Monitoring, and Optimization

Answers that look right on this material and are not. Each one is a distractor from a different question in the Data-Engineer-Associate bank for this domain.

Liquid clustering writes the same directory structure as partitioning, creating one folder per distinct clustering key value, and its contribution is that it selects those folders for the engineer automatically.
Why it is wrong: This is tempting because both techniques aim at data skipping, but liquid clustering keeps no physical directory layout for its keys; it organises data within files and records the layout in the table metadata, which is precisely why it avoids the small directory problem described.
Clustering keys are fixed at table creation, so a later change in the team's query filters would require the table to be recreated and reloaded from the source data.
Why it is wrong: This is tempting because partition columns really are fixed for the life of a table, but clustering keys are deliberately not: they can be redeclared at any time.
Liquid clustering guarantees exactly one data file for each distinct clustering key value, which removes the small file problem by construction on this table.
Why it is wrong: It sounds like a clean fix, but clustering groups similar rows into well sized files rather than promising a file per key value, which would recreate the same problem.

Examworthy is not affiliated with or endorsed by Databricks. Original, blueprint-aligned practice material only.