← SCS-C02·Amazon Web Services

SCS-C02 Data Protection Practice Question

Which THREE of the following are required to use client-side encryption with Amazon S3 using AWS KMS? (Choose three.)

⚠ Common exam trap

The trap is confusing client-side encryption with server-side encryption (SSE-KMS) — options about bucket policies and S3 service decrypt permissions belong to SSE, not client-side encryption.

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

✓

The encrypted data key is stored as metadata with the S3 object.

Option B is correct because with client-side encryption using the AWS SDK Encryption Client, the SDK generates a data key, encrypts the object locally, and stores the encrypted (wrapped) data key as metadata alongside the S3 object so it can be retrieved and unwrapped later. Option D is correct because the caller must have IAM permissions to invoke kms:GenerateDataKey (and typically kms:Decrypt) so the SDK can obtain a plaintext data key and a wrapped copy from AWS KMS. Option E is correct because client-side encryption is performed by the AWS SDK Encryption Client library (e.g., AmazonS3EncryptionClient), which handles key generation, local encryption, and metadata storage; S3 itself never sees plaintext. Option A is not required because a bucket policy forcing encryption governs server-side encryption at the S3 service level and is irrelevant to client-side encryption, which happens before data reaches S3. Option C is not required because the KMS key policy must grant the calling IAM principal (user or role) access to the key, not the S3 service, since S3 is not involved in the KMS operations for client-side encryption.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✗
An S3 bucket policy that forces encryption.
Why it's wrong here
A bucket policy that forces encryption is a server-side enforcement mechanism: S3 evaluates it on incoming requests and can require SSE headers or deny unencrypted objects after S3 receives them. Because client-side encryption happens entirely before the upload, the policy cannot cause or enable it, and an overly strict policy that demands server-side encryption headers may actually reject client-side encrypted objects that arrive without those headers. Thus no bucket policy is required for client-side encryption to work.
✓
The encrypted data key is stored as metadata with the S3 object.
Why this is correct
In the client-side encryption envelope scheme, the SDK creates a one-time data key, encrypts the object with it, then wraps that data key with a KMS customer master key. The resulting encrypted data key is stored in the S3 object's metadata, for example the x-amz-meta-x-amz-key-v2 attributes, so a decrypter can later retrieve it and unwrap it to get the plaintext data key. Without this metadata, the ciphertext cannot be decrypted, so this storage step is a required part of client-side encryption.
✗
A KMS key policy that allows the S3 service to decrypt.
Why it's wrong here
A KMS key policy that lets the S3 service call kms:Decrypt is tied to server-side encryption with KMS (SSE-KMS), because in that model S3 receives plaintext data, encrypts it under a KMS-generated data key, and later calls KMS to decrypt that data key. In client-side encryption, the S3 service only sees ciphertext and never performs cryptographic operations, so it needs no KMS permissions; instead, the IAM user or role invoked by the client SDK must be allowed to call KMS actions. Granting the S3 service decryption permission is therefore unnecessary and does nothing to support client-side encryption.
✓
Permissions for the IAM user or role to call kms:GenerateDataKey.
Why this is correct
The client SDK must obtain a data key from KMS before encrypting the object, so the IAM user or role making the KMS call needs kms:GenerateDataKey permission on the chosen KMS key. With a symmetric KMS key, GenerateDataKey returns a plaintext data key for encryption plus a ciphertext blob of that key to store with the object; this permission cannot be bypassed by relying on the S3 service. Without this permission, key generation fails and client-side encryption using a KMS master key cannot proceed.
✓
The AWS SDK Encryption Client library.
Why this is correct
Client-side encryption is not built into the standard S3 API or the base AWS SDK operations; it must be implemented using the AWS SDK Encryption Client or an equivalent library. That library handles the envelope-encryption protocol: generating a random data key, encrypting the object bytes, wrapping the data key with the KMS master key, writing the encrypted key and algorithm details into object metadata, and parsing that metadata on retrieval. Using a plain S3 PutObject call will not encrypt client-side, so a compatible SDK library is a required component.

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 Data Protection Practice Question

Why each option matters

Option-by-option breakdown

AWS S3 Storage Class Comparison

Related to this question