DP-203 Design and implement data storage Practice Question
You are tuning a dedicated SQL pool in Azure Synapse Analytics. A query that joins two large tables (fact_sales and dim_product) is slow. The fact_sales table is hash-distributed on product_id, and dim_product is replicated. You notice that the query plan shows a shuffle move. What is the most likely cause?
⚠ Common exam trap
Watch out — candidates often confuse a shuffle move with a broadcast join or blame indexing, but the root cause is the mismatch between the join key and the distribution key, which forces data movement regardless of other optimizations.
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 join condition does not include the distribution key for fact_sales.
When the join condition does not include the distribution key (product_id) of the hash-distributed fact_sales table, the SQL engine cannot perform a collocated join. Instead, it must shuffle data across distributions to satisfy the join, which introduces expensive data movement. The shuffle move in the query plan directly indicates this redistribution.
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 fact_sales table uses clustered columnstore index.
Why it's wrong here
A shuffle move occurs because the join column differs from the distribution column; clustered columnstore is merely the storage and compression format and does not dictate data movement. It is tempting because columnstore accelerates analytical scans, and it would be the right choice when the goal is query performance on large fact tables rather than eliminating repartitioning.
- ✗
The dim_product table is replicated, causing a broadcast join.
Why it's wrong here
Replication of dim_product is the intended design: the small dimension is broadcast to every distribution, avoiding a shuffle. A shuffle move indicates the join key does not match the distribution column, or the replicated table is too large to broadcast. Replication would be correct when the dimension is genuinely small.
- ✗
Statistics are out of date on both tables.
Why it's wrong here
Stale statistics cause poor cardinality estimates and suboptimal join strategies, but the plan would show estimation warnings rather than a shuffle move specifically. A shuffle arises from distribution-key mismatch on the join column. Refreshing statistics would be correct when the plan shows skewed row estimates driving a poor join type.
- ✓
The join condition does not include the distribution key for fact_sales.
Why this is correct
Hash distribution on product_id means rows with the same product_id reside on one distribution. If the join predicate omits product_id, the engine cannot co-locate fact and dimension rows, forcing a shuffle move to redistribute data before the join completes.
Go deeper
Related to this question
About these practice questions
This DP-203 question is part of Courseiva's 509-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. 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.