A county 311 application stores MongoDB-compatible JSON case documents and currently runs a self-managed replica set on aging VMs. Architects must choose a new database platform that reduces undifferentiated operations unless a blocking engine feature is proven. Which recommendation is appropriate?
Select an answer to reveal the explanation.
Short Explanation
If the app already speaks Mongo-shaped JSON, don't volunteer to patch replica sets at 2 a.m. DocumentDB is the managed path unless a real engine feature truly blocks it. Self-managing on EC2 is an exception you document, not the default souvenir from the old rack.
Full Explanation
A county 311 application storing MongoDB-compatible JSON case documents on a self-managed replica set on aging VMs should prefer Amazon DocumentDB as the managed Mongo-compatible target unless a required engine feature is proven to block it, rather than defaulting to self-managed MongoDB on EC2. That reduces undifferentiated operations for citizen case data while preserving a familiar document API. Always rebuilding MongoDB on the largest memory-optimized EC2 family so operations stay identical to the datacenter fails the managed-ops goal and keeps patching and failover toil on the county. Converting every 311 document into Amazon Neptune as a graph of every case field as the only allowed store fails purpose-fit—graphs are not the default for document case files. Storing all 311 cases as Windows registry keys on a bastion host fails durability, scale, and governance absurdly. Exam caveat: prefer managed DocumentDB for Mongo-compatible apps unless a blocking feature forces self-managed. Operational check: inventory required Mongo features against DocumentDB compatibility, run a pilot migration of a 311 collection, validate queries and indexes, plan failover tests, and only then approve self-managed EC2 if a hard blocker is documented.