Exam AWS Certified Solutions Architect - Professional SAP-C02 topic 1 question 51 discussion

https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html So the correct answer is B. In the S3 bucket properties, change the default encryption to server-side encryption with AWS KMS managed encryption keys (SSE-KMS). Set an S3 bucket policy to deny unencrypted PutObject requests. Use the AWS CLI to re-upload all objects in the S3 bucket.

I think D is correct. https://docs.aws.amazon.com/AmazonS3/latest/userguide/ServerSideEncryptionCustomerKeys.html

A. In the S3 bucket properties, change the default encryption to SSE-S3 with a customer managed key. Use the AWS CLI to re-upload all objects in the S3 bucket. Set an S3 bucket policy to deny unencrypted PutObject requests. Here's why: Requirements Recap: All current and future objects must be encrypted using customer-managed keys. The current encryption is SSE-S3, which uses S3-managed keys, not customer-managed keys. The bucket does not have versioning enabled, so overwriting (re-uploading) is necessary to change encryption on existing objects.

B. In the S3 bucket properties, change the default encryption to server-side encryption with AWS KMS managed encryption keys (SSE-KMS). Set an S3 bucket policy to deny unencrypted PutObject requests. Use the AWS CLI to re-upload all objects in the S3 bucket.

AWS KMS (Key Management Service) allows for customer-managed keys (CMKs), which can indeed be considered as "keys that the company’s security team manages"

In s3 option there is no option to select AES256 custom key.

To meet the requirement for encrypting all current and future objects in an Amazon S3 bucket with keys managed by the company’s security team, change the S3 bucket’s default encryption to server-side encryption with AWS KMS managed keys (SSE-KMS). Implement an S3 bucket policy to deny unencrypted PutObject requests, ensuring all new uploads are encrypted with the specified KMS key. Then, use the AWS CLI to re-upload all existing objects to the S3 bucket, enforcing the new encryption policy on current data. This approach ensures compliance by applying KMS encryption to both new and existing objects without causing disruptions   .

The solutions need to use SSE-KMS so that the security team can manage the keys, but they also need to ensure that current and future objects are encrypted using customer-managed keys.

Not Option D: " Amazon S3 server-side encryption uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) to encrypt all uploaded objects." AES- 256 is already the default, so you can't change it. https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingServerSideEncryption.html

Correct Approach: This option is accurate and meets all the specified requirements. By changing the default encryption to server-side encryption with AWS KMS managed encryption keys (SSE-KMS), the company can use customer managed keys (CMKs) for encryption. This allows the security team to manage the keys, addressing the core requirement. Setting an S3 bucket policy to deny unencrypted PutObject requests ensures future compliance with the encryption policy. Re-uploading all objects using the AWS CLI ensures that existing objects are encrypted under the new policy, making sure that both current and future objects are encrypted with the keys managed by the company's security team.

B, option D confuses encryption options. AES-256 is part of the SSE-S3 encryption method and doesn't directly involve customer-managed keys

The solution that meets the requirements for encrypting all current and future objects in the Amazon S3 bucket with keys that the company’s security team manages, while ensuring server-side encryption, is: Option B is correct because it directly addresses the new requirement by changing the default encryption method to SSE-KMS, which allows the use of AWS Key Management Service (KMS) keys managed by the company’s security team. This option ensures that all future uploads are encrypted with the specified KMS key. It also includes re-uploading existing objects to ensure they are encrypted under the new scheme. Setting an S3 bucket policy to deny unencrypted PutObject requests enforces the encryption requirement for all new uploads.

Not A. SSE-S3 with a customer managed key is not an actual option as SSE-S3 uses S3 managed keys Not C. S3 bucket policy cannot automatically encrypt objects on GetObject and PutObject requests. With policies you can only allow/deny actions from specific principals Not D. AES-256 with a customer managed key is not an actual option as AES-256 is used as value for the header x-amz-server-side-encryption to set SSE-S3 on putObject and SSE-S3 uses S3 managed keys B is correct as server-side encryption with AWS KMS managed encryption keys (SSE-KMS) is an actual default encryption settings for S3 bucket and you can use S3 bucket policy to deny unencrypted PutObject. These ensure all new objects will be encrypted with customer managed keys. Then using aws cli to re-upload all object will overwrite existing objects (versioning is not enabled)

i think D is correct as B is mentioned KMS managed key..

A - You cannot define your own key B - Correct. Using SSE-KMS and your own KMS customer managed key, you adhere to the requirements C - Does not encrypt existing objects, and you cannot "change" the request to "automatically" encrypt D - You can only choose between SSE-S3 and SSE-KMS (or now DSSE-KMS as well) for default encryption. Underlying the SSE-S3 refers to AES-256 (cfr. "s3:x-amz-server-side-encryption": "AES256") but you cannot specify your customer managed key in that case.

If use KMS-CMK , wouldn't it be possible to manage keys directly while using KMS? Does anyone have an opinion on this?

B is correct https://docs.aws.amazon.com/AmazonS3/latest/userguide/UsingKMSEncryption.html#aws-managed-customer-managed-keys When you use server-side encryption with AWS KMS (SSE-KMS), you can use the default AWS managed key, or you can specify a customer managed key that you have already created.