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.

• ✓

  Use AWS Config with the 's3-bucket-public-read-prohibited' managed rule and configure automatic remediation to block public access.

  Why this is correct

  AWS Config's 's3-bucket-public-read-prohibited' managed rule evaluates every S3 bucket against the defined parameter (blocking public read access) on a continuous basis. Because it is a managed rule, there is no custom code to write or maintain, and when coupled with automatic remediation (using an AWS Systems Manager Automation document that applies the 'block all public access' setting or removes bucket policies), noncompliant buckets are corrected within minutes. This is the only option that provides both automated detection and automated remediation using a pre-built, low-maintenance AWS service, meeting the five-minute requirement without manual intervention.

• ✗

  Create an Amazon EventBridge (CloudWatch Events) rule that triggers an AWS Lambda function to check and fix public read access.

  Why it's wrong here

  An EventBridge rule can certainly detect configuration changes or use scheduled events to invoke a Lambda function that scans buckets and applies fixes, but this requires you to author and deploy custom Python or Node.js code to parse bucket ACLs and policies, determine what constitutes 'public read,' and then modify the S3 configuration accordingly. While feasible, this approach introduces significant engineering effort, potential for logic errors, and needs ongoing maintenance of the Lambda function and its IAM permissions. AWS Config offers the same outcome with a fully managed rule and built-in remediation, so this custom route is unnecessarily complex and more failure-prone, not a best practice.

• ✗

  Apply an S3 bucket policy to each bucket that denies public read access.

  Why it's wrong here

  Attaching a bucket policy that explicitly denies public read access (for example, a statement with "Principal":"*" and "Effect":"Deny" on s3:GetObject) works only for the specific buckets you manually configure. It does not automatically protect newly created buckets, nor does it detect or correct buckets that are later made public via ACLs or policy changes, so a new bucket could remain publicly readable indefinitely. In contrast, AWS Config's managed rule continuously evaluates all buckets and triggers remediation, providing a scalable and automated safeguard that a static, per-bucket policy cannot deliver.

• ✗

  Use AWS Trusted Advisor to check for public read access and manually remediate when notified.

  Why it's wrong here

  AWS Trusted Advisor does include a check for S3 buckets with public read or write access and can notify you via email or CloudWatch Events, but it only provides a report—it has no remediation actions. You would need to manually log into the console or use the CLI to change the ACLs or policies of each flagged bucket, which is slow and error-prone, especially if multiple buckets are involved. This fails the requirement to fix the issue within five minutes because it depends on human intervention after the notification is received and reviewed.

Go deeper

Related to this question