For seven modules you have followed Marta, Dani and Lucía. You have seen how AlpinaShop went from a rented server at a Spanish provider to a Google Cloud platform with continuous delivery, observability, SLOs, governance and a bill 60 % lower. You have seen the decisions and also the mistakes: the MIG that dragged on for five modules, the recommendations endpoint that had to be switched off, the service account key lost for fourteen months.

But you have watched other people decide.

This module is different. There is no AlpinaShop to follow here: there is a blank sheet, a set of constraints and a date. You are going to choose a problem, design a solution, build it, test it, deploy it, measure it, pay for it and defend it. End to end, on your own.

And there is a practical reason why this matters more than any earlier lesson: nobody is going to hire you for having read about Cloud Run. They are going to hire you because you can show a URL that works, a repository with the infrastructure written as code, a dashboard with real metrics and a €14-a-month bill you can explain line by line. That is a portfolio. The rest is lecture notes.

This first lesson is the project specification. It defines what you are being asked for, with which minimum requirements, under which cost limit, with which deliverables, with which rubric you will be assessed and within which deadline. Read it end to end before writing a line of code or creating a single GCP project. It is literally the lesson that stops you having, three weeks from now, half a system and no idea whether it is any good.

1. What exactly you are being asked for, and why it is framed this way
2. How to choose the problem: criteria for a portfolio project that works
3. Four worked proposals
4. Bringing your own problem (and the warning you cannot skip)
5. Mandatory minimum functional requirements
6. Mandatory non-functional requirements
7. The cost constraint: the requirement that will teach you the most
8. Deliverables and their format
9. The assessment rubric
10. Planning: effort per phase and schedule
11. Risk management: the five mistakes that sink a final project
12. How to work with the official documentation
13. What to do when something does not work
14. Your decision today

The brief, in one sentence:

Build on Google Cloud, end to end and with your own hands, a complete platform for a problem you choose, going through the same stages you have watched AlpinaShop go through, and leave it documented, measured, secure and reproducible from scratch.

It is not "make a demo". A demo is a container deployed on Cloud Run with gcloud run deploy and a screenshot. Anybody does that in twenty minutes and it proves nothing, because the real work is not in deploying: it is in everything around the deployment.

What does show judgement is this:

The project is designed to touch every layer of the course, not to go deep into one. That is deliberate: a project that only demonstrates BigQuery competes with thousands of projects that demonstrate BigQuery. A project that demonstrates you can connect compute, data, identity, network, delivery and observability — and explain why each piece is where it is — competes with very few.

How long it takes. Between 40 and 60 hours of real work if this is your first time. Spread over 4-6 weeks at the pace of the odd evening plus a weekend, it is perfectly feasible. If it comes out at 15 hours, you are making a demo. If it comes out at 150, the scope has got away from you, and there is a whole section on that further down.

What you are NOT being asked for. Worth saying early, because half the risk in this module is doing too much:

• You are not asked for a pretty application. An ugly but functional interface scores the same as a beautiful one.
• You are not asked for a machine learning model of your own. A pre-trained API satisfies the AI requirement.
• You are not asked for multi-region high availability. One region is more than enough.
• You are not asked for Kubernetes. Cloud Run is the recommended default.
• You are not asked for a large data volume. A thousand fictional rows demonstrate the same as ten million and cost nothing.
• You are not asked for it to be "finished" in the sense of a product. You are asked for it to be complete in the sense that every layer exists and they work together.

Choosing the problem is the decision with the most consequences in the whole module, and it is taken in the first hour. A bad problem turns the project into a six-month ordeal; a good one turns it into four enjoyable weekends.

Five criteria, in order of importance:

If you choose "algorithmic trading platform" and you do not know what an order book is, you are going to spend 70 % of the time learning finance instead of learning GCP. The domain must be so obvious to you that you could write the functional requirements from memory in twenty minutes.

Good domains: bookings, catalogues, inventories, incidents, fleet tracking, courses, appointments, membership management. Everybody understands how a booking works.

Bad domains: anything with complex regulation (real healthcare, banking, insurance), anything where the algorithm is the product (genuine recommendation engines, true route optimisation), anything that depends on an external integration you do not control.

Try describing your project in one sentence. If you need two "and"s, it is already too big.

• ✅ "A platform where users book places in mountain refuges."
• ⚠️ "A platform where users book places in refuges and wardens manage availability and there is a marketplace of guides."
• ❌ "An ERP for the integrated management of mountain refuges."

Scope is cut before you start, not halfway through. Cutting halfway through means throwing away work already done.

You are going to need data for the operational database, for the analytical warehouse and for the AI component. If your domain needs data you cannot invent credibly (labelled medical images, real banking transactions), change domain.

A good project can be seeded with a 60-line Python script that generates 2,000 coherent rows: dates that make sense, amounts in a reasonable range, a distribution with some seasonality so the dashboard does not come out flat.

The "application + storage + database + data + analytics + AI" requirement must come out of the problem, not be forced on top of it. If you have to invent an excuse to bring in Pub/Sub, the project is badly chosen.

Ask yourself: is there something that happens asynchronously? Are there files to upload? Is there something to analyse historically? If all three answers are yes, the project fits by itself.

You are going to spend 50 hours on this, many of them debugging IAM permissions at eleven at night. If the topic bores you on day one, the project never gets finished. This criterion looks soft and it is the one that kills the most projects.

Score every idea that occurs to you from 1 to 5 on each criterion. If any column scores below 3, discard it:

If you do not have a clear idea of your own, use one of these four. They are sized for the module, they have inventable data and they exercise every mandatory layer. All four are fictional.

The problem. A fictional mountaineering federation manages 12 refuges in the Pyrenees. Today bookings are made by phone and written down in one spreadsheet per refuge. There is overbooking, nobody knows the real occupancy until the weekend arrives, and there is no way of knowing which refuges perform best.

What you build.

• A public site where a hiker searches by refuge and date, sees free places and books.
• A private area where each refuge's warden checks the day's bookings.
• Upload of refuge photos to a bucket, with thumbnail generation.
• Every booking publishes an event that feeds the analytical warehouse.
• An occupancy dashboard by refuge, month and type of place.
• AI component: sentiment analysis of the reviews hikers leave (pre-trained API) or automatic tagging of the photos.

Fictional data. 12 refuges with name, coordinates and capacity; 2,000 bookings spread over 18 months with summer seasonality; 400 free-text reviews.

Difficulty: medium-low. It is this module's reference proposal and the one used in every exercise solution.

The interesting thing it teaches. Availability management has a real race condition (two people booking the last place), which gives rise to a genuine transaction and an integration test that means something.

The problem. A fictional chain of three veterinary clinics needs to manage animal records, appointments and clinical histories. Today they use a desktop program installed on one computer per clinic, with no remote access.

What you build.

• An authenticated site where staff register animals and owners, and schedule appointments.
• Upload of X-rays and photos of an injury's progress to a bucket with a storage class based on age.
• Appointment reminders: creating an appointment publishes a message that triggers a simulated send.
• A dashboard of diary occupancy, most frequent reasons for consultation and revenue per clinic.
• AI component: entity extraction from the free text of the clinical history (natural language API) to tag diagnoses, or classification of the uploaded images.

Fictional data. 3 clinics, 8 vets, 600 animals, 3,500 historical appointments, 1,200 free-text clinical notes.

Difficulty: medium.

⚠️ Important warning for this proposal. Although animal data is not personal data, their owners' data is. Work exclusively with invented names, phone numbers, emails and addresses. Do not copy any clinic's real database, not even an "anonymised" one: badly done anonymisation is re-identifiable and lands you in a GDPR problem that has nothing to do with learning GCP.

The problem. A fictional last-mile delivery company with 30 vans wants to know where its vehicles are, which deliveries they have made and how long each route takes.

What you build.

• Position ingestion: a simulator publishes each van's position to a topic every 30 seconds.
• A web service with a map showing the fleet's current state and the detail of each route.
• Storage of signed delivery notes (images) in a bucket.
• An operational database with vehicles, routes, stops and deliveries.
• A dashboard of punctuality, kilometres per route and failed deliveries by reason.
• AI component: OCR over the scanned delivery notes (vision API) to extract the order number.

Fictional data. 30 vehicles, 12 routes, 90 days of history with around 400 deliveries a day, and a GPS position generator that follows plausible trajectories.

Difficulty: medium-high. It is the proposal with the most data volume and the one that exercises streaming the most, but also the one whose cost most easily runs away if you leave the simulator running. Read that as a warning: here the cost requirement is part of the challenge.

⚠️ The geographic position of an identifiable person is personal data of a sensitive category. Work with invented vehicles and drivers, never with a real fleet's data.

The problem. A fictional technical training school wants to replace its arrangement of videos on a shared drive and enrolments by email with a platform of its own.

What you build.

• A public course catalogue and a private student area with their progress.
• Materials (PDFs, videos) in a bucket, served with CDN and signed URLs.
• An operational database with courses, lessons, enrolments and progress.
• "Lesson completed" events that feed the analytical warehouse.
• A dashboard of completion rate per course, lessons where people drop out and weekly activity.
• AI component: generation of an automatic summary of each lesson with a generative model, or semantic search over the content using embeddings.

Fictional data. 20 courses, 250 lessons, 800 students and 40,000 progress events.

Difficulty: medium. It is the proposal that most resembles this very course, which makes it easy to reason about and unlikely to surprise you.

Bringing your own problem is the best option if you meet the five criteria in section 2. A project that solves something you understand and care about defends itself far better in an interview than a template, because the moment they ask "and why this?" you have a real answer.

But there is one line that is not crossed:

⚠️ Do not use real data from your company, or from anybody's company.

Not an export "that is already anonymised". Not a dump of the development database. Not the customer file with the names changed. Not the support system's conversations "that do not have names in them".

Three reasons, any one of them sufficient:

1. Legal. GDPR does not distinguish between "production" and "a project I am doing to learn". If you process personal data you need a legal basis, a purpose, minimisation and a contractual relationship with the processor. A portfolio project in your personal GCP account has none of that.
2. Contractual. Almost any employment or confidentiality contract forbids taking company data into an environment the company does not control. Your GCP project is exactly that.
3. Practical. A portfolio project is shown off. It goes on GitHub, the URL is shared, it is projected in an interview. If it contains real data, you have just published it.

What you can do: replicate the structure of the real problem with invented data. The schema, the flows, the business rules and the technical difficulties are yours and are not confidential; the data is not. An 80-line synthetic data generator solves this in an afternoon.

And if your project is still going to handle data that looks like personal data (names, emails, addresses, even invented ones), apply from the start what you saw in 04-07 and 07-04: encryption at rest with managed keys, least privilege, defined retention with real deletion, and logs that do not write those fields. Not because your invented data needs it, but because the habit is the deliverable.

Before accepting it, fill this in. If any box is left empty, the idea is not ready:

The excluded scope section is the most important in the document and the one everybody leaves blank. Writing "there will be no payments", "there will be no mobile app", "there will be no multi-language", "there will be no roles beyond admin and user", "there will be no real email notifications" is what saves you three weeks from now, when you fancy adding any of those things.

These six are mandatory. Whatever your problem, they must exist. They are phrased as a verifiable list: each one has a "done" criterion you can check with a command.

Detail on each one:

RF-1 — Containerised web application. Containerised means there is a Dockerfile and that the image is built in CI, not on your laptop. The default recommendation is Cloud Run (07-02): it scales to zero, you do not pay when nobody is using it, and the contract is simple. If you choose GKE, let it be because you have a written reason, not to show off: a cluster left running eats the whole project's budget.

RF-2 — Object storage. An empty bucket created to tick the box does not count. It must be part of the flow: the user uploads something, or the application serves something from there. Apply what you saw in 02-02: uniform bucket-level access, nothing public except what has to be, and a lifecycle rule even if it is trivial.

RF-3 — Managed database. Managed, not a container with PostgreSQL inside. The decision tree in 02-06 tells you which: relational with transactions → Cloud SQL; documents with key access and scaling to zero → Firestore. For most of these projects, Cloud SQL PostgreSQL on the smallest instance or Firestore are the right answers.

RF-4 — Ingestion or processing. This is the requirement most people under-interpret. It is not enough for the app to write to the database. There must be an asynchronous or scheduled flow that takes data from one place to another: a Pub/Sub topic collecting events, a Cloud Run job that dumps into BigQuery every night, a function triggered when a file is uploaded. It is the piece that shows you understand the difference between the operational plane and the analytical one (04-01, 04-04).

RF-5 — Dashboard. Four visualisations that answer questions, not four pretty charts. "Which refuge has the most cancellations?" is a question. "Distribution of bookings" is not. Looker Studio on top of BigQuery is free and sufficient (04-07).

RF-6 — AI component. Always start with a pre-trained API. Vision, Natural Language or Gemini solve the requirement in two hours and they work. Training your own model with Vertex AI is optional, costs money and is the number one source of projects that never get finished. If you have time to spare at the end, then by all means: replace the API with a model of your own and document the comparison against the baseline, exactly as Lucía did in DA-003.

This is where this project separates itself from a demo. Eight requirements, all mandatory, all verifiable:

The three people skip and should not:

RNF-1 (real IaC). The criterion is not "I have some .tf files". The criterion is that the system rebuilds itself from scratch. The test is done in 08-04 and it is merciless: you destroy the entire development environment and create it again. If it does not come up, your IaC was not IaC: it was documentation with Terraform syntax.

RNF-3 (no JSON keys). This is the one that will differentiate you most. Most portfolio projects have a credentials.json in the repository or, at best, in .gitignore. Configuring Workload Identity Federation between GitHub Actions or Cloud Build and GCP takes half an hour the first time and is exactly what a professional does. And remember AlpinaShop's case: a key lost for fourteen months.

RNF-7 (SLO). An SLO is not "I want it to be fast". It is: "99 % of requests to /api/* respond in under 800 ms, measured over a 28-day window". With its error budget calculated and visible. It takes an afternoon and it is one of the things that impresses most in an interview, because almost nobody at junior level knows how to formulate it.

Set a monthly limit now and write it down. The project must be buildable and maintainable within Google Cloud's trial credit (300 USD / 90 days at the time of writing — verify it, the terms change) or, if your credit has run out, below a monthly limit you set yourself.

Reasonable reference values:

Why the constraint is part of the exercise and not an inconvenience. Anybody can build an architecture that works with infinite money. What distinguishes a good cloud engineer is building it with the money that exists. The cost constraint will force you to take exactly the decisions that are taken in a real company:

• Scaling to zero instead of having reserved capacity (Cloud Run vs. MIG).
• Choosing the smallest instance that does the job, and measuring whether it does.
• Shutting down development environments overnight.
• Partitioning BigQuery tables so you do not scan 1.2 TB every time the dashboard opens.
• Not leaving a GKE cluster running "for testing".
• Putting lifecycle rules on buckets from day one.
• Retaining logs for 30 days and not 400.

All of that is 07-05 applied to your own pocket, which is the best way to learn it.

Before creating a single resource. Literally on day one, before anything else:

And the warning that always bears repeating: a budget alerts, it does not prevent. If you leave something expensive running, the budget sends you an email while the meter keeps climbing. What really prevents are quotas (07-07) and the habit of looking at the billing report every few days. Set yourself a reminder: every Tuesday and every Saturday, open the cost report. Thirty seconds.

⚠️ All prices in this module are orders of magnitude, not rates. Google Cloud prices change, vary by region and depend on discounts and the free tier. Always check the official calculator and the service's pricing page before committing a figure to your architecture document.

Seven deliverables. The first three are the project; the next four are what makes the project assessable and defensible.

Repository structure (detailed in 08-03, but decide it now):

Create this skeleton today, even if it is empty. Empty directories with a one-line README.md saying what will go there are worth more than the best intention to organise it later.

This is the rubric you will use to assess yourself in 08-05. Read it now, because knowing how you will be scored changes what you build.

100 points, spread over seven blocks:

A. Design and decisions (20 points)

B. Functional implementation (20 points) — 3 points per functional requirement met (18) + 2 points if the complete flow works end to end with no manual intervention.

C. Infrastructure as code (15 points)

D. Security and identity (15 points)

E. Delivery and testing (10 points)

F. Observability, SLOs and cost (10 points)

G. Documentation and presentation (10 points)

That last row is not a joke. Honest self-assessment is part of the mark: in 08-05 you will see that recognising and prioritising technical debt adds points, and hiding it takes them away.

Estimate for a medium-difficulty project, first time, working alone:

Multiply by 1.5 if this is your first cloud project. It is not pessimism: it is the empirical observation that the first time you configure Workload Identity Federation it takes two hours and the second time, fifteen minutes.

The four milestones are checkpoints, not decoration. At each one you stop and check:

If you are running late, cut functionality, never non-functional requirements. An application with two screens, complete IaC and impeccable security scores far above one with eight screens and a credentials.json in the repository.

These five are not "common mistakes". They are the five reasons portfolio projects do not get finished. Recognise them now and you have half the work done.

How it shows up. In week 2 you add "it would be easy to put payments in too". In week 3, notifications. In week 4, a mobile app. In week 6 you have nine half-finished things and none of them done.

Why it happens. Because adding functionality is fun and finishing is not. And because the excluded scope was not written down.

The countermeasure. The exclusion list from section 4, written and signed by you on day one. When something new occurs to you, do not discard it: note it in a ## Next steps section of the README. That turns the temptation into a deliverable for the presentation, where it scores.

How it shows up. On day one you open the editor and start the application. Three weeks later you have a nice app and no infrastructure, no IaC, no security. And then you try to "put Terraform on" something that already exists, which is twice the work.

Why it happens. Because programming is what you know how to do and everything else feels like a chore.

The countermeasure. The order in 08-03: organisation → network → identity → state → data → application. The application is phase 4 of 8, not phase 1. And there is a hard technical reason: the projectId cannot be changed and the network cannot be redone without destroying everything. What gets decided first is what is expensive to change.

How it shows up. Everything with roles/owner "so it works now", a JSON key downloaded "temporarily", the database password in a variable in the code. In the last week you try to fix it, break everything and end up leaving it as it was.

Why it happens. Because least privilege hurts at the start: every missing permission is a 403 and half an hour of debugging.

The countermeasure. Start restrictive and only open what fails. gcloud policy-troubleshoot tells you exactly which permission is missing (you have it in 03-04). It hurts the first week and never hurts again. And block D of the rubric is worth 15 points that are lost entirely if you get this wrong.

How it shows up. You leave a GKE cluster running over a weekend. Or a streaming Dataflow job. Or a big Cloud SQL instance "so it goes fast". On Monday you have spent €180 and burned half the trial credit.

Why it happens. Because in the cloud you do not see the hardware. A switched-off server in your house consumes nothing; a running VM in the cloud does, even if you are not using it.

The countermeasure. Three things, all from section 7: the budget created before anything else, reviewing the cost report twice a week, and the habit of destroying the development environment when you are not using it. That last one is a superpower you only have if your IaC is real:

If that works, your development project costs nothing when you are not working. And along the way you are running the hardest test of RNF-1 every week, for free.

How it shows up. In the last week you sit down to write the architecture document and you cannot remember why you chose Firestore instead of Cloud SQL. You write a justification invented after the fact, which shows, and which may not even be the real reason.

Why it happens. Because documenting feels like it does not move the project forward.

The countermeasure. docs/diario.md. Every working session, three lines:

Three lines per session, twenty sessions: sixty lines that turn themselves into the architecture document, the ADRs and half the presentation. It is the best-return investment in the whole module.

The last one is the real risk. The genuine mitigation against abandonment is that the project is small and you fancy it, which is what criteria 2 and 5 were saying.

You are going to spend a substantial part of the project reading documentation. Doing it well is a skill, and these are the rules:

1. The official documentation is the source. Everything else is context. A blog post from 2021, a Stack Overflow answer from 2019 or a YouTube video can help you understand a concept, but not for copying commands: the CLI changes, roles get renamed, services get deprecated. The course itself, however up to date it is in 2026, is a snapshot of one moment.

2. The four sections you need to know for each service:

The quotas and limits section is the one fewest people read and the one that avoids the most grief. Knowing that Cloud Run has a request timeout, or that BigQuery has a maximum number of table operations per day, changes the design.

3. The Terraform registry is as important as the GCP documentation. For each resource you create, registry.terraform.io/providers/hashicorp/google/latest/docs gives you the exact arguments, which ones are required, which force the resource to be recreated (ForceNew) and what can be imported. That ForceNew is the difference between a 20-second apply and one that destroys your database.

4. Release notes exist. Every service has its release notes page. Before giving up on a feature, check whether it shipped last month.

5. When the documentation and the error message contradict each other, the error message wins. And when the error message says "permission denied", it is almost always right: it is not a bug, you are missing a permission.

You are going to get stuck. Several times. The following method resolves the vast majority of blockages in under twenty minutes, and the important thing is to apply it in order rather than trying things at random:

Step 1 — Read the whole error. All of it, to the end, including the details and the link it sometimes includes. Half of GCP's errors literally say which permission is missing or which API needs enabling.

Step 2 — Is the API enabled? It is the number one cause of inexplicable errors in the first week:

Step 3 — Is it a permission? If the error contains 403, PERMISSION_DENIED or does not have permission, it is a permission, no exceptions:

Step 4 — Is it the network? If the symptom is a timeout and not a rejection, it is the network:

Step 5 — Is the resource the way you think it is? A describe demolishes half of all wrong hypotheses:

And if after twenty minutes you are still stuck: switch task. Document the blockage in docs/diario.md with the exact error and what you have already tried, and go to another phase. Coming back the next day with a clear head resolves more blockages than pushing on for three hours straight. This advice sounds like self-help and is purely statistical.

Before moving on to 08-02, five things. They are not optional and they take no more than two hours:

• [ ] Choose the problem. One of the four proposals or your own, validated with the template in section 4.
• [ ] Write the sentence. One sentence without "and". Paste it into the first line of the README.
• [ ] Write the five exclusions. What your project is not going to do.
• [ ] Set the cost limit. A number in euros per month, written in the README.
• [ ] Create the repository with the folder skeleton and the first commit.

If you cannot do all five today, your problem is not chosen yet. Go back to section 2.

Choosing a problem you do not understand because it sounds impressive. "Credit risk analysis platform with AI" sounds better than "mountain refuge bookings" until you have to model credit risk. In an interview, a simple project explained well always beats a complex one you stumble through.

Confusing "complete" with "big". The project is assessed by layers covered, not by functionality. Two screens with IaC, CI/CD, an SLO and security are worth 80 points; fifteen screens with none of that are worth 45.

Creating the GCP projects before reading 08-02. The projectId is immutable. If you create test-1234 because you were in a hurry, you are going to show it in the interview. Wait for the design lesson, where the naming convention is decided.

Using the trial credit as if it were infinite. 300 USD looks like a lot until you leave a GKE running: a standard three-node cluster eats about €100 a month on its own. Cloud Run scales to zero; GKE Autopilot does not cost zero but costs little; standard GKE costs from minute one.

Leaving the AI component until the end and choosing to train a model. That is the reverse of the correct order: put the pre-trained API in phase 6 (two hours, it works) and only if you have time to spare, replace it with a model of your own. A simple AI component that works is worth the 3 points; an ambitious half-finished one is worth 0.

Not reading the rubric until the end. The rubric is the specification. Anything you do that is not in the rubric is time that does not score. Keep it open in a tab throughout the module.

Tip: do a git commit at the end of every session, even if it does not work. The commit history is a deliverable in itself: a repository with 60 commits spread over six weeks tells a story of real work. One with 3 giant commits tells a different one.

Tip: save every screenshot and every number from the start. The screenshot of the dashboard the day it worked, the result of the first load test, the first month's bill. In 08-05 you are going to need them and reconstructing them is impossible.

Tip: put a real alarm in the calendar. Two fixed sessions a week, in the calendar, with a name. Personal projects do not die from technical difficulty: they die because there is never a moment.

The exercises in this module are milestones of your own project. The solutions show the same milestone solved for RefugioReserva, the reference project, so that you have a model without being able to copy yours.

Choose your problem and fill in the full validation template from section 4: name, one-line sentence without "and", the problem with its user, included scope (maximum 5 points), excluded scope (minimum 5 points), the table of how you meet the six functional requirements, the origin and volume of the fictional data and the main risk.

Then score your idea with the decision table of the five criteria. If any criterion scores below 3, change idea or adjust it until it goes up.

Decide your monthly limit, justify it in two lines and create the real budget in your billing account with thresholds at 50, 90 and 100 %. Document in a table which services you expect to use, with which minimum configuration and what order of magnitude of cost you have in mind (you will refine it in 08-02 with the calculator).

Also, write the answer to this question: if in three weeks you discover you are at 200 % of your limit, what is the first thing you switch off? That order of priority written in advance is what saves you from deciding in a hurry.

Adapt the schedule in section 10 to your real availability (hours per week you can genuinely dedicate, not the ones you would like). Produce a mermaid diagram with your dates and your four milestones, and for each milestone write its pass criterion and what you would cut if you do not meet it.

Create the repository with the folder skeleton from section 8, the README.md with the project sentence, the exclusions and the cost limit, and docs/diario.md with its first entry. Make the first commit.

Solution 1 — Defining and bounding RefugioReserva

Score with the decision table:

Solution 2 — RefugioReserva's cost constraint

Limit set: €12 a month. Justification: the trial credit is already used up, and I want the project to be able to stay switched on indefinitely as a portfolio piece without it hurting. €12 is roughly what a domain costs (pro rata) plus a minimal database instance.

All these figures are orders of magnitude at the time of writing and for europe-west1. They must be redone with the official calculator in 08-02 before signing the design off.

If I hit 200 % (€24/month), this is the shutdown order, decided in advance:

1. Switch off Cloud SQL outside working hours with a scheduled job (starts at 9, stops at 23). Immediate saving: ~60 % of the big line item. Risk: the demo does not work in the small hours; acceptable.
2. Reduce log retention to 7 days and disable data access logs if I had enabled them.
3. Empty Artifact Registry, leaving only the last 3 images.
4. Migrate from Cloud SQL to Firestore. This is the nuclear option: it removes 80 % of the cost but means redoing the data layer. Only if the previous three are not enough, and it would be a new ADR with its consequences.
5. Destroy the development environment and work only against production, more carefully.

What I would not do: remove the load balancer or the certificate (breaks RNF-5), or disable monitoring (breaks RNF-6). Cutting non-functional requirements to save €2 is trading 15 rubric points for the price of a coffee.

Solution 3 — RefugioReserva's plan and groundwork

Declared real availability: 8 hours a week (two 2-hour evenings during the week + 4 hours on Saturday). Against an estimate of 50 hours, that comes to 7 weeks with a little headroom, not 6. Better to acknowledge it now than to be behind from week 1.

The ground prepared:

Notice two details in the .gitignore: *.tfvars and *credentials*.json. The first avoids uploading per-environment values that sometimes carry secrets; the second is a safety net in case one day, in a hurry, you download a key. You should not download any — RNF-3 — but the safety net does no harm.

And notice above all the last line of the log: do not create any GCP project yet. That is the discipline that separates this module from a tutorial.

You now have the complete specification.

You know what you are being asked for: a complete platform from end to end, not a demo, with all the course's layers connected and explained. And you know what you are not being asked for, which matters just as much: no beauty, no scale, no models of your own, no high availability.

You know how to choose the problem with five criteria in order — known domain, scope in one sentence without "and", inventable data, several natural layers and that you fancy it — and you have four worked proposals with their data, their difficulty and their risks, plus the option of bringing your own with one rule that is not negotiable: real data, never, not even "anonymised", not from your company, for legal, contractual and practical reasons.

You have the six functional requirements with their "done" criterion and the command that verifies it, and the eight non-functional ones that separate a project from a demo: reproducible IaC, CI/CD with a test, least privilege with no JSON keys, managed secrets, your own HTTPS, dashboard and alert, one measured SLO and a budget with an alert.

You have the cost constraint understood for what it is: not an inconvenience, but the requirement that forces you to take the same decisions taken in a company — scale to zero, the smallest instance that does the job, partition, switch off what is not used — and with the reminder that a budget alerts but does not prevent.

You have the seven deliverables with their format and their location, the 100-point rubric spread over seven blocks with criteria that can be verified one by one, and the honest reading of the score, including the warning that a 98 probably means you have marked yourself generously.

You have the planning: 48-75 hours spread over ten phases, a reference schedule with four milestones and, at each one, its pass criterion and what to cut if you fall behind — always functionality, never non-functional requirements.

And you have the five mistakes that sink a final project, with their symptom, their cause and their countermeasure: excessive scope (written exclusions), starting with the code (the phase order, because the projectId cannot be changed), security at the end (restrictive from day one and policy-troubleshoot as an ally), forgetting the cost (budget first and destroy on Fridays) and not documenting as you go (three lines of log per session, the best-return investment in the module).

In the next lesson, 08-02, you go from specification to blueprint: translating each requirement into a specific service with its justification and its rejected alternative, drawing the three diagrams that are worth having, deciding the project structure and the naming convention before creating anything, designing the network and identity on paper, modelling the data with its lifecycle, estimating the cost with the calculator and comparing it against your limit, defining your SLOs and writing your first ADRs.

And do not touch the GCP console until then. The projectId cannot be changed.