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.

• ✓

  Account B’s calling principal must have an identity-based policy that allows sts:AssumeRole on RoleInAccountA’s role ARN.

  Why this is correct

  For a cross-account role assumption, the trust policy on RoleInAccountA is necessary but not sufficient: it lists Account B as a trusted principal, but the individual user or role in Account B must also have an attached IAM policy granting sts:AssumeRole with a Resource that includes RoleInAccountA's ARN. Without that identity-based permission, the caller has no authorization to invoke the STS API, even though the trust side is satisfied. This dual-sided authorization is the standard way to securely delegate access across accounts.

• ✗

  Account A must attach an S3 bucket policy statement to allow sts:AssumeRole from Account B.

  Why it's wrong here

  S3 bucket policies are resource-based policies attached to an S3 bucket for controlling data-plane operations such as GetObject or PutObject; they are not used in the authorization path for STS AssumeRole. Cross-account role assumption is governed entirely by IAM constructs: the target role's trust policy and the calling principal's identity-based policy. Placing a bucket policy in Account A would be ignored when the STS API is called, since STS does not consult S3 policies, and it also would not affect the caller's permissions to assume the role.

• ✗

  Account B must add kms:Decrypt permissions to the caller to satisfy AssumeRole.

  Why it's wrong here

  kms:Decrypt is a key permission needed only when the caller or role reads or processes data encrypted under a customer-managed KMS key, and that step happens after authentication and authorization for the API call. The sts:AssumeRole API action itself only verifies that the caller's identity policy allows that action on the role ARN and that the role's trust policy trusts the caller's account; it has no dependency on KMS permissions. Adding KMS decrypt would not change the AccessDenied outcome, because the failure occurs during STS authorization, not during any subsequent data-access operation.

• ✗

  Account B must create an SCP in the organization to allow sts:AssumeRole.

  Why it's wrong here

  SCPs can restrict allowed actions, but if a trust policy is already correct, the most common reason for AccessDenied is missing identity-based sts:AssumeRole permissions in Account B. SCPs typically produce explicit denies when they block an action, not the standard missing-permission scenario described here.

Go deeper

Related to this question