Examkin

Question

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

A digital banking platform on Google Cloud operates a real-time Wire Transfer API and a Monthly Account Statement Generation service. During peak trading hours, minor response delays in the Wire Transfer API lead to contractual financial penalties due to missed settlement windows, yet operations receives no proactive alerts. Meanwhile, scheduled database maintenance routinely triggers critical page alerts for the background statement generator, consuming on-call resources even though statement delivery deadlines are not at risk. Which TWO actions should the Cloud Architect take to align technical Service Level Indicators (SLIs) and Service Level Objectives (SLOs) with business impact?

  1. Define the Wire Transfer API's SLI based on customer-facing latency measured at the Cloud Load Balancing ingress, and set a strict SLO backed by error budget burn-rate alerting.Answer
  2. Decouple the statement generation service's alert triggers from infrastructure-level spikes, establishing an SLO based on business throughput over a multi-hour rolling window.Answer
  3. C
    Set a unified 99.99% availability SLO across both the Wire Transfer API and the Account Statement Generation service to enforce consistent technical performance.
  4. D
    Configure static threshold alerts based on GKE node CPU utilization to serve as the primary SLI for both microservices.

Answer

The correct architecture decisions are to define customer-facing latency SLIs with burn-rate alerting for the high-impact Wire Transfer API, and to evaluate the background statement generation service against multi-hour throughput SLO windows rather than short-lived infrastructure alerts.
Aligning technical service level objectives with business impact requires treating real-time, financially sensitive services differently from background batch tasks. Establishing SLIs at the ingress load balancer for the critical API directly measures user experience, and using error budget burn-rate alerts ensures proactive intervention before SLA breach. For non-critical batch workloads, evaluating SLOs over wider completion windows prevents operational alert fatigue during routine maintenance.

Step-by-Step Solution

1
Analyze business impact for each workload
Identified that Wire Transfer API delays cause immediate financial penalties, while statement generation delays are acceptable within a multi-hour window.
Technical SLOs must directly reflect the financial and operational consequences of service degradation.
2
Select appropriate SLIs and alerting strategies for synchronous real-time flows
Selected Cloud Load Balancer latency SLIs and error budget burn-rate alerts for the Wire Transfer API.
Burn-rate alerts catch fast error consumption early to protect contractual SLAs without generating spurious pages.
3
Adjust batch workload SLOs to prevent alert fatigue
Configured a multi-hour throughput SLO window for statement generation.
Batch processing relies on eventual completion within business deadlines rather than instant sub-second uptime.

Key Concept

Aligning SLOs/SLIs with business impact requires tailoring measurement points and error budget policies to workload criticality, differentiating synchronous user transactions from asynchronous batch processing.
Rate this question

Topics

Aligning Technical Service Level Objectives (SLAs/SLOs/SLIs) with Business Objectives