DP-900 Describe an analytics workload on Azure Practice Question
You are a data engineer for a financial services company. The company uses Azure Synapse Analytics dedicated SQL pool for its data warehouse. They have a fact table named Transactions that contains 2 billion rows. The table is hash-distributed on the AccountID column. Users run reports that aggregate transaction amounts by date and account type. The reports are slow. Upon investigation, you find that the distribution is highly skewed because a few accounts have millions of transactions. You need to improve query performance without redesigning the entire schema. Which action should you take?
⚠ Common exam trap
A common mix-up: candidates assume that a clustered columnstore index (Option C) is the universal fix for slow queries, but they fail to recognize that data skew in a hash-distributed table is a distribution-level problem that columnstore indexes cannot solve.
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
✓
Change the distribution key to a column with more unique values, such as TransactionID
Changing the distribution key to TransactionID, which has far more unique values than AccountID, will eliminate the data skew that is causing performance degradation. In a hash-distributed table, a skewed distribution key leads to some distributions holding a disproportionate amount of data, causing parallel query execution to be bottlenecked by the largest distribution. By using a highly unique column like TransactionID, the data will be evenly distributed across all 60 distributions, enabling balanced parallelism and faster aggregation queries.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Change the distribution key to a column with more unique values, such as TransactionID
Why this is correct
Changing the distribution key to a high-cardinality column such as TransactionID is the correct fix. In a hash-distributed table, rows are assigned to distributions by hashing the distribution key, so a key with millions of unique values spreads rows nearly uniformly across all compute nodes. This directly eliminates the data skew on the existing key and also ensures that subsequent joins and aggregations on TransactionID can occur with minimal data movement, allowing the massive table to be processed in parallel.
- ✗
Change the distribution to round-robin
Why it's wrong here
Switching the table to round-robin distribution would indeed spread rows evenly across distributions, but it does so without any regard to logical relationships between tables. Since rows are assigned sequentially rather than by hashing a join column, every join between this fact table and any dimension table would require a full shuffle of both tables across all compute nodes, causing enormous data movement and negating the parallel-processing advantage. Round-robin is appropriate only for staging or heap tables that are created for bulk loads and not used in repetitive joins.
- ✗
Create a clustered columnstore index on the table
Why it's wrong here
Creating a clustered columnstore index addresses compression and query performance through columnar segment elimination, not the physical distribution of rows across nodes. If the current distribution key is skewed, many rows with the same value hash to the same distribution, so a columnstore index cannot help because that single distribution still holds a disproportionate share of data and becomes the bottleneck. Moreover, the table presumably already has a columnstore index since this is a typical analytics workload; adding or rebuilding it would incur heavy I/O without fixing the root cause.
- ✗
Replicate the Transactions table to all distributions
Why it's wrong here
Replicating a table to all distributions copies it to every compute node so that joins can occur locally without data movement, but this strategy is intended only for small dimension tables, typically under a few GB. A 2-billion-row financial transactions table would require duplicating that enormous data volume by the number of nodes, vastly increasing storage cost and making the initial replication and any incremental updates extremely slow. The replication process itself would overwhelm the pipeline and still not resolve the fact table's own distribution skew for aggregate queries.
Go deeper
Related to this question
Learn chapter
Data Roles and Core Concepts
Key term
Data
Data is raw, unprocessed information, like numbers, words, or measurements, that can be stored, processed, and analyzed by computers.
Key term
Table
A table is a structured collection of data organized into rows and columns, used in databases and spreadsheets to store and manage information efficiently.
About these practice questions
Courseiva writes every DP-900 question from scratch — 820 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or 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-900 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-900 exam.