ARA-C01 Performance Optimization Practice Question

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 warehouse size is too small; increase it to a larger T-shirt size.

  Why it's wrong here

  Increasing the warehouse size will provide more nodes, but if the data is skewed, the new nodes will also be underutilized while the node holding the skewed key remains the bottleneck. Scaling up may hide the symptom by providing more power to the bottlenecked node, but it doesn't fix the underlying distribution issue.

• ✓

  The query is experiencing data skew; investigate the join key distribution.

  Why this is correct

  The symptom of one node processing significantly more rows than others is a classic indicator of data skew. The architect should analyze the distribution of values in the join column. If a single value (like NULL or a default ID) appears in millions of rows, it will concentrate processing on a single node.

• ✗

  The Result Cache is cold; run the query again to populate the cache.

  Why it's wrong here

  The Result Cache stores the final output of a query, not the intermediate state of a join operator. A cold cache would cause the entire query to be re-run, but it would not cause the specific imbalance between nodes within a join operator that is described in the scenario.

• ✗

  The table is not clustered; apply a clustering key to the join column.

  Why it's wrong here

  Clustering improves pruning (skipping data), but it does not necessarily resolve distribution issues during a join. Joins involve shuffling data across the warehouse nodes based on a hash of the join key. Even if a table is clustered, a skewed key will still result in an uneven hash distribution across nodes.