What permissions does the AWS IAMAccessAdvisorReadOnly managed policy grant?

What the policy grants in practical AWS IAM terms

The policy is narrow by design: it grants read-only access to IAM Access Advisor data, not permission to change IAM policies, create roles, or modify credentials. That means the holder can inspect usage signals to understand which AWS services have actually been used and where permissions may be broader than operational need.

Because the policy is aimed at visibility rather than administration, it is most useful for review, audit, and rightsizing workflows. In practice, that makes it a support control for trimming unused access, not a substitute for broader IAM review permissions or policy management rights. For teams that already use AWS IAM Policies and Roles Guide, this policy fits into the read path of policy analysis rather than the write path of access administration.

Read access to Access Advisor data can still be sensitive because it reveals how an account or role has been used, which services are in play, and where entitlement review should focus. That makes the permission valuable for governance and hygiene, but it should be granted only to people or automation that genuinely need to perform access review.

What this policy does not allow

This managed policy does not grant standing authority over IAM itself. The principal cannot use it to edit permission documents, attach policies, assume other roles, or perform remediation directly. Its utility comes from observation and analysis, not control-plane action.

That distinction matters because access review data can be mistaken for a general-purpose IAM entitlement. It is better thought of as a diagnostic permission, one that helps assess whether a role has more access than it uses. For cloud teams comparing granted access with observed use, Cloud PAM and CIEM Guide is the natural broader context for rightsizing and effective-permission analysis.

If a team needs to reduce privileges based on what is actually exercised, the next step is not to expand this policy but to pair it with the right review process and, where needed, more specific administration rights held by a separate trusted role.

How administrators should use Access Advisor data safely

Access Advisor data is most useful when it supports periodic entitlement review, especially for roles with broad or inherited permissions. The value is in spotting services that have not been used and then testing whether those permissions can be removed without breaking workloads or admin workflows.

The control should be handled as evidence, not as proof that an entitlement is safe to keep forever. Usage history can be incomplete for dormant systems, bursty jobs, or rare break-glass access, so a low-usage signal should trigger validation rather than automatic removal. For teams managing cloud workload permissions more broadly, Cloud Workload Identity Guide provides the adjacent model for understanding how roles, temporary credentials, and runtime access fit together.

When the data shows broad access with little or no actual use, the practical response is usually to right-size first and preserve only the permissions that are demonstrably needed. When the data is being used for audit or review, retain the review evidence so future decisions can be justified and repeated consistently.

Risk and Threat Considerations

The main risk is over-reliance on visibility data that looks authoritative but does not by itself enforce least privilege. If many people can read Access Advisor output, they can learn which services are active, which roles are important, and where the account surface is concentrated.

Failure mechanism: A reviewer may treat usage data as sufficient proof that excess permissions are acceptable, or an unnecessary reader may use the data to map high-value services and target accounts with broad but unused access.

Impact: The organisation can preserve unnecessary privilege, miss opportunities to shrink blast radius, and widen the set of people who understand where sensitive AWS activity is concentrated.

Practitioner Guidance

What to verify: Confirm that the principal using this policy is performing entitlement review, audit, or rightsizing, not general IAM administration. If the same identity also has write permissions, separate the duties so read-only review cannot become policy modification by accident.

Common mistake: Teams often keep unused permissions because no one owns the decision to remove them. Treat Access Advisor output as a starting point for review, then require a named owner to approve retention when a permission looks dormant but is still operationally required.

Practitioner takeaway: Use this policy to observe and reduce permission sprawl, but keep the power to change IAM state in a different, tightly controlled role.

Related resources from NHI Mgmt Group

• What permissions does the AWS AmazonEC2FullAccess managed policy grant?
• What permissions does the AWS AmazonECS_FullAccess managed policy grant?
• What permissions does the AWS AmazonGuardDutyFullAccess managed policy grant?
• What permissions does the AWS AmazonGuardDutyReadOnlyAccess managed policy grant?