Interviewers ask, "What are allow policies, deny policies and Principal Access Boundary policies? How do they work together?" because they want to know: Do you know modern IAM features beyond the basics - deny policies and PAB? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 4 of the top 10 GCP resource hierarchy and IAM interview questions.

Short answer (30 seconds): Allow policies grant access. Deny policies block specific permissions for specific principals, and a deny wins over an allow. Principal Access Boundary, or PAB, is different: it sets the outer limit of which resources a group of principals is even eligible to access. IAM checks all of them. So a user can only get access if they are inside their boundary, not denied, and also granted a role.


 

GCP interview question 4: Allow, Deny, PAB - model answer slide

What is the interviewer really asking?

Do you know modern IAM features beyond the basics - deny policies and PAB?

Allow, Deny, PAB in plain English

  • Allow = grants access
  • Deny = blocks access, wins over allow
  • PAB = limits which resources a principal can ever use

Easy picture: At an airport: the boarding pass is the allow policy, the no-fly list is the deny policy, and the terminal boundary is the PAB - it decides which areas you may enter at all.

Detailed explanation

  • Allow policies are the classic IAM bindings that most people know.
  • Deny policies attach to an organization, folder or project and list principals, denied permissions, and optional conditions. Limits: up to 500 deny policies per resource (check current limits in the IAM quotas page).
  • PAB policies are part of the IAM v3 API and are always children of the organization. A PAB policy is bound to a set of principals and lists the resources they are eligible to access. If a resource is not in the boundary, access is blocked, even if an allow policy grants it. Up to 10 PAB policies can be bound to one principal set.
  • Think of it as three gates: eligible (PAB), not blocked (deny), granted (allow). Always confirm the exact evaluation behaviour in the current Google Cloud docs, because this area is still evolving.

Example commands

gcloud iam policies list --attachment-point=cloudresourcemanager.googleapis.com/projects/PROJECT_ID --kind=denypolicies --format=yaml
# Use Policy Troubleshooter in the console to see allow + deny + PAB for a principal and permission

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

  • Using deny for everything. Prefer least-privilege allow, and use deny for hard guardrails.
  • Forgetting that PAB can block a user who has a valid allow policy, so 'it worked yesterday' tickets happen.
  • Not testing deny rules with the Policy Troubleshooter before rolling out.

Follow-up questions to expect

  • Give a real use case for deny. (Block deleting production buckets for everyone except a break-glass group.)
  • Give a use case for PAB. (Contractors can only touch projects in their own folder.)

How the answer changes by role

Role What to emphasise
Architect Use PAB and deny as hard guardrails on top of a clean allow model.
Data Engineer Deny delete on critical datasets except for a pipeline owner group.
DevOps Engineer Manage deny/PAB as code and test them before rollout.
Platform Engineer Ship guardrails as default so product teams cannot weaken them.

Senior tip

This is the freshest topic in IAM. Showing you know PAB signals you keep up with the platform.

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.