Google SRE interview questions

Ordering and retransmission are what TCP adds, and both of them cost time. Naming something that deliberately gives them up, and saying why, is what turns a textbook answer into a real one.

The arithmetic takes thirty seconds to learn and gets asked constantly. What it is really testing is whether you have ever had to size a VPC that could not be resized later.

Most of what looks like used memory on a healthy Linux box is page cache doing its job. Knowing which column to read, and why df and du disagree, is half of Linux triage.

The question that separates people who have debugged a hung rollout from people who have read about one. The interesting half is not the signal, it is PID 1.

A staple of every networking round, and the follow-up is always about TLS termination. Knowing which layer sees what decides most of the answer.

The oldest question in systems interviewing and still the best, because it is unbounded: every layer you can describe is another layer you could debug.

The question that reveals whether someone knows what load average actually counts on Linux. It is not a CPU metric, and that single fact resolves the whole thing.

The classic ephemeral port exhaustion question. TIME_WAIT is a familiar phrase and the useful facts are narrower: which side accumulates it, and why the popular fix is dangerous.

The scripting round in disguise. The constraint is the question: it exists to see whether you stream or whether you load, and everything else is about whether the script is safe to run twice.

The two-syscall duet behind every process on the box. The follow-ups live in what survives the transition, and candidates who skip that fail the next question.

Everything top, htop and your APM agent display is derived from procfs anyway. Knowing the raw files turns any bare SSH session into a monitoring console.

Multiplexing removes application-level queuing and hands the problem to TCP. Here is where the blocking really lives, the loss math behind it, and the four levers that help.

Loss-based versus model-based congestion avoidance decides whether your WAN transfers fill the pipe or die on the first stray drop. Here is the operator's decision, not the RFC summary.

Anycast turns BGP convergence into your failover mechanism. Sessions stick to the site they landed on, monitoring must go per-site, and a route you cannot withdraw cleanly is worse than DNS.

Two structural differences matter more than any service mapping: the VPC is global rather than regional, and permissions are granted to members on resources through a hierarchy rather than attached to identities.

Spreading instances across availability zones is not the same as surviving an AZ failure. What makes the difference is being able to name the four coupling points that quietly re-unify a blast radius you thought you had split.

A cluster boundary does not always create a new cloud identity. Inspect the workload pool and principal identifier before assuming a leaked key.

The Terraform question that actually filters. Everyone knows both meta-arguments exist; the answer is about how state addresses resources, and why an index is a fragile key.

A pod is a shared network and storage boundary that happens to contain containers. Once you can say what the containers inside one share, sidecars and init containers stop needing separate explanations.

Selectors match object labels; owner references record controller relationships. Keeping those mechanisms separate explains how a Service can select the wrong pods without owning them.

Build instructions depend on earlier inputs, so changing source can invalidate a dependency installation placed after it. Ordering the Dockerfile by how often things change is the whole optimisation, and multi-stage is how the compiler stops shipping to production.

The single most common Kubernetes interview question, and the one where a vague answer is most obvious. Every stage you name is a place the interviewer can ask you to debug.

The pair everyone configures and few can explain. QoS hints at eviction risk, but usage versus requests and Pod priority determine node-pressure ranking, and CPU and memory behave completely differently when you exceed them.

Trace sandbox setup, address allocation and a cross-node packet, then distinguish pod reachability from Service translation.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Describing it as 'it keeps N pods alive' states the part it does not do, since it constrains voluntary eviction and not the machine that fails.

Init containers are the easy half. The hard half is why plain sidecars race your app at both ends of the pod's life, and what restartPolicy Always changes about that.

A registry stores repositories, which hold manifests, which point at content-addressed blobs. Being able to draw that hierarchy and the auth exchange around it accounts for essentially every pull failure, because each one is a specific step in it returning something other than 200.

The kubelet is a local reconcile loop with its own event stream, probe workers and eviction brain. The detail worth holding onto is that Ready status can reflect either a reported health failure or missing heartbeats, and those have different causes and different fixes.

Every control plane component depends on the API server, so who starts the API server? The bootstrap paradox sits at the heart of every cluster, and the kubelet plus a directory of files is the accepted way out.

SSH plus yum is how outages start. The senior answer replaces nodes from versioned images on a cadence, orchestrates with surge capacity and PDBs, and can explain the kernel-skew problem that makes fleet homogeneity a feature.

Upgrades look like rolling restarts right up to the morning the CNI stops talking to the new kubelet. The scored answer is ordering, skew policy, and addon sequencing, not courage under pressure.

The classic five-second stall is rarely CoreDNS being slow; it is UDP, conntrack races and ndots expansion. The diagnosis ladder and the NodeLocal DNSCache fix separate operators from readers of architecture blogs.

Three API servers behind one health-checked endpoint, etcd on its own quorum, leader election everywhere else. The scored part is naming what degrades quietly before anything alerts.

Kubernetes does not see GPUs, it sees an extended resource that something has to advertise. When that advertisement is missing or wrong, the scheduler is behaving correctly and the node is lying.

A Job with a sidecar was broken by design for years: the workload finishes, the proxy does not, and the pod never terminates. Native sidecars fix it by making the container an init container that keeps running.

Changing pod resources historically required recreation, which made vertical autoscaling disruptive for workloads with expensive recovery. In-place resize changes that, with limits worth knowing.

Ingress solved routing by convention and annotation, which meant every controller invented its own. Gateway API's real contribution is not features, it is splitting one object into three so that platform and application teams stop editing the same file.

An end-of-maintenance date changes the risk even while traffic stays healthy. The work is proving routing and security parity before moving a production hostname.

Clusters multiply for good reasons: regions, isolation, tenancy, blast radius. The problem is not creating them, it is that cluster seven diverges from cluster three and nobody knows until an upgrade behaves differently.

Route attachment and cross-namespace backend access have different owners. Use route status to find the failing boundary before broadening any permission.

Compare a shared-library patch across forty services, including affected builds, staged releases, runtime inventory and source-access boundaries.

Long-lived branches pile up merge debt until integration becomes a gamble. There is a named technique that ships a three-month refactor in releasable increments, and its final step is deletion.

The honest mechanics of merging to trunk many times a day: flags, fast CI, trunk locks, and the conditions under which you should not run it at all.

Build graphs identify affected targets only when their dependencies are complete. The ladder from build-everything to content-addressed caching, hermeticity audits, and where undeclared inputs rot correctness.

Ownership files decay faster than org charts. What separates working CODEOWNERS from rubber-stamp theatre is hygiene: team aliases, stale-owner linting, and keeping review routing apart from paging.

The arithmetic takes ten seconds and is the part most often skipped. 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.

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.

The roles question is really a delegation test: can you split commanding the incident from fixing it? Name the roles, the comms cadence, and the handoff discipline that keeps 3am coherent.

Spending the budget is arithmetic; enforcing consequences is politics plus automation. The answer that lands names trigger thresholds, the deploy gate that blocks releases, and the dated escape valve.

Facilitation is mechanics: timeline before theories, blame converted into system questions, actions with owners tracked to closure. Include the defensive engineer and the exec who wants a head.

Internal platforms hide a trap: the direct user is an engineer, but the real traffic belongs to their customers. Define SLIs from the consumer's vantage and turn the error budget into roadmap currency.

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.

Tracing tells you which service and which span. It stops at the function boundary, and that is exactly where a CPU regression lives. Continuous profiling is the layer most teams do not have when they need it.

HTTP success can carry a rejected-span count. Replaying that batch can duplicate accepted telemetry, while enlarging the queue cannot repair invalid data.

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.

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.

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.

Low utilisation with terrible tail latency is not a contradiction. It is the CFS quota doing exactly what it was configured to do. Most candidates have never read nr_throttled.

A two-second dependency should cost you latency, not three services. The mechanics are arithmetic: Little's law plus retry amplification. The fix is a budget, not a ban.

Repeated action items are a measurable defect with a mechanical cause. Answering 'culture' without a mechanism describes the symptom back rather than fixing it.

One disk metric explaining a whole cluster's weirdness is the point of this question. Restarting etcd first turns a slow cluster into a down one, because a restarted member has to catch up before it can vote.

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.

Slow leaks hide inside restart cycles and percentage thresholds. Plot weeks of absolute memory against deploys, prove it with profiler deltas, and alert on predicted time-to-limit instead.

Fork failures can reflect PID limits or memory allocation failure even when host RAM looks available. Find which ceiling broke, cap PIDs per cgroup so one team's leak costs one pod, and fix the unbounded spawn.

The pods are Pending, the nodes are Ready, and the GPUs have vanished from allocatable. Something changed on the node under a fleet that nobody considered part of the deploy surface.

A drain that hangs without erroring is almost always eviction being refused, and the two refusals that look identical from the outside have opposite fixes.

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 volume is in one availability zone and the scheduler cannot move it. Spare capacity in the other two zones is not spare capacity for this pod, and no amount of scaling helps.

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.

Every SDK fetches its credentials from a link-local metadata endpoint with a modest request budget. Enough containers refreshing at once and the endpoint starts refusing, which the SDK reports as an auth problem.

Three terms that get used interchangeably and answer three different questions. The one that makes them operational is the admission rule at the end: no provenance, no deploy.

Choose by trust boundary, not fashion: mesh-issued mTLS inside a cluster, audience-bound tokens across teams and clouds, both together at scale. Static shared secrets are the thing being replaced.

Stateless does not mean there is no state. It means the state is not in the instance, which is what lets you kill any instance at any time. Every scaling and deployment property people want depends on that one thing.

The classic napkin-math question. The number in the prompt is the question. Drawing the architecture before doing the arithmetic produces a design the physics forbids, and the arithmetic takes a minute.

The Google-style NALSD round in miniature. The boxes are easy; what is being scored is whether the numbers fall out of Little's law before you draw them.

Cron is the most-deployed scheduler on earth and the worst-behaved at scale. The scored content is everything crontab cannot do: exactly-once firing, thundering herds, and what happens when the scheduler itself dies.

CAP is not a menu of two letters per system. The scored answer knows what the theorem claims (narrowly), what most engineers misquote, and what a split-brain costs when both halves accept writes.

Type-ahead is a latency budget wearing a search costume: keystrokes arrive every 200 milliseconds, so anything slower feels broken. Prefix indexes, freshness tiers, and typo tolerance are the scored parts.

Drawing an agent that polls a server is the easy third. The interview is about partial applies, fleet-versus-world state, and why rollback must be a pointer flip, never a reverse edit.

Reciting both acronyms is the median answer. Expert level chooses by connectivity assumptions and undo semantics, then defends CRDT metadata growth with numbers.

Comparing the canary against last week is how a Tuesday afternoon looks like a regression. Compare it against a baseline running the same traffic at the same moment, and decide with a threshold somebody can defend.

Announcing a deadline is not a migration plan. The teams that miss it are the ones who were never going to read the announcement.

An internal platform with no stated objective still has one. Every team guesses it, they all guess differently, and the guesses only surface during an outage.

Forty minutes is a symptom with at least four different causes, and three of them are cheaper to fix than moving everyone's development to a remote machine.

You cannot run the counterfactual. What survives scrutiny is a comparison design that narrows the alternatives, not a number that claims to settle it.

A loop that calls a model, gets asked to run a tool, runs it, and feeds the result back. Every operational difference comes from the fact that the number of iterations is not known in advance.

The question that separates people running GPU clusters from people running Kubernetes clusters that happen to have GPUs. The answer is that an integer count cannot express what a GPU workload needs.

Three sharing modes with three different isolation guarantees. MIG partitions the hardware, MPS shares the SMs, time-slicing just interleaves contexts, and picking wrong turns a latency SLO into a lottery.

The default scheduler places pods one at a time, which is exactly wrong for a job that needs all sixteen or none. Two half-placed jobs can hold each other's GPUs forever without either ever starting.

The driver, the container toolkit, the CUDA runtime inside the image and the framework build all have to agree. Upgrade the wrong one first and every pod on the node fails to start with an error that names none of them.

At sixteen GPUs and above, the network is the computer. Collectives run at the speed of the worst link in the group, and placement decides which link that is.

GPU capacity is not elastic the way CPU is. On-demand means whatever is left after the reservations, and in a tight region that is nothing, so the availability problem and the cost problem are the same problem.

The fastest-growing design round in infrastructure hiring. GPU economics break the assumptions CPU autoscaling is built on, and the answer has to start from that rather than from Kubernetes.

CPU memory intuition fails on inference servers. The scarce resource is KV-cache, requests arrive with unseen context lengths, and the fix is queue-depth scaling plus admission control, not bigger pods.

Code rollouts ask 'does it work'; model rollouts ask 'is it better', and the second question has no HTTP status code. Shadow traffic, offline eval gates and quality canaries replace the 500-rate dashboards you cannot use.

The utilisation number everyone quotes means at least one kernel was resident, not that the hardware was doing useful work. A GPU at 95 percent can be doing five percent of what it is capable of.

Code and data are the two things people pin, and they are rarely the two things that changed. The driver, the framework build, the kernel selection and the data ordering all vary underneath a pinned repository.

Failure stops being an event and becomes a rate. Once mean time between failures drops below the length of a run, the design question is not how to avoid interruption but how cheaply you can absorb one.

A release-automation design question with a specific trust boundary. The novel risk is prompt injection: untrusted text reaching a privileged agent, where the text is the instruction and your usual input validation does not apply.

Untrusted text reaching a privileged agent is the whole vulnerability. It is the pull_request_target mistake again, with a model in the middle that will follow instructions it finds in the data.

GPUs are the default for reasons that hold for large generative models and not for everything else. A small classifier on CPU can be cheaper, more available and easier to operate, and knowing where the crossover sits is worth more than knowing the newest card.

A model artifact is code that runs in your cluster with GPU access. Most of the supply-chain controls you already run for containers apply, and the file format adds one of its own.

The question is really whether you learn deliberately or absorb whatever passes by. One specific thing learned recently, with why you picked it and what you did with it, beats any list of newsletters.

An incident answer needs your actual decisions, the evidence behind them and the effect on users. A wrong turn belongs in the story only if it happened.

Explain a technical disagreement you lost, how you supported the chosen implementation and which evidence would justify reopening the decision.

Prepare an accountable account of a technical mistake: disclosure, recovery decisions, a tested prevention measure and the residual risk.

Facilitate a disputed design by stopping personal attacks, separating testable assumptions from priorities and assigning a decision owner.

Turn difficult feedback into a testable improvement, while checking its factual basis and keeping unfair or inappropriate treatment separate.

Make early incident reporting practical through a usable escalation path, constructive response and visible corrective work, without turning reports into a performance quota.

Build a reliability proposal with observed impact, uncertain risk, implementation cost and a verification plan that supports an explicit priority decision.

Coordinate a major incident through explicit roles, bounded investigations, safe recovery decisions and a handoff that preserves current state.

Write an accurate incident review that examines the triggering action and contributing conditions, with corrective actions whose effectiveness can be checked.

Report an unnoticed production problem promptly through the right channel, distinguish actual impact from a near miss and verify the control or detection gap it reveals.

Evaluate a hiring concern against role-related evidence, the quality of the interview sample and the agreed assessment process, without giving unevidenced impressions veto power.

Multi-AZ is the answer and the reason matters more than the acronym. Each tier fails differently, and the database is the one where high availability means a failover with a real gap, not zero interruption.

One is layer 4 and regional, one is layer 7 and regional, one is layer 7 and global. Answer on those two axes and the choice makes itself, including when you need two of them together.

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.

Five stages, and which one you are stuck in tells you what to fix. A machine that reaches a GRUB prompt has a different problem from one that hangs waiting on a filesystem that no longer exists.

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.

The Indian e-commerce interview question, and autoscaling is the wrong first answer. A 10x spike arriving in seconds outruns any scaling loop, so the design has to absorb rather than scale.

Interviewers use this to sort memorised trivia from people who have chased a slow lookup. Three roles, one bit, and the caching rules most candidates repeat incorrectly.

A growing backlog of sockets waiting for the application to close its side usually points at lifecycle handling. Here is the hunt from ss output to the pool timeout that caused it.