AZ-400 Implement an instrumentation strategy Practice Question
You are a DevOps engineer for a large e-commerce company. The company uses Azure DevOps for CI/CD and Application Insights for monitoring. The application is a .NET Core 6 microservice running on Azure Kubernetes Service (AKS) with a Redis cache and Azure SQL Database. Recently, the operations team noticed that the application's response time has degraded significantly during peak traffic hours. Application Insights shows an increase in server-side dependency call duration to Redis and SQL, but no increase in exceptions. The team suspects a connection pooling issue. You have been asked to diagnose and fix the problem. Which approach should you take first?
⚠ Common exam trap
It's easy for candidates to assume the issue is a code bug (Option B) or infrastructure scaling (Option A), but the question explicitly states no exceptions and a connection pooling suspicion, so the correct first diagnostic step is to analyze existing telemetry to confirm the bottleneck before making changes.
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
✓
Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.
The first step in diagnosing a connection pooling issue is to analyze the dependency performance data in Application Insights. The 'Dependency' blade provides detailed percentiles (e.g., P50, P95, P99) for Redis and SQL call durations, allowing you to pinpoint which dependency is the bottleneck. Once identified, you can adjust the connection pool size (e.g., Max Pool Size in SQL connection string or Redis multiplexer settings) to match the peak concurrency demands without overwhelming the database or cache.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Increase the number of AKS nodes to handle peak traffic and reduce resource contention.
Why it's wrong here
Scaling AKS nodes only adds compute capacity (CPU, memory, pod slots); it does not change the per-process connection pool limit that each pod's Redis or SQL client is bound by. If the true bottleneck is connection pool exhaustion or high dependency latency (e.g., p99 SQL calls), more nodes can actually amplify the problem by introducing more concurrent calls to the same dependency, saturating it further. This masks symptoms at the infrastructure layer while increasing cost and operational complexity, without addressing the measured telemetry that points to a dependency-level root cause.
- ✗
Review the application code to ensure that Redis and SQL connections are properly opened and closed using 'using' statements.
Why it's wrong here
Proper connection disposal using 'using' statements is a best practice, but inspecting code without first using telemetry to confirm the actual failure point is inefficient; resource leaks would typically manifest as connection pool timeouts or exhausted pools, which can be confirmed through Application Insights dependency telemetry rather than a blind code review.
- ✗
Run a load test against the application to reproduce the issue and monitor system counters.
Why it's wrong here
A load test can stress the system but it uses synthetic or artificial traffic that may not reflect production data patterns, user behavior, or the exact dependency load; running it against a production-like environment introduces overhead and delays without giving the direct observability into the specific Redis/SQL latency provided by Application Insights dependency tracking.
- ✓
Use Application Insights 'Dependency' performance blade to analyze call duration percentiles and identify whether the bottleneck is in Redis or SQL. Then adjust connection pool sizes accordingly.
Why this is correct
This approach uses telemetry to isolate the dependency (Redis vs SQL) that is causing the delay by comparing p50/p95/p99 call durations, and then lets you tune connection pool max sizes based on measured concurrency and latency, directly addressing the root cause.
Go deeper
Related to this question
Learn chapter
Introduction to DevOps and Azure DevOps
Key term
Application Insights
Application Insights is an Azure monitoring service that helps developers detect, diagnose, and understand issues in live web applications by collecting telemetry data like requests, exceptions, and performance counters.
Key term
Azure DevOps
Azure DevOps is a Microsoft service that provides development tools for planning, building, testing, and deploying software applications using automated pipelines and collaboration features.
About these practice questions
This AZ-400 question is part of Courseiva's 823-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 AZ-400 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 AZ-400 exam.