A library chat-bot only needs to run during open-hours traffic spikes. Why is serverless a good fit at fundamentals depth?
Select an answer to reveal the explanation.
Short Explanation
The chat-bot is like a reference desk that only needs staff when patrons show up. Serverless spins up for those bursts and does not leave a whole server humming overnight when the doors are locked.
Full Explanation
A library chat-bot that mainly runs during open-hours traffic spikes is an intermittent workload. Serverless is a good fit because idle overnight and closed-day time should not require paying for a full customer-managed always-on server OS; the platform can run functions on demand when patrons actually chat, then scale toward zero when quiet.
Requiring payment for a full always-on VM OS even when the library is closed contradicts the on-demand value proposition. Restricting serverless to 24/7 water-billing systems and excluding chat-bots invents a false limitation—bursty interactive apps are a common serverless scenario. Forcing the library to buy CapEx hardware for serverless reverses the model entirely.
Exam caveat: good fit still depends on workload shape—very long-running, stateful, or tightly OS-customized processes may still need containers or VMs; AZ-900 asks you to recognize serverless for event-driven or intermittent compute, not to claim it replaces every hosting option.
Operational check: measure chat-bot invocation counts by hour for a week; if traffic clusters in open hours with long idle gaps, keep serverless and set a budget alert on function execution cost so a viral spike cannot surprise the library’s OpEx line unnoticed.