Cloud Resource Manager in Google Cloud: Organizing Everything You Own in the Cloud
A friendly, in-depth guide to the organization, folders and projects that hold every Google Cloud resource, and to the access rules, policies, tags, liens and habits that keep a growing company tidy, safe and affordable.
Imagine a big company with no filing system. Every employee keeps documents wherever they like. Nobody knows who owns which folder, who can open what, or what happens to the papers when someone leaves. Finding anything takes days, and nobody dares throw anything away. Now imagine the same company with a sensible system: one building, floors for each department, rooms for each team, and a key card that opens exactly the right doors. In Google Cloud, that filing system is called Resource Manager. It decides where every cloud resource lives, who may touch it, which rules apply to it and who gets the bill, and understanding it early saves enormous pain later.
1What Is Cloud Resource Manager?
Resource Manager is the part of Google Cloud that organizes your resources into a tree, so you can manage access, rules and billing from central points.
According to Google’s documentation, Resource Manager is a tool for organizing Google Cloud resources hierarchically. Everything you create, such as a virtual machine, a storage bucket or a database, belongs to exactly one project. Projects can be gathered into folders. Folders and projects sit under an organization, which represents your company. This arrangement is called the resource hierarchy.
The hierarchy is not just a tidy picture. Rules flow down it. If you give a team permission at the level of a folder, that permission applies to every project inside that folder. If you set a rule at the organization level, it reaches the whole company. This makes the hierarchy the single most important structure to get right when you design a Google Cloud environment, because almost everything else, including access, policy, cost tracking and security, hangs from it.
Think of a large office campus. The campus is the organization. Each building is a folder, each floor or department room is a project, and the furniture and equipment inside the rooms are the resources. A key card for the whole campus opens everything. A key card for one building opens all its rooms. A key card for one room opens only that room.
Three ways to work with it
You can work with Resource Manager through the Google Cloud console, which is the website with menus and buttons, through the gcloud command line tool, and through the Resource Manager application programming interface, called an API, which lets other programs and automation tools do the same jobs. Large companies usually manage their hierarchy with automation so that every change is reviewed and recorded.
Google Cloud adds and renames features regularly. Use this guide to learn the ideas, and check the official pages for current limits, role names and screens before you make big changes.
2Why Organization Matters
The cost of a messy cloud is invisible at the start and enormous later.
A new team often starts with one cloud project created by one person. It works. A few months later there are twenty projects, owned by individuals, with unclear names and mixed purposes. A year later there are two hundred. Nobody knows which are still needed. Some contain production data and are open to far more people than anybody realizes. A person leaves the company and a project that runs an important service has no remaining owner. The bills grow, and nobody can say which team is responsible for which share.
Orphaned Projects
Projects owned by individuals disappear in practice when those individuals leave, leaving running services without an accountable owner.
Access Sprawl
Permissions granted one project at a time, over years, become impossible to review or explain.
Unclear Costs
Without structure, finance cannot tell which team or product caused which charge.
Inconsistent Security
Some projects follow security rules and others do not, because nothing applies the rules everywhere.
Risky Deletions
People delete or break things because nothing marks which projects are critical.
Slow Onboarding
Every new team must negotiate access and settings from scratch because no standard pattern exists.
A cloud without a hierarchy is like a city that grew without street names or a land registry. Houses exist, people live in them, but delivering a letter, collecting taxes or finding the owner of a leaking pipe becomes a detective story.
Moving resources and rewriting access rules after hundreds of projects exist is slow and risky. A few hours of planning at the start can save months of cleanup.
3Core Concepts and Vocabulary
A short glossary will make everything else in this guide easier to read.
Resource Hierarchy
The tree that arranges organization, folders, projects and resources, where each item has one parent.
Organization
The root node that represents a company and sits above all folders and projects.
Folder
A grouping node, often used for departments, teams or environments, that can hold projects and other folders.
Project
The base container where resources live, APIs are enabled, billing is attached and collaborators are managed.
Resource
An actual thing you use, such as a virtual machine, bucket or database.
IAM
Identity and Access Management, the system that decides who may do what on which resource.
Allow Policy
A set of grants that connects people or programs with roles on a resource.
Deny Policy
Rules that explicitly block certain actions for certain identities, even if a grant exists elsewhere.
Organization Policy
Rules about what is allowed on resources, such as which regions may be used, independent of who is acting.
Label
A simple key and value attached to a resource to help filter and report.
Tag
A governed key and value that can drive policy and categorization across the hierarchy.
Lien
A protective marker that blocks deletion of a project until the marker is removed.
If the hierarchy is a building, IAM is the key card system that decides who enters which door, organization policy is the building code that decides what may be built at all, and labels and tags are the name plates and color stickers that help staff find things.
A useful rule of thumb: IAM controls who can act, while organization policy controls what can be done. Both flow down the hierarchy and work together.
4The Resource Hierarchy at a Glance
Four levels, one rule: every item has exactly one parent.
flowchart TD
O["Organization (company root)"] --> F1["Folder: Engineering"]
O --> F2["Folder: Finance"]
F1 --> F3["Folder: Production"]
F1 --> F4["Folder: Development"]
F3 --> P1["Project: shop-prod"]
F4 --> P2["Project: shop-dev"]
F2 --> P3["Project: reports-prod"]
P1 --> R1["VM, database, bucket"]
P2 --> R2["VM, database, bucket"]
P3 --> R3["Datasets and jobs"]
| Level | Purpose | Required? |
|---|---|---|
| Organization | Company-wide root for central control | Recommended for any company; needs a Google Workspace or Cloud Identity account |
| Folder | Group related projects and delegate administration | Optional but very useful |
| Project | Container for resources, APIs, billing link and collaborators | Required to use Google Cloud |
| Resource | The actual services and data | Always inside exactly one project |
Google’s documentation notes that every resource except the top one has exactly one parent. A project can sit directly under an organization, inside a folder, or, in the special case of a free trial or free tier user, stand alone with no organization above it.
A family tree where each person has exactly one recorded parent in this tree. You can always follow the line upward to the root, and everything you inherit travels down that same line.
When confused about why a user has access or why an action is blocked, trace the path from the resource up to the organization. The answer is almost always somewhere along that line.
5The Organization Node
The organization is the company’s official presence in Google Cloud, and the place where central control begins.
The organization is the root of the hierarchy. It is created from a Google Workspace or Cloud Identity account, and each such account maps to exactly one organization. The organization is owned by that account’s customer identity, which is set at creation and cannot be changed afterward. All projects created by people in the company’s domain can live under it.
An important benefit is that projects belong to the company, not to individual people. When an employee leaves and their account is removed, the projects they created remain, still under organization control. Central administrators can see all projects, apply rules to all of them and review access across the whole company. Without an organization, none of this is possible, and each project stands alone with its creator as owner.
Starting permissions
Google’s documentation explains that a brand-new organization starts with a fairly open setup: all users in the domain may create projects and billing accounts. Many companies tighten this early, letting only a trusted group create projects, so that new projects always appear in the right place with the right settings.
What an Organization Gives You
- Company ownership of every project
- One place to set access and policy for everything
- A complete view of all projects and resources
- A base for audit, security and cost governance
What It Demands
- A managed identity system such as Workspace or Cloud Identity
- Careful protection of the highest administrator roles
- A plan for who may create projects and where
- Ongoing review as the company grows
The organization is the company’s registered headquarters. Offices opened by staff belong to the company, not to the person who signed the lease, and when that person leaves, the office stays open.
People with powerful roles at the organization level can change everything below. Keep that group very small, use strong sign-in protection and review it regularly.
6Folders: Grouping and Delegating
Folders turn a flat list of projects into a meaningful structure.
Folders are optional containers between the organization and the projects. They work like sub-organizations. A folder can represent a department, a team, an application or an environment, and folders can be nested inside other folders. Their main powers are grouping and delegation. You can apply an access rule or a policy once on a folder, and it applies to everything inside. You can also let a team administer its own folder, creating projects and managing access inside it, without giving them power over the rest of the company.
Folders also help with delegation in a very practical way. Suppose the payments team needs to create test projects quickly. Instead of asking the central team every time, the central team gives the payments team permission to create projects inside its own folder. The team moves fast, yet every project it creates automatically inherits the company’s policies, because the folder sits beneath the organization. Delegation and control work together instead of fighting.
Common ways to structure folders
| Pattern | Example | Good When |
|---|---|---|
| By environment | Production, Staging, Development | Security rules differ most by environment |
| By department or team | Finance, Marketing, Engineering | Teams are independent and own their costs |
| By application or product | Shop, Search, Payments | Each product has its own team and lifecycle |
| Hybrid | Department then environment, or product then environment | Most mid-size and large companies |
Because moving things later is effortful, keep the structure simple. Deep trees with many levels are hard to understand and reason about. Check the current documentation for the maximum allowed nesting depth and other limits before designing an unusually deep tree.
Folders are like floors in an office building. The building owner gives each department a floor and lets the department manager decide who sits where. The owner still sets building-wide rules such as fire exits, which apply to every floor.
Choose folder names that a new employee can understand without explanation, and write down the naming rule. Cryptic names turn the tree into a puzzle.
7Projects: The Base Unit
The project is the container you will deal with every day.
You must have a project to use Google Cloud at all. Google’s documentation says that a project is where you enable APIs, manage billing, and collaborate with others. Every resource belongs to exactly one project. Projects are separated from each other by default: resources in one project cannot automatically see or use resources in another, although you can connect them deliberately through networking and access grants.
Boundary for Access
You can give someone access to one project and nothing else, which makes projects natural security boundaries.
Boundary for Billing
A project is linked to a billing account, so charges can be traced to the project that caused them.
Boundary for Services
APIs are enabled per project, so each project turns on only what it needs.
Boundary for Quotas
Usage limits are tracked per project, which keeps one workload from consuming another’s allowance.
Boundary for Lifecycle
Deleting a project cleans up everything inside it, which is useful for temporary work.
Boundary for Ownership
A project has clear owners and contacts, which makes responsibility visible.
A project is a self-contained shop unit in a mall. It has its own lease, its own utility meter, its own door key and its own list of staff. Neighbors cannot walk in unless the shop owner opens the door.
Because the structure itself is inexpensive, do not hesitate to use separate projects to create clean boundaries between workloads or environments. Many small, well-named projects are easier to govern than a few giant ones.
8Project Name, ID and Number
Every project has three identifiers, and mixing them up is a classic beginner mistake.
| Identifier | Who Chooses It | Can It Change? | Used For |
|---|---|---|---|
| Project name | You | Yes, it is a display name | Showing a friendly label in the console |
| Project ID | You, at creation | No | Requests to Google Cloud and scripts; must be globally unique |
| Project number | Generated automatically | No, and read-only | Internal reference used by some services and identities |
The project ID is the identifier you will type most. Because it cannot be changed, choose it with care. Many companies use a naming pattern that includes the product, the environment and sometimes the owning team, so that the ID explains itself. Google’s documentation also notes that a project ID cannot be reused after the project is fully deleted, so a good ID is a lasting commitment.
Besides these identifiers, a project carries labels, which are key and value pairs used for filtering, a lifecycle state, such as active or delete requested, and a creation time.
The name is a nickname, like “the big store”. The ID is the official street address you write on parcels. The number is the tax registration number the government assigns on its own. People use the nickname in conversation, but couriers need the address.
Project IDs appear in many places, including logs and addresses. Never include confidential details or personal names in them.
9Inheritance of Access Control
The most powerful idea in the hierarchy is that access flows downward from parent to child.
When you grant a role to a person on a folder, that person holds the role on every project inside the folder, and on every resource inside those projects. Google’s documentation describes the effective policy of any resource as the combination of the policy set directly on it and the policies inherited from all its ancestors. For example, granting a networking role at the organization level lets a team manage networks across every project, without per-project grants.
flowchart TD
O["Organization: security auditors can view"] --> F["Folder Engineering: developers can edit"]
F --> P1["Project A"]
F --> P2["Project B: extra grant for database admin"]
P1 --> R1["Resource inherits both grants"]
P2 --> R2["Resource inherits all three grants"]
What this means in practice
Grants Only Add Downward
A child cannot remove a permission its parent granted through a normal allow policy. If you need to block something, use other tools such as deny policies.
Grant at the Right Level
Give permission at the lowest level that still meets the need. A broad grant at the top reaches everything below it.
Prefer Groups
Grant roles to groups of people, not individuals, so that joining or leaving a team changes access automatically.
Review the Whole Path
To understand someone’s real access, look at grants at every level above, not only the resource itself.
A master key for the building opens every room, a floor key opens that floor’s rooms, and a room key opens one room. Having the building key means you cannot be locked out of any room by a room-level rule.
An editor role granted on a high folder years ago quietly reaches every new project added beneath it. Review high-level grants regularly.
10Allow Policies, Deny Policies and Roles
IAM has a few moving parts, and knowing their roles makes the hierarchy easy to reason about.
An allow policy attaches roles to identities on a resource. A role is a named bundle of permissions, and a permission is a single allowed action. Google provides many predefined roles designed for particular jobs, and you can also create custom roles for special needs. Deny policies provide the opposite tool: they state that certain identities may not use certain permissions, and this refusal wins even when an allow policy elsewhere would grant the same permission. Both kinds of policy can be set on organizations, folders and projects and are inherited downward.
| Concept | Meaning | Example |
|---|---|---|
| Permission | One allowed action | Create a virtual machine |
| Role | A bundle of permissions for a job | Viewer, Editor or a specialized predefined role |
| Principal | The person, group or program receiving a role | A user, a group, a service account |
| Allow policy | List of role grants on a resource | Group of developers gets a role on a folder |
| Deny policy | Blocks specific permissions for specific principals | Nobody except a security group may delete audit logs |
Role design guidance
Avoid Basic Roles in Production
The old broad roles, such as Owner and Editor, grant very many permissions. Prefer narrower predefined roles for real work.
Match Roles to Jobs
Create small sets of roles that match real jobs such as developer, operator and auditor, and assign those to groups.
Use Deny for Guardrails
Use deny policies to protect a few critical actions that no ordinary grant should ever unlock.
Allow policies are the list of people invited to a party. Deny policies are the bouncer’s list of people who may not enter, even with an invitation. The bouncer’s list takes priority.
Predefined roles are updated over time. Look up exact role names on Google’s reference pages instead of relying on memory or old tutorials.
11Organization Policy: Guardrails for Everyone
Organization Policy sets rules about what may exist, no matter who is asking.
IAM answers who can do something. Organization Policy answers what is allowed to be done at all. Google’s documentation gives examples such as restricting the locations where resources may be created or blocking resources from having public internet addresses. A rule is set once at a node of the hierarchy, usually the organization or a folder, and it applies to every project below. These rules are often called constraints.
Keep Data in Approved Regions
A company with legal duties about where data lives sets a location rule at the organization. Even an administrator in a project cannot create resources in forbidden regions.
Block Accidental Public Exposure
A rule prevents virtual machines from receiving public internet addresses, so engineers cannot expose servers by mistake.
Limit Risky Credentials
Rules can restrict the creation of certain kinds of keys, pushing teams to safer sign-in methods.
Exceptions by Folder
A research folder is allowed to use a special region by an exception, while everything else follows the strict default.
Policies are inherited, and in many cases a child node can customize the rule, for example by adding a justified exception, depending on how the rule is configured. Because exact constraint names and behaviors change, check the current list of constraints before relying on a particular one.
Organization Policy is the building code. No matter how rich the tenant or how senior the manager, nobody may remove the fire exits. The code applies to every floor unless a documented exception is granted.
A strict rule can break existing workloads. Where possible, trial new rules in a small folder or in a check-only mode before applying them company-wide.
12Labels and Tags
Both attach a key and a value to your resources, but they serve different purposes.
Labels are simple key and value pairs you attach to projects and many resources. They help filter lists, group costs and build reports. Anyone with permission can usually add whatever labels they like, which makes them flexible and also inconsistent. Tags, according to Google’s documentation, are key and value pairs used for categorization, policy enforcement, cost allocation and boundary membership. Tags are defined centrally, with controlled keys and values, so they are better suited to rules than labels are.
| Aspect | Labels | Tags |
|---|---|---|
| Who defines them | Anyone who can edit the resource | Defined centrally and then attached |
| Consistency | Easy to drift, with typos and variants | Controlled keys and values |
| Used for policy | Generally no | Yes, can be used by policy conditions |
| Used for cost reports | Yes, commonly | Supported for cost allocation |
| Best for | Informal grouping and quick filtering | Governance rules tied to categories |
Consistency is the real challenge. If one team writes the environment as “prod”, another as “production” and a third as “prd”, every report splits the same thing into three rows. The cure is a short written standard, automatic application at project creation and a regular check that finds exceptions. Tags help here because their allowed values are defined once and then chosen, not typed freely each time.
A sensible labeling plan
Pick a Small Set
Choose a few keys everybody understands, such as owner, cost center, environment and application.
Write the Rules Down
Document exact key names and allowed values with examples.
Apply at Creation
Set them automatically when projects are made so they are never forgotten.
Audit Regularly
Look for missing or misspelled values and fix them in bulk.
Labels are handwritten sticky notes anyone can add. Tags are official barcodes issued by the head office. Sticky notes are quick, but only barcodes can safely control the automatic doors.
13Creating Projects the Right Way
How projects are born determines how tidy your cloud stays.
Anyone allowed to create projects can do so in the console in minutes. That is both a convenience and a risk. In small teams, manual creation is fine. In larger companies, a standard process is better: a request, a review, then automatic creation with the correct folder, naming, labels, billing link, enabled APIs and starting access, all in one repeatable action.
Request
A team asks for a project, stating purpose, owner and environment.
Review
A platform team checks that a new project is really needed and that the right folder is chosen.
Automatic Creation
A script or infrastructure tool creates the project under the correct folder with a standard name and labels.
Baseline Setup
Billing is linked, required APIs are enabled, logging is configured and groups receive their roles.
Hand Over
The team receives a ready project with documented limits and contacts.
Google’s documentation notes that the creator of a new project is initially granted the owner role on it. In a governed setup, that automatic ownership should be reviewed and often replaced with group-based roles so that no single individual remains the sole owner.
Creating a project through a standard process is like opening a new shop in a mall through the mall office. The office assigns the unit, connects utilities, issues keys and registers the owner, so every shop starts with the same safe setup.
If the official process takes weeks, people will create projects secretly. Keep the automated path fast, and the governance will follow naturally.
14Shutting Down and Recovering Projects
Deleting a project is serious, so Google Cloud gives you a recovery window.
According to Google’s documentation, only an active project can be shut down. The project becomes unusable immediately and moves to a delete requested state. Shutdown stops resource usage, and any linked billing account is disconnected. The project then remains recoverable for 30 days. After that period, the project and its data are permanently deleted.
stateDiagram-v2
[*] --> ACTIVE
ACTIVE --> DELETE_REQUESTED: shut down
DELETE_REQUESTED --> ACTIVE: restored within 30 days
DELETE_REQUESTED --> PermanentlyDeleted: 30 days pass
PermanentlyDeleted --> [*]
Important details to remember
Restoring Is Not Instant Perfection
A restored project returns to its earlier state, but billing must be linked again by hand, some services can take many hours to resume, and some may need a manual restart.
Some Data Goes Sooner
A few services remove data faster than the 30 day window. The documentation gives examples such as storage buckets without soft delete, which may be removed immediately.
IDs Are Not Reusable
A project ID cannot be reused after full deletion. If you want to keep a particular ID, delete the resources inside instead of the project.
Quota Counts Until Gone
A project counts toward your project quota until it is permanently deleted.
Permissions Required
Shutdown and restore need specific permissions, so ordinary users should not hold them on important projects.
Billing May Linger
Charges can continue until the billing cycle ends, so turn billing off deliberately if you are worried about extra charges.
Shutting down a project is like moving a document to the recycle bin. It disappears from view at once and can be restored for a while, but some items in the bin are cleared sooner, and after the deadline the bin is emptied for good.
Treat deletion as irreversible. Keep backups of important data outside the project and use protections such as liens for critical projects.
15Liens: A Padlock on Important Projects
A lien is a simple but effective protection against accidental deletion.
A lien is a marker placed on a project that blocks it from being deleted until the lien is removed. Google’s documentation recommends liens for projects that must not be deleted by accident, for example those with active committed use discounts. Any service or administrator can place a lien, and anyone trying to delete the project will be stopped with a message explaining that a lien exists. Removing the lien is a separate, deliberate step that needs its own permission.
Good Uses for Liens
- Production projects running customer services
- Projects holding the only copy of important data
- Projects tied to long-term commitments
- Shared network or logging projects used by many teams
Watch Out For
- Forgotten liens that block legitimate cleanup
- Liens placed by other services that you did not know about
- Teams removing liens casually without review
- Assuming a lien replaces backups, which it does not
Liens are listed by Google among the common causes of trouble when shutting down or restoring a project. When a deletion fails unexpectedly, checking for liens is a good first step.
A lien is a padlock on the main switch. It does not stop people from using the building. It just stops anyone from switching the whole building off by accident.
Add a lien automatically whenever a production project is created, and require a documented approval to remove it.
16Moving Projects Within the Hierarchy
Companies reorganize, and projects sometimes need new parents.
You can move a project from one folder to another, or from the organization into a folder, if you hold the needed permissions on both the old and new locations. When a project moves, it stops inheriting from its old ancestors and begins inheriting from its new ones. This can change who has access and which organization policies apply, sometimes in surprising ways.
Compare Old and New Inheritance
List the access grants and policies at the old and new locations and note every difference.
Check Policy Conflicts
Make sure the project’s resources do not violate rules at the new location, such as a region restriction.
Warn the Affected People
Tell owners and users that their access might change, and when.
Move During a Quiet Time
Avoid moving critical projects during busy periods, and have a plan to move back.
Verify Afterward
Confirm that applications still work and that the right people have the right access.
Moving a project is like moving a team to a different floor. The desks and computers go with them, but the key card rules, security cameras and fire policies of the old floor no longer apply, and the new floor’s rules take over.
If a service relied on an inherited permission, it may stop working after a move. Test in a non-critical project first whenever possible.
17Essential Contacts and Responsibility
When something important happens, Google needs to reach the right human.
Google Cloud sends notices about billing, security events, legal matters and technical changes. Essential Contacts lets you designate which people or groups receive each type of notice. Contacts can be set at the organization, folder or project level, and Google’s documentation says they cascade down the hierarchy, so a contact set at the top applies to every project below unless changed.
Billing
Notices about invoices, payment problems and spending.
Security
Notices about suspected compromise and security findings.
Technical
Notices about outages, deprecations and changes to services you use.
Legal
Notices about terms, compliance and legal requests.
Shutdown notices, for instance, go to the person who started the shutdown and to technical contacts. Use shared group addresses, not personal emails, so notices do not vanish when someone leaves.
Essential contacts are the emergency numbers on the office noticeboard. When the fire alarm or the landlord calls, the call reaches a team desk that always answers, not one person’s mobile phone that might be switched off.
Send a test message to every contact group once a year and fix those that bounce, so real notices are never lost.
18Projects and Billing Accounts
Who pays is a separate question from who owns, and the two connect through a link.
Charges in Google Cloud are paid through a billing account, which holds payment details and receives invoices. A project must be linked to a billing account before it can use paid services. One billing account can serve many projects, and a company may have several billing accounts, for example one per business unit or per country. The billing account is a separate object from the resource hierarchy, with its own access rules, but the link between a project and a billing account is what makes cost reports possible.
| Question | Answered By |
|---|---|
| Who may use the project? | Access grants in the hierarchy |
| Who pays for the project? | The billing account linked to it |
| Who may change that link? | People with billing permissions on the account and on the project |
| What does the project cost? | Billing reports filtered by project, label or tag |
Consider also how a company with several divisions might arrange payment. A holding company may use one billing account for shared platforms and a separate billing account for each division, so each division’s finance team receives its own invoice and pays independently. Projects are then linked to the account of the division that owns them. When a project moves between divisions, its billing link must be changed too, or the wrong department will keep paying. Treat billing links as part of any reorganization checklist.
Practical points
Shutdown Unlinks Billing
When a project is shut down, its billing link is removed and is not restored automatically after recovery. You must relink it.
Budgets and Alerts
Set budgets on billing accounts or projects, with alerts at several thresholds, so surprises are caught early.
Separate Duties
Keep people who can spend, those who can pay and those who can audit as different groups where possible.
Cost Allocation
Use consistent labels or tags and export billing data for analysis by team, product and environment.
A project is a department, and the billing account is the company credit card. Many departments can use the same card, but the monthly statement must list which department bought what, or finance cannot split the bill.
Sending detailed billing data to an analysis tool lets you answer questions such as which team’s spending grew most last month, without opening endless screens.
19Enabling APIs and Managing Quotas per Project
Each project switches on its own services and has its own usage limits.
Most Google Cloud services are controlled by an API that must be enabled in a project before use. A new project starts with very few enabled, and each team turns on what it needs. This is a quiet security benefit: a project that never enabled a database API cannot run that database, whatever its users try. Companies often restrict which APIs may be enabled in sensitive environments.
Quotas are limits on how much of a service a project can use, such as how many requests per minute or how many virtual machines in a region. They exist to protect you from runaway costs and to protect shared infrastructure. Because quotas are tracked per project, separate projects give separate allowances, so a busy test project does not consume the production project’s capacity.
Enable Only What Is Needed
Each extra enabled API is extra surface to secure and monitor.
Review Quotas Before Launch
Check that limits are high enough for expected peak traffic and request increases early, since approval can take time.
Alert on Usage
Set alerts when a quota is close to exhaustion, so you can act before users are affected.
Use Limits as Safety Nets
Lower quotas in test projects to cap accidental overspending.
Enabling an API is like switching on a utility connection, such as gas or water, in one apartment. Quotas are the maximum flow the pipe supports. Each apartment has its own meter, so one neighbor’s heavy use does not drain yours.
A launch that needs ten times today’s quota will fail on day one if nobody asked in advance. Include quota checks in every launch plan.
20Designing Your Hierarchy: Common Patterns
There is no single correct tree, but a few patterns fit most companies.
The best structure reflects how your organization actually works and where your security and cost boundaries really lie. Three questions guide the design. Who needs to be separated from whom? Which rules should apply to which groups of projects? And who must see the costs of which work? The answers usually point to one of the following shapes.
Before choosing, draw your candidate tree on paper and test it with three real examples: a brand-new product, a team that splits in two, and an acquired company. If any of these causes confusion about where things belong, the design needs another round. A structure that handles change gracefully is worth more than one that looks neat today.
Also decide who owns the structure itself. A small platform or cloud foundation team usually maintains the top levels of the tree, the policies and the project creation process, while product teams manage what happens inside their own folders and projects. Writing this division of responsibility down avoids arguments later, when someone wants a new folder or an exception to a policy and nobody knows whom to ask.
Pattern 1: Environment first
Top-level folders are production, non-production and perhaps shared services. Inside each, folders or projects follow teams or products. This pattern makes it easy to apply strict policies to production and looser ones to development, which is why many security-focused companies prefer it.
Pattern 2: Team or business unit first
Top-level folders are departments or business units, each with environment folders inside. This pattern gives each unit autonomy and clear cost ownership, and suits companies whose units operate almost like separate businesses.
Pattern 3: Hybrid with a shared services area
A mix of the above, plus a folder for shared platforms such as networking, logging and security tools. The shared area has tight access and serves all other folders.
flowchart TD
O["Organization"] --> S["Folder: Shared services"]
O --> PR["Folder: Production"]
O --> NP["Folder: Non-production"]
S --> S1["Project: network-hub"]
S --> S2["Project: central-logging"]
S --> S3["Project: security-tools"]
PR --> A1["Folder: Shop"]
PR --> A2["Folder: Payments"]
NP --> B1["Folder: Shop"]
NP --> B2["Folder: Payments"]
A1 --> A1P["Project: shop-prod"]
B1 --> B1P["Projects: shop-dev, shop-test"]
| Pattern | Strength | Weakness |
|---|---|---|
| Environment first | Simple, strong production controls | Teams are spread across folders, so team-wide changes touch several places |
| Team first | Clear ownership and delegation | Security rules must be repeated in every team folder |
| Hybrid | Balances both | More folders to understand and keep consistent |
Organizing a school: you can group classrooms by grade, by subject, or by building. Each works, but the best choice depends on whether fire drills, timetables or teachers are your main concern.
Two or three folder levels usually suffice. Each extra level adds complexity to every access review and every question about where something belongs.
21A Reference Landing Zone
A landing zone is the prepared ground your workloads arrive on.
Mature companies do not let teams start from nothing. They prepare a landing zone: an organization with a standard folder layout, guardrail policies already applied, central logging switched on, shared networking prepared, groups and roles defined, and a process to create new projects that inherit all of this. Teams then arrive in a safe, consistent environment and focus on their applications.
Identity First
Connect the company’s identity system, define administrator groups and protect them with strong sign-in.
Hierarchy and Naming
Create the folders and write the naming and labeling standards.
Guardrail Policies
Apply organization policies and key deny policies at the top so they cover everything below.
Central Logging and Monitoring
Collect audit logs from the whole organization into a protected project that few people can change.
Shared Networking
Prepare common network foundations that projects connect to under control.
Project Factory
Offer an automated way to create new projects with baseline settings.
A landing zone is a serviced plot of land: roads, water, electricity and building rules are ready before anyone builds a house. Builders move fast because the basics are done and safe.
Google publishes foundation guidance and example blueprints. Adapt them to your needs, and check their current versions before copying.
22Who Gets Access at Which Level
A clear model of access by level prevents both over-permission and endless requests.
Because grants flow downward, the level where you give a role is a decision about how widely it applies. As a general guide, powerful and broad roles belong to very few people at the top, while everyday work roles belong to teams at the project level.
| Level | Typical Holders | Typical Responsibilities |
|---|---|---|
| Organization | Small group of cloud administrators, security and audit teams | Company-wide policy, organization-wide viewing, setting up folders |
| Top folders | Platform or environment owners | Folder-level policy, creating projects inside the folder |
| Team folders | Team leads | Delegated project creation and team-level access |
| Projects | Developers, operators, analysts | Day-to-day work on the resources they own |
| Resources | Specific people for specific items | Narrow exceptions, like one bucket or dataset |
It helps to picture a few typical people. A developer works inside one team’s development and staging projects and has read-only access to production logs. An operator on call can restart services in production but cannot change who has access. A security auditor can view configuration and logs across the whole organization but cannot change anything. A finance analyst can view billing data but not resources. Writing such role descriptions in plain language, then mapping each to groups and predefined roles, gives every request a standard answer and reduces the temptation to hand out broad access just to move fast.
Emergency access deserves its own plan. Sometimes an engineer genuinely needs elevated rights at three in the morning to fix an outage. A good design provides a controlled, logged way to obtain temporary elevated access, with a reason recorded and a review afterward, so that emergencies do not become permanent exceptions.
Habits of good access design
Groups, Not Individuals
Every grant goes to a group, so access follows team membership automatically.
Separate Admin and Daily Accounts
Administrators use a special account only for administration, reducing exposure.
Time-Limited Access
Where possible, give powerful access temporarily, with an expiry, for a specific task.
Regular Reviews
Review high-level grants every few months and remove those no longer needed.
A hospital gives the master key to almost nobody, floor keys to ward managers and room keys to staff on those rooms. Temporary visitors get a pass that expires at the end of the day.
Teams ask for broad access to avoid delays, and nobody asks to give it back. Build a regular review habit so access shrinks as well as grows.
23Service Accounts and Project Boundaries
Programs need identities too, and they live inside projects.
A service account is an identity used by a program or a machine rather than a person. A virtual machine, a function or a pipeline uses a service account to prove who it is when it calls other services. Service accounts belong to a project, but they can be granted roles in other projects, folders or the organization, which is how cross-project work is done.
Because service accounts carry permissions, careful design matters. A single powerful service account shared by many applications is a serious risk, since stealing it opens everything. Prefer one service account per workload, with the smallest roles that workload needs, granted at the lowest sensible level.
Good Practice
- One service account per application or function
- Narrow predefined roles at project or resource level
- Short-lived credentials instead of long-lived key files
- Regular review of unused service accounts
Risky Practice
- One shared super account for everything
- Owner or Editor granted at the organization level
- Downloaded key files left in code or on laptops
- No owner recorded for each service account
A service account is a staff badge for a robot. A robot that cleans the lobby needs a lobby badge, not a master key to the vault. And if one robot is stolen, only the lobby is at risk.
Organization policies can limit the creation of long-lived keys, nudging teams toward safer methods of authentication. Check the current constraint names in the documentation.
24Governance: Audit, Inventory and Visibility
A tidy hierarchy is only valuable if you can see what is in it.
Governance means being able to answer questions about your cloud with confidence. What projects exist? Who has access? Which resources break our rules? Who changed this setting last week? Google Cloud offers tools to answer these at organization scale. Audit logs record administrative actions and, if enabled, data access. Inventory tools list resources and their settings across projects. Security tools highlight risky configurations. Exact product names and features change, so look up the current set in the documentation.
Audit Logs
Record who did what, where and when. Collect them centrally at the organization level into a protected place.
Asset Inventory
Lists resources and their configuration across projects, so you can search, export and compare over time.
Policy Analysis
Helps answer who can access what, taking inheritance into account, which is hard to work out by hand.
Security Findings
Flags risky settings, such as exposed storage, across the whole organization.
Questions worth answering regularly
Which Projects Have No Owner or Label?
These are candidates for cleanup or assignment.
Who Holds Broad Roles?
List every person or account with powerful roles at high levels.
Which Resources Are Public?
Find anything exposed to the internet that should not be.
What Changed Recently?
Review administrative changes around the time any incident began.
Governance is the security desk with a visitor book and camera feeds. A well-run building is not one where nothing goes wrong, but one where you can quickly see what happened and who was involved.
Store audit logs in a project that few people can change. Logs that an intruder can edit are not evidence.
25Automating the Hierarchy
At scale, the hierarchy should be described as code and applied by tools.
Clicking through the console is fine for learning, but it does not scale and leaves no record of why something was changed. Mature teams describe folders, projects, access grants and policies in configuration files stored in version control. Changes go through review, are applied by an automated process, and can be undone by reverting a file. This approach is called infrastructure as code. The Resource Manager API and the gcloud tool make it possible, and common infrastructure tools provide ready-made building blocks.
| Method | Strength | Weakness | Best For |
|---|---|---|---|
| Console | Visual and easy to learn | No review trail, easy to make one-off mistakes | Learning and quick inspection |
| Command line scripts | Repeatable and fast | Scripts can drift and become hard to maintain | Small tasks and migrations |
| Infrastructure as code | Reviewed, versioned, consistent, testable | Needs discipline and skill to set up | Production hierarchy and policies |
| Project factory service | Self-service with guardrails | Needs building and maintenance | Larger companies creating many projects |
Guardrails for automation
Review Every Change
Hierarchy changes alter security for many projects at once, so require a second pair of eyes.
Plan Before Apply
Preview what a change will do before it runs, particularly for deletes and moves.
Protect the Automation Identity
The automation account holds powerful roles. Limit who can change its code and who can run it.
Detect Drift
Compare reality with the code regularly, to catch manual changes that bypassed review.
Infrastructure as code is the architect’s blueprint kept on file. Anyone can see what the building should look like, and when a wall is moved by hand, the difference with the blueprint shows up quickly.
26Cost Awareness
The hierarchy itself is not where the money goes, but it decides how well you can control the money.
I could not confirm a separate price for the core organization, folder and project structure on the pages I reviewed, and the documentation I read did not discuss pricing for it. In general, the cost of Google Cloud comes from the resources and services you run inside projects, not from the act of organizing them. Confirm the current position on the official pricing pages, since terms can change, and note that some related governance tools may have their own pricing.
What the hierarchy does affect is visibility and control of spending. Clear projects with consistent labels let finance see which team caused which charge. Budgets with alerts per project or per billing account warn you early. Quotas cap how far a runaway process can go. Shutting down unused projects stops resource usage, with the caution that billing may continue until the billing cycle ends and that some commitments may be affected.
Separate Projects by Owner
Give each team and environment its own project so costs separate naturally.
Label Everything Consistently
Use agreed keys such as team, application and environment on every project.
Set Budgets and Alerts
Alert at several thresholds and send alerts to groups that will act.
Clean Up the Unused
Review idle projects regularly and shut them down after confirming ownership and backing up data.
Review Commitments Before Deletion
Check discounts and commitments tied to a project before removing it.
Filing cabinets themselves cost little. The expense is in what you store. But a well-labeled cabinet lets you see which drawer is growing and who put the papers there, and that is where savings begin.
Use Google’s official pricing pages and calculator to confirm costs for any service you plan to use, because prices and free allowances change.
27Real-World Scenarios
Stories show how these ideas appear in daily life.
Scenario 1: The Startup That Outgrew One Project
A startup began with a single project holding everything. As the team grew, developers accidentally changed production resources while testing. The company created an organization, three folders for production, staging and development, and moved each environment into its own project. Access was granted to groups, and incidents from careless changes dropped quickly.
Scenario 2: The Departing Engineer
An engineer who created many projects under a personal account left the company. Because those projects were created without an organization, nobody had permission to manage them. After adopting an organization and moving projects under it, ownership belonged to the company and departures no longer caused emergencies.
Scenario 3: Data Location Rules
A company serving customers in a region with strict data laws needed to prove that data stayed in approved locations. An organization-level location policy prevented anyone from creating resources elsewhere, and audit logs supported the evidence given to regulators.
Scenario 4: The Costly Mystery
A finance team saw a large unexplained bill. Because projects carried consistent labels and billing data was exported for analysis, they traced the spike to one test project within an hour, found a forgotten large job, and shut it down.
Scenario 5: The Accidental Shutdown
An administrator shut down the wrong project. Because the project was inside the recovery period, the owner restored it within days. The team relinked billing, restarted a few services and then added liens and tighter shutdown permissions to every production project.
Scenario 6: Acquisition
A company acquired a smaller business whose projects lived in a separate organization. The platform team created a dedicated folder for the acquired business, moved projects in gradually after comparing policies, and used inheritance to apply the company’s baseline security without rebuilding anything.
All these stories are about the same thing: a growing town that needs street names, a land registry and building rules. Towns that add them early grow gracefully, and towns that wait build them in a crisis.
28One Project or Many?
A frequent beginner question is how many projects to create. The answer is usually more than you think.
| Approach | Strength | Weakness |
|---|---|---|
| One project for everything | Simple to start, no cross-project setup | No isolation, mixed quotas and costs, broad access, risky changes |
| One project per environment | Production isolated from testing, clean policies | More projects to manage as products multiply |
| One project per application per environment | Strong isolation, clear ownership and cost, fine-grained access | Needs automation and good naming to stay manageable |
| One project per tiny component | Maximum isolation | Excessive overhead, difficult sharing, confusing sprawl |
For most teams, one project per application per environment is a healthy middle path, with shared services in dedicated projects. Use a few simple tests to decide whether two workloads belong together. Do they have the same owners? The same access needs? The same security rules? The same budget? The same life cycle? If the answer to several is no, separate them.
Housing everyone in a single huge room is cheap to build but impossible to live in. One room per family is a better layout. A separate room for every cupboard goes too far. The art lies in choosing the natural boundaries.
Accounts have limits on the number of projects they may create, which can be raised on request. Check the current quota before planning many projects.
29Key Design Decisions
Architects write down significant choices so later teams understand the reasons.
Create an organization before anything else
Set up an organization from a managed identity account at the start, even for small companies.
Reason: projects belong to the company, central policy becomes possible, and people leaving cause no orphaned projects. Trade-off: requires an identity platform and some setup effort.
Separate production from non-production at folder level
Put production projects in their own folder with stricter policies and fewer people with access.
Reason: protects customers from experiments and makes guardrails simple to apply. Trade-off: team folders appear in more than one place.
Grant access to groups at the lowest sufficient level
Never grant roles directly to individuals, and avoid broad roles at high levels.
Reason: access follows team changes and stays reviewable. Trade-off: group management becomes a core duty.
Create projects only through an automated factory
New projects are created by reviewed code that applies naming, labels, billing, APIs and baseline access.
Reason: consistency and traceability. Trade-off: the factory needs building and maintaining, and teams need a fast request path.
Protect production projects with liens and restricted shutdown rights
Place liens on production projects and allow only a small group to remove them or delete projects.
Reason: avoids accidental loss. Trade-off: legitimate cleanup needs an extra approval step.
A decision record is a ship’s log. Years later, a new captain reads why the ship changed course and avoids the same rocks.
30Common Mistakes and Anti-Patterns
The cheapest education is learning from other teams’ mistakes.
Healthy Habits
- Start with an organization and a simple folder plan
- Grant access to groups at sensible levels
- Use consistent names, labels and tags
- Apply guardrails at the top, exceptions below
- Automate project creation and changes
Risky Habits
- Running everything in one project
- Granting Owner or Editor widely at high levels
- Letting individuals own critical projects
- Creating deep folder trees nobody understands
- Deleting projects without checking for dependencies
Five classic traps in detail
Mirroring the Org Chart Too Closely
Company charts change often, but cloud structures are hard to change. Prefer stable categories such as environment and product.
Forgetting Inheritance
A grant on a high folder quietly reaches projects added later. Review the whole path when assessing access.
Policies Without Testing
A new strict policy breaks existing workloads on the day it is applied. Trial it on a small folder first.
No Naming Standard
Without names and labels that follow rules, nobody can tell what a project is for, and cleanup becomes guesswork.
Trusting the Recovery Window
Teams assume anything deleted can be restored within 30 days, but some data is removed sooner and some settings need manual recovery.
These traps are loose floorboards in a house. Each seems harmless until someone carries something heavy across it.
31Troubleshooting Guide
Start with the simplest cause and work toward the hardest.
| Symptom | Likely Cause | What To Try |
|---|---|---|
| Cannot create a project | Missing project creation permission, or project quota reached | Check permission on the parent folder or organization, and the project quota |
| Project ID already taken | IDs are globally unique and cannot be reused after deletion | Choose a different ID following your naming standard |
| User has unexpected access | Inherited grant from a folder or the organization | Check policies at every ancestor, or use a policy analysis tool |
| User lacks expected access | No grant on the path, or a deny policy blocks it | Review allow and deny policies along the path |
| Resource creation blocked | An organization policy forbids it, such as a location or public address rule | Read the error, find the constraint and request a justified exception if needed |
| Cannot delete a project | A lien or missing permission | Look for liens, and check the delete permission |
| Restored project not working | Billing unlinked, services still resuming or need restart | Relink billing, wait for services and restart where needed |
| Cannot move a project | Missing permission on source or destination, or a policy conflict | Check permissions on both parents and policy rules at the destination |
| API calls fail with disabled message | The service API is not enabled in this project | Enable the API, or check whether policy restricts it |
A calm method
Locate the Resource in the Tree
Find its project, folder and organization. Write down the full path.
Check Access and Policy Along the Path
Look at allow, deny and organization policies at every level.
Read the Exact Error
Error messages usually name the missing permission or the blocking constraint.
Change One Thing at a Time
Adjust a single setting, retest and record what you learned.
Troubleshooting a locked door: find which door, check which key you hold, read the sign on the door, and only then call the locksmith.
32Best Practices Checklist
A short list to review whenever you set up or change your hierarchy.
Create an Organization First
Make the company, not individuals, the owner of every project.
Keep Folders Shallow and Clear
Two or three levels with names anyone can understand.
Separate Production
Give production its own folder, projects and stricter rules.
Use Groups and Least Privilege
Grant narrow roles to groups at the lowest sufficient level.
Protect Top Roles
Keep organization administrators few, protected and reviewed.
Review Regularly
Audit high-level grants and unused service accounts every quarter.
Set Policies at the Top
Apply organization policies and deny rules high up, with documented exceptions.
Add Liens to Critical Projects
Prevent accidental deletion, and restrict who can remove liens.
Label and Tag Consistently
Agree on keys and values, set them automatically and audit them.
Automate with Code
Describe the hierarchy as code, review every change and detect drift.
Set Contacts, Budgets and Alerts
Use group addresses for essential contacts and alert on spending and quotas.
A pilot walks through the same checklist before every flight, however experienced. The list does not express doubt. It expresses respect for what could go wrong.
33Frequently Asked Questions
Quick answers to the questions beginners ask most often.
It is the Google Cloud capability for organizing resources into a hierarchy of organization, folders and projects, and for managing access, policies, tags and project life cycle from central points. You use it through the console, the gcloud tool and an API.
You can use Google Cloud without one, with standalone projects, for example on a free trial. But a company should have one, since it gives company ownership of projects, central policy and a view of everything. An organization requires a Google Workspace or Cloud Identity account.
A folder only groups projects and other folders and carries access and policy for them. A project is the container that actually holds resources and is where APIs, billing links and quotas live.
The name is a changeable display label. The ID is a unique identifier you choose at creation and cannot change. The number is generated automatically and is read-only. Use the ID in requests and scripts.
Access grants, deny policies and organization policies set on a parent apply to its children. A resource’s effective rules combine what is set directly on it and what comes from every ancestor. Grants from parents cannot be removed by a normal allow policy on a child.
IAM controls who can perform actions. Organization Policy controls what is allowed to be done, such as which locations are permitted, regardless of who is asking. They work together and both are inherited.
Labels are free-form key and value pairs for filtering and cost reports. Tags are centrally defined, controlled pairs that can drive policy and governance. Use labels for informal grouping and tags when rules depend on the category.
The project is shut down at once and goes into a delete requested state, and the billing link is removed. It can be restored for 30 days, after which it is permanently deleted. Some services remove data sooner, so do not treat the window as a backup.
Yes, within the 30 day window, by someone with the restore permission. Billing must be relinked by hand, some services may take many hours to resume, and some may need a manual restart.
No. After a project is fully deleted, its ID cannot be reused. If you want to keep a specific ID, delete the resources inside the project instead of the project itself.
A lien is a marker that prevents a project from being deleted until the lien is removed. It is a strong protection for critical projects, though it does not replace backups.
Yes, with permissions on both the source and destination. After the move, the project inherits access and policy from its new ancestors, which may change who can do what, so compare both locations first.
Google documents limits on folder nesting and other quantities, and they can change. Check the current limits page. For clarity, most teams should keep the tree to two or three levels regardless of the maximum.
Under an organization, the project belongs to the organization, not to you, even though the creator is initially granted the owner role. In governed setups that owner role is replaced with group-based roles.
Use a consistent pattern that includes product or team and environment, such as a short product name followed by an environment word. Avoid personal names and secrets, and remember that IDs cannot be changed later.
Yes, in almost all cases. Separate projects for development, staging and production give isolation for access, quotas, costs and mistakes, and allow different policies per environment.
Check grants on the resource and on every ancestor, including groups the user belongs to, plus any deny policies. Policy analysis tools can compute this for you, which is far less error-prone than checking by hand.
I could not confirm a separate charge for the core hierarchy features on the pages I reviewed, and the cost of Google Cloud mainly comes from the services running in your projects. Check the official pricing pages for the current position, including for related governance tools.
Limit the project creation permission to a trusted group on the organization or specific folders, and give everyone else a fast request path. A new organization starts with domain-wide creation rights, so many companies tighten this early.
The hierarchy and billing accounts are separate but linked. Each project links to one billing account at a time. Use projects, labels or tags and billing exports to attribute costs, and multiple billing accounts when different parts of the company pay separately.
Confirm the owner, check for dependencies from other projects, back up data you need, check for commitments tied to the project, remove or review liens, and consider disabling billing. Then shut down during a quiet period.
You designate recipients for categories of notices such as billing, security, technical and legal. Contacts set high in the hierarchy cascade downward. Use shared group mailboxes so notices survive staff changes.
An organization policy may forbid it, for example a location or public address restriction. Roles say who may act, while organization policy says what is allowed. Read the error message to find the blocking constraint.
Yes, and larger organizations should. Folders, projects, access grants and policies can be described in configuration files, reviewed through version control and applied automatically, which gives repeatability and an audit trail.
Create an organization, make a few folders such as production and non-production, create one project per application per environment, grant roles to groups, set a budget with alerts and add labels. Grow the structure only when real needs appear.
Start with ownership and top-level access. List every project and who owns it, find projects outside the organization, and list everyone holding powerful roles at the organization and top folders. Fixing those two areas removes the largest risks quickly, and the rest of the cleanup can follow in stages.
Yes, deliberately. Projects are isolated by default, but you can connect their networks, share data through granted access and let one project’s service account act in another. The connection should be explicit, narrow and documented, so that isolation remains meaningful.
Review high-level access and policies every few months, review unused projects and service accounts at least twice a year, and review the folder design whenever the company reorganizes or launches a major product. Calendar these reviews, so they actually happen.
34Summary and Key Takeaways
Everything in this guide on one short page.
Cloud Resource Manager gives Google Cloud its shape. An organization at the top represents the company, folders group related work, projects hold resources, and every item has exactly one parent. Access, deny rules and organization policies flow downward, which makes the tree both a powerful control tool and a place where careless grants spread widely. A sensible structure, applied early and managed as code, saves enormous effort later.
Key Takeaways
- Build on an organization so that projects belong to the company, central policy is possible and staff departures never orphan services.
- Use folders sparingly and clearly, usually separating production from non-production, and create one project per application per environment for clean boundaries.
- Remember that access and policies are inherited downward: grant roles to groups at the lowest sufficient level, and review high-level grants regularly.
- Use Organization Policy for guardrails such as location limits, deny policies for critical protections, and tags for governance, while labels support cost reporting.
- Treat deletion carefully: projects stay recoverable for 30 days, but billing must be relinked, some data goes sooner, and IDs cannot be reused; protect critical projects with liens.
- Automate project creation and hierarchy changes as reviewed code, collect audit logs centrally and monitor budgets, quotas and contacts.
- Expect change: check current limits, role names and pricing on Google’s official pages before making large decisions.