All new objects in the city’s evidence bucket must be stored with SSE-KMS even when an SDK PutObject omits encryption headers. What should administrators set?
Select an answer to reveal the explanation.
Short Explanation
Bucket default encryption is the city rule on the door: new evidence objects get SSE-KMS even if a rushed Put forgets the headers. Hoping every SDK call remembers is not a control. Public buckets do not magically encrypt.
Full Explanation
To ensure all new objects in the city’s evidence bucket use SSE-KMS even when an SDK PutObject omits encryption headers, configure the bucket’s default encryption to SSE-KMS. Default encryption applies the chosen server-side settings to new objects that do not specify a conflicting encryption choice, reducing reliance on every developer remembering headers on every put.
Relying only on each developer to pass SSE headers on every Put inevitably drifts. Disabling bucket encryption and hoping a nightly Lambda rewrites keys later leaves windows of unencrypted storage and complex rewrite jobs. Making the bucket public does not cause SSE-KMS to “apply automatically” to anonymous uploads in any desirable sense and creates a severe exposure.
Exam caveat: default encryption does not retroactively encrypt existing objects—use inventory and replication/rewrite patterns for legacy objects; consider bucket policies that Deny puts lacking sse-kms if policy requires explicit headers. Operational check: configure default SSE-KMS, PutObject without encryption headers from the SDK, inspect the object’s server-side encryption metadata, and attempt a deny-policy test for incorrect encryption algorithms if the city mandates SSE-KMS exclusively.