PERMISSION_DENIED
GCP PERMISSION_DENIED means Google Cloud accepted the caller identity, then denied a named permission on a fully qualified resource after evaluating IAM allow, deny, and boundary controls.
Last reviewed: April 12, 2026|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
What Does Permission Denied Mean?
In practice, PERMISSION_DENIED is most useful when you treat it as a three-part tuple: principal, permission, and full resource name. Once those three values are known, Policy Troubleshooter and audit logs usually reveal whether the failure is missing allow, deny policy, wrong project, or an external boundary such as a service perimeter.
Common Causes
- -The live principal is a different service account or impersonated identity than the one operators think is running.
- -The required permission is not granted at the evaluated project, folder, organization, or resource node.
- -A conditional allow binding exists, but the live request context does not satisfy the condition expression.
- -A deny policy or principal access boundary blocks the permission even though an allow role exists higher in the hierarchy.
- -The request is pointed at the wrong project, folder, organization, or full resource name, so the right role is being checked in the wrong place.
- -A broader boundary such as VPC Service Controls causes a 403-style block that engineers initially misread as a simple IAM role issue.
How to Fix Permission Denied
- 1Capture the exact principal email, denied permission, full resource name, and request or audit-log context from the failing response.
- 2Run Policy Troubleshooter for the same principal, permission, and resource tuple before editing roles.
- 3Inspect ancestor allow and deny policies for the target project or resource path, not just the local project IAM page.
- 4Apply the smallest valid role or policy fix at the correct hierarchy level, then replay the unchanged request with the same identity.
Step-by-Step Diagnosis for Permission Denied
- 1Record the principal identity, denied permission, and full resource name from the failing response payload or Cloud Audit Logs.
- 2Use Policy Troubleshooter to determine whether the principal should have the permission on that exact resource.
- 3Inspect effective IAM bindings on the resource, project, folder, and organization ancestry, including conditional bindings and deny rules.
- 4Verify the workload is targeting the intended project and service account, especially when ADC or impersonation is involved.
- 5If the result still looks inconsistent, inspect service perimeter or org-policy constraints that can produce a 403-style block outside simple role binding logic.
- 6Replay the same request after a targeted change and compare the before/after authorization traces.
Seen in Production
- -A deployment job fails with
Permission \"resourcemanager.projects.getIamPolicy\" denied on resource \"//cloudresourcemanager.googleapis.com/projects/prod-app\"even though engineers were reviewing IAM on another project. - -Cloud Storage access fails with
Permission \"storage.objects.get\" denied on resource \"//storage.googleapis.com/projects/_/buckets/prod-artifacts/objects/app.tar.gz\"because the role exists on the bucket project, but the workload is running under another service account. - -A conditional binding worked yesterday, then started failing when request time, tags, or attributes no longer satisfied the condition expression.
Policy Troubleshooter and Ancestor Policy Trace
- -Use Policy Troubleshooter output to identify the decisive allow or deny path for the exact
principal + permission + resourcetuple instead of guessing from a role name. - -Audit inherited bindings and conditional expressions at the project, folder, and organization levels because the deciding statement often lives above the project engineers first inspect.
Boundary and Scope Controls
- -Verify the request points to the intended resource hierarchy node (example: service account calls project B while the required role exists only in project A).
- -Inspect service perimeter and organization controls before changing IAM because VPC Service Controls and other boundary controls can still block the call path.
Wrong Fix to Avoid
- -Do not grant broad Owner or Editor access before confirming the exact denied permission and resource path.
- -Do not stop after checking one project IAM page; the real answer may live in inherited bindings, deny policies, or a different target project.
Implementation Examples
{
"error": {
"code": 403,
"message": "Permission 'resourcemanager.projects.getIamPolicy' denied on resource '//cloudresourcemanager.googleapis.com/projects/prod-app' (or it may not exist).",
"status": "PERMISSION_DENIED"
}
}gcloud beta policy-troubleshoot iam \
//cloudresourcemanager.googleapis.com/projects/prod-app \
--principal-email=deployer@prod-app.iam.gserviceaccount.com \
--permission=resourcemanager.projects.getIamPolicy
gcloud beta projects get-ancestors-iam-policy prod-app --include-denySeen in Production
Deployment service account loses inherited access after hierarchy refactor
Frequency: common
Example: A CI pipeline starts failing on projects.setIamPolicy in one environment because the allow existed on an ancestor that changed or a deny policy was added above the project.
Fix: Restore the required role or remove the blocking deny at the correct hierarchy level, then retest with Policy Troubleshooter.
Wrong project or workload identity is selected at runtime
Frequency: common
Example: Application Default Credentials resolve to a different service account than the team expects, so the permission exists for one principal but not the live one.
Fix: Capture the effective principal and full resource name from runtime, then align ADC, impersonation, and project targeting before editing IAM.
Conditional binding or service perimeter blocks a healthy-looking role assignment
Frequency: medium
Example: The role name appears correct in the console, but a condition expression or VPC Service Controls boundary still produces a 403-style block.
Fix: Troubleshoot the exact permission with Policy Troubleshooter, then inspect conditions or perimeter diagnostics separately.
Debugging Tools
- -Policy Troubleshooter for IAM
- -Cloud Audit Logs (
authorizationInfo) - -
gcloud beta policy-troubleshoot iam - -
gcloud beta projects get-ancestors-iam-policy --include-deny - -VPC Service Controls and Org Policy diagnostics
How to Verify the Fix
- -Re-run the denied operation with the same principal and full resource name and confirm it succeeds.
- -Validate Cloud Audit Logs or troubleshooter output now show an allow result for the previously blocked permission.
- -Confirm adjacent privileged operations remain least-privilege and no unintended overgrant was introduced.
- -If impersonation or ADC was involved, verify the runtime still resolves the intended identity after the fix.
How to Prevent Recurrence
- -Codify IAM changes with review gates that evaluate inherited allows, deny policies, and IAM Conditions together.
- -Run policy troubleshooting or simulation checks in CI/CD for the highest-risk service accounts and permissions before rollout.
- -Alert on repeated PERMISSION_DENIED spikes by principal, permission, and resource family.
Pro Tip
- -persist the exact
principal + permission + resourcetuple from each denial and use it as a deterministic regression test in policy pipelines.
Decision Support
Compare Guide
AWS AccessDenied vs GCP PERMISSION_DENIED (403)
Compare AWS AccessDenied and GCP PERMISSION_DENIED to isolate authorization deny layers, separate auth failures, and apply precise IAM fixes fast.
Playbook
Authorization Denial Playbook (403 / AccessDenied / PERMISSION_DENIED)
Use this playbook to triage policy-based access denials after authentication succeeds, isolate the deny layer, and apply least-privilege remediation safely.
Playbook
CORS Error Fix Playbook (Preflight / Origin / Credentials)
Use this playbook to separate browser-enforced cross-origin policy failures from server-side CORS header and route defects and apply strict origin and credential controls safely.
Official References
Provider Context
This guidance is specific to GCP services. Always validate implementation details against official provider documentation before deploying to production.