Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An enterprise manages a multi-account AWS environment using AWS Organizations. The security team has established a centralized identity account containing a SAML 2.0 Identity Provider (IdP) integration. Users first authenticate via the IdP to assume a central broker role (`arn:aws:iam::111111111111:role/FederatedHubRole`) in the identity account. From this central hub, users must transition to target execution roles (e.g., `arn:aws:iam::222222222222:role/TargetExecutionRole`) in various member accounts to perform administrative tasks. During deployment, federated users receive an access denied error when attempting to assume the target execution roles in the member accounts. Which configuration of the target execution role's trust policy will resolve the access issues and permit users to access resources in the member accounts?

  1. A
    Configure the trust policy of the target execution role to trust the SAML identity provider created in the member account, specifying the `sts:AssumeRoleWithSAML` action.
  2. B
    Attach a Service Control Policy (SCP) to the member account's Organizational Unit that permits the central broker role to perform actions, which implicitly grants trust across accounts without updating the target role's trust policy.
  3. Configure the trust policy of the target execution role to trust the ARN of the central broker role in the identity account, specifying the `sts:AssumeRole` action.Answer
  4. D
    Configure the trust policy of the target execution role to trust the identity account's SAML provider ARN, specifying the `sts:AssumeRole` action.

Answer

Configure the trust policy of the target execution role to trust the ARN of the central broker role in the identity account, specifying the `sts:AssumeRole` action.
The correct option correctly identifies that the scenario involves role chaining. When a user first federated into the central broker role, their identity is established as an assumed role session within AWS. When they attempt to assume a target role in a member account, the request is signed by the broker role's temporary credentials. Therefore, the target execution role's trust policy must trust the broker role's ARN and specify the `sts:AssumeRole` action.

Step-by-Step Solution

1
Analyze the access pattern to determine the principal making the request to the target execution role.
The federated user first assumes the broker role in the identity account. At this point, they are using temporary IAM credentials associated with that role session. The request to assume the target role in the member account originates from this role, not directly from the SAML IdP.
Understanding the caller's identity is critical for defining the correct trust relationship principal.
2
Select the appropriate AWS STS API action for the trust policy.
Because the caller is an IAM role principal using temporary AWS security credentials, the standard cross-account role assumption API (`sts:AssumeRole`) must be used.
Actions like `sts:AssumeRoleWithSAML` require an active SAML assertion, which is not present when performing cross-account role chaining.
3
Configure the trust policy on the target execution role in the member account.
Update the trust policy's `Principal` block to point to the central broker role (`arn:aws:iam::111111111111:role/FederatedHubRole`) and set the `Action` to `sts:AssumeRole`.
This establishes the necessary trust relationship allowing the identity account's broker role to assume the target role in the member account.

Key Concept

Role Chaining in Multi-Account AWS Environments
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic