Exams / SCS-C03 / Study guide / Encryption at rest (KMS, CloudHSM, server-side and client-side encryption)
Encryption at rest (KMS, CloudHSM, server-side and client-side encryption): SCS-C03 study notes and practice questions
What to know about Encryption at rest (KMS, CloudHSM, server-side and client-side encryption) for the SCS-C03 exam, from the Data Protection domain (18% of the exam guide), then 1 free question to test it. Part of the SCS-C03 study guide.
These questions ask which encryption option, which key owner and which hardware meets a control. Start from the service’s default. Move to a customer managed key only when the scenario asks for control, audit or separation of duties.
Options by service
Amazon S3 encrypts every new object by default with SSE-S3, using keys that S3 owns and manages. Choose SSE-KMS when the scenario needs key policies, key-use audit in CloudTrail or revocation by disabling a key. DSSE-KMS applies two layers of encryption for rules that require dual-layer encryption. With SSE-C, you supply the key on each request and AWS does not store it.
Client-side encryption means the application encrypts data before upload. Use it when data must be encrypted before it reaches AWS.
Amazon EBS encrypts volumes and their snapshots. Turn on encryption by default for a Region so new volumes are encrypted without a per-volume setting. Snapshots of encrypted volumes stay encrypted.
AWS KMS keys are protected by FIPS-validated hardware. Customer managed keys give you a key policy, grants, rotation and the ability to disable the key. AWS managed keys, such as aws/s3, appear in your account but you cannot change their policy.
AWS CloudHSM gives single-tenant hardware in a cluster you manage. Use it when the scenario requires dedicated hardware you control, a specific hardware-based requirement or your own cryptographic application.
How to choose
Scenario wording
Pick
Encrypt S3 data with no extra configuration
SSE-S3, the default
Audit key use and revoke access by disabling the key
SSE-KMS with a customer managed key
A policy requires two layers of encryption
DSSE-KMS
The key must never be stored or managed by AWS
SSE-C or client-side encryption
Single-tenant, dedicated hardware the customer runs
CloudHSM
Every new EBS volume in a Region must be encrypted
EBS encryption by default
Common traps
A missing key policy. A KMS key policy must allow the account or role. IAM permissions alone do not grant access to a customer managed key.
CloudHSM as the default answer. It adds cost and operational work. KMS is usually enough unless the scenario asks for dedicated hardware.
SSE-S3 for audit. SSE-S3 keys are not visible in your account, so they do not produce key-use logs. Use SSE-KMS for that.
SSE-C without key management. The customer must send the key with every request. A lost key means lost data.
Assuming existing objects are re-encrypted. The S3 default applies to new objects. Re-encrypting existing objects needs a copy or a batch job.
A clinical research company stores trial datasets in Amazon S3. A regulator now requires two independent layers of server-side encryption for the trial-results bucket, using keys that the company controls. The company also needs a CloudTrail record of each decryption of the data in its other buckets, showing which principal used which key.
The other buckets hold lower-risk data. The team wants them to need no application changes and no key handling in code. Keys must rotate automatically each year.
Which TWO changes meet these requirements? (Choose two.)
Choose two answers.
AA. Set the other buckets to SSE-C, and have each application send the encryption key with every request. Store the keys in the application configuration files, and have a developer rotate them each year.
BB. Encrypt each object in the application with a client-side library before upload, using a data key from AWS KMS. Keep the encrypted objects in S3 with the default SSE-S3 setting as well.
CC. Keep SSE-S3 on all buckets, and turn on S3 server access logs to record each object read. The access logs will show who read each object and which key was used to decrypt it.
DD. Set the default encryption of the trial-results bucket to DSSE-KMS with a customer managed key, so that each object gets two layers of server-side encryption.
EE. Set the default encryption of the other buckets to SSE-KMS with S3 Bucket Keys off, using a customer managed key that has automatic rotation turned on.
Show the answer and explanation
Answers: D, E
A. Wrong: With SSE-C, applications must handle the keys and send them on every request, which the team forbids. S3 does not keep the key, and KMS does not log these uses, so the record requirement fails too.
B. Wrong: Client-side encryption requires code changes in every application and key handling in that code. The regulator wants two server-side layers, and client-side encryption does not provide them.
C. Wrong: SSE-S3 keys are managed by S3 and do not produce a record of each decryption. Server access logs record requests, not the key that decrypted each object.
E. Right: Correct. With Bucket Keys off, SSE-KMS calls KMS for each object, so every decryption is logged in CloudTrail with the principal and key. The bucket default needs no application change, and the key rotates each year automatically. Learn more: Using server-side encryption with AWS KMS keys (opens in a new tab)
Explanation
DSSE-KMS provides two server-side layers under a customer managed key, and SSE-KMS logs each key use in CloudTrail with no application change. SSE-C and client-side encryption push key handling into applications, and SSE-S3 keeps no per-decryption record. The two correct changes cover the regulated bucket and the lower-risk buckets.
Want more on Encryption at rest (KMS, CloudHSM, server-side and client-side encryption)? The 5 full-length practice sets have 6 more Encryption at rest (KMS, CloudHSM, server-side and client-side encryption) questions, 325 in all, none of them in the free exam. One payment of $14.99, no subscription. See the practice sets →
Study Encryption at rest (KMS, CloudHSM, server-side and client-side encryption)