DEA-C01 Practice Question 19: Cross Account KMS Key Policy

Reading an SSE-KMS object needs two separate authorizations. S3 must allow s3:GetObject, and the caller must have "kms:Decrypt permissions for the key", because S3 sends the object's encrypted data key to AWS KMS to decrypt. The pattern of symptoms narrows it down. ListBucket works and GetObject fails, so the S3 permissions are fine and the failure is in the KMS step. For cross-account use of a KMS key, AWS KMS is explicit: "Cross-account access requires permission in the key policy of the KMS key and in an IAM policy in the external user's account", and "neither the key policy nor the IAM policy alone is sufficient". Account B has done its half with the IAM policy. The key policy in Account A never names Account B, so KMS denies the decrypt. The fix is a key policy statement that allows the role (or Account B, which then delegates through IAM) to call kms:Decrypt.

Option C puts the permission in the wrong policy. A bucket policy is a resource policy on S3 resources and is evaluated by S3. AWS KMS makes its own decision based on the key policy (plus IAM and grants), so a KMS action written into a bucket policy has no effect on the Decrypt call.

Option A is a cost feature. An S3 Bucket Key cuts the number of requests S3 makes to AWS KMS, but those requests still need permission to use the same customer managed key. It does not grant any access.

Option D makes cross-account sharing impossible rather than easier. The S3 documentation notes that objects encrypted with AWS managed keys "can't be shared cross-account", and that cross-account access to SSE-KMS data requires a customer managed key whose policy can grant the other account.

References: Allowing users in other accounts to use a KMS key; Using server-side encryption with AWS KMS keys (SSE-KMS)