SRE Reliability Principles & Service Level Objectives 2

Question 1

Why does Google's SRE model argue that having a separate SRE team, rather than embedding reliability work in development teams, is beneficial?

Accepted Answer

A dedicated SRE team creates structural incentives to prioritize reliability — developers are motivated to ship features, while SREs are specifically accountable for stability and operational excellence

Answer

Google's SRE model creates a team whose primary incentive and success metric is reliability, counterbalancing development teams whose primary incentive is feature velocity. The structural separation aligns incentives with the organization's reliability goals.

Question 2

An SLA promises customers 99.5% monthly availability with a 10% service credit for each additional 0.5% of downtime. The service experienced 5 hours of downtime in a 30-day month. Was the SLA breached?

Accepted Answer

Yes — 99.5% of 43,200 minutes allows only 216 minutes (3.6 hours) of downtime; 5 hours (300 minutes) exceeds this

Answer

30 days × 24 hours × 60 minutes = 43,200 minutes. 0.5% × 43,200 = 216 minutes (3.6 hours) allowed. 5 hours = 300 minutes, which exceeds 216 minutes, so the SLA is breached.

Question 3

What is the key difference between an SLO and an SLA?

Accepted Answer

SLOs are internal targets that guide engineering decisions; SLAs are external contractual commitments with financial or legal consequences for breach

Answer

SLOs are internal targets that teams use to drive reliability work and gate releases. SLAs are contracts with customers — if the SLA is breached, there are consequences (credits, contract termination). SLOs are typically set stricter than SLAs to provide a buffer.

Question 4

A reliability review finds that a service achieves 99.97% availability — well above its 99.9% SLO. The SRE team proposes loosening the SLO to 99.95%. What is the BEST argument in favor of this change?

Accepted Answer

The gap between actual reliability and the SLO target suggests the service is over-engineered for its current needs; loosening the SLO frees error budget for feature velocity without meaningfully impacting users

Answer

If a service consistently and significantly exceeds its SLO, it may be over-engineered relative to user needs, consuming engineering resources that could be used for features. Adjusting the SLO to reflect the actual user-acceptable threshold releases that budget.

Question 5

Which of the following best describes 'toil' in the SRE context?

Accepted Answer

Manual, repetitive, automatable operational work that scales linearly with service load and does not produce lasting improvement

Answer

Toil is the specific category of work that is manual, repetitive, tactical (no enduring improvement), reactive, and scales proportionally with service growth — the opposite of engineering work that reduces future burden.

(SRE) Site Reliability Engineering Foundation Certification Practice Test

(SRE) Site Reliability Engineering Foundation Certification Practice Test

SRE Reliability Principles & Service Level Objectives 2