A team debates one DynamoDB table with careful keys versus many tables that mirror a relational permits schema. What modeling guidance should developers follow?
Select an answer to reveal the explanation.
Short Explanation
DynamoDB isn’t a tiny SQL clone. Design keys for how the permit app actually reads and writes—often one table plus GSIs—not one DynamoDB table per old ERD box.
Full Explanation
DynamoDB modeling should follow application access patterns, not a one-table-per-SQL-entity reflex. Municipal permitting apps often land on a single-table design with carefully chosen partition/sort keys and GSIs so related entities that are read together can be fetched efficiently in one or a few Queries. Copying every relational permits table into its own DynamoDB table recreates join pain without relational join features and scatters what the UI needs in one screen across many round trips.
Always creating one DynamoDB table per SQL entity regardless of access patterns is the anti-pattern the question targets. Disabling GSIs because “multiple tables make secondary indexes unnecessary” misunderstands how alternate Query shapes are supported in DynamoDB. Normalizing every permit attribute into sixth normal form before choosing keys imports relational dogma that fights DynamoDB’s denormalized, query-driven design style.
Exam caveat: single-table design is guidance, not dogma—split tables when ownership, throughput isolation, or lifecycle truly diverge; the exam rewards access-pattern thinking over schema mirroring. Operational check: list the top Query/Get patterns for permits, map each to base keys or GSIs in a working model, load representative data, and prove no Scan is required for those paths under production-like item counts.