What's changed: Created DP-420 Chapter 5, completing the textbook (Domain 5: monitoring (Normalized RU Consumption hot-partition detection/status codes 429-449-503-408/server-side latency/Azure Monitor alerts/resource logs diagnostic settings→Log Analytics/cross-partition monitoring); backup and restore (periodic vs continuous/PITR/restore point/restore into a new account); security, data movement, DevOps (service-managed vs CMK Key Vault/Private Endpoint-IP-VNet/control-plane Azure RBAC-data-plane Entra ID RBAC/Always Encrypted/CORS/data movement ADF-Spark-Kafka-Stream Analytics-IoT Hub/DevOps declarative ARM-imperative PowerShell-CLI standard↔autoscale-failover)).
5.1Monitoring and troubleshooting
Understand response status codes and failure metrics, monitoring Normalized RU Consumption and server-side latency with Azure Monitor, replication monitoring, alerts and resource logs, and monitoring throughput/data distribution across partitions.
In operations, surface RU skew, throttling, latency, and availability to catch issues early. Cosmos DB exposes metrics/logs/alerts via Azure Monitor.
5.1.1Key metrics and status codes
Normalized RU Consumption shows the RU utilization (0–100%) of the busiest partition—the key metric to detect a hot partition (consumption skewed to one partition); a sustained high value foreshadows 429s. Response status codes / failure metrics (429 rate limiting, 449 concurrency retry, 503 transient, 408 timeout) classify failures. Server-side latency isolates slowness inside the service (vs client/network causes). Monitor throughput/data distribution across partitions; skew calls for revisiting the partition key design.
5.1.2Alerts, resource logs, and auditing
Set Azure Monitor alerts on Normalized RU or throttling rate to notify/auto-respond on threshold breach. Send resource logs (diagnostic settings) to Log Analytics and query with KQL to analyze data-plane requests and control-plane operations. Use logging and auditing for security monitoring (who accessed what data when). Also monitor replication latency and availability to verify cross-region health.
Cues: "detect hot partition/RU skew" = Normalized RU Consumption. "rate limiting" = 429. "slowness inside the service" = server-side latency. "notify on threshold" = Azure Monitor alert. "KQL-analyze requests/operations" = resource logs (diagnostic settings → Log Analytics). Skew signals partition-key redesign.
Watch the mix-ups: (1) Normalized RU (busiest-partition utilization) vs average RU—skew is seen in Normalized. (2) 429 (insufficient throughput) is fixed by SDK retries + more RU or key redesign. (3) Separate server-side latency from client/network latency. (4) Resource logs must be explicitly enabled via diagnostic settings.
5.1.3Section summary
- Normalized RU Consumption detects busiest-partition skew (hot partition) and foreshadows 429s
- Status codes (429/449/503/408) and server-side latency classify failures and slowness
- Azure Monitor alerts + resource logs (diagnostic settings → Log Analytics/KQL) + auditing for ops/security
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. You want to detect whether RU consumption skews to one partition (hot partition). Best metric?
Q2. Which status code does Cosmos DB return when it rate-limits due to insufficient provisioned RU?
Q3. You want to notify and trigger automation when Normalized RU sustains above a threshold. Best?
Q4. You want to analyze data-plane requests and control-plane operations later via KQL. Best?
Q5. If Normalized RU stays high and a hot partition is suspected, what is the correct root-cause remedy?
Keep track of your progress
The full study guide is free to read. Sign up free to practice with the question bank, track what you have read, review your mistakes, and highlight passages.