Start here

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.

The oldest question in systems interviewing and still the best, because it is unbounded: the interviewer stops you when you run out of depth, and where you stop is the score.

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.

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.

Most candidates can recite the flags. The scored part is proving you can capture on a saturated box without adding load, then read the file afterward like evidence.

The signature is unmistakable once seen: handshakes complete, then the connection freezes at the same byte count every time. Here is the probe sequence and the fixes, ranked.

Table full is the symptom everyone knows. The interview answer lives one layer down: per-state timers, the five-day ESTABLISHED default, and what conntrack -S says about hash pressure.

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.

Most throughput tests measure the tester, not the network. Single stream versus parallel, slow start, sender-side retransmits, and the CPU ceiling: how to produce a number you can act on.

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.

Asked in almost every cloud screen, and most candidates recite the table without ever naming the failure it causes. The ephemeral port range is the whole answer.

The question that separates console users from people who have debugged a permissions failure across accounts. Evaluation order is deterministic and knowing it makes AccessDenied readable.

Trace the route and return path before changing rules. First establish whether the failing connection uses IPv4, IPv6 or a private service endpoint.

S3 access failures are rarely about the bucket policy alone. The caller, object ownership and network path determine which authorization checks apply. Start with the failed request and trace changes across those boundaries.

A busy date key can throttle while table capacity remains available. Check the actual key distribution and throttling reason before adding capacity or shards.

Rapid function scaling can overwhelm a shared dependency. Concurrency limits, reserved capacity and queue buffering are the containment toolkit.

Cross-account access is easy to grant and easy to get wrong. External IDs, scoped roles and audit trails separate a controlled bridge from an open door any tenant can walk through.

Queue, log and router solve different problems that all get called events. Picking by workload shape beats picking by whichever service the team already knows.

Four tiers, four bills. Stating RTO and RPO per tier turns a vague resilience wish into a decision leadership can actually price, and the testing story is where candidates fold.

Blue-green works for stateless apps because instances are disposable. Databases are shared state, so safe migrations ride on backward compatibility and an explicit rollback boundary.

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.

Everyone can say state maps config to reality. The follow-up that separates candidates is what else is in the file, and what that means for who may read it.

The services-market question that decides who can actually run a migration. Import is the easy part; the hard parts are resource-for-resource fidelity and proving the first plan is empty.

Extract too early and you maintain a wrapper nobody thanks you for. Here is the extraction trigger, the semver contract that maps onto Terraform surfaces, and the parallel-release path for breaking changes.

sensitive = true stops the echo, not the storage. The complete answer walks the value through git, plan artifacts, state, and provider side effects, naming which mitigation closes which leak.

Three lifecycle arguments influence replacement and drift handling: create_before_destroy, prevent_destroy, and ignore_changes. Each earns its place through an incident story, and each has a failure mode interviewers wait to hear you name.

Stack boundaries follow blast radius and change frequency, not the org chart. The monorepo only pays for itself while a machine can answer, from a commit, exactly which roots need planning.

state rm, import, moved and removed blocks each treat a different wound. The senior signal is not reciting commands, it is the backup, lock and plan ritual wrapped around touching production state.

Four-hour applies with throttling errors share one root cause more often than not. Diagnose which calls burn the quota, split the state along dependency seams, and touch the parallelism flag last, not first.

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.

Asked in nearly every senior Kubernetes loop, and most candidates answer with a feature list. The scoring answer names the three problems it solves and then argues for not adopting it.

Everyone can recite the three. The scoring answer is what each failure causes, and why a badly configured liveness probe is more dangerous than none at all.

A practical question with a precise answer, and the size is not the real cost. Pull time on every node, registry storage, and attack surface all scale with it.

Cilium became the default CNI on major managed platforms for a reason that is mechanical rather than fashionable. The iptables datapath degrades with service count, and eBPF replaces a linear scan with a map lookup.

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.

The kubelet is a local reconcile loop with its own event stream, probe workers and eviction brain. Staff-level candidates can narrate it and explain why Ready status can reflect either reported health failure or missing heartbeats.

Dockershim is gone and the CRI contract decides what a runtime must do. The senior-level part is the shim model: a supervisor process that owns exit codes and stdio so the daemon can die without taking workloads with it.

Controllers should never poll, yet most home-grown operators do. This question separates people who run controllers at ten-thousand-object scale from those who copied a tutorial: watch semantics, cache behaviour, and which LISTs touch etcd.

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.

Exit codes, the previous-container log, and a little-known file at /dev/termination-log that carries a container's last words into kubectl output. Scale triage starts with classification, not with opening pods.

The interviewer does not want the three definitions. They want a decision, the number that justifies it, and what you do when the canary looks fine for nine minutes and then does not.

A question about developer experience as much as engineering. Measure before optimising, and notice that the trust problem and the duration problem may have different causes.

The deployment question that has a real answer and a real trap. Code and schema deploy at different speeds, and any step where they must change together is the step that causes the outage.

Testing is a pipeline design problem in this role, not a QA one. The constraint is the question: you cannot run everything on every commit, so what you choose to defer is the answer.

The security argument for GitOps is more specific than 'Git is the source of truth'. Pull deployment can remove cluster credentials from CI, and that single fact is most of the case.

Most candidates narrate the YAML. The scoring starts underneath: who schedules what, where artifacts live between jobs, and why disposable runners rewrite how you think about caching and trust.

Self-heal did exactly what it was configured to do. The senior answer is not switching it off; it is designing the Git path and the sync order so nobody bypasses the system at 3am again.

If every environment rebuilds, staging never validated the bytes production runs. The promotion model auditors and 2am responders both love, plus the costs nobody mentions until adoption.

Deployment and release are two decisions, not one. The flag patterns that buy you instant reversibility, and the retirement discipline most teams skip.

Public fork PRs normally get a read-only token and no repository secrets. Privileged triggers, runner access and untrusted shell input can break that boundary.

Reciting metric names scores low. Naming the definition decisions that corrupt each one, and the gaming that starts when targets appear, scores high.

For scheduled and stateful workloads the exposure unit is records and time, not requests: shadow runs on real input, row-level diff budgets, checkpoint compatibility, one-cycle warm standby.

Most candidates discuss caches as a speed feature. The staff-level answer treats write access to a shared cache like deploy credentials and proves hermeticity with sampled cold rebuilds.

Runner migration questions hide two different exams: whether a PR job can steal your cloud credentials, and why the fleet idles at half price all night. Isolation first, economics second.

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.

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.

Anyone can divide bad requests by total. This answer shows the aggregation mistakes that quietly corrupt SLO dashboards, the rate-versus-increase traps that make budgets lie, and when subqueries cost too much.

Choose what evidence must survive, then price the collection path. A tail policy can only inspect traces that reach it; low SDK sampling changes the guarantee before the collector sees a span.

Request-shaped SLIs quietly fail on data platforms. The strong answer defines freshness, completeness and deadline SLIs on consumer-visible artifacts, not job success rates.

MTTR is three clocks hiding in one number. Profile detection, diagnosis and fix separately from incident timestamps; attack whichever clock dominates, which is almost never rollback speed.

Their green page, your red SLO. Separate their true failure rate from the amplification your own client adds, buffer at the boundary, then escalate with a client-side scorecard instead of feelings.

An SLA is a price list for failure signed before the failures. Bring the measured distribution, negotiate methodology and exclusions harder than the headline number, and phase targets with dates.

The most-asked scenario question in DevOps interviews, and the one where candidates most often list commands instead of reasoning. 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.

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.

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.

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.

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.

Same-node good, cross-node bad is not a random clue, it is nearly a diagnosis. One short decision tree separates overlay reachability, encapsulation blocks, MTU and policy.

NFS waits can stall shutdown and inflate load average while CPUs stay idle. Check the blocked kernel path before deciding whether signals or mount recovery can release it.

The kill was not random and it was not fair. Learn the scoring function the kernel actually uses, then bend it with oom_score_adj before your monitoring dies during the next leak.

Spikes that march in step with BGSAVE are a page-size story, not a network story. Check actual huge-page usage, fork duration and copy-on-write pressure on the deployed kernel.

Split-brain writes are a fencing failure first and a data problem second. Freeze writes, read the divergence boundary from replication positions, and let the payment ledger arbitrate reality.

Stop the source before tuning anything: kill the runner, revoke its credentials, shed test-shaped traffic at the edge, protect checkout. Forensics and guardrails only after customers stop feeling it.

An incident response question wearing a Git costume. The wrong instinct is to rewrite history first, and it costs you the hour that matters.

The single highest-value security change available to most pipelines, and the reason it works is worth understanding rather than configuring. It removes the secret rather than protecting it.

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.

Everyone endorses least privilege; few can describe how they would measure over-permission across a fleet. The scoring answer names the evidence source, the tiered remediation, and the break-glass hatch that makes it survivable.

Signing proves what shipped, not what runs. The strong answer covers syscall-level detection, the signals that matter, tuning against alert fatigue, and the response path once a sensor fires.

Miners prove unauthorized workload execution, not a particular intrusion sequence. Parallel identity and network containment, backup control-plane protection, rebuild-don't-clean, and restore points older than patient zero.

Break-glass exists to restore login when the identity provider is the thing that died. Few accounts, sealed hardware factors, an alert on every authentication, a printed runbook and a quarterly drill.

Trace who can read ciphertext, who can decrypt it and who can administer the keys. Key rotation, rewrapping and data re-encryption solve different problems.

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.

The classic napkin-math question. The number in the prompt is the question, and candidates who draw the architecture before doing the arithmetic design something the physics forbids.

The design round where the honest answer is mostly about data. Stateless traffic across regions is straightforward; the database is where active-active is either solved or pretended.

The migration question, and the trap is answering with a target architecture. What is being scored is sequencing: how you get there without a rewrite and without a release freeze.

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.

Every candidate says replication and failover. The scoring answer names the replication mode, states the resulting data loss window, and explains how the cluster avoids two primaries.

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.

Everyone names token bucket. The scored part is the rest: drift between nodes, the 429 contract with clients, and whether your quota service should fail open or closed.

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.

Timeouts guarantee uncertainty, not failure: the first request may have succeeded after the client gave up. The idempotency key pattern is the industry answer; the scored details are storage, expiry and concurrency.

The most rehearsed design question, which is exactly why interviewers score the parts blog posts skip: redirect semantics, key generation under failure, and analytics kept off the hot path.

Sharding buys write headroom and bills you in joins, foreign keys, and every future migration. The key choice is a query-pattern bet; the resharding choreography separates operators from diagram artists.

Everyone sizes a metrics system by samples per second and everyone is wrong. The constraint that actually kills these platforms is a single label added on a Friday.

Leases prevent dead holders but not overlapping ones. The staff-level answer is fencing tokens and a candid account of why quorum lock services without downstream checks are still probabilistic.

Listing the match job is table stakes. The scored material is the breaks taxonomy, the suspense account, and why every match must be replayable from immutable raw files.

A disputed invoice needs a reproducible calculation. Retain raw usage events and versioned pricing so each line can be explained and corrected.

A platform question that is really a product question. The design is the easy half; the answer that scores explains how you would know developers chose it rather than were forced onto it.

Over-requested CPU and memory can prevent efficient node packing. Cutting them safely is a measurement problem with a reliability trap sitting in the middle of it.

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.

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.

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.

The most revealing behavioral question there is, because the interesting part is what you did after losing. Most candidates answer a different question, the one where they were right all along.