Front matter

Software and Version Policy

This book describes a platform that changes continuously.

That is not a footnote. It is part of the engineering problem.

Google Cloud services evolve. APIs are added and removed. User interfaces change. Kubernetes versions advance. Terraform providers gain and deprecate arguments. OpenTofu evolves. Ansible collections change. Security recommendations improve. Defaults that were once reasonable become obsolete.

A useful cloud book must acknowledge that directly.

Durable concepts and moving implementation §

The book separates two kinds of knowledge.

Durable concepts §

These should remain useful even when a product interface changes:

• least privilege;
• identity-based access;
• explicit trust boundaries;
• private connectivity;
• immutable or reproducible infrastructure;
• version control;
• policy as code;
• centralized auditability;
• defense in depth;
• failure-domain design;
• tested recovery;
• deployment separation;
• observable systems;
• controlled change.

Moving implementation §

These are expected to change more frequently:

• exact command flags;
• API versions;
• Terraform provider arguments;
• product limits;
• supported Kubernetes releases;
• Console navigation;
• service names;
• default settings;
• pricing;
• quotas;
• beta and preview capabilities.

The book tries not to confuse the second category with the first.

GCP changes §

Google Cloud may change:

• product names;
• service availability;
• supported regions;
• quotas;
• IAM permissions;
• API behavior;
• Console interfaces;
• recommended architectures.

When exact current behavior matters, use the current Google Cloud documentation and release notes alongside this book.

Screenshots §

Screenshots, where used, illustrate a concept at a point in time.

Do not assume that a menu item will remain in the same location forever.

A changed Console layout does not necessarily mean the architecture or API has changed.

API behavior §

Infrastructure automation should rely on documented APIs and provider behavior rather than on the visual arrangement of the Console.

When a chapter depends on a specific API capability, the companion repository should identify the version or provider constraint used for testing.

Terraform providers §

Terraform examples should pin provider versions in the downloadable repository.

Do not copy a provider block from a book and then assume the newest provider released years later will behave identically.

A real environment should make provider upgrades an intentional change:

1. review release notes;
2. update constraints;
3. initialize;
4. run validation;
5. run a plan;
6. review changes;
7. test outside production;
8. promote deliberately.

OpenTofu §

OpenTofu follows its own release process.

Examples that use common HCL and compatible providers may work without modification across both Terraform and OpenTofu, but compatibility should be tested rather than assumed indefinitely.

The companion repository should document known compatibility.

Ansible §

Ansible behavior can vary with:

• ansible-core version;
• Python version;
• collection version;
• target operating system;
• target package versions.

Collections used by examples should be versioned in a requirements file when practical.

Kubernetes §

GKE is a managed Kubernetes platform, but Kubernetes version skew still matters.

Examples should avoid depending unnecessarily on APIs that are already deprecated.

Before applying older manifests to a current cluster, check the Kubernetes API version and GKE release documentation.

Book versions §

Each published revision should carry a visible book version.

For example:

Edition: First Edition
Book version: 1.0
Publication date: 2026

Minor corrections can increment the book version without presenting the work as a completely new edition.

Companion repository versions §

The repository should tag the exact state associated with each publication version:

book-1.0
book-1.1
book-2.0

The default branch may continue forward.

The tag is the reproducible snapshot.

Errata §

Confirmed errors should be corrected online as soon as practical.

The errata page should identify:

• edition;
• version;
• chapter;
• section or page;
• incorrect text or code;
• corrected material;
• date confirmed.

What to do when the book and current documentation disagree §

Do not blindly follow either source.

Determine why they disagree.

A changed flag may be harmless.

A removed API may require migration.

A changed security recommendation may be important.

The right response is investigation, not loyalty to an old example.

A cloud engineer should expect change. The job is to make change controlled, visible, testable, and recoverable.