Flipkart SRE / Platform Engineer interview questions

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.

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

Five commands separate people who have actually built this from people who read about it once. Here is the working sequence, plus the gotchas that break it.

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.

The answer that lands is about one epoll loop per core, not config snippets. Master versus worker duties, the arithmetic of worker_connections, and the limits people forget to raise.

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.

Transparent versus explicit hugepages is a control question, not a size question. Fork-heavy stores suffer THP copy-on-write amplification while large-resident databases gain TLB reach.

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.

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.

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.

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.

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

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.

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.

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.

Quotas are invisible until launch day. Treating them as tracked inventory with utilization alerts beats discovering them in a postmortem.

Guaranteed capacity and discounted capacity are different products. Peak season needs both, arranged in layers and verified with a game day before the traffic arrives.

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

Everyone recites that depends_on forces ordering. The stronger half of the answer is the graph you never see: implicit edges from references, why file layout orders nothing, and what explicit edges cost.

A green plan is evidence, not proof. Build the pyramid: lint in seconds, policy on every PR, real-cloud verification only where shared modules and money justify the burn.

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.

Managed platforms sell governance, not execution: locked state with RBAC, plans on every pull request, and audit logs. Price them per resource under management against the engineering hours self-hosting quietly burns.

Idempotence describes one run; convergence describes the fleet across time. Scheduled check-mode sweeps with diff reporting, alerts above a learned baseline, and a hard rule that incident hotfixes become pull requests the same day.

Promote the same code version, then generate and approve a separate saved plan against each environment's state and inputs. Pin, apply each reviewed artifact in sequence, and let the gates rise as you approach production. Environment branches quietly undo all of it.

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.

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.

Multiple schedulers are supported, rarely understood, and dangerous in a specific way. The strong answer names the deadlock that gang scheduling fixes and the capacity race it can open.

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.

Anti-affinity is binary and falls over at scale; topologySpreadConstraints give you numeric skew control across labeled domains. The subtle parts are eligibility filtering before the skew math, and the fact that Kubernetes never rebalances anything for you.

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, plus the rollback rule that shapes all DDL review.

Hard versus soft rules, topology keys, weights that lose to everything else, and the IgnoredDuringExecution half nobody remembers. Placement shapes blast radius only when paired with disruption budgets.

Heartbeats, conditions and taints are the only vocabulary the control plane understands. NPD translates journald and kernel ring messages into that vocabulary; custom plugins carry your hardware's dialect.

Self-heal did exactly what it was configured to do. The response needs an authorized emergency path, a controlled reconciliation pause when required, and evidence that automation can resume safely.

Redeploying the old tag reverses code and nothing else. What separates staff-level answers is a per-change map of what rolls back in seconds, what rolls back in days, and what only moves forward.

Deployment and release are two decisions, not one. Choose stable cohorts, test failure defaults and propagation, and retire temporary flags without breaking older application versions.

A freeze enforced by email is a suggestion. Tier services, put the window in deploy tooling, price exceptions honestly, and review service outcomes and the cost of delayed changes.

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.

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 pull model is the famous part and explains none of the operational pain. The storage engine is where Prometheus hurts in production: crash recovery, cold queries, disk death.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Most clusters fail an RBAC review on the same handful of patterns. Naming them concretely, plus the namespace-first design that prevents them, is what separates operators from tutorial readers.

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.

A WAF matches patterns in HTTP and stops there. Know exactly which classes it catches, which it cannot see, and what closes the gap, because block-dashboard confidence is how breaches happen anyway.

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.

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.

Most insider incidents are boring: a departing engineer copies a repo, a contractor keeps a token. Buy hygiene rather than surveillance, and protect the culture that makes people report their own mistakes.

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

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.

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.

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.

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.

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

Dual-writing from application code is the answer that fails quietly six months in. Change data capture, per-entity ordering, and a reindex you could run on a Tuesday are what interviewers score.

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.

Trace a retry through the broker, database and external provider. The guarantee changes at each boundary, and a recorded intent does not prove a payment or email completed.

Queue time and build time are separate problems with separate fixes, and most teams spend a quarter optimising the one that is not hurting. Size the fleet from arrival rate, then attack the build with caching and graph awareness.

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.

Data transfer appears on nobody's architecture diagram and reliably appears on the invoice. The strong answer enumerates the taxed flows, ranks the levers, and knows which tax is worth paying.

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.

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.

Token spend has no natural ceiling. Every retry, every retrieved document, every chain step multiplies, and nothing in the system tells anyone until the invoice arrives.

The discount is real and so is the option you are selling. The question is what your usage looks like in year three, and the honest answer for most teams is that they do not know.

A budget miss can coexist with lower cost per request. Separate demand, usage intensity and price effects before assigning an efficiency target.

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.

Tokens are the unit and input and output are priced differently. Get the arithmetic on the table in the first minute, because the number usually decides the design before any other consideration does.

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.

Scale to zero is correct for some workloads and an outage generator for others, and the deciding number is what the first request after idle experiences. Cold start turns an availability promise into a queue.

Per-token pricing looks expensive until you compute what an idle GPU costs at 3am. Break-even depends on workload volume and duty cycle, measured throughput, and the engineering cost on both sides.

GPU cost attribution needs allocation records as well as utilization. Separate exclusive reservations from borrowable quota, then reconcile team charges and idle capacity to the actual bill.

Investigate on-call workload with responder feedback and paging evidence, then verify that relief and alert changes preserve service coverage.

Use shared evidence and an agreed experiment to resolve a cross-team production problem, while containing impact and escalating time-sensitive risk.

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

Address repeated test and review bypasses through verified evidence, immediate risk containment and a repair that preserves the required coverage.

Evaluate a bespoke platform request by its user need, lifetime support cost and available alternatives, then record the decision and any bounded exception.

Plan an on-call transition around service readiness, responder capacity and authority, with rehearsed escalation and evidence that the operating burden is sustainable.

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

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.

Both run pods, so the answer sounds obvious until an interviewer asks what happens when you delete one. The guarantees are narrower and more specific than most candidates think.

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.

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.

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.

A Service moves connections and an Ingress reads requests. The gap between those two sentences is hostname routing, path routing and TLS, and it is also why an Ingress object alone does nothing.

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.