IT maps three workloads: a custom GIS web app on a managed app platform, citywide email from a vendor suite, and a legacy plotter server that needs a specific OS on a VM. Which mapping is correct?
Select an answer to reveal the explanation.
Short Explanation
Mix and match is normal — GIS code on PaaS, mailbox suite as SaaS, picky plotter OS on IaaS. Azure is not a one-flavor-only cafeteria. Match each municipal workload to the service type that fits how much you build versus how much you consume.
Full Explanation
Azure workloads routinely mix service types. A custom GIS web app on a managed application platform is PaaS: the city writes GIS application code while the platform hosts it. Citywide email from a vendor suite is SaaS: finished collaboration consumed as a service. A legacy plotter server that needs a specific OS on a VM is IaaS: guest OS choice and machine-level control. Mapping GIS→PaaS, email→SaaS, and plotter→IaaS correctly applies the shared-responsibility model per workload.
Placing GIS under SaaS email licensing, email on IaaS VMs, and the plotter on PaaS with no OS choice reverses nearly every fit criterion. Requiring all three workloads to use only IaaS because mixed types are "not allowed" is false—Azure subscriptions commonly host mixed IaaS, PaaS, and SaaS consumption. Forcing everything to SaaS because PaaS cannot host custom web applications is also false; custom web apps are a primary PaaS scenario.
Exam caveat: mixed service types still need consistent identity, networking, tagging, and cost governance so the estate does not become three disconnected operational islands.
Operational check: inventory each municipal workload with columns for who writes code, who patches OS, and who updates the app; assign IaaS/PaaS/SaaS from that matrix and review it quarterly as legacy plotter or GIS components are modernized.