SAP-C02 Continuous Improvement for Existing Solutions Practice Question

A company uses Amazon S3 to store sensitive customer data. The security team requires that all data be encrypted at rest using server-side encryption with a customer-managed key (SSE-KMS). What is the MOST secure way to enforce this requirement across all S3 buckets?

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

✓

Use an S3 bucket policy that denies PutObject if the x-amz-server-side-encryption-aws-kms-key-id header is not present.

The most secure way to enforce SSE-KMS across all S3 buckets is to use an S3 bucket policy that denies PutObject if the required encryption header is not present. This ensures that any upload attempts without SSE-KMS are rejected, providing a preventive control. Option A is incorrect because AWS Config rules can only detect and remediate after the fact, not prevent non-compliant uploads. Option B is incorrect because default encryption can be overridden by specifying a different encryption header in the request. Option C is incorrect because IAM policies control permissions for API calls but cannot enforce specific encryption parameters on object uploads.

Answer analysis

Option-by-option breakdown

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

✗
Use AWS Config rules to detect unencrypted objects and remediate with Lambda.
Why it's wrong here
AWS Config rules can detect non-compliant objects and trigger remediation via Lambda, but this is reactive and does not prevent the upload from occurring, making it less secure than a preventive measure.
✗
Enable default encryption on each bucket with SSE-KMS.
Why it's wrong here
Default encryption applies only when no encryption header is specified in the PutObject request; a user can override it by explicitly setting a different encryption header, so it does not enforce SSE-KMS.
✗
Create an IAM policy that requires kms:Encrypt permission for all S3 operations.
Why it's wrong here
IAM policies can restrict which API actions a user can perform, but they cannot enforce that a specific encryption key must be used when uploading objects; encryption requirements must be enforced at the resource level via bucket policies.
✓
Use an S3 bucket policy that denies PutObject if the x-amz-server-side-encryption-aws-kms-key-id header is not present.
Why this is correct
A bucket policy that denies PutObject unless the x-amz-server-side-encryption-aws-kms-key-id header is present ensures that all objects uploaded must use SSE-KMS, providing a strong preventive control that cannot be bypassed by the user.

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

SAP-C02 Continuous Improvement for Existing Solutions Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question