A 311 intake webhook needs short functions to run on upload events. Which statement correctly describes serverless for this scenario without turning into developer configuration?
Select an answer to reveal the explanation.
Short Explanation
When a citizen drops a file on 311, you want a short burst of code—not a server humming all week waiting for the next tip. Serverless is that on-demand burst. Save the binding diagrams for a developer cert; here it is just the concept.
Full Explanation
A 311 intake webhook that needs short functions on upload events is a textbook event-driven case for serverless: the cloud can run code on demand when a file lands, without the city managing servers that idle between tips. At fundamentals depth, that conceptual fit is enough—you are not being asked to wire SDKs or dashboards as the exam skill.
Making custom SDK bindings and App Insights instrumentation the exam’s core skill overshoots AZ-900 into developer configuration territory. Requiring a continuously running VM for each webhook defeats the on-demand serverless idea. Claiming serverless cannot respond to upload events and only supports overnight CapEx batch jobs invents limits that contradict event-driven use.
Exam caveat: production webhooks still need identity, authorization, and abuse protections; serverless appropriateness for the compute model does not waive those application security basics.
Operational check: deploy a nonprod function triggered by a blob or HTTP upload simulating 311 intake, confirm no always-on city-managed VM is required for that path, and verify idle hours show negligible compute cost compared with a waiting VM—keeping the proof at describe-and-observe level.