You have finished the project. You have a system that is built, tested, measured, documented and defended. And now comes the question that always arrives at the end of a long course: what now?

This lesson answers that as honestly as possible, which includes telling you things that are not always said: what this course has given you and what it has not, what certifications are really for and what they are not, how long the first cloud job actually takes to arrive, and why half of what you have learned will expire in three years while the other half will never expire.

This is not a theory lesson. It is a map: where you are, what paths exist, what each one costs and which one makes sense depending on what you want to do.

And it is the last lesson of the course.

1. Where you are now: the honest map
2. The Google Cloud certification path
3. How to prepare for the Associate Cloud Engineer
4. What certifications are and are not worth
5. Building real experience without a cloud job
6. Specialising: the five profiles
7. Keeping up to date when the platform changes every month
8. A word on multicloud, AWS and Azure
9. The closing

These are the things you can do on your own, without a tutorial, and could repeat in a different environment:

It is more than it looks. And above all: you have done all of that together, in a single system, which is the hard part.

Here it is worth being precise, because confusing "I have seen it" with "I know it" is the fast track to an uncomfortable interview:

And this is just as important to know:

• Real migrations: moving a company with legacy systems, undocumented dependencies and cutover windows. It is half of an architect's real job.
• FinOps at scale: committed-use discounts, attribution in large organizations, negotiating with the provider.
• Serious regulatory compliance: ENS, ISO 27001, SOC 2, sector-specific schemes. GDPR is mentioned; it has not been worked on.
• Teamwork on the same infrastructure: Terraform code reviews between several people, shared environments, handling state conflicts.
• On-call and 24×7 operations: rotas, escalation, alert fatigue.
• Procurement and contracts: support, contractual SLAs, corporate billing accounts.

Being at "practitioner" after a course is exactly where you should be. And there is a fact worth keeping in mind: plenty of people with two years of cloud experience have never written a Terraform module or defined an SLO, because in their company another team does that. You have.

⚠️ The names, syllabuses, prices, durations and validity periods change. Everything that follows is indicative at the time of writing; always check cloud.google.com/learn/certification before registering.

Three rules about the order:

1. Do not skip the ACE and go straight to a professional one. You can — there are no formal requirements — and it is a bad idea: the professional exams assume you know how to operate the platform and ask about decisions, not about mechanics.
2. Cloud Digital Leader is not a step before the ACE. It is a different path, for non-technical profiles. If you have finished this course, starting there is a waste of time and money.
3. One professional exam at a time, with real experience in between. Collecting certifications with no projects behind them produces a CV that falls apart in the first technical interview.

Two things about the format that matter: they do not publish the pass mark, so there is no way to work out how much margin you have; and the exam does not penalise wrong answers, so never leave a question blank.

It is the natural next step after this course, so it gets covered in detail.

Five areas, all of them about doing, not designing:

Honest diagnosis: this course covers between 70 and 80 % of the syllabus well. The three clear gaps are Compute Engine in depth (disks, snapshots, managed instance groups), GKE with real kubectl and the exact syntax of the commands. The exam asks things like "which of these four commands does X?", and understanding the concept is not enough there: you have to have typed them.

On question dumps: they exist, they circulate, and using them breaks the exam agreement — your certification can be invalidated. Beyond that, there is a practical reason: passing by memorising answers produces a certification you cannot back up in a technical interview, which is exactly the worst possible outcome.

Assuming 6-8 hours a week:

Week 7 is the one that decides. And the rule that makes it useful: for every question you get wrong, seeing the right answer is not enough; you have to understand why the other three are wrong. That exercise is the one that really teaches.

On renewal: certifications expire after two years and are renewed by sitting the exam again (sometimes with a shorter renewal exam, depending on the programme in force — check this). It is worth knowing before you invest: it is not a permanent qualification, it is a subscription.

Said bluntly, because there is a lot of exaggeration in both directions.

• They get you past the filter. Many hiring processes filter CVs automatically. A certification puts you in the pile somebody actually reads.
• They structure your study. The official syllabus is a concrete list of what you need to know, which is enormously valuable when you study alone.
• They fill gaps you did not know you had. Studying for the ACE forces you to look at Compute Engine in detail even if your project used Cloud Run.
• They are worth money to consultancies. Google partners need a number of certified people to keep their partnership tier. In that specific market, a certification is an asset with direct value.
• They give you confidence. That is not a minor argument when you have spent months studying alone.

• They are not a substitute for experience. Nobody hires an architect for having the Professional Cloud Architect. The certification opens the conversation; experience sustains it.
• They do not guarantee a job. The market asks for "2 years of experience" with or without a certification.
• They do not prove you can build. A multiple-choice exam measures recognition, not capability. Your project proves more than your certification.
• They expire. Two years. It is a subscription, with its recurring cost in money and in time.
• They do not teach the hard part. No certification teaches you to say no to an impossible requirement, to negotiate a deadline or to run a migration with frightened people.

Certification + your own project + the ability to explain it.

All three together. With only the first, you are one candidate among many. With only the second, you do not get past the automated filter. With all three, you are ahead of most junior profiles, because most have one or two.

And if you had to choose only one — because money or time will not stretch further: the project. It is what sustains a forty-minute technical interview.

The classic vicious circle: they ask for experience to give you a job, and you need a job to get experience. It can be broken in four places.

You already have one. Do two more, each attacking a different gap from section 1:

The "not a toy" criterion: it has IaC, it has CI/CD, it has observability and it is documented. A tutorial you followed does not count; a decision you took does.

• Documentation for open source projects. It is the most accessible way in and the most appreciated: fixing an example that no longer works in the Terraform provider for Google is a real contribution.
• Terraform modules. Publishing a well-built module, with a README, examples and tests, is a professional artefact.
• Answering questions. Explaining something to somebody else is the best way to find out whether you know it.
• Writing. An article telling the story of a problem you solved and how. It does not need to be original: it needs to be concrete.

Google Cloud offers an initial trial credit (~USD 300 / 90 days, check this) and a permanent free tier with monthly quotas for several services. With discipline, you can practise for months without paying.

The seven rules of not spending money:

1. A budget with alerts before anything else, always.
2. Nothing that does not scale to zero, unless you have decided otherwise: Cloud Run, Functions, Firestore and BigQuery are your allies.
3. terraform destroy at the end of every session. If your IaC is good, it costs one command.
4. Never leave standard GKE switched on. A three-node cluster is ~€100/month.
5. Never leave Dataflow streaming switched on. It bills 24 hours a day.
6. Watch out for reserved and unused static IPs, which cost money even doing nothing.
7. Check your billing twice a week. Thirty seconds.

And a warning that has to be said clearly: a service account key leaked into a public repository can be used by third parties to mine cryptocurrency in your project, with bills of thousands of euros within hours. It is a documented and frequent incident. That is why RNF-3 of this module was zero JSON keys: it is not purism, it is your credit card.

What makes a portfolio stand out is not the quantity, it is the depth of a single one. One project with a documented architecture, ADRs, tests, an SLO and a measured cost is worth more than eight repositories with a deployed hello world.

And the most effective shortcut, which almost nobody uses: if you already work in tech, propose the first cloud project at your company. Migrating an internal service, setting up a test environment, automating something with Terraform. Real experience, on your CV, without changing jobs. It is by far the quickest route.

Ask yourself which part of the module 8 project you enjoyed:

And do not agonise over the choice: profiles are not cages. Most people change once or twice, and everything you have learned transfers.

Google Cloud publishes changes constantly. It is impossible to follow everything, and there is no need to.

The practical rule: for a project that is meant to last, use GA services with at least a year of life. Novelty is fun and expensive.

The console changes. Names change — Stackdriver became Cloud Operations, AI Platform became Vertex AI. Services get deprecated: Deployment Manager, Cloud Source Repositories.

What does not change:

• The principle of least privilege.
• The difference between the operational plane and the analytical plane.
• That state has to be stored somewhere with locking.
• That a system without observability is a system you do not know is working.
• That a rollback is more valuable than a perfect deployment.
• That cost is a design requirement.
• That decisions are documented because people forget.

That is what transfers between clouds, between companies and between decades. If you take seven things away from this course, let them be those seven.

Practically everything conceptual, with different names:

And everything that is not a product transfers whole: least privilege, IaC, SLOs, error budgets, canaries, the data lifecycle, cost attribution, ADRs. Learning the second cloud costs a fraction of what the first one cost, typically a few weeks to become productive.

• The mechanics. Commands, role names, limits, specific behaviours. You relearn them.
• The network models. The GCP VPC is global; the AWS one is regional. It is a real conceptual difference, not a cosmetic one.
• The identity models. AWS IAM with JSON policies and GCP IAM with roles and a hierarchy resemble each other less than they appear to.
• The philosophy. GCP tends towards the managed and the opinionated; AWS offers more pieces and more responsibility. Neither is better: they are different approaches.

For your career: specialise in one and know the others. Being good at one cloud is worth more than being mediocre at three.

For an architecture: real multicloud — the same workload running on two providers — is expensive and complex, and it almost never pays off. What is common and reasonable is using different services from different providers for different things.

It is exactly the reasoning of AlpinaShop's ADR-004, when it decided not to adopt the hybrid platform: portability has a price, and you have to be sure it is going to be used.

Go back to the beginning for a moment.

In module 1, AlpinaShop was a mountaineering equipment shop with forty people, a physical shop in Sabadell and a platform hosted on a rented server that fell over on campaign days. Marta administered that server by hand. Dani deployed by uploading files. Lucía produced reports by exporting to spreadsheets. Nobody knew how much it really cost to fulfil an order.

And look where they ended up.

The platform runs on Cloud Run, with not a single virtual machine on the serving path — the promise made in module 2 with DA-001 that took five modules to fulfil. The data lives in a managed database with high availability and in an analytical warehouse that Lucía queries without asking anybody's permission. The network is a Shared VPC with real hybrid connectivity to Sabadell and a perimeter that stops the data leaving. Every deployment goes through tests, is promoted with an approval and can be undone in seconds. There are dashboards, alerts, traces and SLOs with an error budget, which is what turned "it feels slow" into a conversation with numbers. There is a recovery plan that has been tested, and that found five problems nobody suspected. And there are organization policies that turn agreements into controls: today, at AlpinaShop, you cannot create a permanent key even if you want to.

The bill went from €1,058 to €425 a month. The cost per order, from €0.88 to €0.35. But what really changed was not the number: it was that now it is understood.

And along the way you saw something courses rarely teach: decisions being undone. App Engine was rejected. GKE was withdrawn. Anthos was turned down, with its review conditions written out. A recommendations endpoint was switched off because batches came out cheaper. A three-line heuristic turned out to be a better baseline than anybody expected. A load balancer was destroyed because it cost more than the whole project.

That is real engineering. It is not getting it right first time: it is deciding with the information available, writing down why, and having the judgement to change your mind when the context changes.

And then there is what you did.

You chose a problem. You bounded it, with written exclusions that saved you from an impossible scope. You designed it before typing, because the projectId cannot be changed. You estimated the cost before spending a euro and, probably, that estimate forced you to change the architecture — which is exactly what it is for. You built in order: network before application, identity before data, one deployment by hand before automating it. You wrote a test that failed and forced you to do it properly. You destroyed your entire environment and brought it back up. You audited your own security and found something. You triggered an alert to check that it arrived. You rehearsed a rollback with a stopwatch. And you told the story, with numbers, including what did not work.

None of that is an exercise. It is the job. It is literally what a cloud engineer does on a Tuesday afternoon, with the only difference being that there are more people, more pressure and more money at stake. The mechanics are the ones you have just practised.

There is a huge amount ahead. Real Kubernetes, real migrations, teams, on-call, systems that have been running for ten years and that nobody dares touch. The platform will change: some services you have studied will have a different name in three years and some will have disappeared. That is not a problem, it is the profession.

Because what stays is not the screens. What stays is knowing that least privilege hurts at first and never hurts again; that a log the administrator can delete is no use as evidence; that a restore that has not been rehearsed does not exist; that an SLO without an error budget is a decorative number; that cost is a design requirement and not a bill that turns up; and that the decision you did not write down on the day you took it is one you will not remember.

You know how to build a complete system in the cloud, from start to finish, and you know how to explain why it is built that way.

Nobody can take that away from you.

Now go and build it again, with something that matters.

Collecting certifications with no projects. A CV with three certifications and no repository falls apart at the first technical question. Alternate: certification, project, certification.

Going straight to a professional exam, skipping the ACE. The professional exams assume you know how to operate the platform. Without that base, you study twice as much and pass less well.

Studying only with videos. The exam asks about commands. Commands are learned by typing them.

Using question dumps. It breaks the exam agreement and produces a certification you cannot back up.

Leaving resources switched on while you study. The week 3 lab with a forgotten GKE cluster costs more than the exam.

Waiting to "be ready" before job hunting. You never will be, entirely. With this course and a project you can already apply for junior roles.

Neglecting the project once it is finished. A README with numbers and a tidy repository keep working for you months later.

Tip: book the exam date before you feel ready. A specific date organises eight weeks of study in a way no good intention ever does.

Tip: if you already work in tech, propose the first cloud project at your company. It is the fastest route to real experience there is, and almost nobody uses it.

Tip: write about what you have done. An article telling how you solved the Cloud SQL peering or why you chose Cloud Run counts as a public demonstration of judgement, and it forces you to understand it better.

Tip: repeat the rebuild from scratch every few months. It is the best reminder that your project is still alive, and you will discover what has changed on the platform.

Draw your own honest map using the three tables from section 1: what you have mastered, what you have seen but not mastered and what has not been touched at all, adapted to what you have actually done in your project (not to what appears in the syllabus). Place yourself on the calibration scale and justify it with concrete evidence from your own work.

Then decide and write down: which certification you are going to take and why that one, with what target date, and which career profile fits you according to which part of the project you enjoyed.

Download the official guide for the exam you have chosen and cross-reference its syllabus, area by area, against what you have seen in this course, marking what is covered, what is partial and what is missing. Take the official sample exam without studying and note down your percentage and your weakest areas.

With that, adapt the eight-week plan from section 3 to your real gaps and your availability, week by week, with concrete and verifiable activities (not "study networking", but "create one load balancer of each type and note down how they differ").

Go through your repository as a stranger would see it: README with the numbers at the top, technical debt visible and prioritised, instructions that work copied and pasted, and the links to the demo — or to the video, if you switched it off — clearly visible.

Write your two-line professional description and the memorised 90 seconds. And choose one specific problem you solved during the project — the peering, event deduplication, the connection pool, the public bucket — and write five hundred words about it: what was happening, what you tried, what it actually was and what you learned.

Solution 1 — The diagnosis of the author of RefugioReserva

Honest map, adjusted to what was actually done:

Calibration: practitioner, without a doubt. The evidence is that I built a complete system on my own, but also that if tomorrow somebody asks me to debug a GKE cluster in production, I would not know where to start.

Decision: Associate Cloud Engineer, target date in ten weeks (eight of study plus two of buffer), registration done in week 2 so that the date is real.

Profile: what I enjoyed most was the Terraform, the pipeline and the moment of seeing the alert arrive. What I enjoyed least, the application interface. SRE / DevOps, and in the medium term the Professional Cloud DevOps Engineer.

Solution 2 — Diagnosis and study plan

Sample exam without studying: 62 % (13 out of 21). The mistakes, grouped:

It matches almost exactly the diagnosis in the mapping table in section 3: the gaps are Compute Engine, GKE and command syntax.

Adapted plan (7 weeks, 6 h/week, with Compute Engine and GKE reinforced):

The rule that makes this plan work: every week ends with a terraform destroy or manual deletion of what was created. Over seven weeks of study, the total cost was €4.10, almost all of it the GKE cluster from weeks 3 and 4.

Result of the second mock exam: 88 %. Of the third: 91 %. Exam passed.

Solution 3 — The portfolio

Professional description (two lines):

I build and operate platforms on Google Cloud: Terraform, Cloud Run, Cloud SQL, BigQuery and keyless CI/CD. A complete project of my own, documented and measured: €10/month, rebuildable from scratch in 14 minutes → github.com/usuario/refugioreserva

What was fixed on reviewing the repository with somebody else's eyes:

1. The demo link pointed at a system that was switched off. Replaced by the video, with a note explaining that it was switched off on purpose and that it is rebuilt in 14 minutes.
2. The "bring it up from scratch" block did not say that a billing account and a domain are needed. A prerequisites section was added.
3. The numbers were in section 5 of the README. Moved up to just below the title.
4. The 14 screenshots were in docs/evidencias/ with no index at all. A README was added in that directory explaining what each one proves.

The article chosen: "My events were arriving duplicated in BigQuery and the dashboard was lying by 12 %". That one was picked out of the four candidates for three reasons: the symptom was invisible (nothing was failing), the cause is a fundamental and badly understood concept (Pub/Sub's "at least once" delivery), the solution is one line of code (row_ids), and the lesson is general — always reconcile the analytical warehouse against the operational one. Five hundred words, a code snippet, a table with the figures before and after.

It is exactly the kind of article an interviewer reads all the way through: concrete, with a real problem and a transferable lesson.

The course ends here.

You know where you are: at practitioner level, able to build a complete system on your own, with an honest map of what you have mastered, of what you have seen without mastering — GKE, Dataflow, Vertex AI, advanced networking — and of what has not been touched at all: real migrations, FinOps at scale, regulatory compliance, teamwork on the same infrastructure and on-call.

You know the complete certification path, with who each one is for, what it measures, what experience it assumes and in what order they make sense, with its three rules: do not skip the ACE, do not mistake Cloud Digital Leader for a preliminary step, and one professional exam at a time with real experience in between.

You have the detailed plan for the Associate Cloud Engineer: its five areas with their weights, the mapping table that says what this course covers — between 70 and 80 % — and what the three real gaps are (Compute Engine in depth, GKE with real kubectl and the exact syntax of the commands), the resources that are worth it, the eight-week plan with the mock-exam week as the one that decides, and the format tips, including the warning that it expires after two years.

You know what certifications are and are not worth: they get you past filters, they structure your study, they fill gaps and they are worth money to consultancies; but they are not a substitute for experience, they do not guarantee a job, they do not prove you can build and they expire. And you know what the combination that works is — certification, project and the ability to explain it — and which one you would choose if you could only have one.

You know how to build real experience without a cloud job: your own projects that are not toys, contributions, writing, the free tier with its seven rules of not spending money — including the reason why JSON keys are your credit card — a portfolio with depth instead of quantity, and the shortcut almost nobody uses: proposing the first cloud project at the company where you already work.

You know the five profiles with what each one really does day to day, what to study for each path and how to choose by looking at which part of your project you enjoyed. And you know that profiles are not cages.

You know how to keep up to date without drowning: the release notes of what you use as the only mandatory source, the deprecation notices as the ones that force you to act, how to tell an announcement in preview from a mature tool, and why it is worth learning concepts and not screens — because the console changes, the names change and services get deprecated, but least privilege, the separation between the operational and the analytical plane, the rollback, cost as a requirement and the documented decision never change.

And you know what transfers to AWS and Azure and what does not: everything conceptual with different names, nothing of the mechanics; that the second cloud costs a fraction of the first; and that for a career it is worth more to be good at one than mediocre at three.

You have been through eight modules. You have followed AlpinaShop from a rented server that fell over on campaign days to a platform that builds itself, observes itself and is governed with controls instead of with good intentions. You have watched decisions being taken and also undone. And then you built your own, from start to finish, with your hands, your decisions and your numbers.

What you take away is not a list of Google Cloud services. It is the way of thinking behind it: deciding with the information available, writing down why, measuring instead of opining, accepting constraints as part of the design, testing what you claim and acknowledging what did not work.

That works in this cloud, in the next one and in whichever comes after.

Good luck. Now go and build.