County public-health analysts need interactive SQL dashboards over clinic case metrics without managing classic Spark clusters. Which Azure Databricks compute should they use?
Select an answer to reveal the explanation.
Short Explanation
Think of a SQL warehouse like the county’s reading room for data—analysts walk in, ask SQL questions, and leave without wrenching on Spark cluster knobs. You'll get that always-on dashboard experience from the warehouse, while Job compute for SQL notebooks and interactive dashboard queries is ephemeral for automated runs so it'll be gone when clinic staff need live visuals, and An instance pool for SQL queries and interactive dashboard serving won't run SQL at all — it'll just hold VMs to speed up launches. You'll still have to size and babysit clusters with All-purpose compute for interactive notebooks and SQL analysis, so you don't get the cluster-free BI concurrency you're after.
Full Explanation
County public-health analysts who need interactive SQL dashboards over clinic case metrics without managing classic Spark clusters should use a SQL warehouse. Warehouses provide a SQL endpoint optimized for BI concurrency, Photon-accelerated query execution, and governance through Unity Catalog, while removing the operational burden of sizing, attaching to, and terminating classic all-purpose clusters for every dashboard refresh. That fit matches civic analytics: epidemiologists and analysts query curated metrics, not operate Spark executors.
Job compute for SQL notebooks and interactive dashboard queries is for ephemeral automated runs; it launches to execute a notebook job and terminates when done, so it does not provide a persistent concurrent SQL endpoint for daytime dashboard use. An instance pool for SQL queries and interactive dashboard serving is not a query engine; it only holds idle cloud VMs to speed cluster provisioning and still requires a real warehouse or cluster to execute SQL, so it cannot itself serve analyst dashboards. All-purpose compute for interactive notebooks and SQL analysis still requires analysts to size, attach to, and manage a Spark cluster themselves—exactly the operational overhead the stem wants removed—and it does not provide the BI-concurrency or governance benefits a purpose-built SQL warehouse gives dashboard users.
Exam caveat: SQL warehouses are the primary interactive SQL/BI compute in Azure Databricks; do not answer “all-purpose cluster” merely because SQL can also run in notebooks. Conversely, do not pick Job compute for SQL notebooks and interactive dashboard queries when the need is persistent dashboard serving; job compute is ephemeral for automated runs, not a concurrent BI endpoint. Serverless vs classic warehouse SKUs may appear in distractors—focus on the warehouse pattern itself when the stem emphasizes interactive SQL without classic cluster management.
Operational check: point the public-health dashboards at a sized SQL warehouse (serverless or pro per policy), grant analysts warehouse and table privileges via Unity Catalog, enable Photon if available, and validate concurrency and query history during clinic reporting peaks rather than attaching users to classic clusters.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.