L12. S3 Data Protection: Bucket Policies, Access Points & Object Lock
Video generating
Check back soon for the video lesson on S3 Data Protection: Bucket Policies, Access Points & Object Lock
Block Public Access as the last line of defense, Access Points for scaling shared-bucket permissions, and Object Lock Compliance mode as a WORM defense even the root user cannot override.
Block Public Access: The Last Line of Defense
S3 Block Public Access is a setting available at both the account level and the individual bucket level, and it overrides any bucket policy or ACL that would otherwise make objects public, no matter how the exposure was introduced. A misconfigured bucket policy, an overly permissive ACL, or a well-meaning developer testing something in production all get stopped by the same control. This is why it is consistently described as the single strongest safeguard against accidental public exposure: it does not require anyone to get every other setting right; it just refuses to let public access happen at all when enabled.Object Ownership: Simplifying Down to Policies
S3 Object Ownership controls who owns objects uploaded by other AWS accounts and, more importantly for the exam, whether ACLs matter at all. Setting Object Ownership to "Bucket owner enforced" disables ACLs entirely for the bucket. Every access decision then comes down to bucket policies and IAM alone, which is simpler to reason about and audit than a mix of ACLs, bucket policies, and IAM working together. This is now AWS's default and recommended setting for new buckets, reflecting a broader shift away from ACLs as an access control mechanism.Access Points for Shared Buckets
When many applications or teams share a single bucket, maintaining one bucket policy that encodes every consumer's rules becomes unwieldy fast. S3 Access Points solve this by creating named, distinct network endpoints for the same underlying bucket, each with its own access policy. A finance team's access point and a marketing team's access point, both pointing at the same bucket, can enforce completely different policies without either team's rules bleeding into the other's. A VPC-only access point takes this further, restricting access to requests that originate from a specific VPC, which is a clean way to keep bucket access private to an internal network path.
Object Lock: WORM Protection
S3 Object Lock enforces Write Once, Read Many (WORM) semantics on objects, and the exam draws a hard line between its two modes:| Mode | Can be overridden? |
|---|---|
| Governance | Yes, by users granted the special s3:BypassGovernanceRetention permission |
| Compliance | No, by anyone, including the root user, until the retention period expires |
Encrypt by Default
Default bucket encryption, set to either SSE-S3 or SSE-KMS, ensures every new object is encrypted automatically, even if the uploader's request never specifies an encryption header. This closes the gap where an application team forgets to configure encryption client-side. Cross-region replication carries its own nuances around preserving encryption status and object ownership on the replica, and it is worth double-checking whenever a scenario combines replication with a KMS-encrypted source bucket, since a replica in a different region needs its own KMS key. Exam tip: If a question says "cannot be deleted by anyone, including the root user," that is Compliance mode, full stop. If it says "can be overridden with special permission," that is Governance mode.- ✓S3 Block Public Access at the account or bucket level overrides any bucket policy or ACL that would otherwise expose objects publicly
- ✓"Bucket owner enforced" Object Ownership disables ACLs entirely, leaving bucket policies and IAM as the only access controls, which is the current AWS-recommended default
- ✓S3 Access Points give each application or team its own named endpoint and policy on a shared bucket, and can be restricted to a specific VPC
- ✓S3 Object Lock Governance mode can be overridden by users with special permission; Compliance mode cannot be overridden or deleted by anyone, including the root user, until the retention period expires
- ✓Default bucket encryption (SSE-S3 or SSE-KMS) ensures new objects are encrypted automatically even when the uploader does not specify encryption settings
1. A bucket policy accidentally grants public read access to an S3 bucket containing sensitive data. What is the most effective control to prevent this from actually exposing the data?
2. A company needs to guarantee that backup files cannot be deleted or overwritten by anyone, including their own root user, for 7 years to satisfy a regulatory requirement, even if credentials are compromised. Which S3 feature enforces this?
3. Multiple application teams share a single S3 bucket, and each team needs a distinct, independently manageable access policy without splitting the bucket. What should they use?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured SCS-C02 learning paths, hands-on AWS security labs, and timed practice exams to make it stick before exam day.