SOA-C02 Security and Compliance Practice Question
An organization wants to ensure that no Amazon S3 bucket in the entire AWS Organization can be made public. The security team requires a preventive control that cannot be overridden by individual account administrators. Which AWS service or feature should be used?
⚠ Common exam trap
Watch out — candidates often choose account-level S3 Block Public Access (Option D) because it seems like a direct preventive control, but they overlook that it can be overridden by account administrators, whereas an SCP is a centralized, non-overridable guardrail that applies across the entire AWS Organization.
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
✓
Create a Service Control Policy (SCP) in AWS Organizations that denies permissions to modify S3 bucket public access settings.
A Service Control Policy (SCP) in AWS Organizations is a preventive guard that applies to all accounts within the organization. It can explicitly deny actions like s3:PutBucketPublicAccessBlock, s3:PutBucketPolicy, and s3:PutObjectAcl, preventing any principal (including root users) from making S3 buckets public. Unlike detective or account-level controls, SCPs cannot be overridden by individual account administrators, meeting the requirement for a non-overridable 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.
- ✓
Create a Service Control Policy (SCP) in AWS Organizations that denies permissions to modify S3 bucket public access settings.
Why this is correct
A Service Control Policy (SCP) attached at the organization root or an organizational unit (OU) is inherited by every AWS account underneath, and it operates as an allow-list or denial of AWS API actions at the account level. Because SCPs are evaluated by AWS Organizations before IAM policies, even an account root user with full administrative rights cannot override an explicit deny of s3:PutBucketPolicy, s3:PutBucketAcl, or s3:PutBucketPublicAccessBlock, making it a true preventative guardrail across the entire organization. This is why the correct answer is to use SCPs rather than account-local controls.
- ✗
Enable AWS Config rules in each account to detect public S3 buckets and automatically remediate them using AWS Lambda.
Why it's wrong here
Enabling AWS Config rules in each account is a detective control: the rules only evaluate resources after a change has been recorded and mark a public bucket as noncompliant, but they do not block the API call that created the exposure. Automating remediation with a Lambda function introduces a delay and requires that function to have its own IAM permissions to alter the bucket policy, and if the bucket is already public an attacker may have copied the data in that gap. This approach is reactive and cannot guarantee delivery of a security objective, whereas an SCP would stop the permission at the authorization layer.
- ✗
Use an IAM policy attached to all IAM users in each account that denies s3:PutBucketPolicy.
Why it's wrong here
Attaching an IAM policy to every IAM user that denies s3:PutBucketPolicy is ineffective because IAM policies are identity-based and only apply to the principals they are attached to; they do not restrict the AWS account root user, nor do they apply to IAM roles, cross-account principals, or AWS services that might be granted permissions separately. An administrative user with full access can also remove or change their own IAM policy, rendering the control useless, and there is no central enforcement across member accounts of an organization. This approach lacks the organization-wide, unmodifiable-by-account-admin property that an SCP provides.
- ✗
Apply Amazon S3 Block Public Access at the account level in each individual AWS account.
Why it's wrong here
S3 Block Public Access at the account level is a strong setting, but it can be disabled by an account root user or admin with appropriate permissions. It is not a fully preventive control across an organization as it can be bypassed by account administrators.
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 SOA-C02 question from scratch — 247 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 SOA-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 SOA-C02 exam.