SCS-C02 Infrastructure Security Practice Question

A company uses AWS Organizations with multiple accounts. The security team wants to enforce that all Amazon S3 buckets across the organization have server-side encryption (SSE-S3 or SSE-KMS) enabled. Which approach should be used to enforce this policy?

⚠ Common exam trap

Watch out — candidates often confuse detective controls (like AWS Config) with preventive controls (like SCPs), or assume that bucket policies or IAM roles can enforce encryption at creation time, when only SCPs can centrally deny the API call across an entire 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) that denies s3:CreateBucket if the bucket does not have encryption enabled.

Service Control Policies (SCPs) in AWS Organizations allow you to centrally deny API actions across all accounts. By creating an SCP that denies `s3:CreateBucket` unless the request includes encryption parameters (SSE-S3 or SSE-KMS), you enforce encryption at the point of bucket creation, preventing non-compliant buckets from ever being created. This is the only approach that proactively enforces the policy across the entire organization, rather than relying on detection or per-account configurations.

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 an S3 bucket policy in each account to deny access to unencrypted buckets.
Why it's wrong here
S3 bucket policies are resource-based policies attached to an already existing bucket; they can only limit access to that specific bucket and cannot intercept or deny the s3:CreateBucket API call. Since the bucket must exist before the policy is attached, any unencrypted bucket created by a user would be created without ever being subject to the policy, and the approach would not scale as a preventive control across many accounts and future buckets.
✗
Use AWS Config rules to detect buckets without encryption and send alerts.
Why it's wrong here
AWS Config rules continuously evaluate the configuration of tracked resources, such as S3 buckets, against compliance rules and can trigger alerts or remediation actions via EventBridge or Systems Manager. However, they run as a detective control after a resource has already been created, so the unencrypted bucket exists before the rule can flag it as noncompliant. This makes the approach reactive, not a guardrail that prevents the creation of unencrypted buckets in the first place.
✗
Create an IAM role in each account that requires encryption when creating buckets.
Why it's wrong here
An IAM role defines a set of permissions that a principal can assume, but it cannot impose requirements on other IAM identities or service actions; a user with s3:CreateBucket permission can create an unencrypted bucket without ever assuming that role. Roles are per-account identity entities, so configuring them in each account does not create a centralized guardrail and offers no enforcement if a principal does not use the role. The role's policy would only restrict what the role itself can do, not the actual creation event.
✓
Create a service control policy (SCP) that denies s3:CreateBucket if the bucket does not have encryption enabled.
Why this is correct
An SCP in AWS Organizations can apply a deny to s3:CreateBucket for every principal in the organization by using the condition key s3:x-amz-server-side-encryption to require an encryption header such as AES256 or aws:kms. Because service control policies are evaluated before any IAM policy and apply across the root, OU, or account level, they act as a centrally managed preventive control that blocks the creation of unencrypted buckets in all member accounts. With the correct condition, any request that omits or misconfigures the encryption parameter will be denied, meeting the company's objective.

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

SCS-C02 Infrastructure Security Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question