Cross-Account SSE-KMS Uploads: Required KMS Key Policy and IAM Permissions

Answer analysis

Option-by-option breakdown

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

• ✓

  In Company A's KMS key policy, allow Company B's partner role principal to use the key for kms:Encrypt, kms:GenerateDataKey, and kms:DescribeKey, and also add a matching IAM policy in Company B that grants the partner role those same KMS actions on Company A's key ARN, constrained to the target S3 bucket context when possible.

  Why this is correct

  Cross-account SSE-KMS requires both the KMS key policy in the key owner account and an IAM policy in the caller account to allow the required KMS actions. Scoping the permissions to the specific bucket or encryption context reduces blast radius.

• ✗

  In Company B's IAM policy, allow kms:Encrypt on Company A's KMS key ARN, without changing Company A's key policy.

  Why it's wrong here

  Adding only an IAM policy in Company B cannot grant access to Company A's KMS key because KMS key policies are the ultimate authority for cross-account access. Unless Company A's key policy includes an explicit Allow statement granting the external principal (or account) the required actions, the request will fail even if Company B's IAM policy permits it. Additionally, the IAM policy alone would need to cover kms:GenerateDataKey and kms:DescribeKey, not just kms:Encrypt, since S3 SSE-KMS uses GenerateDataKey to obtain a plaintext key.

• ✗

  Create a new KMS key in Company B and configure Company A's S3 bucket to use that key for SSE-KMS.

  Why it's wrong here

  Creating a new KMS key in Company B and reconfiguring Company A's bucket to use it would not resolve the original denial; it would instead change the trust boundary and operational ownership. The original issue remains: Company A's existing key policy denies access, and simply switching keys does not address that. Moreover, cross-account usage of a key owned by Company B would require Company A's bucket policy and Company B's key policy to be mutually permissive, adding complexity and potentially violating security requirements if the bucket must remain under Company A's control.

• ✗

  Disable key policy restrictions by setting the KMS key to enabled and removing all policy statements so that encryption automatically works for any principal.

  Why it's wrong here

  Disabling key policy restrictions by removing all statements would make the key effectively unusable because with no Allow statements, no principal has permission—the default behavior is implicit denial. Even if the intent was to allow all principals, that would be an insecure and non-least-privilege approach, exposing the key to any AWS account. The correct fix is to add a scoped, explicit Allow in the key policy for the partner role, not to gut the policy entirely or rely on the key being enabled.

Go deeper

Related to this question