IT must choose SaaS, PaaS, or IaaS for a new citizen engagement app. Why does that choice matter for software security?
Select an answer to reveal the explanation.
Short Explanation
SaaS, PaaS, and IaaS are different leases on the same neighborhood—not the same house keys. Who patches what, and what risk you still own, shifts with the model. Pick the cloud flavor with eyes open on shared responsibility.
Full Explanation
Choosing SaaS, PaaS, or IaaS for a citizen engagement app changes residual risk and the shared-responsibility boundary for application security. In SaaS, the provider typically manages more of the stack while the city still owns identity configuration, data classification, admin hygiene, and how the app is used. In PaaS, the city owns application code and many config choices while the provider secures the runtime platform. In IaaS, the city owns guest OS, middleware, and app security more heavily. The lease model changes who patches what—and what risk remains local.
Treating cloud models as identical in residual risk and shared responsibility erases these boundary shifts and leads to control gaps.
Claiming only IaaS removes the need for authentication controls is wrong; every model still requires strong authN/Z for users and admins.
Asserting SaaS always places patching of custom app code solely on the provider fails when the city builds customizations, scripts, or integrated apps—those remain customer duties in many designs.
Exam caveat: shared responsibility varies by service model—memorize the directional shift, not a claim that cloud removes appsec. Operational check: document the RACI for patching, identity, logging, and key management for the chosen model before build, and verify citizen engagement data controls match the residual risk the city still owns.