City platform teams set an internal 30-day target that the 311 API succeed on at least 99.5% of requests. What kind of service-level concept is that?
Select an answer to reveal the explanation.
Short Explanation
An SLO is the city's own scoreboard for 311 API reliability over a window—not a vendor penalty clause. It says how good "good enough" is for the internal team.
Full Explanation
A service level objective (SLO) is an internal reliability target for a service over a measurement window—owned by the platform team, measured continuously, and used to drive error budgets—not a vendor lawsuit clause. When city platform teams set an internal 30-day target that the 311 API succeed on at least 99.5% of requests, they are defining an SLO: a quantified success ratio, a clear window, and a scoped service.
A vendor penalty clause written into a procurement contract is SLA territory—external and contractual—not the internal objective the stem describes. A one-time marketing uptime promise with no measurement window lacks continuous measurement and error-budget thinking SLOs require. A firewall rule that blocks all failed API responses tries to hide failures instead of measuring reliability and would break legitimate error handling for 311 clients and operators.
Exam caveat: SLOs need explicit service level indicators (SLIs), windows, and alerting or error-budget policy; a number without measurement is aspiration, not an SLO. Operational check: confirm the 311 API SLI (for example successful responses over valid requests), dashboard the 30-day success ratio against 99.5%, and page or freeze risky changes when the error budget is exhausted.