Front matter

Preface

I did not write this book because Google Cloud needs another list of services.

Google already documents its products. There are certification guides that tell you which concepts appear on an exam. There are tutorials that show you where to click in the Console. There are thousands of posts that solve one narrow problem at a time.

Those things are useful, but they are not the same as understanding how to operate a cloud environment.

The problem I wanted to solve is the gap between knowing what a GCP service does and knowing how that service belongs in a system you are responsible for.

That difference matters.

A production cloud environment is not a collection of product pages. Identity affects networking. Networking affects application architecture. Application architecture affects logging. Logging affects incident response. CI/CD affects security. Security affects deployment. Cost controls affect design. Backups are meaningless until recovery has been tested. Infrastructure as code is not just a convenient way to create resources; it changes how the environment should be reviewed, reproduced, audited, and repaired.

The useful question is rarely:

What does this GCP service do?

The useful questions are usually:

• Why would I use it?
• Where does it belong?
• What should be allowed to talk to it?
• Which identity should operate it?
• How do I build it without relying on a human clicking through the Console?
• How do I know when it is broken?
• How do I know when it has been compromised?
• How do I replace it?
• How do I recover it?
• What happens when the clean architecture diagram meets production?

That is the point of this book.

The SecDevOps point of view §

I use SecDevOps deliberately.

Security is not a final stage that happens after somebody has finished building the system. Operations are not something that begins after development hands the application over. Automation is not simply a way to make deployment faster.

Those concerns are part of the architecture.

A service account with too much privilege is an architecture problem. A production environment that can only be reproduced from somebody's memory is an architecture problem. A firewall rule that nobody can explain is an architecture problem. A deployment pipeline that can push arbitrary code directly to production is an architecture problem. A backup nobody has restored is an architecture problem.

This book therefore treats security, development, infrastructure, deployment, and operations as parts of the same system.

This is not a certification book §

You can certainly use this book to strengthen your understanding of concepts that appear in Google Cloud certifications, but certification is not the organizing principle.

I am much more interested in what happens after the exam.

The examples favor the kinds of choices I would want to see in a real environment: private connectivity where practical, machine identity instead of stored credentials, least privilege, centralized logging, repeatable infrastructure, controlled changes, explicit trust boundaries, observable systems, and recovery plans that have actually been tested.

That also means I will sometimes spend more time on an operationally important subject than its place in a certification blueprint would suggest.

This is not a Console walkthrough §

The Google Cloud Console is useful, and sometimes it is the fastest way to inspect something.

It is not the source of truth for the environments built in this book.

The preferred model is:

define it, review it, version it, apply it, observe it, and be able to rebuild it.

Terraform and OpenTofu are therefore first-class parts of the book. Ansible is used where configuration management or day-two host operations are more appropriate than resource provisioning.

The command line also matters. A graphical interface can hide important details. Commands, API behavior, state, and configuration are often much easier to reason about when they are explicit.

SaaS and enterprise are both here on purpose §

Small cloud-native SaaS systems and large enterprise environments are not the same thing.

A young SaaS platform may reasonably use Cloud Run, Cloud SQL, Pub/Sub, Secret Manager, and a relatively small project structure. A large enterprise may need Shared VPC, hybrid networking, centralized security projects, organizational policies, federation, multiple business units, compliance boundaries, and a project factory.

Neither architecture should be forced into the other one's shape.

This book develops the common foundations first and then shows how those foundations diverge into modern SaaS and enterprise designs.

The cloud will change while you are reading this §

That is unavoidable.

Google Cloud will add services, rename things, change interfaces, modify quotas, deprecate features, and improve existing platforms. Terraform and OpenTofu will change. Providers will change. Kubernetes will change.

A printed technical book cannot pretend otherwise.

For that reason, this book separates durable architecture and operating principles from implementation details that are expected to move. The companion repository is where tested code, corrections, and version-specific changes belong.

When the screenshot and the API disagree, trust the API and current documentation.

When the example and production disagree, investigate production.

When somebody says, "We have always done it this way," ask why.

That is the spirit in which this book was written.