SCS-C02 Management and Security Governance Practice Question
A company runs a multi-account AWS environment using AWS Organizations. The security team uses AWS Config to monitor compliance. Recently, they noticed that a developer in the 'development' account created an S3 bucket that is publicly accessible. The security team wants to prevent this in the future by automatically remediating any public S3 bucket. They have an SCP that denies s3:PutBucketPublicAccessBlock, but developers are still making buckets public by using bucket ACLs. The security team wants to implement a solution that automatically fixes any bucket that becomes public. Which solution should they choose?
⚠ Common exam trap
A common mix-up: candidates assume an SCP or IAM policy that denies the specific API call (s3:PutBucketAcl) is the best solution, but the question requires automatic remediation of already-public buckets, not prevention—and SCPs cannot remediate existing noncompliant resources, only block future actions.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
Use AWS Config with the s3-bucket-public-read-prohibited managed rule and an automatic remediation action using AWS Systems Manager Automation
AWS Config's s3-bucket-public-read-prohibited managed rule evaluates S3 bucket ACLs and policies for public read access. When a noncompliant bucket is detected, an automatic remediation action using AWS Systems Manager Automation can invoke a custom SSM document (e.g., AWS-DisableS3BucketPublicReadWrite) to remove public ACLs or apply a bucket policy that denies public access. This provides automated, event-driven remediation without relying on manual intervention or incomplete SCPs.
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 CloudTrail to detect PutBucketAcl events and send to SNS for manual remediation
Why it's wrong here
CloudTrail and SNS only provide a detective control: you are notified after a PutBucketAcl call has already made a bucket public, and the remediation depends on a human responding to the alert and manually correcting the ACL. There is no automatic enforcement or rollback, so the bucket remains publicly accessible until someone acts, which can be hours or days later. Manual processes also don't scale across a multi-account environment and are prone to missed or delayed responses.
- ✓
Use AWS Config with the s3-bucket-public-read-prohibited managed rule and an automatic remediation action using AWS Systems Manager Automation
Why this is correct
AWS Config continuously evaluates bucket configurations against the s3-bucket-public-read-prohibited managed rule, which checks both bucket ACLs and bucket policies for public read access. When a violation is detected, an automatic remediation action invokes an AWS Systems Manager Automation runbook (e.g., AWS-DisableS3BucketPublicRead) to remove the public grant or apply a deny. This is a fully automated lifecycle: detect, remediate, and re-evaluate until compliant, without human intervention, making it the correct solution.
- ✗
Update the SCP to deny s3:PutBucketAcl with a condition for public access
Why it's wrong here
SCPs cannot inspect the contents of an ACL request body, so you cannot write a condition that denies a PutBucketAcl only when the ACL grants public access; the canned ACL header (e.g., public-read) is the only request detail SCPs might see, and even that is not reliable for XML ACLs. Moreover, denying s3:PutBucketAcl does nothing to remediate buckets that are already public—existing ACLs stay in effect—and it fails to block public access granted via bucket policies or object-level ACLs.
- ✗
Attach an IAM policy to all users that denies s3:PutBucketAcl
Why it's wrong here
Attaching an IAM policy that denies s3:PutBucketAcl to all users does not change the ACLs already in place on existing buckets, so any currently public bucket remains public until manually fixed. It also ignores other public-access vectors like bucket policies or object-level ACLs, and IAM policies are scoped to IAM principals within the account—they do not restrict the root user, the S3 service, or any cross-account entities that might have permissions. Denying the action by brute force is not a targeted or comprehensive remediation strategy.
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
Courseiva writes every SCS-C02 question from scratch — 1,205 in total, each with an explanation and a wrong-answer breakdown. None are copied from real exams or dumps. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SCS-C02 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SCS-C02 exam.