Plan and manage an Azure AI solution →easyMultiple Select

AI-102 Plan and manage an Azure AI solution Practice Question

Which TWO monitoring metrics should you track to ensure the health and performance of an Azure AI Search service used for a customer-facing product catalog?

⚠ Common exam trap

A common mix-up: candidates confuse operational metrics (like indexer duration or storage usage) with customer-facing performance metrics, leading them to select indexer execution history instead of search latency.

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

✓

Throttled search queries count.

Option A, throttled search queries count, is correct because throttling directly indicates that the service is hitting its query-per-second (QPS) capacity limits, which degrades the customer-facing catalog experience and signals a need to scale replicas or partitions. Option D, search latency (average and P99), is correct because latency is the primary performance indicator for a user-facing search experience; tracking both average and P99 reveals tail-latency problems that average alone would hide. Option B is not among the correct answers because indexer execution history and duration relates to data ingestion pipelines, not the query-time health of a customer-facing catalog. Option C is not correct because storage used in GB is a capacity metric that does not reflect query performance or service health for end users. Option E is not correct because counting only successful search requests gives no insight into failures, throttling, or latency, and a rising success count can mask underlying performance degradation.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Throttled search queries count.
Why this is correct
Throttled search queries count directly exposes capacity exhaustion, revealing when the service rejects requests because replica or partition limits are exceeded. For a customer-facing catalogue, this metric satisfies the availability constraint: throttling silently degrades the user experience, so tracking it triggers timely scaling before shoppers encounter failed searches.
✗
Indexer execution history and duration.
Why it's wrong here
Indexer execution history and duration measures ingestion pipeline throughput, not the query-side latency and throttling that a customer-facing catalogue depends on. It is tempting because indexer failures do stall content freshness, making this metric correct when the concern is stale or missing documents rather than search performance.
✗
Storage used in GB.
Why it's wrong here
Storage used in GB tracks capacity consumption, not query latency, throttling, or CPU/memory pressure that determine catalogue search responsiveness. It is tempting because quota exhaustion genuinely degrades a service, and storage monitoring would be the right metric when planning partition counts or anticipating index-size limits.
✓
Search latency (average and P99).
Why this is correct
Search latency (average and P99) directly measures query responsiveness, satisfying the customer-facing requirement where slow results harm user experience. P99 exposes tail latency that averages hide, revealing throttling or index bottlenecks. Tracking both percentiles ensures the service meets performance expectations under peak catalogue traffic.
✗
Number of successful search requests.
Why it's wrong here
Successful search requests alone cannot reveal latency, throttling or query failures, so service health stays hidden. It is tempting because throughput looks like a health signal, but Azure AI Search exposes Search Latency and Throttled Search Queries metrics, which together expose performance degradation.

Go deeper

AI-102 Plan and manage an Azure AI solution Practice Question

Why each option matters

Option-by-option breakdown

Related to this question