SAA-C03 Design Secure Architectures Practice Question
A reporting application in Account B must read files from an S3 bucket in Account A. The bucket contains objects encrypted with a customer managed KMS key in Account A. The application role in Account B already has an identity policy allowing s3:GetObject on the bucket prefix, but requests still fail with AccessDenied. Which two changes are required for the application to read the objects? Select two.
⚠ Common exam trap
It's easy for candidates to assume a cross-account IAM role with s3:GetObject permission is sufficient, overlooking that S3 bucket policies and KMS key policies are separate authorization layers that must explicitly allow the external principal, especially when objects are encrypted with a customer managed KMS key.
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 a bucket policy in Account A that allows the Account B role to perform s3:GetObject on the required prefix.
Cross-account S3 access requires the destination account (Account A) to explicitly grant access via a bucket policy that allows the source account's role (Account B) to perform s3:GetObject on the specified prefix. Without this bucket policy, the S3 service in Account A will deny the request, even if the IAM identity policy in Account B permits the action. Option B is correct because the objects are encrypted with a customer managed KMS key in Account A; the application role in Account B must be added to the KMS key policy with kms:Decrypt permission to decrypt the objects during retrieval. Both the S3 bucket policy and the KMS key policy are required for cross-account encrypted access.
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 a bucket policy in Account A that allows the Account B role to perform s3:GetObject on the required prefix.
Why this is correct
Cross-account S3 access requires a resource-based permission on the bucket. The bucket policy must explicitly allow the external role to read the needed prefix, otherwise the bucket owner blocks the request even if the role's identity policy allows it.
- ✓
Add the Account B role to the KMS key policy in Account A with permission to use kms:Decrypt.
Why this is correct
Because the objects use SSE-KMS, S3 must be able to decrypt them with the customer managed key. The external role needs authorization in the KMS key policy, or the decrypt step fails even when S3 access is allowed.
- ✗
Attach an IAM policy in Account B that grants s3:* on the bucket and its objects.
Why it's wrong here
An identity policy in Account B alone cannot authorize access to a bucket in another account. S3 also requires a matching resource policy or equivalent cross-account trust, and broad s3:* is unnecessary for least privilege.
When this WOULD be correct
This option would be correct if the application role in Account B did not already have the necessary S3 permissions, and the question asked for a single-account setup where the bucket and role are in the same account, requiring only IAM policy updates.
- ✗
Create an S3 gateway endpoint in Account B so the application can reach the bucket privately.
Why it's wrong here
An S3 gateway endpoint is a networking feature that provides private connectivity from Account B's VPC to S3, but it does not grant any data-plane authorization. The AccessDenied error occurs because the bucket policy and KMS key policy in Account A do not yet permit the external role, not because traffic traverses the public internet. Even with the endpoint configured, S3 will still evaluate the bucket policy and KMS key policy and deny the request if the role lacks s3:GetObject and kms:Decrypt permissions, so this option does not address the root cause.
When this WOULD be correct
A question where an application in a VPC cannot reach S3 due to public internet routing restrictions (e.g., no NAT gateway, no internet gateway) and the bucket is in the same region. Adding an S3 Gateway Endpoint would provide private connectivity.
- ✗
Add an SCP in Account A that allows the Account B role to bypass KMS encryption checks.
Why it's wrong here
Service control policies (SCPs) are guardrails applied at the AWS Organizations account or OU level that limit the maximum permissions for principals within that account; they can only restrict, never grant, permissions to an external role. An SCP in Account A cannot authorize an Account B role to bypass KMS encryption checks because KMS decisions are always governed by the key policy in Account A, and SCPs do not override that policy. To fix the encryption failure, the Account B role must be explicitly added to the KMS key policy with kms:Decrypt, alongside the bucket policy for s3:GetObject, so this option is both conceptually and technically incorrect.
When this WOULD be correct
An SCP would be correct in a question where an organization wants to prevent all accounts from disabling encryption on S3 buckets, and the correct action is to add an SCP that denies s3:PutBucketEncryption or similar actions to enforce encryption requirements.
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.
✓Add a bucket policy in Account A that allows the Account B role to perform s3:GetObject on the required prefix.Correct answer▾
Why this is correct
Cross-account S3 access requires a resource-based permission on the bucket. The bucket policy must explicitly allow the external role to read the needed prefix, otherwise the bucket owner blocks the request even if the role's identity policy allows it.
✗Attach an IAM policy in Account B that grants s3:* on the bucket and its objects.Wrong answer — click to see why▾
Why this is wrong here
The application role in Account B already has an identity policy allowing s3:GetObject on the bucket prefix, so adding another IAM policy granting s3:* is redundant and does not address the cross-account permission issue or the KMS key policy requirement.
★ When this WOULD be the correct answer
This option would be correct if the application role in Account B did not already have the necessary S3 permissions, and the question asked for a single-account setup where the bucket and role are in the same account, requiring only IAM policy updates.
Why candidates choose this
Candidates may think that granting broader S3 permissions (s3:*) will override any missing permissions, not realizing the core issue is cross-account access and KMS key policy, not insufficient IAM permissions in Account B.
✗Create an S3 gateway endpoint in Account B so the application can reach the bucket privately.Wrong answer — click to see why▾
Why this is wrong here
The error is AccessDenied, not connectivity issues. S3 Gateway Endpoints only provide private network access to S3, but do not grant IAM permissions or resolve KMS decryption authorization failures.
★ When this WOULD be the correct answer
A question where an application in a VPC cannot reach S3 due to public internet routing restrictions (e.g., no NAT gateway, no internet gateway) and the bucket is in the same region. Adding an S3 Gateway Endpoint would provide private connectivity.
Why candidates choose this
Candidates may confuse network connectivity problems with authorization failures, assuming that a private endpoint can bypass IAM or KMS permission issues.
✗Add an SCP in Account A that allows the Account B role to bypass KMS encryption checks.Wrong answer — click to see why▾
Why this is wrong here
SCPs (Service Control Policies) cannot grant permissions; they only restrict permissions. Additionally, SCPs cannot bypass KMS encryption checks; the KMS key policy must explicitly allow the Account B role to use kms:Decrypt.
★ When this WOULD be the correct answer
An SCP would be correct in a question where an organization wants to prevent all accounts from disabling encryption on S3 buckets, and the correct action is to add an SCP that denies s3:PutBucketEncryption or similar actions to enforce encryption requirements.
Why candidates choose this
Candidates may confuse SCPs with resource policies or think SCPs can grant cross-account access, or they may misunderstand that SCPs can override KMS permissions, leading them to select this option as a shortcut to fix the access issue.
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
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 →
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.