DP-300 Practice Question: Monitor, configure, and optimize database resources
You are managing an Azure SQL Database that experiences intermittent performance degradation. Query Store shows a significant increase in wait time for PAGEIOLATCH_SH. You need to identify the most likely cause. What should you investigate first?
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
✓
Insufficient IOPS or throughput at the database level
PAGEIOLATCH_SH waits indicate I/O subsystem pressure, often due to insufficient IOPS or throughput. Option A is incorrect because out-of-date statistics cause cardinality estimation errors, not I/O waits. Option C is incorrect because missing indexes typically cause table scans but not necessarily PAGEIOLATCH waits. Option D is incorrect because blocking causes waits like LCK_M_*, not PAGEIOLATCH.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Out-of-date statistics
Why it's wrong here
PAGEIOLATCH_SH indicates waits on data pages read from storage, pointing to I/O contention or insufficient memory rather than stale statistics, which produce different wait types. Statistics maintenance is genuinely the fix when plans show cardinality estimation errors, making it a tempting first check.
- ✓
Insufficient IOPS or throughput at the database level
Why this is correct
PAGEIOLATCH_SH waits occur when sessions stall reading pages from storage into the buffer pool, so the first suspect is storage throughput. Checking database-level IOPS or throughput limits identifies whether the tier is throttling reads during the degradation windows.
- ✗
Missing indexes
Why it's wrong here
Missing indexes cause scans and CPU or PAGEIOLATCH waits on specific queries, but PAGEIOLATCH_SH points to storage-level I/O pressure affecting page reads broadly. Index tuning is genuinely correct when a query's plan shows scans on large tables, which is why it appears plausible here.
- ✗
Blocking from long-running transactions
Why it's wrong here
PAGEIOLATCH_SH waits indicate physical reads from storage, pointing to missing indexes or poor query plans causing buffer cache misses, not lock contention. Blocking manifests as LCK_M_* waits instead. Investigate blocking only when sessions queue on locked rows, which this wait type does not show.
Go deeper
Related to this question
Learn chapter
Managing Identity and Access for Azure SQL
Key term
Query Store
Query Store is a built-in SQL Server feature that captures and stores a history of query execution plans and performance data for easy monitoring and troubleshooting.
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
This DP-300 question is part of Courseiva's 574-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 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.