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.