Interviewers do not only listen for correct answers. They listen for mistakes you avoid. Here are 10 common GCP IAM and resource hierarchy mistakes from the top 10 questions, with a tip for how to say it like a senior engineer.

10 mistakes to avoid

  1. Resource Hierarchy: Building the hierarchy to copy the HR org chart. Org charts change often; your folders should not. Say instead: Say 'inheritance, billing and blast radius' - three words that show you think beyond the diagram. (full post)
  2. IAM Inheritance: Granting Editor at folder level 'for convenience'. It silently reaches every project below it today and tomorrow. Say instead: Mention deny policies. Many candidates only know 'additive' and stop there. (full post)
  3. Role Types: Giving roles/editor to a service account because 'it just works'. Say instead: Name one real predefined role and one real reason you would build a custom one. (full post)
  4. Allow, Deny, PAB: Using deny for everything. Prefer least-privilege allow, and use deny for hard guardrails. Say instead: This is the freshest topic in IAM. Showing you know PAB signals you keep up with the platform. (full post)
  5. Folder Design: Folders per team that is later reorganised, forcing mass moves. Say instead: Open with 'where does policy differ?' and the interviewer will relax - you are thinking in rules, not boxes. (full post)
  6. IAM vs Org Policy: Thinking Org Policy replaces IAM. It does not grant anything. Say instead: Use the one-liner: 'IAM is who, Org Policy is what.' Then add a concrete example. (full post)
  7. Least Privilege at Scale: Nested groups that nobody can understand. Say instead: Say 'groups, code, review, expiry' - four words that cover the whole answer. (full post)
  8. Conditions & Tags: Complex conditions that no one can read in six months. Say instead: Always add 'labels vs tags' - it is a classic follow-up trap. (full post)
  9. Org Admin & Break-glass: Individual users as Org Admin instead of a group. Say instead: Mention testing the break-glass process. It shows you have seen real incidents. (full post)
  10. Permission Denied: Granting Owner to 'make the error go away'. Say instead: Tell it as a step-by-step story. Interviewers love a calm, ordered debugging path. (full post)

How to avoid these in practice

  • Grant to groups, not people.
  • Grant the smallest predefined role at the lowest sensible level.
  • Keep production, test and sandbox separate.
  • Manage access as code, and review it regularly.

Keep going with the revision sheet or read the glossary.

Disclaimer: This blog is independent and not affiliated with or endorsed by Google. Google Cloud features, limits and commands change, so always check the current documentation. Official references: Resource hierarchy, IAM policy types, IAM quotas and limits.

For example: use gcloud projects get-iam-policy PROJECT_ID to inspect bindings on a project.