Google Cloud Platform (GCP): Scenario-Based Questions

IAM issues in GCP are often misunderstood due to policy inheritance, conditional role bindings, or org-level restrictions. Diagnosing the root cause requires tracing policy grants and understanding the role scope.

🔍 Investigation Steps

• Use IAM Policy Troubleshooter: Access it in the Cloud Console or via CLI to simulate access.
• Run: gcloud policy-troubleshoot iam or use the UI to check permission inheritance.
• Review Resource Hierarchy: Check if the role is granted at the project, folder, or org level.
• Inspect Custom Roles: Validate if custom roles include all expected permissions.
• Check Deny Policies: GCP now supports explicit deny bindings which override any allow.

🛠 Common Root Causes

• Missing APIs: Permissions do not work unless relevant APIs are enabled.
• Misconfigured Custom Role: Editor-like custom role missing specific permissions (e.g., deploy, billing).
• Overridden by Deny Policy: A deny condition can block access even with an Editor role.
• Wrong Resource Level: Role assigned at org but permission needed at project or vice versa.

✅ Fixes & Recommendations

• Use gcloud projects get-iam-policy [PROJECT_ID] to audit roles and bindings.
• Use fine-grained custom roles to assign only what’s needed and avoid over-provisioning.
• Re-assign roles at the correct resource scope (folder, project, or service level).
• Document IAM policies using YAML + versioning (e.g., with Terraform or Deployment Manager).

🧪 Tools to Use

• IAM Policy Troubleshooter (Console + CLI)
• Audit Logs (Cloud Logging → IAM activity filter)
• gcloud CLI (gcloud projects get-iam-policy)

🚫 Common Mistakes

• Assuming "Editor" grants everything — some services require separate IAM roles (e.g., Cloud Run Admin).
• Missing API activation step, even with correct roles.
• Over-relying on console UI without auditing policy bindings and logs.

📌 Real-World Insight

IAM debugging in GCP often reveals hidden policy interactions. Experienced teams use automation (Terraform, Pulumi) to declare and track permissions while regularly auditing access with least-privilege principles.