Let's Connect

A developer's screen with code and an AWS architecture diagram, representing studying for the AWS Solutions Architect Associate exam

My AWS Solutions Architect Associate study plan had to survive a full-time job, so I built it around four things and cut everything else: a structured video course for coverage, the official SAA-C03 exam guide to scope the domains, hands-on labs in a free-tier account, and timed practice exams until I was consistently above the pass mark. The single biggest mistake I see is treating this as a memorization exam. It is not. It is a pick-the-best-trade-off exam, and the only way I made the trade-offs stick was by building the services with my own hands, breaking them, and paying the small bills that follow. Reading about an S3 bucket policy taught me nothing. Locking myself out of my own bucket taught me everything.

What does the SAA-C03 actually test?

Before watching a single video I downloaded the official exam guide PDF from the AWS certification page and read it end to end. That document is the contract: it lists the four domains and, more usefully, their weighting. For SAA-C03 the split is Design Secure Architectures at 30%, Design Resilient Architectures at 26%, Design High-Performing Architectures at 24%, and Design Cost-Optimized Architectures at 20%. I let those percentages decide how I spent my evenings. Security and resilience are more than half the exam, so IAM, VPC design, and multi-AZ failover got the most hours. I did not waste a week memorizing every EC2 instance family when cost optimization is a fifth of the questions.

The whole exam is framed through the AWS Well-Architected Framework. Once I internalized its pillars (operational excellence, security, reliability, performance efficiency, cost optimization, and sustainability), the questions stopped looking like trivia and started looking like the design reviews I already do at work. A question is almost always asking: given this constraint, which pillar does the scenario prioritize, and which service satisfies it without over-building?

Why hands-on labs were the part that actually stuck

Video courses are passive. You nod along, the instructor makes it look obvious, and three days later you cannot remember whether an S3 bucket policy or an IAM policy is the right tool for cross-account access. The fix is to open a terminal and do it. I ran every core lab in a dedicated free-tier account that I treated as disposable, with a strict billing alarm so a forgotten NAT gateway or an idle RDS instance could not quietly cost me money. That billing alarm is itself a lesson the exam tests.

The labs I forced myself to do by hand, not just watch:

  • Launch an EC2 instance into a public subnet, then into a private subnet behind a NAT gateway, and prove the difference by trying to curl the internet from each.
  • Write an S3 bucket policy that denies any request not using TLS, then lock myself out and recover by editing the policy as the bucket owner.
  • Build a VPC from scratch (CIDR, two AZs, public and private subnets, route tables, internet gateway) instead of using the default VPC, so route tables stopped being magic.
  • Stand up an RDS instance with Multi-AZ enabled, trigger a reboot-with-failover, and watch the endpoint stay the same while the standby is promoted.
  • Attach an IAM role to an EC2 instance and read an S3 object from it with zero hardcoded keys, which is the single most-tested security pattern on the exam.

That last one matters far beyond the exam. The instinct to bake an access key into a config file is exactly the habit AWS wants you to unlearn, and it is the habit that leaks credentials in production. If you are setting up your first instance properly, the workflow I describe in AWS EC2 for beginners maps directly onto what the SAA expects you to know about instance roles and security groups.

A laptop showing dashboards and metrics, representing tracking practice exam scores while studying for the AWS Solutions Architect Associate
I tracked every practice-exam attempt in a spreadsheet and only booked the real exam once I cleared 85% on fresh question sets twice in a row.

How I used the free tier without getting a surprise bill

The free tier is generous but full of traps, and the SAA exam quietly tests whether you know where the meter is running. A NAT gateway is not free and bills per hour plus per GB. An Elastic IP that is allocated but not attached to a running instance is billed. An RDS Multi-AZ deployment doubles your instance cost. I set a budget alarm the moment I created the account so I would learn these the cheap way rather than on a client's invoice. Here is the exact CloudWatch billing alarm I used, created from AWS CLI v2.

create-billing-alarm.sh
# Billing metrics live only in us-east-1, so target that region
# regardless of where your resources are.
aws cloudwatch put-metric-alarm \
  --region us-east-1 \
  --alarm-name "free-tier-spend-over-10-usd" \
  --namespace "AWS/Billing" \
  --metric-name "EstimatedCharges" \
  --dimensions Name=Currency,Value=USD \
  --statistic Maximum \
  --period 21600 \
  --evaluation-periods 1 \
  --threshold 10 \
  --comparison-operator GreaterThanThreshold \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:billing-alerts

Before that works you have to enable billing alerts in the Billing console preferences once, otherwise the AWS/Billing metric never publishes. I also tore everything down at the end of each study session with a quick check for the resources that bill silently.

end-of-session-teardown.sh
# Find unattached Elastic IPs (these bill while idle).
aws ec2 describe-addresses \
  --query "Addresses[?AssociationId==null].PublicIp" \
  --output text

# List running instances so nothing is left on overnight.
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" \
  --query "Reservations[].Instances[].[InstanceId,InstanceType]" \
  --output table

Learning where AWS bills you is not a side quest for this exam, it is a whole domain. The same instincts feed straight into real work; my notes on reducing your AWS bill came directly out of the cost-optimization habits I built while studying.

How many practice exams is enough?

Practice exams are where you convert knowledge into the specific skill of reading AWS questions, which are deliberately wordy. I did not book the real exam until I scored above 85% on fresh question sets twice in a row, not on sets I had already seen and half-memorized. The goal of a practice exam is not the score, it is the review afterward. For every question, right or wrong, I wrote one sentence on why the correct answer was correct and why each distractor was wrong. That review is where the learning happens.

Reading the question carefully is its own skill because the qualifier word changes the entire answer:

  • "Most cost-effective" means the cheapest option that still meets the stated requirement. It often points at S3 Glacier, Spot Instances, or a single-AZ setup. Do not pick the gold-plated answer.
  • "Most resilient" or "highly available" means spend more to survive failure. This points at Multi-AZ, Auto Scaling across AZs, and cross-region replication.
  • "Least operational overhead" pushes you toward managed and serverless services (RDS over self-managed databases on EC2, Lambda over a cron box).
  • "Real-time" versus "can tolerate delay" decides between synchronous processing and a queue like SQS.
The exam is rarely asking which answer works. Usually three of the four work. It is asking which one fits the qualifier in the question, and the qualifier is one word you can miss if you skim.Md Raihan Hasan

What are the exam-day tactics that worked?

You get 130 minutes for 65 questions, which is enough time only if you do not get stuck. My discipline was simple: read the question, then read the answers, then eliminate. On almost every question I could strike two answers immediately because they violated the qualifier (a single-AZ answer when the scenario demanded resilience, or an over-engineered answer when it demanded cheap). That turns a four-way guess into a coin flip at worst, and usually into a clear winner.

If a question made me think for more than ninety seconds, I flagged it and moved on. There is a review screen at the end and the flagged questions are listed there. A surprising number of later questions jogged my memory on earlier ones, so I came back to the flagged set with answers I did not have on the first pass. I never left a question blank because there is no penalty for a wrong answer, so a guess on a flagged question is strictly better than nothing.

Did the certification actually help on the job?

Honestly, it helped in specific ways and not in others, and I would rather tell you the truth than sell the cert. What it gave me was a mental map of the service catalog. Before the SAA I reached for EC2 for everything. After it, I knew when SQS decouples a fragile synchronous flow, when CloudFront belongs in front of S3, and when an Auto Scaling group across AZs is the honest answer instead of a bigger instance. It made me faster at the design-review conversation because I now share the vocabulary the rest of the team uses.

What it did not do is make me an expert operator. The exam does not teach you to debug a 3am production incident, tune an RDS slow query, or untangle a real VPC peering mess across accounts. Those came from doing the work, and from putting a real system into production. The architecture I actually run, with the trade-offs the exam only gestures at, is in my write-up on deploying Laravel on AWS. The cert was the map. The territory I learned by walking it.

If you are starting, do this in order: read the exam guide to scope the domains, watch a course once at normal speed for coverage, then spend the bulk of your time in a free-tier account building the resilient, secure, and cost-aware patterns you will be tested on. Drill timed practice exams until 85% is boring, watch the qualifier words, and flag-and-return on exam day. Treat the certificate as proof you can reason about trade-offs, not proof you can run production. Earn the second one at work.