Examkin

Question

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

An insurance enterprise processes policyholder claims on Google Cloud using two primary components: a synchronous Claim Submission API that impacts immediate customer satisfaction, and an asynchronous Document Archival worker pipeline that processes claims for long-term auditing within a 24-hour window. Executive leadership wants to align operational reliability alerting with business impact while avoiding alert fatigue. Which TWO actions should the Cloud Architect recommend to achieve this alignment?

  1. Define a tight availability SLO for the Claim Submission API measured by successful HTTP request ratio (SLI), and configure multi-window error budget burn-rate alerts for on-call engineers.Answer
  2. Set a throughput and latency SLO for the Document Archival pipeline over a 24-hour window, deferring operational intervention until sustained error budget depletion threatens the daily audit deadline.Answer
  3. C
    Apply a uniform 99.99% availability SLO target across both the Claim Submission API and the Document Archival worker pipeline to enforce strict end-to-end service consistency.
  4. D
    Configure static metric alerts on Compute Engine CPU utilization thresholds for Document Archival worker nodes to trigger immediate paging whenever CPU exceeds 80%.

Answer

The Cloud Architect should establish a high-availability SLO with multi-window burn-rate alerting for the customer-facing Claim Submission API, while defining a 24-hour window SLO for the asynchronous Document Archival pipeline that only escalates when sustained error budget depletion threatens operational deadlines.
Effective SRE and business process optimization requires aligning reliability targets with user impact. The synchronous Claim Submission API directly affects policyholders, making a real-time HTTP success SLI with multi-window burn-rate alerts essential to mitigate outage risks. Conversely, the asynchronous Document Archival service can tolerate short-term delays, making a wider 24-hour evaluation window appropriate to avoid paging engineers for transient backlogs that do not breach business compliance targets.

Step-by-Step Solution

1
Analyze service criticality and business impact for each system component
Identified Claim Submission API as synchronous/user-facing (high business impact for downtime) and Document Archival as asynchronous batch processing (tolerant of transient delays up to 24 hours).
SLOs must reflect customer experience and business consequence rather than uniform technical targets.
2
Formulate appropriate Service Level Indicators (SLIs) and Service Level Objectives (SLOs) matching component requirements
Configured real-time HTTP success ratio SLI for the submission API and a 24-hour completion latency/throughput SLI for the archival pipeline.
Differentiating metric windows prevents alert fatigue while maintaining appropriate safeguards for critical workflows.
3
Establish error budget burn-rate alerting strategies instead of static infrastructure threshold alerts
Alerts trigger when consumption of error budgets accelerates beyond safe thresholds, ignoring routine CPU utilization spikes on asynchronous workers.
Burn-rate alerts tie operational escalation directly to potential SLO breaches rather than raw resource metrics.

Key Concept

Aligning SLO targets and error budget alerting strategies with business criticality and user experience rather than enforcing uniform metrics or raw infrastructure thresholds.
Estimated Time:1m 30s
Rate this question

Topics

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