A council IT slide lists virtual machines, containers, and serverless. How should serverless be placed relative to always-on VMs?
Select an answer to reveal the explanation.
Short Explanation
Line the options up like layers of packaging. A VM is a whole computer you still tend. Containers trim some of that work. Serverless is the meal-kit delivery—you bring the recipe (code), and the kitchen (platform) handles the stove time, often charging per cook rather than for a stove left on all night.
Full Explanation
Relative to always-on virtual machines, serverless is a higher abstraction. The platform runs your code on demand—often billed by executions or resources consumed—without the customer managing guest operating systems the way they would for continuously running VMs. On a council IT slide that lists VMs, containers, and serverless, place serverless as less infrastructure management and more event-driven or on-demand compute, not as another flavor of patching VMs.
Treating serverless as identical to managing guest OS patching on every VM collapses the abstraction levels. Claiming serverless sits below bare metal and requires more OS administration than VMs reverses the ladder. Saying serverless replaces networking and identity and cannot be discussed as a compute model mixes domains; serverless is still a compute hosting approach alongside VMs and containers.
Exam caveat: higher abstraction does not mean zero cost or zero design work—cold starts, execution timeouts, and stateless patterns matter in real apps, but AZ-900 mainly wants the abstraction and billing-by-use contrast with always-on VMs.
Operational check: for a candidate city workload, ask whether staff must patch a guest OS 24/7; if the answer should be no and traffic is event-driven, document serverless on the architecture slide above VM-based hosting and confirm the cost model is execution-oriented in Cost Management samples.