Amazon & AWS SRE / Production Engineer interview questions

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.

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: every layer you can describe is another layer you could debug.

Two different resources produce the same errno, and the second one is invisible unless you know to look. One command distinguishes them.

A beginner question with a senior follow-up hiding in it. Once you know a hard link is a second name for an inode, log rotation and backup behaviour both stop being mysterious.

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.

The swap-used graph is the least informative memory metric on the box. Here is what swappiness actually weights, which numbers to watch instead, and the policy worth defending.

SIGKILL writes no stack trace and the application cannot defend itself. The verdict is already sitting in the kernel ring buffer, and reading it precisely is the skill being priced.

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.

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.

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.

Two questions settle most of it: how much of the machine do you want to own, and is the workload request-shaped or long-running. Fargate is a way of running containers rather than a competitor to ECS and EKS, which is the distinction people get wrong.

The comparison table is easy to recite and explains nothing about the failure the difference actually causes. The ephemeral port range is the whole answer.

Turns the standard autoscaling definition into the problem it actually causes. Almost every candidate can define an HPA; far fewer can say why theirs did not save them.

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.

A design question with a clear answer at this scale, and the reasoning is what scores. The three options solve different problems and peering and Transit Gateway connect networks while PrivateLink exposes services.

Most candidates can sell serverless. The question asks you to argue against it, which needs a real understanding of the execution model rather than the marketing.

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

A question that sounds introductory and turns on one distinction: what you stop operating, and what you start paying for instead. The answer is three mechanical differences and one economic one.

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.

Database redundancy still needs reconnecting clients. Distinguish the deployment type, then measure how promotion and DNS changes affect application requests.

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.

DNS failover is a blunt instrument with three delays stacked on top of each other: detection, propagation and client caching. Knowing their sizes tells you when DNS is the right layer at all.

The cheapest storage class is rarely the cheapest answer. Retrieval pricing, minimum durations and per-transition fees decide whether a lifecycle rule saves money or manufactures waste.

Large object uploads are a reliability design problem, not a bandwidth one. Parts, retries and the completion call decide whether a flaky link costs one chunk or the whole night.

Volume choice is IO-shape matching: burst buckets, provisioned IOPS and throughput designs behave very differently under mixed OLTP-plus-batch load. Average latency graphs hide the failure entirely.

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.

Roles versus users looks like syntax trivia and is actually a secrets-management position. The follow-ups about instance profiles and IRSA separate practitioners from tutorial graduates.

Fleet-wide replacement is a traffic-shaping problem: bake once, wave through in controlled batches, watch the alarms, and keep the exit open. In-place patching is the alternative and usually the regret.

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.

Service control policies cap what anyone in a member account can do, no matter what their IAM admins wrote. The craft is choosing a handful of denials that age well.

Gateway endpoints avoid NAT processing for supported traffic. Interface endpoints have hourly and processing fees; cost savings depend on traffic, while access restrictions need explicit policies.

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.

Orchestration buys a visible state machine with declared retries; choreography buys independence and coupling debt. Money paths usually deserve the state machine.

Postgres spends memory on a backend process per connection, and serverless fan-out treats that as an invitation. Pooling at the proxy layer is the standard cure; pinning is the catch.

Strip the marketing and Aurora is a rewrite of the storage layer: the log is the database, committed to a quorum across three AZs. Know when that machinery pays and when it just bills.

Instance metadata is a local credential vending machine and SSRF is the coin slot. IMDSv2 raises the bar at the host; layered defences and blast-radius limits finish the job.

Account-per-team is the right instinct, but hand-rolled account setup drifts within a month. Vending turns governance into a pipeline with an SLA instead of a ticket queue.

Latency budgets decide architecture, and most teams buy edge compute before earning it with caching and protocol work. Know which rung of the ladder your problem actually needs.

Active-active replication moves writes but not truth. Last-writer-wins quietly discards one of the two orders your finance team expects both to exist.

Four commands, and the interesting one is plan, because it is the only point where you see the three-way comparison Terraform is actually making before anything changes.

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.

The table is half the answer. The other half is who holds credentials, who repairs a stuck lock at night, and why the boring option usually wins until RBAC demands grow teeth.

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 that is worth naming before you reach for it.

The right answer depends on who owns the truth: the platform, the caller, or nobody. At scale there is a fourth option most candidates miss, where your image pipeline publishes values instead of Terraform hunting for them.

Service types choose how an application is exposed. Follow the actual traffic path: cloud controllers can target nodes or pods, and internal exposure differs from public exposure.

A ReplicaSet keeps a count. A Deployment manages a sequence of ReplicaSets, and that is the entire difference: it is what turns a change into a rollout you can pause and undo.

The writable layer is part of the container, not the image, and it dies with the container. Everything about volumes follows from knowing which of those two a file is in.

Explain per-node eligibility and update behaviour, then verify that a Ready collector is actually delivering logs.

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.

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.

The registry is often assumed to figure it out. The real mechanism is an index of per-platform manifests and a client-side choice at pull time, and knowing which layer makes that choice is the whole question.

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.

Scale-downers mark a node removable only when every pod on it can leave safely. Your batch workload died because nothing marked it special. The mechanism is a filter cascade, and the fix is priorities, PDBs and annotations.

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.

Green PRs can still break main because they were validated against a stale tip. Merge queues revalidate the exact combination that lands, trading extra validation work for coverage of combined changes.

Hooks must finish in seconds or developers bypass them, and a bypassed hook protects nothing. Budget feedback latency numerically and split checks by authority and hermeticity.

kubectl-edit happens when no designed emergency path exists. What an expedited lane may drop, what it must never drop, and how pre-authorization plus follow-up tickets keep it honest.

One cadence for every team is the naive answer. Cadence follows constraints: store review for mobile, compatibility windows for APIs, contracts and embedded realities for trains.

The data-path question separates people who have sized a cluster from people who installed one. Shard sizing, refresh versus flush, and each ILM phase carry one specific failure mode apiece.

Where linear models break: compounding growth, step functions, peak days and saturation cliffs. Forecast per constrained resource, backtest, subtract lead time to get the real order-by date.

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.

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.

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.

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.

Bandwidth graphs look healthy and the partner swears they are fine. The wall is ports, not bits: the available source-port budget depends on the gateway and its address allocation.

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.

Stateful firewalls keep established flows alive after their rule vanishes, so cleanup day passes every check and lag appears days later. Flow logs name the hour; inventories prevent the repeat.

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 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.

Two controllers with different opinions and no shared hysteresis. Flat traffic with an oscillating node count means the loop is driven by something other than demand, and the candidates are few.

Code rolled back and the database did not. The old version is now running against a schema it has never seen, and that is a worse incident than the one you were trying to end.

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.

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.

Threat modelling dies as a document ritual and lives as a design-stage habit. The answer that scores: tier reviews by blast radius, short sessions on RFCs, findings filed where engineers already work.

Volumetric floods die at the anycast edge; everything else reaches your origin anyway. The origin leak, expensive endpoints and unproxied surfaces decide whether a CDN is armour or decoration.

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.

It converts a synchronous failure into a delay. That is the whole benefit and the whole cost, because the caller now gets an answer before the work has happened and somebody has to tell them when it did.

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 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.

The catalog is the easy half. The scored half is stampede dynamics: one hot key expiring can multiply origin load by a thousand in a second, and there are three distinct fixes.

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

The vocabulary question hiding real depth: which primitive replaces ORDER BY, why sharding by player is wrong, and what a 45,000 updates-per-second storm actually costs.

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.

Size stored sessions from expiry and creation rates, then decide how quickly logout must take effect and what failover may forget.

Ladders and player logic are the warm-up. Cache topology, egress arithmetic, and knowing which quality metric actually predicts churn are what separate the answers.

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

DNS time-to-live is a suggestion and nineteen minutes is what believing it costs. The mechanism you choose decides your failover time, and the health check you choose decides whether it fires at all.

A question about method, not about tactics. Candidates who open with a list of levers lose to candidates who open with one question about the bill itself.

The difference between scaling node groups and provisioning nodes is the whole answer. One picks from shapes you defined in advance; the other reads the pending pods and buys what they need.

Four purchase instruments, one fleet, and a finance team asking why you did not commit to everything at maximum discount. The scoring rubric rewards the arithmetic of being wrong, not the discount table.

Everyone quotes the discount. Fewer candidates can describe what happens when a notice arrives late or a worker disappears without completing shutdown and why some workloads shrug it off while others lose hours of compute.

Pay-per-use sounds free until the invoice arrives. The useful method is to decompose the bill into invocations, gigabyte-seconds and the lines nobody models, then locate the honest crossover rather than arguing about it.

Most of your rows are read rarely and cost the same as the ones read constantly. Tiering pays for itself only when access patterns are honest, which is why the audit comes before the architecture.

Central teams optimise well and get ignored; federated teams own outcomes and drown in tooling. The mature answer is a hub-and-spoke split by decision type, and the interview tests whether you can say exactly who decides what.

An upfront purchase, a refund and two currencies can produce several valid totals. Work out which total finance needs, then prove every adjustment from the source rows.

A training job is an hours-long computation with no user watching. Whether an interruption costs four minutes or four days is decided entirely by checkpoint cadence and restart semantics designed before the run.

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.

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.

Explain mentoring through an observed blocker, a bounded owned task, useful feedback and evidence that the engineer can apply the learning independently.

Explain a reliability objection through the failing mechanism, a feasible alternative and an explicit decision about the remaining service risk.

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

Defend a change with irreversible effects by separating code rollback, data recovery and external correction, with explicit recovery objectives and tested limits.

Decide whether to continue a migration using remaining costs and current benefits, then deliberately operate or unwind the partial state.

Transfer incident responsibility with current impact, evidence-qualified hypotheses, active changes and the next authorized decision, followed by explicit acceptance.

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.

Compare proxy, hosted and group repositories. Trace a tested artifact into production, and understand when a cache can keep builds running during an upstream outage.

Four levels, and the two that matter operationally are the subscription, where quotas and billing live, and the resource group, which is the unit you delete. Getting the boundaries wrong is expensive to unpick later.

Service principal with a client secret is the answer people give and the one that leaves a credential in a config file. Managed identity is the same object with the secret handled by the platform.

The opener in most DevOps interviews, and the one most people answer as a list of nouns. What earns the follow-up is saying what each stage is allowed to fail for and how long it takes.

Pipeline as code moved the build definition into the repository, where it is reviewed and versioned with the thing it builds. Declarative is the default answer, and knowing when scripted still earns its place is the follow-up.

Jenkins is mostly plugins, they have a dependency graph nobody drew, and the controller is a single point of failure for every team. The answer is a rehearsal against a copy of production, not a maintenance window and hope.