Google Cloud / Advanced: Governance, Reliability, and Architecture / Lesson 14
Infrastructure as Code and Change Management
Use declarative intent, state, plan review, identity, and recovery as one change process rather than treating a successful plan as authorization.
On this page
Lesson goals
- Distinguish configuration, provider schema, state, plan, and apply.
- Protect state and review replacement/drift.
- Interpret a synthetic change list without running Terraform.
Configuration describes desired state, not current truth
Terraform configuration declares resources through provider schemas; state tracks managed identities and attributes; planning compares intent, recorded state, and refreshed information under the selected workflow. These are different artifacts. A source change does not itself change Google Cloud, and a plan is neither proof of application health nor permission to apply.
Pin and review Terraform/provider versions and dependency selections for the actual module. Provider defaults and schemas evolve. Separate environment inputs, project/region selection, module interfaces, and workload identity. This course installs no provider and runs no init, validate, plan, apply, import, refresh, or destroy command.
An excerpt still requires a complete reviewed module
The non-runnable excerpt describes bucket access intent using Google provider resource fields. Variables, provider selection, state backend, project, lifecycle decisions, and authorization are intentionally outside the excerpt. It is not a ready deployment. Its purpose is to connect a declarative field to a documented service control without claiming provider or API validation.
A reusable module should expose meaningful inputs and outputs, not every provider attribute indiscriminately. Separate routine application changes from foundational network or policy ownership. Review what replacing or renaming a resource would mean for stored data and references before approving any plan.
resource "google_storage_bucket" "archive" {
name = var.bucket_name
location = var.region
uniform_bucket_level_access = true
public_access_prevention = "enforced"
}
The excerpt is not initialized, validated, planned, or applied and is not a complete module.
State is sensitive operational data
Terraform state can contain resource identifiers and sensitive values. Marking an output sensitive affects presentation; it does not automatically remove secrets from state. Protect backend access, encryption, locking/concurrency, version history, recovery, and separation of environments according to the selected backend’s contract. Never commit real state or credentials as a teaching convenience.
Only one reviewed process should own a resource’s desired state. Manual cloud edits can create drift, while overlapping tools can repeatedly undo one another. Imports and moved-resource declarations have specific semantics; they are not harmless renames. Review how existing resources enter management without unintended recreation.
Flag destructive intent in a synthetic change list
The offline Python program counts a create/delete replacement in an invented change list. It deliberately does not claim to parse every Terraform plan schema or decide whether a replacement is safe. A real plan review should inspect the provider/resource version, exact attributes, dependencies, data lifecycle, and approval scope.
Do not infer safety from “no changes” alone. The desired configuration may omit an important control, drift may be outside managed resources, and a plan cannot test recovery or user-facing behavior. Separate syntactic/schema checks, policy checks, reviewed plan, authorized execution, and post-change validation.
changes = [{"address": "bucket.archive", "actions": ["delete", "create"]}, {"address": "service.reader", "actions": ["update"]}]
replacements = [item["address"] for item in changes if {"delete", "create"}.issubset(item["actions"])]
print("replacement review", ",".join(replacements))
replacement review bucket.archive
The local convention flags bucket.archive; it reads no state and performs no cloud operation.
Approval includes rollback and verification
Record the reason, target environment, identity, reviewed artifact, expected changes, data protection, rollback/roll-forward strategy, and post-change checks. A rollback can itself require a migration; reverting source text does not guarantee restoration of deleted data. Keep emergency changes auditable and reconcile them back into the owned configuration.
Use isolated, authorized validation for real infrastructure work. The course’s source excerpts remain documentation, and its Python review operates only on embedded invented records. No state backend is opened, no credential discovered, and no cloud or Terraform operation performed.
Common errors and fixes
A plan is treated as approval to apply.
- Why it happens
- Technical preview and authorization were conflated.
- How to fix it
- Require an explicit reviewed change process.
- Prevent it next time
- Record artifact, identity, target, and approval scope.
Sensitive output is assumed absent from state.
- Why it happens
- Display redaction was confused with storage protection.
- How to fix it
- Protect and inspect state handling under the backend contract.
- Prevent it next time
- Keep credentials and real state out of source.
Reverting code is called complete rollback.
- Why it happens
- Resource/data side effects were omitted.
- How to fix it
- Design recovery and migration-aware rollback before execution.
- Prevent it next time
- Review replacement and deletion consequences.
Check your understanding
1. A plan replaces a bucket that stores required records. What must be established before any authorized implementation?
Show worked solution
Determine why replacement occurs, what data and references exist, retention/lock constraints, protection and restore evidence, migration order, identity permissions, and rollback/roll-forward strategy. A source diff alone cannot establish data safety. Review the exact plan artifact and service/provider behavior; do not test the hypothesis by applying it to a real bucket from a lesson.
2. Why can a no-change plan coexist with an insecure or incomplete design?
Show worked solution
The configuration may intentionally or accidentally omit a required control, and some resources or settings may be outside its managed scope. A plan compares under its workflow; it does not infer business requirements, check every policy, or demonstrate application recovery. Keep architecture review, policy evaluation, and operational tests distinct from state convergence.
Key takeaways
- Intent, state, plan, approval, execution, and service validation are different artifacts.
- Protect state and manage drift through clear ownership.
- A local replacement check is not Terraform or cloud validation.