You have the problem chosen, the scope bounded, the cost limit set and the repository created. What you do not have yet is a single resource in Google Cloud, and that is deliberate.

This is the lesson people skip most often and the one that is most expensive to skip. Designing before typing is not an academic ritual: it is the rational response to an uncomfortable technical fact about the cloud. There are decisions you take in thirty seconds and pay for over years.

The projectId cannot be changed. Ever. If you create mi-proyecto-test-2 because you were in a hurry, that identifier will appear in every command, in every console URL, in every log, in every line of the bill and in the screenshot you show in an interview. Changing it means recreating everything inside it.

A subnet's CIDR range cannot be shrunk. A bucket's region cannot be changed. Migrating from Firestore to Cloud SQL — or the other way round — means rewriting the entire data layer. The schema of a partitioned BigQuery table lets you add columns but not change the partition key without recreating it.

None of those decisions is hard. All of them are irreversible. And that is why they are taken with a sheet of paper in front of you, not with the console open.

By the end of this lesson you will have the complete blueprint of your system: which logical components exist, which GCP service implements each one and why that one and not the alternative, what everything is called, who can talk to whom, who has permission to do what, where each piece of data lives and for how long, how much it will cost next month, what you are going to measure to know it works, and the important decisions written down in a format that will still make sense six months from now.

1. Why you design before typing, and what "enough design" is
2. From requirements to logical components
3. From logical components to GCP services
4. The three diagrams that are worth having
5. Designing the organizational structure
6. Naming and labelling conventions
7. Network design
8. Identity design
9. Data model and data lifecycle
10. Up-front cost estimate
11. Defining the project's SLOs
12. Architecture decision records (ADRs)
13. Reviewing the design before implementing
14. The complete design of RefugioReserva

The reason to design is not "doing things properly". It is that the cost of changing a decision grows brutally with the moment at which you change it:

The rows at the top are the ones that justify designing. The one at the bottom is the one that justifies not over-designing: adding a field costs the same before as after, so do not lose an hour deciding whether the notas field should exist.

Design has very rapidly diminishing returns. For a 50-hour project:

The nine artefacts of "enough design", and none of them takes more than a page:

The rule that decides whether a design is finished: when you can answer, without hesitating and without opening the console, these five questions:

1. How much will it cost per month, and why?
2. What happens if the most important component goes down?
3. Who can read the users' data?
4. Which service did you choose and which did you reject, and why?
5. How will you know it is working properly without anybody telling you?

If you hesitate on any of them, that is where the design is missing.

Before naming a single Google service, describe your system in logical components: functional pieces, provider-agnostic. This step looks bureaucratic and it is the one that avoids the most common beginner mistake, which is designing the architecture as a list of products you fancy using.

Six families of components cover practically any project in this module:

How you fill this in for your project. Take your functional requirements from 08-01 and write, for each component, what it does in your domain:

If any box comes out forced — "well, I would put Pub/Sub here because something has to go in" — that is a sign that the problem you chose does not exercise that layer naturally. Two legitimate ways out: change the problem slightly so that it needs it, or implement the simplest possible version of the component and document in an ADR that it is deliberately minimal. What is not acceptable is dropping in a complex service for no reason: that scores negatively in block A of the rubric, not positively.

Now for the translation. For each component, one row with four mandatory columns: service chosen, why, what you rejected and why you rejected it.

That fourth column is 50 % of block A of the rubric. An interviewer does not ask you "did you use Cloud Run?"; they ask you "why Cloud Run and not App Engine?". If you did not write it down the day you decided, you will not remember it.

For 90 % of the projects in this module, the answer is Cloud Run. And the main reason is not technical but economic: it scales to zero. A portfolio project gets zero traffic 99 % of the time, and anything that does not scale to zero eats the budget from 08-01 without giving anything back.

The real dilemma in this module is Cloud SQL versus Firestore, and it has an economic dimension that needs putting on the table:

If your cost limit is €0, the decision is made: Firestore. If you have €10-15 and your domain has genuine referential integrity (like a booking that cannot exceed capacity), Cloud SQL makes it far easier and the decision justifies itself.

The economic warning: Dataflow in streaming mode keeps workers running 24 hours a day. For a portfolio project that can be €60-100 a month for a flow that processes twelve messages. Pub/Sub + a function does exactly the same thing for €0 at this volume, and demonstrates just as well that you understand the pattern. Save Dataflow for when the transformation genuinely justifies it, and document the reason.

One row per component. Ten to thirteen rows. It is the most quoted document in your final presentation.

A diagram is not decoration: it is a tool for answering a specific question. And the reason most architecture diagrams are useless is that they try to answer every question at once and end up as a tangle of forty boxes.

The rule: one diagram, one level of detail, one question.

Answers: what is this and who touches it? Your system is a single box. Around it, the actors and the external systems.

Ten boxes at most. If you have twenty actors, your scope is too big (go back to 08-01).

Answers: how does a request and a piece of data flow through the inside? Here the GCP services do appear, but grouped by function, not by product.

The five rules of a readable component diagram:

1. Fifteen boxes maximum. If you need more, make two diagrams.
2. Arrows follow the direction of the request, not of the data. If you get confused, add the label.
3. Group by responsibility (edge, application, data, analytics), not by product.
4. Label the arrows that are not obvious. RUN --> SQL needs no label; LB -.-> GCS does.
5. No unnecessary crossings. If two lines cross, reorder the boxes.

Answers: which project, which region, which network, what is public and what is not? It is the diagram a security reviewer looks at first.

This diagram must make obvious, at a glance, what is exposed to the internet. In the example: only the load balancer. The database has no public IP, Cloud Run does not accept direct traffic (only from the load balancer), and the data project is not reachable from outside.

It depends on your account:

Without an organization you lose organization policies and folders, but everything else works the same and the rubric does not require an organization. If you have your own domain (which you are going to need anyway for RNF-5), you can create a free Cloud Identity and have an organization; it is a bonus that adds points but is not mandatory.

A project is the unit of isolation, of billing and of IAM. Three reasonable options:

The recommendation is B, with a cheap variant: if your analytics are small, put BigQuery in the production project and save yourself the fourth project. What is always worth separating is dev from prod, because that is what makes the promotion pipeline of RNF-2 credible and because it lets you destroy dev on Fridays without fear.

A single region. For a project in Spain, europe-west1 (Belgium) or europe-southwest1 (Madrid).

Write the decision and its reason. It is a three-line ADR, and it is the kind of detail that shows you think about data residency and not just about making it work. And remember from 01-05: some services are global (IAM, Cloud DNS, the global load balancer, Artifact Registry in multi-region mode), so the region does not apply to everything.

Decided once, applied always, and decided now because the projectId cannot be changed.

The hard rules GCP imposes and that you need to know beforehand:

• projectId: 6-30 characters, lowercase letters, digits and hyphens; starts with a letter; unique across all of Google Cloud and never reusable, not even after deleting the project.
• Buckets: the name is globally unique. That is why they carry a random suffix: refugio-fotos will almost certainly be taken. Terraform solves it with random_id.
• Service accounts: the accountId (the part before the @) is 6-30 characters and also cannot be changed.
• No underscores in DNS-compatible names (buckets, Cloud Run services). They are fine in BigQuery datasets and tables, which use _.
• No names containing test, tmp, 2, nuevo, final. All of that ends up in production and stays there.

Labels are key-value pairs that appear in the billing export. They are what lets you answer "how much does the data component cost me?" without guessing. They cost nothing and go in from the very first apply.

In Terraform they are applied in one go with a shared variable:

gestionado-por = terraform is the most useful of the five: any resource without that label, or created by hand, stands out in a billing query. It is your zero-cost configuration drift detector.

Even if you use Cloud Run — which is serverless — there are network decisions to take, because the private database, the egress connector and the load balancer live in a VPC.

Do not use the default network. It comes with subnets in every region in the world and permissive firewall rules you did not choose. Create a VPC in custom mode.

Reserve a space and divide it up. A private /16 is more than enough:

The two traps that catch everybody the first time:

1. The Serverless VPC Access connector needs its own non-overlapping /28. Not a /29, not a /27: a /28.
2. Cloud SQL with a private IP needs a range reserved for private services access and a peering with Google's network. It is an extra step that the documentation mentions in passing and that produces a cryptic error if it is missing. In Terraform it is two resources: google_compute_global_address with purpose = "VPC_PEERING" and google_service_networking_connection.

This is the most valuable artefact in the network design: a table of who can talk to whom. It is written before creating a single firewall rule, and afterwards it translates into rules almost mechanically.

The last row is the policy: anything not explicitly allowed is denied. It is the principle from 03-01 and it is the difference between a network that was designed and a network that "works".

Write the list of everything that will be reachable from the internet. It should fit in three lines:

If that list has more than five entries, review it: almost certainly something is exposed that does not need to be.

Same as with the network: you write the table before creating anything. And you apply the principle from 03-04 in its most practical form: one service account per workload, with the minimum roles, and no downloaded keys.

The five principles you must respect and that the rubric checks:

1. Never roles/editor or roles/owner on a service account. They are the primitive roles from 03-04 and they grant thousands of permissions.
2. The narrowest possible scope. secretAccessor on the secret, not on the project. In Terraform that is google_secret_manager_secret_iam_member, not google_project_iam_member.
3. One SA per workload. If the function and the app share an SA, they share permissions, and the blast radius of a failure doubles.
4. Zero JSON keys. Workloads inside GCP use the attached SA; external CI/CD uses WIF. If you have a .json, you have failed.
5. serviceAccountUser is the permission everybody forgets. For sa-deploy to be able to deploy a service that runs as sa-refugio-web, it needs to act as that account. It is the most frequent 403 of the first automated deployment.

And the one that gets discovered late: Compute Engine's default service account has the editor role. If you let your resources use it, your whole least-privilege design is decorative. Create explicit SAs for everything.

The table that avoids the most expensive mistake in these projects, which is putting everything into the operational database:

Write it as DDL, even if it is a draft. It is what forces you to think about keys, constraints and types:

Three details that deserve attention and that score in the rubric:

• The CHECK on plazas is a business rule expressed in the database. It is free and it prevents impossible data even if the application has a bug.
• The partial index (WHERE estado = 'confirmada') is smaller and faster than a full one, because cancelled bookings do not take part in the availability calculation.
• The capacity check is not in the schema. It cannot be: it depends on the sum of bookings for a given date. It goes in a transaction with a lock in the application, and it is precisely what the mandatory integration test will test.

In BigQuery the criteria are different: you denormalise, you partition by date and you cluster by whatever you filter on most. The reason is economic: BigQuery charges by bytes read, and an unpartitioned table is read in full every time.

require_partition_filter = TRUE is the option that saves your bill. With it, a query without a WHERE DATE(ocurrido_en) ... fails instead of scanning the whole table. It is the equivalent of a seatbelt and in a project with a cost limit it is not optional.

Notice too what is not there: contact details do not travel to the analytical store. Nobody needs the booker's email to calculate occupancy, and every piece of personal data you do not replicate is a GDPR problem you do not have.

Every piece of data is born, lives and must die. The last part is the one that never gets designed.

⚠️ GDPR warning, and this is not a formality. As soon as your system stores a name, an email, a phone number or a position associated with an identifiable person, you are processing personal data, even if it is made up and even if it is a learning project.

For this project: use fictional data exclusively (generated names, @example.com emails, phone numbers from the range reserved for fiction). With that, formally there is no processing of personal data and no obligation.

But design as if there were, because the habit is what is being assessed and what transfers to a real job: minimisation (do not store what you do not use), purpose limitation (do not replicate contact details to the analytical store), a defined retention period with real, automatic deletion, encryption at rest, restricted access and traceability of who accesses what.

And if this design were ever going to process real people's data, a full GDPR and compliance review would be needed — legal basis, record of processing activities, impact assessment where applicable, data processing agreement with Google — which is entirely outside the scope of this course.

It is done now, with the design in hand and before building. If it does not fit within the limit from 08-01, what changes is the design, not the limit.

1. List the services from your translation table.
2. For each one, estimate the driver that determines the price: hours running, GB stored, GB processed, number of requests, GB of egress to the internet.
3. Check whether the free tier covers it. Surprisingly often, it does.
4. Use the official calculator for whatever it does not cover.
5. Add it up and add 25 % of headroom for what you have not foreseen.

The four money sinks of a portfolio project, in order of frequency:

1. Cloud SQL running 24/7. It is almost always the biggest line item.
2. The global load balancer. The forwarding rule costs per hour whether or not there is traffic. It can be €15-20/month. If your limit is very tight, consider serving Cloud Run with its own custom domain (which gives free TLS) and documenting in an ADR that you give up CDN and Cloud Armor on cost grounds.
3. Standard GKE. A three-node cluster is around €100/month. Do not use it.
4. Streaming Dataflow. Workers running permanently.

In this order, from the cheapest change to the most painful:

And one decision that has to be taken consciously: if your limit is €0, the correct architecture is Firestore + Cloud Run + BigQuery + Cloud Functions + a Cloud Run custom domain, with no load balancer and no Cloud SQL. It is a perfectly defensible design, as long as why is written down. A project that says "I chose Firestore because my cost constraint was €0 and Cloud SQL costs €8/month running" demonstrates more judgement than one that spent €60 without thinking about it.

From 07-06, in its minimum viable version. One or two SLOs are enough. The mistake is defining six and measuring none.

Step 1 — What is the critical user journey? Not "the site works". Something concrete: "a hiker checks availability and completes a booking".

Step 2 — Which SLI measures it? An SLI is a ratio of good events to valid events:

Step 3 — Set the target. Be realistic: the target must be achievable with your architecture and higher than what a user notices. 99.9 % monthly is a good starting point; 99.99 % in a portfolio project with a single region is a lie, because the region itself does not guarantee it.

Step 4 — Calculate the error budget. It is what makes the SLO useful:

And the error budget policy, written now, which is what turns the SLO into a tool rather than a decorative number:

In a one-person project this may sound excessive. It is not: it is one paragraph, and it is exactly the kind of artefact that in an interview shows you have understood what an SLO is for.

An ADR (Architecture Decision Record) is one page that records one important decision. It is the most valuable document you will write in this project, and here is why, without embellishment:

• Three months from now you will not remember why you chose Firestore. The code says what you did; the ADR says why.
• In an interview they are going to ask you exactly that. An ADR is a prepared answer.
• Writing the decision down forces you to actually have one. Half the time, when you reach the "alternatives" section you discover you had not considered any.
• It lets you revisit the decision honestly. If the context changes, you write a new ADR that supersedes the previous one. You do not rewrite the old one: you leave it as a historical record. That is how the evolution of your judgement becomes visible, which is what is being assessed.

The two sections people leave weak and that are the ones that count:

• "Negative": every architecture decision loses something. If your ADR has no drawbacks, you have not decided: you have justified what you already wanted to do. Writing "I accept that without a load balancer I lose Cloud Armor and edge caching" demonstrates judgement, not weakness.
• "What would change this decision": it turns the decision into something revisable and shows you know it is contextual. It is exactly what AlpinaShop did with DA-004 on Anthos.

Three is the rubric's minimum; five or six is normal. One per design session and you have them.

This is milestone M1 from 08-01. You either pass it or you do not; there is no "almost". Go through it yourself, in the cold light of day, ideally the day after finishing the design.

Architecture

• [ ] All six functional requirements have a service assigned
• [ ] All eight non-functional requirements have a mechanism assigned
• [ ] Every service has its justification and its rejected alternative written down
• [ ] The three diagrams exist and are consistent with each other
• [ ] No diagram has more than 15 boxes

Organization and names

• [ ] It is decided how many projects there are and exactly what they are called
• [ ] The projectIds comply with the rules (6-30, lowercase, no test/final/2)
• [ ] The region is decided and the reason is written down
• [ ] There is a naming convention for every resource type
• [ ] There is a labelling convention, including gestionado-por

Network

• [ ] There is an addressing plan with no overlaps
• [ ] The serverless connector has its /28
• [ ] Private Cloud SQL has its private services access range
• [ ] The flow matrix is written, with deny by default
• [ ] The public surface fits in five lines

Identity

• [ ] There is one service account per workload
• [ ] None of them has owner or editor
• [ ] Every role is at the narrowest possible scope
• [ ] WIF is planned for CI/CD, with no JSON keys
• [ ] serviceAccountUser is accounted for the deployer

Data

• [ ] It is clear which data lives where and why
• [ ] The operational schema is written as DDL
• [ ] The analytical table is partitioned, with require_partition_filter
• [ ] The lifecycle of every piece of data is defined, including its deletion
• [ ] No contact data is replicated to the analytical store
• [ ] It is noted that all the data is fictional

Cost

• [ ] There is an estimate table by service
• [ ] The total with 25 % headroom fits within the limit from 08-01
• [ ] If it did not fit, there is an ADR documenting the cut
• [ ] The budget with alerts is already created

Operations

• [ ] There is at least one SLI and one SLO with its window
• [ ] The error budget is calculated
• [ ] There is a written error budget policy
• [ ] It is planned what is going to be monitored

Documentation

• [ ] There are ≥3 ADRs with context, options, decision and consequences
• [ ] docs/arquitectura.md is written and contains the diagrams
• [ ] The diario.md has entries for every design session

If you have ticked every box and still cannot answer these five without looking, the design is not finished:

1. How much will it cost per month and what is the biggest line item?
2. If the database goes down, what stops working and what keeps working?
3. Who — which identity exactly — can read the users' data?
4. What did you reject in the most important decision, and why?
5. How will you find out something is wrong before somebody tells you?

As a consolidated reference, this is how the example project's design ends up. Read it as a model of format and level of detail, not as something to copy.

It does not fit. The load balancer eats more than everything else put together. This is not a design failure: it is exactly what estimating before building is for. And the answer goes into an ADR:

Revised cost: €9.55/month, within the limit. And, above all: a story to tell in the final presentation that is worth more than the load balancer.

Designing the architecture as a list of products you want to use. The symptom is a diagram with twelve GCP logos and no justification. The cure is the logical-components step: first what is needed, then what implements it.

Skipping the "rejected alternative" column. It is half of the 20 points in block A. And it is the literal question in an interview.

Creating the projects with provisional names. There are no provisional names in GCP: the projectId is forever and cannot be reused, not even after deleting it.

Using the default VPC. It brings subnets in every region and permissive rules you did not choose. Creating a custom VPC costs five lines of Terraform.

Forgetting the private services access range. Cloud SQL with a private IP needs a reserved block and a peering. If it is not in the design, it shows up as an incomprehensible error the day you create the database.

Not partitioning your BigQuery tables. It is the mistake you pay for in the bill, not in performance. And require_partition_filter = TRUE is your safety net.

Defining six SLOs. One well-measured SLO is worth more than six in a document. Start with availability.

Designing the lifecycle without the deletion. "It is kept forever" is not a retention policy: it is the absence of one. And as soon as there is real personal data, it is a breach.

Tip: write the ADR the day you take the decision, not at the end. Fifteen minutes then, or an invented reconstruction three weeks later.

Tip: draw the diagrams in mermaid inside the repository, not in an external tool. They get versioned with the code, they are updated in the same commit as the change and they render in GitHub. A diagram in a PNG exported from a web tool is out of date from day two.

Tip: do the cost estimate even if you are sure it fits. The RefugioReserva case — where the load balancer was eating three times the whole budget — is the norm, not the exception. That discovery is worth more than the design itself.

Tip: if you hesitate between two services for more than twenty minutes, choose the simpler one and write the ADR. A reversible decision taken quickly beats a perfect decision taken late. And the ADR already leaves the door open.

Produce, for your project: the list of logical components with what each one does in your domain; the complete translation table with the four mandatory columns (service, why, rejected alternative, why it is rejected); and the three mermaid diagrams — context, components and deployment — respecting the maximum of 15 boxes and the five readability rules.

Save it all in docs/arquitectura.md.

Without creating anything in GCP, produce: the addressing plan with its blocks (including the connector's /28 and the private services access range); the allowed flow matrix with the deny-by-default row; the public surface list; the identity table with one service account per workload and its roles at the narrowest scope; the DDL of the operational schema; the schema of the partitioned analytical table; and the lifecycle table for every piece of data with its deletion mechanism.

Add the explicit note that all the data is fictional and what you would do differently if it were not.

Fill in the cost estimate table using the official calculator and compare it against your limit. If it does not fit, apply the measures in order and write the ADR for the cut. Define one or two SLOs with their SLI, target, window and error budget, plus the error budget policy. Write at least three ADRs using the complete template, including the negative consequences section and the one on what would change the decision.

Finish with the complete checklist from section 13 and answer the five control questions in writing.

Solution 1 — RefugioReserva's architecture

Logical components filled in:

The translation table and the three diagrams are the ones in section 14 and in section 4. One detail of the deployment diagram is worth flagging: after ADR-006, the load balancer disappears from the permanent state and Cloud Run is exposed with its custom domain, so the definitive deployment diagram has one box fewer and the Client → Cloud Run arrow goes directly. The diagram is updated when the decision changes; a diagram that contradicts the ADR is worse than having no diagram.

Solution 2 — RefugioReserva's network, identity and data

Addressing (prod):

Dev uses 10.10.0.0/16 with the same structure. They do not overlap, on purpose: if one day I wanted to peer the two VPCs, I could; if they overlapped, I could not.

Flow matrix: the one in section 7, with two clarifications after ADR-006. Since there is no longer a load balancer, Cloud Run is configured with --ingress=all (required for the custom domain) and the protection moves to: authentication on the private routes, strict input validation, and --max-instances=5 as a cap on spend and on abuse. This loss is acknowledged in ADR-006 and will also appear in the 08-05 self-assessment as conscious technical debt.

Identities:

Four accounts, no primitive roles, no keys. sa-deploy is federated from GitHub with WIF restricted to the repository and to the main branch.

Data: the schemas from section 9. The lifecycle table includes one row worth highlighting:

That verification column is what turns the retention policy into something checkable. Without it, it is an intention.

Note on fictional data: the 2,000 records are generated with data/seed/generar.py by combining lists of invented names and @example.com emails (a domain reserved by RFC 2606 for precisely this). If the system processed real data, it would need: a legal basis for the processing, information for the data subject, a record of processing activities, a data processing agreement with Google Cloud, an impact assessment for processing the refuges' location data, and probably customer-managed encryption keys (CMEK) on Cloud SQL and on the buckets. None of that applies here because there is no real personal data, and that is exactly the reason there is none.

Solution 3 — RefugioReserva's cost, SLOs and ADRs

The estimate, the load balancer discovery and the complete ADR-006 are in section 14. The final table after the cut:

Still just over. Additional measure applied, from the cuts table: overnight shutdown of production Cloud SQL between 01:00 and 08:00 via a scheduled job, which reduces that line item by 29 % (~€2.30). Final estimated cost: €10.51 with headroom, within the limit. The consequence — the application does not work between 1 and 8 in the morning — is documented in the README and declared explicitly in the SLO: the measurement window excludes that period, because an SLO breached by a planned and known shutdown measures nothing useful.

RefugioReserva's five ADRs:

The five control questions, answered:

1. How much will it cost? €10.51 a month. The biggest line item is Cloud SQL (€5.70 after the overnight shutdown), followed by the domain.
2. What if the database goes down? Availability search and booking creation stop working — the entire critical journey. Still working: the static refuges page (cached), the bucket photos and the Looker Studio dashboard, which reads from BigQuery. The application must degrade with a clear message, not with a 500 error. This is a concrete reliability test for 08-04.
3. Who can read the users' data? My personal account (project owner), sa-refugio-web (through cloudsql.client + the credentials from the secret) and sa-job-nocturno. Nobody else. sa-procesar-evento and sa-deploy do not have access to Cloud SQL, and the analytical store contains no contact details.
4. What did I reject in the most important decision? In ADR-002, Firestore. It would have saved €8/month and all the private networking work, but capacity control under concurrency — the heart of the problem — would have been noticeably more fragile without row-locking transactions. I accepted the cost and offset it with the overnight shutdown.
5. How do I find out something is wrong? An email alert when the 5xx error rate exceeds 5 % for 5 minutes, an alert on SLO error budget consumption at 50 %, an uptime check every 5 minutes against /salud, and a billing budget alert at 50/90/100 % of €12.

You have the blueprint. And, more importantly, you have the decisions taken and written down before it cost money to undo them.

You know why you design before typing: not out of academic rigour, but because there are decisions — projectId, region, CIDR, database engine, partition key — that cost ten seconds now and a complete rebuild later. And you know what "enough design" is: nine artefacts, five to eight hours, none of them more than a page, and the proof that it is finished is the five control questions.

You know how to go from requirements to logical components before naming a single Google product, and from there to services using the course's decision trees — 02-07 for compute, 02-06 for data, 04-01 versus 04-04 for analytics — always documenting the four columns: what you choose, why, what you reject and why. That fourth column is half of block A of the rubric and the literal question in an interview.

You know how to draw the three diagrams that are worth having — context, components, deployment — each with one question and one level of detail, with the 15-box rule and the five readability rules, and in mermaid inside the repository so they age with the code and not in a forgotten PNG.

You have decided the organizational structure: how many projects and why two is the right balance, the region with its reason written down, the naming convention with GCP's hard rules (the unrepeatable projectId, the global bucket name) and the labels, with gestionado-por=terraform as a free drift detector.

You have the network designed on paper: the addressing plan with the connector's /28 and the private services access range everybody forgets, the flow matrix with deny by default, and the public surface in five lines.

You have the identity in a table written before creating anything: one service account per workload, no primitive roles, every permission at the narrowest scope, WIF without keys and serviceAccountUser accounted for so that the first automated deployment does not give you an inexplicable 403.

You have the data model with what lives where and why, the operational DDL with its constraints and its partial index, the partitioned analytical table with require_partition_filter as a seatbelt for the bill, and — what almost nobody designs — the complete lifecycle, including deletion, with its mechanism and its verification query, and with the GDPR warning that turns discipline into habit even when your data is invented.

You have the cost estimate done before spending a euro, with the four money sinks identified and the cuts table in order. And you have the RefugioReserva example, where the estimate revealed that the load balancer cost three times the entire budget: exactly the discovery that estimating beforehand is for.

You have your SLOs defined with their SLI, their realistic target, their window and their calculated error budget, plus the policy that turns that budget into decisions.

And you have your ADRs, with the complete template and with the two sections most people leave weak: the negative consequences — because every decision loses something, and acknowledging it is judgement — and what would change the decision, which is what keeps it alive.

In the next lesson, 08-03, you start building. And you will do it in a specific, justified order — organization, network, identity, Terraform state, data, application, delivery, analytics, AI, observability — with a phase 0 of preparation, eight phases each with its verifiable "done" criterion, the cross-cutting practices that stop the project deforming along the way, the five-step method for when you get stuck, and the most honest warning in the module: the first time, everything takes twice as long.

Save the design in the repository and commit. From here on, everything you create must correspond to something that is already in this document.