While preparing for the AWS SAA-C03, many candidates get confused by how to encrypt an already-populated S3 bucket without rebuilding the whole pipeline. In the real world, this is fundamentally a decision about operational effort vs. correctness at scale (millions of objects) while keeping the CDN origin stable.
The Scenario #
A media startup, Northwind Arcade, runs a serverless marketing site. Static assets (images, JS bundles, product PDFs) live in an Amazon S3 bucket containing millions of objects. The bucket is the origin for an Amazon CloudFront distribution.
The team just discovered the bucket was created years ago without default encryption, so many existing objects are unencrypted. Security now requires:
- All existing objects must be encrypted, and
- Any new uploads must be encrypted automatically,
with the least engineering effort and minimal disruption.
Key Requirements #
- Encrypt existing S3 objects at massive scale (millions).
- Ensure future objects are encrypted by default.
- Minimize operational work (no full migration/re-architecture).
- Keep the S3 bucket usable as the CloudFront origin.
The Options #
- A) Create a new bucket with default encryption, download all objects locally, then upload into the new bucket.
- B) Turn on bucket default encryption, generate a list of unencrypted objects using S3 Inventory, then run an S3 Batch Operations job to copy objects onto themselves to apply encryption.
- C) Create a new KMS key, switch the bucket to SSE-KMS, enable versioning.
- D) In the S3 console, sort by encryption, manually select unencrypted objects, and apply encryption.
Correct Answer #
B
The Winning Logic #
Option B is the lowest-effort, scalable path that satisfies both requirements:
- Future objects: enabling S3 default encryption ensures new PUTs are encrypted automatically (assuming requests don’t explicitly disable/override it).
- Existing objects: S3 does not retroactively encrypt already-stored objects just because you enabled default encryption.
Using S3 Inventory to identify unencrypted objects and S3 Batch Operations to run a bulk COPY action (often “copy to same bucket/key”) forces S3 to rewrite the objects with the chosen server-side encryption.
Operationally, this avoids building new storage, avoids client-side reupload, and is purpose-built for “millions of objects” scale.
💎 Professional-Level Analysis #
This section breaks down the scenario from a professional exam perspective, focusing on constraints, trade-offs, and the decision signals used to eliminate incorrect options.
🔐 Expert Deep Dive: Why Options Fail #
This walkthrough explains how the exam expects you to reason through the scenario step by step, highlighting the constraints and trade-offs that invalidate each incorrect option.
Prefer a quick walkthrough before diving deep?
[Video coming soon] This short walkthrough video explains the core scenario, the key trade-off being tested, and why the correct option stands out, so you can follow the deeper analysis with clarity.
🔐 The Traps (Distractor Analysis) #
This section explains why each incorrect option looks reasonable at first glance, and the specific assumptions or constraints that ultimately make it fail.
The difference between the correct answer and the distractors comes down to one decision assumption most candidates overlook.
-
Why not A?
Huge operational burden and risk: local staging for millions of objects, long transfer times, data egress/ingress considerations, plus updating CloudFront origin behavior (or managing cutover) and potential cache inconsistencies. -
Why not C?
Switching to SSE-KMS and enabling versioning doesn’t automatically re-encrypt existing objects. Also, it adds key-management overhead and potentially higher per-request cost. It’s not the “least work” path and doesn’t directly solve the backfill requirement. -
Why not D?
Not feasible at scale. Manual console operations on millions of objects is slow, error-prone, and unrealistic.
🔐 The Solution Blueprint #
This blueprint visualizes the expected solution, showing how services interact and which architectural pattern the exam is testing.
Seeing the full solution end to end often makes the trade-offs—and the failure points of simpler options—immediately clear.
graph TD
Admin([Security requirement: encrypt all objects]) --> S3Bucket[(S3 Bucket)]
S3Bucket -->|Enable| DefaultEnc[Turn on Default Encryption]
S3Bucket --> Inventory["S3 Inventory Report (CSV)"]
Inventory --> Batch[S3 Batch Operations Job]
Batch -->|COPY same key to apply SSE| S3Bucket
User([Viewer]) --> CF[CloudFront]
CF -->|Origin fetch| S3Bucket
- Diagram Note: Default encryption protects future uploads, while Inventory + Batch Operations rewrites existing objects in bulk without changing the CloudFront origin bucket.
🔐 Real-World Practitioner Insight #
This section connects the exam scenario to real production environments, highlighting how similar decisions are made—and often misjudged—in practice.
This is the kind of decision that frequently looks correct on paper, but creates long-term friction once deployed in production.
Exam Rule #
When you see “encrypt existing S3 objects” + “millions of objects” + “least effort”, pick S3 Inventory + S3 Batch Operations (and enable default encryption for future writes).
Real World #
- Prefer SSE-S3 for simplest ops unless compliance mandates SSE-KMS.
- If switching to SSE-KMS, validate KMS limits and CloudFront/origin access patterns (more moving parts: key policy, IAM, request costs).
- Coordinate with lifecycle/replication rules: bulk copy can change metadata (ETag behavior for multipart) and can impact downstream integrity checks.