A clerk asks how using vendor SaaS for a citizen portal differs from building a custom portal on virtual machines. Which contrast is accurate?
Select an answer to reveal the explanation.
Short Explanation
Think ready-to-drive car versus buying an engine and chassis. SaaS is the finished app you just use; IaaS VMs are the raw machines you still have to build the portal on. Same citizen portal goal, totally different who-builds-what story.
Full Explanation
The accurate contrast is service-type responsibility. SaaS means the city consumes a finished citizen portal application that the vendor operates. Building the same portal on virtual machines is an Infrastructure as a Service approach: the city provisions compute and networking, chooses and patches guest operating systems, and assembles the application stack. Same business outcome, different shared-responsibility boundary—consume versus build.
Claiming that SaaS and IaaS both require the city to install and patch the guest OS for every release collapses the models; SaaS customers do not administer the application host OS. Asserting that IaaS always includes a finished citizen portal with vendor-managed updates reverses the definition—IaaS stops at infrastructure primitives, not a packaged portal. Saying SaaS only provides bare virtual networks while IaaS only provides finished productivity apps swaps the categories entirely and would lead planners to the wrong procurement lane.
Exam caveat: teams sometimes run third-party software on IaaS VMs and casually call it "SaaS"; for AZ-900, SaaS specifically means the provider delivers and updates the application service, not merely that software happens to run in Azure.
Operational check: when comparing bids, list who patches the OS, who deploys application releases, and who owns the data plane backups—if those duties remain with municipal IT, the design is IaaS (or PaaS), not SaaS, regardless of marketing language on the portal proposal.