SAA-C03 Practice Question 41: KMS Key Policy Cross Account
AWS Certified Solutions Architect – Associate (SAA-C03) · Test 5 · question 1 of 10
Account A stores objects in an S3 bucket encrypted with a customer managed AWS KMS key in Account A. A data science role in Account B has been granted s3:GetObject on the bucket through the bucket policy, and its identity policy allows kms:Decrypt on the key's ARN. Requests from Account B still fail with an access denied error referring to the KMS key.
What is missing?
Show answer and explanation
Answer:
A KMS key is protected by its own resource-based policy, and cross-account access requires permission from both sides. The key policy in the owning account must grant the external principal (or its account, with the caller's identity policy narrowing it) permission to use the key, and the caller's identity policy must allow the same action. Account B has only its half. Adding the grant to the key policy in Account A supplies the missing half and the decrypt succeeds, which is why the error names the key rather than the bucket.
Option A is false and would weaken the design. SSE-KMS objects are readable across accounts once the key policy permits it; switching to SSE-S3 gives up the audit trail and access control the customer managed key provides.
Option B breaks the encryption model. An object is decrypted with the key it was encrypted under, so a new key in Account B cannot read existing objects, and S3 cannot be pointed at a key the bucket's account cannot use for new writes.
Option C addresses object-level authorisation that is already satisfied and is the legacy mechanism. The bucket policy already grants s3:GetObject; the failure is at the KMS layer, which ACLs do not touch.
Reference: Key policies in AWS KMS