And yes — the notes are free.

Let me be upfront about what this post is and isn't.

This is not a "10 tips to pass AWS SAA" post written by someone who used three paid courses and a study partner. This is a first-person account of how I — a final-year MCA student from Kerala with no cloud background, no mentor, and no paid resources — passed the AWS Solutions Architect Associate exam.

Everything I used is free. Everything I did is repeatable. And I'm writing this because when I was preparing, I couldn't find a single guide that was actually honest about the process.

Why I Even Did This

I want to be clear about something upfront: I wasn't studying for the exam. I was studying to understand AWS. The exam was just the first checkpoint I set for myself on the way to becoming job-ready as a Cloud or SRE engineer.

That framing matters. It changed everything about how I prepared.

As for the timeline — I'll be honest. I booked the exam on February 13th because there was a 25% discount and a free retry offer that expired February 15th. I was tight on money and it was too good to pass up. So I booked it, which meant I had a hard deadline whether I wanted one or not.

Looking back, that was the single most right decision I made in that entire period. The deadline turned me into a more disciplined person than I'd ever been. Deadlines are underrated.

The Method — And Why It's Different

Most people preparing for SAA do one of two things: watch a full Udemy course from start to finish, or grind practice tests until they recognize answer patterns. I did neither.

I opened a ChatGPT project — I called it "career" — and I explicitly told it:

"My goal is not to pass an exam. My goal is to be production-level job-ready. Teach me AWS the way a real engineer needs to understand it."

That single instruction changed the quality of every conversation that followed.

Then I started from EC2 and worked through each service systematically. As I read and learned, I typed out questions in real time — whatever came to mind, whatever confused me. The key rule I set for myself: a question stays in the chat even if it gets answered three messages later. Those questions were my actual thought process made visible. They forced me to articulate what I didn't understand instead of skimming past it.

This became the notes repo you can see on my GitHub: github.com/ShownShaiju/aws-learning

13 days. One service per day. Written in my own words, not copy-pasted.

day-01 → EC2 fundamentals, instance families, pricing models
day-02 → Auto Scaling, launch templates, scaling policies
day-03 → Load Balancers — ALB vs NLB, multi-AZ design
day-04 → IAM — users, roles, policies, secure access patterns
day-05 → VPC — subnets, IGW, NAT Gateway, multi-AZ networking
day-06 → S3 + CloudFront — bucket policies, static hosting, CDN
day-07 → Lambda — execution model, cold starts, event-driven compute
day-08 → S3 lifecycle and storage classes — cost optimization
day-09 → RDS + DynamoDB — Multi-AZ vs Read Replicas, consistency models
day-10 → API Gateway — Lambda integration, routing models
day-11 → SNS, SQS, DLQ — messaging patterns, decoupling systems
day-12 → Route 53 + Global Accelerator — DNS, routing policies
day-13 → Elastic IP + ElastiCache (Redis) — static addressing, caching

Each file represents one focused learning session. Not a day of memorizing — a day of understanding how that service behaves inside real systems.

The Mock Test Situation (The Honest Version)

After the first week, I ran a quick mock on Gemini. Scored 3 out of 10.

I wasn't panicked. I still had topics to cover and I'd deliberately held off on practice tests for exactly this reason: if you take mocks before you understand the material, you stop learning and start memorizing answer patterns. That might help your score but it defeats the entire point if your actual goal is to become job-ready.

So I kept learning. Covered the remaining services. And only in the last 3 to 4 days before the exam did I shift to practice questions.

My approach in those final days:

• Do 20 questions at a time

• Every wrong answer — go back to the source, not just read the explanation

• Every question I got right by guessing — treat it as a wrong answer

The only external resource I added was the Tutorial Dojo free mock — widely regarded as the closest simulation to the real exam. I took it at midnight the night before.

It destroyed my confidence.

Tutorial Dojo has a category of questions that felt nothing like standard prep material — harder, more ambiguous, more like real architectural decision-making. I went to sleep that night genuinely unsure if I was ready.

I sat the exam the next morning anyway.

What the Exam Actually Felt Like

65 questions. 130 minutes. Most questions describe a real architecture scenario with specific constraints — cost, availability, latency, compliance — and ask you to pick the best solution from four plausible options.

The hardest part is eliminating the two obviously wrong answers quickly and then reasoning carefully between the remaining two. There's no trick. It's just: given these constraints, what's the right call?

There are also around 15 unscored questions mixed in — experimental questions that AWS is testing. You won't know which ones they are. You can get all 15 wrong and it won't affect your score. But you also won't know if you did.

When I walked out of the exam hall, I wasn't confident. Those hard questions had gotten to me and I genuinely didn't know.

That evening, I got the Credly badge email.

What AWS SAA Does NOT Teach You

I want to be honest about this because most certification posts skip it.

Passing SAA does not mean you can:

• Debug a CrashLoopBackOff in Kubernetes

• Configure an ALB with proper health checks in practice

• Understand what's actually happening when a pod OOMKills

The cert teaches you the what and when. It does not teach you the how of actually operating these systems under pressure. That gap only closes by building real things, breaking them, and fixing them.

I knew this going in. The certification was milestone one. The real work came after.

The Notes

The GitHub repo linked above has 13 days of condensed notes on core SAA concepts — written in plain language, no fluff. When I dropped the link as a reply in a Twitter thread, it pulled 103 link clicks and 37 bookmarks in a few days. I'm putting it here so it lives somewhere more permanent.

If you're preparing for SAA-C03, take it, use it, adapt it. That's why I wrote it down.

What I Did Next

After the cert, I started building — a full 5-tier cloud-native platform on Amazon EKS. That's where the real education began. Everything SAA taught me in theory, I started breaking and fixing in practice.

That story is the next post.

Spoiler: a lot went wrong.

Connect with me: LinkedIn · GitHub