5.2 - Encryption at rest (KMS, CloudHSM, rotation, key policies)
AWS Certified Security Specialty objective 5.1 covers protecting stored data with keys you control. AWS KMS sits at the centre: the key policy ultimately decides who may use a customer managed key, automatic rotation replaces only the backing key material while the key ID and every existing ciphertext stay valid because older material is retained for decryption, the rotation period can be shortened from the default, and a key created with imported material behaves differently since it depends on material you re-import and it expires. Deleting a key means scheduling it with a mandatory waiting period, and an application that suddenly throws KMSInvalidStateException usually points at a key that is disabled or pending deletion, which you cancel. Envelope encryption uses GenerateDataKey to return a plaintext data key and its encrypted copy, and the plaintext copy is discarded as soon as the local encryption finishes. When the organization must own the hardware you attach a CloudHSM cluster as a KMS custom key store or root Redshift on it, dual-layer server side encryption adds a second AWS-applied layer, S3 Bucket Keys cut KMS throttling and cost, EBS encryption by default plus an SCP on ec2:Encrypted stops unencrypted volumes, and an Auto Scaling group needs kms:CreateGrant for its service-linked role. Expect key lifecycle and key access scenarios.
KMS automatic rotation = same key ID, new backing material, old material kept so existing ciphertext still decrypts. KMSInvalidStateException with pending deletion = cancel the scheduled key deletion. Company must own the hardware but keep KMS integrations = CloudHSM as a KMS custom key store.
Practice questions
1. A team must guarantee that every object written to an S3 bucket is encrypted, and that a PutObject request without encryption headers fails outright. What should they configure?
- A CloudWatch alarm that fires whenever an unencrypted object appears, so the on call engineer can delete it manually
- An AWS Config rule that flags the bucket as non compliant and reports it in the compliance dashboard once a day
- A bucket policy that denies s3:PutObject when the encryption header is absent (correct answer)
- A nightly Lambda function that scans the bucket and rewrites every unencrypted object in place
Only a Deny in the bucket policy is preventive: the write is rejected before any clear text ever lands. Config rules and CloudWatch alarms are detective, so the object exists unencrypted in the interval, and a nightly rewrite leaves the data exposed for up to a day while also changing every object's version.
2. What is the practical difference between SSE-S3 and SSE-KMS for an S3 bucket?
- SSE-KMS lets you control the key policy and logs each key use in CloudTrail (correct answer)
- SSE-S3 encrypts only object metadata while SSE-KMS also encrypts the object body itself
- SSE-S3 requires the client to encrypt the payload before it is uploaded to the bucket
- SSE-KMS stores objects unencrypted but records a cryptographic hash of each one for later verification
Both encrypt the full object server side; the real gain of SSE-KMS is a customer controlled key policy plus an audit trail of every Decrypt call. SSE-S3 is also server side and needs no client work, and neither option leaves data unencrypted or limits itself to metadata.
3. A bucket stores millions of small objects with SSE-KMS and the workload is now throttled by KMS request limits. Which change reduces KMS calls without weakening encryption?
- Switch the bucket to SSE-S3 so that objects stop being encrypted by any managed key service
- Import your own key material into the KMS key so that data keys no longer need to be generated
- Enable S3 Bucket Keys on the bucket (correct answer)
- Move the bucket to a region where the KMS request quota is documented as unlimited for all callers
An S3 Bucket Key derives a short lived bucket level key from the KMS key, so S3 calls KMS once per time window instead of once per object, cutting requests and cost while keeping SSE-KMS. Switching to SSE-S3 would lose the customer key policy, imported key material changes the origin of the key and not the number of GenerateDataKey calls, and no region offers an unlimited KMS quota.
4. An unencrypted EBS volume is attached to a running production instance and must become encrypted. What is the supported path?
- Toggle the encryption attribute on the volume from the console while the instance keeps running normally
- Snapshot the volume, copy the snapshot with encryption enabled, then create a new volume from that copy (correct answer)
- Attach a KMS key directly to the existing volume identifier using the modify-volume API call
- Enable encryption by default in the account settings, which retroactively encrypts every existing volume in the region
Encryption is fixed at volume creation, so the only route is snapshot, encrypted copy, new volume, then swap the attachment. There is no toggle and no modify-volume encryption parameter, and account level encryption by default applies to newly created volumes only, never retroactively.
5. An RDS MySQL instance was created without storage encryption and now must be encrypted at rest. What must be done?
- Modify the instance and select a KMS key, then reboot it during the next scheduled maintenance window
- Enable Performance Insights with a customer managed key, which encrypts the underlying storage as a side effect
- Restore a snapshot into a new encrypted instance and cut over to it (correct answer)
- Turn on automated backups with a retention period long enough for the encryption setting to take effect
Like EBS, RDS storage encryption is decided at creation, so the supported path is copy the snapshot with encryption, restore into a fresh instance and repoint the application. Modify offers no encryption switch, Performance Insights encrypts only its own metrics store, and backup retention has nothing to do with volume encryption.
6. Which statement about encrypting an Amazon EFS file system is correct?
- Encryption at rest is chosen at creation, while encryption in transit is enabled per mount with TLS (correct answer)
- Both encryption at rest and encryption in transit can be switched on at any moment from the file system console page
- Encryption in transit is always on and cannot be disabled by any client, whatever mount helper options are supplied
- Encryption at rest can be added later provided the file system is unmounted from every connected instance first
EFS at rest encryption is an immutable creation time property, whereas in transit encryption is a client side choice made with the -o tls mount option through the EFS mount helper. It therefore cannot be turned on later, is not always on, and unmounting changes nothing about the stored data.