An application in Account B (IAM role arn:aws:iam::account-b:role/app-read) reads objects from an S3 bucket in Account A. The bucket uses SSE-KMS with a customer-managed KMS key in Account A. Object reads consistently fail with an error that includes "AccessDenied" and "kms:Decrypt".
The IAM permissions in Account B for kms:Decrypt are correct, but the requests still fail.
Which change will most directly fix the failure?
Answer choices
Good practice is not just finding the correct option. The wrong answers often show the exact trap the exam wants you to fall into.
Add kms:Decrypt to the KMS key policy in Account A for the Account B role arn:aws:iam::account-b:role/app-read, and remove kms:Decrypt from the role policy in Account B.
Adding kms:Decrypt to the KMS key policy is a valid approach, but removing kms:Decrypt from the role policy is not required to fix an AccessDenied kms:Decrypt failure. KMS authorization requires both (1) identity policy permission (in Account B) and (2) the KMS key policy permission (in Account A). Removing the role permission can cause the failure to continue or move to a different authorization denial.
Update the IAM role in Account B to use the s3:GetObject permission only, and rely on S3 to authorize KMS decrypt automatically.
S3 authorization to call GetObject does not eliminate the need for KMS permissions to call kms:Decrypt. For SSE-KMS, the GetObject request ultimately requires kms:Decrypt in KMS, which is authorized by both the caller’s IAM permissions and the KMS key policy.
Modify the KMS key policy in Account A to allow kms:Decrypt for the Account B role arn:aws:iam::account-b:role/app-read, using the appropriate cross-account conditions (for example, allowing the use via S3 and the expected encryption context for the bucket).
For SSE-KMS, S3 must call KMS Decrypt when serving objects. KMS authorization is evaluated against the KMS key policy in Account A in addition to the identity policy in Account B. If the error includes kms:Decrypt AccessDenied in a cross-account scenario, the most direct fix is to update the KMS key policy to allow the Account B role to use the key for decrypt (often with conditions tied to S3 usage and the specific bucket/object encryption context).
Switch the S3 bucket encryption from SSE-KMS to SSE-S3, keeping all existing IAM and KMS configuration unchanged.
Changing to SSE-S3 avoids KMS decryption entirely, so it could remove the kms:Decrypt failure. However, that is not a targeted fix for the underlying authorization issue and conflicts with the stated requirement of using the existing customer-managed KMS key for SSE-KMS.
Common exam trap
Logging in proves the user can authenticate. It does not automatically mean the user is allowed to enter privileged or configuration mode. Watch for AAA authorization, privilege level and command authorization details.
Technical deep dive
This kind of question is testing the difference between identity and permission. A user may successfully log in to a router because authentication is working, but still fail to enter configuration mode because authorization is missing, misconfigured or mapped to a lower privilege level.
Related practice questions
Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.
Practise SAA-C03 questions linked to SAA-C03 VPC.
Practise SAA-C03 questions linked to SAA-C03 S3 lifecycle policy questions.
Practise SAA-C03 questions linked to SAA-C03 RDS Multi-AZ questions.
Practise SAA-C03 questions linked to SAA-C03 IAM policy.
Practise SAA-C03 questions linked to SAA-C03 Route 53 failover questions.
Practise SAA-C03 questions linked to SAA-C03 CloudFront.
Practise SAA-C03 questions linked to SAA-C03 NAT gateway questions.
Practise SAA-C03 questions linked to SAA-C03 VPC endpoint questions.
Practise SAA-C03 questions linked to SAA-C03 Auto Scaling.
Practise SAA-C03 questions linked to SAA-C03 disaster recovery questions.
Practise SAA-C03 questions linked to SAA-C03 high availability questions.
Practise SAA-C03 questions linked to SAA-C03 cost optimization questions.
Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.
Question 1
Question 2
Question 3
Question 4
Question 5
Question 6
FAQ
Authentication checks who the user is.
The correct answer is: Modify the KMS key policy in Account A to allow kms:Decrypt for the Account B role arn:aws:iam::account-b:role/app-read, using the appropriate cross-account conditions (for example, allowing the use via S3 and the expected encryption context for the bucket). — With SSE-KMS, an S3 GetObject request causes S3 to call KMS Decrypt to read the object. Even when the IAM role in Account B has an identity policy that allows kms:Decrypt, KMS still evaluates the KMS key policy in Account A. In cross-account scenarios, AccessDenied for kms:Decrypt typically means the KMS key policy does not allow the external principal (the Account B role) to use the key for decrypt, possibly under the expected S3 encryption context/usage conditions. Updating the KMS key policy to explicitly permit kms:Decrypt for arn:aws:iam::account-b:role/app-read resolves the authorization path that is currently blocked. Why others are wrong: A is not the best fix because it removes a required permission from the caller’s identity policy. Even if the key policy is updated, removing kms:Decrypt from Account B can still block KMS. B is incorrect because S3 GetObject does not grant KMS Decrypt; KMS checks both identity and key policy. D bypasses the failure by changing encryption, but it does not directly address the secure, least-change root cause (KMS key policy authorization) and may not meet compliance requirements.
Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.
Sign in to join the discussion.