Public works wants short event-driven jobs that resize citizen photo uploads on demand without provisioning or patching servers. Which model best fits?
Select an answer to reveal the explanation.
Short Explanation
Those photo resizes are like pop-up food trucks that appear when a crowd shows up and leave when it is quiet. FaaS runs short event jobs without you standing up permanent servers. Keeping always-on VMs or bare metal for occasional uploads is renting a full restaurant for snack orders.
Full Explanation
Function as a Service runs short-lived, event-triggered code without requiring the customer to provision, scale, or patch dedicated servers. Public works jobs that resize citizen photo uploads on demand are bursty and brief, which is the classic serverless pattern: invoke on upload, process the image, exit, and pay primarily for execution time. Dedicated bare-metal hosts that stay powered continuously add capital and patching overhead for work that does not need always-on capacity. A long-lived IaaS virtual machine farm similarly forces staff to scale and patch servers for peak upload days even when most hours are idle. On-premises tape robots that process uploads overnight fail the on-demand latency expectation and introduce batch delay unsuitable for citizen-facing photo workflows. Exam caveat: FaaS is not a universal replacement for every municipal workload; long-running GIS engines or stateful databases may still need IaaS or PaaS, but event-driven image transforms are a textbook FaaS fit. Operational check: after enabling serverless resize, verify event triggers fire only on authorized buckets, function identity has least privilege to read and write objects, timeouts and memory match expected photo sizes, and dead-letter handling captures failed citizen uploads for retry.