SAA-C03 - Design Secure Architectures (30% of the exam) - Section 1.7

Design encryption at rest and key management using AWS KMS, envelope encryption and AWS CloudHSM.

Explain how AWS KMS uses envelope encryption, encrypting a data key with a KMS key and using that data key to encrypt the data itself, and distinguish AWS-managed keys from customer managed keys on rotation control and auditability. Choose AWS CloudHSM when regulation demands dedicated hardware security modules under exclusive customer control rather than the shared, managed KMS model.

AWS KMSEnvelope encryptionAWS CloudHSMCustomer managed keys

Practice question for this objective

Free sampleDesign Secure Architecturesmedium

A company stores millions of confidential objects in an Amazon S3 bucket and requires that all of them be encrypted at rest with a customer managed AWS KMS key for auditability. After enabling SSE-KMS as the default, the team finds that high request volumes generate a large number of KMS GenerateDataKey calls, raising both cost and the chance of hitting KMS request limits. They want to keep the same KMS key and encryption while sharply reducing KMS API calls. Which configuration meets this requirement?

ASwitch the bucket default encryption to SSE-S3 with Amazon S3 managed keys, removing the dependency on KMS for object encryption and eliminating the KMS request charges.
BRequest a quota increase for KMS cryptographic operations and add client-side caching of data keys in the application so fewer calls reach the KMS service.
CEnable an S3 Bucket Key for the bucket, so S3 uses a short-lived bucket-level data key and reduces the number of GenerateDataKey calls made to KMS. Correct
DReplace the customer managed key with an AWS managed key for S3, because AWS managed keys are not billed for GenerateDataKey calls on encrypted objects.

Enable an S3 Bucket Key to reduce KMS GenerateDataKey calls while keeping SSE-KMS encryption under a customer managed key. An S3 Bucket Key creates a bucket-level data key from the configured KMS key and reuses it to protect many objects, so S3 makes far fewer GenerateDataKey requests to KMS. This lowers KMS cost and request pressure while the bucket still encrypts every object with SSE-KMS under the same customer managed key, preserving the audit trail.

Why A is wrong: SSE-S3 removes the KMS calls but also abandons the customer managed key and the audit trail the company requires, so it fails the encryption control.

Why B is wrong: Raising quotas and writing client-side caching addresses the symptom but requires application changes and does not reduce the underlying per-object KMS billing the way a bucket key does.

Why C is correct: An S3 Bucket Key generates a bucket-level key that S3 reuses for many objects, cutting per-object KMS calls while keeping SSE-KMS and the customer managed key.

Why D is wrong: AWS managed keys still incur request charges and remove the customer-controlled key policy and rotation control the audit requirement depends on.

See more SAA-C03 practice questions, answers explained.

Exam traps in Design Secure Architectures

Answers that look right on this material and are not. Each one is a distractor from a different question in the SAA-C03 bank for this domain.

Send each file block to the KMS Encrypt API so the customer managed key directly encrypts all of the multi-gigabyte file contents in place.
Why it is wrong: Calling KMS Encrypt per block violates the no-call-per-byte requirement and exceeds the four kilobyte KMS payload limit, so it cannot encrypt multi-gigabyte files.
AWS Secrets Manager can store the HSM partition password and rotate it, which by itself satisfies the FIPS 140-2 Level 3 requirement for the encryption keys.
Why it is wrong: Secrets Manager rotates secrets such as database credentials but does not store cryptographic key material in an HSM, so it cannot meet a hardware key-storage mandate.
An AWS owned key, because AWS manages and rotates it transparently across accounts and the company inherits that rotation without configuring anything itself.
Why it is wrong: Tempting because AWS owned keys need no setup, but they are not visible in the company account, expose no key policy to edit, and produce no per-account audit trail, so the governance requirements fail.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.