A legacy report engine on EC2 writes citizen extracts to an attached data volume. Security requires that volume's data be encrypted at rest. What should the developers ensure?
Select an answer to reveal the explanation.
Short Explanation
If citizen extracts live on a disk glued to that EC2 box, that disk needs the EBS encryption checkbox — not gzip cosplay or tossing files onto ephemeral scratch space. Encrypt the data volume with EBS/KMS and sleep better.
Full Explanation
Sensitive citizen extracts written by a legacy report engine on EC2 must land on an encrypted EBS data volume (or a volume encrypted with KMS). EBS encryption protects data at rest on the attached disk, including snapshots that inherit the volume's encryption setting when configured correctly. Developers preparing the artifact and runtime for municipal reporting should attach or migrate to an encrypted volume so extracts of resident data are not stored cleartext on disk. This is the straightforward at-rest control DVA-style questions expect for EC2-attached storage.
Disabling EBS encryption and relying on gzip of CSV extracts fails because compression is not confidentiality—anyone who obtains the volume or snapshot can decompress the files. Storing the only copy on instance store ephemeral disks fails conceptually: ephemeral storage disappears on stop/terminate and is not a durable encrypted data-at-rest solution for required extracts. Publishing the volume snapshot publicly so peer cities can verify the encryption header fails because public snapshots expose the data rather than securing it.
Exam caveat: encrypting an existing unencrypted volume typically requires snapshot-and-copy-to-encrypted or recreate-from-encrypted snapshot workflows—you cannot merely flip a live volume flag in all cases. Operational check: confirm the data volume shows Encrypted=true with the intended KMS key, verify new snapshots remain encrypted, and restrict who may CreateVolume/CopySnapshot with that key.