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.

• ✗

  Apply a service control policy (SCP) that denies the s3:PutBucketPublicAccessBlock and s3:PutBucketEncryption actions unless the bucket has encryption enabled.

  Why it's wrong here

  Incorrect. This SCP is circular and unenforceable; it denies s3:PutBucketEncryption unless the bucket already has encryption enabled, which cannot be satisfied when creating a bucket. SCPs cannot enforce configuration requirements on bucket creation - they only control permissions.

• ✗

  Use an S3 bucket policy that denies PutObject unless the request includes the x-amz-server-side-encryption header.

  Why it's wrong here

  This bucket policy would use the s3:x-amz-server-side-encryption condition key to deny unencrypted PutObject calls, which does enforce an encryption header on new object writes. However, it has no effect on the bucket's default encryption configuration, so a non-compliant bucket can still be created without server-side encryption. The policy is also evaluated at object-write time only, meaning it neither remediates existing objects nor prevents the underlying bucket-level misconfiguration.

• ✓

  Enable AWS Config with the s3-bucket-server-side-encryption-enabled rule and set up automatic remediation using Systems Manager Automation.

  Why this is correct

  AWS Config's managed rule s3-bucket-server-side-encryption-enabled continuously evaluates each bucket and flags any bucket whose default encryption setting is disabled. When non-compliance is detected, the rule can trigger an SSM Automation remediation—typically the AWS-EnableS3BucketEncryption document—which automatically applies the appropriate SSE-S3 or SSE-KMS default encryption to the bucket. This pairing of continuous detection and automated remediation provides an enforceable, organization-wide corrective control that directly satisfies the encryption requirement.

• ✗

  Create an IAM role with permissions to enforce encryption and attach it to all accounts in the organization.

  Why it's wrong here

  An IAM role is an identity construct that grants permissions to principals when assumed; attaching a role to an account does not set any bucket property or activate any enforcement mechanism. Creating an IAM role with encryption permissions in every account only allows users or services to call actions like PutBucketEncryption, but it does not force those actions to be taken. AWS Organizations does not attach roles to accounts—it uses SCPs at the root or OU level—and, unlike AWS Config with remediation, a role alone cannot evaluate bucket state or act automatically.

Go deeper

Related to this question