A project manager says signing the Lambda deployment package with code signing means citizen SSN fields are encrypted at rest in DynamoDB. What distinction should the developer draw?
Select an answer to reveal the explanation.
Short Explanation
Signing the deployment ZIP proves who built it—integrity and authenticity. Encrypting SSN fields or table storage keeps secrets secret—confidentiality. The PM mixed the wax seal with the locked vault; the city still needs both stories where policy requires them.
Full Explanation
Code signing for Lambda deployment packages proves integrity and authenticity of the artifact that runs—helping ensure only approved bundles execute. Encryption at rest for DynamoDB protects confidentiality of stored citizen attributes such as SSN fields. A project manager equating package signing with field or table encryption conflates two different controls: one guards what code you run; the other guards how stored data is protected. Both may be required; neither replaces the other.
Code signing and field encryption are not identical and one does not satisfy both integrity and confidentiality goals. Signing does not automatically encrypt DynamoDB items or make SSE-KMS redundant. Claiming neither signing nor encryption applies to municipal AWS workloads is false.
Exam caveat: enable DynamoDB SSE (often with CMKs for sensitive tables) for data confidentiality, and use code signing/config rules for deploy integrity—map each requirement in compliance matrices separately. Operational check: show a signed Lambda successful deploy and an unsigned reject in a signing profile sandbox; separately show the DynamoDB table’s SSE settings protecting SSN attributes; document both controls for the project manager without merging them into one checkbox.