## TL;DR
Replace the wildcard with actions the role actually used, not with a slightly smaller wildcard. Pull the last 90 days of activity for the role from Access Analyzer policy generation or CloudTrail, build a policy from used actions scoped to named resources, deploy it alongside monitoring, and only then detach the wildcard policy. The role keeps working, the finding clears, and the review gains evidence that the new policy matches real use.

```text
AWS IAM role has excessive permissions error: how to fix wildcard action policy
```

## Use this when
- A least privilege review flags a role whose policy allows an action wildcard on all resources.
- Security tooling rates the role critical because of broad managed or inline policies.
- The team cannot say which actions the workload actually needs.

## Not for this skill when
- The role is a documented break glass role with separate alerting. Record the exception instead of narrowing it.
- The workload is being decommissioned. Delete the role rather than rewriting its policy.

## Steps
1. Identify the exact policy documents attached to the role, separating managed, inline and permissions boundary policies, and copy the wildcard statements into the ticket. Verify: every wildcard statement is listed with its policy name.
2. Generate a used-actions view for the role from IAM Access Analyzer policy generation over at least 90 days, and cross-check rare actions in CloudTrail before dropping them. Verify: a used action list exists and rare but real actions are marked to keep.
3. Draft the replacement policy with named actions grouped by service, each statement scoped to the specific resource patterns the workload touches, and no action or resource wildcard remaining. Verify: the draft validates in the policy editor and contains no full wildcards.
4. Run both policies through the IAM policy simulator for the top workload calls, comparing allowed results so the replacement does not silently deny a needed action. Verify: simulated results match the old policy for every tested real call.
5. Attach the replacement, watch CloudTrail and application errors for denied calls during a soak period, and fix gaps by adding the named action rather than restoring a wildcard. Verify: the soak period ends with no unresolved access denied errors from this role.
6. Detach and delete the wildcard policy, re-run the access review or Access Analyzer check for the role, and attach the clean result to the review evidence. Verify: the role no longer appears on the excessive permissions report.
7. Record an owner and a review date on the new policy so future wildcard drift is caught at the next cycle instead of accumulating again. Verify: the policy carries an owner tag or a documented owner in the review system.

## Why it happens
Wildcard policies usually start as a shortcut during a build, when the fastest way to clear a denied error is to grant a whole service. The grant then survives into production because nothing breaks, and the review finding is the first moment anyone compares the grant against actual use. Usage data makes the narrowing safe: ninety days of activity shows the real action set, which is almost always a small fraction of the service, so the tightened policy is evidence based rather than guesswork.

## Variants and edge cases

### how to reduce IAM role permissions without breaking the app
The cautious phrasing. The soak period and simulator checks are the parts that make the reduction safe, so do not skip them to move faster.

### role flagged with Action star Resource star
The scanner phrasing using the policy shape itself. Treat managed and inline policies separately; the wildcard often hides in only one of them.

### least privilege policy generation from CloudTrail
The tooling phrasing. Access Analyzer policy generation is the fastest route, but always cross-check seasonal actions that may fall outside the window.

Edge cases to check before closing the review cycle:
- Quarterly or year end jobs may use actions invisible in a 90 day window. Ask the workload owner about periodic jobs before finalizing.
- A permissions boundary can mask a wildcard on paper while the effective grant stays broad. Review effective access, not documents alone.
- Service roles shared by several workloads need the union of all their usage, not one application view.

Compatibility: AWS IAM roles and policies, IAM Access Analyzer policy generation, CloudTrail based usage review, current AWS console and CLI v2.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_jqdk0r08rFTa1zEMoUrv7Q