Examkin

Question

Difficulty: HardMulti-Account Identity and Access Management Federation

An enterprise implements a multi-account AWS environment under AWS Organizations. Corporate data analysts authenticate through an external SAML 2.0 Identity Provider (IdP) to access AWS. Upon authentication, users assume a federated role named `SAML-Analyst-Role` in a centralized Identity AWS account (Account ID: `111122223333`). From this role, analysts need to assume a cross-account role named `Athena-Query-Role` in a target Analytics member account (Account ID: `123456789012`) to run database queries. The trust policy for `Athena-Query-Role` in the Analytics account is configured as follows:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/SAML-Analyst-Role"
},
"Action": "sts:AssumeRole"
}
]
}

The default `FullAWSAccess` Service Control Policy (SCP) has been detached from the Analytics Organizational Unit (OU) containing the Analytics account, and only the following custom SCP is attached:

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AnalyticsAccessOnly",
"Effect": "Allow",
"Action": [
"athena:*",
"glue:*",
"s3:*",
"kms:*"
],
"Resource": "*"
}
]
}

When data analysts attempt to switch roles to `Athena-Query-Role` from their federated session, they receive an Access Denied error. Which combination of configuration changes will resolve this issue?

  1. Update the SCP on the Analytics OU to include `sts:AssumeRole` in the list of allowed actions, and attach an IAM policy to the `SAML-Analyst-Role` in the Identity account that grants `sts:AssumeRole` permissions on the `Athena-Query-Role` ARN.Answer
  2. B
    Add `sts:AssumeRole` to the SCP on the Analytics OU. Because the SCP explicitly allows this action on the OU, no additional IAM policies need to be attached to the `SAML-Analyst-Role` in the Identity AWS account.
  3. C
    Modify the trust policy of the `Athena-Query-Role` in the Analytics account to change the allowed action from `sts:AssumeRole` to `sts:AssumeRoleWithSAML` since the users originate from a SAML-federated session.
  4. D
    Attach an IAM policy to the `SAML-Analyst-Role` in the Identity account that grants `sts:AssumeRole` permissions on the `Athena-Query-Role` ARN. No changes are required for the SCP since SCPs only restrict IAM principals created within the member account and do not apply to cross-account role assumptions.

Answer

Update the SCP on the Analytics OU to include `sts:AssumeRole` in the list of allowed actions, and attach an IAM policy to the `SAML-Analyst-Role` in the Identity account that grants `sts:AssumeRole` permissions on the `Athena-Query-Role` ARN.
To resolve the issue, the calling role in the Identity account must be granted permissions to assume the target role, and the Service Control Policy (SCP) of the target account's OU must allow the `sts:AssumeRole` action. Both are required because AWS evaluates both the identity-based policy of the caller and the SCP of the target account for cross-account resource access.

Step-by-Step Solution

1
Analyze the role transition sequence.
Identify that the user first federates into the Identity account using SAML, and then attempts a cross-account role assumption (sts:AssumeRole) into the Analytics account. Determine that standard cross-account role assumption requires the calling principal to have an identity-based IAM policy allowing `sts:AssumeRole`.
To ensure the calling role has the necessary outbound permissions.
2
Evaluate the impact of the Service Control Policy (SCP) on the target account.
Note that the default `FullAWSAccess` SCP has been detached, and the custom SCP acts as an allow-list which does not include `sts:AssumeRole`. Since SCPs act as guardrails that filter all requests (including cross-account requests) targeting resources in the account, `sts:AssumeRole` must be explicitly added to the SCP.
To prevent the target account boundary from blocking the incoming STS call.
3
Verify the correct STS action to use.
Confirm that `sts:AssumeRole` is the correct action for an IAM role assuming another IAM role, whereas `sts:AssumeRoleWithSAML` is only for the initial federated login.
To prevent misconfiguring the trust policy with an incorrect STS action.

Key Concept

Cross-account IAM role assumption under restrictive Service Control Policies (SCPs) in a multi-account environment.
Estimated Time:2m 30s
Rate this question

Topics

Multi-Account Identity and Access Management Federation

More questions from this topic