How I Passed the AWS SAA-C03 (After Initially Feeling Completely Lost)

May 27, 2026

When I started studying for the AWS Certified Solutions Architect Associate exam (SAA-C03), I thought it would be straightforward. I already worked in IT. I had touched cloud concepts before. I figured it would mostly be connecting dots and memorizing a few services.

I was wrong.

The exam is broad in a way that sneaks up on you. AWS isn’t just “learn EC2 and S3.” It’s learning how dozens of services interact under different constraints: cost, scalability, fault tolerance, security, operational overhead, and performance. The hard part isn’t memorizing definitions. It’s thinking like an architect under pressure.

Passive Studying Felt Productive, But Wasn’t

I started with videos and note-taking. At first it felt great. I was picking up terminology fast: VPCs, route tables, security groups, NAT gateways, load balancers, IAM policies, RDS vs DynamoDB, SQS vs SNS.

The issue: recognition is not the same as recall.

I could recognize concepts when an instructor explained them, but AWS exam questions are designed to force tradeoffs. You’re rarely asked, “What does this service do?” You’re asked, “Which architecture BEST satisfies these constraints while minimizing operational overhead and maximizing availability?”

That’s a completely different skill. I had fallen into the classic trap: consuming information instead of stress-testing my understanding.

Adrian Cantrill Helped Me Understand AWS Under the Hood

What helped me most was Adrian Cantrill’s AWS courses. His material focuses on how AWS actually works under the hood, not surface-level memorization.

A lot of courses teach AWS like a glossary: “Here’s what S3 does. Here’s what Lambda does.” But architecture requires understanding why these systems behave the way they do. What actually happens when traffic traverses a NAT Gateway? Why is EFS fundamentally different from EBS? Why does eventual consistency matter? What tradeoffs make serverless attractive in some scenarios but not others?

That deeper understanding made it much easier to reason through unfamiliar scenarios.

But I learned something important: understanding AWS deeply is necessary, but not sufficient to pass the SAA-C03. There was still a separate phase where I had to learn the testing mentality.

AWS questions are engineered with trap answers that are technically valid but not optimal, overengineered solutions, services that almost fit, and answers that violate subtle constraints like operational overhead or cost. Early on, I’d choose answers that worked instead of answers most aligned with AWS best practices.

That distinction matters. Multiple answers may satisfy the functional requirement, but AWS usually wants the one that’s more managed, more scalable, more fault tolerant, easier to operate, and more cost-efficient long term.

Over time, I started noticing recurring phrases: “minimal operational overhead,” “most cost-effective,” “highly available,” “decoupled architecture,” “elastic scaling,” “least administrative effort.” Those phrases aren’t filler. They’re often the entire question.

Once I began treating AWS questions less like trivia and more like architectural optimization problems, my scores improved dramatically.

The Turning Point: A “Lessons Learned” Journal

The single highest-yield thing I did was keep an Excel “lessons learned” journal. Every time I got a practice question wrong, I documented what the question was actually testing, why my answer was wrong, why the correct answer was better, the keyword or architectural clue I missed, and the AWS design principle behind it.

Patterns emerged:

“Managed service” meant AWS wanted the lowest operational overhead answer
“Decoupling” pushed toward SQS, SNS, or EventBridge
“Millions of requests with unpredictable scaling” hinted at serverless
“Shared storage across multiple EC2 instances” screamed EFS
“Millisecond latency at massive scale” pointed toward DynamoDB

My studying shifted from “memorize AWS facts” to “recognize architectural patterns.” The exam rewards pattern recognition more than raw memorization.

Anki Was Lower Yield for Me

I tried Anki because everyone recommends spaced repetition. To be fair, Anki works well for service limits, feature differences, acronyms, and small factual distinctions.

But for this exam, I found it lower yield. The SAA-C03 is less about isolated facts and more about judgment under ambiguity. A flashcard can teach you “S3 is object storage.” It can’t prepare you for “A company needs a cost-effective, highly durable storage solution for infrequently accessed archival data with retrieval times of several hours.”

I shifted most of my energy from flashcards to practice-question analysis, and gains came much faster.

Tutorials Dojo Practice Exams Were Incredibly Helpful

The biggest accelerator was the Tutorials Dojo practice exams. This was the closest thing to learning the language of the actual AWS exam.

The value wasn’t just the questions. It was the explanations. Good explanations teach why the right answer is correct, why the wrong answers are tempting, and what AWS principle the question is testing.

AWS exams are full of distractors that are technically possible but operationally suboptimal: a solution might work but require too much maintenance, scale but cost too much, or be secure but violate the “fully managed” requirement. Tutorials Dojo trained me to think comparatively instead of absolutely. That’s how real cloud architecture decisions actually work.

The Free AWS Practice Question Bank Was Underrated

One resource people overlook is the free AWS practice question bank. Working through AWS-authored questions helped me calibrate to how AWS frames problems.

AWS has recurring themes: prefer managed services, reduce operational burden, design for failure, scale horizontally, optimize for elasticity, use least privilege, automate where possible. Once you internalize those principles, many questions stop feeling like random trivia. You start seeing the worldview behind the exam.

What Finally Made Everything Click

Near the end, something changed. Instead of memorizing every AWS service independently, I started organizing them mentally around problems:

Storage: S3, EFS, EBS, Glacier, FSx
Messaging and decoupling: SQS, SNS, EventBridge, MQ
Compute: EC2, Lambda, ECS, Fargate, Elastic Beanstalk
Databases: RDS, Aurora, DynamoDB, Redshift
Networking: VPC, Route 53, CloudFront, Transit Gateway, Direct Connect

That mental compression reduced cognitive overload massively. Instead of memorizing hundreds of isolated facts, I was learning systems. Systems are easier to reason about under exam pressure.

Final Thoughts

Passing the SAA-C03 wasn’t about finding a magic resource. It was about changing how I learned. The biggest improvements came from reviewing mistakes deeply, building a lessons learned journal, studying architectural tradeoffs, practicing scenario-based thinking, and prioritizing understanding over memorization.

If you’re struggling early on, that’s normal. AWS feels overwhelming because cloud architecture is fundamentally about balancing competing constraints. That complexity is the point.

But once you stop asking “What does this service do?” and start asking “Why is this the best architectural decision for this situation?” the exam becomes much more manageable.

And honestly, that mindset shift is probably more valuable than the certification itself.