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.

• ✓

  Enable S3 Block Public Access at the account level

  Why this is correct

  Enabling S3 Block Public Access at the account level is the definitive control because it applies a centralized, organization-wide guardrail that overrides any per-bucket settings. It blocks public access through all four mechanisms—ACLs, bucket policies, access point policies, and multi-object access point policies—and, once set, cannot be overridden by a bucket policy unless the account-level setting itself is changed. This creates a hard boundary that ensures no bucket in the account can be made publicly accessible, even if a future misconfiguration or a bucket policy explicitly permits public access. The question asks for actions to 'ensure' protection, making this the strongest and most reliable answer as it covers all existing and future buckets.

• ✗

  Enable AWS CloudTrail for the bucket

  Why it's wrong here

  Enabling AWS CloudTrail for the bucket is a detective control, not a preventive one. CloudTrail records API calls (such as PutBucketPolicy, PutBucketAcl, and GetObject) and can help you audit who made what changes and when, but it does not intercept or block any public-access configuration. If an attacker or an IAM user sets a bucket policy that grants public read/write, CloudTrail will dutifully log the event after it has already taken effect. It can help with post-incident investigation and alerting, but it provides no enforcement and therefore cannot 'ensure' that public access is prevented.

• ✗

  Remove all bucket ACLs

  Why it's wrong here

  Removing all bucket ACLs is a good hygiene practice and eliminates one vector for granting public access, but it is insufficient by itself. S3 considers both ACLs and bucket policies when evaluating access; a bucket policy that includes a Principal: "*" with an Action like s3:GetObject would still make objects public even if all ACLs are removed. Additionally, if the bucket has no ACLs at all, a policy that allows public access can still be effective because access control is evaluated as an OR: a grant in either ACL or policy can permit the request. Therefore, removing ACLs alone does not guarantee the bucket remains private, especially if a bucket policy or an access point policy later grants public rights.

• ✗

  Set a bucket policy that denies all public access

  Why it's wrong here

  Setting a bucket policy that denies all public access is a direct attempt to lock down a specific bucket, but it is not a blanket assurance because S3's access evaluation combines multiple policy types. A denial in a bucket policy can limit what that bucket's own policy allows, but it does not block public access granted through an S3 access point or an object ACL if the bucket ACL is still present; also, S3's access decisions consider the effective permissions across identity-based and resource-based policies, and a bucket policy denial can be bypassed by the account root if it's not an explicit deny with proper conditions. Moreover, this solution requires knowing exactly which statements to write to cover all principals and actions, and it doesn't protect future buckets. S3 Block Public Access is the service-native, comprehensive safeguard that is both simpler and more robust than a custom bucket policy.

• ✓

  Enable S3 Block Public Access at the bucket level

  Why this is correct

  Enabling S3 Block Public Access at the bucket level is a powerful and direct control that blocks all public access for that specific bucket, but it only protects one bucket at a time. It overrides any ACL or bucket policy settings that would otherwise grant public access, and it cannot be bypassed by a new policy unless the bucket owner explicitly turns off the setting. However, the question likely expects a solution that 'ensures' protection across the account, and a bucket-level setting does not cover other buckets that might already exist or be created later. That is why the account-level setting is the more comprehensive correct answer; bucket-level is correct only for that individual bucket, not as a complete account-wide assurance.

Go deeper

Related to this question