Databricks-Spark-Assoc Spark Architecture and Components Practice Question
A Spark job reads a large CSV file, performs a groupBy aggregation, and then writes the result. The Spark UI shows that the job has multiple stages, and one stage has a large number of tasks. Which factor primarily determines the number of tasks in the stage that performs the aggregation?
⚠ Common exam trap
The trap here is assuming that the number of tasks always equals the number of input partitions, ignoring that shuffle operations introduce a new partitioning determined by spark.sql.shuffle.partitions.
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 value of spark.sql.shuffle.partitions.
The number of tasks in a stage that follows a shuffle (like an aggregation) is determined by the number of shuffle partitions, which defaults to spark.sql.shuffle.partitions (200). The input partitions affect the initial stage, while executors and cores affect concurrency, not the total task count.
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 value of spark.sql.shuffle.partitions.
Why this is correct
For operations that trigger a shuffle, such as groupBy, the number of tasks in the subsequent stage is equal to the number of shuffle partitions. By default, spark.sql.shuffle.partitions is set to 200, but it can be adjusted. This configuration directly controls the parallelism of the aggregation stage.
- ✗
The number of partitions in the input RDD/DataFrame.
Why it's wrong here
The number of partitions in the input determines the number of tasks in the initial stage that reads the data. However, for the aggregation stage after a shuffle, the number of tasks is determined by the number of partitions in the shuffled data, which defaults to spark.sql.shuffle.partitions, not the input partitions.
- ✗
The number of cores per executor.
Why it's wrong here
Cores per executor determine how many tasks can run in parallel on each executor, but they do not set the total number of tasks. The total number of tasks in a shuffle stage is determined by the number of partitions, not by the hardware configuration of executors.
- ✗
The number of executors in the cluster.
Why it's wrong here
The number of executors affects how many tasks can run concurrently but does not determine the total number of tasks in a stage. Tasks are distributed across executors, but the total count is set by the number of partitions. Increasing executors may speed up processing but does not change the task count.
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.