All jobs / DevOps / SRE / cloud
SRE interview questions
SRE questions a DevOps / SRE / cloud can be asked, from first job to senior. Open one to see the strongest answer and why it works.
A service will “just run on one big VM” in prod. What do you ask first?
The strongest answer: What happens when that VM dies, how we deploy without a 20-minute outage, and whether we have a backup — one box is a single point of failure, not a strategy
Why it works: Exactly. Death, deploy, backup. Simpler is not safer when it is a single box.
- Ask about death of the box.
- Ask about deploy downtime.
- Ask about backup / restore.
- Do not confuse simple with safe.
An incident just ended. The first sentence in the room is “whose fault.” What do you do?
The strongest answer: Redirect to mitigate-is-over, then a blameless timeline of what the system allowed — I do not write a name as the root cause
Why it works: Exactly. Systems allow errors. A name is not a root cause.
- Blameless timeline.
- What the system allowed.
- No villain as root cause.
- Do not paste git blame as the review.
SLI, SLO, SLA — one sentence each, and how do they relate?
The strongest answer: SLI: the measurement, such as the fraction of requests succeeding within 300 ms; SLO: our internal target on it over a window; SLA: the contractual promise to customers with consequences, set looser than the SLO
Why it works: Exactly — measure, target, promise. The gap between SLO and SLA is where the team fixes things before customers are owed anything.
- SLI measures; SLO targets; SLA promises.
- Pick user-facing indicators.
- SLO stricter than SLA.
- Window and target, not a slogan.
Pages at 3 a.m. What is the first job?
The strongest answer: Mitigate: stop the bleeding (rollback, flag, take a bad instance out), then investigate — I do not start a root-cause essay while users still burn
Why it works: Exactly. Mitigate, then learn. Essays and blame wait.
- Stop the bleeding.
- Then investigate.
- Do not hunt a villain first.
- Do not mute the page as step one.
Leadership wants “99.999% uptime.” What do you do?
The strongest answer: I ask which user journey and which window, then I propose an SLO we can measure and an error budget — I do not invent a five-nines we cannot operate
Why it works: Exactly. A journey, a window, a budget. This product does not invent a five-nines we cannot run.
- Name the journey.
- Pick a window you can measure.
- Use an error budget.
- Do not invent five nines.
A postmortem has 30 actions. What do you keep?
The strongest answer: The few that change the system (a gate, a probe, a permission) with owners and dates — I do not keep a novel of “be more careful”
Why it works: Exactly. System changes, owned. Careful and communicate are not actions.
- Few system actions.
- Owners and dates.
- No “be careful.”
- The meeting is not the fix.
The error budget is spent and a feature wants to ship. What do you say?
The strongest answer: We spend the remaining reliability work first, or the product owner accepts a burned budget in writing — I do not silently ship and “hope the month resets”
Why it works: Exactly. A budget is a decision tool. Silent ship and silent widen are how SLOs die.
- Spent budget = reliability first.
- Or a written accept.
- Do not silent-ship.
- Do not edit the SLO to pass.
Three channels, six theories, no owner. What do you install in the first ten minutes?
The strongest answer: A commander, a comms person, and one working channel — theories go in a doc, not in six places — I do not start a sixth theory
Why it works: Exactly. Command, comms, one room. Seniority can join; it does not have to start.
- Name a commander.
- Name comms.
- One working channel.
- Theories in a doc.
Two-year platform strategy: what are the first three pages?
The strongest answer: The paved road (CI, identity, observe, deploy), the reliability bar (SLOs, incident), and the cost/IAM boundaries — not a tool shopping list
Why it works: Exactly. Road, bar, boundaries. Tools follow. Rewrites and vendor tables are appendices.
- Describe the paved road.
- Write the reliability bar.
- Write cost and IAM boundaries.
- Put vendors in the back.
What must a senior DevOps / platform engineer show besides a tool list?
The strongest answer: A reliability call, a blast-radius call, and a time they said no to a slogan (multi-cloud, five nines, “just SSH”) — tools move
Why it works: Exactly. Judgement on radius and slogans. A clean incident record is luck or silence.
- Hear a no to a slogan.
- Hear a blast-radius story.
- Hear a reliability trade.
- Do not hire on a tool list.
Who is allowed to spend the error budget on purpose?
The strongest answer: The product owner of that SLO, in writing, with a halt if burn is faster than the plan — I do not let a silent deploy spend it
Why it works: Exactly. A named spender, a written spend, a halt. Decorative budgets are slides.
- Name the spender.
- Write the spend.
- Halt on fast burn.
- Do not decorate.
Incidents keep teaching “communicate better.” What programme replaces that sentence?
The strongest answer: A commander roster, a comms template, a severity that pages the right people, and one action that changes a gate — I do not run a vibe retrospective
Why it works: Exactly. Roster, template, page-the-right-people, a system change. Vibes and blame bonuses are how people hide.
- Roster and template.
- Page by severity.
- One system action.
- No blame pay.
You have 80 services and 4 SLOs. Is that wrong?
The strongest answer: No — SLOs belong on user journeys, not on every process; 80 process SLOs are how nobody pages on checkout
Why it works: Exactly. Journey SLOs. A forest of process SLOs is pager theatre.
- SLO the journeys.
- Services inherit, they do not each get a novel.
- Do not copy-paste three SLOs × 80.
- Do not one-number the company.
Someone asks you to “guarantee we will handle 10× Black Friday.” What do you refuse to invent?
The strongest answer: A percentile or a success rate I cannot measure — I will talk in load tests we have run, headroom we have seen, and what we will shed — not a marketed 10×
Why it works: Exactly. This product does not invent percentiles or outcome claims. Show tests, headroom, and shed.
- Talk from tests you ran.
- Name shed / degrade.
- No invented percentiles.
- No zero-error promise.
A page storms at 2 a.m. for a non-user metric. What do you owe the humans?
The strongest answer: I silence that page, fix the rule in the morning, and I do not praise “grit” for staying up on a lie — pager debt is a platform defect
Why it works: Exactly. A lying page is a defect. Grit is how you burn the roster.
- Kill lying pages.
- Fix the rule.
- Do not praise grit for noise.
- Do not multiply pages.
The platform team is 70% tickets (“please bump the limit”). What do you install?
The strongest answer: A toil budget, self-service for the top asks, and a no that is a ticket on the road — I do not hire only to answer the same Slack
Why it works: Exactly. Toil is a budget. Self-serve the repeats. Hire-against-Slack is a treadmill.
- Measure toil.
- Self-serve the top asks.
- Turn a no into a road ticket.
- Do not staff a helpdesk forever.
On-call is the same two people every week because they “know the system.” What do you change?
The strongest answer: A roster, a paved runbook, and pages a new person can survive — a hero roster is a bus factor and a quality defect
Why it works: Exactly. If only two people can take the page, the platform is unfinished. Pay is not a roster.
- Rotate a real roster.
- Write runbooks a new person can use.
- Page less, on symptoms.
- Do not staff on-call with two heroes.