In 06-05 everything was said except the essential part. You know what the problem is — AlpinaShop's infrastructure exists only because Marta ran the right commands, and nobody would know how to reproduce it — you know what infrastructure as code is, you understand state and you know the migration procedure step by step. What is missing is the tool to do it with.

This lesson brings it, and with it the module closes. By the end, AlpinaShop's VPC, its subnets, its firewall rules and its buckets will be written in files that get reviewed in a pull request, applied from a pipeline and reproduced in another region by changing one variable. And the answer to "how long does it take to rebuild the environment?" will go from "nobody knows" to "about twenty minutes".

A word about scope: this lesson teaches enough Terraform to manage AlpinaShop's infrastructure with good judgement. Terraform is worth a whole course of its own, and what is covered here is what gets used 95 % of the time, flagging what is left out.

1. Why Terraform won
2. The concepts: provider, resource, data source, variable, output and dependencies
3. State: what it contains and why it never goes into Git
4. The remote backend in Cloud Storage
5. The workflow: init, validate, plan, apply, destroy
6. How to read a plan
7. AlpinaShop's real code: the network and the bucket
8. Variables, tfvars and environments
9. Modules: writing the red-alpinashop module
10. Public registry modules, with judgement
11. Importing what already exists
12. Terraform in CI/CD: plan on every pull request
13. What Terraform should NOT manage
14. prevent_destroy and the danger of terraform destroy
15. Infrastructure Manager and alternatives
16. AlpinaShop's final state

In 06-05 you saw why Deployment Manager lost. The other side of the coin is why Terraform won, and it is not down to technical merit alone:

The first row matters more than it seems even for somebody who only uses GCP. AlpinaShop's real infrastructure is not just GCP: there is a DNS record at the domain registrar, repositories and branch protections on GitHub, perhaps an external CDN tomorrow. With Terraform, all of that is declared in the same place with the same flow, and dependencies between providers work exactly as they do within one.

A note on the licence, because one has to be honest: in 2023 HashiCorp moved Terraform from an open source licence to the Business Source License, which prompted the appearance of OpenTofu, a fork under an open licence managed by a foundation. For normal use — a company managing its own infrastructure — the BSL imposes no practical restriction, and both tools are compatible at the level of code and of state. It is worth knowing about; for AlpinaShop it changes nothing.

Terraform is written in HCL (HashiCorp Configuration Language), and it has few kinds of block. With these six you do almost everything.

Provider (provider): the plugin that knows how to talk to an API. It is declared with its version pinned:

Pinning the provider version is not optional. Without version, Terraform downloads the latest available, and a major version can change the behaviour of existing resources. The ~> 6.0 syntax allows minor and patch updates but not the jump to 7, which is where the breaking changes are.

Resource (resource): something Terraform creates and manages.

The distinction between the local name (principal) and the name attribute (alpinashop-vpc) is confusing at first. The local one is the label other parts of the code use to reference the resource; the name attribute is what appears in the GCP console.

Data source (data): queries something that exists but that Terraform does not manage.

The difference from a resource is total: a data only reads, it never creates or modifies. It is used to obtain the project number, the latest image of an operating system or a resource created by another team.

Variable (variable): a parameterisable input.

The validation block is the equivalent of Deployment Manager's schemas from 06-05, and it produces a clear error before anything is touched.

Output (output): a value exposed when the run finishes.

sensitive = true stops the value appearing in the output. It does not encrypt it or hide it from the state, which is an important distinction and one we come back to in section 3.

Dependencies. Most are implicit: they arise from referencing one resource from another.

Terraform builds a graph, creates the network first and then the subnet, and parallelises everything that has no dependencies between the parts. Explicit ones with depends_on are the last resort, for dependencies that are not expressed through data:

Tip: use depends_on as little as possible. A depends_on that could be replaced by a reference is a missed opportunity for the code to express the real relationship.

In 06-05 state was explained conceptually. Here comes the practical part, which is where the real problems live.

The terraform.tfstate file is a JSON containing, for each managed resource: its local name, its type, its real identifier in GCP and all of its attributes as they were at the last operation.

Look at that last line. The password is in plain text in the state file. It is not a configuration mistake: it is the normal behaviour. Terraform stores every attribute of every resource, and some attributes are secrets. The same happens with generated keys, tokens and certificates.

Hence the four rules of state:

And an important consequence that follows from all this: access to the state is as sensitive as access to production. Whoever can read the state bucket can read the passwords Terraform manages. That is why section 13 insists that Terraform must not manage secret values.

The .gitignore is not negotiable:

With one deliberate exception: .terraform.lock.hcl DOES go into Git. That file pins the exact provider versions and their checksums, and versioning it guarantees that the whole team and the pipeline use exactly the same thing. It is the equivalent of a package-lock.json.

The backend defines where the state lives. For GCP, Cloud Storage.

First the bucket is created, and this is the only thing done by hand in the whole process — the chicken-and-egg problem:

And it is declared in the code:

The prefix matters more than it seems: it separates states. prod/red, prod/datos, dev/red are independent states, and that separation limits the blast radius: a mistake while operating the network cannot affect the database's state.

Locking works on its own, with no configuration. Terraform creates a .tflock object while it operates; if somebody else launches apply at the same time, they get a clear error instead of corrupting the state:

If a process dies leaving the lock in place — a cancelled build, for instance — it is released with terraform force-unlock ID. It is a command to use carefully: only when you are sure there is no operation in progress.

The -out=plan.tfplan detail deserves emphasis because it is the difference between reviewing and trusting. Without it, terraform apply recalculates the plan at that moment; if something changed in between, it applies something different from what was reviewed. With the file, it applies exactly what was approved. In a pipeline it is mandatory.

And terraform destroy destroys everything in the state. Its legitimate use is an ephemeral test environment. In production it is the tool's most dangerous command, and section 14 explains how to protect yourself.

Knowing how to read a plan is the most important skill in this lesson. A badly reviewed apply is an incident.

The four symbols:

And the summary line at the end:

The golden rule is the -/+ one. A replacement happens when an attribute changes that the GCP API does not allow to be modified in place. Terraform, with no other option, destroys and creates. And on some resources that is catastrophic:

That plan would destroy AlpinaShop's orders database with all its data. Terraform says so clearly — # forces replacement — but an automatic or distracted apply executes it without hesitation.

What to do about an unexpected -/+, in this order: read which attribute is forcing it — Terraform marks it with # forces replacement; decide whether that change is really necessary; if it is, look for a way without destroying — create the new resource, migrate and delete the old one; and if it is not, fix the code. Never apply without having understood the cause.

Another case that causes confusion: plans that never come out empty even when you change nothing. They are usually down to an attribute that GCP normalises — a list it reorders, a default value it fills in — and they are solved either by writing the real value into the code or, when the provider behaves incorrectly, with lifecycle { ignore_changes = [...] }. That second option is a patch and is best used sparingly: each ignore_changes is a part of the infrastructure Terraform stops watching.

Now the real code, explained line by line.

Notice two things about this code that are the whole point of the exercise. First, the comments explain the why, not the what: that 35.191.0.0/16 are Google's probes, that private_ip_google_access breaks half of module 3 if it is missing. That knowledge lived in Marta's head and now lives in the repository. And second, the entorno, equipo, centro-coste and aplicacion labels are the ones from the whole course: being code, they stop being applied "when somebody remembers" and get applied every time.

The goal is for alpinashop-dev and alpinashop-prod to share the same code with different values, solving the configuration drift from 06-05.

Folders per environment versus workspaces, which is the structural decision that has to be taken:

AlpinaShop chooses folders per environment, and the main reason is operational safety: with workspaces, the only difference between applying in development and applying in production is having run terraform workspace select prod beforehand, and it is far too easy to forget. With folders, each one has its own backend and its own provider, and applying in production requires physically being in the production directory. It is a small barrier that avoids the most expensive mistake.

The resulting structure of the alpinashop-infra repository:

A module is a directory of Terraform code invoked with parameters. It is the reuse mechanism.

And how it is used from each environment:

The three rules of a good module:

1. One clear responsibility. red-alpinashop does the network. A module that creates the network, the database and the load balancer is a monolith by another name.
2. Parameterise what varies, fix what does not. private_ip_google_access = true is fixed on purpose: it is not a decision each environment should take, it is an AlpinaShop rule.
3. Expose the outputs others need. A module whose outputs are not enough forces people to break its encapsulation.

And a warning about over-abstraction, which is the most common mistake when people discover modules: a module with twenty variables to cover every imaginable case is harder to use than writing the resource directly. Start with flat code, extract a module when you repeat it for the second time, and not before.

The Terraform Registry hosts thousands of public modules, and Google maintains a collection of GCP modules of notable quality.

The criteria for deciding whether to use a public module or write your own:

The rule I use: the more complex the resource, the more a public module pays off. A module for creating a VPC with two subnets saves little and adds an external dependency; a module for setting up a Shared VPC with hierarchical rules, or a hardened GKE cluster with all its best practices, saves weeks of work and of mistakes.

And two serious warnings. Always pin the version with version = "~> X.Y": without it, a terraform init in the pipeline can pull a new version of the module that changes production resources without anybody having decided so. And a public module is third-party code with permissions over your infrastructure: for modules from unknown organizations, read it first, or fork it into your own repository. It is exactly the same software supply chain reasoning as in 06-01.

This is the moment to apply the procedure from 06-05 with the real tool. Everything Marta created by hand in modules 2 and 3 has to become managed without destroying or recreating anything.

The modern way, with declarative import blocks:

And the trick that saves most of the manual work:

Terraform writes into generado.tf the configuration of the resources declared in the import blocks, read from reality. Then it has to be cleaned — remove computed fields, replace literals with references, add comments — exactly as explained in 06-05.

The complete procedure, with the cycle that has to be respected:

Tips so the migration does not get stuck:

• Three at a time, not fifty at a time. A plan with fifty imported resources runs to hundreds of lines and the important differences get lost. Import a small group, verify the empty plan, move on.
• Start with the harmless. Firewall rules and empty buckets first; Cloud SQL last.
• Everything in alpinashop-dev first. A mistake there costs nothing.
• prevent_destroy before the first apply on any resource containing data.
• A -/+ always stops you. The rule from section 6, applied with even more reason during an import.

The identifier format varies by resource and is documented at the end of each one's page in the google provider. It is the most tedious detail, and there is no shortcut.

Here the whole module converges: the repository from 06-02, the pipeline from 06-01 and the infrastructure as code from 06-05.

The flow AlpinaShop puts in place:

The plan pipeline, which runs on every pull request:

The step that posts the plan as a pull request comment is the one that changes the team's culture. Without it, reviewing an infrastructure change forces you to read HCL and imagine the effect. With it, the reviewer sees exactly which resources are created, modified and destroyed, without running anything. It is the literal application of the principle from 06-05: review infrastructure the way you review code.

The apply pipeline, with manual approval:

Notice that it applies the plan file generated in the PR, not a recalculated one. That is what guarantees that exactly what was approved gets executed. And the -auto-approve is not dangerous here precisely because of that: the human approval already happened, in the --require-approval trigger from 06-01.

And with no key at all. The pipeline's service account authenticates with Cloud Build's identity; if the apply ran in GitHub Actions, it would be with the Workload Identity Federation from 06-02. At no point in this flow does a JSON credentials file exist.

The permissions of the apply service account deserve a note: it is the most powerful account in the whole infrastructure, because it can modify networks, IAM and databases. It should be scoped to the resources it manages, not be Editor on the project, and its use should be audited. It is the same warning as in 06-01 raised a level.

Knowing what to leave out is as important as knowing what to manage. The rule, already stated in 06-05: Terraform manages the shape, not the contents.

The first row is the most important and the most often breached. Look at the difference:

And an intermediate case worth resolving properly: a randomly generated password. random_password also ends up in the state, so the right solution is for the provider to generate it — Cloud SQL can do that — or an external process, with Terraform only creating the container.

The question that settles the doubts: does this change on its own, or does it change because somebody decides it? What changes on its own — data, autoscaled instances, pipeline tables — is not Terraform's. What changes because somebody decides it, is.

terraform destroy destroys everything in the state. It is a legitimate operation for ephemeral environments and a catastrophe in production, and there are three ways of running it by accident: typing it in the wrong directory, an apply with an unreviewed -/+, and deleting resources from the code without realising that deleting them means destroying them.

The first-line protection, prevent_destroy, on anything containing data:

With prevent_destroy = true, a plan that tries to destroy the resource does not run:

It is an error from the tool, not a warning. To really destroy it you have to edit the code, remove the protection and apply again: two deliberate steps instead of one accidental one.

AlpinaShop's five layers of protection, defence in depth:

And a clarification about the reach of prevent_destroy: it protects the resource, not the state. If somebody deletes the block from the code, Terraform does not see it and protects nothing. The real protection comes from layers 3, 4 and 5 together.

Running Terraform yourself means managing the state bucket, the locking, the versions and the pipeline's permissions. Infrastructure Manager is Google's managed service that does all of that by running Terraform underneath:

For AlpinaShop, which already has the pipeline from 06-01 working and wants full control over the flow, its own Terraform is the choice. Infrastructure Manager is excellent for teams that prefer not to manage state and live exclusively on GCP.

The alternatives to Terraform itself, to have the complete map:

Recommendation for AlpinaShop: Terraform, for the reason the lesson opens with — the ecosystem and the people who already know it. And an observation about Pulumi worth making: writing infrastructure in a general-purpose language is tempting and carries a real risk, because it is easy to write infrastructure that is too clever. HCL's limitation is partly a virtue: it forces the infrastructure to be readable by somebody who did not write the code.

It is worth looking at the before and after, because the journey has been a long one:

That change in the last row is the module's cultural summary. The knowledge has left people's heads and entered the repository.

Pushing the .tfstate to Git. It contains plain-text secrets and Git does not forget. A remote backend in Cloud Storage with versioning, and .gitignore from the first commit.

Not pinning the provider or module versions. An init in the pipeline can pull a new version that changes production resources without anybody having decided so. version = "~> 6.0" always.

Running apply without a plan file. It recalculates the plan and can apply something different from what was reviewed. plan -out=file and apply file.

Ignoring a -/+. It is the most expensive mistake in the tool. A replacement on Cloud SQL or on a bucket with contents destroys data. Stop and work out which attribute is forcing it.

Managing secrets with Terraform. The value ends up in plain text in the state. Terraform creates the container in Secret Manager; the value is set outside.

Deleting resources from the code thinking they "stop being managed". Deleting them from the code means destroying them. To stop managing without destroying: terraform state rm.

Using workspaces to separate production from development. The only barrier is remembering workspace select, and one day somebody will not remember. Folders per environment.

Creating modules too early. A module with twenty variables to cover every case is worse than flat code. Extract a module the second time you repeat something.

Importing fifty resources at once. The resulting plan is unreadable and the dangerous differences get lost. Three at a time, verifying the empty plan.

Forgetting prevent_destroy on resources with data. It is two lines and it can save the database.

Carrying on touching things by hand. Infrastructure as code's original sin. As soon as the code and reality diverge, the tool stops being trustworthy and you are back where you started.

A final tip: start with the new stuff. If migrating everything that exists looks unmanageable, adopt the rule that from today, everything new is created with Terraform, and import the old as you touch it. In a few months most of it will be managed without ever having run a migration project.

Write a bucket-alpinashop module that creates a Cloud Storage bucket with AlpinaShop's conventions: uniform access, public access prevention, configurable versioning, the four mandatory labels (entorno, equipo, centro-coste, aplicacion), a parameterisable lifecycle rule and prevent_destroy for production. Write its variables with validation, its outputs, and the block that invokes it to create alpinashop-datalake in production. Explain what you decided to parameterise and what you decided to fix, and why.

A pull request on alpinashop-infra produces this plan:

Analyse each change, classify it by risk, say whether you would approve the PR and what you would ask the author for. Indicate which is the most dangerous and why.

Marta asks you to design AlpinaShop's infrastructure workflow end to end, assuming the migration from 06-05 is already complete. Define: the repository structure, the backend configuration and the separation of states, the Cloud Build pipelines needed, the IAM permissions of each service account involved, the branch protections and CODEOWNERS, and the emergency procedure for when something has to be changed in production at 3 in the morning with the pipeline down. Justify the security decisions.

Solution 1

What I parameterised and why:

The design principle: you parameterise what legitimately varies between cases; you fix what is an organization decision. Turning public_access_prevention into a variable would open the door to somebody, in a hurry, creating a public bucket "just for a test". If at some point a genuinely public bucket were needed — a static site — it is declared with google_storage_bucket directly and that exceptional case gets a specific review. A module also serves to make difficult what should not be done.

On prevent_destroy, a debatable decision worth reasoning through. I have fixed it to true always, rather than parameterising it per environment. The reason is that prevent_destroy does not accept expressions: the lifecycle block cannot use variables, so prevent_destroy = var.entorno == "prod" gives a syntax error. It is a real limitation of Terraform. The options are fixing it to true for everything — which forces a manual step to delete a test bucket, annoying but safe — or creating two modules. I have chosen the former: the annoyance of deleting a development bucket by hand is far smaller than the risk of destroying a production one.

And a warning about dynamic: dynamic blocks are powerful and they make the code harder to read. With three conditional lifecycle rules, the module is starting to approach the limit of what is reasonable. If they grew to eight, it would be better to expose a list-of-rules variable and let whoever uses it declare them explicitly.

Solution 2

Change-by-change analysis:

Change 1 — destroying the SSH rule. It is the only change that could be an improvement: if that rule allowed SSH from broad ranges, removing it is exactly what 03-01 recommends. But a - destroy in a plan always calls for asking why it is disappearing. There are two possible causes with opposite implications: that the author deliberately deleted it from the code, or that they deleted it by accident while editing the file. What to ask for: that the pull request description explain it, and confirmation that nobody depends on that access — a supplier, a backup process, a support access route. If nobody knows, the safe alternative is to restrict the source rather than remove the rule, and observe for a week with the firewall logs from 06-06 before retiring it.

Change 2 — the subnet replacement. This is the one that gets the PR rejected.

Widening 10.20.0.0/24 to 10.20.0.0/22 is an apparently reasonable operation — more available addresses — and the GCP API does not allow a subnet's range to be changed in place when there are resources inside it. Terraform, with no other option, proposes destroying it and creating it.

What would happen on applying: destroying sn-datos-euw1 affects everything that lives in it, starting with the alpinashop-pedidos Cloud SQL instance and its private IP. In the best case, the operation fails halfway because GCP refuses to delete a subnet with resources in it, and the state is left inconsistent — Terraform believes it has started an operation it cannot finish. In the worst case, if something had been deletable, the private IPs would change and everything that references them would stop working. In neither case is the result acceptable.

And there is an alternative that makes the replacement completely unnecessary, and it is what should be proposed to the author: GCP allows an existing subnet's range to be widened without recreating it, using gcloud compute networks subnets expand-ip-range. The operation is non-destructive and only allows widening, never narrowing:

Afterwards ip_cidr_range is updated in the code and terraform plan comes out empty, because reality already matches. It is a case where the right operation is done outside Terraform and the code simply reflects it, and it is worth acknowledging: forcing the tool to do something the API does not support well is worse than making a documented exception.

Change 3 — reducing Cloud SQL's tier. It does not destroy data and that is why a lot of people would wave it through. But going from db-custom-4-15360 to db-custom-2-7680 halves the CPU and memory of the production database, and it has two immediate consequences: an instance restart, that is to say, a few minutes of service interruption, and appreciably lower capacity for the same traffic.

The questions for the author: is it intentional or is it the wrong tfvars? And if it is intentional, is it justified with data? This is where 06-04 comes into play: if Cloud SQL's CPU has been under 20 % for months, it is a perfectly reasonable saving. If it is at 60 %, halving the capacity is provoking the next incident. A sizing change without the metric to back it up is guesswork. And in any case, it must be applied in a maintenance window, not on a Tuesday at eleven in the morning.

A reasonable suspicion, incidentally: that this change comes from having applied dev.tfvars to production by mistake, because db-custom-2-7680 looks very much like the development value. It is worth checking.

Change 4 — creating the bucket. The only harmless one. You check that it has uniform access, public access prevention, the four labels and its lifecycle, and that is that.

Would I approve the PR? No. And what I would ask for, in this order:

1. Split the pull request into three. This PR mixes a security improvement, a network change, a sizing change and a new resource. They are four different intentions, with different risks and different moments to apply. A PR with a single intention gets reviewed well, approved quickly and reverted cleanly if it goes wrong.
2. Take the subnet widening out of Terraform, do it with expand-ip-range and update the code afterwards.
3. Justify the tier change with the CPU metric for the last two months, and schedule it in a maintenance window.
4. Explain in the description why the SSH rule is disappearing and confirm that nobody depends on it.

The most dangerous is change 2, no argument, and for a reason worth spelling out: it is the only irreversible one. Change 3 is undone by going back to the previous tier; change 1 is undone by recreating the rule; change 4 is undone by deleting the bucket. A destroyed resource does not come back, and it takes with it the private IP addresses of everything it contained.

And the procedural lesson: this plan is exactly the argument in favour of posting the plan as a pull request comment. Reading only the modified HCL, the change from /24 to /22 looks like a minor one-character edit. It is the plan that reveals that this character destroys the database's subnet.

Solution 3

Structure of the alpinashop-infra repository:

Backend and separation of states. The alpinashop-terraform-estado bucket in alpinashop-cicd, with versioning, uniform access and public access prevention. And states separated by environment and by domain:

The separation of states is a security decision, not an organisational one. With a single state, any operation on any resource locks everything and a mistake has total reach. With separate states, touching a Cloud Monitoring dashboard cannot affect the database even in the worst case.

Pipelines:

Development being applied automatically is deliberate: it is how you guarantee that alpinashop-dev always reflects main, which is exactly what prevents the drift from 06-05. Production requires approval because of the impact.

IAM permissions:

The most important security decision: sa-tf-plan is read-only. The plan runs on every pull request, and anyone can open a pull request — including somebody with bad intentions who modifies cloudbuild-plan.yaml in their branch. If that account had write permissions, opening a PR would be enough to modify production. It is exactly the anti-pattern explained in 06-01, and here it is even more serious because we are talking about infrastructure.

The second: people have no direct write access in production. sa-tf-apply-prod is impersonated with serviceAccountTokenCreator, which is recorded in the audit logs with the person's name. It is the literal application of 03-04 and of "nobody is owner of prod".

Branch protection and CODEOWNERS:

On main: direct pushes forbidden, a minimum of one approval (two for entornos/prod/), CI green mandatory, approvals that expire when new changes arrive, linear history, no exceptions for administrators and secret scanning.

The emergency procedure, which is the part of the exercise most people get wrong.

The naive answer is "give Marta permanent emergency permissions". It is a bad one: a permanent permission ends up being used outside emergencies and erodes everything else. The right answer has four elements:

1. Emergency access with logged impersonation. Marta belongs to a gcp-emergencia@ group that can impersonate sa-tf-apply-prod without going through the pipeline. It is not a hidden permission: it is a documented, audited, named route.

2. The plan is not skipped even in an emergency. It is the first thing people propose dropping in a hurry, and it is exactly the other way round: at 3 in the morning, sleepy and under pressure, is precisely when you most need to see what is going to be destroyed. It costs twenty seconds and it stops one incident becoming two.

3. An automatic alert when the emergency access is used. With the Pub/Sub sink from 06-06, any impersonation of sa-tf-apply-prod outside the pipeline publishes a message that reaches the security channel at the time. Not to prevent it, but so that everybody knows it happened.

4. Mandatory regularisation within 24 hours. The emergency change was made with main's code, so the state and the code match only if the change was made by editing the code. If it was done with gcloud by hand, there is drift. In either case, within the following 24 hours a pull request has to be opened documenting the change and proving with an empty plan that code and reality match again. Without that step, the first emergency is the beginning of the return to chaos, because from then on nobody trusts that the code is the truth.

And the reflection that closes the exercise. A well-designed emergency procedure does not remove the protections: it replaces them with traceability. In normal conditions, the protection is preventive — review, approval, scoped permissions. In an emergency, the protection is detective — immediate alert, audit record, mandatory regularisation. What must never exist is a route with neither of the two, because that route becomes the usual one.

AlpinaShop has its infrastructure written, versioned, reviewable and reproducible. The question that opened 06-05 — how long it takes to rebuild the environment — now has an answer: about twenty minutes and a terraform apply.

You know why Terraform won: multi-provider, a module ecosystem, maturity, community, and the definitive acknowledgement that Infrastructure Manager is Terraform managed by Google. With the honest note about the licence and OpenTofu.

You have mastered the concepts: provider with its version pinned because not doing so is letting an update decide for you; resource with its local name distinct from the real name; data source that only reads; variable with validation; output with sensitive, knowing that it hides but does not encrypt; and implicit dependencies arising from the references, with depends_on as the last resort.

You genuinely understand state: what it contains — including plain-text passwords — why it never goes into Git, and the four rules that follow from that. You know how to set up the backend in Cloud Storage with versioning, automatic locking and prefixes that separate states to limit the blast radius. And you know that .terraform.lock.hcl does go into Git.

You handle the init → validate → plan → apply flow, with the -out=file that guarantees exactly what was reviewed gets applied. And above all you know how to read a plan: +, ~, - and the -/+ that must always stop you, with the table of which resources a replacement is acceptable on and which ones it means losing data on.

You have AlpinaShop's real code in HCL — the VPC, the subnets with private_ip_google_access, the firewall rules with Google's probe ranges explained in a comment, the bucket with its lifecycle and its four labels — and with it the knowledge that lived in Marta's head has moved to the repository. You know how to parameterise with variables and tfvars so that alpinashop-dev and alpinashop-prod share code, and why AlpinaShop chooses folders per environment over workspaces: because a workspace's only barrier is remembering to select it.

You know how to write a module with its three rules — one responsibility, parameterise what varies and fix what is policy, expose the necessary outputs — and when to consume public registry modules, with the rule that the more complex the resource the more it pays off, and the two warnings: pin the version, and a third-party module is code with permissions over your infrastructure.

You know how to import what already exists with declarative import blocks and -generate-config-out, three at a time, verifying the empty plan, starting with the harmless and leaving Cloud SQL until last. You have Terraform in the pipeline: an automatic plan on every pull request posted as a comment — which changes the team's culture, because the reviewer sees the effect without running anything — apply only after approval and applying the already reviewed plan, and without a single JSON key in the whole flow.

You know what Terraform should not manage — secret values, data, ephemeral objects — with the rule that sums it up: manage the shape, not the contents, and the question that settles the doubts: does this change on its own, or because somebody decides it? And you have the five layers of protection against accidental deletion, with prevent_destroy and deletion_protection as the first two and human review as the one that really matters.

Finally, you know Infrastructure Manager as a managed way of running it and the map of alternatives — Pulumi, Config Connector, Crossplane, CDKTF — with the observation that HCL's limitation is partly a virtue, because it forces the infrastructure to be readable.

And here module 6 ends. Look at what has changed.

At the start, AlpinaShop had an application deployed from a laptop with the latest tag, some manifests in Drive, a function outstanding since module 5, no way of knowing whether the shop was working other than waiting for a customer's email, and infrastructure that existed only in a terminal's history.

Now there is automated delivery: the code on GitHub with mandatory review, Cloud Build building, testing and publishing images tagged with the commit, promotion to production with approval, and the ML pipeline finally at maturity level 2. There are event-driven pieces that react on their own, with idempotency, retries and dead letter. There is complete observability: metrics, dashboards, alerts that warn within five minutes, checks from four continents, structured logs, distributed traces and a proven journey that goes from the alert to the line of code in seventeen minutes. And there is infrastructure as code: versioned, reviewed in pull requests and reproducible.

The system no longer depends on two people remembering to run things.

What remains are the decisions that kept being postponed, and now there is a basis for taking them. The catalogue is still on GKE, even though DA-001 decided long ago that its place is Cloud Run — and now that there is a pipeline, observability and infrastructure as code, that move is finally viable. There is a physical warehouse with its own systems that somebody will have to integrate. Networking stopped at the basics and there are outstanding conversations about Shared VPC and hybrid connectivity. Security was built piece by piece and has never been reviewed as a whole. The bill has grown with every module and nobody has looked at it closely. Alerts have been set up, but what "working well" means has not been defined: there are no SLOs and no error budgets. And the organization already has three projects, four repositories, dozens of service accounts and no policy governing the whole.

In module 7, advanced topics, they all get resolved: Anthos for hybrid and multicloud, Cloud Run to take the catalogue where it always belonged, advanced networking with Shared VPC, peering and hybrid connectivity, security reviewed from top to bottom, cost management so the bill stops being a monthly surprise, reliability with SLOs and error budgets that turn the alerts from 06-04 into measurable objectives, and governance at scale with organization policies and auditing.

AlpinaShop now builds, deploys and observes itself. Now it is time to make it robust, economical and governable.