Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.
Question 1 · choose 1
A 2 TB Delta table is partitioned by region only so that five regional jobs can MERGE into it at the same time without write conflicts. The partitions have become full of small files, and most queries filter on order_date. The team wants fewer small files and good skipping on order_date without losing concurrent writes. What should they do?
AKeep the region partitions and add order_date as a second partition column
BKeep the region partitions and run OPTIMIZE ZORDER BY (order_date) nightly
CSwitch to liquid clustering on order_date and rely on row-level concurrency
DRun the five jobs one after another instead of at the same time
Show the answer and why
AKeep the region partitions and add order_date as a second partition column
Incorrect
Even more partitions make the small-file problem worse on a table of this size.
BKeep the region partitions and run OPTIMIZE ZORDER BY (order_date) nightly
Incorrect
This adds maintenance and keeps the over-partitioned layout that Databricks advises against for tables of this size.
CSwitch to liquid clustering on order_date and rely on row-level concurrency
Correct
Liquid clustering tables allow row-level concurrency, which reduces write conflicts without partition boundaries, and Databricks recommends it over partitioning for a table of this size.
DRun the five jobs one after another instead of at the same time
Incorrect
That removes conflicts by giving up the concurrent writes the team needs.
For a table of this size, Databricks recommends liquid clustering instead of partitioning. Liquid clustering tables support row-level concurrency, so concurrent writers conflict less without relying on partition boundaries.
Queries on a large table filter on device.region, a field inside the STRUCT column device. The team compares partitioning with liquid clustering for skipping on this field. Which TWO statements are correct? (Choose TWO.)
ALiquid clustering can use device.region as a clustering key
BPartitioning by device.region works if the table is over 100 TB
CPARTITIONED BY cannot use device.region as a partition column
DLiquid clustering needs device to be cast to VARIANT first
EZ-ordering by device.region can be combined with liquid clustering
Show the answer and why
ALiquid clustering can use device.region as a clustering key
Correct
Liquid clustering recognizes a struct field as a clustering key and is the only way to skip on it without extracting it.
BPartitioning by device.region works if the table is over 100 TB
Incorrect
Table size does not change the rule that partition columns must be top-level.
CPARTITIONED BY cannot use device.region as a partition column
Correct
Partition columns must be top-level; a struct field in PARTITIONED BY is treated as an expression.
DLiquid clustering needs device to be cast to VARIANT first
Incorrect
VARIANT is not a supported clustering type; the struct field is used directly.
EZ-ordering by device.region can be combined with liquid clustering
Incorrect
Liquid clustering is not compatible with ZORDER.
Partition columns must be top-level columns of supported types, so complex types and struct fields cannot be partition columns. Liquid clustering accepts a struct field as a key, which lets queries skip data on it.
An unpartitioned table receives appends in time order and is often filtered on recent dates. Why does it prune reasonably well without any partitioning?
ADelta creates hidden date partitions for every new table it writes
BThe disk cache keeps the most recent data files in memory
CUnpartitioned tables are clustered by ingestion time automatically
DZ-order is applied automatically on the date column on every write
Show the answer and why
ADelta creates hidden date partitions for every new table it writes
Incorrect
No hidden partitions are created.
BThe disk cache keeps the most recent data files in memory
Incorrect
Caching speeds reads; it does not prune files.
CUnpartitioned tables are clustered by ingestion time automatically
Correct
Ingestion time clustering gives partitioning-like performance on unpartitioned tables.
DZ-order is applied automatically on the date column on every write
Incorrect
Z-order is not applied automatically.
Unpartitioned Delta Lake tables automatically use ingestion time clustering, which gives partitioning-like query performance when data arrives in time order.
A data engineer creates a Unity Catalog managed Iceberg table with PARTITIONED BY (region). How does Unity Catalog treat this clause?
AIt uses region as a liquid clustering key
BIt creates Hive-style region partitions
CIt rejects the statement
DIt ignores the clause and leaves the table unclustered
Show the answer and why
AIt uses region as a liquid clustering key
Correct
For managed Iceberg tables, Unity Catalog supports only liquid clustering and interprets PARTITION BY columns as clustering keys.
BIt creates Hive-style region partitions
Incorrect
Managed Iceberg tables do not use partitioning.
CIt rejects the statement
Incorrect
The clause is accepted and mapped to clustering keys.
DIt ignores the clause and leaves the table unclustered
Incorrect
The columns become clustering keys.
Databricks recommends liquid clustering for managed tables. For managed Iceberg tables, Unity Catalog supports only liquid clustering and treats PARTITION BY columns as clustering keys.