Databricks Certified Data Engineer - Associate

Explanation:

A. The SQL endpoint being used by each of the queries might need a few minutes to start up. → Valid. Databricks SQL warehouses (formerly endpoints) can take time to start if they're in a stopped state. This directly causes refresh delays. B. The queries attached to the dashboard might take a few minutes to run under normal circumstances. → Valid. If the underlying queries are long-running (e.g., scanning large datasets), refresh will naturally take minutes. C. The queries attached to the dashboard might first be checking to determine if new data is available. → Valid. Databricks SQL dashboards support query result caching and incremental refresh checks, which may involve checking for new data before re-running — this can add delay. D. The Job associated with updating the dashboard might be using a non-pooled endpoint. → Incorrect / Fails to explain. Databricks SQL dashboards do not use Jobs to refresh. They run queries directly on SQL warehouses (endpoints). There is no "job" involved in dashboard refresh. Also, "non-pooled endpoint" is not a meaningful concept in this context — SQL warehouses use managed resources, and pooling refers to cluster pools, not SQL endpoints. Thus, D is irrelevant and fails to explain the delay. E. The queries attached to the dashboard might all be connected to their own, unstarted Databricks clusters. → Valid. While less common now (since SQL warehouses are preferred), dashboard queries can be tied to classic clusters. If those clusters are stopped, they must start up — causing minutes of delay.