SCS-C02 Management and Security Governance 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.

• ✗

  AWS Trusted Advisor bucket permissions check

  Why it's wrong here

  AWS Trusted Advisor's S3 bucket permissions check only scans for buckets that are exposed to 'Everyone' or 'Any Authenticated AWS User' via bucket ACLs or bucket policies, which is equivalent to checking for public access. It does not flag policies that grant access to a specific external AWS account, nor does it provide any mechanism to annotate a finding as 'intended' after manual review. In this scenario the policy likely grants cross-account access to a particular external principal, so Trusted Advisor would not even identify it as a risk, let alone help validate intent.

• ✗

  AWS Config rule s3-bucket-public-read-prohibited

  Why it's wrong here

  The AWS Config managed rule s3-bucket-public-read-prohibited only checks whether a bucket allows anonymous public read access, typically against the canned ACL 'public-read' or a bucket policy using a wildcard principal with read actions. It is a compliance rule that returns a binary compliant/non-compliant result and has no workflow for you to mark access as intentional. Because cross-account read access to a named external account is not 'public read', the rule would remain compliant and provide no signal that the external principal might be unintended.

• ✗

  AWS CloudTrail event history

  Why it's wrong here

  CloudTrail event history captures the API calls that affect a bucket — for example, who called PutBucketPolicy, when, and with what policy document — so it can show the exact moment the questionable permission was created. However, it is a reactive audit log; it cannot classify the resulting access as intended or accidental, and it does not proactively enumerate which external principals currently have access. You would still need to manually compare the logged policy against business requirements, which is precisely the review that IAM Access Analyzer automates.

• ✓

  AWS IAM Access Analyzer

  Why this is correct

  IAM Access Analyzer continuously analyzes resource-based policies and creates findings whenever access to a resource like an S3 bucket is granted to an external principal — an AWS account outside your zone of trust or an anonymous principal. Each finding details the external account/principal, the exact actions allowed, and the policy statement causing the access, so you can determine whether that access is intended. In the console you can then mark the finding as 'Archive' for intended access or take remediation action for unintended access, which is the only option here that directly answers the security engineer's question.

Go deeper

Related to this question