Enforcing S3 Encryption and Public Access Block with SCPs
A financial services company is designing a multi-account AWS environment using AWS Organizations. They need to enforce that all newly created S3 buckets in any account have server-side encryption enabled using AWS KMS (SSE-KMS) with a customer managed key. Additionally, they want to prevent any S3 bucket from being publicly accessible. What is the MOST efficient and comprehensive way to enforce these policies?
Quick Answer
The answer is to combine SCPs that deny unencrypted PUT operations and block public access with a resource-based policy on the S3 service. This is correct because SCPs act as preventive guardrails at the account level, denying any s3:PutObject that lacks the x-amz-server-side-encryption-aws:kms header, while a second SCP denies s3:PutBucketPublicAccessBlock unless a specific condition key is met, and a centralized S3 resource policy blocks all public access across the organization. On the AWS Certified Solutions Architect Professional SAP-C02 exam, this scenario tests your understanding that SCPs cannot directly enforce encryption on resources—they only control API permissions—so you must pair them with service-level policies for comprehensive enforcement. A common trap is choosing AWS Config rules, which are detective and require remediation, not preventive. Memory tip: SCPs are the gatekeeper, S3 policies are the lock—together they enforce S3 encryption and block public access proactively.
⚠ Common exam trap
Many candidates confuse SCPs with resource-based policies or AWS Config remediation, thinking reactive detection is sufficient, but the question asks for the 'most efficient and comprehensive' approach, which requires proactive prevention at the API level using SCPs.
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 an SCP that denies s3:PutObject without the x-amz-server-side-encryption-aws:kms header, and another SCP that denies s3:PutBucketPublicAccessBlock with a condition key. Also, use a resource-based policy on the S3 service to block public access.
SCPs can deny the s3:PutObject action unless the x-amz-server-side-encryption-aws:kms header is present, ensuring SSE-KMS is enforced at the API level across all accounts. Additionally, an SCP denying s3:PutBucketPublicAccessBlock with a condition key (e.g., requiring the PublicAccessBlockConfiguration to be fully enabled) prevents any bucket from being made publicly accessible. This approach is comprehensive and efficient as it proactively blocks non-compliant actions before they occur, rather than relying on reactive remediation.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Use a service control policy (SCP) to deny the s3:PutBucketAcl action that grants public access, and rely on bucket policies to enforce encryption.
Why it's wrong here
Bucket policies are account-specific and may not be enforced across all accounts; also does not address encryption.
- ✗
Use AWS Config rules with automatic remediation to enable encryption and block public access on any non-compliant bucket.
Why it's wrong here
Config rules are detective, not preventive; non-compliant buckets may exist temporarily.
- ✓
Create an SCP that denies s3:PutObject without the x-amz-server-side-encryption-aws:kms header, and another SCP that denies s3:PutBucketPublicAccessBlock with a condition key. Also, use a resource-based policy on the S3 service to block public access.
Why this is correct
SCPs can deny actions based on conditions, and resource policies can prevent public access proactively.
- ✗
Create an SCP that denies the s3:PutBucketPublicAccessBlock action and attach it to the root OU.
Why it's wrong here
SCPs cannot enforce encryption settings; they only control actions.
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
One of 1,660 original SAP-C02 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SAP-C02
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. A company is designing a multi-account AWS environment using AWS Organizations. The security team requires that all Amazon S3 buckets across accounts must have server access logging enabled and must block public access. What is the MOST scalable and secure way to enforce these requirements?
hard- A.Use AWS CloudFormation StackSets to deploy S3 buckets with logging and public access blocks
- ✓ B.Apply service control policies (SCPs) at the organizational unit (OU) level to deny actions that disable logging or enable public access
- C.Create IAM roles in each account with policies that require logging and block public access
- D.Use AWS Config rules to detect non-compliant buckets and send notifications
Why B: Service control policies (SCPs) at the OU level are the most scalable and secure way to enforce guardrails across all accounts in an AWS Organization. By denying actions that disable server access logging (e.g., s3:PutBucketLogging with a condition that the logging target is not set) and actions that enable public access (e.g., s3:PutBucketPublicAccessBlock with a condition that the block is not set to true), SCPs prevent non-compliant configurations from being created or modified, regardless of the IAM principal used. This approach is centralized, immutable by child accounts, and scales automatically as new accounts are added to the OU.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAP-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 SAP-C02 exam.