An enterprise with a multi-account AWS environment managed under AWS Organizations uses an… — AWS Certified Solutions Architect - Professional

An enterprise with a multi-account AWS environment managed under AWS Organizations uses an external SAML 2.0 Identity Provider (IdP) to authenticate corporate users. The security team wants users to federate first into a central Identity account ( $111111111111$ ) and then assume a target role named WorkloadDeveloperRole in a member Production account ( $222222222222$ ) to manage resources.

To scale administration, the security team enforces Attribute-Based Access Control (ABAC). Users must only manage resources in the Production account where the resource tag CostCenter matches the user's CostCenter attribute from the corporate directory. This attribute must be securely propagated from the IdP through the federation session to the cross-account role.

Which two configurations must the solutions architect implement to establish this trust relationship and ensure compliant access? (Select two.)

Configure the SAML assertion in the corporate IdP to map the user's CostCenter attribute to https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter. In the Identity account ( $111111111111$ ), configure the trust policy of the federated IAM role to allow both the sts:AssumeRoleWithSAML and sts:TagSession actions for the SAML provider principal.Answer
In the Production account ( $222222222222$ ), configure the trust policy of WorkloadDeveloperRole to allow both the sts:AssumeRole and sts:TagSession actions for the Identity account's federated role principal. In the Identity account, configure the federated role's permissions policy to allow sts:AssumeRole on the target role, and configure the cross-account role assumption to pass the CostCenter tag as a transitive session tag.Answer
C
Configure the trust policy of the initial federated role in the Identity account ( $111111111111$ ) to allow only the sts:AssumeRole action for the SAML provider principal, and configure the corporate IdP to sign the SAML assertion with a private key registered in AWS IAM.
D
Attach a Service Control Policy (SCP) to the Organizational Unit (OU) containing the Production account ( $222222222222$ ) that allows the sts:AssumeRole and sts:TagSession actions for the federated role in the Identity account ( $111111111111$ ), thereby overriding the need to define a local trust policy on the WorkloadDeveloperRole in the Production account.
E
In the Identity account ( $111111111111$ ), configure the trust policy of the federated role to allow only sts:AssumeRoleWithSAML. In the Production account ( $222222222222$ ), configure the trust policy of WorkloadDeveloperRole to allow sts:AssumeRole from the SAML provider principal directly, bypassing the Identity account for the cross-account step.

Answer

Configuring the corporate IdP to map the CostCenter attribute to the AWS principal tag namespace and allowing both sts:AssumeRoleWithSAML and sts:TagSession in the Identity account's federated role trust policy, combined with configuring the Production account's WorkloadDeveloperRole trust policy to allow sts:AssumeRole and sts:TagSession from the Identity account's federated role, and passing the tag as a transitive session tag during cross-account role assumption.

The correct configuration combines mapping the directory attribute to the AWS principal tag namespace and allowing both sts:AssumeRoleWithSAML and sts:TagSession in the Identity account role's trust policy (enabling the session tag to be set initially), with configuring the Production account's WorkloadDeveloperRole trust policy to allow sts:AssumeRole and sts:TagSession from the Identity account's federated role principal, while specifying the tag as transitive to maintain the attribute across the role boundary.

Step-by-Step Solution

Map the identity directory attributes to AWS principal tags in the SAML assertion.

The CostCenter attribute is sent to AWS in the SAML assertion under the prefix https://aws.amazon.com/SAML/Attributes/PrincipalTag:CostCenter.

This tells AWS to automatically parse the attribute and apply it as a session tag to the federated IAM session.

Configure the trust policy of the federated IAM role in the Identity account (

111111111111

) to trust the SAML provider and allow both sts:AssumeRoleWithSAML and sts:TagSession.

The user successfully federates into the Identity account role, and the CostCenter session tag is successfully attached to the temporary session credentials.

The sts:AssumeRoleWithSAML action allows the token exchange, and sts:TagSession allows session tags to be set during federation.

Configure the trust policy of the WorkloadDeveloperRole in the Production account (

222222222222

) to trust the federated IAM role in the Identity account and allow both sts:AssumeRole and sts:TagSession.

The target role is prepared to receive session tags from the caller in the Identity account.

For cross-account role assumption with session tags, the target role's trust policy must explicitly allow both sts:AssumeRole (to permit the caller) and sts:TagSession (to permit propagating the session tags).

In the Identity account, invoke sts:AssumeRole pointing to the Production account role, marking the CostCenter tag as transitive.

The CostCenter tag is propagated to the assumed role session in the Production account, enabling ABAC validation against local resource tags.

Transitive tags ensure that session tags carry over to subsequent roles in the role chain.

Key Concept

Cross-Account Session Tag Propagation and Trust Configuration

Estimated Time:2m 30s

Question

Answer

Step-by-Step Solution

Key Concept

Common Mistakes

Topics

More questions from this topic