DP-700 Monitor and Optimize an Analytics Solution Practice Question
Exhibit
{
"job_id": "98765",
"status": "Completed",
"metrics": {
"input_rows": 100000000,
"shuffle_write_size": "500GB",
"peak_memory": "16GB",
"duration": "45m"
}
}Refer to the exhibit. The Spark job completed but took 45 minutes for a 100 million row dataset. The shuffle write size is significantly high. What should you investigate to improve performance?
⚠ Common exam trap
Test-takers frequently investigate cluster node sizes or storage throughput instead of recognizing that excessive shuffle write sizes point directly to inefficient join operations and missing broadcast settings.
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
✓
Investigate join strategies and broadcast settings.
A high shuffle write size relative to the input dataset suggests that the job is performing excessive data movement across the cluster. This is typically caused by inefficient joins, such as sort-merge joins where broadcast joins would have been more efficient. Investigating the join strategy and partition counts helps identify why so much data is being shuffled, which is the primary cause of latency in large-scale Spark jobs that process significant volumes of data.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Reduce the number of partitions.
Why it's wrong here
Reducing partitions generally increases the amount of data processed per task, which can lead to memory overflow. It does not reduce the volume of data being shuffled; instead, it might make the shuffle even more unstable by creating larger data chunks for the network to transmit.
- ✓
Investigate join strategies and broadcast settings.
Why this is correct
High shuffle write sizes are a classic symptom of inefficient join operations. By analyzing the execution plan in the Spark UI, you can determine if a broadcast join would be more appropriate, which would allow the engine to avoid the expensive shuffle phase entirely for smaller lookup tables.
- ✗
Enable auto-vacuuming on the table.
Why it's wrong here
Auto-vacuuming helps clean up orphaned files and manage storage, but it has no impact on the performance of a Spark job's shuffle process. Shuffling is a compute-intensive task that happens in memory and over the network during runtime, not a storage-related background task.
- ✗
Increase the disk capacity of the Lakehouse.
Why it's wrong here
Shuffle operations in Spark occur in the memory or on the local temporary storage of the executors, not on the primary Lakehouse storage. Increasing Lakehouse storage will not provide any performance benefit for memory-intensive operations like shuffling, making this an ineffective solution for performance tuning.
About these practice questions
One of 152 original DP-700 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 and reviewed by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
Last reviewed September 2026 · checked against the official Microsoft exam blueprint
This DP-700 practice question is part of Courseiva's free Microsoft 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 DP-700 exam.