easymultiple choiceObjective-mapped

A cross-account IAM role in Account B reads encrypted S3 objects from Account A. The objects use SSE-KMS with a customer-managed KMS key in Account A. Account B can successfully call s3:GetObject, but decryption fails with an AccessDeniedException from KMS. What change most directly fixes the issue?

Question 1easymultiple choice
Full question →

A cross-account IAM role in Account B reads encrypted S3 objects from Account A. The objects use SSE-KMS with a customer-managed KMS key in Account A. Account B can successfully call s3:GetObject, but decryption fails with an AccessDeniedException from KMS. What change most directly fixes the issue?

Answer choices

Why each option matters

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

Distractor review

Add kms:Decrypt only to the Account B role’s IAM policy, without changing the customer-managed KMS key policy in Account A.

For a customer-managed KMS key, KMS authorization is enforced by both the IAM identity policy (for the role) and the KMS key policy. If the key policy does not allow the Account B principal to use the key, kms:Decrypt will still be denied.

B

Distractor review

Update the Account A S3 bucket policy to grant kms:Decrypt to Account B.

S3 bucket policies control access to S3 operations (like s3:GetObject). They do not grant permissions to KMS for SSE-KMS decryption; KMS key policy or grants must allow kms:Decrypt.

C

Best answer

Update the customer-managed KMS key policy in Account A to allow kms:Decrypt for the specific Account B role principal.

With SSE-KMS, S3 calls KMS on your behalf during decryption. KMS checks the customer-managed key policy (and optionally grants). Allowing the Account B role principal in the KMS key policy for kms:Decrypt directly resolves KMS AccessDenied.

D

Distractor review

Enable KMS key rotation, which automatically allows cross-account decrypt permissions.

Key rotation changes key material over time but does not modify which principals are authorized to use the key. It does not grant kms:Decrypt permission to Account B.

Common exam trap

Common exam trap: authentication is not authorization

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

How to think about this question

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.

KKey Concepts to Remember

  • Authentication checks who the user is.
  • Authorization controls what the user is allowed to do after login.
  • Privilege levels affect access to EXEC and configuration commands.
  • AAA, TACACS+ and RADIUS can separate login success from command access.

TExam Day Tips

  • Do not assume successful login means full administrative access.
  • Look for words such as cannot enter configuration mode, privilege level, authorization or command access.
  • Separate login problems from permission problems before choosing the answer.

Related practice questions

Related SAA-C03 practice-question pages

Use these pages to review the topic behind this question. This is how one missed question becomes focused revision.

More questions from this exam

Keep practising from the same exam bank, or move into a focused topic page if this question exposed a weak area.

FAQ

Questions learners often ask

What does this SAA-C03 question test?

Authentication checks who the user is.

What is the correct answer to this question?

The correct answer is: Update the customer-managed KMS key policy in Account A to allow kms:Decrypt for the specific Account B role principal. — For SSE-KMS objects, the ability to decrypt depends on KMS authorization for the customer-managed key in Account A. Even if s3:GetObject succeeds, the decrypt step requires kms:Decrypt permission that must be granted by the KMS key policy (and/or grants) in Account A for the Account B role principal. Therefore, updating the KMS key policy to allow kms:Decrypt for the specific cross-account role is the most direct fix. Option A fails because KMS still requires the key policy to permit the cross-account principal to use the key. Option B is incorrect because bucket policies do not grant KMS usage permissions needed for SSE-KMS decryption. Option D is irrelevant to authorization; rotation does not change key usage permissions for other accounts.

What should I do if I get this SAA-C03 question wrong?

Then try more questions from the same exam bank and focus on understanding why the wrong options are tempting.

Discussion

Loading comments…

Sign in to join the discussion.