CLF-C02 Security and Compliance Practice Question
A company stores sensitive documents in Amazon S3. The security team wants a preventive control that ensures no S3 bucket in the AWS account can ever be configured with a bucket policy that grants public read or write access. This control must apply automatically to all newly created buckets and to existing buckets, without requiring changes to individual bucket policies. Which AWS feature should the security team use?
⚠ Common exam trap
Candidates often confuse detective controls (like AWS Config rules) with preventive controls (like S3 Block Public Access), or they assume an IAM policy can universally block public access without considering that it must be attached to every principal and does not cover ACL-based public access.
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
✓
Amazon S3 Block Public Access at the account level
Amazon S3 Block Public Access at the account level is a preventive control that, when enabled, overrides any bucket policies or ACLs that would grant public read or write access. It applies automatically to all existing and newly created buckets in the account without requiring changes to individual bucket policies. This meets the security team's requirement for a blanket, account-wide preventive control.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
AWS Config with the s3-bucket-public-read-prohibited managed rule
Why it's wrong here
AWS Config is a detective service that evaluates resource configurations against rules. The s3-bucket-public-read-prohibited rule can detect buckets that allow public read access, but it does not prevent the bucket from being created or configured with public access. The scenario explicitly requires a preventive control, not a detective one.
When this WOULD be correct
A company wants to continuously monitor and automatically remediate S3 buckets that are publicly accessible, using a combination of AWS Config rules and AWS Systems Manager Automation to revoke public access. In that scenario, AWS Config with the s3-bucket-public-read-prohibited rule would be the correct detective and remediation tool.
- ✓
Amazon S3 Block Public Access at the account level
Why this is correct
Amazon S3 Block Public Access provides centralized controls that can be applied at the account level. When enabled, these settings override any bucket-level policies that grant public access, preventing both new and existing buckets from ever being made publicly accessible. This is the preventive control described in the scenario.
- ✗
AWS Identity and Access Management (IAM) policy with a condition that denies s3:PutBucketPolicy for any action that grants public access
Why it's wrong here
While an IAM policy with a condition key like s3:PutBucketPublicAccessBlock or a specific condition can deny PutBucketPolicy for public grants, it only applies to IAM users and roles that have the policy attached. It does not prevent the account root user or other authorized principals from making buckets public. It also does not apply to existing buckets that were made public before the policy was created. Therefore, it is not a comprehensive preventive control across the entire account.
When this WOULD be correct
This option would be correct in a scenario where the security team needs to restrict specific IAM users or roles from configuring bucket policies that grant public access, while allowing other authorized administrators to manage bucket policies. The control would apply only to those identities, not to all buckets account-wide.
- ✗
Amazon GuardDuty with a finding suppression rule for S3 public access events
Why it's wrong here
Amazon GuardDuty is a threat detection service that monitors for malicious activity and unauthorized behavior. It can generate findings when an S3 bucket is made public, but it does not prevent the action from occurring. GuardDuty is a detective and response service, not a preventive control.
When this WOULD be correct
A security team wants to automatically detect and alert on any S3 bucket that becomes publicly accessible, and they need a managed threat detection service that can analyze S3 access patterns and generate findings for review. GuardDuty would be the correct choice for this detective requirement.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The CLF-C02 exam frequently reuses these exact scenarios with slightly different constraints.
✓Amazon S3 Block Public Access at the account levelCorrect answer▾
Why this is correct
Amazon S3 Block Public Access provides centralized controls that can be applied at the account level. When enabled, these settings override any bucket-level policies that grant public access, preventing both new and existing buckets from ever being made publicly accessible. This is the preventive control described in the scenario.
✗AWS Config with the s3-bucket-public-read-prohibited managed ruleWrong answer — click to see why▾
Why this is wrong here
AWS Config is a detective control that evaluates and reports on compliance, but it does not prevent the creation of public buckets. It can only detect and alert after a bucket has been made public, not block the action proactively.
★ When this WOULD be the correct answer
A company wants to continuously monitor and automatically remediate S3 buckets that are publicly accessible, using a combination of AWS Config rules and AWS Systems Manager Automation to revoke public access. In that scenario, AWS Config with the s3-bucket-public-read-prohibited rule would be the correct detective and remediation tool.
Why candidates choose this
Candidates may confuse detective controls (AWS Config) with preventive controls (S3 Block Public Access), or assume that a managed rule can block actions, when in fact it only evaluates existing configurations.
✗AWS Identity and Access Management (IAM) policy with a condition that denies s3:PutBucketPolicy for any action that grants public accessWrong answer — click to see why▾
Why this is wrong here
An IAM policy with a condition denying s3:PutBucketPolicy for actions granting public access is not a preventive control that applies automatically to all buckets without changes to individual bucket policies. It only restricts who can set bucket policies, but does not prevent existing public access or apply to buckets created by users who are not bound by that IAM policy.
★ When this WOULD be the correct answer
This option would be correct in a scenario where the security team needs to restrict specific IAM users or roles from configuring bucket policies that grant public access, while allowing other authorized administrators to manage bucket policies. The control would apply only to those identities, not to all buckets account-wide.
Why candidates choose this
Candidates may think an IAM policy with a condition can enforce a blanket ban on public access across all buckets, but they overlook that it only applies to the users/roles it is attached to and does not affect existing public access or buckets created by other principals.
✗Amazon GuardDuty with a finding suppression rule for S3 public access eventsWrong answer — click to see why▾
Why this is wrong here
GuardDuty is a detective control that identifies threats and generates findings, not a preventive control that blocks public access. It cannot prevent S3 buckets from being configured with public access; it only alerts after the fact.
★ When this WOULD be the correct answer
A security team wants to automatically detect and alert on any S3 bucket that becomes publicly accessible, and they need a managed threat detection service that can analyze S3 access patterns and generate findings for review. GuardDuty would be the correct choice for this detective requirement.
Why candidates choose this
Candidates may confuse GuardDuty's ability to detect public access with a preventive capability, or they may think that a 'finding suppression rule' can block the action, not realizing GuardDuty only monitors and reports.
Analysis generated from the official CLF-C02blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
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
One of 988 original CLF-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This CLF-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 CLF-C02 exam.