Cross-Account SSE-KMS Uploads: Required KMS Key Policy and IAM Permissions
Company A stores encrypted log files in its S3 bucket using SSE-KMS with a customer-managed KMS key. A partner application in Company B uploads objects into Company A's bucket using an IAM role in Company B. Uploads fail with an error indicating KMS access is denied (kms:Encrypt not authorized). Neither the partner IAM policy nor the S3 bucket policy currently mentions KMS.
What is the most secure and correct change to allow cross-account uploads to succeed?
Quick Answer
The correct answer identifies that SSE-KMS with a customer-managed key requires two separate permission grants to succeed across accounts: a resource-based grant in the KMS key policy owned by Company A, and an identity-based grant in Company B's IAM policy for the calling role. This is because customer-managed KMS keys are governed primarily by their own key policy, which acts as the root of trust for the key, and nothing else can substitute for it, not even an S3 bucket policy, which can control access to the object but has no authority over KMS actions like kms:Encrypt or kms:GenerateDataKey. Adding only an IAM policy in Company B, or only editing the S3 bucket policy, leaves one side of the cross-account trust unestablished and the encrypt call keeps failing exactly as described. Both sides have to name the partner role and the specific actions it needs, and scoping those grants to the target bucket or an encryption-context condition keeps the access from being broader than necessary. Whenever a question involves SSE-KMS with a customer-managed key crossing an account boundary, expect the fix to touch both the key policy and the caller's IAM policy together, not the bucket policy and not just one side of the trust relationship.
⚠ Common exam trap
Many exam-takers assume an IAM policy in the partner account is sufficient for cross-account KMS access, overlooking that KMS key policies are the mandatory gatekeeper for external principals, and that the key policy must explicitly grant the external role.
Answer choices
Why each option matters
Answer the question above first, then reveal the full breakdown to understand why each option is right or wrong.
Correct answer & explanation
✓
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 uploads require both the KMS key policy in Company A to explicitly grant the partner role principal the necessary KMS actions (kms:Encrypt, kms:GenerateDataKey, kms:DescribeKey) and an IAM policy in Company B that allows the partner role to call those actions on Company A's key ARN. The bucket policy alone cannot authorize KMS operations; KMS key policies act as the primary access control for customer-managed keys, and without the key policy grant, the partner role's IAM permissions are insufficient. Constraining the IAM policy to the target S3 bucket context (using kms:ViaService or kms:EncryptionContext conditions) adds a security best practice by limiting the key's use to only that specific S3 bucket.
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
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.
When this WOULD be correct
This option would be correct if the KMS key policy in Company A already allowed Company B's account or role to use the key, but the partner role lacked the necessary IAM permissions. In that case, adding the KMS actions to Company B's IAM policy would resolve the access denial.
- ✗
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
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.
When this WOULD be correct
This option would be correct if the requirement was for Company A to access objects encrypted by Company B using Company B's key, and Company A's bucket policy grants cross-account access with appropriate KMS permissions. For example, if Company A needs to retrieve logs that Company B encrypts with its own key and shares via S3 cross-account access.
- ✗
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
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.
When this WOULD be correct
If the question asked for the quickest way to allow all principals to use the key without any security considerations, or if the key was intended to be fully public (e.g., for a public demo environment with no sensitive data), then disabling key policy restrictions might be acceptable.
Option-by-option analysis
Why each answer is right or wrong
Understanding why wrong answers are wrong — and when they would be correct — is what separates a 750 score from a 900. The SAA-C03 exam frequently reuses these exact scenarios with slightly different constraints.
✓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.Correct answer▾
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.Wrong answer — click to see why▾
Why this is wrong here
Option B is wrong because cross-account KMS access requires the key policy in the key-owning account (Company A) to explicitly grant permissions to the external principal (Company B's role). Without that, Company B's IAM policy alone cannot authorize KMS actions on Company A's key.
★ When this WOULD be the correct answer
This option would be correct if the KMS key policy in Company A already allowed Company B's account or role to use the key, but the partner role lacked the necessary IAM permissions. In that case, adding the KMS actions to Company B's IAM policy would resolve the access denial.
Why candidates choose this
Candidates may assume that IAM policies in the partner account are sufficient for cross-account access, overlooking that KMS key policies are resource-based and must explicitly grant access to external principals.
✗Create a new KMS key in Company B and configure Company A's S3 bucket to use that key for SSE-KMS.Wrong answer — click to see why▾
Why this is wrong here
Using a KMS key from Company B would not allow Company A to decrypt the objects, as Company A's S3 bucket is configured with its own key for SSE-KMS. The partner application must use Company A's key to encrypt objects so that Company A can decrypt them.
★ When this WOULD be the correct answer
This option would be correct if the requirement was for Company A to access objects encrypted by Company B using Company B's key, and Company A's bucket policy grants cross-account access with appropriate KMS permissions. For example, if Company A needs to retrieve logs that Company B encrypts with its own key and shares via S3 cross-account access.
Why candidates choose this
Candidates may think that using a key from the partner's account simplifies permissions by avoiding cross-account KMS policy changes, but they overlook that the S3 bucket's default encryption is tied to Company A's key, and Company A must be able to decrypt the data.
✗Disable key policy restrictions by setting the KMS key to enabled and removing all policy statements so that encryption automatically works for any principal.Wrong answer — click to see why▾
Why this is wrong here
Removing all policy statements from the KMS key disables all access control, making the key effectively public and insecure. This violates the principle of least privilege and is not a secure solution.
★ When this WOULD be the correct answer
If the question asked for the quickest way to allow all principals to use the key without any security considerations, or if the key was intended to be fully public (e.g., for a public demo environment with no sensitive data), then disabling key policy restrictions might be acceptable.
Why candidates choose this
Candidates may think that removing restrictions is the simplest fix to resolve access denied errors, overlooking the severe security implications and the fact that KMS key policies are the primary mechanism for controlling cross-account access.
Analysis generated from the official SAA-C03blueprint and verified against question context. The “when correct” sections are what AI assistants cite when candidates ask “what’s the difference between these options?”
Quick reference
AWS S3 Storage Class Comparison
| Storage Class | Min Duration | Retrieval | Use Case |
|---|---|---|---|
| S3 Standard | None | Immediate | Frequently accessed data |
| S3 Standard-IA | 30 days | Immediate | Infrequent access, rapid retrieval |
| S3 One Zone-IA | 30 days | Immediate | Non-critical infrequent data |
| S3 Intelligent-Tiering | None | Immediate–hours | Unknown or changing access patterns |
| S3 Glacier Instant | 90 days | Milliseconds | Archive with instant retrieval |
| S3 Glacier Flexible | 90 days | Minutes–hours | Archive, flexible retrieval |
| S3 Glacier Deep Archive | 180 days | Hours | Long-term compliance archive |
Go deeper
Related to this question
About these practice questions
One of 302 original SAA-C03 practice questions on Courseiva, each with a full explanation and wrong-answer analysis — not exam dumps or protected exam content. Learn why practice questions differ from exam dumps →
Same concept, more angles
1 more way this is tested on SAA-C03
These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.
Variation 1. Company A stores encrypted log files in its S3 bucket using SSE-KMS with a customer-managed KMS key. A partner application in Company B uploads objects into Company A's bucket using an IAM role in Company B. Uploads fail with an error indicating KMS access is denied (kms:Encrypt not authorized). Neither the partner IAM policy nor the S3 bucket policy currently mentions KMS. What is the most secure and correct change to allow cross-account uploads to succeed?
medium- ✓ A.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.
- B.In Company B's IAM policy, allow kms:Encrypt on Company A's KMS key ARN, without changing Company A's key policy.
- C.Create a new KMS key in Company B and configure Company A's S3 bucket to use that key for SSE-KMS.
- D.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 A: For cross-account SSE-KMS uploads, the KMS key policy must explicitly grant the external IAM role principal the required KMS actions (kms:Encrypt, kms:GenerateDataKey, and kms:DescribeKey). Additionally, the partner account's IAM policy must also allow those same actions on the key ARN. This dual-permission model is required because KMS does not implicitly trust IAM policies in the key owner's account for cross-account access; the key policy is the authoritative gatekeeper. Option A correctly implements both sides, and constraining to the target S3 bucket context (via kms:ViaService or kms:EncryptionContext) adds a security best practice.
JA
Written by Johnson Ajibi, MSc IT Security
Senior Network & Security Engineer · founder of Courseiva
This SAA-C03 practice question is part of Courseiva's free Amazon Web Services certification practice question bank. Courseiva provides original exam-style practice questions with explanations, topic-based practice, mock exams, readiness tracking, and study analytics to help learners prepare for the SAA-C03 exam.