Examkin

Question

Difficulty: HardIAM Policies and Roles

A developer is configuring an application running on an Amazon EC2 instance in Account A (111122223333111122223333) to write logs to an Amazon S3 bucket in Account B (444455556666444455556666) by assuming an IAM role. The EC2 instance is associated with an IAM instance profile containing a role named `AppEngineRole`. In Account B, the developer has created an IAM role named `LogWriterRole` with a permissions policy allowing `s3:PutObject` on the S3 bucket.

Currently, the application fails to write logs and receives an `AccessDenied` error. The developer reviews the existing configurations:

Account A - `AppEngineRole` Permissions Policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::account-b-logs-bucket/*"
}
]
}

Account B - `LogWriterRole` Trust Policy:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}

Which of the following changes must the developer make to resolve the error and allow the application to assume the role and write to the S3 bucket? (Select TWO.)

  1. Modify the permissions policy of `AppEngineRole` in Account A to allow the `sts:AssumeRole` action on `arn:aws:iam::444455556666:role/LogWriterRole`.Answer
  2. Modify the trust policy of `LogWriterRole` in Account B to specify the principal `"AWS": "arn:aws:iam::111122223333:role/AppEngineRole"` instead of the EC2 service principal.Answer
  3. C
    Modify the trust policy of `LogWriterRole` in Account B to specify the principal `"AWS": "arn:aws:iam::111122223333:instance-profile/AppEngineRole"`.
  4. D
    Modify the permissions policy of `AppEngineRole` in Account A to grant `s3:PutObject` permissions on the S3 bucket in Account B.
  5. E
    Update the application code to initialize the AWS SDK client using credentials retrieved by calling the Instance Metadata Service (IMDS) directly for the assumed role.

Answer

To resolve the issue, the developer must allow the `AppEngineRole` in Account A to perform the `sts:AssumeRole` action on `LogWriterRole`, and they must update the trust policy of `LogWriterRole` in Account B to trust the ARN of `AppEngineRole` rather than the EC2 service principal.
For cross-account role assumption to succeed, two configurations are required: first, the permissions policy of the calling role in Account A must grant the `sts:AssumeRole` action targeting the ARN of the role in Account B. Second, the trust policy of the target role in Account B must designate the calling role's ARN in Account A as a trusted principal. Currently, the calling role in Account A lacks the permission to call `sts:AssumeRole`, and the target role in Account B incorrectly trusts the EC2 service principal rather than the calling IAM role itself.

Step-by-Step Solution

1
Analyze the execution environment and required IAM authorization flow.
The application runs on EC2 in Account A under the identity of `AppEngineRole` and needs to perform tasks in Account B. Direct bucket access is not configured; instead, the application must assume the `LogWriterRole` in Account B to obtain temporary credentials.
Understanding the authorization flow (role assumption across accounts) is necessary to identify the missing components.
2
Evaluate the permissions policy of the calling role (`AppEngineRole` in Account A).
The permissions policy currently grants `s3:PutObject` on the Account B bucket directly. However, to assume `LogWriterRole` in Account B, the caller must have `sts:AssumeRole` permissions on that specific role.
An IAM entity cannot assume a role unless it is explicitly permitted to call `sts:AssumeRole` on the target resource.
3
Evaluate the trust policy of the target role (`LogWriterRole` in Account B).
The trust policy currently trusts the service principal `ec2.amazonaws.com`. This configuration only allows the EC2 service to assume the role. It must be updated to trust the actual IAM role `AppEngineRole` from Account A.
For an application running on an EC2 instance to assume a cross-account role, the target role's trust policy must trust the calling IAM role's ARN, not the EC2 service principal.

Key Concept

Cross-account IAM role delegation requires a bi-directional handshake: the caller's identity-based policy must allow `sts:AssumeRole` on the target role, and the target role's trust policy must trust the caller's IAM ARN.
Rate this question

Topics

IAM Policies and Roles

More questions from this topic