A state agency SLA for a shared municipal identity portal requires measurable monthly uptime and p99 API latency. Today the city only pages on host-down events. Which improvement best aligns monitoring to the SLA and KPIs?
Select an answer to reveal the explanation.
Short Explanation
An SLA without gauges is a promise you cannot prove. Wire uptime and p99 latency into CloudWatch so the identity portal’s scoreboard matches what the state agency actually wrote down.
Full Explanation
A state agency SLA for a shared municipal identity portal that requires measurable monthly uptime and p99 API latency cannot be managed by paging only on host-down events. Instrumenting availability and latency SLIs with CloudWatch metrics, alarms, and dashboards that map directly to the SLA objectives—and notifying before breaches—aligns monitoring to the contract and KPIs. That improvement works because SLAs are user-journey objectives, not merely instance reachability. Tracking only disk free space because SLA language never mentions availability fails by ignoring the actual contractual measures. Publishing a quarterly PDF of EC2 instance types without CloudWatch alarms fails as static inventory, not runtime assurance. Relying on annual vendor questionnaires instead of runtime metrics fails conceptually for continuous SLA management. Exam caveat: define how partial outages and regional maintenance count toward uptime; ambiguous SLI math creates disputes even with perfect dashboards. Operational check: implement availability and p99 latency SLIs for login and token APIs, set burn-rate or threshold alarms with headroom before monthly breach, review the dashboard in the monthly SLA meeting, and retire host-down-only paging as the sole signal.