SCS-C02 S3 Default Encryption 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.

• ✓

  Enable default encryption on the bucket with SSE-S3 or SSE-KMS.

  Why this is correct

  Enabling default encryption on the bucket with SSE-S3 or SSE-KMS ensures every object placed in S3 is automatically encrypted at rest, even if the client does not send an encryption header. SSE-S3 uses AES-256 managed by AWS, while SSE-KMS uses envelope encryption with a customer-managed KMS key, giving you auditability, key rotation, and fine-grained access control. This is the simplest baseline measure to satisfy typical encryption-at-rest requirements for a new S3 data protection strategy.

• ✓

  Add a bucket policy that denies s3:PutObject unless the request includes the x-amz-server-side-encryption header.

  Why this is correct

  Adding a bucket policy that denies s3:PutObject unless the request includes the x-amz-server-side-encryption header makes encryption-at-rest a mandatory condition on every write API call. The policy uses a condition such as StringNotLike or StringNotEquals on s3:x-amz-server-side-encryption to reject any upload that does not declare AES256 or aws:kms, preventing unencrypted objects from ever being stored. This is a defense-in-depth complement to default encryption because it forces clients to take an explicit action and works across SDK, CLI, and console uploads.

• ✗

  Enable S3 Object Lock.

  Why it's wrong here

  S3 Object Lock implements a write-once-read-many (WORM) model that prevents objects from being deleted or overwritten during a retention period or while a legal hold is in place. It protects against accidental or malicious modification or deletion, but it says nothing about how the object data is encoded or encrypted at rest. Because the requirement is specifically about encrypting data at rest rather than preserving its integrity, enabling Object Lock does not meet the stated data protection goal.

• ✗

  Enable S3 Transfer Acceleration.

  Why it's wrong here

  S3 Transfer Acceleration uses Amazon CloudFront's globally distributed edge locations to route uploads over optimized network paths, reducing latency and packet loss for large files. Its sole purpose is to improve upload speed and performance; it neither encrypts the object content at rest nor adds encryption in transit beyond the standard TLS already available on S3 endpoints. Enabling this feature would not satisfy an encryption-at-rest requirement and would only add cost.

• ✗

  Enable S3 Block Public Access.

  Why it's wrong here

  S3 Block Public Access is a set of four bucket- and account-level controls that prevent public exposure of S3 resources by overriding ACLs and bucket policies that would grant broad public access. It does not inspect or enforce encryption on the object payloads, and unencrypted objects remain perfectly storable as long as they are private. Therefore, while it strengthens privacy and access control, it does not address the requirement to encrypt data at rest and cannot be used as a step toward that goal.

Go deeper

Related to this question