Observability Platforms and Operations
What the exam tests
Observability Platforms and Operations tests backend selection, querying, retention, dashboards, alerting, SLO operations, cost control, security, and Kubernetes deployment patterns.
Core rules
- Prometheus uses pull-based scraping, service discovery, and local TSDB; remote_write feeds long-term stores such as Thanos or Mimir. Alerting rules evaluate PromQL and route through Alertmanager.
- Loki indexes labels, not full log text; keep labels low-cardinality. Tempo and Jaeger store traces; Grafana commonly queries all three signals.
- Dashboards should use RED for services and USE for resources. Alerts should target symptoms and SLO burn, not every cause.
- Retention must cover the SLO window and investigation needs. Cardinality, log volume, and trace sampling drive cost.
- Multi-tenancy, RBAC, encryption, and PII redaction are operational requirements, not optional features.
- The OpenTelemetry Operator can inject auto-instrumentation and manage Collectors in Kubernetes.
Worked example
A 99.9% SLO over 30 days has a 0.1% error budget. A fast-burn alert uses a 1-hour window at burn rate 14.4x; at that rate 2% of the 30-day budget is consumed in one hour. Pair it with a 5-minute short window to confirm the burn and a 6-hour slow-burn alert at 6x. The reasoning is that a single static error-rate threshold either pages on harmless blips or waits too long for real outages. Multiwindow burn-rate alerts balance precision and recall while tying pages to user impact.
Traps
Alerting on CPU alone pages on causes, not symptoms. Static thresholds ignore SLO context. Retention shorter than the SLO window makes budget calculations impossible. Unbounded labels in Loki or Prometheus cause cardinality explosions. Dashboards that query raw logs over long ranges are slow and expensive. Missing runbooks and ownership turn alerts into noise.