For context, I’ve spent about six years working in the “Cloud/DevOps” space and about four years of hands on AWS specifically. My first few years were spent building for Azure. I prefer AWS by a mile. Some days I don’t want anything to do with Microsoft at all. AWS just fits the way I think about building systems, so once I switched over properly, I stayed there.

At my current organisation, I joined at a time when the company was at the “foundation stage” of its cloud adoption journey. I was the sole DevOps/Platform engineer, which meant I had the rare opportunity to build almost everything from scratch: AWS landing zones, networking foundations, CI/CD pipelines, multi-account structure, security baselines, everything. It was a playground in the best possible sense complex but greenfield, high-impact, and packed with learning opportunities.

This is important, because hands-on experience is the single biggest predictor of success in the AWS SA-Pro exam. And I’ll say this upfront: if you don’t actively build things in AWS, this exam is going to feel very theoretical.

How Hard Is the AWS Solutions Architect Professional in 2025?

The honest answer: It depends on your mileage.

For me personally, the exam wasn’t overwhelmingly difficult. Challenging? Definitely. But not in the “I have no idea what they’re even talking about” way. I would describe it more as: You absolutely need to know the small details. Not just the concepts details. And the only way to know those details is to have spent real time navigating AWS services in production scenarios.

If I compare it to the AWS Solutions Architect Associate, which I sat in August 2024, the Professional exam is surprisingly similar in what it tests. The Associate always felt like trivia to me. Lots of “what service does what” and that sort of thing, which is fine for what it is, but it never felt close to how you actually design systems day to day. The Pro exam expects you to:

• understand the tradeoffs between services,

• know the correct design pattern for common architectures,

• identify failure scenarios,

• design cross-account, cross-region, and multi-service solutions.

It feels much more like real architecture work instead of memorising product labels.

AWS has widened the coverage and injected more subtlety into the questions. The trick is not “knowing everything”, but knowing the right models for designing scalable, resilient, secure architectures.

The exam is also very time-intensive. I had three questions marked for review when I completely ran out of time. That’s after moving at a fairly brisk pace. Many questions have multiple paragraphs, multiple moving parts, and multiple “correct” answers where you must pick the best one. Managing time is as important as managing knowledge.

My Strengths (and Weaknesses) Going Into the Exam

Because of my day-to-day work, I use a lot of the “core” services

• EC2s, ECS and EKS

• Lambda

• SQS/SNS

• API Gateway

• VPCs design and inter-VPC connectivity

• RDS/Aurora/DynamoDB/Elasticache

• CloudFront

• Multi-account organisations - tons of questions on SCPs

• IAM, SSO, and identity patterns

This aligns very well with the blueprint of the exam, so those domains felt comfortable. In fact, I would say the exam heavily rewards anyone who has:

1. Designed infrastructure at scale

2. Worked in multi-account environments

3. Built distributed systems with real production constraints

4. Dealt with networking issues, cross-region connectivity, and failover

5. Spent time on security and identity management

If you’ve lived through real outages, written Terraform modules a dozen times, refactored networking because of growth, or had to justify your design against the Well Architected pillars, you’ll find the exam scenarios eerily familiar.

My main weakness was the data/ML side of AWS.
We don't really use AWS Glue, EMR, Redshift, or SageMaker heavily in my daily work. These definitely showed up in the exam, but never in a way that required deep implementation knowledge If you understand broadly what these services do and when they’re appropriate, that’s generally enough.

Should You Take the AWS SA-Pro in 2025/2026?

If you have years of hands-on AWS. It reflects real world skills and validates the kind of architectural decision making used by senior engineers and architects.

I consider it a must-have for anyone aiming to become an enterprise architect, DevOps lead, or principal engineer. It demonstrates that you can design, reason about, and justify large scale infrastructure decisions, which is exactly what modern engineering teams rely on.

If you’re someone without real hands on experience in AWS and you’re trying to pivot into cloud engineering from something unrelated, this is not the cert to start with. It will feel brutal and rote learning. The whole exam assumes you’ve actually built things, broken them, fixed them and learned from that cycle.

Final Verdict

Passing the AWS Solutions Architect Professional in 2025 was a rewarding milestone. It reaffirmed what I’ve learned over the years: the best way to become good at cloud architecture is to build things, break things, fix things, and keep iterating.

The exam isn’t about trick questions or obscure trivia. It’s about real, practical architecture. It’s about the tiny details you only learn from deploying production systems, not from watching videos.

Let me properly introduce myself since you've clearly stumbled into my digital living room. I'm Joel. By day, I perform arcane rituals to appease the Cloud Gods (mostly AWS and Azure, though occasionally I dabble in the dark arts of Google Cloud when feeling particularly masochistic). People call this "DevOps" or "SRE" or "Platform Engineering," but really it's just professional whack-a-mole where the moles are servers and the mallet is YAML. Sometimes I win. Sometimes the moles form a union. It's complicated. Whatever.

Why?

I've reached that dangerous age where men traditionally do dull things like buy dull cars or take up falconry. Instead, I started a blog. This is clearly the mature choice or another dull idea.
I almost didn't launch this blog. Not because of technical challenges or laziness, but because of that nagging tech bro question: "What's your unique value proposition?"

Then I realised I don't have one. I'm not here to "disrupt" or "innovate" or "synergize." I'm just a guy who loves technology, hates unnecessary complexity, enjoys flying, and occasionally has coherent thoughts between debugging sessions. My credentials? I've broken production environments in multiple countries and lived to tell the tales.

What to Expect (Besides Occasional Regret)

I admire people with niche blogs about "Python left pad optimization techniques." I am not those people.

1. Cloud/Infrastructure Shenanigans:
   I'll rant about AWS and cry about Microsoft, Kubernetes clusters, and why every "serverless" solution causes pain. I might even share my patented "Five Stages of Production Outage Grief" (Spoiler: Stage 4 involves questionable whiskey choices).

2. Aviation Adventures:

   As a private pilot, I've developed a Pavlovian response to the smell of 100LL.

   I'll take you inside the cockpit (metaphorically) to explore this world that breeds superiority complexes.

3. Tech Philosophy (With Poor Life Choices):
   Deep dives into critical questions like:

• Why do we call it "Artificial Intelligence" when it's mostly artificial stupidity?

• Can we rebrand tech debt as "technical nostalgia"?

• Why does every documentation page look like it was translated through Klingon and back?

  Will there be useful technical insights? Absolutely but covered in the metaphorical Cheeto dust of real world chaos. Will there be aviation stories? Definitely! An hour wont pass without me talking about aeroplanes.

  If you've read this far, congratulations and my condolences. You clearly have the same questionable judgment that led me to start this circus. Feel free to yell at me.
  Now if you'll excuse me, I need to go troubleshoot another prod issue. Some things never change.

Clear skies and clean builds,
Joel