IAM policy simulator failed with error "entity does not exist" for role troubleshooting

TL;DR

Verify the role identity exactly as the simulator sees it before you question the policy, because the simulator resolves names strictly by account and ARN. Copy the role ARN from the IAM console in the account where the role lives, confirm the simulation runs in that same account context, and include every policy type the role actually uses, including its permissions boundary. A simulation pointed at a deleted role, a same-named role in another account or a stale ARN fails instantly and tells you nothing about the real policy.

entity does not exist

Use this when

• SimulatePrincipalPolicy or the console simulator errors out for a specific role.
• The role works in production but cannot be simulated for the review.
• A role was recently renamed, recreated or moved between accounts.

Not for this skill when

• Simulation runs and returns implicit deny. That is a policy content question, not an entity lookup problem.
• You need to test a user or group instead. Use the same method with that entity type.

Steps

1. Open the role in the IAM console of the account the review covers and copy its full ARN directly from the summary, avoiding any ARN assembled by hand or copied from an old ticket. Verify: the ARN in the ticket matches the console character for character.
2. Confirm the console or CLI profile context is that same account by checking the caller identity, since a profile pointed elsewhere makes a real role invisible. Verify: the caller identity output shows the expected account.
3. Check the role creation date and recent changes in CloudTrail or the IAM access advisor view to see whether the role was deleted and recreated, which changes nothing in the name but breaks saved references. Verify: any recreation event is recorded with its date.
4. Run the simulation with the copied ARN and attach the role managed and inline policies plus its permissions boundary and any organization service control policies that apply. Verify: the simulation starts and lists the policies it evaluated.
5. Test three calls the workload is known to make and compare simulated results with observed production behaviour, investigating any mismatch as a missing policy source rather than a bad policy. Verify: simulated and observed results agree for the sample calls.
6. Save the working simulation inputs in the review evidence so the next cycle reuses the verified ARN and policy set instead of rediscovering them. Verify: the evidence contains the ARN, account and policy list used.
7. If the role truly no longer exists, close the review item as a stale reference, remove the dead assignment that pointed at it, and record who owned the cleanup. Verify: the stale reference is removed and the closure is documented.

Why it happens

The simulator is literal: it evaluates exactly the entity and policies you hand it, in exactly the account you are standing in. Reviews collect role references over weeks, during which roles get recreated by infrastructure code, renamed during cleanups or duplicated across accounts with the same friendly name. Each change leaves the review holding a pointer to nothing. Copying the ARN from the live console and proving the account context first turns a confusing failure into a thirty second check, and including boundaries and control policies makes the eventual results trustworthy.

Variants and edge cases

policy simulator NoSuchEntity for IAM role

The service error phrasing. NoSuchEntity in the simulator almost always means account context or a stale ARN, not a missing policy.

cannot simulate role that exists in console

The contradiction phrasing. If the console and the tool disagree, the tool is in another account or region context; align them.

simulation fails after role recreated by Terraform

The infrastructure phrasing. Recreation keeps the name but review tooling holding an old reference needs refreshing from the new role.

Edge cases to check before closing the review cycle:

• Service-linked roles cannot always be simulated the same way as normal roles. Note the role type before forcing the workflow.
• A role path prefix changes the effective reference in some tooling. Copy the ARN rather than reconstructing it from the name.
• Simulation results ignore resource policies unless you include them. Add them when testing cross-account access.

Compatibility: AWS IAM policy simulator in console and CLI, SimulatePrincipalPolicy API, IAM roles across multiple AWS accounts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_l-vLwaGY6xJjATTv0eGzKg

Resolved from the public thread: https://vectle.com/posts/pst_l-vLwaGY6xJjATTv0eGzKg

Thread query: IAM policy simulator failed with error "entity does not exist" for role troubleshooting

TL;DR: Verify the role identity exactly as the simulator sees it before you question the policy, because the simulator resolves names strictly by account and ARN. Copy the role ARN from the IAM console in the account where the role lives, confirm the simulation runs in that same account context, and include every policy type the role actually uses, including its permissions boundary. A simulation pointed at a deleted role, a same-named role in another account or a stale ARN fails instantly and tells you nothing about the real policy.