A city adopts a vendor's multi-tenant 311 mobile app as SaaS. Which characteristic best describes that model?
Select an answer to reveal the explanation.
Short Explanation
Multi-tenant SaaS is like a shared bus route — the vendor drives the vehicle and rolls out improvements for everyone riding. The city does not patch the OS under that 311 app or push the next release from City Hall. That hands-off app update story is a classic SaaS tell.
Full Explanation
A vendor multi-tenant 311 mobile app consumed as SaaS is characterized by provider-managed application lifecycle. The vendor operates the shared application, typically ships updates across tenants, and the city does not deploy the 311 binary from its own datacenter. Multi-tenancy means many customers share the vendor's operated platform while retaining logically separated configuration and data, which matches how municipalities often adopt citizen-service apps without standing up an app farm.
Requiring the city to patch the app's underlying OS and push every feature update from City Hall describes customer-managed infrastructure, not SaaS. Running a private copy on dedicated city-owned servers with no vendor involvement is an on-premises or self-hosted model, which abandons the SaaS operations boundary. Treating SaaS as renting empty VMs and writing the entire 311 codebase from scratch confuses SaaS with IaaS plus custom development.
Exam caveat: multi-tenant SaaS can still offer per-tenant configuration, branding, and data isolation; multi-tenant does not mean every municipality sees every other city's tickets—isolation controls remain a contractual and technical requirement.
Operational check: validate tenant isolation and data residency in the vendor's documentation, confirm how emergency after-hours support is escalated, and test that municipal administrators can export 311 history before go-live so public-records obligations are met independently of the vendor console.