Compared with running MySQL yourself on EC2, what operational benefit should a city expect from a managed database service such as Amazon RDS?
Select an answer to reveal the explanation.
Short Explanation
Self-managing MySQL on EC2 means you are the on-call plumber for patches and backups. RDS takes a big bite out of that undifferentiated busywork so staff can spend time on the application. It does not delete security duties, and it is still a real SQL database—not Glacier object storage.
Full Explanation
Compared with running MySQL yourself on EC2, a city should expect a managed database service such as Amazon RDS to reduce undifferentiated database administration such as routine backups and engine patching. RDS automates many operational tasks—backup orchestration, patch windows, Multi-AZ failover options, and monitoring integrations—so DBAs and cloud engineers spend more time on schema, performance, and application needs and less time on host-level choreography.
It is incorrect that the city must still patch the database OS and engine on the same self-managed schedule with no AWS assistance when using RDS. Managed databases do not eliminate the need for IAM controls or network isolation; those remain customer responsibilities. Managed databases also do not “only store objects in Glacier” and never run SQL—that confuses archival storage with relational services.
Exam caveat: Managed database benefit = less undifferentiated admin (backups, patching, etc.). Shared responsibility still covers access control, network design, encryption choices, and application optimization.
Operational check: enable automated backups with retention matching records policy, configure Multi-AZ for production finance databases, set a maintenance window outside peak citizen usage, restrict security groups to app tiers, and compare monthly patch-labor hours before and after leaving self-managed MySQL on EC2.