SAA-C03 Design Secure Architectures Practice Question
An application in Account B reads objects from an Amazon S3 bucket in Account A. The bucket uses SSE-KMS with a customer managed key in Account A. The role in Account B already has s3:GetObject, but downloads fail with AccessDenied on decrypt. Which two changes are required for the role to read the object successfully? Select two.
⚠ Common exam trap
Test-takers frequently think only the IAM policy (Option B) is needed, forgetting that cross-account KMS access requires the key policy (Option C) to explicitly grant the external role decrypt permission, as IAM policies alone are insufficient for resource-based policies like KMS key policies.
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
✓
Add kms:Decrypt permission in the role's IAM policy for the KMS key.
The role in Account B needs explicit kms:Decrypt permission in its IAM policy to use the KMS key for decrypting the S3 objects. Option C is correct because the KMS key policy in Account A must grant the role from Account B permission to call kms:Decrypt, as the key is customer managed and cross-account access requires both the key policy and the IAM policy to allow the action.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Add an SCP that grants the role additional permissions for KMS usage.
Why it's wrong here
Service control policies (SCPs) act as permission boundaries in AWS Organizations; they can only restrict the maximum available permissions for an account or OU, never grant new permissions. Adding an SCP cannot 'grant' the role additional KMS usage rights because SCPs are evaluated as deny filters, not as allow statements. The actual failure occurs because the role lacks an explicit kms:Decrypt allow in its identity-based policy, and the KMS key policy lacks a cross-account grant—SCP changes do not address either of those required authorization components.
- ✓
Add kms:Decrypt permission in the role's IAM policy for the KMS key.
Why this is correct
To successfully read an SSE-KMS-encrypted S3 object from another account, the IAM role must have an explicit kms:Decrypt permission on the customer master key (CMK) that encrypted the object. Without this identity-based allow, KMS returns an AccessDenied error even if S3 GetObject is permitted by bucket policy or ACL. The KMS key policy in Account A must also explicitly allow the role (or Account B) to call kms:Decrypt; both the key policy and the identity policy must be satisfied for KMS to authorize the decryption.
- ✓
Update the KMS key policy in Account A to allow the role from Account B to use Decrypt.
Why this is correct
For cross-account SSE-KMS access, the CMK policy in the owning account must trust the external principal or an authorized account path. KMS evaluates both the identity policy and the key policy, so both must allow the operation.
- ✗
Grant the role read access with an S3 bucket ACL.
Why it's wrong here
An ACL can affect S3 object authorization, but it does not grant permission to use the KMS key. The failure is at the decrypt step, so changing the ACL alone does not resolve the access denied error.
- ✗
Enable S3 Transfer Acceleration on the bucket.
Why it's wrong here
S3 Transfer Acceleration uses AWS edge locations to speed up uploads and downloads over the public internet by routing traffic through optimized network paths; it has no effect on authorization decisions. The AccessDenied error occurs during the KMS decrypt step, when S3 calls KMS to decrypt the object's envelope key, and Transfer Acceleration does not alter IAM policies, KMS key policies, or S3 permissions. Therefore, enabling it cannot resolve a missing kms:Decrypt permission and is irrelevant to the root cause of this cross-account encryption failure.
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
This SAA-C03 question is part of Courseiva's 935-question bank — original exam-style content with full explanations and wrong-answer analysis, never real exam questions or exam dumps. Learn why practice questions differ from exam dumps →
Same concept, more angles
4 more ways 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. Based on the exhibit, an application role in Account B can reach an S3 bucket in Account A, but reads fail with AccessDenied on KMS. The bucket objects use SSE-KMS with a customer managed key in Account A. What change is required so the application can decrypt the objects while keeping the access restricted?
hard- ✓ A.Add the Account B role ARN to the KMS key policy with kms:Decrypt and kms:DescribeKey permissions, scoped to S3 usage in us-east-1.
- B.Add s3:GetEncryptionConfiguration to the Account B IAM policy so S3 can use the customer managed key on reads.
- C.Change the bucket to SSE-S3 because SSE-S3 always allows cross-account reads without any KMS policy changes.
- D.Add the Account B role to the bucket ACL with FULL_CONTROL so S3 can bypass KMS on behalf of the reader.
Why A: When using SSE-KMS with a customer managed key, cross-account access requires the KMS key policy to explicitly grant the external IAM role (from Account B) the kms:Decrypt and kms:DescribeKey permissions. Without these, S3 can retrieve the encrypted object, but KMS will deny the decryption request, resulting in an AccessDenied error. Scoping the policy to S3 usage in us-east-1 follows the principle of least privilege while enabling the necessary decryption.
Variation 2. 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?
medium- A.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.
- B.Update the IAM role in Account B to use the s3:GetObject permission only, and rely on S3 to authorize KMS decrypt automatically.
- ✓ C.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).
- D.Switch the S3 bucket encryption from SSE-KMS to SSE-S3, keeping all existing IAM and KMS configuration unchanged.
Why C: When using SSE-KMS with a customer-managed KMS key in a cross-account scenario, the KMS key policy must explicitly grant the external IAM role (arn:aws:iam::account-b:role/app-read) permission to perform kms:Decrypt. Even if the IAM role in Account B has the correct kms:Decrypt permission, the KMS key policy in Account A acts as a resource-based policy that must also allow the cross-account principal. Without this, the KMS service denies the decrypt request, resulting in the 'AccessDenied' error.
Variation 3. 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?
easy- A.Add kms:Decrypt only to the Account B role’s IAM policy, without changing the customer-managed KMS key policy in Account A.
- B.Update the Account A S3 bucket policy to grant kms:Decrypt to Account B.
- ✓ C.Update the customer-managed KMS key policy in Account A to allow kms:Decrypt for the specific Account B role principal.
- D.Enable KMS key rotation, which automatically allows cross-account decrypt permissions.
Why C: SSE-KMS with a customer-managed KMS key requires explicit permission to use the key for decryption. The S3 GetObject call succeeds because the bucket policy allows it, but KMS decryption fails because the KMS key policy in Account A does not grant kms:Decrypt to the IAM role principal in Account B. Updating the KMS key policy to allow the Account B role principal to call kms:Decrypt directly resolves the AccessDeniedException.
Variation 4. Account B has an IAM role that includes kms:Decrypt for a specific KMS key ARN in account A. However, when the role tries to read an S3 object encrypted with that CMK, the application fails with AccessDenied: not authorized to perform kms:Decrypt. CloudTrail shows the KMS API call is denied by key policy. What is the most secure and correct fix?
medium- A.Update the IAM role in account B to include kms:Encrypt and kms:GenerateDataKey; then kms:Decrypt will start working automatically.
- ✓ B.Update the KMS key policy in account A to allow the account B role principal to use kms:Decrypt on the key.
- C.Disable key policy for the CMK by switching to S3-managed encryption, because KMS key policies are always enforced regardless of grants.
- D.Create an SCP in account A that allows kms:Decrypt for all accounts, avoiding changes to the key policy.
Why B: Cross-account access to a customer managed KMS key (CMK) requires the key policy to explicitly grant the external IAM role principal the necessary permissions (e.g., kms:Decrypt). Even if the IAM role in Account B has an IAM policy allowing kms:Decrypt, the KMS key policy in Account A acts as a resource-based policy that must also allow the action; without this, the request is denied by the key policy, as shown in CloudTrail.
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.