GCP Least Privilege at Scale: Interview Answer
Interviewers ask, "How do you manage least privilege at scale across hundreds of users and projects?" because they want to know: Do you have operational maturity: groups, code, reviews, expiry? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 7 of the top 10 GCP resource hierarchy and IAM interview questions.
Short answer (30 seconds): I never grant roles to individual users. I use groups that match job functions, and I grant predefined roles to those groups at the lowest sensible level. Everything is defined in Terraform, so changes get reviewed. Then I check regularly with IAM Recommender, which shows unused permissions, and Policy Analyzer, which shows who can access what. For sensitive access I use time-limited or just-in-time grants.
What is the interviewer really asking?
Do you have operational maturity: groups, code, reviews, expiry?
Least Privilege at Scale in plain English
- Grant to groups, not individuals
- Predefined roles at the right level
- Review with IAM Recommender and Policy Analyzer
Easy picture: A gym gives access by membership plan (groups) with an end date, not by handing personal keys to each member. Reports show who never used the pool, so you can reduce the plan.
Detailed explanation
- Groups: manage membership in your identity provider. Access reviews become group reviews, and leavers lose access automatically.
- Code: IAM bindings in Terraform give history, review and rollback. Avoid manual console grants except for emergencies, and then log them.
- Review: IAM Recommender looks at permission usage history and suggests smaller roles. Policy Analyzer answers 'who can access this resource?'. Both help during audits.
- Time-bound access: use IAM Conditions with an expiry for temporary access, and Privileged Access Manager for just-in-time elevation where available.
Example commands
gcloud asset analyze-iam-policy --organization=ORG_ID --identity='group:data-team@example.com'
gcloud projects add-iam-policy-binding PROJECT_ID --member='group:data-team@example.com' --role='roles/bigquery.dataViewer'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
- Nested groups that nobody can understand.
- Break-glass access that is never reviewed.
- Permanent access for a one-time task.
Follow-up questions to expect
- How do you handle contractors? (Separate group, expiry condition, PAB or folder boundary.)
- How do you prove compliance? (Policy Analyzer reports + audit logs.)
How the answer changes by role
| Role | What to emphasise |
|---|---|
| Architect | Define personas and role bundles, then review them quarterly. |
| Data Engineer | Separate pipeline service accounts from human analyst access. |
| DevOps Engineer | Terraform-managed bindings plus peer review. |
| Platform Engineer | Offer access-request workflows with expiry as a product. |
Senior tip
Say 'groups, code, review, expiry' - four words that cover the whole answer.
Practice
- Say the 30-second answer aloud without reading it, and time yourself.
- Draw the diagram from memory on paper.
- Explain it once to a junior engineer and once to a CTO.
Keep learning
- Main guide: GCP IAM & Resource Hierarchy Interview Questions (2026)
- Previous question: IAM vs Organization Policy in GCP: Interview Answer
- Next question: GCP IAM Conditions and Tags Explained
- New to GCP? Read the GCP IAM glossary for beginners
- Quick revision: GCP IAM interview revision sheet
- More topics: GCP interview questions and answers
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.
IAM vs Organization Policy in GCP: Interview Answer
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.
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_IDReplace 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
- Say the 30-second answer aloud without reading it, and time yourself.
- Draw the diagram from memory on paper.
- Explain it once to a junior engineer and once to a CTO.
Keep learning
- Main guide: GCP IAM & Resource Hierarchy Interview Questions (2026)
- Previous question: GCP Folder Structure Best Practices for 200 Projects
- Next question: GCP Least Privilege at Scale: Interview Answer
- New to GCP? Read the GCP IAM glossary for beginners
- Quick revision: GCP IAM interview revision sheet
- More topics: GCP interview questions and answers
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.
GCP Folder Structure Best Practices for 200 Projects
Interviewers ask, "How would you design the folder structure for a company with 200 projects?" because they want to know: Can you design for governance and growth instead of just drawing boxes? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 5 of the top 10 GCP resource hierarchy and IAM interview questions.
Short answer (30 seconds): I design folders around where policy differs, not around the org chart. A common start is top-level folders for Production, Non-Production, Shared Services like networking and security, and Sandbox. Under those I group by business unit or application. I keep it to three or four levels so inheritance stays easy to explain. Every folder should answer: what rule or access is different here?
What is the interviewer really asking?
Can you design for governance and growth instead of just drawing boxes?
Folder Design in plain English
- Group by what needs different rules: environment, risk, ownership
- Keep it shallow: 3-4 levels
- Add shared folders: Common/Networking, Security, Sandbox
Easy picture: Arrange a library by how the rules differ (open shelves, loan desk, restricted room), not by who donated the books. Donors change; rules do not.
Detailed explanation
- Start with the question: what rules differ? Production needs stricter policies, more audit, fewer humans with access. Sandbox needs freedom and a budget cap. Shared services such as networking, logging and security need their own owners.
- A common pattern: Org → (Common, Production, Non-Production, Sandbox) → business unit or team → applications. Another common pattern puts business unit first. Pick the one that matches how policies and ownership really differ in your company.
- Avoid deep trees. Each level adds a place where someone can attach a surprising grant or constraint. Many teams keep three or four levels, though Google allows up to ten.
- Plan the 'project factory': new projects are created by automation, named by a standard, labelled, linked to billing, and placed in the right folder.
Example commands
# Terraform sketch
resource "google_folder" "prod" {
display_name = "Production"
parent = "organizations/${var.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
- Folders per team that is later reorganised, forcing mass moves.
- Mixing prod and non-prod in the same folder because it was quicker.
- No sandbox, so engineers experiment in production projects.
Follow-up questions to expect
- Where would the shared VPC host project go? (A shared services/networking folder.)
- How do you handle a company acquisition? (A separate folder first, then integrate.)
How the answer changes by role
| Role | What to emphasise |
|---|---|
| Architect | Align folders with the landing zone blueprint. |
| Data Engineer | Ask for raw/curated/sandbox separation by environment. |
| DevOps Engineer | Implement folders and bindings as Terraform with review. |
| Platform Engineer | Own the project factory that places projects in folders automatically. |
Senior tip
Open with 'where does policy differ?' and the interviewer will relax - you are thinking in rules, not boxes.
Practice
- Say the 30-second answer aloud without reading it, and time yourself.
- Draw the diagram from memory on paper.
- Explain it once to a junior engineer and once to a CTO.
Keep learning
- Main guide: GCP IAM & Resource Hierarchy Interview Questions (2026)
- Previous question: GCP IAM Deny Policy vs Principal Access Boundary
- Next question: IAM vs Organization Policy in GCP: Interview Answer
- New to GCP? Read the GCP IAM glossary for beginners
- Quick revision: GCP IAM interview revision sheet
- More topics: GCP interview questions and answers
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.
GCP IAM Deny Policy vs Principal Access Boundary
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.
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 permissionReplace 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
- Say the 30-second answer aloud without reading it, and time yourself.
- Draw the diagram from memory on paper.
- Explain it once to a junior engineer and once to a CTO.
Keep learning
- Main guide: GCP IAM & Resource Hierarchy Interview Questions (2026)
- Previous question: GCP IAM Roles: Basic vs Predefined vs Custom
- Next question: GCP Folder Structure Best Practices for 200 Projects
- New to GCP? Read the GCP IAM glossary for beginners
- Quick revision: GCP IAM interview revision sheet
- More topics: GCP interview questions and answers
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.
GCP IAM Roles: Basic vs Predefined vs Custom
Interviewers ask, "Basic vs predefined vs custom roles - which do you use and when?" because they want to know: Do you apply least privilege, and do you know the maintenance cost of custom roles? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 3 of the top 10 GCP resource hierarchy and IAM interview questions.
Short answer (30 seconds): Basic roles like Owner, Editor and Viewer are very broad, so I avoid them in production. Predefined roles are my default because Google maintains them and updates permissions as services change. I create custom roles only when a predefined role gives too much and I need an exact set of permissions. Custom roles add maintenance work, so I keep them few and manage them in code.
What is the interviewer really asking?
Do you apply least privilege, and do you know the maintenance cost of custom roles?
Role Types in plain English
- Basic (Owner/Editor/Viewer) = too broad for production
- Predefined = default choice, Google maintains them
- Custom = only when predefined is too wide; you maintain it
Easy picture: Roles are job badges. A basic role is a master badge (opens too much). A predefined role is a standard staff badge. A custom role is a special badge you design - and you must keep updating it.
Detailed explanation
- Basic roles (Owner, Editor, Viewer) were created before fine-grained IAM. Editor alone has thousands of permissions across most services. They are fine for a personal sandbox, not for shared production.
- Predefined roles are service-specific and created by Google, e.g. roles/bigquery.dataViewer. When a service adds a new feature, Google updates the role. This is a benefit and a small risk: review changes for sensitive roles.
- Custom roles are defined by you from a list of permissions at organization or project level. Some permissions cannot be used in custom roles, and you must update them yourself when a service adds new permissions.
- Practical order of choice: smallest predefined role → combination of two predefined roles → custom role. Use the IAM Recommender to find over-granted roles.
Example commands
gcloud iam roles describe roles/bigquery.dataViewer
gcloud iam roles create customDeployer --organization=ORG_ID --file=role.yaml
gcloud recommender recommendations list --recommender=google.iam.policy.Recommender --project=PROJECT_ID --location=globalReplace ORG_ID, FOLDER_ID and PROJECT_ID with your own values. Check gcloud help for current flags before you use a command.
Common mistakes
- Giving roles/editor to a service account because 'it just works'.
- Creating dozens of custom roles that nobody owns or updates.
- Assuming a custom role updates itself when a service adds permissions. It does not.
Follow-up questions to expect
- How do you find unused permissions? (IAM Recommender, based on usage history.)
- Org-level or project-level custom roles? (Org level if reused across projects.)
How the answer changes by role
| Role | What to emphasise |
|---|---|
| Architect | Define a small catalog of approved roles per persona. |
| Data Engineer | Know the BigQuery roles well: dataViewer, dataEditor, jobUser, user. |
| DevOps Engineer | Pipelines get narrow deploy roles, never Editor. |
| Platform Engineer | Publish role bundles (via groups) as part of the platform contract. |
Senior tip
Name one real predefined role and one real reason you would build a custom one.
Practice
- Say the 30-second answer aloud without reading it, and time yourself.
- Draw the diagram from memory on paper.
- Explain it once to a junior engineer and once to a CTO.
Keep learning
- Main guide: GCP IAM & Resource Hierarchy Interview Questions (2026)
- Previous question: GCP IAM Policy Inheritance: Can a Child Remove a Role?
- Next question: GCP IAM Deny Policy vs Principal Access Boundary
- New to GCP? Read the GCP IAM glossary for beginners
- Quick revision: GCP IAM interview revision sheet
- More topics: GCP interview questions and answers
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.
