Databricks-Spark-Assoc Troubleshooting and Tuning DataFrame Apps Practice Question
A job is reading a huge amount of data from a table, but only uses three columns. Which optimization technique will provide the most significant I/O performance benefit?
⚠ Common exam trap
Candidates often select repartitioning or caching instead of column pruning, misunderstanding that I/O bottlenecks depend on the amount of data read from disk.
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
✓
Column pruning.
Column pruning is the practice of reading only the required columns from a data source. In formats like Parquet, this reduces the total amount of data read from disk and transferred across the network. This is a crucial optimization for Databricks developers to reduce I/O bottlenecks and improve overall pipeline speed, especially when dealing with wide tables containing hundreds of unused columns in analytical query workloads.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Caching the DataFrame.
Why it's wrong here
Caching stores the data in memory, but it does not reduce the initial I/O cost of reading the entire table the first time. If the table is extremely wide, the initial read will still be slow, and caching will consume excessive memory, potentially leading to OOM issues before the job completes.
- ✓
Column pruning.
Why this is correct
Column pruning forces Spark to read only the columns required by the transformation. By ignoring unused columns at the storage layer, you significantly reduce the amount of data transferred from disk to memory, which is the primary performance gain for wide tables in distributed analytics and ETL applications.
- ✗
Increasing the number of partitions.
Why it's wrong here
Increasing partitions without reducing the data volume per task will not help with I/O performance. The total amount of data read remains the same, and the overhead of managing more partitions might actually lead to slightly degraded performance due to the increased metadata management required by the Spark driver.
- ✗
Broadcasting the table.
Why it's wrong here
Broadcasting is for join operations where a small table is sent to all executors. It is not an I/O optimization for reading a large table. Applying broadcast to a large table will exhaust executor memory, causing the application to fail rather than improving the speed of data retrieval from storage.
About these practice questions
Courseiva writes every Databricks-Spark-Assoc question from scratch — 295 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 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.