A municipal finance system needs a relational schema with SQL joins across budgets, vendors, and purchase orders. Which AWS database family fits that pattern?
Select an answer to reveal the explanation.
Short Explanation
If your data looks like spreadsheets that need to join on IDs—budgets to vendors to POs—you want a relational SQL database. On AWS that points to RDS or Aurora, not a cache, a cold object archive, or a suitcase appliance. Caches speed things up; they do not become your finance schema.
Full Explanation
A municipal finance system that needs a relational schema with SQL joins across budgets, vendors, and purchase orders should use Amazon RDS or Amazon Aurora for managed relational SQL workloads. Relational engines support normalized schemas, complex joins, transactions, and SQL tooling that finance applications typically assume. At Cloud Practitioner depth, “relational + SQL joins” maps to RDS/Aurora rather than to key-value or object storage.
Amazon ElastiCache provides in-memory caching and does not replace SQL joins as a system of record. Amazon S3 with Glacier policies is object storage with lifecycle archiving, not a primary relational engine. AWS Snowcone is an edge device and not an online multi-AZ SQL join service.
Exam caveat: Joins, normalized schema, SQL → relational (RDS/Aurora). Key-value/document at scale → DynamoDB. Cache → ElastiCache/MemoryDB. Warehouse analytics → Redshift. Pick by access pattern.
Operational check: model the finance entities relationally, choose PostgreSQL/MySQL (or Aurora) on RDS, place DB subnets privately, enable encryption and Multi-AZ, and run representative join-heavy reports before go-live so vendor payment windows are not blocked by an ill-fit datastore.