4.4.3. Diagnostic Tools and Service Health
💡 First Principle: Cloud Trace, Cloud Profiler, Query Insights, and the index advisor each diagnose a different specific symptom, and correctly routing a described problem to the right tool is the actual exam skill — not simply "using observability tools" in the abstract.
| Symptom Described | Right Tool | What It Reveals |
|---|---|---|
| "A request is slow, and it's unclear which downstream service is responsible" | Cloud Trace | End-to-end request latency broken down across services |
| "An application is consuming unexpectedly high CPU or memory" | Cloud Profiler | Code-level CPU/memory usage inside a running application |
| "A specific database query is running slowly" | Query Insights | Query-level performance detail for managed databases |
| "A database would benefit from a missing index" | Index advisor | Recommended indexes based on observed query patterns |
The Personalized Service Health dashboard complements all of the above by surfacing Google Cloud service incidents specifically relevant to the resources and regions your project actually uses, rather than a generic status page covering every service globally regardless of relevance to you.
⚠️ Exam Trap: Cloud Trace, Cloud Profiler, and Cloud Monitoring are interchangeable names for the same diagnostic tool — a natural assumption since all three live under the observability umbrella, but they serve distinct purposes: Trace analyzes request latency across services, Profiler analyzes CPU/memory usage within running code, and Monitoring tracks metrics and alerting broadly. An exam scenario naming the exact symptom is pointing at exactly one of the three.
Reflection Question: A team notices one specific microservice's CPU usage spikes unpredictably, but the cause within the application's own code is unclear. Which diagnostic tool targets that specific symptom, and why wouldn't Cloud Trace be the right choice here?
