SAA-C03 Design Secure Architectures Practice Question

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 an allow statement for the vendor in the role’s trust policy to permit sts:AssumeRole from the vendor account (and include any required ExternalId condition).

  Why this is correct

  To grant an external vendor access to your AWS resources, you must edit the role's trust policy to include a principal from the vendor account and an action of sts:AssumeRole. This trust relationship is the only mechanism that authorizes a foreign principal to assume your role; the permissions policy alone cannot authorize cross-account assumption. Adding an ExternalId condition prevents the confused deputy problem by ensuring the role is assumed only for your intended vendor, not a third party using the same role.

• ✗

  Attach the same allow policy to the vendor account’s existing IAM user so the user can call sts:AssumeRole directly into your role.

  Why it's wrong here

  Attaching the same allow policy to the vendor's IAM user only grants that user permissions in its own account; it does not affect the trust relationship of your role. While any IAM principal can attempt an sts:AssumeRole call, that call will be denied unless your role's trust policy explicitly permits the vendor's account or principal to assume it. The permission policy on the IAM user is irrelevant to whether your role trusts the vendor, so this approach fails to establish the required trust.

  When this WOULD be correct

  If the vendor needed to access resources in your account using their own IAM user (not assuming a role), you would attach a resource-based policy (e.g., S3 bucket policy) allowing the vendor's user ARN. In that case, the vendor's user policy would need to allow the corresponding API calls (e.g., s3:GetObject).

• ✗

  Replace the AssumeRole call with GetCallerIdentity so the vendor can infer permissions without assuming the role.

  Why it's wrong here

  GetCallerIdentity is a simple API that returns details about the calling principal (such as account ID, user ID, and ARN); it does not grant any permissions to access resources in your account. Using it instead of AssumeRole would not let the vendor perform any actions on your internal resources, because the vendor never receives temporary credentials scoped to your role. This approach fundamentally changes the access mechanism but fails to provide the necessary authorization, leaving the vendor with no way to operate in your account.

  When this WOULD be correct

  When troubleshooting an IAM permissions issue within the same account, GetCallerIdentity can be used to verify the identity and permissions of the caller without needing to assume a role.

• ✗

  Enable MFA on the vendor’s IAM user and require MFA for your role using condition keys in the permissions policy.

  Why it's wrong here

  Requiring MFA for the vendor's IAM user and enforcing an MFA condition in your role's policy is a good security practice, but it does not address the core issue: the role still does not trust the vendor account. An MFA condition can be added to the trust policy to strengthen the gate, but without a base allow statement for sts:AssumeRole in the trust policy, the request is denied before any MFA check is even evaluated. Thus, MFA alone cannot establish the cross-account trust required for the vendor to assume the role.

  When this WOULD be correct

  A question where the vendor is already allowed to assume the role (trust policy is correct) but the role's permissions policy restricts access unless MFA is present. For example, a security requirement that all cross-account role assumptions must be authenticated with MFA. In that case, adding an MFA condition to the permissions policy would be the correct fix.

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.

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?”

Go deeper

Related to this question