You are setting up monitoring for a web service on Azure. What do you actually monitor, and why? Use a method, not a wishlist.
What they are really testing: Whether you monitor with intent, signals tied to user experience and saturation, rather than dumping every metric onto a dashboard. They want a method (RED for services, USE for resources) and the Azure tooling that backs it.
A real interview question
You are setting up monitoring for a web service on Azure. What do you actually monitor, and why? Use a method, not a wishlist.
What most people say
drag me
“I would turn on Azure Monitor and set up alerts on CPU and memory so I know when the servers are stressed.”
CPU and memory are resource clues, not user-facing signals, a service can be failing users with healthy CPU, or have high CPU while serving fine. There is no method, no error rate or latency, and alerting on raw CPU produces noise that trains people to ignore the pager.
The follow-ups they ask next
Your CPU alert fires constantly but users never notice. What is wrong with the alert?
It is alerting on a cause, not a symptom. High CPU with healthy latency and error rate is not an incident. Re-base alerts on user-facing SLOs (RED), and demote CPU/saturation to dashboards you consult during triage, not pages.
A request is slow but each service in the chain looks fine on its own dashboard. How do you find the culprit?
Per-service dashboards hide cross-service latency. Use distributed tracing in Application Insights to follow one request across hops and see which dependency call is slow, the application map and end-to-end transaction view surface the bottleneck.
What the interviewer is listening for
- Leads with a method (RED and USE)
- Watches p95/p99 latency, not just averages
- Alerts on user-facing symptoms, not raw CPU
- Maps the method onto Application Insights and Azure Monitor
What sinks the answer
- Monitors a wishlist with no method
- Alerts on CPU/memory as the primary signal
- Only looks at average latency
- No mention of tracing or error rate
If you genuinely do not know
Say this instead of freezing. Reasoning out loud from what you do know beats silence every single time, and a good interviewer is listening for exactly that.
“I would use a method: [RED, Rate/Errors/Duration] for the service and [USE, Utilization/Saturation/Errors] for resources. I watch [latency at p95/p99, not the average] and [error rate]. On Azure I wire that through [Application Insights and Azure Monitor / Log Analytics]. I alert on [user-facing SLOs], not [raw CPU], which is just a triage clue.”
Keep going with observability
Foundation
What is the difference between monitoring and observability?
Foundation
What are the three pillars of observability, and what is each good for?
Foundation
What should you measure first for a service? Explain the golden signals (or RED/USE).
Junior
What are good logging practices for a distributed system?
Junior
What are the main metric types (counter, gauge, histogram), and when do you use each?
Junior
What is distributed tracing, and how does it work?
Knowing the answer is not the same as recalling it under pressure
Sign in to send the questions you fumble to spaced recall, so they come back right before you would forget them, and learn the concepts behind them with hands-on labs.
Start free