Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
A
Best answer
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.
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.
B
Distractor review
In Company B's IAM policy, allow kms:Encrypt on Company A's KMS key ARN, without changing Company A's key policy.
KMS key policies govern access to the key; adding permissions in the caller account alone cannot override a restrictive key policy in the key owner account.
C
Distractor review
Create a new KMS key in Company B and configure Company A's S3 bucket to use that key for SSE-KMS.
Switching bucket ownership encryption to a partner key changes trust boundaries and operational ownership. It also doesn't directly resolve the original denial and can complicate key administration.
D
Distractor review
Disable key policy restrictions by setting the KMS key to enabled and removing all policy statements so that encryption automatically works for any principal.
Removing restrictions or effectively allowing all principals defeats security objectives and is not required for cross-account access. Key policies should be explicit and least-privilege.