Try each one before opening the answer. Every option is explained, with the Databricks documentation page that proves it.
Question 1 · choose 1
Dashboards filter a 15 TB managed table only on event_date. In the query profile, the scan reads 98% of the table's files and the pruning metric shows almost nothing skipped. The table uses liquid clustering on customer_id, a key no dashboard filters on. What is the most effective fix?
AIncrease the warehouse size for the dashboards
BRecluster on event_date and run OPTIMIZE
CAdd a BROADCAST hint to the dashboard queries
DPartition the table by customer_id in addition to clustering it
Show the answer and why
AIncrease the warehouse size for the dashboards
Incorrect
More compute speeds up the scan but still reads almost every file.
BRecluster on event_date and run OPTIMIZE
Correct
Data skipping works on the clustering layout; clustering on the filter column lets scans prune files.
CAdd a BROADCAST hint to the dashboard queries
Incorrect
A broadcast hint changes join strategy; the problem is a scan that cannot skip files.
DPartition the table by customer_id in addition to clustering it
Incorrect
Clustering is not compatible with partitioning, and customer_id is not the filter column.
The query profile shows the percentage of data pruned during scanning. Little pruning on a filtered column means the layout does not match the filter; changing clustering keys and running OPTIMIZE realigns the files.
A performance engineer must open the query profiles of slow dashboard queries that other users ran on the warehouse wh_bi. They own none of the queries. What permission do they need?
ACAN MONITOR on the SQL warehouse wh_bi
BCAN USE on the SQL warehouse wh_bi
CSELECT on system.query.history
DUSE CATALOG on the catalogs the dashboards query
Show the answer and why
ACAN MONITOR on the SQL warehouse wh_bi
Correct
Viewing a query profile requires owning the query or at least CAN MONITOR on the warehouse that ran it.
BCAN USE on the SQL warehouse wh_bi
Incorrect
CAN USE lets a user run queries, not view others' profiles.
CSELECT on system.query.history
Incorrect
The system table holds query records, not the profile view.
DUSE CATALOG on the catalogs the dashboards query
Incorrect
Data privileges do not grant access to query profiles.
To view a query profile, a user must own the query or have at least CAN MONITOR permission on the SQL warehouse that executed it.
A long query has a large DAG in its query profile. Where can the data engineer quickly see which operators took the most time?
AThe Top operators panel of the query profile
BThe Query text panel of the profile
CThe SQL warehouse's monitoring page for that hour
DThe query's result table and row count
Show the answer and why
AThe Top operators panel of the query profile
Correct
Top operators lists the most expensive operators of the query.
BThe Query text panel of the profile
Incorrect
That shows the statement, not operator costs.
CThe SQL warehouse's monitoring page for that hour
Incorrect
Warehouse monitoring covers load, not one query's operators.
DThe query's result table and row count
Incorrect
Results do not include execution metrics.
The query profile has Details, Top operators and Query text tabs, and a DAG of operators with time, memory and row metrics. Top operators shows the most expensive ones.
A query profile shows a wall-clock duration of 2 minutes and an aggregated task time of 3 hours. What explains this?
AThe query waited 3 hours in the warehouse queue before it ran
BTask time sums all cores on all nodes, so parallel tasks add up
CThe metrics are wrong and should be ignored for a query this short
DThe query was served from the result cache after its first run
Show the answer and why
AThe query waited 3 hours in the warehouse queue before it ran
Incorrect
Queue time is part of the wall-clock duration.
BTask time sums all cores on all nodes, so parallel tasks add up
Correct
Aggregated task time combines execution time across cores and nodes.
CThe metrics are wrong and should be ignored for a query this short
Incorrect
The difference is expected with parallel execution.
DThe query was served from the result cache after its first run
Incorrect
A result served from cache does not add hours of task time.
Aggregated task time is the combined time across all cores of all nodes. It can be much longer than the wall-clock duration when many tasks run in parallel, and shorter when tasks waited for nodes.
A data engineer wants a support partner, who is not a member of the workspace, to examine a query profile. How can they share it?
ASend the partner the profile URL from the query history
BExport the query results to CSV and send the file
CGrant the partner CAN MONITOR on the SQL warehouse
DDownload the profile as JSON for the partner to import
Show the answer and why
ASend the partner the profile URL from the query history
Incorrect
The URL works only for users with CAN MANAGE on the query.
BExport the query results to CSV and send the file
Incorrect
Results do not contain the execution profile.
CGrant the partner CAN MONITOR on the SQL warehouse
Incorrect
A non-member cannot be granted workspace permissions.
DDownload the profile as JSON for the partner to import
Correct
Users without CAN MANAGE on the query, or outside the workspace, can receive the profile as a JSON download.
To share a query profile, send its URL to users with CAN MANAGE on the query; otherwise download it as JSON, which can be imported from the query history page.