SAA-C03 Design Secure Architectures Practice Question

An S3 bucket uses a customer-managed KMS key as the default for SSE-KMS encryption. A service role will upload objects using s3:PutObject. Assuming the role already has permission to write to the bucket, which KMS permission is most directly required for the role to let S3 encrypt the object during upload?

⚠ Common exam trap

Many exam-takers confuse kms:Decrypt (needed for GET/read operations) with kms:GenerateDataKey (needed for PUT/write operations), or they assume any KMS permission will work because S3 handles encryption transparently.

Answer choices

Why each option matters

Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.

Correct answer & explanation

✓

kms:GenerateDataKey (and optionally kms:DescribeKey)

When S3 uses SSE-KMS with a customer-managed KMS key, the service calls KMS to generate a data key for encrypting the object. The s3:PutObject operation requires the caller to have kms:GenerateDataKey permission on the KMS key so that S3 can obtain the plaintext and encrypted versions of the data key. Optionally, kms:DescribeKey may be needed for S3 to verify the key exists, but kms:GenerateDataKey is the most directly required permission.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
kms:GenerateDataKey (and optionally kms:DescribeKey)
Why this is correct
For SSE-KMS uploads, S3 uses KMS to generate a data key for encrypting the object. kms:GenerateDataKey is the direct permission required for that flow. kms:DescribeKey can be useful for validation or troubleshooting, but it is not the core cryptographic permission.
✗
kms:Decrypt only
Why it's wrong here
kms:Decrypt only is insufficient because SSE-KMS encryption during upload requires S3 to request a new data key from KMS, not to decrypt an existing one. While kms:Decrypt is essential when reading objects back to unwrap the stored ciphertext data key, it does not help S3 obtain a fresh data key for encrypting the object being written. Without kms:GenerateDataKey, the upload flow fails even if Decrypt is allowed.
✗
kms:CreateAlias and kms:UpdateAlias only
Why it's wrong here
kms:CreateAlias and kms:UpdateAlias only manage the friendly alias name that references a CMK, but they do not grant any cryptographic permission on the key itself. These IAM actions allow renaming or creating aliases, yet S3's SSE-KMS upload needs the key to generate a data key, which requires kms:GenerateDataKey. Alias management is an administrative control plane operation, completely separate from the data plane encryption operation that S3 performs on your behalf.
✗
kms:ScheduleKeyDeletion and kms:CancelKeyDeletion only
Why it's wrong here
kms:ScheduleKeyDeletion and kms:CancelKeyDeletion are administrative lifecycle permissions that control whether a KMS key is pending deletion or is restored. Granting these does not allow S3 to use the key for encryption because they do not authorize any cryptographic operations such as generating or decrypting data keys. In fact, scheduling deletion would render the key unusable for SSE-KMS, leading to upload failures once the key is pending deletion or eventually deleted.

Quick reference

AWS S3 Storage Class Comparison

Storage Class	Min Duration	Retrieval	Use Case
S3 Standard	None	Immediate	Frequently accessed data
S3 Standard-IA	30 days	Immediate	Infrequent access, rapid retrieval
S3 One Zone-IA	30 days	Immediate	Non-critical infrequent data
S3 Intelligent-Tiering	None	Immediate–hours	Unknown or changing access patterns
S3 Glacier Instant	90 days	Milliseconds	Archive with instant retrieval
S3 Glacier Flexible	90 days	Minutes–hours	Archive, flexible retrieval
S3 Glacier Deep Archive	180 days	Hours	Long-term compliance archive

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question