The AWS Certified Solutions Architect - Associate (SAA-C03) tests whether you can design systems on AWS that are secure, resilient, high-performing, and cost-effective. It is not a memorisation exam. Almost every question is a short scenario with several workable-looking answers, and the skill being tested is judgement: reading the scenario for its real priority and choosing the design that best serves it. The fastest route to passing is to learn each service hands-on in a free-tier account and to view every choice through the lens of the AWS Well-Architected Framework, which is effectively the rubric behind the “best” answers. This guide is a full self-study course organised around the four official design domains. It explains the concepts and the trade-offs, shows where candidates lose marks, and turns the material into a plan. It is original teaching material only. It contains no real or simulated exam questions, and you should confirm the current weights and rules against AWS’s own Solutions Architect Associate exam guide before booking.
Chapter 1: Exam overview and how to use this guide
What the SAA actually measures
The SAA measures whether you can design solutions using AWS services to meet a set of requirements, weighing security, reliability, performance, and cost against one another. AWS recommends at least a year of hands-on experience designing solutions on AWS before attempting it, which signals the level: this is an intermediate, judgement-heavy exam, not an introduction to the cloud. The most important planning fact is the domain split. AWS organises the scored content into four domains with fixed weights: Design Secure Architectures at 30%, Design Resilient Architectures at 26%, Design High-Performing Architectures at 24%, and Design Cost-Optimized Architectures at 20%. Those weights are remarkably even, which tells you something important: no domain can be skipped, and security, although the largest, is only slightly ahead of the others. Spread your effort broadly rather than betting on a favourite area.
The exam is 65 questions in 130 minutes, delivered as multiple-choice (one correct answer) and multiple-response (select two or more) questions. Only 50 of the 65 are scored; the other 15 are unscored questions AWS is trialling, and they are not identified, so you answer every question as if it counts. Results are reported as a scaled score from 100 to 1,000, and the pass mark is 720. Because the score is scaled across questions of varying difficulty, do not try to convert 720 into a fixed percentage; aim to be answering confidently across all four domains on fresh questions.
The Well-Architected Framework is the rubric
The single most useful mental model for this exam is the AWS Well-Architected Framework, a set of design pillars that AWS uses to define good architecture: operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability. The four exam domains map directly onto the middle four pillars, which is no accident. When a question offers several designs that would all technically work, the “best” answer is the one that best satisfies the relevant pillars for the stated priority. Internalising the pillars turns vague scenarios into a structured choice.
How to use this course
Read the chapters in order. Chapters 2 to 5 work through the four domains, each explaining the key services, the design patterns, and the trade-offs the exam tests. Chapter 6 explains the scenario technique that ties them together, Chapter 7 turns the content into a timeline built around hands-on practice, and Chapter 8 covers final preparation and exam day. The bold terms are a checklist: by the end you should be able to say what each service is, and, more importantly, when you would choose it over the alternatives. Short worked examples appear where a trade-off is easy to misread, but none of them are exam questions.
Chapter 2: Design Secure Architectures (30%)
This is the largest domain. Its through-line is controlling access and protecting data: who or what can reach a resource, whether that access is the minimum necessary, and whether data is protected both at rest and in transit. The strong instinct to build is to ask, for any design, “who can access this, and is it least privilege?”
Secure access with IAM
AWS Identity and Access Management (IAM) is the foundation, and you need it in genuine depth for this exam. The building blocks are users, groups, roles, and policies. The most important architectural idea is the IAM role: a set of permissions that can be assumed temporarily, which is how you grant access without long-lived credentials. An EC2 instance gets permissions through an instance profile wrapping a role; one AWS service acts on another’s behalf by assuming a role; a user in one account accesses another account through a cross-account role. Policies come in flavours the exam distinguishes: identity-based policies attach to users, groups, or roles, while resource-based policies (such as an S3 bucket policy) attach to the resource and specify who may use it. Over it all sits least privilege: grant only the actions and resources genuinely required. As a teaching example of the pattern the exam rewards: an application on EC2 that needs to read one S3 bucket should be given a role with read access scoped to that bucket, not broad S3 access and certainly not hard-coded keys.
Secure network design
The second pillar of security is the network, built on the Virtual Private Cloud (VPC). Within a VPC you place subnets, designating them public (with a route to an internet gateway) or private (no direct inbound internet path). Two firewall mechanisms work together and are frequently contrasted: security groups are stateful firewalls attached to instances, where return traffic for an allowed connection is automatically permitted, while network ACLs (NACLs) are stateless firewalls at the subnet level, where you must allow both directions explicitly. For private resources that need outbound internet access (to fetch updates, say) without being reachable from outside, a NAT gateway in a public subnet provides one-way egress. To reach AWS services privately without traversing the internet, VPC endpoints keep traffic on the AWS network. The recurring exam pattern is a tiered design: a public-facing load balancer in public subnets, application and database servers in private subnets, and tightly scoped security groups between the tiers. Holding the stateful-versus-stateless distinction between security groups and NACLs clearly is one of the most reliable ways to answer network-security questions.
Data protection
The third pillar is protecting the data itself. The expected default is encryption at rest and encryption in transit, with AWS KMS (Key Management Service) managing the keys. You should know that most storage and database services integrate with KMS so that encryption is largely a configuration choice, that you can use AWS managed keys or customer managed keys (the latter giving control over rotation and access policy), and that data in motion is protected with TLS. Recognise supporting services by purpose too: AWS Secrets Manager for storing and rotating credentials, AWS Certificate Manager for TLS certificates, and AWS WAF and AWS Shield for protecting web applications against malicious traffic and DDoS. The exam’s instinct is that sensitive data should always be encrypted and that access to the keys is itself an access-control decision.
Chapter 3: Design Resilient Architectures (26%)
This domain is about designing systems that survive failure gracefully, the second-largest slice of the exam. The unifying idea is to assume that components will fail and to design so that a failure degrades rather than topples the system. Two patterns dominate: spreading workloads across Availability Zones for high availability, and decoupling components so they fail independently.
High availability across Availability Zones
The foundation of resilience on AWS is the Availability Zone (AZ): isolated data centres within a Region that fail independently. A highly available design spans multiple AZs so the loss of one does not take the application down. In practice this means putting instances in several AZs behind Elastic Load Balancing, which distributes traffic and stops sending it to unhealthy targets, and using Auto Scaling groups to replace failed instances and adjust capacity to demand. For data, managed services offer Multi-AZ deployments: an RDS database can run a standby in another AZ and fail over automatically, while S3 stores objects redundantly across AZs by default. The exam draws a useful line between high availability (quick recovery from failure, typically via redundancy across AZs) and fault tolerance (continuing to operate through a failure with no interruption), and a scenario’s wording about acceptable downtime tells you which it wants. As a teaching example: a requirement that the application “remain available if an Availability Zone fails” points to instances spread across at least two AZs behind a load balancer, with Auto Scaling maintaining the desired count.
Decoupling for resilience
The second resilience pattern is decoupling: connecting components through intermediaries so they do not depend on each other being available at the same moment. Amazon SQS provides message queues that buffer work between a producer and a consumer, so if the consumer slows or fails, messages wait safely rather than being lost, and the producer is unaffected. Amazon SNS provides publish/subscribe messaging, fanning a message out to many subscribers at once. Amazon EventBridge routes events between services based on rules. The architectural payoff is that decoupled components scale and fail independently, which is why the exam so often prefers a queue-based or event-driven design over tightly coupled synchronous calls. The classic contrast worth holding: SQS is a pull-based queue for point-to-point work distribution, while SNS is push-based fan-out to multiple subscribers.
Backups, recovery, and multi-Region
Resilience also means being able to recover. You should understand backups and snapshots (point-in-time copies of volumes and databases), the role of S3 versioning and lifecycle in protecting and retaining data, and, at a high level, disaster-recovery strategies that trade cost against recovery speed, from simple backup-and-restore through to multi-Region designs. The two terms the exam uses to frame this are RTO (recovery time objective), how quickly you must recover, and RPO (recovery point objective), how much data loss is acceptable. A stricter RTO or RPO justifies a more redundant and more expensive design, and matching the strategy to the stated objectives is the judgement being tested.
Chapter 4: Design High-Performing Architectures (24%)
This domain is about choosing services and configurations that meet performance requirements as load grows, and it is fundamentally a matching exercise: given a workload, select the compute, storage, database, and delivery options that fit. The exam rewards knowing not just what each service does but when it is the right tool.
Performant and elastic compute
On compute, the choice is about matching the execution model to the workload. Amazon EC2 suits long-running or specialised workloads where you want control, with instance families optimised for compute, memory, or other needs. AWS Lambda suits short, event-driven, spiky workloads, scaling automatically with no servers to manage. Containers on ECS or EKS, optionally serverless with Fargate, suit applications packaged for portability and fine-grained scaling. The performance lever common to EC2 and containers is Auto Scaling, which adds capacity as demand rises so performance holds under load. The instinct the exam rewards is elasticity: prefer designs that scale out automatically to meet demand over fixed capacity sized for a guessed peak.
Storage and database performance
On storage, performance and access pattern drive the choice between S3 (massively scalable object storage), EBS (block storage for a single instance, with volume types tuned for throughput or IOPS), and EFS (shared file storage across many instances). On databases, the relational-versus-non-relational decision recurs: RDS and Aurora for structured, relational data with complex queries (Aurora offering higher performance and scaling), and DynamoDB for key-value access at massive scale with single-digit-millisecond latency. To scale read performance specifically, two levers appear constantly: read replicas offload read traffic from a primary database, and caching with Amazon ElastiCache (Redis or Memcached) or DynamoDB Accelerator (DAX) keeps hot data in memory. As a teaching example of matching to the requirement: a read-heavy application straining a relational database is a classic case for adding read replicas or a cache, rather than simply scaling the instance up.
Content delivery and networking performance
Finally, getting data to users quickly is its own concern. Amazon CloudFront is the content-delivery network that caches content at edge locations close to users, cutting latency for static and dynamic content alike. Amazon Route 53 provides DNS with routing policies (such as latency-based or geolocation routing) that send users to the best endpoint. For very high or specialised throughput needs you might recognise AWS Global Accelerator for routing over the AWS backbone. The pattern the exam likes is pushing content and routing decisions toward the edge so users are served from somewhere near them.
Chapter 5: Design Cost-Optimized Architectures (20%)
This is the smallest domain, but it offers some of the most reliable marks once you know the cost levers, because the decisions are concrete. It is about meeting the requirements at the lowest sensible cost: choosing the right pricing model, the right storage tier, and right-sized resources, and avoiding waste.
Pricing models for compute
The EC2 purchasing options are the headline cost lever, and the exam tests matching them to usage patterns. On-Demand is flexible with no commitment, suiting unpredictable or short-term workloads. Reserved Instances and Savings Plans give substantial discounts in exchange for a one- or three-year usage commitment, suiting steady, predictable baseline load. Spot Instances offer the deepest discount using spare capacity but can be reclaimed at short notice, suiting fault-tolerant, flexible, or batch workloads that can absorb interruption. The instinct the exam rewards is to map the model to the workload: commit (Reserved or Savings Plans) for the steady baseline, use On-Demand for variable peaks, and use Spot for interruptible work. A common cost-optimised design blends them, with reserved capacity for the baseline and Spot or On-Demand for bursts.
Cost-effective storage
Storage cost optimisation centres on S3 storage classes and lifecycle policies. Data that is accessed often belongs in Standard; data accessed rarely belongs in an infrequent-access class; data that is archival belongs in a Glacier class, which is far cheaper but slower to retrieve. S3 Intelligent-Tiering moves objects between tiers automatically based on access patterns, which suits data whose access is unpredictable. Lifecycle policies automate the transition of objects to cheaper tiers and their eventual expiry. The exam pattern is to match the storage class to how often and how quickly data must be accessed, paying for retrieval speed only where it is actually needed. As a teaching example: logs that must be kept for compliance but are rarely read are a textbook case for a lifecycle policy that transitions them to an archival class after a set period.
Right-sizing and cost visibility
The final piece is eliminating waste through right-sizing, matching instance and resource sizes to actual utilisation rather than over-provisioning, and through visibility. You should recognise AWS Cost Explorer for analysing past spend, AWS Budgets for alerting on cost or usage thresholds, and AWS Trusted Advisor and Compute Optimizer for recommendations that surface idle or oversized resources. Serverless and managed services contribute to cost optimisation too, because paying only for what you use (as with Lambda) can be cheaper than running idle servers. The judgement the exam tests is choosing the lowest-cost option that still meets the security, reliability, and performance requirements, never cost in isolation.
Chapter 6: The scenario technique that ties it together
The four domains are the content, but passing depends on a method for the scenario questions, because almost every question presents several designs that would technically work and asks for the best one. This chapter is that method.
Read for the binding requirement
The decisive habit is to read each scenario to the end and pin down its binding requirement: the one priority the question is really testing. Scenarios are written so that more than one option is workable, but only one is best for the stated priority, and the wording almost always reveals which it is. Phrases like “most cost-effective”, “highest availability”, “lowest latency”, “least operational overhead”, or “most secure” are not decoration; they are the rubric. Once you have identified the binding requirement, strike out any option that violates it, even if it would otherwise be a fine design, and among what remains choose the one that best fits the relevant Well-Architected pillars. As a teaching example of how the same scenario can have different best answers: a workload described as needing the lowest cost and able to tolerate interruption points toward Spot, whereas the same workload described as needing guaranteed availability points away from Spot and toward On-Demand or reserved capacity. The facts are identical; the binding requirement decides.
Watch for operational overhead and managed services
A second, quieter pattern runs through the exam: AWS generally prefers managed services and designs with less operational overhead. When two options achieve the same outcome but one offloads more work to AWS (a managed database over a self-run one on EC2, a serverless option over a server you must patch and scale), the managed option is usually the intended answer, especially when the scenario mentions minimising administrative effort. Recognising this saves you on many questions where both designs would function.
Build the habit on practice questions
This technique is a skill, and like any skill it has to be practised. Drill it on scenario questions throughout your study, not just at the end, and each time make yourself name the binding requirement out loud before choosing. Training this judgement matters as much as knowing the services, because the services alone will leave you stuck between two plausible answers.
Chapter 7: Study plan and timeline
With the content and the technique understood, the work is pacing them, and the non-negotiable here is hands-on practice. Design judgement comes from building, so a plan that is all reading will not prepare you for the scenarios.
Pair every topic with the console
Spend your hours roughly in proportion to the domain weights, which are even enough that all four matter, with a little extra on security as the largest. But the structural rule is to pair every topic with hands-on work in a free-tier account: build a VPC with public and private subnets, launch instances behind a load balancer with Auto Scaling, create an S3 bucket and apply a lifecycle policy, stand up an RDS database with Multi-AZ, wire two components together with an SQS queue. Building these makes the trade-offs intuitive in a way reading cannot, and it is what turns a memorised service list into the judgement the exam rewards.
Choose a timeline
A balanced default is around ten weeks at six to eight hours a week, including labs. A workable sequence is: weeks one to two on AWS fundamentals and the Well-Architected pillars while setting up your account; weeks three to five on compute, storage, databases, and networking (the high-performing and resilient material), building as you go; weeks six to eight on security in depth, with IAM, VPC firewalls, and encryption; week nine on cost optimisation and consolidating weak areas with mini-projects; and week ten on full-length timed practice. Someone with real cloud experience can compress to a four-week intensive at around fifteen hours a week, building daily and moving quickly to mocks. Someone newer to AWS should stretch to a twelve-week steady plan at around five to six hours a week, starting from Cloud Practitioner-level basics. To turn whichever timeline you pick into dated weeks for your own start date, use the free study-plan generator. If you are still deciding between AWS and Azure for this step, the AWS SAA vs Azure AZ-104 comparison covers the trade-off.
Practise scenarios throughout
Move from learning services to answering scenario questions as soon as you have covered a domain, and keep a steady diet of them through the middle of the plan. The exam is judgement under realistic constraints, so the habit of reading for the binding requirement and choosing the Well-Architected fit has to be built over weeks, not crammed at the end.
Chapter 8: Final preparation, exam day, and format
Final preparation
In the last week or two, shift from building new things to sitting full-length, timed practice exams and consolidating. Treat each mock as a diagnosis rather than a score: for every question you miss, go back to why the right answer was right and why your choice failed the binding requirement. Cost optimisation is the domain where many candidates leak marks, so watch it specifically, and revisit the Well-Architected pillars, the IAM and VPC security patterns, the multi-AZ and decoupling patterns, and the pricing and storage-class levers. Aim to be scoring comfortably above 720 on fresh questions before you book, and stop adding new services once you are there; the final days are for consolidation, not expansion.
Exam day and format
On the day, the exam is 65 questions in 130 minutes, taken at a Pearson VUE (or PSI) test centre or through online proctoring, with valid government-issued identification required. The questions are multiple-choice (one correct answer) and multiple-response (select the number stated), and you can flag questions and return to them, so pace yourself and revisit the hard ones rather than stalling. Remember that 15 of the 65 questions are unscored and unmarked, so answer everything normally. Apply the method you practised on every question: read to the end, name the binding requirement, eliminate the options that break it, and choose the design that best fits the Well-Architected pillars, leaning toward the managed, lower-overhead option when two designs are otherwise equal. Rest the day before rather than cramming, because this exam rewards clear judgement over recall, and the hands-on weeks you put in are exactly what make that judgement feel natural under the clock.