Business Challenge
The blueprint is usually met as a repository somebody cloned, and all four of these follow from treating it as a template rather than as a sequence.
The stages are ordered because each one builds what the next assumes. Stage 0 bootstraps a Google Cloud organization and configures a CI/CD pipeline for the blueprint code in subsequent stages — so every later stage runs on machinery the first one created. Skipping ahead means hand-building the thing you skipped.
Correct approachRead the stages as a dependency chain, not a menu. You can simplify what each stage produces; you cannot easily reorder them.
You do, by hand, with your own credentials. The bootstrap stage produces a seed project holding the Terraform state and the privileged service accounts, plus a CICD project running the pipeline — and neither can be created by the pipeline they are about to become.
Correct approachPlan that one step as a deliberate, witnessed, logged event. It is the single most privileged action in the foundation's life, and the only one with no pipeline, no review gate and no state file behind it.
It is, and the two exist precisely to be less simple. The foundation pipeline deploys the resources used across the platform; the infrastructure pipeline handles projects and infrastructure used by workloads. Merging them gives every workload team the credentials that can rewrite the organisation.
Correct approachKeep the split even at small scale. It is the same reasoning as post #26's deployment service account, applied one level up.
The blueprint offers two topologies and neither is that. Either use separate Shared VPC networks for each environment, with no network traffic directly allowed between environments; or use a hub-and-spoke model that adds a hub network to connect each environment, with traffic between them gated by a network virtual appliance.
Correct approachChoose on whether environments must talk. If they must not, the first is simpler and stronger; if they must, the hub is where you put the control rather than hoping firewall rules cover it.
Architecture
The blueprint describes the best practices that let you deploy a foundational set of resources in Google Cloud, and it arrives in two halves: a guide describing the architecture and controls, and a Terraform repository that deploys them.
The folders
| Folder | What it holds |
|---|---|
| Bootstrap | The projects that are used to deploy foundation components. |
| Common | Projects with resources that are shared by all environments. |
| Production | Projects with production resources. |
| Nonproduction | A copy of the production environment, to test workloads before promoting them. |
| Development | The cloud resources used for development. |
| Networking | The networking resources shared by all environments. |
Two of those are worth pausing on. Bootstrap being a folder in the hierarchy rather than a scratch project is the blueprint saying the machinery is part of the estate and governed like it. And nonproduction as a copy of production — not a smaller, cheaper approximation — is what makes a test meaningful, and is the line most organisations quietly redraw first.
The six stages
| Stage | Does | Pipeline |
|---|---|---|
0-bootstrap | Bootstraps the organization and configures the CI/CD pipeline for later stages. | — run by hand |
1-org | Organisation structure and baseline security. | Foundation |
2-environments | The development, nonproduction and production environments. | Foundation |
3-networks | Shared VPCs and network resources. | Foundation |
4-projects | Sets up a folder structure, projects, and an infrastructure pipeline. | Infrastructure |
5-app-infra | An example of deploying workload infrastructure. | Infrastructure |
Notice where the boundary falls. Stages 0 to 3 are the platform team's; 4 and 5 are the workload teams'. Stage 4 is the hinge — it creates the projects and the pipeline that later fills them, which is how a business unit gets self-service without getting the organisation's credentials.
Stage 0 produces a seed project holding the Terraform state and the privileged service accounts, and a CICD project running Cloud Build. Everything afterwards runs through that machinery. But the machinery cannot create itself, so stage 0 is executed with a human's credentials against an organisation that has no guardrails yet — before the organization policies of post #22, before the pipelines, before the audit trail is pointed anywhere useful. Post #25 argued the state bucket is a credential store; this is the hour in which it is created, by someone acting as themselves. Treat it as a ceremony: named people, a recorded session, and credentials rotated afterwards.
Two pipelines, and why the split is the point
The foundation pipeline deploys the foundation resources used across the platform. The infrastructure pipeline handles projects and infrastructure used by workloads — VM instances, databases — typically per business unit.
The separation exists so that the service account able to create a folder is never the service account a workload team can reach. Post #26 made this argument about a single deployment identity; the blueprint makes it structural, with different pipelines, different projects and different privileged accounts. If you take one idea from the blueprint and implement nothing else, take this one.
Networking: pick the topology, not the firewall rules
Both options use Shared VPC as the principal networking construct, because it allows a clear separation of responsibilities. The choice above it is binary:
- Separate Shared VPC per environment, with no network traffic directly allowed between environments. Isolation by absence of a path, which is the strongest kind.
- Hub-and-spoke, with a hub network connecting each environment and traffic between them gated by a network virtual appliance. Connectivity where you need it, with one place to inspect it.
Both put the decision in the topology rather than in a firewall rule, which is the difference between a control you can describe in a sentence and one you have to audit.
Why This Architecture Holds Up
Most of this series has argued about one component at a time. The blueprint is what those arguments look like assembled, and several of them show up as settled decisions:
| Earlier post | What the blueprint does with it |
|---|---|
| #18, naming standards | Publishes a convention with a random suffix on project IDs — the case that post made from first principles. |
| #22, day-one policies | Applies them in stage 1, before any workload exists, which is the "actually on day one" the post asked for. |
| #25, Terraform state | Puts state in the seed project with privileged accounts, access held narrowly. |
| #26, deployment identity | Generalised into two pipelines with separate privileged service accounts. |
| #23, asset inventory | Detective controls are a first-class section rather than an afterthought. |
What to expect to change
- The environment count. Three environments is a reasonable default and a poor fit for organisations with staging, UAT and a regulated production. The folder pattern extends; the stage-2 code has to follow it.
- Nonproduction as a full copy. The most expensive recommendation in the blueprint, and the first one trimmed. Trim it knowingly — the value of the environment falls with its fidelity.
- The network topology. Genuinely a choice, and one that is hard to reverse once workloads depend on the paths.
- The pipeline tooling. Cloud Build in the blueprint; the shape matters more than the product, and post #26's Infrastructure Manager is a legitimate substitute for the foundation half.
The two-pipeline split and the day-one organization policies are the parts doing the most work per line of code, and both are far cheaper to keep than to retrofit. Post #22 made the retrofit argument for policies: enforcement is not retroactive, so the same list applied in year three is a remediation project per constraint. The pipeline split is worse, because unpicking a shared privileged account after teams depend on it means changing how every team deploys.
Using it without adopting it
The blueprint is deployable Terraform, and it is also a checklist. An organisation already running on Google Cloud gets more from reading it as a gap analysis than from attempting to apply it: compare your folder structure to the six, your pipeline count to two, your network topology to the pair on offer, and your day-one policies to stage 1. Each difference is either a decision you made deliberately or one you have not made yet, and the second kind is the reason to read it.
Key Architecture Decisions
| Decision | Choose this | Because |
|---|---|---|
| Adopting the blueprint | In stage order | Stage 0 configures the CI/CD pipeline every later stage runs on. |
| The bootstrap step | A named, witnessed, logged ceremony | It runs with human credentials against an organisation with no guardrails yet. |
| Pipeline count | Two, even when small | Foundation resources and workload resources need different privileged accounts. |
| Where self-service begins | Stage 4 | It creates the projects and the infrastructure pipeline that fills them. |
| Environments that must not talk | Separate Shared VPC, no direct traffic | Isolation by absence of a path is the strongest form. |
| Environments that must talk | Hub-and-spoke with an NVA | One gated place to inspect traffic, rather than distributed firewall rules. |
| Nonproduction fidelity | Trim it knowingly, if at all | It is meant to be a copy of production; the test's value falls with its fidelity. |
| Bootstrap as a folder | Keep it in the hierarchy | The machinery is part of the estate and should be governed like it. |
| An estate already running | Read it as a gap analysis | Each difference is a decision made deliberately or one not yet made. |
| What to keep when trimming | The pipeline split and the day-one policies | Both are far cheaper to keep than to retrofit. |
Closing Thought
The useful thing about the blueprint is not that it is right. It is that it is complete — it takes a position on every question this series has raised, in an order that works, with the dependencies made explicit by the stage numbers. Most foundation documents are lists of good ideas with no sequence, and a sequence is the part that is hard.
What it cannot give you is the reasoning, which is why reading it cold tends to produce cargo-cult adoption — a folder called nonproduction that is a third the size of production, two pipelines merged for convenience, day-one policies deferred until after the first workload. Every one of those is defensible if made deliberately and corrosive if made by default. The blueprint is at its best read as the answer sheet to questions you have already tried to answer, which is roughly what the last twenty-eight posts were for.
#30 does the harder version: landing zone design for a real organisation — what changes when the blueprint meets an existing estate, a regulator, and teams who were already deploying before anyone wrote a foundation.
Comments