After a major storm, a city’s resident AI assistant spikes in usage and FinOps sees token spend and throttling. What should the AI platform team manage first?
Select an answer to reveal the explanation.
Short Explanation
A storm surge of resident questions is like rush hour on a toll bridge—you need lanes, limits, and a budget. Watch quotas and rate limits, scale capacity where it matters, and keep FinOps visibility on token spend. That keeps the assistant available without blowing the municipal AI budget or starving other apps.
Full Explanation
After a storm-driven surge in the resident AI assistant, the platform team must first manage quotas, scaling, rate limits, and cost controls for the civic model workload so emergency demand is served within FinOps and reliability boundaries. The approach works because Foundry and related model endpoints throttle and bill on usage; explicit quota headroom, autoscaling or capacity reservations where available, per-client rate limits, and budget alerts keep the municipal assistant responsive without unbounded token spend or cascading 429 failures across departments sharing the same capacity pool. In an emergency, governance of capacity and cost is the control plane that protects both resident experience and the city’s cloud budget.
Focusing first on quotas, scaling, and checkpointing controls for the model training job queue fails because that governs background long-running training, not live resident inference; training scale and checkpoints do not create quota headroom, per-client rate limits, or budget protection for the civic assistant surging with storm demand. Prioritizing rate limits, caching, and cost budgets for internal analytics sandbox use fails because sandbox controls isolate internal experimentation; tightening a non-emergency sandbox does not relieve throttling or token spend on the shared capacity serving residents during the emergency. Relying first on usage metering, scaling, and chargeback tags for nightly batch embedding jobs fails because batch metering and chargeback are after-the-fact accounting for overnight jobs; they do not enforce live quotas, rate limits, or autoscaling for the resident assistant, so they cannot prevent 429s or unbounded surge spend during the storm.
Exam caveat: quotas, scaling, and checkpointing controls for the model training job queue can improve training efficiency and recovery for long jobs, but they are not the first control to manage; without quotas, rate limits, and budget alerts on the civic inference workload, the surge can still overwhelm capacity, and overly tight limits can silence the assistant during the storm.
Operational check: set emergency runbook thresholds for TPM/RPM, enable cost anomaly alerts, document which apps share the quota, pre-approve temporary scale-up, and verify throttling returns structured backoff rather than silent failures for 311 and emergency communications teams.
Prefer to study offline? Printable PDF study book + test engine ($7.50, unofficial). These questions stay free here.