Cloud Resource Manager is the Google Cloud service that lets you create, organize, find, and protect the containers that hold all your cloud resources.

A resource is anything you can create in Google Cloud: a virtual machine, a database, a storage bucket, a network, a message queue, or a repository of code. A container is a place that holds resources and gives them shared rules. Cloud Resource Manager manages three kinds of containers: organizations, folders, and projects. Together they form what Google calls the resource hierarchy, which is a tree: one organization at the top, folders below it, projects below those, and finally the resources themselves at the bottom.

The service does four big jobs. It lets you create and arrange these containers. It gives you a single place to attach permissions, so a rule set once at a high level applies to everything beneath it. It lets you attach policies, such as “no server in this department may have a public internet address”. And it lets you label and tag containers so that people, reports, and rules can find and treat them correctly.

Where it sits among other services

Most Google Cloud services you hear about, such as Compute Engine for virtual machines or Cloud Storage for files, do something with your data or your programs. Cloud Resource Manager is different. It does not run your application. It organizes the place where your application lives. Because of this, it is easy to ignore on day one and painful to fix on day five hundred. Experienced architects treat it as the foundation of the building: invisible when done well, disastrous when done badly.

It is also a service you never really switch on. The moment you create your first project, you are already using it. The programming interface behind it is called the Cloud Resource Manager API, and the web console page called “Manage resources” is its everyday face.

To appreciate the hierarchy, picture what cloud life looked like without it.

In the early days of Google Cloud, the main unit was the project. A project was a simple bucket: you created one, turned on the services you needed, and started working. For a single developer or a small team, that was enough. Projects belonged to individual user accounts, usually someone’s personal email address.

As large companies arrived, cracks appeared. A company might have two thousand projects, each created by a different employee. When one of those employees left the company, the projects they owned could be left orphaned, with no administrator. There was no central place to say “every project in the finance department must obey these rules”. There was no easy way to see the full list of projects, or to cut costs across a department. Security teams could not enforce anything company-wide.

Google responded by adding the organization and folder levels above projects. The organization became the single root that the company owns, rather than any individual employee. Folders let the company mirror its own structure, such as departments, teams, or environments. Along with these came central policy tools, notably the Organization Policy Service, so rules could be set once and enforced everywhere beneath.

The five pains it removes

Four levels make up the entire tree. Learn each one, and you understand ninety percent of Cloud Resource Manager.

The organization

The organization is the root, the very top of the tree. It represents your company. It is tied to your company’s identity domain, which comes from either Google Workspace, Google’s business email and office suite, or Cloud Identity, a lighter product that provides company user accounts without email. When your domain gets an organization resource, every project created by people in that domain can live beneath it.

The organization has a permanent numeric identifier. It also has special administrator roles. Whoever holds those roles can see and control the whole tree, so they are handed out sparingly. This is the most powerful level, which makes it the most important to protect.

Folders

Folders are optional groupings that sit between the organization and projects. You can place folders inside other folders to build a deeper tree, though Google sets a maximum depth, so check the current limits before designing something elaborate. Folders exist for two reasons: to mirror how your company is organized, and to give you a convenient level at which to attach permissions and policies.

Projects

A project is the basic working container. Every resource you create must live in exactly one project. A project is also the place where you enable services (for example, turning on the database service), where quotas are tracked, where API traffic is counted, and where billing is attached. If the organization is the company and folders are departments, a project is a workspace where real work happens.

Resources

Resources are the actual cloud objects. A virtual machine, a storage bucket, a database instance, and a network are all resources. Each resource has exactly one parent project. The project’s own parent is a folder or the organization.

flowchart TD
  Org["Organization: example-company.com"] --> FProd["Folder: Production"]
  Org --> FDev["Folder: Development"]
  Org --> FShared["Folder: Shared Services"]
  FProd --> FPay["Folder: Payments"]
  FProd --> FShop["Folder: Shopping"]
  FPay --> P1["Project: payments-prod"]
  FShop --> P2["Project: shop-web-prod"]
  FDev --> P3["Project: shop-web-dev"]
  FShared --> P4["Project: central-logging"]
  FShared --> P5["Project: network-hub"]
  P1 --> R1["Cloud SQL database"]
  P1 --> R2["Compute Engine VMs"]
  P2 --> R3["Cloud Run service"]
  P2 --> R4["Storage bucket"]
    

The golden rule of the tree

Every resource has exactly one parent. This is what makes the structure a tree and not a tangled web. Because there is only one path from any resource up to the organization, the system can always answer the question “which rules apply here?” by walking up that one path. If a resource could have two parents with conflicting rules, the answer would be ambiguous. The single-parent rule keeps things predictable.

Every project carries three different identifiers. Mixing them up is one of the most common beginner errors, so this chapter slows down and explains each one.

The project name is only a display label. Two projects can even share the same name. It is meant for people reading a list. The project ID is a globally unique text string, unique across every Google Cloud customer in the world. Because it is unique and permanent, programs use it to point at a project. Once you pick it, you can never change it, and even after a project is deleted, the same ID generally cannot be reused. The project number is a long numeric value that Google generates. You cannot choose it. Some automatically created service identities include the project number in their names.

Why the permanent ID matters for naming

Because the ID is permanent and globally unique, people sometimes put sensitive or awkward words into it by accident, such as an internal codename or a customer name. That text then appears in logs, in web addresses, and in error messages forever. A good habit is to choose IDs that are neutral and structured, such as a company prefix, the service name, and the environment. Avoid personal names and confidential project codenames.

A sensible naming pattern

Cloud Resource Manager does not work alone. It sits at the center of a group of services that together control who, what, where, and how much.

Google does not publish every internal detail of how its management services are built, and that is normal. What we can describe confidently is the conceptual architecture: the roles each piece plays and how they cooperate. Treat this chapter as a clear mental model for architects and learners, not as an engineering blueprint of Google’s data centers.

The cast of characters

flowchart TD
  Console["Web Console"] --> API["Cloud Resource Manager API"]
  CLI["gcloud Command Line"] --> API
  IaC["Terraform and other automation"] --> API
  Libs["Client Libraries"] --> API
  API --> AuthN["Authentication"]
  AuthN --> IAM["IAM: who may do this?"]
  IAM --> Tree[("Resource Hierarchy Data")]
  Tree --> OPS["Organization Policy Service: is this allowed?"]
  Tree --> Bill["Cloud Billing link"]
  API --> Audit["Cloud Audit Logs"]
  Tree --> Asset["Cloud Asset Inventory"]
    

The ways people reach it

Humans usually start in the Google Cloud console, the web interface, where the “Manage resources” page shows the tree. Engineers prefer the gcloud command-line tool for quick actions. Larger teams use infrastructure as code, which means describing the desired hierarchy in text files that a tool then applies, so the structure is repeatable, reviewable, and version controlled. All three paths lead to the same API, and all three are subject to the same permission checks and policies.

When you ask “can this person create a server here?”, the system answers by walking up the tree. Understanding that walk explains almost every behavior you will see.

Every node has a name and a parent pointer

Each organization, folder, and project has a unique resource name that includes its type and numeric identifier. Each folder and project also records who its parent is. That is the entire structure: a collection of nodes, each pointing upward to one parent. There is no separate “tree object”. The tree exists because the pointers connect.

This is like a family tree drawn only with “who is my parent?” notes. To find someone’s grandparent, you follow their note, then the parent’s note. To find every ancestor, you keep following until you reach the root, which has no parent.

Policies are attached to nodes

An IAM allow policy is a list that says “this person or group has this role”. It can be attached to an organization, a folder, a project, or an individual resource. An organization policy is a rule about permitted behavior, and it can be attached to an organization, a folder, or a project. Tags, labels, and other metadata are also attached at various levels.

The evaluation walk

When a request arrives, such as “Asha wants to delete this storage bucket”, the system builds the list of ancestors for that bucket: the project, the folder or folders above it, and the organization. It then gathers the policies attached to the bucket itself and to each ancestor. For permissions, it asks: does any of these policies grant Asha a role that includes the needed permission? Allow policies are additive, which means grants from different levels are combined. If a higher level gives Asha a role, she keeps it at every level below. Then it checks whether any rule that denies or restricts the action applies, because such rules can override a grant.

sequenceDiagram
  participant U as Asha
  participant API as Resource Manager and Service API
  participant IAM as IAM
  participant H as Hierarchy Data
  participant OP as Organization Policy
  participant AL as Audit Logs
  U->>API: Request to delete a bucket
  API->>H: Find ancestors of the bucket
  H-->>API: Project, Folder, Organization
  API->>IAM: Collect policies on bucket and ancestors
  IAM-->>API: Combined grants and any denies
  API->>OP: Check constraints on the path
  OP-->>API: Allowed or blocked
  API->>AL: Record the decision
  API-->>U: Success or permission denied
    

Why changes can take a moment

Google Cloud is a global system with many servers. When you change a policy, the change must spread to the places that evaluate requests. In normal use this is quick, but it is not always instant. Google’s documentation notes that some changes take a short time to take effect everywhere. Teams therefore avoid designs that depend on a change being visible to the second, and they build in a short wait or a retry when automation depends on a fresh permission.

Operations are asynchronous

Creating or deleting a project is not a single instant step. When you ask for a new project, the system starts a long-running operation and returns a handle you can check. Behind the scenes it creates the project record, assigns the number, sets up default service accounts and settings, and links it into the hierarchy. Tools usually hide this by waiting for completion, but automation scripts must check the operation status before assuming the project is ready for use.

Inheritance is the single most important idea in the hierarchy. A rule set high up reaches everything beneath it, without anyone repeating it.

The basic idea

Inheritance means that a child receives the settings of its parents automatically. If you give a group of auditors the role “can view everything” at the organization level, they can view every folder, every project, and every resource in the company, now and in the future. New projects created tomorrow are covered the moment they appear. You did not need to do anything extra.

This is powerful and dangerous at the same time. It saves enormous effort, but a mistake at a high level spreads just as far. A grant of broad editing power at the top of the tree is a grant of editing power over the whole company.

Allow policies add up

For permission grants, Google Cloud unions the policies along the path. Suppose the following is true. At the organization level, the security team group has a viewer role. At the folder for payments, the payments developers group has an editor role. At the project, one individual has a database administrator role. What can the individual do inside the project? Whatever the project grant allows, plus anything inherited from above that applies to them. What can the payments developers do? Edit inside the payments folder and everything beneath it, but nothing in the sibling shopping folder.

An important consequence: you cannot take away an inherited allow by removing it at a lower level. If a group is granted access at the folder, simply deleting a grant at the project below does not remove it, because the folder-level grant still applies. To reduce access, you must change it at the level where it was granted, or use a deny rule, which we cover shortly.

flowchart TD
  O["Organization: Auditors can view"] --> F["Folder Payments: Payment developers can edit"]
  F --> P["Project payments-prod: Alex is database admin"]
  P --> R["Cloud SQL instance"]
  O -.->|"inherited"| F
  O -.->|"inherited"| P
  F -.->|"inherited"| P
  P -.->|"inherited"| R
    

An effective permission table

Deny policies

Because allows only add up, Google Cloud provides deny policies as a separate tool. A deny policy says “regardless of any allow, these people may not perform these actions here”. Deny rules are checked first, and they win. Teams use them sparingly for hard guard rails, such as preventing anyone except a small group from deleting projects, even if someone was granted a broad role by accident. Deny policies are also inherited down the tree.

Conditions

IAM conditions make a grant apply only when certain facts are true, such as “only until the end of this month” or “only for resources carrying this tag”. A temporary contractor can get access that expires on its own. A grant can apply only to the resources labeled for a specific team. Conditions are a way to make broad grants narrower without creating many separate grants.

IAM answers “who may act?”. Organization policies answer a different question: “what is allowed to exist or happen here at all?”

Imagine a company decides that no virtual machine may ever have a direct public internet address, because that would be too easy for attackers to find. If you used only IAM, you would have to trust every person with permission to create machines to remember the rule. Someone will forget. The Organization Policy Service lets the company state the rule once, at the top, and have the platform refuse any request that breaks it. Even an administrator with full permissions cannot override the restriction unless the policy itself is changed at the right level.

Constraints

Each rule is built from a constraint, which is a named restriction that Google defines, such as “restrict where resources may be created” or “disable creation of service account keys”. Constraints come in two flavors. A boolean constraint is simply on or off. A list constraint allows or denies a list of values, such as a list of permitted countries or regions. You choose which constraints to apply and set their values on a node in the tree.

How policies inherit

Organization policies inherit down the tree like permissions, but you have more control. At a lower node you may choose to inherit and merge with the parent’s rule, or to override and replace it. Using an override is a deliberate exception. For example, the company might forbid public addresses everywhere but allow an exception for one project that runs a public website behind carefully managed controls. The exception lives in one visible place that auditors can inspect.

flowchart TD
  O["Organization: block public VM addresses"] --> F1["Folder Production: inherits rule"]
  O --> F2["Folder Sandbox: inherits rule"]
  F1 --> P1["Project internal-api: inherits rule"]
  F1 --> P2["Project public-website: exception set here"]
  P2 --> R["Load balancer exposed deliberately"]
  F2 --> P3["Project experiments: inherits rule"]
    

Testing before enforcing

A new restriction can break existing applications. Suppose you forbid a certain action, and a hidden system you forgot about depends on it. Google provides ways to preview or test the effect of a policy before fully enforcing it, such as dry-run style modes and analysis tools. The safe approach is to observe first, fix what would break, and only then enforce. Check the current documentation for which constraints support which testing modes.

Folders tell you where something lives. Tags and labels tell you what it is, who owns it, and how it should be treated.

The tree can only express one hierarchy. But companies think in many dimensions at once. A project might belong to the Payments department, run in production, handle regulated data, and be funded by a particular cost center. You cannot express all of those in a single tree. That is why Google Cloud offers two kinds of metadata.

Labels

Labels are simple key and value pairs, such as “team equals payments” or “environment equals prod”. They are mainly for organizing, searching, and cost reporting. You can filter your billing report by a label to see how much each team spent. Labels are informal: they do not control access or enforce rules by themselves.

Tags

Tags, as Cloud Resource Manager defines them, are more formal. A tag is defined centrally at the organization or project level as a key with a set of allowed values. A tag value is then bound to a resource or container. Because tags are managed with their own permissions and have a controlled list of values, they can be used by IAM conditions and organization policies. For example, “only apply this strict rule to resources tagged environment equals production”.

A practical tagging scheme

Projects are not permanent. They are created, used, moved, shut down, and eventually erased. Knowing each stage prevents both clutter and disaster.

Creation

To create a project, a person or an automation needs permission to create projects in a particular parent. At creation you give the project a name, an ID, and a parent folder or organization. You then link it to a billing account so that paid services can be used. Without a billing link, most services will not run, and some projects stay limited to free capabilities.

A freshly created project is nearly empty. Services that you want, such as compute, storage, or databases, must be enabled one by one. Enabling a service, using what is called its API, is how you say “this project will use this capability”. Many teams automate this list so every new project starts in a consistent, safe state.

Active life

While active, a project accrues usage, enforces quotas, receives policy from its ancestors, and hosts resources. Over time, teams may move it to a different folder when reorganizing. A move changes the parent pointer, so the project immediately starts inheriting permissions and policies from its new ancestors and stops inheriting from the old ones. This can change what people can do, so moves should be reviewed carefully.

Liens: a safety latch

A lien is a lock placed on a project to prevent deletion. Think of it as a “do not remove” sign that only the owner of the lien can take down. Services and administrators use liens to protect critical projects, such as one holding shared networking, from being deleted by accident. Someone must first remove the lien before the project can be deleted.

Shutdown and recovery

When someone deletes a project, it does not vanish at once. It moves into a pending deletion state. The project stops serving traffic and its resources are shut down or become unavailable. For a recovery window, which Google documents as a number of days, the project can be restored. If nobody restores it before that window ends, the project and its resources are permanently erased and the data cannot be recovered. Always check Google’s current documentation for the exact length of the window, because it is a policy that could change.

stateDiagram-v2
  [*] --> Creating: Request new project
  Creating --> Active: Operation completes
  Active --> Active: Move, rename, enable services
  Active --> PendingDeletion: Delete requested
  PendingDeletion --> Active: Restore within window
  PendingDeletion --> Erased: Window ends
  Erased --> [*]
    

There is no single perfect layout. There are a few well-known patterns, each with strengths. The best design is the simplest one that matches how your company really works.

Pattern 1: environment first

The top-level folders are environments: Production, Non-production, and Shared. Beneath each, you place folders for teams or applications. The big benefit is security. Production can carry very strict policies and tight permissions, while non-production is looser for experimentation. A mistake in one environment is less likely to touch the other.

Pattern 2: business unit first

The top-level folders are departments or business units, and each contains its own environments beneath. This pattern respects company structure and makes cost reporting by department easy. The risk is that security policies for production must be repeated in many places, so automation is essential to keep them consistent.

Pattern 3: hybrid

A shared folder holds company-wide services such as networking, logging, and security tools. Business folders hold applications. Environments appear as folders or as separate projects within each application’s folder. Most large companies end up here because it balances central control with team independence.

flowchart TD
  Org["Organization"] --> Common["Folder: Common Services"]
  Org --> Prod["Folder: Production"]
  Org --> NonProd["Folder: Non-Production"]
  Org --> Sandbox["Folder: Sandbox"]
  Common --> Net["Project: network-hub"]
  Common --> Log["Project: central-logging"]
  Common --> Sec["Project: security-tools"]
  Prod --> PA["Folder: Team A"]
  Prod --> PB["Folder: Team B"]
  NonProd --> NA["Folder: Team A"]
  NonProd --> NB["Folder: Team B"]
  PA --> PAp["Project: team-a-app-prod"]
  NA --> NAp["Project: team-a-app-dev"]
    

How many projects?

A project is a strong boundary for permissions, quotas, billing, and blast radius, which is the amount of damage a single mistake can do. Because of that, modern guidance leans toward more, smaller projects rather than a few giant ones. A common starting rule is one project per application per environment. Projects are cheap to create, and clear boundaries are worth far more than the small administrative overhead.

Keep the tree shallow

Deep trees are hard to understand and make policies harder to reason about. Most organizations do well with three or four levels of folders at most. If you cannot draw your hierarchy on a single page, it is probably too complicated.

The hierarchy decides who pays and how much each team may use. Understanding these links keeps surprise bills away.

Projects and billing accounts

A billing account is the payment arrangement: it holds the card or invoice details. Each project is linked to exactly one billing account at a time, though one billing account can pay for many projects. Billing accounts are separate resources with their own permissions, so the person who can create projects is often not the person who may link them to the company’s payment arrangement. This separation lets finance control spending while engineers control building.

Seeing where money goes

Cloud Billing reports show spending by project, by service, and by label. Because a project is the unit that spending is attached to, a clean project layout produces a clean cost report almost for free. Labels add finer detail, such as which feature or customer a workload belongs to. Many teams export billing data to an analytics database so finance can build their own dashboards and spot trends.

Budgets and alerts

A budget is an amount you plan to spend. You can attach alerts that notify people when actual or predicted spending crosses chosen percentages of the budget. Alerts alone do not stop spending, but automation can react to them, for example by shutting down a test environment. This is particularly useful in sandbox folders where experimenting is encouraged but surprises are costly.

Quotas

A quota is a limit on how much of a service a project can use, such as how many virtual machines it may create or how many requests it may make per minute. Quotas exist to protect you from runaway usage and to protect Google’s shared platform. They are tracked per project, which is another reason separate projects keep teams from stepping on each other. If a noisy experiment uses up the shared quota in a giant project, a production application in the same project may suddenly be throttled.

The hierarchy is also a security structure. Where you place a person, a rule, or a project decides how far a mistake or an attacker can reach.

Roles that manage the tree itself

Cloud Resource Manager has its own set of roles, separate from roles that control individual services. Some govern the organization as a whole, some govern folders, and some are narrow, such as the ability to create projects or to move a project from one place to another. Google publishes the exact list of role names and permissions, and these can be extended over time, so use the current documentation when assigning them. In plain terms, the roles break down like this.

Principle of least privilege

The principle of least privilege says every person and every program should have only the minimum access needed for their job. In the hierarchy this translates into a simple habit: grant at the lowest level that still works. If a team needs access to one project, grant it on that project, not on the folder that contains fifty others. Grant broad roles at the top only when the job is truly company-wide, such as security auditing.

Use groups, never individuals

Grant roles to groups rather than individual people. When someone joins or leaves a team, you change group membership once, instead of hunting down dozens of direct grants. Groups also make reviews easier: an auditor can read a short list of group names instead of hundreds of email addresses.

Separation of duties

Important powers should be split among different people so no single person can do harm alone. The person who can approve spending should not be the same as the person who writes the code. The person who can change organization policies should not be the same as the person who deploys applications that must obey them. In Google Cloud, this means placing different roles in different groups and avoiding anyone holding every key.

Protecting the organization administrators

The accounts that hold the highest roles are the most attractive targets for attackers. Protect them with the strongest sign-in methods available, such as physical security keys, keep their number small, avoid using them for daily work, and monitor every action they perform. Many companies also keep a break-glass account, which is a very tightly controlled emergency login stored securely, to be used only if normal administrators are locked out. Every use of such an account should trigger an alert and a review.

Service accounts and hierarchy

Programs use service accounts as identities. A service account lives in a project, but it can be granted roles anywhere in the tree. A common risk is a service account created in a low-security test project that is later granted a powerful role in production. Because identities cross project boundaries easily, regularly review where each service account holds roles, and block creation of long-lived downloadable keys where possible, using the organization policy discussed earlier.

flowchart TD
  OrgAdm["Org Admins: very few, strong sign-in"] --> Org["Organization"]
  SecGrp["Security group: view and audit"] --> Org
  NetGrp["Network group"] --> FCommon["Folder: Common Services"]
  AppGrp["App team group"] --> FApp["Folder: App Team"]
  Bot["Deployment service account"] --> Proj["Single project only"]
  Org --> FCommon
  Org --> FApp
  FApp --> Proj
  Deny["Deny rule: only a small group may delete projects"] -.-> Org
    

Small projects are safer, but applications still need to talk to each other and share common services. A few well-known patterns let projects cooperate without giving up their boundaries.

Shared networking

Without sharing, every project builds its own private network, and connecting them becomes a tangle. Google Cloud offers Shared VPC, where one host project owns the network and other service projects use pieces of it. A central network team manages addresses, routing, and firewall rules in the host project, while application teams deploy servers in their own projects, connected to the shared network. The result is centralized control with distributed ownership.

Central logging and monitoring

Security teams want one place where all audit records are gathered, so investigators do not have to search a thousand projects. A common design is a dedicated logging project inside a locked-down shared folder. Log routing rules set at the organization or folder level automatically copy records from every project beneath into that project, where retention and access are controlled by the security team. Because routing is defined high in the tree, new projects are included automatically.

Central security and shared tools

Security scanning tools, secrets management for shared secrets, and shared build systems often live in their own shared projects. This keeps them separate from application teams, so a mistake in an application cannot damage the tools that protect everyone.

flowchart LR
  subgraph Shared["Folder: Common Services"]
    NH["network-hub host project"]
    LG["central-logging project"]
    SC["security-tools project"]
  end
  subgraph Apps["Folder: Applications"]
    A1["app-one-prod service project"]
    A2["app-two-prod service project"]
  end
  A1 -->|"uses subnets"| NH
  A2 -->|"uses subnets"| NH
  A1 -->|"audit logs routed"| LG
  A2 -->|"audit logs routed"| LG
  SC -->|"scans"| A1
  SC -->|"scans"| A2
    

Keep dependencies visible

Every shared service creates a dependency. If the network host project is deleted, every service project built on it breaks. That is why shared projects are the best candidates for liens, strict deny rules, and the smallest possible circle of administrators. Document these dependencies where everyone can see them.

A large tree is useless if you cannot see what is in it or what changed. Google Cloud gives you tools for watching and searching.

Audit logs for the hierarchy

Cloud Audit Logs record administrative actions: who created a project, who moved a folder, who changed a policy, and who granted a role. These records answer the questions every investigator asks: who, what, when, and from where. Admin activity records are on by default and cannot be switched off. Records of data reads and writes in services are typically optional and may need to be switched on, and they can grow large, so teams choose carefully which to keep.

Events worth alerting on

Cloud Asset Inventory

Cloud Asset Inventory maintains a searchable, time-aware record of resources and their access policies across the tree. You can ask questions such as “which projects have a public storage bucket?” or “who has the owner role anywhere in this folder?” You can also look at how things were at an earlier time, which is invaluable when investigating an incident. Large organizations export this data to analytics tools to build dashboards and automatic checks.

Advisors and recommendations

Google Cloud includes tools that suggest improvements, such as pointing out roles that were granted but never used, so you can tighten them. Reviewing these suggestions on a schedule is an easy way to move steadily toward least privilege.

Clicking in a console works for ten projects. It does not work for a thousand. Large companies describe their hierarchy in text and let tools build it.

Infrastructure as code

Infrastructure as code, often shortened to IaC, means writing down your desired setup in files that a tool reads and applies. Instead of clicking “create folder, create project, link billing, enable services”, you describe the end result. The tool compares that description to reality and makes the changes needed. Because the descriptions are text files, they can live in a Git repository, be reviewed by colleagues, and be rolled back if a change was wrong. The hierarchy itself becomes a reviewable piece of software.

Project factories

A project factory is a standard recipe that creates new projects the same way every time. A team requests a project by filling in a short request, such as the application name, environment, owner group, and cost center. The factory creates the project in the correct folder, links billing, enables the approved services, applies labels and tags, creates the right groups with the right roles, and connects logging. The requester gets a ready, compliant project in minutes, and the security team knows every project follows the same baseline.

flowchart TD
  Req["Team submits project request"] --> Rev["Automated and human review"]
  Rev --> Fac["Project Factory pipeline"]
  Fac --> Cr["Create project in correct folder"]
  Cr --> Bl["Link billing account"]
  Bl --> Api["Enable approved services"]
  Api --> Tg["Apply labels and tags"]
  Tg --> Ac["Create groups and grant roles"]
  Ac --> Lg["Connect logging and monitoring"]
  Lg --> Done["Notify team: project ready"]
    

Landing zones and blueprints

A landing zone is a pre-built, secure foundation for running in the cloud: a hierarchy, shared projects, networking, identity setup, policies, and logging, all created together. Google publishes reference blueprints and open-source modules to help build one, and partner and community tools exist as well. These are starting points to adapt, not finished answers, because every company’s rules differ. The key idea is to automate the foundation first, then add applications on top.

Protecting the automation

Automation that can create projects and grant roles is extremely powerful, so it must be protected like an administrator. Give it its own service account with only the roles it needs, restrict who may change the pipeline’s recipes, require review for every change, and watch its activity in the audit log. An attacker who controls the factory controls the company.

Follow a single request from a human idea to a running application, and you will see every part of the service doing its job.

A product team at a growing online grocery company wants a new analytics system. Here is how the hierarchy supports the story from start to finish.

flowchart LR
  A["Request"] --> B["Approval"]
  B --> C["Create project"]
  C --> D["Inherit policies and permissions"]
  D --> E["Grant group access"]
  E --> F["Build and run"]
  F --> G["Audit logs routed centrally"]
  F --> H["Promote to production project"]
  H --> I["Operate and review regularly"]
  I --> J["Retire: export data, delete, wait out recovery window"]
    

The beautiful part of this flow is how little the team has to remember. Safety comes from the structure, not from everyone’s memory. The people building the analytics system focus on analytics, while the hierarchy quietly applies the company’s rules.

Every design has costs. Seeing them clearly lets you decide where to spend effort.

Decision trade-offs in plain words

These habits come from lessons that many organizations learned the hard way.

Best practices

Common mistakes

Mistakes will happen. A good design makes them small, visible, and reversible. Here are the most common failure types and how to respond.

Scenario: a project was deleted by mistake

Because deleted projects wait in a pending state for a recovery window, quick action can bring the project back. Resources that depend on it may need a short time to return to normal, and some resources may not be fully restorable. The best protection is prevention: liens on critical projects, a deny rule limiting who may delete, alerts on deletion events, and a second person’s approval for retirement. After a restore, the team should review how the mistake happened and close the gap.

Scenario: a bad organization policy broke applications

Suppose a new restriction on service account keys suddenly stops a hidden program that relied on them. The fix is to find the change in the audit log, confirm it is the cause, and either adjust the policy for the affected folder or fix the program. Because policy changes are recorded and made at a specific node, you can quickly see what changed, who changed it, and where. This is why such changes should be tested in a small safe folder and announced in advance.

Scenario: someone granted too much access

If an overly powerful role was granted at a high level, the damage spreads down the tree. Remove the grant at the level where it was made, review the audit log for what the person or program did with that power, and rotate any credentials that might have been exposed. Because allows only add up, removing the grant at a lower level will not help, since the high-level grant still applies.

Scenario: the administrators are locked out

If the only organization administrators lose access, for example because of an identity provider outage or a mistaken account change, the company may not be able to manage its tree. Prevent this with a small group of administrators held by different people, strong sign-in methods that do not depend on a single device, and a break-glass emergency procedure that is tested regularly and monitored closely. Google Cloud support can also help in extreme cases, but you should plan not to need that.

Scenario: a project lost its billing link

If the billing account is closed or the link is removed, paid services in the project can stop. Re-link the project to a valid billing account. To avoid this, restrict who can change billing links, set up alerts on billing changes, and monitor billing account health.

flowchart TD
  F["Problem noticed"] --> Q{"What kind?"}
  Q -->|"Project deleted"| R1["Restore inside recovery window"]
  Q -->|"Policy broke apps"| R2["Find change in audit log, adjust at that node"]
  Q -->|"Too much access"| R3["Remove at granting level, review logs, rotate credentials"]
  Q -->|"Admins locked out"| R4["Use tested break-glass procedure"]
  Q -->|"Billing link lost"| R5["Re-link valid billing account"]
  R1 --> V["Verify services healthy"]
  R2 --> V
  R3 --> V
  R4 --> V
  R5 --> V
  V --> PM["Write short post-incident review and add a safeguard"]
    

Measuring recovery

Two simple numbers guide planning. The recovery point objective, or RPO, asks how much recent change you can afford to lose. The recovery time objective, or RTO, asks how long you can afford to be without the service. If your hierarchy is described in code stored in Git, your RPO for structure is almost zero, because every approved change is in version control. Your RTO depends on how well rehearsed the rebuild pipeline is.

The ideas in this guide appear across industries. The examples below describe common, widely discussed practices at a general level, and they illustrate patterns rather than claim details of any company’s private setup.

A small startup example

A ten-person startup creates an organization, sets up three folders: Common, Production, and Non-production, and applies a handful of policies: allowed regions, no service account keys, and domain-restricted sharing. They create one project per application per environment, use one group per team, and create projects through a short automated pipeline kept in version control. When they later hire a security lead and need to pass a customer’s security review, most of the evidence is already there: the policies, the audit logs, and the access lists. Nothing here is exotic. It is simply the ordinary discipline applied early, when it was cheap.

Most real companies do not start with a perfect tree. They start small, grow messy, and later need to clean up. This chapter explains how to do it safely.

Case 1: projects that exist outside any organization

Teams sometimes create projects using personal accounts before the company has an organization. Such projects have no parent. Once the organization exists, these projects can usually be moved into it, but moving requires the right permissions on both the project and the destination, and it changes which policies apply. Plan a window, tell the team, and review the effects. Always check Google’s current documentation for requirements, because the exact conditions can change.

Case 2: reshuffling folders

A reorganization may require moving many projects between folders. Because moves change inherited permissions and policies, do it in a deliberate sequence.

flowchart LR
  A["Old tree"] --> B["Inventory and snapshot"]
  B --> C["Design new tree"]
  C --> D["Simulate access and policy effects"]
  D --> E["Pilot move"]
  E --> F{"Problems?"}
  F -->|"Yes"| G["Adjust design or policies"]
  G --> D
  F -->|"No"| H["Move remaining projects in waves"]
  H --> I["Verify and clean up"]
    

Case 3: merging two companies

When two companies join, two organizations may exist. Google Cloud allows projects to be moved between organizations under certain conditions, but you should check current requirements and plan carefully. A common approach is to keep both organizations for a time, apply common baseline policies to each, and move workloads gradually into the surviving one.

If you are starting from zero, here is a sensible order to learn things, followed by a glossary of the important terms in this guide.

A beginner’s learning path

Glossary

To tie every idea together, here is one story that touches identity, hierarchy, policy, billing, automation, and recovery.

A company called Nimbus Retail, a made-up online store with about two hundred employees, is moving to Google Cloud. Its newly hired cloud lead, Meera, is asked to build the foundation.

Week one: the foundation

Meera confirms that the company’s identity domain is set up and that an organization resource exists. She creates two administrator groups: one for organization administration with only three trusted people, and one for security auditing. She protects those accounts with security keys. She also prepares a break-glass emergency account, stored securely and monitored.

Week two: the tree and the guard rails

She designs a shallow hybrid tree: Common Services, Production, Non-production, and Sandbox. She sets organization policies at the top: resources only in approved regions, no public addresses for virtual machines, no downloadable service account keys, and sharing only with the company’s domain. The Sandbox folder gets a lower budget and automatic cleanup. A deny rule limits project deletion to a small group.

Week three: the factory

Meera writes the whole structure as code and stores it in a Git repository with mandatory review. She builds a project factory: a team fills in a short form, and the pipeline creates the project, links billing, enables an approved list of services, applies tags and labels, creates the groups, and routes logs to the central logging project.

Week four: first teams arrive

The checkout team requests two projects: one for non-production and one for production. Both are created in minutes. The team members only need to be added to their groups. During the first deployment, an engineer tries to create a virtual machine with a public address. The platform refuses, citing the organization policy. The engineer uses the approved load-balancer pattern instead, and the application launches safely.

Month three: an incident

A junior engineer accidentally deletes a project that held a staging database. An alert on project deletion fires within minutes. Because the project is in pending deletion, the platform engineer restores it inside the recovery window and verifies that services return. The team adds a lien to the project and the post-incident review leads to a stricter deny rule on deletion for non-sandbox folders.

flowchart TD
  W1["Week 1: Org admins, auditor group, break-glass account"] --> W2["Week 2: Tree and organization policies"]
  W2 --> W3["Week 3: Hierarchy as code and project factory"]
  W3 --> W4["Week 4: First teams get projects in minutes"]
  W4 --> E1["Policy blocks public address on a VM"]
  E1 --> E2["Team uses approved pattern instead"]
  W4 --> M3["Month 3: Project deleted by mistake"]
  M3 --> R1["Alert fires, project restored in recovery window"]
  R1 --> R2["Lien and stricter deny rule added"]
    

What this story teaches

Rules written on paper protect nobody until the platform enforces them. The hierarchy is where written governance becomes working controls.

From policy document to platform control

Most companies have a security policy document full of sentences such as “customer data must stay in approved countries” and “only authorized staff may change production”. A document alone relies on every employee reading it, remembering it, and obeying it on a busy Friday afternoon. Governance in the cloud means translating each sentence into something the platform enforces or records. The location sentence becomes a resource location constraint. The production sentence becomes a folder with restricted roles and a deny rule. The record-keeping sentence becomes audit logs routed to a protected project with a set retention period.

The shared responsibility idea

When you use a cloud provider, security duties are shared. Google is responsible for protecting the underlying infrastructure: the buildings, the hardware, and the core services. You are responsible for how you use them: who has access, which settings you choose, and what data you put in. Cloud Resource Manager sits squarely on your side of that line. Google gives you the tools to structure and restrict your environment, but the decisions, such as who is an administrator and which policies exist, are yours. A badly designed hierarchy is not a failure of the platform. It is a failure of the design.

Evidence for auditors

Auditors and customers often ask the same questions: Who can access production? Where is data stored? How do you know nobody changed the rules without approval? A well-run hierarchy answers these quickly. The tree shows the structure. The access lists show who holds which role. Organization policies show the enforced restrictions. Audit logs show every change over time. Asset inventory shows what exists today and what existed in the past. Teams that treat these as evidence sources, and practice producing reports from them, find audits far less painful.

Culture matters as much as configuration

The strongest controls fail if people feel they must work around them. If requesting a project takes three weeks, teams will hide workloads in personal accounts. If an exception process is humiliating, teams will avoid it and take risks. Good governance is fast for the right things, firm on the dangerous things, and friendly in how it is explained. Publish a short guide in plain language, give teams a quick way to ask questions, and treat every request for an exception as feedback about whether a rule is too strict, too vague, or poorly explained.

Short answers to the questions beginners ask most often.

Cloud Resource Manager is the quiet foundation of everything you build on Google Cloud. It gives the company a single owned root, a tree of folders and projects that mirrors how work is organized, and a place to attach permissions, rules, tags, and billing. You have seen how a request walks up the tree to be checked, how grants add up and policies restrict, how projects are born and retired, and how automation turns all of this into a repeatable, reviewable foundation. You have also seen the common mistakes, from over-broad roles to untested policies, and how to recover from them.