SCS-C02 AWS Config 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.

• ✓

  Create an AWS Config rule that checks for S3 bucket encryption and auto-remediates

  Why this is correct

  The AWS Config managed rule s3-bucket-server-side-encryption-enabled evaluates every S3 bucket against your encryption policy and marks those without default encryption as non-compliant. By attaching an automatic remediation action, Config invokes an SSM Automation document that runs PutBucketEncryption on the non-compliant bucket, bringing it into compliance without manual intervention. This detects buckets that CloudFormation created without encryption and repairs them, making it an effective retrospective and continuous control.

• ✗

  Enable S3 Block Public Access at the account level

  Why it's wrong here

  S3 Block Public Access is a security control that only restricts who can access an object or bucket via public policies; it has no bearing on how data is encrypted at rest. Enabling it at the account level would not detect or prevent CloudFormation from deploying an S3 bucket with SSE disabled, because the bucket's encryption configuration is entirely independent of public access settings. This option fails to address the encryption requirement.

• ✓

  Attach a service control policy (SCP) to the root OU that denies S3 bucket creation without encryption

  Why this is correct

  A service control policy attached to the root organizational unit can deny s3:CreateBucket API calls when the request does not include an encryption setting, such as the x-amz-server-side-encryption header. Since SCPs govern all IAM principals under the OU—including the CloudFormation service role—any template that attempts to create a bucket without specifying encryption will be blocked at the API level. This is a strong preventive control that stops unencrypted buckets from ever being created, regardless of whether the caller is an administrator or an automated service.

• ✗

  Attach an IAM role to the CloudFormation service that grants permissions to encrypt buckets

  Why it's wrong here

  Attaching an IAM role to the CloudFormation service simply grants permissions to perform API calls; it does not mandate that those calls include encryption parameters. Even with the s3:PutEncryptionConfiguration permission, CloudFormation will happily create an unencrypted bucket if the template omits the BucketEncryption property. IAM roles are not policy engines for resource configuration—they only authorize actions, so this approach cannot enforce encryption as a condition of resource creation.

• ✗

  Use a CloudFormation stack policy to deny creation of S3 buckets without encryption

  Why it's wrong here

  A CloudFormation stack policy is designed to protect existing stack resources from being accidentally updated during a stack update operation; it does not impose conditions on resource creation. When CloudFormation initially creates an S3 bucket, the stack policy has no effect because the bucket does not yet exist to be protected. Moreover, stack policies cannot require that the template's BucketEncryption property be set—they only restrict update actions like replacement or deletion, not the initial configuration.

Go deeper

Related to this question