Front matter

The Example Environment

A large technical book becomes difficult to follow if every chapter invents a completely different organization, network, project, region, and service account.

The examples therefore use one consistent fictional environment. Identifiers are stable across every chapter, so a project ID or a service account you meet in Chapter 2 means the same thing in Chapter 30.

It is not intended to be copied exactly into production. Its purpose is to make examples predictable.

Two reference estates §

The book carries two fictional estates, because the same control often has a different correct answer for a product company and for an enterprise.

The SaaS estate carries most of the book. The enterprise estate appears where the difference matters: the resource hierarchy, hybrid connectivity, and anything involving delegated administration across business units.

.domain is not a delegated top-level domain, so no example in this book resolves to a real host. Substitute a domain you control.

Both organizations share one example billing account:

01A2B3-C4D5E6-F7G8H9

Resource hierarchy §

organizations/123456789012            rickcollette.domain   (SaaS estate)
├── fldr-bootstrap
│   └── rc-saas-bootstrap-seed-01     Terraform state, factory identity
├── fldr-common
│   ├── rc-saas-shared-net-01         Shared VPC host
│   ├── rc-saas-shared-log-01         aggregated log sink destinations
│   ├── rc-saas-shared-sec-01         KMS, Secret Manager, SCC
│   ├── rc-saas-shared-art-01         Artifact Registry
│   └── rc-saas-shared-cicd-01        Cloud Build, Cloud Deploy, WIF pools
├── fldr-environments
│   ├── fldr-development   → rc-saas-dev-app-01,  rc-saas-dev-data-01
│   ├── fldr-nonproduction → rc-saas-stg-app-01,  rc-saas-stg-data-01
│   └── fldr-production    → rc-saas-prod-app-01, rc-saas-prod-data-01
└── fldr-sandbox           → rc-saas-sbx-<user>-01   (30-day TTL)

The enterprise estate adds a business-unit layer above the environment folders, so administration can be delegated per unit.

Naming §

Project IDs follow <prefix>-<env>-<function>-<nn>:

• prefix — rc-saas or rc-ent
• env — one of bootstrap, shared, dev, stg, prod, sbx
• function — one of app, data, net, log, sec, cicd, art
• nn — a two-digit ordinal, so a replacement can stand up beside its predecessor

Project IDs are globally unique across all of Google Cloud and can never be reused once deleted, so the exact values in this book will not be available to you. Substitute your own.

Other resource classes derive from the project:

Required labels §

Every project and every significant resource carries these five labels. They drive cost attribution, incident routing, and the scope of several detection rules:

env           bootstrap | shared | dev | stg | prod | sbx
owner         team slug
cost-center   cc-NNNN
data-class    public | internal | confidential | restricted
system        system slug

Addressing §

All examples use RFC 1918 or RFC 5737 documentation ranges. The SaaS production plan:

Real address allocation must be coordinated with the rest of your organization's private space before anything is deployed. Ranges that overlap on-premises or another cloud cannot be connected later without renumbering.

Identities §

Roles are bound to groups, never to individual users, so that access changes in the directory rather than in an IAM policy. The groups used throughout:

gcp-org-admins@rickcollette.domain
gcp-security-viewers@rickcollette.domain
gcp-network-admins@rickcollette.domain
gcp-prod-viewers@rickcollette.domain
gcp-prod-deployers@rickcollette.domain
gcp-app-developers@rickcollette.domain
gcp-app-operators@rickcollette.domain
gcp-billing-viewers@rickcollette.domain
gcp-breakglass@rickcollette.domain

Where an example needs an individual, it is written USERNAME@rickcollette.domain.

Workloads use purpose-named service accounts — sa-app-api-runtime, sa-deploy-prod, sa-data-postgres — one per workload, never one per team, and never shared across environments. None of them has a downloadable key; the book uses attached service accounts and Workload Identity Federation throughout, and explains why.

DNS §

rickcollette.domain                     public zone
api.rickcollette.domain                 public application endpoint
prod.internal.rickcollette.domain       private zone, production VPC
corp.rickcollette.domain                forwarded to on-premises resolvers

Environments §

Three application environments, plus disposable sandboxes:

dev     stg     prod     sbx

Development is not treated as production. Production carries narrower IAM, no standing human write access, protected deployment paths, longer retention, deletion protection, and full audit coverage. The differences are stated explicitly wherever they matter rather than left implied.

The example application §

A conventional multi-service platform: a public web and API service, background workers, a relational database, object storage, a cache, asynchronous messaging, secrets, CI/CD, and monitoring. Different chapters implement its parts on Cloud Run, GKE, Compute Engine, Cloud SQL, Pub/Sub, Memorystore, and Cloud Storage.

The application is intentionally boring. The infrastructure is the subject of the book.