Front matter

A Note About Terraform and OpenTofu

This book covers both Terraform and OpenTofu because infrastructure code should not be taught as though the tool name is more important than the operating model.

Both tools use HashiCorp Configuration Language for the kinds of configurations shown throughout this book. Both are capable of managing Google Cloud infrastructure through provider-driven resource definitions. For a large amount of everyday GCP infrastructure code, the configuration is intentionally very similar.

That does not mean the tools should be treated as permanently identical.

Why both are included §

There are real environments standardized on Terraform.

There are real environments standardized on OpenTofu.

A SecDevOps book aimed at working engineers should not force the reader to mentally translate every example simply because their organization chose the other compatible tool.

Where the same configuration works with both, the book says so.

Where the tools differ in a way that matters, the difference is shown explicitly.

What is generally interchangeable §

Many examples use common constructs such as:

• terraform blocks;
• providers;
• resources;
• data sources;
• variables;
• locals;
• outputs;
• modules;
• for_each;
• count;
• lifecycle rules;
• expressions;
• remote state patterns.

The Google provider resources used to create GCP infrastructure are also commonly usable from both ecosystems, subject to the provider version and registry behavior supported by the tool version in use.

What is not safe to assume §

Do not assume that future versions of Terraform and OpenTofu will remain behaviorally identical in every area.

Differences may appear in:

• language features;
• state handling;
• encryption capabilities;
• provider installation;
• registry behavior;
• command-line options;
• backend behavior;
• metadata;
• module features;
• future ecosystem integrations.

When a feature is tool-specific, the book identifies it as such.

Commands §

Terraform commands use the terraform executable:

terraform init
terraform validate
terraform plan
terraform apply

OpenTofu commands use tofu:

tofu init
tofu validate
tofu plan
tofu apply

Do not create shell aliases that hide which engine is running in production automation unless your team has deliberately designed and tested that abstraction.

State §

State is operationally sensitive regardless of which tool manages it.

State can expose:

• resource identifiers;
• infrastructure relationships;
• network information;
• metadata;
• and, depending on resources and provider behavior, sensitive values.

Treat state as protected infrastructure data.

Remote state should have:

• restricted IAM;
• encryption;
• versioning or another recovery mechanism;
• controlled access;
• a documented recovery process.

Do not put state files in Git.

Plans are security-relevant artifacts §

A plan is not merely a preview for convenience.

It is a statement of intended change.

Production pipelines should preserve a reviewable relationship between:

1. the reviewed source commit;
2. the generated plan;
3. the identity approved to execute it;
4. the environment being modified.

The farther those four things drift apart, the less meaningful the review becomes.

Modules §

Reusable modules are encouraged, but a module should simplify infrastructure rather than conceal it.

A module that nobody understands is not automatically safer because it has fewer lines in the calling configuration.

Good modules have:

• a narrow purpose;
• explicit inputs;
• useful outputs;
• versioning;
• documentation;
• secure defaults;
• tests;
• clear ownership.

The examples in this book §

Examples are written to emphasize architecture first.

The downloadable repository should state the versions against which each major example set was tested.

If you are using a newer Terraform, OpenTofu, or provider release, read the plan.

Always read the plan.