mediummultiple choiceObjective-mapped

Exhibit

Cross-account access attempt:

Account A:
- EC2 instance profile role: arn:aws:iam::111122223333:role/AppRole
- Identity policy allows s3:GetObject on arn:aws:s3:::shared-data-bucket/*

Account B:
- Bucket policy currently allows the account root principal only
- Application log shows: AccessDenied when calling GetObject on shared-data-bucket
- Security requirement: no static credentials; access must be revocable centrally

Based on the exhibit, what is the most appropriate fix so the workload in Account A can access the S3 bucket in Account B without using long-lived access keys?

Question 1mediummultiple choice
Full question →

Based on the exhibit, what is the most appropriate fix so the workload in Account A can access the S3 bucket in Account B without using long-lived access keys?

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

Best answer

Create an IAM role in Account B, trust Account A's AppRole to assume it with STS, and then access the bucket using temporary credentials.

Assuming a role in the target account is a clean cross-account pattern that uses temporary credentials instead of static keys. The trust policy in Account B controls who may assume the role, and the role in B can then be given the exact S3 permissions needed. This is easy to revoke centrally by changing the trust relationship or role policy.

B

Distractor review

Attach AmazonS3FullAccess to the instance profile role in Account A and keep using the same direct access path.

This broadens permissions in the source account but does not solve the cross-account trust and resource authorization model cleanly.

C

Distractor review

Add an SCP to Account A that allows S3 actions against buckets in Account B.

SCPs restrict permissions within AWS Organizations but do not grant cross-account access to a bucket.

D

Distractor review

Enable S3 versioning on the bucket so cross-account requests are automatically trusted.

Versioning is useful for recovery, but it has nothing to do with authorization between accounts.

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: Create an IAM role in Account B, trust Account A's AppRole to assume it with STS, and then access the bucket using temporary credentials. — The best cross-account pattern is to use STS AssumeRole into the target account. Account B creates a role with a trust policy that allows Account A's role to assume it, and the role in B receives only the permissions needed for the S3 bucket. That gives the team temporary credentials, centralized revocation, and least privilege. It is also a common, scalable pattern for cross-account AWS access. Why others are wrong: Expanding permissions in Account A alone does not establish the proper cross-account trust relationship. SCPs cannot grant access to a bucket in another account, so they are not the solution. S3 versioning provides data protection, not authorization, so it does not help with the access denial shown in the exhibit.

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.