A municipality is choosing databases for two workloads: (1) millions of meter-ID lookups with simple key access, and (2) a permitting app that needs multi-table joins and transactional integrity. Which pairing best matches access patterns?
Select an answer to reveal the explanation.
Short Explanation
Match the filing cabinet to the job: a giant keyed drawer for “look up this meter ID,” and a relational ledger when permits need joins and transactions. DynamoDB shines at scale for keys; Aurora/RDS owns the join-heavy desk work.
Full Explanation
Municipal data platforms rarely have one access pattern. Millions of meter-ID lookups are classic key-value gets: given a meter identifier, return the current attribute document with predictable latency at high request rates. Amazon DynamoDB is purpose-built for that pattern—partitioned key access, seamless scale, and no join tax for simple lookups. By contrast, a permitting application that needs multi-table joins, foreign-key style relationships, and transactional integrity belongs on a relational engine such as Amazon Aurora or Amazon RDS, where SQL, ACID transactions, and normalized schemas protect permit workflows that span parcels, applicants, fees, and inspections. Pairing DynamoDB for meter keys with Aurora/RDS for permitting joins matches each civic workload to the engine that fits its access pattern.
Amazon Redshift for both fails: Redshift is a columnar warehouse for analytics, not a low-latency OLTP key-value store or a transactional permitting OLTP system. Neptune for meter lookups plus ElastiCache for permitting joins misassigns graph and cache: Neptune targets relationship graphs, and ElastiCache is an in-memory cache, not a durable relational system of record for permit transactions. Using RDS only for meter key-value traffic while putting complex SQL joins on DynamoDB reverses the fit—DynamoDB does not excel at multi-table relational joins, and forcing SQL-shaped permitting onto a key-value API invites application complexity and integrity risk.
Exam caveat: “one AWS database for everything” is a common distractor. SAA-C03 rewards matching engines to access patterns. DynamoDB can model some relational-looking data with careful design, but the question’s explicit multi-table joins and transactional integrity point to Aurora/RDS for permitting.
Operational check: validate meter APIs stay single-digit millisecond GetItem/Query paths on DynamoDB with well-chosen keys; confirm permitting transactions commit across related tables on Aurora/RDS with proper isolation; and ensure neither workload is forced through the wrong API merely to standardize on one product.