Interviewers ask, "What is the difference between IAM and Organization Policy?" because they want to know: Do you separate access control (IAM) from configuration guardrails (Org Policy)? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 6 of the top 10 GCP resource hierarchy and IAM interview questions.

Short answer (30 seconds): IAM answers who can do what. Organization Policy answers what is allowed at all, no matter who asks. For example, IAM can say Anna may create a VM. Org Policy can say no VM may have an external IP. So even an Owner cannot break that rule. I use IAM for access and Org Policy for guardrails, and I set both as high in the hierarchy as it makes sense.

GCP interview question 6: IAM vs Org Policy - model answer slide

 

What is the interviewer really asking?

Do you separate access control (IAM) from configuration guardrails (Org Policy)?

IAM vs Org Policy in plain English

  • IAM = WHO can do WHAT
  • Org Policy = WHAT is allowed to exist or be configured
  • Both inherit down the hierarchy

Easy picture: IAM decides who holds the key. Org Policy is the building rule, such as 'no open flames', and it applies even to the owner.

Detailed explanation

  • IAM works on principals and permissions. Org Policy works on resource configuration through constraints, for example restricting allowed regions, disabling service account key creation, or requiring OS Login.
  • Org Policy constraints are enforced even for highly privileged users, because they restrict the resource, not the person. Changing them needs a specific role (Organization Policy Administrator).
  • Both inherit down the hierarchy. For Org Policy, a child can inherit, merge or override depending on the constraint and the rule you set, so read the constraint behaviour carefully.
  • Typical senior answer: use both together. IAM for least-privilege access, Org Policy for baseline security guardrails, deny/PAB for hard limits.

Example commands

gcloud org-policies list --organization=ORG_ID
gcloud org-policies describe constraints/iam.disableServiceAccountKeyCreation --organization=ORG_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

  • Thinking Org Policy replaces IAM. It does not grant anything.
  • Applying a restrictive constraint at the org top without a dry-run or exception path.
  • Not knowing that Org Policy can be tested in dry-run mode before enforcement.

Follow-up questions to expect

  • Name three useful constraints. (Allowed locations, no SA key creation, no public IPs on VMs.)
  • How do you give one project an exception? (Override at the project, with approval and audit.)

How the answer changes by role

Role What to emphasise
Architect Define the guardrail baseline as part of the landing zone.
Data Engineer Know location constraints for data residency.
DevOps Engineer Troubleshoot 'constraint violated' failures in pipelines.
Platform Engineer Manage constraints and exceptions as a controlled process.

Senior tip

Use the one-liner: 'IAM is who, Org Policy is what.' Then add a concrete example.

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.