DP-300 Practice Question: Monitor, configure, and optimize database resources
Exhibit
Refer to the exhibit. SELECT wait_type, wait_time_ms, waiting_tasks_count FROM sys.dm_os_wait_stats WHERE wait_type = 'PAGEIOLATCH_SH' ORDER BY wait_time_ms DESC;
You run the query in the exhibit on an Azure SQL Database. The result shows high wait_time_ms for PAGEIOLATCH_SH waits. What does this indicate?
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
✓
I/O subsystem bottleneck for read operations
PAGEIOLATCH_SH waits indicate that a query is waiting for a data page to be read from disk into the buffer pool, which is an I/O operation. High wait_time_ms for this wait type typically points to an I/O subsystem bottleneck for read operations, making option A correct. Option B (CPU bottleneck) is incorrect because PAGEIOLATCH_SH is related to I/O, not CPU. Option C (blocking) is incorrect because blocking is associated with LOCK waits, not PAGEIOLATCH_SH. Option D (memory pressure) is incorrect; while memory pressure can increase physical I/O, the wait type itself specifically indicates I/O latency for reading pages from disk.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✓
I/O subsystem bottleneck for read operations
Why this is correct
PAGEIOLATCH_SH waits occur when a thread waits for a data page to be read from storage into the buffer pool, so sustained high wait_time_ms points to slow read I/O rather than CPU, locking or memory pressure. This satisfies the stem's read-operation bottleneck constraint.
- ✗
CPU bottleneck
Why it's wrong here
PAGEIOLATCH_SH waits occur when a thread waits for a data page to be read from storage into the buffer pool, so the bottleneck is I/O, not processor scheduling. CPU pressure instead manifests as SOS_SCHEDULER_YIELD or CXPACKET waits, making this tempting when slow queries are assumed to be compute-bound.
- ✗
Blocking between concurrent transactions
Why it's wrong here
PAGEIOLATCH_SH is a storage-read wait, so it points to slow I/O rather than lock contention. Blocking produces LCK_M_* waits, which is why this misleads anyone who equates long-running queries with concurrent-transaction contention; the correct diagnosis here is disk latency or insufficient memory.
- ✗
Memory pressure
Why it's wrong here
PAGEIOLATCH_SH measures time waiting for pages to be read from disk, which is an I/O symptom; memory pressure instead shows RESOURCE_SEMAPHORE or low page-life-expectancy. It tempts because insufficient buffer-pool memory does force extra physical reads, but the wait itself names storage latency, not memory shortage.
Go deeper
Related to this question
Learn chapter
Optimizing Database Query and Index Performance
Key term
Azure SQL Performance Tuning
Azure SQL Performance Tuning is the process of optimizing the speed and efficiency of queries and database operations in Microsoft Azure SQL Database or SQL Managed Instance to reduce latency and improve throughput.
About these practice questions
Courseiva writes every DP-300 question from scratch — 574 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 by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This DP-300 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-300 exam.