A library consortium wants to publish a simple custom API for catalog lookups without babysitting servers. Which choice best fits?
Select an answer to reveal the explanation.
Short Explanation
Custom API, no desire to babysit VMs? That is a PaaS pitch. Drop the code on a managed platform and skip the OS chore list that IaaS would hand you.
Full Explanation
A library consortium that wants to publish a simple custom API for catalog lookups without babysitting servers is describing a platform-as-a-service need. PaaS hosts the application runtime and operating system so developers deploy API code and focus on catalog logic, authentication, throttling, and data access rather than virtual-machine patching. That responsibility split is why PaaS best fits the consortium’s goal.
Requiring only IaaS virtual machines forever fails because IaaS keeps guest-OS patching with the customer—the opposite of avoiding server babysitting. Equating the need with SaaS Outlook Online fails because email hosting is unrelated to publishing custom catalog APIs. Insisting on perpetual on-premises servers with no cloud option fails conceptually: custom APIs routinely run on managed cloud platforms; rejecting PaaS is a preference, not a technical law.
Exam caveat: PaaS reduces OS chores but does not eliminate secure coding, secret management, identity integration, or abuse protection for a public-facing catalog API. Operational check: deploy the API to a managed app platform, remove standing SSH/RDP for this workload, enable platform logging and TLS, integrate Entra ID or API keys per design, and load-test catalog lookups before release.