DP-700 Monitor and Optimize an Analytics Solution Practice Question
You are monitoring a Microsoft Fabric Lakehouse. You notice that queries against a specific Delta table are performing slowly despite the table having a small data size. You need to identify the root cause of the performance degradation. What should you examine first?
⚠ Common exam trap
Candidates tend to check complex spark configurations or query syntax first, overlooking physical file distribution and the classic small-file performance bottleneck.
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 total number of files within the table directory.
High latency in Delta tables often stems from an excessive number of small files, which increases metadata overhead. Optimizing file size via compaction is a standard best practice in Fabric. By examining the table's file metadata, you can determine if a 'small file problem' exists, which is a common performance bottleneck in analytical workloads. Monitoring these metrics allows you to proactively trigger maintenance tasks like OPTIMIZE and VACCUUM to ensure efficient query execution and storage utilization.
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 number of partitions in the table metadata.
Why it's wrong here
While partitioning is important, an excessive number of partitions can lead to large metadata overhead, but it is not the primary cause of slowness for small tables. File count distribution is a more common performance killer when files are not optimally sized for the Spark compute engine.
- ✓
The total number of files within the table directory.
Why this is correct
Delta tables perform best when data is stored in optimally sized files. If a table contains thousands of small files, the query engine spends excessive time on metadata listing and initialization. Monitoring file count helps identify when the table requires a compaction process to merge these small files.
- ✗
The CPU utilization of the Spark pool.
Why it's wrong here
CPU utilization is a lagging indicator of performance issues rather than a root cause for slow table scans. If the Spark pool is healthy but queries are still slow, the bottleneck is almost certainly related to data organization, such as file fragmentation, rather than raw compute availability.
- ✗
The storage account throughput limits.
Why it's wrong here
Storage throughput limits are rarely the bottleneck for small data tables in Fabric. Unless you have reached extreme IOPS concurrency limits across the entire workspace, small tables should easily reside within the default throughput capacity provided by the underlying ADLS Gen2 storage architecture used by Fabric.
About these practice questions
This DP-700 question is part of Courseiva's 152-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 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.