DP-203 Develop data processing Practice Question
Exhibit
Refer to the exhibit.
```kusto
let StartDate = datetime(2024-01-01);
let EndDate = datetime(2024-01-31);
let TotalSales = materialize(
Sales
| where OrderDate between (StartDate .. EndDate)
| summarize TotalAmount = sum(Amount) by ProductID
);
TotalSales
| where TotalAmount > 10000
| join kind=inner (Products) on ProductID
| project ProductName, TotalAmount
| order by TotalAmount desc
```You are analyzing a Kusto query in Azure Data Explorer that calculates total sales per product for January 2024 and filters for products with sales over 10,000. The query uses the materialize() function. You notice that the query runs slower than expected. What is the primary reason the materialize() function may not be providing the expected performance benefit in this query?
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
The materialize() result is referenced only once in the query, so materialization adds unnecessary overhead
Materialize() only provides performance benefit when the materialized result is referenced multiple times. In this query, the materialized result is used only once, so the overhead of materialization (storing the result in memory) outweighs any benefit, potentially making the query slower. Option A is incorrect because there is no join with a Products table; the query uses a single table. Option B is incorrect because summarize does not inherently materialize results; it computes aggregations on the fly. Option C is incorrect because datetime range filters in Kusto are sargable and do not cause full table scans.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
The join with the Products table forces a shuffle that bypasses the materialized result
Why it's wrong here
materialize() caches a tabular result; a downstream join does not inherently force a shuffle that discards that cache, so this misstates the mechanism. The function is designed for repeated consumption of an intermediate result within one query, which is where it delivers its benefit.
- ✗
The query uses summarize, which already materializes results internally
Why it's wrong here
summarize() produces an aggregation but does not persist or reuse its output across references the way materialize() does, so this claim is technically false. materialize() exists precisely to cache an intermediate tabular expression that is referenced more than once in the same query.
- ✗
The datetime range filter is not sargable, causing full table scan
Why it's wrong here
A datetime filter on a column is sargable in Kusto and benefits from indexing, so it would not cause a full scan that defeats materialize(). Non-sargable predicates arise from functions applied to the filtered column, which is not the case in this query.
- ✓
The materialize() result is referenced only once in the query, so materialization adds unnecessary overhead
Why this is correct
materialize() caches an intermediate result to avoid recomputation when referenced multiple times. With only a single reference, the query pays the cost of writing and reading the cached table without any reuse benefit, so the overhead outweighs the saving and slows execution.
Go deeper
Related to this question
About these practice questions
One of 509 original DP-203 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DP-203 practice question is part of Courseiva's free Microsoft certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the DP-203 exam.