A city wants code to run when a citizen uploads a permit PDF, without managing a server operating system. Which cloud computing model fits that need?
Select an answer to reveal the explanation.
Short Explanation
Serverless is like a streetlight that only draws power when something trips the sensor. The city writes the “what to do when a PDF lands” logic; the platform handles the machinery underneath so nobody is babysitting a server OS for every upload.
Full Explanation
Serverless computing fits when the city wants code to run in response to events—such as a citizen uploading a permit PDF—without managing a server operating system. The cloud platform executes the function on demand, scales with arrivals, and the customer focuses on the application logic rather than patching and babysitting VMs for each upload.
Traditional CapEx hosting where the city owns and patches every physical server maximizes OS management burden, the opposite of the need. A dedicated always-on VM that staff must patch even when no PDFs arrive keeps idle compute and OS responsibility. Colocation in a city-owned rack still requires the city to manage the OS for every upload path—again failing the without-managing-a-server-OS requirement.
Exam caveat: serverless reduces infrastructure management; it does not remove responsibility for secure code, identity, data protection, or understanding execution limits at a describe level—shared responsibility still applies to what the city writes and stores.
Operational check: prototype the permit-upload path as an event-triggered function in a nonprod subscription, confirm no city-managed guest OS appears in the resource list for that path, and verify Cost Management shows charges tied to executions or use rather than a 24/7 VM meter.