Question

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

A healthcare provider operates a telemedicine application on Google Cloud serving two distinct capabilities: a real-time emergency video triage service where disruptions create direct clinical risks and financial penalties, and an asynchronous medical record export service where generation can take up to 24 hours without violating compliance obligations. Currently, engineering applies a uniform 99.99% availability target across all infrastructure components and relies on static CPU utilization thresholds for alerting. During load surges, non-critical batch record export failures trigger high-priority paging alerts, consuming error budgets and exhausting on-call personnel. Which TWO architectural and operational adjustments should the lead cloud architect recommend to align technical service levels with business and clinical impact? (Select TWO.)

  1. Decouple service metrics by establishing separate SLIs and SLOs per user journey, maintaining a 99.99% availability SLO for real-time video triage while defining a relaxed completion latency SLO for asynchronous record exports.Answer
  2. B
    Automatically adjust the target SLO monthly to match the measured 30-day SLI historical baseline across all microservices, and contractually re-bind customer SLAs to this dynamic percentage.
  3. Transition alerting strategies from static CPU utilization thresholds to multi-window, multi-burn-rate alerts based on error budget consumption for critical user journeys.Answer
  4. D
    Configure Cloud Load Balancing health checks for both services to execute deep dependency queries against backend databases to trigger immediate multi-region failover when backend CPU spikes occur.

Answer

The team should decouple service metrics by establishing separate SLIs and SLOs per user journey (maintaining strict targets for real-time triage and relaxed targets for batch exports) and transition alerting strategies from static CPU thresholds to multi-window, multi-burn-rate error budget alerts.
Establishing separate SLIs and SLOs based on user journey criticality aligns technical targets with business risk, ensuring that low-priority batch jobs do not trigger critical pages. Pairing this with multi-window, multi-burn-rate error budget alerts ensures on-call engineers are paged only when error budget depletion threatens business objectives.

Step-by-Step Solution

1
Analyze business impact across user journeys
Real-time triage carries severe clinical/financial impact during downtime, whereas asynchronous exports tolerate delayed execution up to 24 hours.
Technical service level objectives (SLOs) must reflect business risk rather than treating all infrastructure components uniformly.
2
Define decoupled SLIs and SLOs
Set a high availability SLO (e.g., 99.99%) for video triage requests and a batch completion SLO (e.g., 99.0% processed within 24 hours) for record exports.
Decoupling prevents low-criticality workload failures from consuming critical operational focus.
3
Modernize operational alerting mechanisms
Implement multi-window, multi-burn-rate alerts tracking error budget consumption on critical journeys instead of static CPU utilization thresholds.
Burn-rate alerting ensures pages occur only when customer-facing reliability is endangered, preventing alert fatigue.

Key Concept

Aligning SLOs and error budget burn rates with business impact and user journey criticality.
Rate this question