Interviewers ask, "How does IAM policy inheritance work? Can a child remove a parent's grant?" because they want to know: Do you understand that allow policies are additive, and that you cannot 'override' a parent? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 2 of the top 10 GCP resource hierarchy and IAM interview questions.

Short answer (30 seconds): Allow policies are additive. The effective access on a resource is the combination of its own policy and every parent's policy. So if a user gets Viewer at folder level, I cannot take that away at the project level by simply not granting it there. If I need to block access, I use an IAM deny policy, or I fix the grant at the level where it was given. That is why I grant at the lowest level that still makes sense.

 

GCP interview question 2: IAM Inheritance - model answer slide



What is the interviewer really asking?

Do you understand that allow policies are additive, and that you cannot 'override' a parent?

IAM Inheritance in plain English

  • Effective access = union of allow policies from resource up to Org
  • A child cannot remove a role granted by a parent
  • Use deny policies to block, not 'remove'

Easy picture: A master key given at floor level opens every room on that floor. The room manager cannot take that key back. You must change it at the floor, or add an extra lock (a deny policy).

Detailed explanation

  • An IAM allow policy is a list of bindings: who (principal) gets which role on which resource. Policies are inherited by child resources.
  • Because allow policies are additive, there is no 'override down'. A project cannot cancel a folder-level binding. This surprises people coming from other systems where child rules can override parent rules.
  • To explicitly block, use IAM deny policies. They can be attached to an organization, folder or project, and a matching deny rule beats any allow. Deny policies are part of the IAM v2 API.
  • Design rule: grant broad roles rarely and high only for truly broad groups (e.g. security auditors). Grant narrow roles low, close to the resource.

Example commands

gcloud projects get-iam-policy PROJECT_ID
gcloud resource-manager folders get-iam-policy FOLDER_ID
# See all policies that apply to a resource
gcloud asset analyze-iam-policy --organization=ORG_ID --full-resource-name=//cloudresourcemanager.googleapis.com/projects/PROJECT_ID

Replace ORG_ID, FOLDER_ID and PROJECT_ID with your own values. Check gcloud help for current flags before you use a command.

Common mistakes

  • Granting Editor at folder level 'for convenience'. It silently reaches every project below it today and tomorrow.
  • Trying to 'remove' access in a child project and not understanding why the user still has it.
  • Forgetting that new projects added under a folder inherit its grants immediately.

Follow-up questions to expect

  • How would you give a team access to 40 projects safely? (Folder-level predefined role to a group, not 40 bindings.)
  • How do you find who inherits access to a bucket? (Policy Analyzer / Asset Inventory.)

How the answer changes by role

Role What to emphasise
Architect Decide at which level each persona gets access; document it as the access model.
Data Engineer Grant dataset-level roles instead of project-wide BigQuery Admin.
DevOps Engineer Manage bindings in Terraform at the right level; avoid per-project copies.
Platform Engineer Bake group-based bindings into the project factory template.

Senior tip

Mention deny policies. Many candidates only know 'additive' and stop there.

Practice

  1. Say the 30-second answer aloud without reading it, and time yourself.
  2. Draw the diagram from memory on paper.
  3. Explain it once to a junior engineer and once to a CTO.

Keep learning

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.