3.6 Querying: Visual Query, SQL, KQL, DAX

One Question, Different Languages

The exam often shows the same business question against different assets and asks which query tool is appropriate. The decisive factor is what asset holds the data and who is querying it, not which language you personally prefer. Anchor on the asset first, then the persona.

The Four Query Surfaces

• Visual Query Editor — a no-code/low-code graphical builder (Power Query under the hood) available over a lakehouse SQL analytics endpoint or a warehouse. Drag tables, apply filters/joins/aggregations visually; it generates the query for you. Best for analysts who want results without writing T-SQL.
• SQL (T-SQL) — used in the warehouse (full read-write) and the lakehouse SQL analytics endpoint (read-only). Use it for relational SELECT/JOIN/GROUP BY, views, and — warehouse only — stored procedures and DML.
• KQL (Kusto Query Language) — the language of the eventhouse/KQL database. Operators like where, summarize, project, and built-in time-series functions make it ideal for telemetry, logs, and event analytics.
• DAX (Data Analysis Expressions) — queries and computes over a semantic model: measures, filter/row context, time intelligence. It is the consumption language for BI, not a data-prep or raw-table language.

Choose-the-Language Table

Rule of thumb: if the question stresses no coding skills, the answer is the Visual Query Editor. If it stresses stored procedures or writes, the answer is warehouse T-SQL. If it stresses time bins or telemetry, the answer is KQL. If it stresses measures or report calculations, the answer is DAX.

SQL Analytics Endpoint: The Detail That Trips Candidates

Every lakehouse automatically provides a SQL analytics endpoint. You can run T-SQL SELECTs, create views, and connect BI tools to it — but it is read-only with respect to the lakehouse Delta tables. To change lakehouse data you go back to Spark, notebooks, or Dataflow Gen2. If a query scenario needs T-SQL writes or stored procedures, that points to a warehouse, not the lakehouse endpoint. This is the single most common DP-600 query distractor and it appears in both the store-selection and the querying topics.

KQL for the Eventhouse

When a scenario mentions device telemetry, logs, or "how many events per 5-minute bin," the answer surface is KQL in the eventhouse. KQL's pattern below is purpose-built for time-series and is far more natural than forcing the same logic into T-SQL or DAX:

• TelemetryEvents | where Timestamp > ago(1h) | summarize count() by bin(Timestamp, 5m)

That single line buckets events into 5-minute windows over the last hour. Reproducing it in T-SQL requires manual date math, and in DAX it would require a modeled table that does not exist at the raw-stream layer.

DAX Is Not a Prep Language

A frequent trap offers DAX as an answer for transforming or cleaning raw tables. DAX is for semantic model calculation and analysis — measures, filter context, and time intelligence — and it consumes a modeled star schema. It does not ingest, clean, or reshape source data. Keep preparation in lakehouse/warehouse engines (Spark, T-SQL, Dataflow Gen2) and reserve DAX for the model layer.

Common Wrong-Language Distractors

Cross-Querying and the SQL/KQL Bridge

A few capabilities blur the lines and DP-600 tests whether you know the limits. An eventhouse exposes a T-SQL query surface that emulates a subset of SQL so SQL-fluent users can run basic SELECTs against KQL data, but rich time-series logic still belongs in KQL. Conversely, a KQL queryset can reference data via the external_table or shortcut mechanisms, but you would not run a transactional UPDATE there.

The safe exam stance: name the native language of the asset (KQL for eventhouse, T-SQL for warehouse, read-only T-SQL for the lakehouse endpoint, DAX for the semantic model) unless the question explicitly invokes a bridge feature.

Matching Persona, Asset, and Output

When a scenario is ambiguous, resolve it on three axes in order: (1) which asset holds the data, (2) what the output must be (a cleaned table, a transactional write, a time-series rollup, or a report measure), and (3) the persona's skill level. A no-code analyst over a lakehouse lands on the Visual Query Editor; a SQL developer needing stored procedures lands on warehouse T-SQL; an operations analyst counting telemetry events lands on KQL; a report author defining a year-over-year measure lands on DAX.

Memorizing this triage prevents the classic mistakes of reaching for DAX to clean data or expecting the read-only lakehouse endpoint to perform writes.