Question 729 of 1,040
Design Secure ArchitecturesmediumMultiple ChoiceObjective-mapped

Quick Answer

The answer is to add a condition requiring sts:ExternalId to equal a specific value that Company B’s workload must provide in the sts:AssumeRole call. This directly solves the confused deputy problem because the cross-account IAM role external ID condition acts as a secret shared only between the trusting account (Company A) and the specific workload in Company B. Even though the trust policy restricts the role to account 2222, any principal in that account could assume it; the external ID ensures only the workload that knows and passes the unique value succeeds. On the SAA-C03 exam, this scenario tests your understanding of preventing unauthorized cross-account access when a third party assumes a role—a common trap is thinking the principal ARN alone is enough, but the external ID is required when you cannot specify a unique role or user in the other account. Remember the mnemonic: “External ID = Extra IDentity check for the deputy problem.”

SAA-C03 Design Secure Architectures Practice Question

This SAA-C03 practice question tests your understanding of design secure architectures. The scenario asks you to isolate a root cause — eliminate options that address a different problem before choosing. After answering, compare your reasoning against the explanation and wrong-answer breakdown below. Once you have made your selection, read the full explanation to reinforce the concept and understand why each distractor is designed to mislead on exam day.

Company A (account 1111) hosts an IAM role (RoleInAccountA) that is assumed by a workload in Company B (account 2222) using sts:AssumeRole. Security requires that only Company B’s intended workload can assume the role, even if another principal in account 2222 tries to assume it. The trust policy already restricts who can assume the role to account 2222. What additional trust policy condition most directly satisfies this requirement?

Question 1mediummultiple choice
Full question →

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 condition requiring sts:ExternalId to equal a specific value that Company B’s workload must provide in sts:AssumeRole.

Option A is correct because the sts:ExternalId condition key is specifically designed to prevent the confused deputy problem. By requiring a unique external ID that only Company B's intended workload knows and passes in the sts:AssumeRole call, the trust policy ensures that even if another principal in account 2222 attempts to assume the role, it cannot provide the correct external ID, thus blocking the request.

Key principle: Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

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 condition requiring sts:ExternalId to equal a specific value that Company B’s workload must provide in sts:AssumeRole.

    Why this is correct

    An ExternalId acts as a shared secret known only to the intended workload (or integration). Adding a sts:ExternalId condition causes sts:AssumeRole to fail for any other principals in account 2222 that do not supply the correct ExternalId, directly mitigating confused-deputy scenarios.

    Related concept

    Read the scenario before looking for a memorised answer.

  • Add a condition requiring aws:PrincipalArn to start with arn:aws:iam::2222:role/.

    Why it's wrong here

    A PrincipalArn prefix pattern may still match multiple roles or principals in account 2222. It does not provide a workload-specific secret/secret-like value, so other roles in account 2222 could still assume the role successfully if they match the pattern.

  • Add a condition requiring sts:RoleSessionName to match the string "integration".

    Why it's wrong here

    RoleSessionName is controlled by the caller at AssumeRole time. An attacker can set RoleSessionName to the expected value, so it is not a reliable workload identifier.

  • Rely only on an SCP in account 1111 to block all sts:AssumeRole calls except from Company B’s OU.

    Why it's wrong here

    SCPs are organization-level guardrails but are not a workload-specific control inside the IAM role trust policy evaluation. They do not address the confused-deputy problem in the way ExternalId does, and they are broader than the requirement’s “only the intended workload” constraint.

Common exam traps

Common exam trap: answer the scenario, not the keyword

The trap here is that candidates often confuse the purpose of sts:RoleSessionName (which is for auditing, not security) or assume that restricting by principal ARN prefix is sufficient, but they overlook that any role in account 2222 could match that prefix, failing to isolate the specific workload.

Trap categories for this question

  • Similar concept trap

    SCPs are organization-level guardrails but are not a workload-specific control inside the IAM role trust policy evaluation. They do not address the confused-deputy problem in the way ExternalId does, and they are broader than the requirement’s “only the intended workload” constraint.

Detailed technical explanation

How to think about this question

The sts:ExternalId condition is part of AWS's confused deputy prevention mechanism, where the external ID acts as a shared secret between the trusting account (1111) and the trusted workload. When Company B's workload calls sts:AssumeRole, it must include the external ID in the request; AWS evaluates the trust policy and verifies the external ID matches, ensuring only that specific workload can assume the role. This is commonly used in cross-account access scenarios, such as when a third-party SaaS provider needs to access a customer's AWS resources.

KKey Concepts to Remember

  • Read the scenario before looking for a memorised answer.
  • Find the constraint that changes the correct option.
  • Eliminate answers that are true in general but not in this case.

TExam Day Tips

  • Watch for words such as best, first, most likely and least administrative effort.
  • Review why wrong options are wrong, not only why the correct option is correct.

Key takeaway

Answer the scenario, not the keyword: identify the specific constraint before choosing the most familiar-sounding option.

Real-world example

How this comes up in practice

A company's IT admin needs to give a contractor read-only access to production logs without sharing account credentials. Using role-based access control (RBAC) and temporary scoped permissions — not a permanent shared password — is the correct pattern. Questions like this test whether you can apply least-privilege access across cloud identity services.

What to study next

Got this wrong? Here's your next step.

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

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.

Practice this exam

Start a free SAA-C03 practice session

Short sessions build daily habit. Longer sessions build exam-day stamina. Try a timed session to simulate real conditions.

FAQ

Questions learners often ask

What does this SAA-C03 question test?

Design Secure Architectures — This question tests Design Secure Architectures — Read the scenario before looking for a memorised answer..

What is the correct answer to this question?

The correct answer is: Add a condition requiring sts:ExternalId to equal a specific value that Company B’s workload must provide in sts:AssumeRole. — Option A is correct because the sts:ExternalId condition key is specifically designed to prevent the confused deputy problem. By requiring a unique external ID that only Company B's intended workload knows and passes in the sts:AssumeRole call, the trust policy ensures that even if another principal in account 2222 attempts to assume the role, it cannot provide the correct external ID, thus blocking the request.

What should I do if I get this SAA-C03 question wrong?

Identify which exam domain this question belongs to, review the core concept, then practise similar questions from the same domain.

What is the key concept behind this question?

Read the scenario before looking for a memorised answer.

About these practice questions

Courseiva creates original exam-style practice questions with explanations and wrong-answer analysis. It does not publish real exam questions, exam dumps, or protected exam content. Learn why practice questions differ from exam dumps →

How Courseiva writes practice questions · Editorial policy

Same concept, more angles

3 more ways this is tested on SAA-C03

These questions test the same concept from different angles. Work through them to make sure you can recognise it however the exam phrases it.

Variation 1. Account A hosts a role named AppReadRole. Account B needs to access it using STS AssumeRole. Account A’s role trust policy includes this condition: - StringEquals: { "sts:ExternalId": "b-7f9a" } When Account B runs: aws sts assume-role --role-arn arn:aws:iam::111111111111:role/AppReadRole --role-session-name test the call fails with: "AccessDenied: ExternalId mismatch". What should Account B change?

medium
  • A.Provide the correct --external-id value (b-7f9a) in the AssumeRole call.
  • B.Add kms:Decrypt permissions to Account B’s IAM user because trust policy failures are KMS related.
  • C.Remove the ExternalId condition from the trust policy so any caller can assume the role.
  • D.Use AssumeRoleWithSAML instead of AssumeRole so ExternalId is not required.

Why A: The error 'AccessDenied: ExternalId mismatch' occurs because the trust policy on Account A's role requires an `sts:ExternalId` condition with the value `b-7f9a`, but Account B's `aws sts assume-role` command did not include the `--external-id` parameter. By providing the correct `--external-id b-7f9a` in the call, Account B satisfies the condition, allowing the role assumption to succeed. This is a standard security mechanism to prevent the confused deputy problem.

Variation 2. A SaaS vendor needs temporary access to an S3 bucket in your AWS account to read customer exports. The vendor will assume an IAM role you created. During integration testing, the vendor reports that their AssumeRole requests succeed, but your security team is concerned about the possibility of confused-deputy attacks. Which trust policy approach most directly mitigates this risk?

medium
  • A.Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.
  • B.Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.
  • C.Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.
  • D.Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.

Why A: Option A is correct because the `sts:ExternalId` condition in the trust policy forces the vendor to include a unique external ID in their `AssumeRole` API call. This prevents a confused-deputy attack by ensuring that the role can only be assumed when the caller provides the exact external ID you have pre-shared, thereby verifying the intended purpose of the cross-account access.

Variation 3. A SaaS vendor needs temporary access to an S3 bucket in your AWS account to read customer exports. The vendor will assume an IAM role you created. During integration testing, the vendor reports that their AssumeRole requests succeed, but your security team is concerned about the possibility of confused-deputy attacks. Which trust policy approach most directly mitigates this risk?

medium
  • A.Add an sts:ExternalId condition to the role trust policy that must match the unique external ID you provide to the vendor.
  • B.Require the vendor to use the same MFA device serial number as your internal administrators in the trust policy.
  • C.Remove the role’s permissions policy and rely only on the S3 bucket policy to validate the caller.
  • D.Allow sts:AssumeRole from the vendor account root principal without restricting to the vendor’s specific IAM role.

Why A: Option A is correct because adding an `sts:ExternalId` condition to the role trust policy forces the vendor to include a unique external ID in their `AssumeRole` API call. This prevents a confused-deputy attack by ensuring that the role can only be assumed when the caller presents the specific external ID you control, even if the vendor's account is compromised or used by a different AWS service.

Keep practising

More SAA-C03 practice questions

Last reviewed: Jun 11, 2026

Question Discussion

Share a tip, memory trick, or ask about the reasoning behind this question. Do not post real exam questions, leaked content, braindumps, or copyrighted exam material. Comments are moderated and may be removed without notice.

Loading comments…

Sign in to join the discussion.

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.