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.

• ✗

  Use external tables in the dedicated SQL pool to query the data lake directly.

  Why it's wrong here

  While external tables in a dedicated SQL pool can indeed query files in the data lake without copying them into the pool, the dedicated pool's compute nodes are provisioned around the clock unless you manually pause the SQL pool. That ongoing hourly billing is wasted if queries are only ad-hoc and infrequent, even if the amount of data scanned is small. A serverless SQL pool would provide the same external-file access with zero predictable fixed costs, making this approach wrong because it optimizes storage over the much larger, constant compute cost.

  When this WOULD be correct

  If the company needed to combine raw data from the data lake with curated data already in the dedicated SQL pool in a single query, and the dedicated SQL pool was already active for other workloads, external tables would allow seamless joins without moving data.

• ✓

  Create a serverless SQL pool endpoint to query the data lake directly.

  Why this is correct

  Creating a serverless SQL pool endpoint lets you issue standard T-SQL queries directly against Parquet, JSON, CSV, or other files in the data lake using OPENROWSET or external tables, with compute resources dynamically spawned only while a query is executing. Because billing is per byte of data scanned rather than per minute of provisioned capacity, the service auto-scales to the query at hand and is ideal for sporadic, ad-hoc exploration. There is no need to ingest or transform data first, so analysts can run immediate exploratory queries with full T-SQL projection, filtering, and joins across lake files.

• ✗

  Load the raw data into the dedicated SQL pool before querying.

  Why it's wrong here

  Physically loading the raw data into a dedicated SQL pool first introduces a COPY/PolyBase ingestion pipeline, creates duplicate storage in the pool, and requires compute resources to perform the load itself. For data that is queried only occasionally, the combined cost, complexity, and maintenance of keeping that raw data synchronized outweighs any query performance gain. This approach also delays analysis until ingestion completes and risks querying stale copies if the lake files change, so it is poorly suited to ad-hoc exploration where direct file reads are simpler and more current.

  When this WOULD be correct

  This option would be correct if the company required frequent, high-performance queries on the raw data, and the data volume was manageable within the dedicated SQL pool's storage, or if the queries needed to join raw data with the curated data in the pool frequently.

• ✗

  Use Azure Data Explorer to query the data lake.

  Why it's wrong here

  Azure Data Explorer is optimized for interactive analytics on large volumes of streaming and time-series data, but it uses a Kusto query language (KQL), not T-SQL, and is not the best fit for general T-SQL ad-hoc queries.

  When this WOULD be correct

  A company needs to run high-performance, interactive queries on large volumes of streaming telemetry data (e.g., IoT sensor logs) with low latency, and they are comfortable using Kusto Query Language (KQL) instead of T-SQL. They prioritize speed and scalability over full T-SQL compatibility.

Option-by-option analysis

Why each answer is right or wrong

Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The DP-900 exam frequently reuses these exact scenarios with slightly different constraints.

Analysis generated from the official DP-900blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”

Go deeper

Related to this question