SCS-C02 Infrastructure Security 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.

• ✗

  Use S3 bucket policies to deny access to objects without encryption.

  Why it's wrong here

  S3 bucket policies are resource-based policies that control access to objects and bucket operations. While you can write a condition that denies `s3:PutObject` when encryption headers are missing, this only governs data-plane requests; it does not evaluate or enforce the bucket's default encryption configuration at creation time. Because bucket policies do not apply to the `s3:CreateBucket` action or check for the `BucketEncryption` property, they cannot ensure that every bucket itself has SSE enabled.

• ✗

  Apply an IAM policy that requires SSE for all S3 actions.

  Why it's wrong here

  IAM policies are identity-based and attach to users, groups, or roles, not to resources like S3 buckets. Although you can require the `s3:x-amz-server-side-encryption` condition on object write calls, this cannot enforce encryption on the bucket's configuration or on the `CreateBucket` call, which does not expose an encryption parameter to IAM. To truly cover all S3 actions, the policy would have to be attached to every principal and service role, and it still wouldn't remediate existing buckets.

• ✓

  Use AWS Config with a managed rule (s3-bucket-server-side-encryption-enabled) and an automatic remediation action.

  Why this is correct

  AWS Config's managed rule `s3-bucket-server-side-encryption-enabled` continuously evaluates each S3 bucket for the presence of server-side encryption. When a bucket is found non-compliant, an automatic remediation action—typically a Systems Manager Automation document that calls `PutBucketEncryption`—is invoked to enable default encryption on that bucket. This provides a closed loop that both detects drift and corrects it for existing and newly created buckets, making it the only option that satisfies 'ensure all S3 buckets' proactively and reactively.

• ✗

  Create a service control policy (SCP) that denies creation of buckets without encryption.

  Why it's wrong here

  An SCP is an organization-wide policy that restricts what IAM principals can do, and you can attach one that denies `s3:CreateBucket` unless the request includes a `BucketEncryption` parameter. However, SCPs are purely prohibitive—they only block new bucket creation and never act on buckets that already exist without encryption. Additionally, SCPs do not provide any feedback or automatic correction when a bucket is misconfigured by another mechanism, so they fall short of a complete assurance control.

Go deeper

Related to this question