DP-203 Develop data processing Practice Question
You are using Azure Synapse Analytics dedicated SQL pool to run a query that joins a large fact table (10 billion rows) and a small dimension table (1 million rows). The query is slow. Which distribution strategy should you use for the dimension table to improve performance?
⚠ Common exam trap
Many candidates choose hash distribution on the foreign key (Option D) thinking it aligns the join keys, but they overlook that the fact table is typically distributed on a different column (e.g., its own primary key or a date column), so the join still requires data movement, whereas replication is the optimal strategy for small dimension tables in a star schema.
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
✓
Replicate the dimension table to all compute nodes.
Replicating the small dimension table (1 million rows) to all compute nodes eliminates data movement during the join with the large fact table (10 billion rows). In Azure Synapse dedicated SQL pool, replicated tables store a full copy on each distribution, so the join can be performed locally on every node without shuffling data across the network, drastically reducing query latency.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Round-robin distribute the dimension table.
Why it's wrong here
Round-robin spreads dimension rows evenly across distributions, so joining to the fact table requires shuffling or broadcast for every query. Round-robin suits staging or loading tables where no consistent join key exists and even distribution matters more than co-location.
- ✗
Hash-distribute the dimension table on its primary key.
Why it's wrong here
Hash-distributing the dimension on its primary key spreads its 1 million rows across all distributions, forcing data movement during the join. Replicating the small dimension to every compute node removes that shuffle entirely. Hash distribution suits large fact tables needing even distribution, not small dimensions joined to them.
- ✓
Replicate the dimension table to all compute nodes.
Why this is correct
Replicating the small dimension table places a full copy on every compute node, eliminating data movement during joins with the 10-billion-row fact table. Because replicated tables are readable on all distributions, each node joins locally, which removes the shuffle that made the query slow.
- ✗
Hash-distribute the dimension table on the foreign key column.
Why it's wrong here
Hash-distributing on the dimension's foreign key does not match the fact table's distribution column, so rows still move between distributions during the join. Hash distribution on a join key is correct when both tables share that column and are similarly sized.
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.