A library consortium runs Platform as a Service web apps and argues that nobody on staff needs to do security work anymore. Which customer responsibilities still apply on PaaS?
Select an answer to reveal the explanation.
Short Explanation
PaaS is like a managed restaurant kitchen where the landlord keeps the appliances working, but you still decide who gets keys and what recipes go on the menu. Libraries still own data, access, and app configuration. Thinking security ends at PaaS signup leaves the front door wide open.
Full Explanation
On Platform as a Service, the provider typically manages operating systems, middleware, and runtime platforms, but customers remain responsible for classifying data, enforcing access control, and securing application configuration and code. A library consortium running PaaS web apps therefore still has substantial security work even though staff no longer patch guest servers. Reducing customer duty to physical cage access and rack power alone is incorrect because those facility controls belong to the provider on PaaS, while data and access duties stay with the consortium. Claiming only hypervisor firmware updates remain for the customer reverses the model—firmware and host layers are provider-owned, and application configuration is customer-owned. Asserting that PaaS contracts forbid any customer security settings is false; identity, secrets, network rules, and app hardening remain customer levers. Exam caveat: moving from IaaS to PaaS shrinks OS work but does not create a security-free zone—exam items often test whether candidates still assign data and IAM to the customer. Operational check: for each PaaS library app, document data classification, require MFA and least-privilege roles, review environment variables and connection strings, enable platform audit logs, and schedule application dependency updates independent of provider OS patching.