Examkin

Question

Difficulty: Very hardIAM Policies and Roles

A developer is implementing Attribute-Based Access Control (ABAC) in an AWS account. The developer configures an IAM role named `ProjectRunnerRole` with the following trust policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:user/AppDeveloper"
},
"Action": "sts:AssumeRole",
"Condition": {
"StringEquals": {
"aws:RequestTag/Project": "Phoenix",
"aws:RequestTag/CostCenter": "1001"
}
}
}
]
}

An IAM user named `AppDeveloper` in the same account attempts to assume this role by calling the `sts:AssumeRole` API and passing the session tags `Project=Phoenix` and `CostCenter=1001`. The request fails with an `AccessDenied` error. Which TWO of the following configurations are required to resolve this error and successfully allow the user to assume the role?

  1. Update the Action element of the trust policy in ProjectRunnerRole to allow both sts:AssumeRole and sts:TagSession.Answer
  2. Attach an identity-based policy to the AppDeveloper user that grants both sts:AssumeRole and sts:TagSession permissions targeting the ARN of ProjectRunnerRole.Answer
  3. C
    Modify the Principal element in the trust policy of ProjectRunnerRole to specify the service principal sts.amazonaws.com.
  4. D
    Change the condition keys in the trust policy from aws:RequestTag/Project and aws:RequestTag/CostCenter to aws:PrincipalTag/Project and aws:PrincipalTag/CostCenter.
  5. E
    Configure the application to authenticate the SDK client using hardcoded temporary access keys and session tokens belonging to ProjectRunnerRole.

Answer

To allow the IAM user to assume the role with session tags, the trust policy of the role must include both the sts:AssumeRole and sts:TagSession actions, and the identity-based policy attached to the user must grant permissions for both actions targeting the role's ARN.
To successfully assume an IAM role while passing session tags, both the trust policy of the target role and the identity-based policy of the calling principal must explicitly allow the sts:TagSession action alongside sts:AssumeRole. The trust policy in the scenario only permits sts:AssumeRole, which causes the API call to fail with AccessDenied when tags are passed. Therefore, updating the trust policy to include sts:TagSession and attaching an identity-based policy to the caller with both permissions solves the issue.

Step-by-Step Solution

1
Analyze the error message and the trust policy structure.
The error is AccessDenied during sts:AssumeRole while trying to pass session tags, and the trust policy only permits sts:AssumeRole.
AWS STS requires explicit permission for the sts:TagSession action in the trust policy to allow callers to pass session tags.
2
Evaluate the caller's permissions.
The caller (AppDeveloper) must also have permissions to perform both sts:AssumeRole and sts:TagSession in their identity-based policy.
AWS security requires authorization on both the resource (the role trust policy) and the caller (identity-based policy) for session tag operations.
3
Differentiate between aws:RequestTag and aws:PrincipalTag.
Confirm that aws:RequestTag is the correct key because tags are passed in the request, not already attached to the user.
aws:RequestTag evaluates the tags that are passed in the API call request, whereas aws:PrincipalTag evaluates the tags attached to the calling principal.

Key Concept

IAM Session Tags and sts:TagSession Authorization
Rate this question

Topics

IAM Policies and Roles

More questions from this topic