IaaS vs PaaS for first cloud migration

WHAT THIS TESTS The interviewer wants to see contextual judgment: you should not pick a model in the abstract but justify it against this team's monolith, limited expertise, and migration goals across control, overhead, and speed.

A GOOD ANSWER COVERS Frame the trade-offs. IaaS, infrastructure as a service, provides virtual machines, storage, and networking; you control the OS and runtime, which makes it ideal for a lift-and-shift where the existing monolith runs largely unchanged on cloud VMs. The cost is high operational overhead: you still patch the OS, configure scaling, and manage availability. PaaS, platform as a service, manages the OS, runtime, and scaling for you, which slashes operational burden and accelerates feature work, but typically expects apps to conform to its model, so a legacy monolith often needs refactoring to fit. For a team with limited cloud expertise and an existing monolith, recommend starting with IaaS lift-and-shift. It is the fastest, lowest-risk way to get into the cloud without forcing a risky rewrite while skills are still thin, getting them off on-premises hardware quickly. Then, once the team builds confidence, incrementally modernize components toward PaaS or managed services to reduce long-term overhead.

COMMON WRONG ANSWERS Recommending PaaS immediately without acknowledging the refactoring effort a monolith needs to fit it, or ignoring that a low-expertise team will struggle with both a migration and a rewrite at once. Treating the choice as universal rather than situational. Forgetting the phased path that captures both quick value and eventual modernization.

LIKELY FOLLOW-UPS What would change your answer if the app were already containerized or microservices-based? How do managed databases and CaaS fit between IaaS and PaaS? What are the long-term cost and overhead trade-offs of staying on IaaS? How do you avoid lift-and-shift becoming permanent?

ONE CONCRETE EXAMPLE The team moves their monolith onto cloud VMs that mirror their current servers, changing little code and reaching the cloud in weeks. They accept that they still manage the OS for now. Six months later, with more cloud fluency, they migrate the database to a managed service and break off one module onto a PaaS app platform, steadily trading control for lower operational overhead.