GCP
Google Cloud (GCP) is organised around a hierarchy that inherits: an organisation contains folders, folders contain projects, and a project contains everything else. That sounds administrative and it is the most consequential thing on the platform, because a project is cheap enough to create for one service and complete enough to delete in one action. This page covers the hierarchy and what inherits down it, why service accounts are the usual way in, the network model that differs from everyone else's, and where the platform is genuinely strong and genuinely not.
- The unit
- The project
- Roles
- Inherit downward
- The network
- Global, not regional
A hierarchy that inherits, and a boundary that is cheap
Everything you create lives in a project, and every project has an owner, a billing account, its own quotas and its own set of enabled services. Projects can be grouped into folders, folders into more folders, and all of it under one organisation that corresponds to your company domain. The tree is not decoration: permissions granted at any level apply to everything beneath it, so a role given at the folder level reaches every project inside it, now and in future.
The rule that matters most about that inheritance is that it is additive. Granting a narrower role further down does not reduce what was granted higher up — the effective permission is the union of everything inherited, so a broad grant near the top of the tree quietly widens every project underneath it. There is a separate deny mechanism, added later, that does take precedence, and it exists precisely because the additive model has no way to say "except here". Treat a grant at the organisation or folder level as a decision about every project that will ever exist below it.
When a boundary is cheap
- You make one per service per environment, because it costs a minute and no money.
- Blast radius shrinks by default — a mistake reaches one project, not the company.
- Cost allocation is free: the project is the line on the bill, with no tagging discipline needed.
- Cleanup is one action — deleting the project removes everything that was ever in it.
When it is expensive
- You make as few as you can justify, and share the ones you have.
- Environments end up separated by naming conventions, which stop nothing.
- Cost allocation needs tags nobody applied consistently from the first day.
- Cleanup is an archaeology project, so nothing is ever cleaned up.
That is the practical difference worth carrying away, and it is not a claim that one platform is better. It is that the price of a boundary decides how many boundaries a team creates, and the number of boundaries decides how far a mistake travels. On Google Cloud the honest default is a project per service per environment, folders that mirror how the organisation actually delegates ownership, and grants made as low in the tree as they can be. Deleting a project is reversible for a recovery window and then it is not, which is exactly the property you want from a cleanup mechanism.
Service accounts are the way in
A service account is the identity a workload uses: a virtual machine, a container, a scheduled job. What makes it worth understanding carefully is that it is two things at once. It is a principal — something that can be granted roles and make calls. It is also a resource — something that other principals can be granted permissions on. Once you see that, the classic escalation becomes obvious: a person who cannot read a database but can impersonate a service account that can, can read the database. Permission to act as an identity is permission to do everything that identity can do.
The practical consequence is that you should almost never create a service account key. A downloaded key is a permanent credential in a file, and it has the same failure story as any long-lived secret: it lands in a repository, a build variable, a laptop and a chat message, and its use is indistinguishable from legitimate use. Everything inside the platform can get credentials without one — a workload is attached to a service account and receives short-lived tokens automatically. Everything outside it, including a pipeline running elsewhere, can use workload identity federation, which lets an external system prove who it is and receive a short-lived token in exchange. The correct number of key files in a mature setup is zero.
A global network, and where the platform actually leads
One architectural difference is worth stating plainly because it changes designs rather than opinions: a virtual private network here is a global object, and subnets inside it are regional. Two machines in different continents can sit in the same private network and reach each other by private address with nothing peered, nothing tunnelled and no gateway in between. On the other large clouds a virtual network is regional, and connecting two regions is a piece of infrastructure somebody has to build and operate. If your system is genuinely multi-region, that difference removes an entire layer of work.
The corollary is that a network can span projects. A shared network lets one project own the addressing, the firewall rules and the connectivity while other projects attach workloads to it — so a network team keeps control of the network without owning every service in the company. That combination, a cheap project boundary plus a network that crosses it, is the shape most Google Cloud estates converge on, and it is worth designing toward deliberately rather than arriving at after three reorganisations.
On strengths and weaknesses, the fair summary is narrow rather than sweeping. The data and analytics stack is the platform's centre of gravity: a warehouse you query without provisioning anything, and the machine-learning tooling around it, are genuinely ahead and are the reason many organisations arrive. Kubernetes runs well here, which is unsurprising given where it came from. Against that: the long tail of services is thinner than the oldest cloud's, regional coverage for some services lags, and the platform has retired products often enough that "will this still exist in five years" is a question a serious buyer should ask out loud rather than treat as cynicism.
How this shows up in real delivery
Quotas are the operational fact that catches teams out, because they are per project and per region rather than per company, and several of them are low by default. A service that scales fine in staging can stop scaling in production simply because the production project has a different limit, and the failure arrives as a refused request rather than as a slow one. Check the limits for anything you plan to scale before you plan to scale it, and request increases in advance — approval is not instant, which makes it a poor thing to discover during a launch.
Because a project is the billing unit, cost attribution is a structural property rather than a discipline: if every service has its own project, the invoice already tells you what each service costs, with no tagging convention to enforce. Use that. Set a budget with an alert on every project the day it is created — an alert does not stop anything, but it converts a runaway job from a month-end discovery into a same-day one. And export the detailed billing data to the warehouse rather than reading the console, because the questions worth asking are comparisons over time.
One more thing that is specific enough to be worth naming: a service must be explicitly enabled in a project before it can be used, and the first call to a service that is not enabled fails with an error that names the problem clearly if you read it. This is a feature — it keeps a project's attack surface to what it actually uses — and it is a recurring five-minute confusion for anyone who creates projects from code without enabling services in the same step. Put the enablement in the infrastructure code next to the resources that need it.
Where it degrades
- One project holding everything, which throws away the cheapest boundary the platform offers.
- A broad role granted at the organisation or folder level, which quietly widens every project below.
- Downloaded service account keys, when the platform can issue short-lived credentials instead.
- Workloads left on the default service account, running with far more permission than they call.
- Permission to impersonate a service account, granted as though it were weaker than the roles it holds.
- Scaling plans made without reading the per-project quota, which refuses rather than slows.
- No budget alert on a new project, so a runaway job is a month-end discovery.
- Adopting a service without asking about its deprecation history, on a platform that has one.
When to use it
Use it when
- Data-heavy products, where the warehouse and the analytics tooling are the reason to be here at all.
- Teams that want many small isolated environments, since the boundary costs a minute and no money.
- Genuinely multi-region systems, where a global private network removes a layer of connectivity work.
- Kubernetes-centred platforms, where the managed offering and the ecosystem fit together closely.
Avoid it when
- Requirements that name a service only the oldest cloud has, where portability arguments will not survive contact.
- Organisations already deep in another vendor's identity and licensing, where the switching cost is not technical.
- Products needing a specific region or compliance regime the platform does not cover — check before designing.
- Long-horizon commitments to a niche managed service, without asking what its deprecation record looks like.
Found this useful?
Share it with someone who is working on the same problem.