SCS-C02 Data Protection Practice Question

Answer analysis

Option-by-option breakdown

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

• ✓

  Add a bucket policy that denies s3:PutObject if s3:x-amz-server-side-encryption is not aws:kms. Use S3 Inventory to report encryption status of existing objects.

  Why this is correct

  This solution combines an explicit bucket policy deny with the s3:x-amz-server-side-encryption condition key to reject any PutObject that does not specify aws:kms as the encryption value, making enforcement happen before the write is committed. Because this is a request-level condition, it cannot be bypassed by client-side SDK settings or explicit SSE headers that differ from KMS. S3 Inventory then provides a periodic CSV or Parquet report of existing objects, including their encryption status, enabling the team to locate and remediate any legacy objects that predate the policy.

• ✗

  Use AWS Config rule s3-bucket-server-side-encryption-enabled to check compliance.

  Why it's wrong here

  The AWS Config managed rule s3-bucket-server-side-encryption-enabled only checks whether the bucket has default encryption configured; it does not inspect individual object headers and cannot evaluate the encryption state of each upload. This is a detective control—it will flag a noncompliant bucket in the compliance dashboard after the fact but will not stop an unencrypted PutObject from being accepted. It also cannot distinguish between SSE-S3 and SSE-KMS, so it falls short of the requirement that every object be encrypted with aws:kms.

• ✗

  Use S3 Object Lock with governance mode.

  Why it's wrong here

  Object Lock with governance mode enforces a retention period and prevents objects from being deleted or overwritten, but it has no awareness of encryption headers and does not influence how objects are written. The governance setting simply allows privileged users to bypass retention for legal holds or lifecycle actions, and it can be applied to objects regardless of whether they are encrypted. Since it lacks any mechanism to evaluate or reject an unencrypted upload, this control addresses durability and compliance hold requirements, not the stated encryption requirement.

• ✗

  Enable default encryption with SSE-KMS on the bucket. Use S3 Inventory to report encryption status.

  Why it's wrong here

  Setting a bucket's default encryption to SSE-KMS encrypts only objects that are uploaded without an explicit x-amz-server-side-encryption header; if a client sends that header with a different value such as AES256 or even a different KMS key, the request-level header overrides the bucket default and the object may be written with non-KMS encryption. The default does not block these explicit overrides, so it cannot guarantee that all objects use aws:kms. While S3 Inventory will report which objects are encrypted, it is a read-only audit that provides no enforcement for future writes, leaving the same gap as the original problem.

Go deeper

Related to this question