SAP-C02 Design for New Solutions Practice Question

• ✓ A.Use server-side encryption with customer-provided keys (SSE-C)
• B.Use server-side encryption with S3 managed keys (SSE-S3)
• ✓ C.Use server-side encryption with AWS KMS managed keys (SSE-KMS) with a customer managed key
• D.Enable default encryption on the S3 bucket with SSE-S3
• E.Use client-side encryption with the Amazon S3 encryption client

Why A: Option A (SSE-C) is correct because with server-side encryption using customer-provided keys, the company supplies and fully controls the encryption keys on every request, and S3 never stores them, so the company can rotate them annually per its own policy. Option C (SSE-KMS with a customer managed key) is correct because a customer managed KMS key is created, owned, and rotated by the company (automatic annual rotation can be enabled), satisfying both the company-managed key and annual rotation requirements. Option B (SSE-S3) is not correct because S3 fully manages and rotates the keys, so the company does not control them. Option D (default bucket encryption with SSE-S3) is not correct for the same reason—keys are AWS-managed, not company-managed. Option E (client-side encryption with the S3 encryption client) is not correct because it does not use S3 server-side encryption with company-managed keys as specified, and key management/rotation would fall outside the described SSE key-management model.

• A.Use S3 server-side encryption with customer-provided keys (SSE-C) and implement a Lambda function to rotate keys every 90 days.
• B.Use S3 server-side encryption with S3-managed keys (SSE-S3) and enable S3 server access logs.
• C.Use S3 server-side encryption with AWS KMS-managed keys (SSE-KMS) and enable automatic key rotation every 90 days. Enable AWS CloudTrail for KMS key usage logging.
• ✓ D.Use client-side encryption with the AWS Encryption SDK and store the keys in AWS Secrets Manager with automatic rotation.

Why D: Meets all requirements with the least operational overhead. Client-side encryption with the AWS Encryption SDK ensures data is encrypted at rest. Keys are stored in AWS Secrets Manager, which supports automatic rotation on a custom 90-day schedule. CloudTrail logs all Secrets Manager API calls, providing an audit trail of key usage. Option A requires custom Lambda code for rotation. Option B uses SSE-S3, which cannot be rotated on a 90-day schedule and lacks key usage audit. Option C uses SSE-KMS, but automatic rotation for customer managed keys is fixed at 365 days, failing the 90-day requirement.

• ✓ A.AWS KMS data key
• B.AWS KMS customer managed key
• C.AWS Certificate Manager
• D.AWS CloudHSM
• ✓ E.Amazon S3 bucket with SSE-KMS enabled

Why A: Option A (AWS KMS data key) is correct because envelope encryption requires generating a unique data key from KMS to encrypt the actual data; the plaintext data key encrypts the objects while the encrypted copy of the data key is stored alongside the data. Option E (Amazon S3 bucket with SSE-KMS enabled) is correct because SSE-KMS is the S3 server-side encryption mode that integrates with AWS KMS to perform envelope encryption automatically, using KMS keys to protect the data keys. Option B is not required because the scenario specifies an AWS managed key (aws/s3), not a customer managed key, and AWS managed keys rotate annually by default. Option C is incorrect because AWS Certificate Manager manages TLS/SSL certificates for data in transit, not encryption at rest. Option D is incorrect because AWS CloudHSM is a dedicated hardware security module service and is not needed when using AWS KMS managed keys for S3 envelope encryption.

• ✓ A.Enable default encryption with SSE-KMS on the S3 bucket.
• B.Use client-side encryption before uploading to S3.
• C.Enable S3 server access logging.
• D.Use a bucket ACL to grant access to the data lake.
• ✓ E.Configure an S3 bucket policy that allows access only from specific IAM roles.

Why A: Option A is correct because enabling default encryption with SSE-KMS on the S3 bucket ensures all objects are encrypted at rest using AWS KMS-managed keys, satisfying the encryption requirement without relying on each uploader to set encryption headers. Option E is correct because an S3 bucket policy that allows access only from specific IAM roles enforces least-privilege authorization, ensuring that only the intended IAM principals can read or write the Parquet data. Option B is not required because server-side encryption with SSE-KMS already meets the encryption-at-rest requirement, and client-side encryption adds key-management complexity without being mandated. Option C is incorrect because S3 server access logging only records request activity for auditing; it does not control access or encrypt data. Option D is incorrect because bucket ACLs are legacy, coarse-grained access mechanisms and cannot express the fine-grained, role-based authorization that a bucket policy provides.

• A.Enable SSE-KMS on the S3 bucket in Account A and specify the ARN of the KMS key from Account B. S3 will automatically use the key.
• B.Update the KMS key policy in Account B to grant Account A access to the key. No changes needed in Account A.
• ✓ C.Update the KMS key policy in Account B to grant Account A access to the key, and update the S3 bucket policy in Account A to allow the kms:Encrypt and kms:Decrypt actions for the key.
• D.Update the S3 bucket policy in Account A to allow s3:PutObject with the kms:Encrypt permission. No changes needed in Account B.

Why C: When using an AWS KMS CMK from a different account (Account B) for SSE-KMS on an S3 bucket in Account A, you must explicitly grant Account A access to the key via the KMS key policy in Account B. Additionally, the S3 bucket policy in Account A must allow the kms:Encrypt and kms:Decrypt actions for the cross-account key, as S3 will use these permissions to encrypt and decrypt objects on behalf of the bucket owner. Without both policy updates, the cross-account KMS operation will fail with an access denied error.