SCS-C02 Infrastructure Security 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.

• ✗

  Enable AWS CloudTrail to monitor GetPublicAccessBlock calls.

  Why it's wrong here

  AWS CloudTrail records API activity such as GetPublicAccessBlock calls, but it only provides an audit log of actions taken; it does not evaluate the contents of S3 bucket policies for compliance or proactively identify buckets that allow public access. Moreover, the GetPublicAccessBlock API simply retrieves the current Block Public Access settings for a bucket, not the bucket policy itself, so monitoring this call gives no insight into policy statements that grant public read or write access. To detect public policies you would need a dedicated policy analyzer or a config rule, not CloudTrail logs.

• ✓

  Use IAM Access Analyzer to review bucket policies for public access.

  Why this is correct

  IAM Access Analyzer is the correct tool here because it uses automated reasoning to analyze resource-based policies, including S3 bucket policies, and generates findings for any policy that grants access to principals outside your AWS account or organization. It specifically flags 'public' access when a bucket policy allows anonymous access (Principal: "*"), and it also surfaces cross-account access with detailed context about the external principal, actions, and resource. This allows you to review every bucket policy systematically and remediate unintended public exposure, making it a comprehensive policy-review solution.

• ✗

  Use Amazon Inspector to scan bucket policies.

  Why it's wrong here

  Amazon Inspector is an automated vulnerability management service that scans workloads such as Amazon EC2 instances, container images in Amazon ECR, and AWS Lambda functions for software vulnerabilities and unintended network exposure. It has no capability to parse, inspect, or evaluate S3 bucket policies for public access, because its scanning engine operates on compute resources and operating systems, not on object storage configuration. Therefore, using Inspector to review S3 bucket policies would be completely out of scope and technically ineffective.

• ✓

  Use AWS Config with the s3-bucket-public-read-prohibited managed rule.

  Why this is correct

  The AWS Config managed rule s3-bucket-public-read-prohibited is a correct choice because it continuously evaluates S3 buckets and marks them NON_COMPLIANT if their bucket policies or bucket ACLs grant public read access. This rule can be run on a scheduled frequency or in response to configuration changes, and results can be aggregated across the organization via aggregation, giving ongoing compliance assurance. It is specifically designed to catch S3 buckets that are publicly readable, making it a valid managed rule for this requirement, though it focuses only on read access rather than all public actions.

• ✗

  Use AWS Trusted Advisor to check S3 bucket permissions.

  Why it's wrong here

  AWS Trusted Advisor does offer an S3 bucket permissions check, but it is a high-level best-practice review that only flags buckets with public read or write access on its dashboard and does not provide per-bucket policy-level detail, historical audit trails, or integration with compliance remediation workflows. It also does not comprehensively analyze the full policy language for statements like Principal: "*" with conditions, and it is not designed to be a continuous per-bucket compliance enforcement mechanism. Therefore, while it can surface basic issues, it is not robust enough for ensuring all S3 bucket policies are free of public access across an enterprise environment.