Municipal DBAs insist on installing, patching, and tuning the database engine themselves on virtual machines. Which deployment option are they choosing?
Select an answer to reveal the explanation.
Short Explanation
If the DBAs want to wrench on the engine themselves — install, patch, tune — they are keeping the keys to the garage. That is self-managed: the city owns the database software lifecycle on those VMs. Managed services and SaaS would take that wrench out of their hands.
Full Explanation
A self-managed database deployment places the engine on virtual machines or hosts where municipal DBAs install, patch, tune, and operate the software themselves. When DBAs insist on owning those tasks on VMs, they are choosing self-managed operations rather than a provider-operated database service that would take engine patching away from staff. A fully managed SaaS productivity suite with no database engine access does not give DBAs patch-and-tune control of an engine. A provider-managed database service intentionally shifts engine patching to the cloud vendor, which contradicts the team’s insistence on doing that work themselves. Serverless functions that only invoke external HTTP APIs are an application compute pattern, not a DBA-operated database deployment model. Exam caveat: self-managed maximizes control and operational burden; managed services reduce undifferentiated engine ops—Cloud+ tests whether you can tell those options apart from the stem’s verbs such as install, patch, and tune. Operational check: harden and baseline the database VMs, schedule patch windows with change control, automate backups and quarterly restore tests, monitor replication lag and storage growth, restrict SSH and DBA roles, and document that guest OS and engine patching remain city responsibilities in the shared-responsibility matrix.