Citizen profiles in DynamoDB are ordinary JSON documents, but Social Security numbers must remain unreadable even to operators who can read the table in the console. Only those SSN fields should be protected this way. What should the application do?
Select an answer to reveal the explanation.
Short Explanation
Picture the DynamoDB item as a manila folder: most pages stay readable city paperwork, but the SSN slip goes in a sealed envelope before it ever hits the drawer. That is selective client-side field encryption — not flipping the whole table's lights off.
Full Explanation
When citizen profiles in DynamoDB must keep Social Security numbers unreadable even to operators who can scan the table in the console, the application should encrypt SSN attributes client-side before PutItem so those field values are ciphertext while other JSON fields remain ordinary attributes. Field-level encryption gives selective confidentiality: queries, indexes, and support workflows can still use names or case IDs that are not wrapped, while SSNs stay sealed until a privileged decrypt path runs. Municipal privacy programs often require exactly this split—protect the high-sensitivity slip without making the entire manila folder opaque.
Enabling S3 Object Lock on a backup vault fails because Object Lock addresses WORM retention for S3 objects, not selective attribute confidentiality inside live DynamoDB items. Turning off encryption at rest so client libraries can envelope-encrypt everything fails conceptually: table encryption at rest is complementary, not optional for field-level goals, and blanketing every attribute is not the same as protecting only SSNs. Replacing DynamoDB with unencrypted ElastiCache fails because it abandons the durable store and removes field-level controls rather than implementing them.
Exam caveat: client-side ciphertext attributes cannot be used in ordinary DynamoDB condition expressions the way plaintext can; design access patterns before wrapping fields. Operational check: verify console GetItem shows ciphertext for SSN attributes, confirm authorized decrypt paths still recover cleartext for lawful workflows, and ensure KMS key policies limit who may unwrap those envelopes.