A Node.js inspection service must persist a nested checklist object to DynamoDB without turning numbers into unexpected strings or dropping nested maps. What should the team use?
Select an answer to reveal the explanation.
Short Explanation
Hand DynamoDB a real nested object the way your app thinks about it. The document client (or proper marshalling) keeps numbers as numbers and maps as maps—no surprise string conversions.
Full Explanation
Nested checklist objects from a Node.js inspection service include maps, lists, and numeric scores that must round-trip into DynamoDB AttributeValue types without silent coercion. The AWS SDK document client (or equivalent marshalling helpers) converts native JSON structures into the correct DynamoDB types—maps stay maps, lists stay lists, and numbers remain numbers—so persistence matches what inspectors entered in the field.
Storing the checklist only as a CSV string collapses structure, forces brittle parsing, and commonly stringifies numbers so downstream math and validation break. Writing each nested field as a MySQL column through the RDS Data API abandons the DynamoDB model the question assumes and couples the service to a relational schema for what is document-shaped data. Base64-encoding the object as an opaque Binary blob preserves bytes but discards typed attributes, queryability of nested fields, and clear schema evolution.
Exam caveat: without the document client, low-level AttributeValue maps are easy to mis-build (N vs S confusion); the exam often tests recognizing marshalling as the fix, not “store everything as a string.” Operational check: PutItem a checklist with nested maps and numeric fields, GetItem it back through the document client, and assert deep equality including number types—not stringified digits—before promoting the service.