SAA-C03 Design Secure Architectures Practice Question

Exhibit

Current trust policy in Account A:
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {"AWS": "arn:aws:iam::444455556666:root"},
      "Action": "sts:AssumeRole"
    }
  ]
}

CloudTrail entry from Account A:
{
  "eventSource": "sts.amazonaws.com",
  "eventName": "AssumeRole",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::444455556666:assumed-role/OtherRole/automation"
  },
  "errorCode": "AccessDenied"
}

Based on the exhibit, a workload in Account B must assume a role in Account A. Security requires that only the specific role arn:aws:iam::444455556666:role/PipelineExecRole can assume it, and only when the caller supplies the external ID acct-b-prod-7788. Which change best satisfies the requirement with the least privilege?

⚠ Common exam trap

Candidates often confuse the trust policy's `Principal` element with permission boundaries or SCPs, mistakenly thinking those can restrict who can assume a role, when in fact only the trust policy controls the assumption, and the external ID condition is required to prevent confused deputy attacks.

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

✓

Replace the principal with arn:aws:iam::444455556666:role/PipelineExecRole and add a StringEquals condition on sts:ExternalId = acct-b-prod-7788.

It explicitly restricts the trust policy principal to the specific IAM role ARN `arn:aws:iam::444455556666:role/PipelineExecRole` and adds a `StringEquals` condition on `sts:ExternalId` set to `acct-b-prod-7788`. This satisfies the security requirement by ensuring only that exact role can assume the role in Account A, and only when the correct external ID is provided, following the principle of least privilege.

Answer analysis

Option-by-option breakdown

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

✗
Keep the root principal and add an aws:PrincipalTag condition in the trust policy to require the tag acct-b-prod-7788.
Why it's wrong here
Principal tags can help with authorization, but they do not ensure that only one exact role in Account B can call STS. Any principal that can supply the tag might still satisfy the condition. This does not provide the required caller-specific trust boundary.
✓
Replace the principal with arn:aws:iam::444455556666:role/PipelineExecRole and add a StringEquals condition on sts:ExternalId = acct-b-prod-7788.
Why this is correct
This change directly restricts trust to one named role in Account B and adds a confused-deputy defense with the external ID. The role trust policy is the correct place to control who can assume the role, and the external ID ensures only the expected caller can complete the STS request.
✗
Attach a permission boundary to the role in Account A so that only PipelineExecRole can use it.
Why it's wrong here
Permission boundaries limit the maximum permissions a role can have after it is assumed, but they do not control who is trusted to assume the role. The trust policy, not the permission boundary, determines which external principal can call sts:AssumeRole.
✗
Add an SCP in Account B that allows sts:AssumeRole only for PipelineExecRole.
Why it's wrong here
An SCP can constrain identities in Account B, but it cannot by itself grant trust on the role in Account A. The trust policy in Account A must still explicitly allow the correct principal and should include the external ID condition for secure cross-account access.

Go deeper

SAA-C03 Design Secure Architectures Practice Question

Exhibit

Why each option matters

Option-by-option breakdown

Related to this question