TCS Incident Response & Production Debugging interview questions

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.

Tests the mitigate-before-diagnose reflex under time pressure, plus whether you know the two ways a disk can be full and the trap that makes freed space not come back.

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

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

Emergency mode after a storage change is usually one line in fstab. The order of operations is what decides the outcome here, along with whether the recovery preserves data-mount dependencies rather than booting past them.

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.

A hang suggests missing progress; a refusal suggests an explicit error. Packet evidence distinguishes firewall behavior from routing failures and closed listeners. Then rule counters, not eyeballs, finger the guilty line.

Everyone reaches for reinstall. The disciplined path is one journal file, four failure signatures, and an explicit decision about whether this host deserves surgery at all.

The reflex is rollback and it is usually right. Shared state, changed credentials and unavailable old artifacts can make an undo incomplete or unsafe. Verify those dependencies before choosing the recovery.

An unchanged pipeline can fail because of environment state, external inputs or a latent artifact defect. Failures that start on an expiry boundary narrow the field to two suspects fast.

This one separates people who read journals from people who restart harder. The exit code and signal systemd already recorded usually name the disease.

Nothing errors because dropping unmatched lines is documented behaviour. Counting the tagged failures converts an invisible leak into a number, and numbers have owners.

Duplicate-IP claims need evidence, and one command provides it. Then the real skill: telling a genuine two-owner clash apart from ARP flux, because the fixes could not be more different.

Exit codes said green while the warehouse went hollow. Where detection should have sat, why retries could not help, and the backfill discipline finance will actually accept.

Two commands disagreeing is the diagnosis, not the mystery. A deleted file with an open handle is invisible to du and fully charged by df, and rm made it worse rather than better.

The heap is the part you configured and the smaller part of what the process uses. The kernel counts everything the cgroup touches, including the page cache the JVM never asked 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.

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.

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.

A senior favourite, because the naive answer is to look at averages and the average is exactly what is hiding the problem. Tail latency has a short list of causes and they are all structural.

Tests whether you know that Kubernetes waits, and for how long. The default timings surprise most candidates, and they explain why a node failure hurts longer than people expect.

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