How should a municipal cloud primer correctly place Azure Functions versus Azure Virtual Machines?
Select an answer to reveal the explanation.
Short Explanation
Functions hide the servers — that is the serverless idea. VMs hand you the virtual hardware and OS as infrastructure. Mix those labels on a quiz and you miss the whole service-type story.
Full Explanation
Azure Functions are serverless compute: the platform hosts and scales the execution environment so municipal developers focus on code and triggers rather than managing servers. Azure Virtual Machines are IaaS compute: the city receives virtualized hardware and a guest operating system it is responsible for configuring and maintaining. A municipal cloud primer that places Functions as serverless and VMs as IaaS correctly teaches the service-type distinction AZ-900 emphasizes.
Calling both only SaaS productivity apps with no compute role misclassifies them—neither is “Word in the cloud,” and both are compute options. Calling Functions always IaaS virtual machines that cities must patch manually collapses serverless into IaaS and assigns the wrong operations burden. Calling virtual machines serverless only, while claiming Functions always provision dedicated hosts the customer patches, swaps the labels and invents a patching model that contradicts the Functions abstraction.
Exam caveat: Functions still run on underlying platform infrastructure Microsoft manages; “serverless” describes the customer’s abstraction and billing/execution model, not the literal absence of computers anywhere. Operational check: in training, open a Function App’s overview and a VM’s overview side by side—point out OS disk, extensions, and patch operations on the VM, versus trigger bindings and host management on Functions—so staff internalize the classification with portal evidence.