Databricks-Spark-Assoc Developing DataFrame/DataSet API Applications Practice Question
A data engineer needs to join two large DataFrames, `sales` and `products`, on the `product_id` column. The `products` DataFrame is extremely small and fits entirely in a single executor's memory. To optimize performance and avoid a costly shuffle join across the network, which strategy should be applied using the Spark DataFrame API?
⚠ Common exam trap
Candidates often confuse broadcast joins with repartitioning. They might attempt to manually repartition both DataFrames, which triggers a massive, unnecessary shuffle, rather than using the broadcast hint to replicate the small table.
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
✓
Call `sales.join(broadcast(products), "product_id")` to explicitly push the small DataFrame to all worker nodes.
Broadcasting small datasets avoids expensive network shuffles by copying the entire small DataFrame to all worker nodes. This optimization drastically improves query performance for star schemas and dimension table lookups. Using the broadcast function explicitly guarantees that the Catalyst optimizer chooses a broadcast hash join instead of a sort-merge join.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
Call `sales.join(broadcast(products), "product_id")` to explicitly push the small DataFrame to all worker nodes.
Why this is correct
Wrapping the smaller DataFrame with the broadcast function forces the Catalyst optimizer to use a broadcast hash join. This eliminates the shuffle phase for the large sales dataset, significantly reducing overall execution time and resource contention across the cluster.
- ✗
Partition both DataFrames explicitly by `product_id` using `repartition(col("product_id"))` prior to joining.
Why it's wrong here
Explicit repartitioning forces a full shuffle of both datasets across the network to align keys. This operation is computationally expensive and does not solve the fundamental performance bottleneck of joining a large table with a tiny lookup table.
- ✗
Increase the shuffle partition count configuration via `spark.sql.shuffle.partitions` to a higher value.
Why it's wrong here
Raising spark.sql.shuffle.partitions redistributes the same shuffled data across more tasks; it does not eliminate the network exchange, so the large-to-small join still pays full shuffle cost. It is tempting because partition tuning genuinely relieves skewed or oversized shuffle partitions, which is the right fix for skewed aggregation workloads rather than broadcast-eligible joins.
- ✗
Cache the `sales` DataFrame in memory before executing the standard inner join operation.
Why it's wrong here
Caching the large sales DataFrame stores intermediate results in memory or disk, but it still requires a full shuffle across the network to match keys with the products table unless a broadcast join is explicitly enforced.
About these practice questions
This Databricks-Spark-Assoc question is part of Courseiva's 295-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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Databricks exam blueprint
This Databricks-Spark-Assoc practice question is part of Courseiva's free Databricks 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 Databricks-Spark-Assoc exam.