Question

Difficulty: HardAligning Technical Service Level Objectives (SLAs/SLOs/SLIs) with Business Objectives

A digital banking enterprise hosts its transaction processing platform on Google Cloud. The application architecture exposes two key endpoints: an `ExecuteInstantPayment` API where request latency over 2000 ms2000\text{ ms} incurs financial compliance penalties and customer loss, and a `GenerateMonthlyStatement` API where batch report generation can be delayed by several hours without business revenue impact. The engineering team needs to establish a Site Reliability Engineering (SRE) framework that aligns technical operational metrics with actual business risk. Which TWO implementation strategies should the team execute? (Select TWO.)

  1. Establish a strict latency SLI for `ExecuteInstantPayment` measuring the proportion of successful requests completed under 2000 ms2000\text{ ms}, paired with an SLO that triggers deployment freezes when error budget burns excessively.Answer
  2. B
    Define the target percentage of 99.9%99.9\% availability as the SLI metric while using the rolling 30-day aggregated metric measurement as the SLO metric.
  3. Set a relaxed availability and latency SLO for `GenerateMonthlyStatement` relative to `ExecuteInstantPayment`, allowing the batch system to consume error budget during peak load without incurring unnecessary over-provisioning costs.Answer
  4. D
    Enforce a unified 99.99%99.99\% availability SLO across both endpoints to ensure consistent enterprise infrastructure standards across all microservices.

Answer

The correct strategies are to establish a latency SLI for instant payments tied to the 2000 ms2000\text{ ms} penalty threshold with error-budget deployment freezes, and to set a lower, more relaxed SLO for monthly statement generation to avoid over-engineering non-critical workloads.
Aligning technical service level objectives with business impact requires setting precise SLIs that capture real business degradation (such as the 2000 ms2000\text{ ms} penalty threshold for instant payments) and establishing differentiated SLOs so non-critical batch processes do not consume unnecessary operational costs or trigger false-alarm engineering overhead.

Step-by-Step Solution

1
Analyze business impact across endpoints
Identified that `ExecuteInstantPayment` has severe financial penalties beyond 2000 ms2000\text{ ms}, while `GenerateMonthlyStatement` tolerates significant latency.
SLOs and SLIs must directly reflect business risk and user experience rather than uniform arbitrary technical targets.
2
Define valid SLIs and SLOs for high-impact endpoint
Created a latency SLI measuring request duration 2000 ms\leq 2000\text{ ms} and tied SLO error budget burn rate to feature release policies.
SLIs measure actual operational compliance against defined metrics, while SLOs enforce governance when error budgets deplete.
3
Differentiate service targets for low-impact workload
Applied a looser SLO to statement generation, preserving budget and infrastructure cost.
Over-engineering availability for non-critical services increases cloud operational expenditure without adding business value.

Key Concept

Aligning Technical SLOs/SLIs with Business Objectives
Rate this question