Most GCP exam prep guides will tell you to do labs, build projects, study for 3 months, and practice until you dream in cloud architecture.

I did none of that.

Here's what I actually did — and what I'd do differently if I were starting again.

My starting point

I already had the AWS Solutions Architect Associate cert when I decided to go for the GCP Associate Cloud Engineer. That meant I wasn't starting from zero — I understood what a VPC was, why IAM existed, how subnets worked. The cloud fundamentals were already there.

That confidence — and honestly, a little overconfidence — shaped how I approached the prep.

What I actually did

I bought a Udemy course, watched it over 3 to 4 weeks, and sat the exam.

That's it. No hands-on labs, no practice projects, no infrastructure spun up. Just the course with notes on anything unfamiliar.

If you're expecting a sophisticated study system — this isn't that post. This is the honest version.

Where my AWS background helped

A lot of GCP concepts clicked quickly because I already understood the why behind them:

• Cloud Storage felt immediately familiar — same idea as S3, similar permission model

• Cloud Run made sense straight away — serverless, event-driven, just like Lambda

• VPCs, IAM, subnets, service accounts — the concepts transferred even if the details differed

Knowing what these services are for meant I could focus on how GCP implements them, rather than learning from scratch.

Where my AWS background got in the way

The same knowledge that gave me a head start and confidence also created blind spots.

GCP's database options genuinely confused me. Cloud SQL, Spanner, Bigtable, Firestore, Memorystore — I hadn't built the same intuition I had for AWS equivalents, and the exam loves scenario questions that test exactly this.

Cloud Functions vs Cloud Run tripped me up. Both serverless, both event-driven — but different use cases. I didn't have a clean mental model going in.

The AWS comparison instinct worked against me in the exam room. When unsure, my brain defaulted to "what would AWS do here?" GCP has enough genuine differences that this caused second-guessing at the worst possible time.

What the exam actually tests

It's scenario-based — here's a business problem, which GCP services solve it? Focus your prep on:

• Database selection — Cloud SQL vs Spanner vs Bigtable vs Firestore

• Cloud Run vs Cloud Functions — know the difference clearly

• GKE — heavily tested

• IAM and Service Accounts — least privilege in practice

• Networking — GCP VPCs are global, not regional

What I'd do differently

Go in with a more open mind. AWS knowledge helps — but treat GCP as its own thing rather than constantly mapping it back to AWS. That comparison is a crutch that slows you down when the concepts genuinely diverge.

I'd also do some hands-on work in a real GCP environment. I passed without it, but I walked out knowing there were questions I guessed on that hands-on experience would have answered.

The honest bottom line

If you already have AWS SAA — 4 to 6 weeks with a good Udemy course is enough to pass. You don't need 3 months or an elaborate system.

What you do need is to be honest about where your AWS knowledge helps and where it creates blind spots. Go in knowing both.

Good luck. Drop any questions in the comments — I sat this over a year ago but the experience is still clear enough to be useful.

I'm a cloud ops engineer based in Canada working with GCP and Terraform daily. I spent 12 years in QA before switching careers. Follow along if you're on a similar journey.

I spent 12 years as a QA engineer.

Not dabbling — 12 years. That was my career, my identity, and what I thought I'd keep doing. Then the itch hit. I wanted something new because I was personally ready for a different kind of challenge. I wanted to build things, work closer to infrastructure, and move into a space I hadn't explored yet.

So I did what a lot of people do: I went down a rabbit hole exploring the hottest tech role and landed on data engineering. Spent nearly a year preparing for it. Courses, projects, the whole thing.

It didn't work out. Not because I wasn't capable — but because I kept losing direction. Data engineering has an overwhelming number of tools and I never felt confident about which ones to focus on. After nearly a year of feeling like I was going in circles, I decided to redirect my energy somewhere I could be more focused.

Looking back though, that year wasn't wasted. Building data pipelines meant I had touched real cloud resources like IAM, S3, Lambda, Glue — even if I didn't fully comprehend what I was doing at the time. When I started studying for the AWS cert, those experiences suddenly made sense. Concepts I had blindly configured before now had names, reasons, and context. The data engineering detour quietly became part of my cloud foundation.

I should also mention — I was doing all of this with a newborn at home. I'm not saying that to make it sound heroic. It just meant that perfect study conditions never existed. You find the gaps — a quiet 30 minutes, a phone during a feed, a lunch break. You just keep moving.

I had to pivot again.

This time I looked at what job postings were actually asking for. Multi-cloud knowledge kept coming up — AWS, GCP, Azure. So I made a plan: get the AWS SAA first, then Azure Fundamentals, then GCP Cloud Engineer. Stack the certs, build the story, apply everywhere.

Here's the part I don't see talked about enough: I got the GCP Cloud Engineer cert while I was still working as a QA. I hadn't switched yet. But I also wasn't starting from zero.

The hands-on experience from those data engineering projects mattered more than I expected. I had actually provisioned real cloud resources, dealt with IAM permissions, and understood at a basic level how cloud services connect. When I sat the cert exam, that context made a real difference.

After multiple failed interviews — both external and internal — I landed a GCP cloud ops role. The cert opened the conversation, but it was the combination of certification and real hands-on experience that made the difference.

One year in, I'm working with GCP and Terraform daily.

If you're in the middle of a career switch and it's not going the way you planned, that's not failure. My first few attempts didn't work out. The pivot did. Sometimes the path is messier than the plan — and sometimes the detours are exactly what you needed.

I got this cert while still working as a QA full time. No one had given me a cloud role yet. I just decided to get qualified first and figure out the rest after.

In my next post I'll cover how I actually prepared for the GCP Cloud Engineer exam — what tripped me up coming from AWS, what I'd do differently, and the resources that were actually worth my time.

I'm a cloud ops engineer based in Canada, working daily with GCP and Terraform. I spent 12 years in QA before switching careers — got my GCP cert while still in my old role and used it to land a new one. I write about real problems I run into at work, cert prep, and what career switching in tech actually looks like. Follow along if any of that sounds useful.