Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An enterprise manages its multi-account environment using AWS Organizations. The security team has configured an on-premises SAML 2.0 Identity Provider (IdP) for federated access. The enterprise wants to allow external developers authenticated via this IdP to assume a specific troubleshooting role in a target member account. The Solutions Architect configures the SAML identity provider object inside the member account. However, when developers attempt to federate directly into the target member account via the identity provider's portal, they receive an explicit access denied error before they can choose a role. Which configuration change will successfully resolve this authentication failure and establish the trust relationship?

  1. Update the IAM role trust policy in the target member account to set the local SAML provider as the Principal, specify the sts:AssumeRoleWithSAML action, and add a condition that the SAML:aud attribute matches the AWS SAML endpoint.Answer
  2. B
    Update the IAM role trust policy in the target member account to list the local SAML provider as the Principal, but configure the policy to allow the standard sts:AssumeRole action to permit cross-account federation.
  3. C
    Attach a Service Control Policy (SCP) to the target member account's Organizational Unit (OU) that explicitly allows the sts:AssumeRoleWithSAML action, dynamically overriding the trust policy requirement.
  4. D
    Modify the trust policy of the target member account's IAM role to trust the SAML provider located in the organization's management account, enabling cross-account trust via a single centralized provider.

Answer

Update the IAM role trust policy in the target member account to set the local SAML provider as the Principal, specify the sts:AssumeRoleWithSAML action, and add a condition that the SAML:aud attribute matches the AWS SAML endpoint.
Direct SAML 2.0 federation into a member account requires configuring a SAML identity provider resource inside that specific member account. The trust policy of the IAM role to be assumed must list this local SAML provider as the principal and explicitly allow the sts:AssumeRoleWithSAML action. Adding a condition verifying that the SAML:aud attribute matches the standard AWS SAML endpoint ensures the assertion is intended for the correct AWS environment.

Step-by-Step Solution

1
Analyze the authentication flow for direct SAML federation into an AWS member account.
Identify that the federation portal attempts to execute the sts:AssumeRoleWithSAML API call directly against the target account's STS endpoint.
Direct federation bypassing the management account requires the target member account to have its own trust relationship established with the SAML identity provider.
2
Evaluate the IAM role trust policy requirements for SAML federation.
Determine that the trust policy must explicitly declare the local SAML provider as the principal and authorize the sts:AssumeRoleWithSAML action.
Standard sts:AssumeRole is only used for IAM identity delegation (users, roles, services), not for federated SAML assertions, which require a specialized STS action.
3
Assess the effect of Service Control Policies (SCPs) on cross-account federation trust.
Confirm that SCPs can only deny permissions as guardrails and cannot grant trust or replace the trust policy of an IAM role.
SCPs act as a filter on permissions and do not grant access directly; the local IAM role trust policy must still explicitly permit the federation action.

Key Concept

Direct multi-account SAML federation requires configuring local SAML provider objects and matching trust policies using the sts:AssumeRoleWithSAML action in each target account.
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic