A 311 platform swaps in a new triage model and latency SLOs start failing. What should the MLOps team do first to protect residents?
Select an answer to reveal the explanation.
Short Explanation
When a model swap blows the latency budget, you'll hit undo — scaling out replicas won't recover the latency SLO quickly since it won't speed up individual predictions, so residents shouldn't wait on a model that already misses the latency budget. Raising timeouts won't keep requests succeeding within SLO, and collecting traces to isolate the source can wait until service is restored. Roll back to the last good deployment, then dig into why the new one crawled.
Full Explanation
Rolling back to the previous deployment that met the latency SLO is the correct first action because a live 311 triage endpoint that breaches latency objectives is already harming resident experience. Progressive municipal rollout assumes you can undo a bad cutover: restore the last known-good model and traffic path, stabilize the queue and wait times, then investigate why the new triage model regressed separately from keeping a failing revision online. Protecting residents means prioritizing service restoration over defending a fresh deployment that fails its contractual or operational latency floor.
Scaling out inference replicas to recover the latency SLO quickly fails because adding replicas raises throughput, not per-request speed; residents still wait on slow predictions and the latency SLO keeps getting missed. Raising endpoint timeout limits to keep resident requests succeeding fails because it masks the breach instead of fixing it—residents still experience slow or failed responses, and the latency SLO is violated no matter what timeout you set. Collecting production traces to isolate the latency regression source fails as a first step because it delays restoration while residents keep hitting a failing endpoint; isolating the source is useful only after the last good deployment is back online.
Exam caveat: when stems pair a model swap with failing latency SLOs and ask what to do first for residents, choose rollback to the last good deployment—not scaling replicas to recover the latency SLO quickly, raising timeouts to keep resident requests succeeding, or collecting traces to isolate the source instead of restoring service. Investigation follows restoration.
Operational check: confirm the prior deployment is still registered and rollable, execute the rollback, verify latency SLO and error rate recover on the 311 endpoint, then open a separate incident for why the new triage revision was slow before any re-promotion.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.