Autoscaling for the city’s library catalog API should react when average CPU trends upward over a monitoring window. What kind of scaling is that?
Select an answer to reveal the explanation.
Short Explanation
Watching average CPU climb over a window is like noticing the line at the counter getting longer—then opening another register. Triggered scaling reacts to that trend instead of waiting for a calendar or a human click. Metrics drive the decision; capacity follows.
Full Explanation
Triggered scaling based on trending metric conditions—such as rising average CPU over a monitoring window—is the autoscaling kind that reacts to live signals for the city’s library catalog API. Scheduled scaling that ignores live metrics and only uses a calendar fails the CPU-trend trigger described. Manual scaling performed only during change windows with tickets fails automated metric reaction. Cold-site DR failover unrelated to API demand is not demand-based autoscaling. Exam caveat: triggered/metric-based scaling ≠ scheduled or manual; windowed averages reduce spike flapping. Operational check: configure CPU average over an evaluation window, set min/max instance counts, and test scale-out under catalog search load. In municipal platform operations, record the chosen control and the rejected alternatives in the change record so future on-call engineers understand the failure modes avoided for citizen services. Re-check the decision after the next provider feature change or compliance update to ensure the same answer still holds for the city's estate. Confirm monitoring, access reviews, and backup coverage still align with the selected approach before closing the civic hypercare period.