SOA-C02 Security and Compliance 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 all existing and future S3 buckets.

  Why it's wrong here

  S3 default encryption is a bucket-level fallback: it automatically encrypts objects only when the upload request omits a server-side encryption header. It is not an enforcement control because a client can explicitly include a different encryption header such as aws:kms, and existing objects already in the bucket will remain unencrypted after enabling the setting. Thus it cannot guarantee that every object stored in the bucket is both encrypted and specifically AES256.

• ✗

  Use AWS CloudTrail to monitor uploads without encryption and alert the administrator.

  Why it's wrong here

  AWS CloudTrail is a detective audit service, not a preventive security control. It records data events such as s3:PutObject after the operation has already succeeded, and while the event may contain encryption-related request parameters, CloudTrail cannot block or influence the request being processed. An upload that sets no encryption header will still write an unencrypted object, and the administrator is merely alerted after the fact, possibly with no easy way to retroactively enforce compliance.

• ✗

  Use S3 Inventory to list unencrypted objects and remediate them manually.

  Why it's wrong here

  S3 Inventory is a reporting feature that periodically produces a CSV/Parquet catalog of object metadata, including each object's encryption status. It is useful for identifying unencrypted objects after they have been uploaded and for tracking them, but it is fundamentally reactive: it requires a human or separate remediation process to fix noncompliant objects. Inventory does not sit in the request path and therefore has no ability to deny a new s3:PutObject that creates an unencrypted object.

• ✓

  Apply an S3 bucket policy that denies s3:PutObject unless the request includes the x-amz-server-side-encryption header set to AES256.

  Why this is correct

  This bucket policy is the correct preventive control. By using a Deny statement with the s3:x-amz-server-side-encryption condition key and the StringNotEquals operator, S3 evaluates the policy before accepting any PUT and rejects the request unless the header is exactly AES256. This forces every upload—from CLI, SDKs, or other IAM principals—to explicitly request SSE-S3 encryption, and it overrides any default bucket encryption behavior because the policy blocks requests that do not meet the condition.

Go deeper

Related to this question