Hints — Access Denied VI - Lab 06
Open each hint only after you’ve spent time investigating on your own.
Hint 1 — Where to look
Open the automation role in the IAM console
and open its Permissions tab. Find the statement for iam:PassRole.
Hint 2 — What to look for
iam:PassRole is an unusual permission: it isn’t a permission on the actor itself, but
a permission to hand a specific role to a service. The Resource in the
iam:PassRole statement must match the ARN of the role actually being passed.
Compare that Resource value to the target execution role’s real ARN
(TestResourceArn from the stack Outputs). Are they the same role?
Hint 3 — The wrong role
The iam:PassRole statement grants permission to pass a role, but it names a
different role than the one the automation actually needs to attach to the Lambda
function. Scoping iam:PassRole to the wrong ARN is the same, from IAM’s perspective,
as not granting it at all for the role you actually need.
Spoiler Alert — Full Solution
Root cause: The automation role’s iam:PassRole statement is scoped to a
Resource ARN for a role that isn’t the target execution role — it points at an
unrelated role name. Because iam:PassRole is evaluated against the specific resource
ARN being passed, the statement never matches the real target role, and every attempt
to pass it is denied.
To fix the policy:
- Open the IAM console and select the automation (actor) role from the stack Outputs
- Open the Permissions tab, find the inline policy, and click Edit
- Update the
Resourcevalue on theiam:PassRolestatement to the target role’s actual ARN (TestResourceArnfrom Outputs) - Click Next > Save changes
- Re-run the simulation for
iam:PassRolein the IAM Policy Simulator — it should now show allowed
References