Examkin

Question

Difficulty: Very hardMulti-Account Identity and Access Management Federation

An enterprise manages a multi-account AWS environment using AWS Organizations. The security team is setting up identity federation with an external SAML 2.0 Identity Provider (IdP) to allow developers to access a role named DeveloperRole in several member accounts. The architecture must meet the following requirements:
1. Developers must authenticate via the corporate IdP and receive a federated session with access rights determined by their department attribute (attribute-based access control, or ABAC).
2. All federated sessions across all accounts must be prohibited from making changes to account billing settings.
3. Administrative overhead should be minimized while adhering to the principle of least privilege.

Which two configuration steps must the solutions architect perform to implement this solution? (Select two.)

  1. In each member account, create a SAML identity provider resource and a role named DeveloperRole. Configure the trust policy of the DeveloperRole to list the SAML identity provider as the principal, allow the sts:AssumeRoleWithSAML and sts:TagSession actions, and map the department attribute to the aws:PrincipalTag/Department session tag.Answer
  2. Create a Service Control Policy (SCP) that denies billing modification actions, and attach it to the target Organizational Units (OUs) or member accounts. In each member account, attach an IAM policy to the DeveloperRole that grants the necessary permissions for developer activities.Answer
  3. C
    Create a single Service Control Policy (SCP) at the Organization root that defines the external SAML IdP as the principal and allows the sts:AssumeRoleWithSAML action, enabling trust for all member accounts without modifying individual local IAM role trust policies.
  4. D
    In each member account, create a role named DeveloperRole with a trust policy that allows the sts:AssumeRole action for the SAML identity provider. Configure the SAML identity provider to pass the department attribute within the SAML assertion as a standard session policy instead of session tags.
  5. E
    Configure the trust policy of a centralized DeveloperRole in the management account to trust the SAML IdP. Configure a Service Control Policy (SCP) at the organization root that dynamically permits role chaining from the management account to member accounts, bypassing the need for individual trust policies in the member accounts.

Answer

The correct configuration requires creating a SAML identity provider and the DeveloperRole in each member account with a trust policy allowing both sts:AssumeRoleWithSAML and sts:TagSession to pass the department session tag, while enforcing billing restrictions via a Service Control Policy (SCP) combined with local IAM policies granting developer permissions.
Establishing federated access with ABAC requires configuring a local SAML identity provider and a role in each target member account. The role's trust policy must explicitly allow the action stating sts:AssumeRoleWithSAML to permit federation, as well as the action stating sts:TagSession to allow attributes from the SAML assertion to be mapped as session tags. To enforce billing restrictions across all accounts without administrative overhead, a Service Control Policy is used to deny billing actions globally at the Organization level, while local IAM policies are attached to the federated role to grant the required developer permissions.

Step-by-Step Solution

1
Configure SAML identity providers and roles locally in each member account.
Each member account has a trust relationship established with the external IdP.
SAML federation is account-specific and requires the SAML provider and IAM roles to be present in each account where users will log in.
2
Update the trust policy of the DeveloperRole to allow both federation and session tagging.
The role trust policy contains the actions sts:AssumeRoleWithSAML and sts:TagSession.
sts:TagSession must be explicitly allowed alongside sts:AssumeRoleWithSAML to enable the transmission of SAML attributes as session tags for ABAC.
3
Create and attach an SCP denying billing modifications at the organizational level.
An SCP is attached to the relevant OUs or member accounts, filtering out billing actions.
SCPs act as organizational guardrails to enforce maximum permissions (like denying billing changes) across all users and roles, including federated sessions.
4
Attach a local IAM permissions policy to the DeveloperRole in each member account.
Federated users have developer permissions that are filtered by the SCP.
Because SCPs do not grant permissions, a local IAM policy must be attached to the role to grant the actual access required by the developers.

Key Concept

Multi-Account SAML federation trust relationships and the interaction of local IAM policies with Service Control Policies.
Estimated Time:3m 0s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic