DEA-C01 Data Operations and Support Practice Question
A data engineer is troubleshooting a slow Amazon Redshift query that joins a large fact table with several dimension tables. The EXPLAIN plan shows a hash join on the distribution key, but the query still runs slowly. The fact table is distributed by KEY(column_x) and the dimension tables are distributed ALL. The engineer notices that the fact table has a high number of rows with the same value in column_x. What is the most likely cause of the slow performance?
⚠ Common exam trap
Watch out — candidates often assume a hash join on the distribution key is always optimal, overlooking that data skew in the distribution key itself can negate the benefit and cause severe performance degradation.
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 fact table's distribution key column has data skew, causing uneven data distribution across nodes.
Data skew in the distribution key column_x causes some slices to hold a disproportionate number of rows, leading to uneven workload distribution during the hash join. The EXPLAIN plan shows a hash join on the distribution key, which should be efficient if data is evenly distributed, but skew forces the node with the most rows to become a bottleneck, slowing the entire query.
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 table's distribution key column has data skew, causing uneven data distribution across nodes.
Why this is correct
Distribution by KEY(column_x) with many duplicate values concentrates those rows on few slices, so some nodes process far more data than others. That skew makes the hash join uneven and dominates query runtime despite correct distribution style.
- ✗
The dimension tables should be distributed by KEY instead of ALL.
Why it's wrong here
Distributing dimensions by KEY would introduce cross-node redistribution during joins, since the fact table's skewed column_x values would not co-locate with dimension rows. It is tempting because KEY distribution suits large tables, and it would be correct for a dimension too large to replicate to every node.
- ✗
The Redshift cluster does not have enough disk space.
Why it's wrong here
Insufficient disk space would raise disk-full errors or force query queuing, not slow a hash join that the EXPLAIN plan already shows executing. It is tempting because storage pressure does degrade clusters, and it would be the cause if the console reported low free space.
- ✗
The fact table does not have a sort key.
Why it's wrong here
A missing sort key affects zone-map filtering and range scans, not the hash join's build and probe phases, so it cannot explain the slowness. It is tempting because sort keys genuinely accelerate filtered queries, and adding one would be the right fix for a query scanning most of the fact table.
Go deeper
Related to this question
About these practice questions
One of 1,321 original DEA-C01 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 DEA-C01 practice question is part of Courseiva's free Amazon Web Services 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 DEA-C01 exam.