Question 1

What is the goal of Site Reliability Engineering?

Accepted Answer

Site Reliability Engineering applies software engineering principles to operations and production systems so that services are reliable, scalable, and manageable over time.

The key idea is not just “ops with coding,” but building systems and processes that make reliability sustainable. Strong answers often mention automation, measurement, toil reduction, and service objectives.

Question 2

What is an error budget?

Accepted Answer

An error budget is the amount of unreliability a service is allowed to have while still meeting its SLO.

This concept is useful because it creates a practical balance between feature velocity and system reliability. When the error budget is being consumed too quickly, teams may need to slow down risky change and focus on stability work.

Question 3

Why are SLOs important in SRE?

Accepted Answer

SLOs provide a clear reliability target that teams can measure and use to guide engineering decisions.

Without SLOs, reliability discussions often become vague or subjective. SLOs help prioritize work, tune alerting, and determine when operational risk is acceptable versus when investment is needed.

Question 4

What is toil in SRE?

Accepted Answer

Toil is repetitive, manual, operational work that scales linearly, has little long-term value, and is often automatable.

Reducing toil matters because it frees engineers to improve systems rather than repeatedly patching symptoms. Interviews often look for candidates who understand that not all operational work is equally valuable.

Question 5

What should an incident commander do during a major incident?

Accepted Answer

An incident commander should coordinate the response, keep the team aligned, assign responsibilities clearly, and ensure communication remains structured and timely.

The commander should not try to solve every technical detail personally. Their main job is to maintain situational awareness and make the response efficient, calm, and organized.

Question 6

Why are runbooks valuable?

Accepted Answer

Runbooks provide step-by-step guidance for common operational tasks and incident scenarios.

They are valuable because they reduce confusion during stressful situations, make response more consistent, and help newer responders act effectively. A strong answer also mentions that runbooks must be maintained and tested to stay useful.

Question 7

What is MTTR, and why does it matter?

Accepted Answer

MTTR usually refers to Mean Time To Recovery or Mean Time To Resolution, depending on team terminology. It measures how quickly a service is restored after an incident.

It matters because shorter recovery time usually means less user impact. However, a good answer should also note that MTTR alone is not enough; teams should also look at incident frequency, severity, and prevention work.

Question 8

Why are blameless postmortems important?

Accepted Answer

Blameless postmortems focus on understanding system and process causes rather than assigning personal blame.

This encourages honest learning and better long-term improvements. If people fear punishment, they are more likely to hide mistakes or provide shallow explanations, which weakens reliability culture.

Question 9

How do you prioritize reliability work?

Accepted Answer

I would use SLO performance, incident history, business impact, recurring failure patterns, and operational pain points to decide what to improve first.

This matters because reliability work competes with feature work. A strong answer shows that you can prioritize based on measurable risk and service impact rather than vague intuition.

Question 10

What is a good on-call practice?

Accepted Answer

Good on-call practice includes actionable alerting, clear escalation paths, up-to-date runbooks, sustainable rotations, and enough engineering investment to keep the load reasonable.

Healthy on-call is about system quality as much as staffing. If on-call is constantly painful, that often points to deeper issues in observability, automation, or architecture.

Question 11

What is the relationship between SRE and DevOps?

Accepted Answer

DevOps is a broader cultural and operational approach focused on collaboration, automation, and faster delivery. SRE is a more specific implementation model that applies engineering discipline to reliability and operations.

They overlap heavily. Many teams use SRE practices to achieve DevOps goals, especially around automation, observability, incident response, and service ownership.

Question 12

What does a mature reliability program look like?

Accepted Answer

A mature reliability program has meaningful SLOs, high-quality observability, tested incident processes, good automation, clear ownership, low-toil operations, and a culture that learns from failure.

The important point is that maturity is visible in everyday behavior, not just in documentation. Reliable systems come from repeated operational discipline, not a single tool or framework.

Question 13

What is service ownership in SRE?

Accepted Answer

Service ownership means specific teams are accountable for the reliability, operation, and improvement of the services they build or maintain.

This is important because reliability improves when ownership is clear. Ambiguity around responsibility often leads to slower incident response and weaker long-term improvements.

Question 14

What is alert tuning?

Accepted Answer

Alert tuning is the process of improving alert thresholds, conditions, routing, and severity so alerts are more actionable and less noisy.

It matters because poor alerts create fatigue and poor response quality. Strong SRE practice treats alerts as products that need maintenance.

Question 15

Why are incident severity levels useful?

Accepted Answer

Severity levels help teams classify incidents consistently based on impact and urgency.

This makes communication, escalation, and coordination more structured. It also helps organizations review incident patterns more meaningfully over time.

Question 16

What is a runbook versus a playbook?

Accepted Answer

A runbook usually describes step-by-step operational procedures for a specific task or incident response. A playbook may be broader and include decision paths, roles, and higher-level response guidance.

Teams use these terms differently, but a strong answer shows that documented response patterns are essential for reliable operations.

Question 17

What is a near miss in reliability work?

Accepted Answer

A near miss is an event that could have caused a significant incident but did not, often because of luck, timing, or an existing safeguard.

Near misses are valuable learning opportunities. Mature teams analyze them because they reveal risk before it turns into customer-visible impact.

Question 18

What is capacity planning?

Accepted Answer

Capacity planning is the process of forecasting and preparing enough infrastructure and system capability to handle expected demand.

It is part of reliability because many outages happen when systems hit scale limits that could have been anticipated. Good answers connect capacity to traffic patterns and growth expectations.

Question 19

Why are game days useful?

Accepted Answer

Game days are controlled exercises where teams simulate failures or incidents to test systems, runbooks, and response readiness.

They are useful because they expose gaps in automation, observability, and team coordination before a real outage forces the lesson.

Question 20

What is chaos engineering at a high level?

Accepted Answer

Chaos engineering is the practice of intentionally injecting controlled failures into systems to understand behavior and improve resilience.

It should be done carefully and with guardrails, but it can reveal hidden dependencies and weak assumptions that normal testing misses.

Question 21

Why is communication important during incidents?

Accepted Answer

Clear communication helps responders stay aligned, keeps stakeholders informed, and reduces confusion while the technical work is happening.

Many incidents get worse when information is fragmented or delayed. Strong candidates understand that incident response is both technical and collaborative.

Question 22

What is a dependency risk in reliability engineering?

Accepted Answer

Dependency risk is the risk that a service fails or degrades because an external or internal dependency becomes slow, unavailable, or incorrect.

Many modern systems are only as reliable as the chain of services behind them. Good answers mention timeouts, retries, fallback behavior, and dependency observability.

Question 23

What is graceful degradation?

Accepted Answer

Graceful degradation means a system continues providing partial functionality when some components fail instead of failing completely.

This is a valuable advanced concept because resilient systems often cannot avoid all failures, but they can reduce user impact by degrading intelligently.

Question 24

Why is automation important in SRE?

Accepted Answer

Automation reduces toil, improves consistency, and helps teams respond faster and more safely to operational events.

SRE is not about manually working harder during outages. It is about engineering systems and workflows that make reliability sustainable.

Question 25

What is operational readiness?

Accepted Answer

Operational readiness means a service is prepared to run in production with the necessary monitoring, documentation, ownership, capacity planning, and support processes in place.

This matters because a technically functional service may still be operationally fragile if the surrounding readiness work is missing.

Question 26

How do you learn from repeated incidents?

Accepted Answer

I would look for recurring patterns in causes, missed signals, weak runbooks, dependency issues, and change-related failures, then prioritize fixes that address systemic risk rather than only isolated symptoms.

Repeated incidents are often a sign that teams are resolving events tactically but not improving the system deeply enough afterward.

Question 27

How do you keep on-call sustainable?

Accepted Answer

I would improve alert quality, reduce toil, automate common fixes, maintain runbooks, balance rotations fairly, and invest in system improvements that reduce incident frequency.

Sustainable on-call is a sign of reliability maturity. If on-call remains painful for long periods, the system or process usually needs deeper engineering attention.

Question 28

What is a service review in reliability work?

Accepted Answer

A service review is a structured evaluation of a service’s reliability posture, risks, dependencies, incidents, and improvement priorities.

It helps teams step back from day-to-day operations and assess whether the service is becoming more or less resilient over time.

Question 29

Why are dependency maps important during incidents?

Accepted Answer

Dependency maps help responders understand which downstream or upstream systems may be involved in an outage.

This speeds diagnosis and reduces guesswork, especially in distributed systems where impact can spread across many services.

Question 30

What is rollback versus mitigation during an incident?

Accepted Answer

Rollback attempts to return the system to a previous known-good state, while mitigation reduces impact without necessarily restoring the old version or design.

Both are useful strategies. Good incident responders choose the fastest safe path to reduce user impact.

SRE, Reliability & Incident Response

1. What is the goal of Site Reliability Engineering?

2. What is an error budget?

3. Why are SLOs important in SRE?

4. What is toil in SRE?

5. What should an incident commander do during a major incident?

6. Why are runbooks valuable?

7. What is MTTR, and why does it matter?

8. Why are blameless postmortems important?

9. How do you prioritize reliability work?

10. What is a good on-call practice?

11. What is the relationship between SRE and DevOps?

12. What does a mature reliability program look like?

13. What is service ownership in SRE?

14. What is alert tuning?

15. Why are incident severity levels useful?

16. What is a runbook versus a playbook?

17. What is a near miss in reliability work?

18. What is capacity planning?

19. Why are game days useful?

20. What is chaos engineering at a high level?

21. Why is communication important during incidents?

22. What is a dependency risk in reliability engineering?

23. What is graceful degradation?

24. Why is automation important in SRE?

25. What is operational readiness?

26. How do you learn from repeated incidents?

27. How do you keep on-call sustainable?

28. What is a service review in reliability work?

29. Why are dependency maps important during incidents?

30. What is rollback versus mitigation during an incident?