Encryption at rest and in transit: SOA-C03 study notes and practice questions
What to know about Encryption at rest and in transit for the SOA-C03 exam, from the Security and Compliance domain (16% of the exam guide), then 1 free question to test it. Part of the SOA-C03 study guide.
Encryption questions here are operational: share an encrypted snapshot, encrypt an existing database, fix a certificate that won’t renew.
AWS KMS
AWS managed keys (aws/ebs, aws/rds…) are created by services; you can’t change their policies, so they can’t be shared with other accounts.
Customer managed keys have your key policy; add other accounts to share encrypted resources. Grants give temporary, specific permissions (services use them).
Automatic rotation of customer managed keys can be turned on (yearly by default, or a custom period); old versions stay available to decrypt.
Keys are regional; multi-Region keys share key material across Regions.
Every use is logged in CloudTrail.
Deleting a key has a 7 to 30 day waiting period; disable it first to see what breaks.
Encrypting existing resources
Resource
How
EBS volume
Snapshot → copy the snapshot with encryption → create a volume. Turn on EBS encryption by default per Region for new volumes
RDS instance
Snapshot → copy with encryption → restore a new instance
S3 objects
Set default encryption; re-encrypt existing objects with S3 Batch Operations (copy in place)
Sharing encrypted snapshots and AMIs
Re-encrypt with a customer managed key if it uses an AWS managed key.
Allow the other account in the key policy.
Share the snapshot or AMI.
The other account copies it, ideally re-encrypting with its own key.
Certificates
ACM public certificates have no extra charge and renew automatically if they are in use and validation still works. DNS validation renews without action as long as the CNAME record stays; email validation needs someone to approve.
Certificates for CloudFront must be in us-east-1.
Imported certificates don’t renew automatically; watch the DaysToExpiry metric.
Common traps
Sharing a snapshot encrypted with the default key.
Deleting the DNS validation record and then failing renewal.
A solar installer's analytics account needs a copy of an EBS snapshot from the production account.
The snapshot is encrypted with the AWS managed key aws/ebs because default EBS encryption was turned on with default settings. When the engineer tries to share it with the analytics account, the console does not allow it.
What should a CloudOps engineer do to give the analytics account a usable copy?
Choose one answer.
AA. Edit the key policy of the aws/ebs key to allow the analytics account, and then share the snapshot with that account.
BB. Make the snapshot public for a few minutes so that the analytics account can copy it, then make it private again.
CC. Copy the snapshot with a customer managed key, allow the analytics account in its key policy, and share it.
DD. Turn off default EBS encryption in the production account and share the snapshot again, because it will then be decrypted.
C. Right: Correct. A copy can be re-encrypted with a customer managed key, whose key policy can grant another account permission to use it. The copy can then be shared, and the analytics account can copy it with its own key. Learn more: Copy an Amazon EBS snapshot (opens in a new tab)
Snapshots encrypted with an AWS managed key cannot be shared, because other accounts can never be granted use of that key. The fix is to copy the snapshot with a customer managed key, grant the other account in that key's policy, and share the copy. The receiving account usually then makes its own copy encrypted with its own key.
Want more on Encryption at rest and in transit? The 5 full-length practice sets have 9 more Encryption at rest and in transit questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →