DP-900 Describe an analytics workload on Azure Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Serverless SQL pool

  Why this is correct

  Serverless SQL pool fits ad hoc SQL queries on large lake volumes because it provisions no fixed compute; the service spins up compute per query, reads data directly from Azure Data Lake files (Parquet, Delta, CSV), and bills only for the amount of data scanned. This on-demand model eliminates idle costs and delivers fast T-SQL responses for unpredictable workloads, making it ideal for occasional analytical bursts. Of the four options, it is the only one designed specifically as a serverless T-SQL query endpoint over data lake files.

• ✗

  Dedicated SQL pool

  Why it's wrong here

  Dedicated SQL pool is provisioned as a fixed cluster of Synapse compute nodes with defined DWUs, so you pay per running hour even when no queries execute, making it expensive for sporadic ad hoc analysis. It trades cost for performance reliability, giving predictable outcomes through table distribution, indexes, and materialized views, but requires capacity planning and manual scale operations. For occasional, unpredictable queries that do not need that persistent, optimized schema, this offering is overkill and carries prohibitive idle-time costs.

• ✗

  Apache Spark pool

  Why it's wrong here

  Apache Spark pool is a managed big-data compute engine meant for multistage transformations, batch or streaming pipelines, and machine learning using Python, Scala, Java, or R; it is not a SQL endpoint that you can point at a file with a T-SQL query. While Spark SQL exists, a Spark pool must be spun up, requires submitting jobs with cluster startup latency, and bills vCore uptime rather than query bytes processed, adding orchestration overhead ill-suited to quick ad hoc exploration. The skill set and cost model are a mismatch for an analyst's simple SQL-on-lake requests.

• ✗

  Azure Data Explorer pool

  Why it's wrong here

  Azure Data Explorer pool excels at high-speed interactive analytics over telemetry, logs, and time-series data, but its native query language is KQL (Kusto Query Language), not ANSI or T-SQL, and its storage is built around ingestion into tables rather than querying arbitrary Parquet or Delta files in a data lake. An analyst wanting to write quick SQL against a large dataset would face incompatible syntax, a separate ingestion pipeline, and a design goal—long-running streaming ingest rather than disposable queries—that does not match this use case.

Go deeper

Related to this question