GCP IAM recommender failed with error "permission denied on resource" how to fix

TL;DR

Grant the recommender read access at the level where you ask for recommendations, because the API evaluates the caller against that exact resource. Check whether the call is made as a user, a service account or an automation identity, grant IAM Recommender Viewer plus the resource viewer role at project, folder or organization level as appropriate, and wait for propagation before retesting. If a denial persists, read the denial in Cloud Audit Logs to see which permission name is missing instead of granting broader roles by guess.

permission denied on resource

Use this when

• IAM Recommender returns no results and a permission denied error for a project.
• Recommendations load for some projects and fail for others under the same identity.
• An automated least privilege job fails on the recommender call.

Not for this skill when

• Recommendations load but you disagree with one. Dismiss or snooze it with a reason instead.
• The denial names a VPC service controls perimeter. That needs perimeter work, not a role grant.

Steps

1. Identify the exact identity making the recommender call by checking the job configuration or the audit log principal for a failed call. Verify: the calling identity is named and is the one whose roles you will change.
2. Open Cloud Audit Logs for the failed call and record the missing permission string and the resource the call targeted. Verify: the denial entry names a specific permission and resource.
3. Grant the IAM Recommender Viewer role at the targeted project or folder level to that identity, avoiding an organization wide grant unless the job truly works at that level. Verify: the role appears on the resource policy for the calling identity.
4. Confirm the same identity also holds a viewer role that lets it read the target resource, since recommender results depend on reading the underlying policy. Verify: the identity can open the project IAM policy page or read it through the API.
5. Wait several minutes for IAM propagation, then repeat the single failing recommender call and record the new result. Verify: the call returns recommendations or an empty but successful response instead of a denial.
6. Run the recommender across the full scope of the review, note any remaining denied resources as separate line items, and grant or exclude each deliberately. Verify: every resource in scope is either returning recommendations or documented as excluded.
7. Write the granted roles and their scope into the review evidence so the next cycle starts from the same working access. Verify: the evidence lists identity, role and scope for the recommender job.

Why it happens

Recommender is not a single global switch; every call is authorized against the resource in the request. An identity that can read one project and not its sibling will see a patchwork of results that looks random until you line it up with grants. Audit logs remove the guesswork because the denial entry names the missing permission, and granting at the smallest level that matches the review scope keeps the fix consistent with the least privilege goal of the review itself.

Variants and edge cases

IAM Recommender API not returning recommendations

The symptom phrasing. An empty successful response and a denied response look alike in some consoles; check the call status before changing roles.

recommender.googleapis.com permission denied for service account

The automation phrasing. Grant the job identity, not your own user, or the fix will vanish when the job runs again.

unused service account recommendations missing for folder

The scope phrasing. Folder level calls need folder level grants; project grants do not roll upward.

Edge cases to check before closing the review cycle:

• Organization policies can block the recommender service itself in some projects. Check policy constraints when roles look right but calls still fail.
• Recommendations need usage history. A brand new project may return none successfully, which is not an error.
• Propagation can take minutes. Retesting instantly creates false failures and extra grants.

Compatibility: Google Cloud IAM Recommender for projects, folders and organizations, Cloud Audit Logs, recommender API v1 and v2.

Provenance

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