Streetlight engineering wants a new internal API for sensor data and prefers managed hosting so developers write code without managing operating systems. Which cloud service type best fits?
Select an answer to reveal the explanation.
Short Explanation
PaaS is the rented kitchen — you bring the recipe (your API code), and the platform handles the stove and dishes (hosting and OS). The streetlight team still builds a custom app, just without babysitting servers. That is why managed hosting for builders points to PaaS, not SaaS or bare IaaS.
Full Explanation
Building a custom internal API while preferring managed hosting so developers avoid operating-system administration is the Platform as a Service pattern. PaaS supplies a managed runtime and hosting environment: engineers write and deploy application code while the platform handles much of the underlying OS patching and hosting plumbing. Streetlight sensor APIs are exactly the kind of custom workload PaaS targets—purpose-built logic without a full VM babysitting tax.
SaaS email only fails because a mailbox product does not implement a custom sensor API; SaaS replaces building finished commodity apps, not writing municipal telemetry interfaces. Insisting on IaaS exclusively because every custom API requires hand-patched guest OS ignores PaaS, where the platform absorbs much of that OS work. Calling a sovereign region a cloud service type for APIs confuses geography and compliance isolation with the IaaS/PaaS/SaaS service model.
Exam caveat: PaaS still requires the city to secure application code, secrets, authentication to the API, and correct configuration of platform features; "managed hosting" does not remove secure-development responsibilities.
Operational check: confirm the chosen PaaS offering supports the team's language runtime and scaling needs, wire deployment from source control with non-production slots or environments, and verify structured logging so sensor API failures are visible to operations without RDP into servers.