A checkout team misses its 99.9% success promise because availability is tracked by server CPU and ad hoc log searches. Leaders want a measurable user-focused objective with burn-rate alerts for on-call response. Which SLO design with measurable indicators and alerts best fits CloudWatch and Application Signals?
Select an answer to reveal the explanation.
Short Explanation
You need user outcomes tied to paging math, not server health. Burn-rate alerts act like a fuel gauge warning before the tank hits empty.
Full Explanation
The correct design replaces server-centric monitoring with a user-centric service level indicator, the ratio of good checkout requests to total valid requests, recorded as a formal SLO in Application Signals so the 99.9% promise is measurable and auditable. The SLO tracks error budget, and burn-rate CloudWatch alarms detect both fast-burn outages and slow-burn degradations so on-call is paged in proportion to urgency. Static threshold alarms fail by alerting concept because fixed thresholds cannot express remaining error budget or urgency, causing noisy pages or late detection even though the SLI is sound. A latency-only SLO fails because the promise is about checkout success, so failed checkouts would consume no budget. A CPU and memory based design fails by SLI validity because host saturation does not measure user success, repeating the original anti-pattern. Exam caveat: an Application Signals SLO is built on a single SLI (availability or latency of an operation, or a CloudWatch metric), so latency would be a separate SLO if required; prioritize user-focused good-event wording and burn-rate alarms when the stem asks for on-call response. Practical check: validate the SLI against real checkout transactions, confirm Application Signals shows budget burn, and test both fast-burn and slow-burn alarm paths with rehearsed runbooks.