A parks registration app must protect date-of-birth fields with application-level encryption while still using AWS KMS for key custody. Which pattern should the architect design?
Select an answer to reveal the explanation.
Short Explanation
Envelope encryption is a lockbox inside a lockbox: KMS hands you a data key, you encrypt the DOB locally, and you stash the wrapped key with the data. Plaintext env vars and public topics are how PII leaks, not how you protect it.
Full Explanation
Application-level protection of date-of-birth fields in a parks registration app should use envelope encryption with AWS KMS retaining custody of master key material. The application calls KMS to generate a data key, encrypts DOB fields locally with that data key, and stores the encrypted data key alongside the ciphertext. Only authorized app roles can unwrap the data key via KMS, limiting exposure of long-lived master keys and aligning with least-privilege key use for municipal PII.
Storing DOB values in plaintext environment variables on each EC2 instance places sensitive data in process configuration that is easy to leak via logs, AMIs, or SSRF-style reads. Publishing DOB fields to a public SNS topic for “transparent backup” broadcasts PII. Disabling KMS and relying only on VPC isolation confuses network boundaries with confidentiality controls—VPC isolation does not encrypt field values at rest inside databases or disks.
Exam caveat: envelope encryption is the standard pattern when apps need field-level crypto while still using KMS CMKs. Operational check: implement GenerateDataKey, encrypt/decrypt round-trips in non-production, restrict kms:Decrypt to the app role, enable automatic CMK rotation awareness for wrapped keys, and verify DOB columns never appear plaintext in logs or support exports.