Technical interview questions for software engineers — languages, databases, web, cloud, DevOps, and fundamentals. Browse all topics.

  • PHP Interview Questions

  • OOP Interview Questions

  • jQuery Interview Questions

  • MySQL Interview Questions

  • JavaScript Interview Questions

  • HR Interview Questions

  • HTML Interview Questions

  • C/C++ Interview Questions

  • Showing posts with label Google Cloud IAM. Show all posts
    Showing posts with label Google Cloud IAM. Show all posts

    GCP IAM Interview Revision Sheet: 10 Answers

    This one-page GCP IAM interview revision sheet gives you the key idea of each of the top 10 resource hierarchy and IAM questions in a few words. Read it the day before your interview, then open the full post for any line you cannot explain.

    How to use this sheet

    Skim the table once to see the whole map. Pick any row where the key idea feels fuzzy and read the linked article for a 30-second spoken answer. On interview day, use the checklist below after you can explain every row without reading. If you have five minutes left, rehearse questions 1 (hierarchy), 4 (allow/deny/PAB), and 10 (permission denied)—those three show up most often in senior GCP conversations.

    Return to the GCP interview questions hub for glossary, gcloud cheat sheet, and common mistakes.

    10 answers in 10 words

    # Topic Key idea
    1 Resource Hierarchy Org → Folder → Project → Resource
    2 IAM Inheritance Allow is additive; use deny to block
    3 Role Types Predefined roles first; custom roles rarely
    4 Allow, Deny, PAB Three gates: eligible, not denied, granted
    5 Folder Design Folders follow policy, not the org chart
    6 IAM vs Org Policy IAM = who. Org Policy = what
    7 Least Privilege at Scale Groups, code, review, expiry
    8 Conditions & Tags Conditions + tags = 'only if'
    9 Org Admin & Break-glass Few admins, split duties, test break-glass
    10 Permission Denied Troubleshooter first, then other layers

    Interview-day checklist

    • Draw the Organization, Folders, Projects, Resources tree and say what flows down.
    • Name one real example for each answer.
    • Say least privilege, groups and code review in your answers.
    • Know your troubleshooting steps for 'permission denied'.

    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.


    Bookmark and Share

    10 Common GCP IAM Mistakes Interviewers Look For

    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.


    Bookmark and Share

    GCP IAM & Resource Hierarchy Interview Questions

    If you are preparing for a Google Cloud interview, the resource hierarchy and IAM are almost always the first topics. This guide lists the top 10 GCP resource hierarchy and IAM interview questions that I would expect at senior level for Architect, Data Engineer, DevOps and Platform Engineer roles. Each question links to a full post with a 30-second answer, the concept in plain English, common mistakes and tips by role.

    In one sentence: Google Cloud is a tree (Organization, Folders, Projects, Resources). Access rules and company rules are set at one level and flow down. Most IAM interview questions test whether you understand that flow.

    GCP resource hierarchy diagram: Organization, Folders, Projects and Resources with policies flowing down

     

    Who is this guide for?

    Engineers with some cloud experience who want clear, short answers in simple English. If some words are new, start with the GCP IAM glossary for beginners.

    The 10 questions and short answers

    1. Explain the GCP resource hierarchy. Why does it matter? GCP has four levels: Organization at the top, then Folders, then Projects, then the actual resources like VMs and buckets.
    2. How does IAM policy inheritance work? Can a child remove a parent's grant? Allow policies are additive.
    3. Basic vs predefined vs custom roles - which do you use and when? Basic roles like Owner, Editor and Viewer are very broad, so I avoid them in production.
    4. What are allow policies, deny policies and Principal Access Boundary policies? How do they work together? Allow policies grant access.
    5. How would you design the folder structure for a company with 200 projects? I design folders around where policy differs, not around the org chart.
    6. What is the difference between IAM and Organization Policy? IAM answers who can do what.
    7. How do you manage least privilege at scale across hundreds of users and projects? I never grant roles to individual users.
    8. How do IAM Conditions and Tags help control access? An IAM Condition adds an 'only if' to a role binding.
    9. Who should have Organization Administrator access? How do you protect the top of the hierarchy? Very few people, and never daily-use accounts.
    10. A user says 'permission denied'. How do you troubleshoot it? First I get the exact principal, the exact permission and the exact resource from the error.

    How to use this list

    1. Read each short answer, then open the full post for the concept and mistakes.
    2. Say each answer aloud once. Time yourself: about 30 seconds.
    3. Use the revision sheet the day before your interview.
    4. Check the common mistakes list. Interviewers often probe these.

    More resources in this series


    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.


    Bookmark and Share

    GCP IAM gcloud Commands Cheat Sheet (Interview)

    These gcloud commands support the top 10 GCP IAM and resource hierarchy interview questions. You do not need to memorise them, but showing one real command in an interview makes your answer more believable.

    Important: replace ORG_ID, FOLDER_ID, PROJECT_ID and email addresses with your own values. Flags and features change, so check gcloud help and the current documentation before running anything in a real environment.

    Commands by interview question

    Q1. Resource Hierarchy

    gcloud organizations list
    gcloud resource-manager folders list --organization=ORG_ID
    gcloud projects list --filter='parent.id=FOLDER_ID'

    Read the full answer: GCP Resource Hierarchy Explained: Interview Q&A

    Q2. IAM Inheritance

    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

    Read the full answer: GCP IAM Policy Inheritance: Can a Child Remove a Role?

    Q3. Role Types

    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=global

    Read the full answer: GCP IAM Roles: Basic vs Predefined vs Custom

    Q4. Allow, Deny, PAB

    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

    Read the full answer: GCP IAM Deny Policy vs Principal Access Boundary

    Q5. Folder Design

    # Terraform sketch
    resource "google_folder" "prod" {
      display_name = "Production"
      parent       = "organizations/${var.org_id}"
    }

    Read the full answer: GCP Folder Structure Best Practices for 200 Projects

    Q6. IAM vs Org Policy

    gcloud org-policies list --organization=ORG_ID
    gcloud org-policies describe constraints/iam.disableServiceAccountKeyCreation --organization=ORG_ID

    Read the full answer: IAM vs Organization Policy in GCP: Interview Answer

    Q7. Least Privilege at Scale

    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'

    Read the full answer: GCP Least Privilege at Scale: Interview Answer

    Q8. Conditions & Tags

    # Condition expression examples
    request.time < timestamp('2026-12-31T00:00:00Z')
    resource.matchTag('ORG_ID/env', 'dev')

    Read the full answer: GCP IAM Conditions and Tags Explained

    Q9. Org Admin & Break-glass

    gcloud organizations get-iam-policy ORG_ID
    # Alert idea: log filter on SetIamPolicy at organization level

    Read the full answer: GCP Organization Admin and Break-Glass Account

    Q10. Permission Denied

    gcloud policy-troubleshoot iam //cloudresourcemanager.googleapis.com/projects/PROJECT_ID --principal-email=user@example.com --permission=storage.objects.get
    gcloud logging read 'protoPayload.status.code=7' --project=PROJECT_ID --limit=20

    Read the full answer: GCP Permission Denied Error: How to Troubleshoot

    Tips for using commands in an interview

    • Describe what the command shows, not just the syntax.
    • Mention that production changes go through code review (for example Terraform).
    • Never say you grant Owner to fix an error. Use the troubleshooting steps in GCP Permission Denied Error: How to Troubleshoot.

    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.


    Bookmark and Share

    GCP IAM Glossary for Beginners: Simple Definitions

    GCP and IAM have many new words. This glossary explains the terms used in the top 10 GCP resource hierarchy and IAM interview questions in simple words, with how to say them out loud.

    Remember: IAM decides who can do what. Organization Policy decides what is allowed to exist. Both flow down the hierarchy.


    GCP resource hierarchy diagram: Organization, Folders, Projects and Resources with policies flowing down

     

    GCP IAM terms in simple words

    Word Plain meaning How to say it
    GCP / Google Cloud Google's service where companies rent computers, storage and databases "G, C, P"
    Cloud Computers you rent over the internet instead of owning them cloud
    IAM Identity and Access Management: the system that decides who can do what "eye-am"
    Organization The top of the tree: your whole company
    Folder A group box that holds projects
    Project A workspace for one app or team; holds services, billing link, limits and access rules
    Resource A real thing you use: a virtual machine, a storage bucket, a database table
    Principal A person, group or program asking for access
    Role A bundle of permissions, like a job badge
    Permission One small action, such as "read a file"
    Policy A written rule
    Allow policy / Deny policy A rule that grants access / a rule that blocks access
    PAB (Principal Access Boundary) A rule that limits which resources a group of principals can ever use "P, A, B"
    Organization Policy Company rules about what is allowed to exist (for example, no public IP addresses)
    Least privilege Give only the access that is needed, and nothing more
    Terraform A tool where you write your cloud setup as code files "terra-form"
    Quota A usage limit for a project "kwoh-ta"
    Break-glass account An emergency admin account, locked away and used only if normal admins cannot get in
    VPC Service Controls A security fence around Google services "V, P, C service controls"
    Audit logs The written record of every request in the cloud

    Where to go next

    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.


    Bookmark and Share

    GCP Permission Denied Error: How to Troubleshoot

    Interviewers ask, "A user says 'permission denied'. How do you troubleshoot it?" because they want to know: Do you have an ordered troubleshooting method, and do you avoid 'just grant Owner'? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 10 of the top 10 GCP resource hierarchy and IAM interview questions.

    Short answer (30 seconds): First I get the exact principal, the exact permission and the exact resource from the error. Then I use Policy Troubleshooter. It checks allow, deny and principal access boundary policies and tells me which one blocks the request. If IAM looks correct, I check Organization Policy constraints, VPC Service Controls, and conditions or expired grants. Finally I read the audit logs for the real denied call. I fix it at the right level and never by granting Owner.


    GCP interview question 10: Permission Denied - model answer slide

     

    What is the interviewer really asking?

    Do you have an ordered troubleshooting method, and do you avoid 'just grant Owner'?

    Permission Denied in plain English

    • Confirm principal, permission, resource
    • Check allow, deny, PAB with Policy Troubleshooter
    • Then Org Policy, VPC-SC, and audit logs

    Easy picture: Like a doctor: collect symptoms (error), run the right test (Policy Troubleshooter), check other body systems (Org Policy, VPC-SC, API), then treat the cause - not just the symptom.

    Detailed explanation

    • Step 1: capture the error. It usually names the permission, such as bigquery.tables.getData, and the resource.
    • Step 2: run Policy Troubleshooter with principal + resource + permission. It examines allow, deny and PAB policies and shows which ones apply and how.
    • Step 3: if IAM is fine, look at other layers: Org Policy constraints, VPC Service Controls perimeters (the error will mention a perimeter), IAM Conditions that expired, and API not enabled in the project.
    • Step 4: confirm in Cloud Audit Logs. Then fix with the smallest change at the lowest sensible level, and record why.

    Example commands

    gcloud policy-troubleshoot iam //cloudresourcemanager.googleapis.com/projects/PROJECT_ID --principal-email=user@example.com --permission=storage.objects.get
    gcloud logging read 'protoPayload.status.code=7' --project=PROJECT_ID --limit=20

    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 Owner to 'make the error go away'.
    • Checking only the project policy and missing inherited grants or a deny policy.
    • Missing that the API is disabled or a VPC-SC perimeter is blocking the call.

    Follow-up questions to expect

    • What if the user has the role but still fails? (Condition, deny policy, PAB, VPC-SC, or wrong resource.)
    • How do you stop repeat tickets? (Document the access model; self-service with expiry.)

    How the answer changes by role

    Role What to emphasise
    Architect Design the access model so failures are easy to explain.
    Data Engineer Know the BigQuery job vs data permission split.
    DevOps Engineer Pipeline failures: check service account, impersonation, API enablement.
    Platform Engineer Provide a self-service troubleshooting guide for product teams.

    Senior tip

    Tell it as a step-by-step story. Interviewers love a calm, ordered debugging path.

    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.

    Watch the video

    Prefer to watch? See the full video with all 10 questions: GCP Resource Hierarchy & IAM: Top 10 Senior Interview Questions. There is also a 1-minute Short for this question: watch the Short.

    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.


    Bookmark and Share

    GCP Organization Admin and Break-Glass Account

    Interviewers ask, "Who should have Organization Administrator access? How do you protect the top of the hierarchy?" because they want to know: Do you think about security governance, separation of duties and incident readiness? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 9 of the top 10 GCP resource hierarchy and IAM interview questions.

    Short answer (30 seconds): Very few people, and never daily-use accounts. I use a small group with strong multi-factor authentication and separate duties, so the person who manages the hierarchy is not the same as the one who manages security policy or billing. I keep a break-glass account that is stored safely, tested, and triggers alerts when used. Every change at the organization level is logged and reviewed.


    GCP interview question 9: Org Admin & Break-glass - model answer slide

     

    What is the interviewer really asking?

    Do you think about security governance, separation of duties and incident readiness?

    Org Admin & Break-glass in plain English

    • Very few people, in a group, with MFA
    • Separate duties: org admin, security admin, billing admin
    • Break-glass account, monitored and tested

    Easy picture: A bank vault needs two keys held by different people. The emergency key sits in a sealed envelope, and you test it once a year to be sure it still works.

    Detailed explanation

    • Organization Administrator can set IAM policy on the organization and manage the hierarchy, which means very high impact. It does not give direct access to every resource's data, but an admin can grant themselves access, so treat it as top privilege.
    • Separation of duties: split roles such as Organization Administrator, Security Admin, Billing Account Administrator, and Organization Policy Administrator across different groups.
    • Super admin accounts in Cloud Identity/Workspace sit above GCP IAM. Protect them with hardware security keys and use them only in emergencies.
    • Monitor: send Admin Activity audit logs to a protected log bucket and alert on org-level IAM changes.

    Example commands

    gcloud organizations get-iam-policy ORG_ID
    # Alert idea: log filter on SetIamPolicy at organization level

    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

    • Individual users as Org Admin instead of a group.
    • One person holding every admin role.
    • A break-glass account no one has tested in a year.

    Follow-up questions to expect

    • What if the only admin leaves? (Recovery path via super admin; test it.)
    • How do you audit admin actions? (Admin Activity audit logs, sinks, alerts.)

    How the answer changes by role

    Role What to emphasise
    Architect Design the admin model and separation of duties.
    Data Engineer Know who approves access to sensitive datasets.
    DevOps Engineer Set up alerting on org-level IAM changes.
    Platform Engineer Run the break-glass process and rehearse it.

    Senior tip

    Mention testing the break-glass process. It shows you have seen real incidents.

    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.


    Bookmark and Share

    GCP IAM Conditions and Tags Explained

    Interviewers ask, "How do IAM Conditions and Tags help control access?" because they want to know: Can you scope access precisely without creating a mess of bindings? This post gives you a ready 30-second answer, the concept in plain English, common mistakes and tips for different roles. It is question 8 of the top 10 GCP resource hierarchy and IAM interview questions.

    Short answer (30 seconds): An IAM Condition adds an 'only if' to a role binding. For example, only until Friday, or only on resources with the tag environment equals development. Tags are key-value pairs attached to resources and they are inherited down the hierarchy. Together they let me say: this group gets this role only on development resources. It reduces the number of separate bindings and keeps policy readable.


    GCP interview question 8: Conditions & Tags - model answer slide

     

    What is the interviewer really asking?

    Can you scope access precisely without creating a mess of bindings?

    Conditions & Tags in plain English

    • Conditions add 'only if...' to a role binding
    • Tags label resources; conditions can read tags
    • Examples: expiry time, environment, resource name

    Easy picture: A condition is a sticky note saying 'only if'. Tags are coloured stickers on rooms. Together: 'this team may enter rooms with a green sticker, until Friday'.

    Detailed explanation

    • Conditions use a CEL expression, for example checking the request time or the resource name or type.
    • Tags are resource-manager tags: a tag key and tag value that you create at the organization or project, then bind to resources. Tags are inherited by child resources, which is why they work well with the hierarchy.
    • Pattern: bind a role to a group on a folder, and add a condition that matches the tag env=dev. The same group gets no access to resources tagged env=prod, even in the same folder.
    • Limits: not every service supports every condition attribute. Test with Policy Troubleshooter and keep expressions simple.

    Example commands

    # Condition expression examples
    request.time < timestamp('2026-12-31T00:00:00Z')
    resource.matchTag('ORG_ID/env', 'dev')

    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

    • Complex conditions that no one can read in six months.
    • Assuming every resource type supports every condition attribute.
    • Using labels (billing/cost) where you need tags (access control). They are different things.

    Follow-up questions to expect

    • Labels vs tags? (Labels = metadata for billing/filtering; tags = can drive policy and conditions.)
    • Can tags be used with Org Policy? (Yes, conditional org policies by tag.)

    How the answer changes by role

    Role What to emphasise
    Architect Use tags to express environment and data sensitivity across projects.
    Data Engineer Tag datasets by sensitivity and restrict access by condition.
    DevOps Engineer Apply tags in Terraform at project creation.
    Platform Engineer Make tagging mandatory in the project factory.

    Senior tip

    Always add 'labels vs tags' - it is a classic follow-up trap.

    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.


    Bookmark and Share

    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.


    GCP interview question 7: Least Privilege at Scale - model answer slide

     

    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

    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.


    Bookmark and Share

    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.

    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.


    Bookmark and Share

    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?

     

    GCP interview question 5: Folder Design - model answer slide


    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

    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.


    Bookmark and Share

    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.


     

    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.


    Bookmark and Share

    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.


    GCP interview question 3: Role Types - model answer slide

     

    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=global

    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

    • 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

    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.


    Bookmark and Share

    GCP IAM Policy Inheritance: Can a Child Remove a Role?

    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.


    Bookmark and Share