Cloudflare Observability, SLOs & Reliability interview questions

Every candidate can define chaos engineering. Far fewer can say what they would break first, and almost none volunteer the abort condition, which is the thing that makes it a programme rather than an incident.

The observability failure that scales with your success. Cardinality is the cost driver in every metrics system, and the fix has to be structural or it comes back next quarter.

The instinct is to delete old logs. That is backwards: the waste lives in what you ingest, not how long you keep it. This answer walks the levers in the order that actually pays.

Most candidates recite the pull model and stop. The interviewer asking this wants the storage engine story, because that is where Prometheus hurts in production: crash recovery, cold queries, disk death.

Dashboard sprawl is an operating-model problem wearing a tooling costume. The scored answer moves definitions into git, attaches ownership metadata to every panel, and deletes without ceremony.

The kernel watches syscalls, sockets and short-lived processes that userspace agents polling every few seconds never meet. Know what eBPF adds, what it costs, and the security conversation it starts.

Forty healthy islands equal one blind estate. Compare the consolidation patterns honestly, keep alerting local, curate what crosses the WAN, and make the global view read-only and cheap.

Rotation length decides focus versus fatigue, handoff quality decides whether Tuesday inherits Monday's mess, and follow-the-sun only works when every region holds real authority.

Monitoring dies silently: stuck alert queues, full TSDBs, collectors killed inside the same blast radius. Layer independent checks and a heartbeat so absence of signal pages louder than any red dashboard.

You have added a dependency with a latency distribution an order of magnitude wider than anything else in your stack, whose failure mode is a plausible wrong answer rather than an error.

The arithmetic takes ten seconds and most candidates stall on it. The stall is the signal: it means error budgets are something you have read about rather than used.

Alert fatigue is a design failure, not a discipline failure. The fix is a rule about what may page at all, and burn-rate alerting is how you implement it.

A question with a right answer and a subtle reason. Histogram versus summary is the part that catches people, and it turns on whether you can aggregate across instances.

Tracing is the only telemetry that answers where the time went across services. The mechanism is context propagation, and the reason teams fail at it is that one uninstrumented hop breaks the chain.

OpenTelemetry is an API and a wire protocol, not a product. Candidates who promise instant multi-vendor bliss have never run the collector in production or negotiated with a vendor who knows it.

Day-one telemetry is cheap and retrofitting it costs an incident. The answer that scores names the linking layer (trace IDs in logs, exemplars on metrics) that turns three tools into one story.