Public works must lift-and-shift a legacy permit binary that requires a specific operating system image. Which cloud service type best fits that use case?
Select an answer to reveal the explanation.
Short Explanation
That crusty permit program is picky about its OS — IaaS is the workshop where you still get to pick the machine and the operating system. SaaS and many PaaS offerings will not hand you a custom guest OS for a lift-and-shift binary. Move the box, keep the OS, that is the IaaS play.
Full Explanation
A legacy permit binary that depends on a specific operating system image is a classic Infrastructure as a Service lift-and-shift case. IaaS provides virtual machines where the city selects the guest OS, installs the binary, and retains deep control of the machine image. That control is precisely what stubborn legacy workloads need when they cannot be rewritten for a managed application platform or replaced with a finished SaaS product overnight.
SaaS fails because finished productivity suites do not expose arbitrary custom OS images for municipal binaries; SaaS delivers applications, not guest OS shopping. Claiming PaaS alone always lets customers choose any guest OS for old binaries overstates PaaS—managed app platforms abstract or constrain the OS so builders focus on code, which often blocks binary-level OS fidelity. Serverless functions alone fail because event-driven compute does not recreate an OS-dependent desktop or server permit tool that expects a traditional machine image.
Exam caveat: IaaS enables the lift, but it also keeps patching, backup, and hardening on the city's plate; choosing IaaS for legacy software is not a free pass from ongoing VM operations.
Operational check: capture a golden image of the required OS and permit application, document patch windows that public works can tolerate, and verify that licensing for the legacy binary allows cloud hosting before migrating the first production VM.