A permitting system needs complex multi-table joins and a normalized relational schema. A vendor proposes Amazon DynamoDB as the primary store. What is the sound Cloud Practitioner response?
Select an answer to reveal the explanation.
Short Explanation
DynamoDB is fantastic when you mostly fetch by key, like grabbing a coat by its ticket number. If your app lives on multi-table joins and a classic relational schema, RDS is the better fit. Forcing joins into a key-value world is like using a coat-check for a full accounting ledger.
Full Explanation
When a permitting system needs complex multi-table joins and a normalized relational schema, but a vendor proposes Amazon DynamoDB as the primary store, the sound Cloud Practitioner response is to prefer a relational service such as Amazon RDS when the access pattern depends on schemas and SQL joins rather than key-value lookups. DynamoDB excels at scaled key-value and document access patterns; forcing complex relational joins into partition-key designs usually creates painful data modeling and application complexity for classic permitting schemas.
It is incorrect to accept DynamoDB on the claim that every SQL join maps one-to-one to partition keys. Amazon CloudTrail tables of API activity are not a transactional relational database for permits. AWS Snowmobile is a large-scale data transfer service using a physical truck; it does not provide ACID SQL joins as a database substitute.
Exam caveat: Choose the database by access pattern. Joins + normalized schema → relational. Key-value at scale → DynamoDB. Vendor pressure does not change the pattern fit.
Operational check: inventory the permitting queries that require multi-table joins, prove them on RDS/Aurora in a pilot, and only consider DynamoDB for clearly key-driven microservices (for example, status lookup by permit ID) rather than as a wholesale replacement for the relational core.