An organization is establishing a comprehensive reliability framework for its customer-facing REST API hosted on Google Cloud. The team must satisfy the following architectural and operational requirements: Technical measurement: Accurately capture request success ratios from the user perspective to quantify service performance. Operational governance: Implement an internal threshold that regulates release velocity, drives alerting, and preserves an operational buffer before customer contracts are impacted. Contractual agreement: Define formal commitments with enterprise customers specifying financial penalties, such as billing credits, if service degradation exceeds acceptable limits. Which strategy correctly differentiates and aligns the Service Level Indicators (SLIs), Service Level Objectives (SLOs), and Service Level Agreements (SLAs)?

Define the SLI as the ratio of successful HTTP responses to total requests, set an internal SLO of 99.9% availability over a 28-day window to control error budgets and deployment velocity, and establish an external SLA at 99.5% availability with financial credit tiers for breaches.: ### What the Solution Is This strategy establishes a standard **Site Reliability Engineering (SRE) reliability hierarchy** that clearly separates the **technical measurement (SLI)**, the **internal operational goal (SLO)**, and the **external legal contract (SLA)**. It places the internal operational targets higher than the external contractual commitments to establish a defensive safety margin. ### How It Meets the Requirements - **Technical measurement (SLI)**: Defines a request-based ratio metric that quantifies the number of successful HTTP requests against the total valid requests, accurately reflecting user happiness on a 0% to 100% scale. - **Operational governance (SLO)**: By setting an internal SLO of **99.9%** across a rolling **28-day window**, the team can track their **error budget** and trigger automated alerting, incident responses, or deployment freezes before any contractual obligations are threatened. - **Contractual agreement (SLA)**: By setting the contractual SLA at **99.5%**, the organization creates a **0.4% defensive safety margin** (the difference between 99.9% and 99.5%). Financial penalties and billing credits are only triggered if the system degrades past the internal SLO and breaches the contractual SLA. ### Key Advantages - **Defensive safety margin**: The gap between the internal SLO and the external SLA ensures internal engineering teams are paged and can remediate issues long before monetary liabilities occur. - **Balanced velocity**: The internal 28-day error budget provides a quantitative mechanism to pause feature deployments when reliability degrades without incurring legal or contractual breaches. - **User-centric metrics**: Using request-based success ratios correlates directly with real customer experience. ### Why This Is Optimal Setting the internal SLO stricter than the external SLA prevents operational teams from operating at the cliff edge of contractual failure, allowing proactive incident mitigation and maintaining sustainable release velocity.

Aligning Sli Slo Sla Defensive Hierarchy | Professional Cloud DevOps Engineer

Aligning Sli Slo Sla Defensive Hierarchy

Worked example. The correct answer is already marked and every option is explained below, so there is nothing to select here. To answer questions yourself, start the free trial.

An organization is establishing a comprehensive reliability framework for its customer-facing REST API hosted on Google Cloud. The team must satisfy the following architectural and operational requirements:

Technical measurement: Accurately capture request success ratios from the user perspective to quantify service performance.
Operational governance: Implement an internal threshold that regulates release velocity, drives alerting, and preserves an operational buffer before customer contracts are impacted.
Contractual agreement: Define formal commitments with enterprise customers specifying financial penalties, such as billing credits, if service degradation exceeds acceptable limits.

Which strategy correctly differentiates and aligns the Service Level Indicators (SLIs), Service Level Objectives (SLOs), and Service Level Agreements (SLAs)?

Define the SLI as the ratio of successful requests to total requests, set the internal SLO at 99.5% availability over a 28-day window, and establish an external contractual SLA at 99.9% availability with financial credit tiers.

Define the SLI as the average backend CPU utilization, set the internal SLO at 99.5% availability, and publish the SLO directly as the customer-facing SLA so internal alerts immediately trigger customer credits.

Set a 100% availability SLI target, set the internal SLO equal to the external SLA at 99.5% availability, and use breaches of the 99.5% threshold exclusively to trigger customer credit claims and emergency rollbacks.

Define the SLI as the ratio of successful HTTP responses to total requests, set an internal SLO of 99.9% availability over a 28-day window to control error budgets and deployment velocity, and establish an external SLA at 99.5% availability with financial credit tiers for breaches.

Professional Cloud DevOps Engineer

Aligning Sli Slo Sla Defensive Hierarchy

Related questions