Observability Foundation common mistakes
Observability Foundation · Understand the traps and how to avoid them.
Treating the Three Pillars as three interchangeable data sources and answering that logs alone can satisfy a question about diagnosing latency in a distributed request.
Candidates memorize the pillar names (metrics, logs, traces) without internalizing what each is structurally good at: metrics are cheap aggregates with no per-request context, logs are high-cardinality events without causal linkage, traces carry request-scoped causality across services. The exam repeatedly probes the boundary between them.
What to do instead
For each pillar, write one sentence on its cardinality, cost profile, and what question it uniquely answers. Practice classifying scenarios: 'which service in this chain added 800ms' is a trace question; 'how many 5xx this hour' is a metric question; 'what did the handler log before failing' is a log question. Answer with the pillar that carries the needed dimension, not the one you know best.
Answering that adding more dashboards and alert rules is the correct remedy for an outage that monitoring failed to predict, instead of recognizing the need for unknown-unknown detection and high-cardinality exploration.
Candidates conflate 'monitoring' with 'observability' and default to the operations they know. The exam tests the conceptual distinction: monitoring answers pre-defined questions about known failure modes; observability lets you ask arbitrary new questions about emergent behavior without shipping new code.
What to do instead
Learn the framing as a contrast pair: monitoring = known unknowns, dashboards and threshold alerts on anticipated signals; observability = unknown unknowns, derived from rich, high-cardinality, correlated telemetry (traces with wide attributes, structured events) that supports ad hoc query. When a scenario describes a novel failure the team never anticipated, the answer is improved telemetry richness and cardinality, not more pre-built dashboards.
Assuming OpenTelemetry is a backend or an observability platform, or that adopting the SDK automatically produces a working pipeline, and selecting answers that describe OTel as the storage/visualization layer.
Vendor marketing and tutorial framing blur the line. Candidates hear 'we use OpenTelemetry' and infer it is a product. The exam distinguishes the API, SDK, semantic conventions, Collector, and OTLP protocol from the backends that store and query the data.
What to do instead
Fix the mental model: OTel is vendor-neutral instrumentation plus a telemetry pipeline (API/SDK in-process, Collector as a standalone agent/gateway, OTLP as the wire protocol), and it explicitly does not store or visualize. Memorize the Collector's three pipeline stages (receivers, processors, exporters) and be ready to place a component on that diagram when a question asks 'where does batching/sampling/redaction happen'.
Confusing the trace with the span, or assuming a span represents a service rather than a timed operation, leading to wrong answers about parent-child relationships and span counts.
The vocabulary is used loosely in blog posts ('the trace for the checkout service'). Candidates then mis-answer questions about how many spans a fan-out produces, what a root span is, or where a child span's duration sits relative to its parent.
What to do instead
Anchor on definitions: a trace is the whole causal graph identified by one trace ID; a span is a single timed operation with its own span ID, a parent span ID (absent on the root), start/end timestamps, and attributes. Drill the containment rule: a child span's interval normally nests inside its parent's, and a parent's duration includes time waiting on children. Practice reading a span tree and stating which span is the critical-path contributor.
Treating context propagation as automatic across every boundary, and answering that a trace will stay intact through an async queue, a third-party HTTP call, or a message consumer without explicit propagation.
In-process instrumentation is largely automatic, so candidates generalize that tracing 'just works'. They miss that context must be injected into and extracted from carriers at every process and protocol boundary, and that async/messaging hops need explicit linking.
What to do instead
Learn propagation as an explicit inject/extract contract over a carrier (W3C Trace Context headers for HTTP, message attributes for queues). For each boundary type in a scenario, name the mechanism: HTTP header injection, messaging attribute injection, or a span link for batch/async fan-in. If a question shows a broken trace with a new root at a consumer, the answer is missing extraction on the consumer side.
Choosing head-based sampling as the fix when the scenario requires retaining all traces containing errors or slow requests, or conversely choosing tail-based sampling for a constraint on agent CPU and memory at the source.
Candidates learn 'sampling reduces cost' as a single idea and do not separate the decision point (before the trace is complete vs after all spans for a trace arrive). Head-based sampling cannot know the outcome; tail-based sampling requires buffering whole traces and therefore a Collector with capacity.
What to do instead
Memorize the trade: head-based = decision at trace start, cheap, cannot be outcome-aware, good for uniform volume reduction; tail-based = decision after spans are collected, can keep all errors and outliers, but needs buffering and centralized Collector capacity. Match to the stated constraint: 'must never drop error traces' points to tail-based; 'SDK overhead on mobile clients is the binding constraint' points to head-based with a conservative rate.
Assuming that instrumenting every service automatically yields full-stack observability, and ignoring the end-user, browser, mobile, and infrastructure layers when a question asks where the missing visibility is.
Candidates equate 'full-stack' with 'all our backend microservices' and forget the tiers outside the server: real user monitoring, synthetic checks, host/container metrics, and network telemetry. Questions about a slow page that is fast server-side expose this gap.
What to do instead
Build a layer checklist and walk it for every full-stack scenario: end-user/browser and mobile (RUM, web vitals), edge/CDN, service tier (traces, RED metrics), data tier (query latency, connection pools), infrastructure (host/container CPU, memory, throttling), and network (latency, retransmits, DNS). When server-side traces look healthy but users report slowness, the answer lies in a layer outside the service tier.
Answering that AIOps removes the need for observability data quality and governance, or that DevSecOps shifts observability responsibility entirely to a security team rather than embedding telemetry in the delivery pipeline.
Candidates treat AIOps and DevSecOps as buzzword upgrades that supersede fundamentals. In reality AIOps correlates and baselines existing telemetry (garbage in, garbage out), and DevSecOps makes security signals another telemetry stream owned by the same delivery teams.
What to do instead
Frame both as consumers of good telemetry, not replacements. For AIOps: state that anomaly detection and correlation depend on consistent semantic conventions, sufficient history for baselines, and labeled events; noisy or unlabeled data degrades it. For DevSecOps: expect security-relevant telemetry (audit logs, policy violations, vulnerability scan results) to flow through the same pipeline, with the pipeline itself (CI/CD) instrumented and access to telemetry governed.
Describing maturity as a tool purchase ('adopt platform X and you are at level 4') rather than as progression in practice, ownership, and feedback loops, and mis-ordering the stages when asked what a level-2 organization should do next.
Maturity models are abstract, and candidates substitute the concrete thing they know (products) for the abstract thing being tested (capability progression). They also skip prerequisites, recommending SLO-driven error budgets before basic instrumentation consistency exists.
What to do instead
Learn the ladder as capability stages: reactive/ad hoc debugging, then standardized instrumentation and centralized telemetry, then SLOs and actionable alerting tied to user experience, then proactive/production-embedded practices such as chaos testing, continuous profiling, and cost-aware telemetry governance. For 'what next' questions, identify the current stage from the described symptoms and pick the immediately following capability, not the most advanced one.
Blaming application code for latency that the scenario's evidence places in the network or container layer, such as ignoring retransmits, DNS resolution time, CNI overlay overhead, or CPU throttling shown in container metrics.
Candidates default to the layer they understand best (application traces) and under-weight infrastructure signals, especially when a trace shows time in a client span that is actually spent in transit or in a throttled container. Container-level cgroup limits and network path effects are less familiar.
What to do instead
Learn to attribute time by span type: a client span that is long while the corresponding server span is short points to network transit, DNS, connection setup, or queueing outside the server process. Check container signals: CPU throttling (cfs throttled periods), memory limits and OOM kills, and CNI/pod-network latency. When evidence shows throttling or retransmits, answer with the infrastructure cause and its fix (raise limits, fix DNS caching, tune the network path), not with application code changes.