5 exercises — practice structuring strong English answers to SRE interview questions: SLOs and error budgets, incident response, toil reduction, observability vs monitoring, and high-availability design.
How to structure SRE interview answers
SLO questions: define SLI → SLO → error budget → link to engineering prioritisation
Incident questions: contain first, diagnose second → named phases → communication cadence → blameless post-mortem
Toil questions: use the Google SRE definition (manual, repetitive, automatable, no lasting value) → give specific examples with impact
Observability questions: known unknowns (monitoring) vs unknown unknowns (observability) → three pillars: metrics, logs, traces
HA questions: address multiple layers → name patterns (bulkhead, graceful degradation, stateless) → invoke CAP theorem for distributed systems
0 / 10 completed
1 / 10
The interviewer asks: "What is an SLO, and how do you go about setting one?" Which answer best demonstrates SRE depth?
Option B is the strongest: it gives the precise definition (ratio of good events over a time window), uses the correct acronym hierarchy (SLI → SLO → error budget), provides a concrete example, explains the process for setting one, and connects SLOs to engineering prioritisation via the error budget. The SRE vocabulary hierarchy: SLI (Service Level Indicator) — the actual metric being measured (e.g., request success rate, latency p99). SLO (Service Level Objective) — the internal target for that metric (e.g., 99.9% of requests succeed). SLA (Service Level Agreement) — an external, contractual commitment, typically less strict than the SLO. If the SLO is 99.9%, the SLA might guarantee 99.5%. Error budget — 100% minus SLO. "We have 0.1% of requests we're allowed to fail. If we've burned it all, we freeze features and work on reliability." The error budget concept is what distinguishes a true SRE answer from a DevOps-monitoring answer — it directly connects reliability targets to engineering decision-making. Option C mentions the SLA distinction but doesn't explain SLIs or error budgets. Option D is a reasonable answer but misses error budgets and stakeholder negotiation.
2 / 10
The interviewer asks: "Walk me through how you would run an incident response for a P1 — your main API is returning 500s for all users." Which answer demonstrates the clearest incident management process?
Option C is the strongest: it gives the complete incident lifecycle with named phases, specific time targets (5-minute communication, 15–30 minute updates), names the tooling (PagerDuty, observability stack, status page), mentions the "contain first, diagnose second" principle, and ends with the post-mortem step. The priority order in incident response is critical: Contain (stop the bleeding) BEFORE Diagnose (find root cause). Many junior engineers make the mistake of diving into diagnosis while users are still fully affected. Key incident response vocabulary: P1/P2/P3 — severity levels (P1 = complete outage). Incident commander — person coordinating response, not necessarily fixing it. On-call rotation — who gets paged. Rollback — revert to last known good version. Circuit breaker — automatically stop requests to a failing dependency. Status page — public (or internal) communication channel. Blameless post-mortem — focuses on systemic failures, not individual blame. MTTR (Mean Time to Recovery) — key SRE metric for incident response speed. Option B is good but less structured. Option D is too vague to demonstrate real incident response ownership.
3 / 10
The interviewer asks: "What is toil, and how have you worked to reduce it?" Which answer best demonstrates SRE thinking?
Option B is the strongest because it gives the precise SRE definition of toil with all its components, distinguishes toil from overhead and from engineering work (a nuance most candidates miss), gives three concrete examples with measurable impact, and references the Google SRE guideline (50% cap). The Google SRE definition of toil has specific properties — an answer that lists all of these shows genuine familiarity with the SRE literature: Manual — requires human action. Repetitive — done repeatedly, not once. Automatable — could be done by a machine. Tactical — interrupt-driven, reactive. No lasting value — the service is the same after as before. Scales with service growth — if traffic doubles, toil doubles. The distinction between toil and overhead matters: meetings, on-calls, reading documentation are overhead — not toil. Engineering work that builds automation to eliminate future toil is the opposite of toil. In interviews, name specific automation you built: "I wrote a script that automated X, eliminating Y hours of manual work per month." Options C and D are reasonable but lack the specific definition components that demonstrate SRE book knowledge.
4 / 10
The interviewer asks: "How do you approach observability — and what's the difference between observability and monitoring?" Which answer best demonstrates depth?
Option B is the strongest: it makes the precise conceptual distinction (known unknowns vs unknown unknowns), explains all three pillars with their specific purpose, and grounds the answer in a concrete implementation (OpenTelemetry). The monitoring vs. observability distinction for SRE interviews: Monitoring — watching predefined metrics against thresholds to detect known failure modes. "Alert when error rate > 1%." Observability — the ability to understand any system state by querying its external outputs, including failure modes you didn't anticipate. The "known unknowns vs unknown unknowns" framing is the professional SRE articulation. The three pillars: Metrics — time-series aggregates (Prometheus, Datadog). High volume, low cardinality. Good for dashboards and alerts. Logs — structured event records (Loki, Splunk, CloudWatch). High volume, arbitrary context. Good for diagnosis. Traces — distributed request flows across services (Jaeger, Tempo, Honeycomb). Low volume, high context. Good for latency diagnosis and dependency mapping. OpenTelemetry — the CNCF standard for instrumenting services to emit all three signals with a single SDK — vendor-neutral. Smart candidates mention it to show they're following industry standards.
5 / 10
The interviewer asks: "How do you design a system for high availability, and what trade-offs does that involve?" Which answer best demonstrates systems thinking?
Option B is the strongest: it addresses HA systematically through multiple layers, precisely names the patterns (redundancy, graceful degradation, bulkheads, stateless services), acknowledges the cost and complexity trade-offs, invokes CAP theorem to show distributed systems depth, and ends with the most important design question ("what is the acceptable degraded state?"). Key HA vocabulary and patterns: Single point of failure (SPOF) — any component whose failure takes down the system. Redundancy — duplicate components so failure of one doesn't stop the service. Multi-AZ / Multi-region — deployment across failure domains. Graceful degradation — the system continues at reduced functionality when dependencies fail. Bulkhead pattern — isolate failures between components (circuit breaker is a bulkhead). Stateless services — services that don't hold session state locally, enabling any instance to serve any request (critical for failover). CAP theorem — in a network partition, a distributed system must choose between Consistency and Availability. HA systems choose Availability (AP systems). Options C and D are solid technical answers but miss the graceful degradation and CAP discussion that demonstrate SRE-level thinking vs. DevOps-level thinking.
6 / 10
Alex from the Platform team Slack channel: 'Hey @john, our new microservice, OrderService, is spiking in latency. Any ideas?' What's the MOST appropriate response to offer Alex?
The key here is SRE's focus on understanding *before* reacting. Simply escalating without details risks wasting valuable time. Asking for context allows you to assess the severity and potential root cause, which guides the appropriate response. A rollback should only be considered after investigation.
7 / 10
You're reviewing a pull request for a new feature that adds a complex caching layer to your application. The PR description reads: 'This will improve performance by using a distributed cache.' Which of the following is the MOST helpful comment you could add?
The initial description is too vague. A good SRE engineer wants details about *how* the caching layer was implemented – which technology, configuration choices, and potential failure modes. This proactive questioning demonstrates a focus on operational risk and maintainability.
8 / 10
During a daily standup, Sarah (a Platform Engineer) says: 'I spent the last two hours debugging intermittent errors in our data pipeline.' What's the BEST follow-up question to ask her?
Understanding *how* Sarah approached the problem is crucial. Knowing which debugging tools she utilized provides insights into her process and potential areas for improvement in tooling or processes. Simply asking about the root cause without knowing *how* she investigated misses a critical step.
9 / 10
The API response from your service shows a high error rate (80%) for requests to endpoint /users/{user_id}. The logs reveal that the database connection pool is exhausted. What should you prioritize?
While scaling servers might seem like a solution, it doesn't address the underlying problem. Circuit breakers are a common SRE pattern for isolating failing services and preventing cascading failures. Identifying and fixing the exhausted connection pool is the most effective long-term strategy.
10 / 10
You're designing a system to monitor your application's performance. A senior engineer asks: 'What are the key differences between monitoring and observability?' Which of the following best describes this distinction?
The core difference lies in proactive understanding. Monitoring primarily focuses on predefined metrics (CPU usage, response time) – alerting you when thresholds are breached. Observability goes further, providing the context to *understand* why those metrics changed, allowing for root cause analysis and improved system behavior.
What does "SRE / Platform Engineer Interview Questions — IT English Practice" cover?
Practice answering SRE and platform engineer interview questions in English: SLOs and error budgets, incident response, toil reduction, observability, and high availability. 5 exercises.
How many questions are in this interview set?
This set has 10 exercises, each with a full explanation.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account, sign-up, or paywall.
Do these exercises include model answers?
Yes. Each interview question gives you several possible responses and asks you to pick the one that communicates most clearly and completely — the explanation then breaks down exactly why that answer works, including the specific vocabulary a strong candidate would use.
What if I choose an answer that isn't the strongest one?
You'll see which option was correct and read a full explanation of why it's stronger than the alternatives, plus the key vocabulary and phrasing worth reusing in a real interview.
Can I retry the questions?
Yes — use the "Try again" button on the results screen to reset and go through the set again.
Is this the same as a real technical or behavioural interview?
No — it's focused practice for the language side of interviewing: recognising which phrasing sounds precise and confident versus vague, and knowing the vocabulary interviewers expect for this role. It won't replace mock interviews, but it builds the vocabulary you'll need in one.
Where can I find interview prep for other roles?
Browse the full Interview exercises hub for 170+ modules covering behavioural, technical, and system design rounds across dozens of IT roles, or check the "Next up" link below to continue.
Do I need an account, and is my progress saved?
No account is needed. Progress is tracked only for your current visit — reloading or leaving the page resets the counter.
Who writes these interview questions?
Every question is written by the CoderSlingo team based on real technical interview patterns for this role, then reviewed for accuracy and clarity.