Swiggy SRE / Platform Engineer interview questions

Everyone knows ulimit -n. The interview question is which process inherits which value, why limits.conf did nothing for your service, and how you size the ceiling honestly.

A and AAAA are the easy part. The bites live at the zone apex, inside 255-byte TXT chunks, in CAA blocking your renewals, and in SRV records half the internet ignores.

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.

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.

Ask whether Multi-AZ means a DB instance or a DB cluster. One has a non-readable standby; the other has two readers. That distinction decides whether the proposal can relieve the primary.

Sessions, locks and pub/sub are three very different contracts with the same server. Knowing which guarantees each one lacks is the difference between a cache and an outage.

Origin access control pins the bucket to your distribution, and signed URLs or cookies decide who plays what. Get the expiry wrong and the leak comes back with a signature on it.

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.

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.

A dead-letter queue with no owner is a landfill with a nicer name. Triage discipline separates teams that recover messages from teams that archive regret.

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

One ForceNew attribute turns an edit into a destroy. Know the schema mechanics, the four lifecycle levers, and why create_before_destroy trades downtime for name collisions.

Static INI files die somewhere near two hundred hosts. Point inventory plugins at the systems that already know the truth, derive groups from tags with constructed inventory, and plan for stale hosts before they page you.

Terraform shapes the world; images define what boots inside it. Bake contents into versioned artifacts on a patch cadence, roll fleets by replacement, and keep user_data for identity and wiring only.

PDB governs voluntary disruptions only and does not gate rolling updates at all. Candidates who say 'it keeps N pods alive' have just described the part it does not do.

Priority is one number with three separate effects: scheduling order, preemption victim selection, and eviction order under node pressure. Conflating those is the trap; designing tiers that survive both a full cluster and a hot node is the pass.

Utilization-based scaling is the wrong sensor when work arrives as backlog. The design questions are threshold math against drain rate, reaction-time bounds from polling, and why lag-driven fleets oscillate without generous targets and idempotent consumers.

The gating instinct is right and the cardinality is wrong: init containers make every new replica race the same migration. Here is the once-per-release shape interviewers want, plus the rollback rule that shapes all DDL review.

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.

A vocabulary check with a trap inside it. Strict semantic versions bind libraries and SDKs; continuously deployed services play a different game, and pretending otherwise signals inexperience.

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.

A freeze enforced by email is a suggestion. Tier services, put the window in deploy tooling, price exceptions honestly, and judge the policy by incidents prevented.

Dependency bots fail as noise generators or silent auto-mergers. Tiering by risk, weekly batching, and treating bot PRs with a real review SLA is what keeps updates flowing.

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.

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.

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.

Metrics describe the server's experience; synthetics describe the user's. The strong answer designs a few money-path journeys from real geographies, pages only on persistent failure, and budgets for script rot.

Usable runbooks live one click from the alert, front-load symptom-to-action pairs, and stay alive because CI and drills force the issue rather than anyone hoping.

Rotation length decides focus versus fatigue, handoff quality decides whether Tuesday inherits Monday's mess, and follow-the-sun only works when every region holds real authority.

One surface cannot serve the responder and the review. Tier dashboards by the question each audience asks, and make every tile answer in five seconds or link one click deeper.

Sampling keeps proportions and loses rare individuals; filtering keeps chosen classes complete and loses whatever you misclassified. Decide retention at write time, keep counters always, rehydrate the rest.

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.

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.

The reflex is rollback and it is usually right. There is exactly one class of failure where undo makes things worse, and knowing it is the entire interview.

The box looks CPU-starved but the CPUs are starving themselves. Reading the reclaim loop correctly separates people who have sat on the console from people who have read about it.

The backup is doing its job and the database is paying for it. Attribution first, then enforcement that actually binds on modern kernels, because priority support depends on the active kernel and IO scheduler.

A public registry throttles by source IP and your whole fleet shares one. Why fifty nodes count as a single anonymous user, and authentication and caching changes that reduce upstream demand.

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.

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.

Reciting injection classes you cannot fix is the trap. The scored move maps each risk category to a lever an ops or platform engineer owns, from response headers to metadata endpoints.

The dangerous question is not whether the vendor is secure but what the integration can touch once connected. Scope of granted access, data flow, offboarding, then tier the vendor and match effort to tier.

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.

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 interviewers score the parts 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.

Two contracts in one system: an OTP with a 30-second promise and a sale announcement reaching fifty million phones without burning providers. Priority lanes and double-layer dedup decide the grade.

The app server that proxies uploads through itself is the design that fails this question. Direct-to-storage, validate after arrival, and make CDN invalidation almost never necessary.

The difficult decisions are preserving offline intent and enforcing rules that span devices. Interviewers want conflict classes named and handled deliberately, not a CRDT framework proposed on instinct.

Vendor limits are a shared budget your own teams will fight over. Broker the capacity, degrade by priority lane, and never let feature code see vendor HTTP semantics.

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.

Percentage savings make every quarter look like a win and tell you almost nothing. The candidates who get hired bring a denominator tied to revenue and defend it under pressure.

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.

Pay-per-use sounds free until the invoice arrives. The candidates who impress decompose the bill into invocations, gigabyte-seconds and the lines nobody models, then locate the honest crossover.

A services-industry staple that ends more managerial rounds than any technical question. The scored signal is whether you can say 'yes, with these guardrails' or 'no, and here is the Monday alternative' without either sounding like a refusal or a pushover.

Burnout questions look soft but score systems thinking. Interviewers want the signals you watched, the structural fixes you made, and the number that proved the fix worked.

Noisy-neighbour questions score evidence, translation and patience. Show how the other team's fix becomes their idea, and when the risk needs immediate incident coordination.

A composure test wearing a war-story costume. Interviewers score whether you correct the record with evidence, refuse mid-incident litigation, and repair the relationship afterwards.

A launch-versus-guardrail negotiation. Interviewers score whether you price the risk in the stakeholder's currency, offer a path that still serves the business goal, and leave the final call with a named owner.

Culture change with receipts. Interviewers score whether you built mechanisms, credited messengers, shipped postmortem actions, measured report latency, rather than reciting the blameless poster.

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.

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.

The junior-filter question that still separates candidates who understand the model from those who memorised a definition. 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.