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
Field-level or client-side encryption protects high-sensitivity attributes such as SSNs while leaving less sensitive JSON fields usable for queries and operators who should not see cleartext SSNs. DynamoDB encryption at rest still applies to the table; turning it off does not achieve selective protection. S3 Object Lock and migrating to unencrypted ElastiCache do not address selective attribute confidentiality in DynamoDB items.