An existing application stores sensitive information on a non-boot Amazon EBS data volume attached to an
Amazon Elastic Compute Cloud instance. Which of the following approaches would protect the sensitive data
on an Amazon EBS volume?
A.
Upload your customer keys to AWS CloudHSM. Associate the Amazon EBS volume with AWS CloudHSM.
Re- mount the Amazon EBS volume.
B.
Create and mount a new, encrypted Amazon EBS volume. Move the data to the new volume. Delete the old
Amazon EBS volume.
C.
Unmount the EBS volume. Toggle the encryption attribute to True. Re-mount the Amazon EBS volume.
D.
Snapshot the current Amazon EBS volume. Restore the snapshot to a new, encrypted Amazon EBS
volume. Mount the Amazon EBS volume.
Explanation:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html To migrate data between
encrypted and unencrypted volumes:
1. Create your destination volume (encrypted or unencrypted, depending on your need) by following the
procedures in Creating an Amazon EBS Volume.
2. Attach the destination volume to the instance that hosts the data to migrate. For more information, see
Attaching an Amazon EBS Volume to an Instance.
procedures in Making an Amazon EBS Volume Available for Using. For Linux instances, you can create a
mount point at /mnt/destination and mount the destination volume there.
4. Copy the data from your source directory to the destination volume. It may be most convenient to use a bulkcopy utility for this.
B
Answer should be D
D
B. By snapshotting an unencrypted volume, any volume created from that is not encrypted. You’d have to copy the snapshot to an encrypted copy, and use that one to create a volume.
“non-boot Amazon EBS data volume”, answer is B
although there is no such option:
While copying an unencrypted snapshot of an unencrypted volume, you can encrypt the copy. Volumes restored from this encrypted copy are also encrypted.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html#EBSEncryption_considerations
answer is B
Answer is B, you can not encrypt a already created EBS volume, Amazon only allow EBS volume to be encrypted when you first create it.
D should be correct.
1-Snapshot the current Amazon EBS volume.
2-create a new encrypted Amazon EBS volume from Snapshot.
3-Detach the old EBS Volume(unencrypted ) and delete.
4-Attached the new Amazon EBS volume to instance.
AWS allow to encryption option while Create volume from Snapshot.
yes D should also be a practicle option.
so you mean option D also sounds right?
In the given link:
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSEncryption.html
You can read:
While copying an unencrypted snapshot of an unencrypted volume, you can encrypt the copy. Volumes restored from this encrypted copy are also encrypted.
While copying an encrypted snapshot of an encrypted volume, you can re-encrypt the copy using a different CMK. Volumes restored from the encrypted copy are only accessible using the newly applied CMK.
You cannot remove encryption from an encrypted snapshot.
So, B is the only correct answer (but not the best approach in my opinion)
D is wrong
You can copy an unencrypted snapshot to an encrypted snapshot and then restore this new encrypted snapshot to an encrypted volume. (the best approach)
But you can’t directly restore an unencrypted snapshot to an encrypted volume
I go with D.
B. OK with creating an encrypted AWS EBS volume Ref. “https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-volume.html”; Not OK with the “move data”. “Move” is for relocating data on the same volume. “B” has no protection for data modification on the existing volume while data is being move. “Move” implies copy data files. The process is labor intensive.
D. Take a snapshot of the data and “restore” the snapshot to create a new volume with encryption are AWS service functions. “Restore” loads lazily in the background. Ref. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-restoring-volume.html
I agree with Gnart, D option is more practical and safe.