Cloudflare Incident Response & Production Debugging interview questions

Status codes describe an HTTP failure category. Locate the component that emitted the response, then use its logs to distinguish connection, capacity and application failures.

Intermittent DNS is the most-reported and least-understood Kubernetes failure. There are three well-known causes and each leaves a different fingerprint.

Both can be right, which is the whole point. Retransmissions mean a segment was not acknowledged, and the network is only one of the places that can happen.

The classic gap between what the backend measures and what the user experiences. A 504 is emitted by something in front of the backend, which is exactly the part your service dashboards do not cover.

Automation can renew a certificate without deploying it correctly. Check the served leaf and chain, the client trust store and the exact verification failure.

Established traffic keeps working while new connections die at random, which is exactly why this one confuses people. The table is full of flows that will not be needed again for days.

One saturated core on a proxy is rarely about raw traffic volume. It is a parallelism failure with three usual suspects, and the per-thread view names the culprit in minutes.

Gradual drift produces no errors on the host that has it, only weirdness everywhere else. Sweep first, histogram second, repair third: the distribution shape names the culprit before you log into anything.

Mixed resolution after a transfer is not propagation voodoo. Compare the parent delegation, authoritative answers and validation results. NXDOMAIN and SERVFAIL are clues; neither names a unique cause.

Purges act on exact cache keys, and the edge is full of variants the purge never named. Verify per variant at real POPs, then fix the key model instead of chasing URLs forever.

Raising the limit buys hours and proves nothing. The six-hour periodicity is the diagnosis: something is opening descriptors on a code path that never closes them.

The disk is not full, the keyspace quota is. Defragmenting without disarming the alarm leaves the cluster read-only, and disarming without compacting puts it back within minutes.

The pod's resolver is configured to try five search domains before the real one. An uncached external hostname can trigger several search-expanded queries before its absolute lookup, and the failures are what you are paying for.

Somebody silenced it during an incident nine days ago to stop the noise, and nothing ever expired the silence. The monitoring was working perfectly and nobody was listening.

A deceptively deep question, because there are at least six places a version can get stuck and they span the pipeline, the cluster and the edge. Work the path in order.

An idle database with a starved application is the tell. The connections are held, not used. More database capacity does not release leaked connections.

Three places, and which one depends on how the thing was started. Knowing which logs the runtime collects and which the application writes itself, and that journald may not persist across reboots, saves the first twenty minutes.

A common scenario question, and the one where a list of commands most often stands in for an argument about what each one eliminates. Empty logs is the clue, not the obstacle.

The gentlest scheduling question there is, and it still separates people who read the events from people who guess. Check whether the pod has a node before choosing between scheduling and startup diagnosis.

The pods are Running, the dashboard is green, and users get errors. The gap between Running and receiving traffic is where this question lives, and it has a precise answer.