A city prefers a provider-operated database service so staff stop patching database VMs themselves. Which cloud-native choice best reflects that preference?
Select an answer to reveal the explanation.
Short Explanation
Managed database services are the city hiring a specialist to mow the patch lawn while you focus on the data. You still own schema and access design, but the provider handles a lot of the boring upkeep. That is the cloud-native trade when undifferentiated ops should leave your ticket queue.
Full Explanation
A managed database service is a cloud-native offering in which the provider operates undifferentiated platform tasks such as patching, backups of the engine, and high-availability plumbing, while the city still owns schema design, queries, and data governance. Preferring to stop patching database VMs themselves is the classic signal to adopt managed database PaaS rather than self-managed engines. Lifting the database onto self-managed IaaS VMs preserves the same OS and DBMS patch cadence in-house and therefore fails the stated preference. Exporting nightly CSV dumps to a file share avoids running a cloud database engine but also abandons transactional database capabilities the city still needs. Pinning every database VM to a single dedicated host with hardware pass-through increases operational burden instead of removing patching work. Exam caveat: “managed” shifts platform operations to the provider but does not remove customer responsibility for data, access control, query performance, or application credentials. Operational check: select a managed engine that meets residency and encryption requirements, migrate with a tested cutover, confirm automated backups and patch windows align with court or finance change freezes, and update the shared-responsibility matrix so staff no longer expect to SSH-patch database guests.