SAA-C03 Design Secure Architectures Practice Question
Company A runs an internal app in account A. The app needs to upload objects to an S3 bucket in account B. When the app calls S3, it receives AccessDenied for s3:PutObject. The team already created an IAM role in account B named UploadRole with a policy allowing s3:PutObject. They did not yet set up any trust relationship. Which change most directly fixes the access problem with least privilege?
⚠ Common exam trap
Candidates often think bucket policies alone can solve cross-account access, but without a trust policy on the IAM role, the app cannot assume the role to obtain the required permissions.
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
✓
Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A.
The app in account A needs to assume the UploadRole in account B to gain s3:PutObject permissions. Without a trust policy on UploadRole that allows sts:AssumeRole from the app's IAM principal in account A, the role cannot be assumed, resulting in AccessDenied. Updating the trust policy directly establishes the cross-account trust relationship with least privilege, as it grants only the necessary assume-role capability.
Answer analysis
Option-by-option breakdown
For each option: why learners choose it and why it is or isn't the right answer here.
- ✗
Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.
Why it's wrong here
Using static access keys increases risk and bypasses role-based trust controls. It also does not leverage the existing role in account B. Attaching account B permissions directly to account A identities is typically not least-privilege for cross-account access.
When this WOULD be correct
If the question asked for a solution where a single IAM user in account A needs to upload objects to an S3 bucket in account B without using roles, and the bucket policy allows access based on user ARN, then creating access keys for that user and attaching the necessary permissions would be correct.
- ✓
Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A.
Why this is correct
A cross-account role requires both an IAM permissions policy and a trust policy. The trust policy must allow the specific principal in account A to call sts:AssumeRole into account B’s role. With that trust in place, the app can obtain temporary credentials and then use the UploadRole permissions for s3:PutObject.
- ✗
Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.
Why it's wrong here
Bucket policies can grant access, but granting broadly to account A principals is harder to keep least-privileged. It also does not address that sts:AssumeRole must be authorized for the app to use the intended role. This option ignores the missing trust relationship root cause.
When this WOULD be correct
This option would be correct if the question stated that the app in account A uses an IAM user with programmatic access keys (not a role) and the requirement is to allow that user to write to the bucket without assuming a role, using a bucket policy that grants access to the entire account A.
- ✗
Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.
Why it's wrong here
An SCP can restrict actions at the organization level, but it won’t fix the current AccessDenied stemming from missing trust. If MFA enforcement is needed, it should be reflected in an appropriate condition in the trust policy, not as the primary missing permission.
When this WOULD be correct
An SCP denying sts:AssumeRole unless MFA is used would be correct in a question where an organization wants to enforce MFA for all cross-account role assumptions, and the issue is that a role is being assumed without MFA.
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.
✓Update the trust policy on UploadRole (account B) to allow sts:AssumeRole from the app’s IAM role or principal in account A.Correct answer▾
Why this is correct
A cross-account role requires both an IAM permissions policy and a trust policy. The trust policy must allow the specific principal in account A to call sts:AssumeRole into account B’s role. With that trust in place, the app can obtain temporary credentials and then use the UploadRole permissions for s3:PutObject.
✗Create IAM user access keys in account A and attach the UploadRole policy directly to those keys.Wrong answer — click to see why▾
Why this is wrong here
IAM user access keys are long-term credentials and do not solve cross-account access; the app in account A needs to assume a role in account B, not use a user with a policy attached directly.
★ When this WOULD be the correct answer
If the question asked for a solution where a single IAM user in account A needs to upload objects to an S3 bucket in account B without using roles, and the bucket policy allows access based on user ARN, then creating access keys for that user and attaching the necessary permissions would be correct.
Why candidates choose this
Candidates may think that attaching a policy to access keys is a straightforward way to grant permissions, overlooking the cross-account nature of the problem and the need for role assumption.
✗Add s3:PutObject permissions to the bucket policy in account B for all principals in account A.Wrong answer — click to see why▾
Why this is wrong here
Option C grants s3:PutObject to all principals in account A, which violates least privilege by not restricting to the specific app role, and it does not address the missing trust relationship needed for cross-account access via role assumption.
★ When this WOULD be the correct answer
This option would be correct if the question stated that the app in account A uses an IAM user with programmatic access keys (not a role) and the requirement is to allow that user to write to the bucket without assuming a role, using a bucket policy that grants access to the entire account A.
Why candidates choose this
Candidates may think a bucket policy is the simplest way to grant cross-account S3 access, overlooking that the app's IAM role still needs explicit permission to assume a role in account B, and that a bucket policy alone does not replace the need for a trust relationship.
✗Attach an SCP (service control policy) in AWS Organizations to deny sts:AssumeRole unless the caller uses an MFA device.Wrong answer — click to see why▾
Why this is wrong here
The problem is lack of cross-account trust, not an SCP. SCPs deny actions at the OU/account level but don't grant permissions; they would only block access if already allowed, and here no trust exists.
★ When this WOULD be the correct answer
An SCP denying sts:AssumeRole unless MFA is used would be correct in a question where an organization wants to enforce MFA for all cross-account role assumptions, and the issue is that a role is being assumed without MFA.
Why candidates choose this
Candidates may confuse SCPs with IAM policies or think that any denial of access can be fixed by adding a deny statement, not realizing SCPs are a guardrail, not a solution for missing trust relationships.
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 302-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.