GCP IAM recommender failed with error permission denied on resource

Not specified by the original author.

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

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

Thread query: 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.

Not specified by the original author.

TL;DR

Fix this in GCP by acting on the exact message first: reproduce the failure on the smallest single item first, note the exact inputs that trigger it, and change only the input or setting the error names. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

GCP Policy Analyzer query failed: PERMISSION_DENIED iam.policyAnalyzer.queryActivity on project during review

Use this when

• The operation in GCP fails with this exact message: GCP Policy Analyzer query failed: PERMISSION_DENIED iam.policyAnalyzer.queryActivity on project during review.
• The same failure repeats on retry with unchanged inputs.
• A review, export or check is blocked until this item completes.

Not for this skill when

• The message is a permission or outage notice from the platform. Resolve that first, then return here if this error remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in GCP, and copy the full message plus the item, user or metric involved into the run notes. Verify: the error is reproduced on demand with a named item, not only seen in a log.
2. Apply the specific fix for this error: reproduce the failure on the smallest single item first, note the exact inputs that trigger it, and change only the input or setting the error names. Verify: confirm the single item now succeeds before rerunning the full batch.
3. Check the neighbouring items that share the same config, ontology, baseline or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Rerun the original operation in GCP on the previously failing scope, watching for the same message rather than assuming success from a quiet log. Verify: the operation completes and the original message does not appear.
5. Compare the result counts, decisions or alerts against the source in GCP so a silent partial success is caught before sign off. Verify: counts match the source or every difference is named and explained.
6. Record the fix, the triggering input and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the error, the fix applied and the evidence of success.

Why it happens

The failure is deterministic for the inputs involved, so a full batch retry repeats it; isolating the smallest failing item exposes the exact input or setting responsible.

Variant phrasings

GCP Policy Analyzer query failed: PERMISSION_DENIED iam.policyAnalyzer

The verbatim form searchers paste from the terminal or console. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix: GCP Policy Analyzer query failed: PERMISSION_DENIED iam.policyAnalyzer

The how-to phrasing for the same failure in GCP. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

GCP troubleshooting for this failure

The symptom-first phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: GCP at current versions, plus the platform API or console the query names; no extra tooling beyond a text editor and the source system access needed to verify counts.

Provenance

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

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

Thread query: GCP Policy Analyzer query failed: PERMISSION_DENIED iam.policyAnalyzer.queryActivity on project during review

TL;DR: Fix this in GCP by acting on the exact message first: reproduce the failure on the smallest single item first, note the exact inputs that trigger it, and change only the input or setting the error names. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

Not specified by the original author.

TL;DR

Grant the caller a billing role on the billing account, not on the project. A billing account admin adds the IAM binding with roles/billing.viewer for read access. The call fails because Cloud Billing lives above projects in the resource hierarchy, so project roles never cover it.

The error

Permission denied: consumer billing

Fix it

1. Identify the caller. For a human: gcloud auth list and note the active account. For automation, find the service account email in the job config. Expected: you know exactly which identity made the failing call.

2. Have a billing account admin check current bindings: gcloud billing accounts get-iam-policy [BILLING_ACCOUNT_ID] Expected: the caller's identity is missing, or has no billing role.

3. Add the read role: gcloud billing accounts add-iam-policy-binding [BILLING_ACCOUNT_ID] --member=user:[EMAIL] --role=roles/billing.viewer (For a service account, use --member=serviceAccount:[EMAIL] instead.) Expected: the command prints the updated policy including the new binding.

4. Retry the original billing API call. Expected: a 200 response with the billing data instead of the permission error.

Use this when

• The Cloud Billing API returns permission denied for a project owner or editor
• A cost agent's service account can read project resources but not billing data
• The billing console shows the account but blocks the details view

Not for this skill when

• The billing account is closed (fix the account state first; no role grant helps a closed account)
• The error is about enabling the Cloud Billing API on the calling project (enable the service, then this skill applies)
• You need to create new billing accounts (that needs the Billing Account Creator role, a different grant)

Variant phrasings

• 403 caller does not have permission on Cloud Billing API
• billing.accounts.get permission denied GCP
• service account cannot read billing account
• grant billing viewer role on billing account

Why it happens

Billing accounts sit above projects in the GCP resource hierarchy. IAM granted on a project, even Owner, does not flow upward to the billing account. Billing IAM is managed separately, only by someone holding Billing Account Administrator on that account, which is why capable-looking identities hit this wall.

Edge cases

• roles/billing.viewer is read-only; linking projects or changing budgets needs Billing Account User or cost-management roles
• If the caller also needs to enable the billing API, the project needs the service usage enable permission too
• Organization-level policy can restrict who gets billing roles; the admin may need an exception approved
• Token or credential caching in agents can make a fresh grant look like it failed; force a new auth session before retesting

Provenance

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

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

Thread query: "Permission denied: consumer billing" on the Cloud Billing API

TL;DR: Grant the caller a billing role on the billing account, not on the project. A billing account admin adds the IAM binding with roles/billing.viewer for read access. The call fails because Cloud Billing lives above projects in the resource hierarchy, so project roles never cover it.