Real SRE interview questions with detailed answers on SLIs, SLOs, error budgets, toil, incidents, monitoring and capacity planning, by difficulty.
60questions with answers
Site Reliability Engineering (SRE) is an approach that applies software engineering to operations problems, so that a service meets a defined reliability target while the team keeps shipping. SRE teams write code to automate work, measure reliability with numbers (SLOs) and use an error budget to balance new features against stability.
DevOps is a broader culture and set of practices that break down the wall between development and operations. A common way to put it is that SRE is one concrete way to implement DevOps, with specific rules: SLOs, error budgets, a cap on toil and blameless postmortems.
The trap is saying they are enemies or the same thing. Both aim at fast, safe delivery, but SRE brings stricter, measurable reliability goals.
An SLI (service level indicator) is a measurement of how the service behaves, for example the percentage of requests that succeed. An SLO (service level objective) is the target for that measurement, for example "99.9 percent of requests succeed over 30 days". An SLA (service level agreement) is a contract with customers that says what happens, usually a refund or credit, if you miss a target.
Think of it as measure, goal, promise. The SLI is the speedometer reading, the SLO is the speed you aim for, and the SLA is the fine you pay if you go too slow.
The common mistake is mixing them up. An SLO is an internal goal that teams use to make decisions, and it is normally stricter than any SLA, so you can react before you break the contract.
An error budget is the amount of unreliability your SLO allows. It equals 100 percent minus the SLO. If the SLO is 99.9 percent availability over 30 days, the budget is 0.1 percent, which is about 43 minutes of full downtime, or the same share of failed requests.
The budget turns reliability into a shared, measurable resource. While budget remains, the team can ship features and take risks. When the budget is spent, the team slows feature releases and focuses on reliability work until it recovers.
It also solves an old argument. Developers want speed and operations wants stability, and the error budget gives both sides one number to agree on.
Choose indicators that reflect what users feel. The most common are:
A good SLI is written as a ratio of good events to total events. Avoid internal numbers such as CPU use as SLIs, because users do not feel CPU. They feel slow pages and errors.
100 percent is almost impossible, and chasing it is very expensive and slows everything down. Each extra nine of availability costs far more than the last, and users usually cannot tell the difference, because their own network, device or ISP fails more often than a 99.99 percent service.
It also leaves no room for change. Every deployment carries some risk, so a target of zero failures means you would stop releasing. Choosing a sensible target such as 99.9 percent gives the team a budget to spend on improvements.
The right answer is "pick the lowest reliability that keeps users happy, then use the remaining budget for velocity".
Toil is work that is manual, repetitive, automatable, tactical, has no lasting value, and grows as the service grows. Examples are restarting a stuck job by hand, creating accounts from tickets, or acknowledging noisy alerts that need no action.
SREs reduce toil because it eats time that should go to engineering work, it does not scale, and it is boring and error-prone. Google's SRE guidance suggests keeping toil under about 50 percent of an engineer's time.
Not all operational work is toil. On-call incident response and a hard debugging session are not toil if they teach you something and improve the system. The trap is calling every ops task toil.
The four golden signals are the minimum set of metrics to watch for any user-facing service:
They come from Google's SRE book. If you can only monitor four things, these tell you whether users are affected and how close you are to a limit.
Reducing MTTD and MTTR usually gives the best return, through better alerts, runbooks, safe rollbacks and automation. A caution: MTTR is an average, and incident durations are very uneven, so one long outage hides many short ones. Many teams also track percentiles.
Note that "R" can mean repair, recover, respond or resolve, so say which you mean in an interview.
A postmortem is a written review of an incident that records what happened, why, how it was handled and what will change. Its purpose is learning and prevention, not blame.
A good one contains a short summary and impact, a timeline, contributing factors (usually several, not one root cause), what went well, what went badly, and specific action items with owners and dates. It is written in a blameless way, meaning it asks how the system allowed the failure, not who caused it.
The common failure is a document that nobody reads and no action items that get done. Review and track the actions like any other work.
The number of nines is the availability percentage, and each one cuts allowed downtime by ten times.
| Availability | Downtime per 30 days | Downtime per year |
|---|---|---|
| 99% | about 7.2 hours | about 3.65 days |
| 99.9% | about 43 minutes | about 8.8 hours |
| 99.99% | about 4.3 minutes | about 53 minutes |
| 99.999% | about 26 seconds | about 5.3 minutes |
At four nines you have a few minutes a month, which is less than the time a human needs to be paged and log in. So high targets force automation, such as automatic failover and rollback.
Always ask "available for whom, and measured how?". A number without a definition of success is meaningless.
Monitoring checks known conditions: you decide in advance what to measure and alert on, such as error rate or disk space. Observability is the ability to understand the internal state of a system from the data it emits, so that you can investigate problems you did not predict.
In practice, observability relies on three kinds of telemetry: metrics (numbers over time), logs (events) and traces (the path of one request across services). Monitoring answers "is something wrong?", and observability helps answer "why is it wrong, and where?".
The trap is saying "observability is just a new word for monitoring". Monitoring is part of it, but observability matters most in distributed systems where failure modes are hard to predict.
A runbook is a step-by-step guide for handling a known operational task or alert, so that anyone on call can act quickly and consistently, even at 3 a.m.
A good runbook includes: what the alert means and its user impact, how to check the current state, the steps to mitigate (with exact commands), how to verify the fix, who to escalate to and when, and a last-reviewed date. It is linked directly from the alert.
Keep it short and tested. A runbook that is out of date is worse than none, so update it after every incident that used it. If a runbook is always the same steps, the next move is to automate it.
Severity levels are a shared scale, for example SEV1 to SEV4, that describes how bad an incident is. Each level defines the impact, the response expected and who gets involved.
For example, SEV1 might mean a full outage or data loss for many customers, with an immediate page, an incident commander and executive updates. SEV3 might mean a minor degradation handled during working hours. The exact definitions vary by company.
Severity levels remove debate in the moment. Everyone knows how fast to move and whom to call. Define them by user impact, not by technical cause, and allow the level to change as you learn more.
A canary release sends a new version to a small share of traffic or servers first, watches key metrics, and only then rolls it out to everyone. If the metrics look bad, you stop and roll back, and only a small group of users is affected.
The name comes from the canary in a coal mine. The small group detects danger early.
For it to work you need clear health criteria, such as error rate and latency compared with the old version, ideally checked automatically. The common mistake is a canary that is too small or too short to show a problem, or one with no automated check, so nobody notices the bad signal in time.
Because the goal during an incident is to stop user harm quickly. Finding the root cause can take hours, while a rollback, failover or traffic shift may restore service in minutes.
Common mitigations include rolling back the last deploy, turning off a feature flag, shifting traffic to a healthy region, scaling up, or restarting a stuck component. They are safe because they are quick and reversible.
Keep the evidence. Before you restart or replace something, capture logs, metrics and a heap or thread dump if possible, so the postmortem can still find the cause.
The wrong answer is "I would find the root cause first". Users stay down while you investigate.
A healthy rotation has a low number of actionable pages, clear runbooks, fair scheduling and support when things go wrong. Google's guidance suggests an engineer should not be handling more than a couple of incidents per shift, so there is time to follow up properly.
Practical ingredients:
Burnout is a reliability risk. Tired people make mistakes and leave, so treat noisy on-call as a bug to fix.
Start from what users need and what the service can achieve today, then agree on the target with the product team. Do not just copy 99.99 percent.
A practical method:
Review SLOs regularly. A target that is always met by a wide margin may be too loose or may mean you are over-investing in reliability. A target that is always missed is not guiding anything.
A request-based SLI counts good events over all events: for example, 99.9 percent of requests succeed. A window-based SLI divides time into windows, such as one-minute slices, and counts the share of windows that are "good", for example windows where the error rate was under 1 percent.
Request-based SLIs weight busy periods more, because more requests happen then, which usually matches user experience. Window-based SLIs treat each minute equally, so a quiet but broken night counts the same as a busy afternoon, which can better reflect "was the service up".
Pick the one that matches how users experience the service. Request-based is the common default for high-traffic APIs, and window-based can suit low-traffic services where a few requests would make a ratio unstable.
The closer to the user, the more accurate, but the harder to collect. Each point sees different failures.
| Where | Sees | Misses |
|---|---|---|
| Server logs and metrics | Errors inside the app | Requests that never arrived |
| Load balancer | Most traffic, and 5xx from the app | Client network problems |
| Client or synthetic probe | Real user view, DNS, CDN | Hard to scale, noisy |
A common approach is to use the load balancer as the main SLI source, because it sees requests that the app never handled, and to add synthetic checks or real-user monitoring for the user view. Measuring only at the app server is the trap: when the app crashes, it records nothing, and the SLI looks perfect.
A rolling window (for example the last 30 days) moves continuously, so old failures fall out gradually and the budget is always based on recent behaviour. A calendar window (for example each month) resets on a fixed date.
Rolling windows give a smoother, more honest signal and avoid the "budget resets on the 1st, so ship everything now" effect. Calendar windows are simpler to explain to business teams and align with reporting, contracts and SLA periods.
Many teams use a rolling 28 or 30 day window for engineering decisions and a calendar window for SLA reporting. State the choice clearly, because it changes how a bad day affects your budget.
An error budget policy is a written agreement, signed by engineering and product, that says what the team will do depending on how much budget is left. It removes the argument at the moment of crisis.
Typical rules: when the budget is spent, feature releases pause except for fixes and reliability work until the budget recovers. A single huge outage may trigger a mandatory postmortem. A policy without executive support is useless, so get product and leadership to agree before it is needed.
An average hides the slow requests that hurt users. If 99 requests take 100 ms and one takes 10 seconds, the average looks fine at about 200 ms, but one in a hundred users waited ten seconds.
Use percentiles, such as p50 (median), p95 and p99. The p99 tells you that 99 percent of requests were faster than this value. Tail latency matters even more in systems where one user request fans out to many calls, because the slowest call decides the total.
For SLOs, express latency as "99 percent of requests complete under 300 ms". Also use histograms, not pre-computed averages, because you cannot correctly average percentiles across servers.
Request success rate does not fit a batch process, so pick indicators about whether the output is on time, complete and right.
Alert on the SLI breaching, for example "freshness over 30 minutes", not on every job failure, because retries may recover. The trap is using generic availability for a pipeline: the process can be "up" while delivering stale or wrong data.
A symptom alert fires when users are affected, for example "error rate above the SLO threshold" or "checkout latency is high". A cause alert fires on an internal condition, such as "CPU above 80 percent" or "disk 85 percent full".
SRE guidance is to page on symptoms and use causes for diagnosis and tickets. Symptom alerts catch problems you did not predict, and they always mean the user is hurting. Cause alerts often fire when nothing is wrong, which creates noise and trains people to ignore pages.
Some causes are still worth alerting on, if they predict an imminent symptom, such as a disk that will fill in four hours. Make those low urgency unless time is short.
Alert fatigue happens when people get so many alerts, mostly useless, that they stop trusting them. You fix it by making every page meaningful.
Practical steps:
Review it regularly, for example after every on-call week. A good target is that almost every page leads to action.
Both are checklists for what to measure.
RED is for services (things that handle requests): Rate (requests per second), Errors (failed requests) and Duration (latency). It describes the user's experience of a service.
USE is for resources (things like CPU, memory, disks, network): Utilization (how busy), Saturation (how much extra work is queued) and Errors (error counts). It helps find bottlenecks.
In troubleshooting, start with RED to see whether users are affected and which service is slow, then use USE on the machines behind it to find the limiting resource. The four golden signals are close to RED plus saturation.
Each answers a different question, and you usually use all three together.
A typical flow: an alert on a metric, a dashboard to narrow down the service, a trace to find the slow call, then logs for that service to find the cause.
Good practice is to share a request or trace ID across all three, so you can jump from one to another. The trap is relying on logs alone, which are expensive and slow to search at scale.
A good dashboard answers a question quickly, for a specific audience. It should let an on-call engineer see in seconds whether users are affected and where to look next.
Principles:
The trap is a dashboard that shows everything because it can. If nobody can tell what is important, it will not help during an incident.
Prometheus has four core types:
rate() to get requests per second.histogram_quantile, even across many instances.rate(http_requests_total[5m])histogram_quantile(0.99, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))The common mistake is graphing a raw counter. It only climbs, so you must use rate or increase to see behaviour.
An incident usually moves through five steps, and teams that name them respond more calmly.
Throughout, someone communicates status. The key point is that mitigation comes before root cause.
Separating roles stops one person from trying to debug, coordinate and communicate at the same time, which they cannot do well.
In small incidents one person may hold several roles, but the IC role should still be clear. A rule many teams use is that the IC can hand over the role at any time, with a clear statement of the current state.
The trap is a crowd of senior people all debugging and no one coordinating. More engineers in the channel without roles makes it slower.
It should avoid naming a person as the cause, using words such as "human error" as a conclusion, and stopping at a single root cause.
"Human error" is where analysis should begin, not end. Ask why the system let a normal mistake cause an outage: why was there no validation, review, staged rollout or quick rollback?
Wording examples:
Each finding should lead to an action that changes the system. Actions that say only "be more careful" do not count, because people cannot be careful forever.
Break MTTR into stages, then speed up each: detect, acknowledge, diagnose, mitigate and verify.
The biggest lever is usually safe, quick rollback, because most incidents follow a change. Measure each stage separately. If detection takes 20 minutes and the fix takes 5, work on detection first.
Use one channel as the source of truth, post regular updates, and keep them clear and honest.
A good update states the impact, the current status, what you are doing, and when the next update will come. Example: "Some users cannot log in. We have identified a bad release and are rolling back. Next update in 20 minutes."
Practices:
Silence makes people ask questions, and those questions distract responders.
Every network call needs a timeout, so a slow dependency cannot hold your resources forever. Retries can help with brief failures, but they must be limited and spread out.
The trap is retry amplification. If three layers each retry three times, one failing call becomes 27 calls, which can turn a small problem into an outage.
A circuit breaker is a pattern that stops calling a dependency that is failing, so your service fails fast instead of waiting and piling up requests. It protects both your service and the struggling dependency, which gets room to recover.
In the closed state, calls go through. After too many failures it becomes open, and calls fail immediately or use a fallback. After a wait, it becomes half-open and lets a few test calls through. If they succeed, it closes again.
Decide the fallback in advance, such as cached data or a simpler response. A breaker with no fallback still returns errors, just faster.
Both protect a service from too much traffic, but for different reasons.
Rate limiting controls how much each client or API key may send, for example 100 requests per second per key. It is about fairness and protecting against abuse or buggy clients.
Load shedding is when an overloaded service deliberately rejects some requests, such as returning 503 for lower-priority traffic, so it can keep serving the important requests well. It is about survival under overload.
Without shedding, an overloaded service tries to serve everything, gets slower, and ends up serving nothing correctly. It is better to reject 20 percent quickly and serve 80 percent well. Prioritise by importance, for example health checks and paid users first, and return a clear error with a Retry-After header.
Graceful degradation means that when part of a system fails or is overloaded, the service keeps working in a reduced but useful way, instead of failing completely.
Examples: a shopping site hides personalised recommendations but still lets users buy; a search page shows cached results when the ranking service is down; a video app lowers quality instead of buffering; a feature flag turns off a non-essential widget.
To do this you need to decide which features are critical and which are optional, make non-critical dependencies soft (failure does not block the request), and test the fallback paths regularly. Untested fallbacks often fail when needed. It also helps with SLOs: a degraded but successful response may still count as good, if you define quality that way.
A single point of failure (SPOF) is a component whose failure takes down the whole service. Examples are one database server, one load balancer, one availability zone, or a single DNS provider.
You remove SPOFs with redundancy. N+1 means you have the capacity you need (N) plus one spare, so you survive one failure. N+2 survives two failures at the same time, which matters during maintenance or when one failure is already in progress.
Redundancy only helps if failures are independent, so spread replicas across racks, zones or regions. Also test failover, since an untested standby often does not work. Finally, check shared dependencies such as a common config service, because they can quietly become the next SPOF.
A liveness probe asks "is this process stuck?". If it fails, Kubernetes restarts the container. A readiness probe asks "can this pod serve traffic right now?". If it fails, the pod is removed from the Service endpoints, but it is not restarted.
Use readiness to stop traffic while the app starts, loads data or when a dependency is unavailable. Use liveness only for real deadlocks. A startup probe gives slow apps time to boot before the others begin.
readinessProbe: httpGet: path: /ready port: 8080 periodSeconds: 5 failureThreshold: 3The classic mistake is making the liveness probe depend on a database. When the database is down, every pod restarts in a loop, which turns a dependency problem into a full outage.
Capacity planning is making sure you have enough resources for future demand, with a safety margin, at a reasonable cost.
Steps:
Use real traffic data, not guesses. Also plan for the non-linear parts: a database or cache may fail at a lower load than CPU graphs suggest. The trap is sizing for average traffic, so a normal peak causes an outage.
Each test answers a different question:
Good practice is to use realistic traffic patterns and data, test in an environment like production, watch the golden signals and dependencies, and compare results with the SLO. Tools such as k6, Locust and Gatling are common.
The trap is a test that hits one cached URL. It says nothing about real behaviour.
All three reduce deployment risk in different ways.
| Method | How it works | Best for |
|---|---|---|
| Canary | Send a small share of traffic to the new version | Catching problems with real traffic |
| Blue-green | Run two full environments, switch traffic at once | Fast, clean rollback |
| Feature flag | Ship code off, turn on for chosen users | Separating deploy from release |
Canary needs good metrics and an automatic check. Blue-green needs double capacity and care with shared databases. Feature flags add code complexity and old flags must be removed.
They combine well: deploy with a canary, and release the feature to users with a flag. For database changes, use backward-compatible steps (expand, migrate, contract), so that rollback is always possible.
RTO (recovery time objective) is how long the business can accept the service being down. RPO (recovery point objective) is how much data loss is acceptable, measured in time. An RPO of 5 minutes means you can lose at most the last 5 minutes of data.
They drive cost and design. A low RTO and RPO need more automation and replication.
Choose by asking the business what an hour of downtime costs. The trap is promising a low RTO without testing, because a plan that has never been exercised usually fails.
Because a backup that cannot be restored is not a backup. Failures are common: corrupted files, missing permissions or keys, incomplete data, an outdated process, or a restore that takes ten times longer than expected.
Test regularly by restoring into a clean environment, checking the data and measuring how long it took. Compare the result with your RTO and RPO. Automate the test and alert if it fails.
Also check that backups are stored separately, cannot be deleted by the same account that could be compromised, and are encrypted, with the keys available during a disaster.
A strong interview line is "we measure the restore, not the backup job status". A green backup job only proves a file was written.
Chaos engineering is the practice of deliberately injecting failures, such as killing a pod, adding latency or cutting a dependency, to learn whether the system survives and to find weaknesses before real incidents do.
A safe approach:
A game day is a planned exercise where the team practises responding to a simulated failure. Do not start with random production failures. Begin with known, small experiments and build trust.
A production readiness review is a structured check, done before a service launches or when it moves to SRE support, that makes sure it is ready to run reliably.
Typical areas:
It works best as a collaboration, not a gate that says no. The result is a list of gaps with owners, and the team decides which must be fixed before launch.
Burn rate is how fast you are consuming the error budget compared with the rate that would use it exactly over the SLO window. A burn rate of 1 means you will spend exactly the whole budget by the end of the window. A burn rate of 10 means you will spend it in a tenth of the time.
Alerting on burn rate links alerts directly to the SLO. A fixed threshold such as "error rate above 1 percent" can fire for harmless blips or miss a slow leak. Burn rate tells you how urgent it is.
Google's workbook recommends multiwindow, multi-burn-rate alerts. For a 30 day SLO, a 14.4x burn over 1 hour (checked with a short 5 minute window too) pages someone, because it uses 2 percent of the budget in an hour. A 6x burn over 6 hours also pages. A 1x burn over 3 days opens a ticket. The short window makes the alert reset quickly once the problem is fixed.
Your service cannot be more available than its critical dependencies, unless you add redundancy or fallbacks. When components are in series, the availabilities multiply.
For example, a service that needs a database at 99.9 percent, a queue at 99.9 percent and its own code at 99.9 percent gives about 99.9% x 99.9% x 99.9% = 99.7 percent. You lose a little with every hard dependency.
Redundancy works the other way. Two independent replicas at 99.9 percent each fail together only 0.1% x 0.1% = 0.0001 percent of the time, giving about 99.9999 percent, if their failures really are independent.
Ways to improve: remove or soften critical dependencies, add caching and fallbacks so you can serve degraded responses, and use timeouts to stop a slow dependency dragging you down. The trap is assuming independence. Shared causes, like one region or one config push, break the math.
Treat it as a risk decision that belongs to the business, make the risk visible and follow the agreed policy. Do not simply refuse, and do not silently give in.
Steps:
The aim is a decision made with full information. If the policy is regularly overridden, it is a sign that the policy or the SLO needs revisiting.
The SLA should be looser than the internal SLO, so you have warning time before you breach a contract. If the SLA promises 99.9 percent, a typical internal SLO might be 99.95 percent. When you drop below the SLO, you act. You only owe money when you drop below the SLA.
An SLA is a business and legal document, with credits, exclusions and measurement rules. An SLO is an engineering tool for decisions. They should be derived from the same SLI but need not be equal.
Also make the SLA realistic. Promise only what the architecture and dependencies can deliver, because cloud providers' own SLAs cap what you can promise. The trap is making the SLA equal to the SLO, which leaves no safety margin.
Cardinality is the number of unique label combinations in a metric. Each unique combination creates a separate time series. High cardinality means a huge number of series.
If you add a label such as user_id or request_id to a metric, a million users create a million series. Memory, storage and query time in systems like Prometheus rise sharply, and the monitoring system can slow down or crash, often during the incident when you need it most. Cost also grows in hosted tools.
Keep labels to bounded values such as status_code, method or region. Put unbounded details, like user or request IDs, in logs and traces. If you need per-customer data, use sampling, aggregation or a tool designed for high-cardinality events.
First check carefully that there really is no impact, then decide whether the alert is wrong, early or a symptom of a hidden problem. Do not just silence it.
Steps:
The wrong answer is to mute it and move on. Every non-actionable page is a defect that should be fixed.
Black-box monitoring tests the system from the outside as a user would, for example a synthetic probe that loads the login page every minute. It finds symptoms that users would feel, including problems in DNS, CDN or networking, and it works even if the app is too broken to report.
White-box monitoring uses internal signals the system exposes, such as metrics, logs and traces. It finds causes and early warnings, for example a growing queue or rising memory.
You need both. Black-box answers "is it working for users right now?", and white-box answers "why not, and what is about to fail?". If you rely only on white-box, a crashed app that reports nothing looks healthy. If you rely only on black-box, you see failures late and without detail.
Look for the common cause instead of working through alerts one by one. A flood usually means a shared dependency or a recent change, and many alerts are just symptoms of one failure.
Approach:
Afterwards, fix the monitoring with alert grouping, dependency-aware suppression and fewer cause alerts.
A cascading failure is when one component's problem spreads and overloads others, until much of the system fails. A typical chain is: one server fails, its load moves to the others, those become overloaded and fail, and so on.
Other triggers include retry storms, slow dependencies exhausting thread pools, and a cache failure that sends all traffic to the database.
Prevention techniques:
Practice with load tests and failure injection, because these failures are hard to predict on paper.
A thundering herd is when a large number of clients or processes act at the same moment and overwhelm a resource. Common examples: many caches expire at the same time, so all requests hit the database; or a service comes back after an outage and all clients reconnect at once.
Ways to handle it:
The wrong answer is to simply add more database capacity. The spike is brief but huge, so it is cheaper to flatten it than to buy for the peak.
Autoscaling helps, but it is not a magic fix, and it can cause new failures if configured badly.
Test autoscaling with load tests, and always set sensible minimum and maximum values.
Because of queueing. When a server is almost fully busy, any random burst of requests has to wait in a queue, and the queue grows faster than it drains. Waiting time rises slowly at first and then explodes as utilization approaches 100 percent.
A simple rule of thumb from queueing theory is that average wait grows roughly like 1 / (1 - utilization). At 50 percent utilization the factor is 2, at 90 percent it is 10, and at 99 percent it is 100.
So you cannot run resources at 100 percent. Plan for a safe ceiling, often 60 to 70 percent peak for latency-sensitive services, and measure the knee of the curve in load tests. Headroom also covers failures, since losing one of three nodes pushes the rest from 60 to 90 percent.
The trap is saying "CPU is only at 80 percent, so we have room". At that level, latency may already be unacceptable.
Make changes small, frequent, gradual, observable and reversible, and use automation to enforce it. Big infrequent changes are riskier, so a slow release process often makes reliability worse.
Practices:
The wrong answer is a manual approval board for every change. It slows delivery and rarely catches real problems.
Yes. They cover topics that regularly come up in SRE and reliability engineering interviews, such as SLOs, error budgets, incident management, monitoring and capacity planning. The answers are written for preparation, so you can explain each idea in your own words.
It covers entry level to mid level, from definitions to scenario and trade-off questions. For senior material, use the Senior SRE interview pack, and for a full role-based pack, use the Junior or Mid-Level SRE pack.
Not for most questions. A few use Kubernetes or Prometheus as examples, but the ideas apply to any stack. A basic understanding of how web services run in production is enough.
They are grouped by difficulty, with easy questions on definitions, medium questions on applying the ideas, and hard questions on scenarios and trade-offs. Start with the easy ones and work up.