SAA-C03 Design Secure Architectures Practice Question

A third-party payroll vendor in another AWS account must assume a role in your account to write a daily settlement file to Amazon S3. You want to prevent confused-deputy attacks and make every assumed session traceable in CloudTrail back to an individual vendor user. Which three trust-policy or session controls should be used? Select three.

⚠ Common exam trap

It's easy for candidates to think a bucket policy alone can control role assumption, but it cannot—the trust policy is the only mechanism to restrict which external principals can assume a role, and confused-deputy protections require explicit conditions like external ID and source identity.

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

✓

Specify the exact vendor role ARN as the trusted principal in the role trust policy.

Specifying the exact vendor role ARN as the trusted principal in the trust policy ensures that only that specific role in the vendor's account can assume the role, preventing any other entity from impersonating the vendor. This is a key control to limit the trust boundary and avoid confused-deputy attacks.

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

✓
Specify the exact vendor role ARN as the trusted principal in the role trust policy.
Why this is correct
The trust policy should name only the specific vendor role that is allowed to assume the role in your account. Restricting the principal minimizes the trust boundary and prevents unrelated identities from attempting the assumption path.
✓
Require an external ID in the trust policy conditions.
Why this is correct
An external ID helps prevent confused-deputy attacks because the vendor must present a value that your account and the vendor agreed on. That prevents another customer from tricking the vendor into using the same role on their behalf.
✓
Require sts:SourceIdentity when the vendor assumes the role.
Why this is correct
SourceIdentity is recorded in CloudTrail and becomes part of the assumed-role session context. Requiring it gives investigators a way to trace the session back to the individual vendor user or workload that initiated the role assumption.
✗
Use a wildcard principal and rely on the S3 bucket policy to narrow access later.
Why it's wrong here
A wildcard principal makes the trust policy too broad and expands who can attempt to assume the role. The trust policy should be the first and tightest control, while the bucket policy should only govern what an already-authorized session can do after assumption.
When this WOULD be correct
In a scenario where you want to allow multiple accounts or services to assume a role without specifying each ARN individually, and you have additional controls like an external ID and source identity to prevent confused-deputy attacks, a wildcard principal might be acceptable if combined with strong condition keys.
✗
Give the vendor long-term IAM user credentials in your account for easier auditing.
Why it's wrong here
Long-term credentials increase operational and security risk and do not provide the same safety properties as temporary role sessions. Cross-account access should use STS and temporary credentials, not shared long-lived IAM users in the customer account.
When this WOULD be correct
A question where a trusted third party needs direct access to your AWS resources without assuming a role, and you have full control over their access policies. For example, a contractor who needs to upload files to S3 and you want to manage their permissions directly within your account, with CloudTrail logging tied to that IAM user.

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.

✓Specify the exact vendor role ARN as the trusted principal in the role trust policy.Correct answer▾

Why this is correct

The trust policy should name only the specific vendor role that is allowed to assume the role in your account. Restricting the principal minimizes the trust boundary and prevents unrelated identities from attempting the assumption path.

✗Use a wildcard principal and rely on the S3 bucket policy to narrow access later.Wrong answer — click to see why▾

Why this is wrong here

Using a wildcard principal in the trust policy would allow any AWS principal to assume the role, violating the principle of least privilege and failing to prevent confused-deputy attacks. The S3 bucket policy cannot restrict who assumes the role, only what the assumed role can access.

★ When this WOULD be the correct answer

In a scenario where you want to allow multiple accounts or services to assume a role without specifying each ARN individually, and you have additional controls like an external ID and source identity to prevent confused-deputy attacks, a wildcard principal might be acceptable if combined with strong condition keys.

Why candidates choose this

Candidates may think that a bucket policy can compensate for a permissive trust policy, not realizing that the trust policy controls who can assume the role, while the bucket policy only controls actions after the role is assumed.

✗Give the vendor long-term IAM user credentials in your account for easier auditing.Wrong answer — click to see why▾

Why this is wrong here

Option E suggests giving the vendor long-term IAM user credentials in your account, which violates the principle of least privilege and makes auditing harder because actions are tied to a shared credential rather than individual vendor users. It also does not prevent confused-deputy attacks or ensure traceability to individual vendor users.

★ When this WOULD be the correct answer

A question where a trusted third party needs direct access to your AWS resources without assuming a role, and you have full control over their access policies. For example, a contractor who needs to upload files to S3 and you want to manage their permissions directly within your account, with CloudTrail logging tied to that IAM user.

Why candidates choose this

Candidates may think that giving the vendor their own IAM user in the account simplifies auditing because the user is directly visible in CloudTrail, but they overlook the security risks of sharing long-term credentials and the inability to trace actions back to individual vendor employees.

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

SAA-C03 Design Secure Architectures Practice Question

Why each option matters

Option-by-option breakdown

Why each answer is right or wrong

AWS S3 Storage Class Comparison

Related to this question