mediummulti selectObjective-mapped

A software vendor in Account B must assume a role in Account A to process support tickets. Security wants to prevent confused deputy attacks. Which two configurations are required for this access pattern to work safely? Select two.

Question 1mediummulti select
Full question →

A software vendor in Account B must assume a role in Account A to process support tickets. Security wants to prevent confused deputy attacks. Which two configurations are required for this access pattern to work safely? Select two.

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

Require a specific sts:ExternalId value in the role trust policy in Account A.

A trust policy condition on sts:ExternalId is the standard confused-deputy protection for third-party role assumption. It ensures that only callers who know the shared external identifier can assume the role.

B

Best answer

Make sure the vendor includes that same ExternalId when calling sts:AssumeRole.

The caller must supply the exact ExternalId value that the trust policy expects. If the value is missing or different, STS denies the AssumeRole request.

C

Distractor review

Share long-term access keys from Account A with the vendor.

Long-term credentials increase risk and are not needed for third-party access. STS temporary credentials are the secure mechanism for this scenario.

D

Distractor review

Attach a permissions boundary to the role to satisfy the ExternalId requirement.

Permissions boundaries limit what the role can do after it is assumed. They do not validate who may assume the role and do not protect against confused deputy attacks.

E

Distractor review

Allow sts:GetSessionToken instead of sts:AssumeRole in the trust policy.

GetSessionToken is not the cross-account role-assumption mechanism used for third-party access. The correct approach is sts:AssumeRole with an ExternalId condition.

Common exam trap

Common exam trap: NAT rules depend on direction and matching traffic

NAT is not only about the public address. The inside/outside interface roles and the ACL or rule that matches traffic are just as important.

Technical deep dive

How to think about this question

NAT questions usually test address translation, overload/PAT behaviour, static mappings and whether the right traffic is being translated. Read the interface direction and address terms carefully.

KKey Concepts to Remember

  • Static NAT maps one inside address to one outside address.
  • PAT allows many inside hosts to share one public address using ports.
  • Inside local and inside global describe the private and translated addresses.
  • NAT ACLs identify traffic for translation, not always security filtering.

TExam Day Tips

  • Identify inside and outside interfaces first.
  • Check whether the scenario needs static NAT, dynamic NAT or PAT.
  • Do not confuse NAT matching ACLs with normal packet-filtering intent.

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?

Static NAT maps one inside address to one outside address.

What is the correct answer to this question?

The correct answer is: Require a specific sts:ExternalId value in the role trust policy in Account A. — The secure third-party access pattern uses STS AssumeRole with an ExternalId. Account A must include an ExternalId condition in the role trust policy, and the vendor in Account B must pass the same value when calling sts:AssumeRole. This prevents another customer or attacker from tricking the vendor into using a role intended for a different account. Long-term access keys should not be used for cross-account vendor access because they are hard to rotate and do not provide the temporary, scoped access that STS provides. Permissions boundaries limit post-assumption permissions but do not secure the trust relationship. sts:GetSessionToken is not a substitute for cross-account role assumption.

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.