Know what the AWS SAA exam asks you to do
The AWS Certified Solutions Architect (Associate), often called AWS SAA, is a proctored, timed test made up of multiple-choice and multiple-response questions. The questions use short architecture scenarios and requirements. You need to choose appropriate AWS services and patterns, interpret constraints such as security, high availability, disaster recovery, performance and cost, and identify the best option among plausible alternatives.
That last part matters. A service can be technically capable and still be the wrong answer if it adds unnecessary operational work, fails a stated availability requirement or costs more than a simpler design. Practise explaining why one option fits the requirements better than its nearest competitor—not just recalling service definitions.
The available exam information does not specify the current duration, question count, scoring details or appointment rules. Check the official AWS certification website and current exam guide for those details before booking. Do not build your study plan around figures from an old forum post or an unofficial practice test.
A useful way to review an architecture scenario is to trace the requirements, name the design, then check security, failure handling, performance and cost. The examiner strip below uses the platform's scenario-review emphases, not an official AWS marking scheme. A MySummaries examiner strip for this exam looks like this:
The strip shows the scenario-review emphases used by the platform's AWS SAA examiner persona.
Build a board from architecture patterns
Start with your own study material: the current exam guide, course notes, service documentation and notes from practice questions. Put the material you rely on into one revision board. Avoid copying whole chapters onto it. Each section should help answer a decision you may face in a scenario: what requirement triggers this design, which service fits, and what constraint rules out a tempting alternative?
Organise the board into related sections rather than a long glossary. For example, group a pattern with its security and failure considerations. Include a concise comparison when two services are often confused, and capture the exact conditions under which a choice changes. Keep links or source titles alongside notes so you can verify a detail when AWS changes a service or feature.
Here, the board uses a two-tier web application as a running example. A MySummaries board on this topic ends up looking like this:
- Application Load Balancer distributes HTTP/HTTPS requests across registered targets in multiple Availability Zones.
- Auto Scaling group spans AZs; set health checks and scaling policies to match workload behaviour.
- Place the ALB in public subnets and application instances in private subnets when the app does not need public instance addresses.
- Security groups are stateful and attached to resources such as ENIs; use narrow rules and security-group references where appropriate.
- Do not place database credentials in application code; retrieve secrets from AWS Secrets Manager and grant access with an IAM role.
Amazon RDS Multi-AZ provides a standby for availability and failover. A standard Multi-AZ DB instance standby is not a read-scaling endpoint; use a read replica when the requirement is read scaling.
Amazon CloudFront can cache content at edge locations. Amazon Route 53 can route DNS queries using policies such as failover or weighted routing; choose the policy that matches the stated need.
- NAT gateway lets instances in a private subnet initiate IPv4 connections to the internet; it does not allow unsolicited inbound internet connections.
- For AZ resilience, consider a NAT gateway in each AZ and route each private subnet through its local gateway.
The board connects a two-tier application design to the network, database and security decisions that affect it.
Reduce each topic to decisions you must not miss
For each board section, make a short core checklist. This is not a replacement for understanding the design; it is a quick test of whether you remember its important boundaries. If you cannot explain why a rule applies, return to the source material and add the missing reasoning to your notes.
For the running web application example, the core can be stated as four checks. A MySummaries core checklist cut from the board looks like this:
The core is a four-point check of availability, subnet placement, database purpose and outbound routing.
Practise scenario questions by tracing the constraint
Use a consistent sequence for every practice question. First identify the required outcome: for example, “survive an AZ failure”, “allow private instances to download updates” or “serve a large read workload”. Then underline constraints that narrow the design: existing operating systems, latency, data sensitivity, recovery needs, limited operational capacity or a cost ceiling. Next map the outcome to a service or pattern, and check whether the option actually satisfies the constraint.
Finally, compare the best-looking alternatives. Ask what each one does not provide. A NAT gateway is not a way to accept unsolicited inbound internet traffic. A Multi-AZ database setup is not automatically a read-scaling solution. A highly available design is not necessarily the lowest-cost design. The question's wording determines which trade-off is acceptable.
Practise multiple-response questions with particular care: assess each option against the stated requirements rather than stopping when you find one correct-sounding service. After answering, record the reason you chose the right option and the exact misconception behind the strongest distractor. A mistake log such as “confused failover with read scaling” gives you a useful revision task; “need more AWS” does not.
Practise writing a short architecture answer
The exam is multiple-choice and multiple-response, not an oral examination. Still, writing a compact design before looking at answer choices can expose whether you understand the scenario or are recognising familiar product names. Use headings such as Requirements, Proposed Architecture, Security, Reliability, Performance and Cost. Under each, write only the decisions relevant to the case.
For instance, consider a public web application that must tolerate an Availability Zone failure, keep its database off the public internet and scale its web tier. A MySummaries marked answer on this scenario looks like this:
A public web application runs on Amazon EC2 and uses an Amazon RDS database. It must continue serving requests after an Availability Zone failure, scale its web tier with demand and keep the database inaccessible from the internet. Propose an architecture.
3/4Put an Application Load Balancer in public subnets across two Availability Zones and an Auto Scaling group of EC2 instances in private subnets. Use an RDS Multi-AZ deployment for database failover. The instances can reach the database over the VPC, and the ALB sends traffic to the application tier.
The answer maps the main availability and scaling requirements to appropriate services and keeps EC2 instances out of public subnets. It does not state how inbound and database traffic are restricted, or how instances obtain outbound access if required.
Missed
−State that the database is in private subnets and its security group permits the database port only from the application security group.
−If instances need internet egress, specify a NAT gateway route from the private subnets; do not imply the ALB provides outbound access.
Model answerUse an internet-facing Application Load Balancer in public subnets across at least two Availability Zones, with an EC2 Auto Scaling group in private subnets across those zones. Configure target health checks and scaling to match the workload. Place RDS in private subnets with Multi-AZ enabled for availability and failover. Allow the database port only from the application security group, and use an instance IAM role for AWS access rather than embedded credentials. If application instances need outbound IPv4 access, route through NAT gateways; consider one per AZ for egress resilience. This design adds managed components and possible NAT costs, so confirm they fit the stated requirements.
That is a MySummaries paper, filled with AWS SAA material. Yours is written from your own notes. Start free
The marked answer shows a solid design that loses a point for leaving traffic boundaries and egress unspecified.
Read the marker's reasoning and compare it with your own. A common weakness in scenario answers is naming the correct service without stating the setting or boundary that makes it fit. “Use a database security group” is less useful than saying which source it permits. “Make it highly available” is less precise than naming the AZ-spanning resources and the failover mechanism.
Turn errors into focused revision
Review your mistake log by cause, not only by service name. Sort errors into categories such as misunderstood requirement, wrong service fit, missing security boundary, availability confused with recovery, or cost trade-off overlooked. Revisit the relevant board section, check the source, then answer a fresh question that tests the same decision. Do not simply memorise the answer to the question you missed.
A useful revision loop is: answer a question, explain the choice in one or two sentences, compare it with the requirement, and add the unresolved fact to the board. Turn facts that need repeated recall into flashcards—for example, the difference between a NAT gateway and an internet gateway, or between RDS Multi-AZ availability and read replicas. Review those cards on later days rather than rereading the entire board each time.
Use practice tests to find gaps, not as a prediction of the real question set. If a practice resource gives an explanation that conflicts with current AWS documentation, verify the detail. Service features and exam guidance can change, so keep your source material current.
Listen to a decision explained
Audio review is useful when you want to rehearse a pattern away from a screen, but it should reinforce a design you have checked—not substitute for verification. A short explanation can follow one scenario from its availability requirement to the service choice, then point out the tempting alternative that fails a constraint. A MySummaries lecture generated from the board might sound like this:
Transcript · tap any word to jump there
Start with the failure the scenario requires you to tolerate. If the requirement is an Availability Zone failure, distributing application targets across zones is not enough by itself: the traffic entry point and the scaling design must also support targets in more than one zone. An Application Load Balancer can send requests to healthy registered targets, while an Auto Scaling group can replace unhealthy EC2 instances and maintain the intended capacity.
Next check the network boundary. An internet-facing load balancer can receive public traffic while application instances stay in private subnets. If those instances need to initiate internet connections, a NAT gateway can provide outbound IPv4 access; it is not an inbound entry point. For resilience to a gateway's AZ failure, consider the route and NAT placement in each AZ rather than treating one gateway as a multi-AZ service.
Then read the database requirement literally. RDS Multi-AZ supports availability and failover, while a standard Multi-AZ DB instance standby is not a read-scaling endpoint. If the scenario needs more read capacity, look for a read-replica requirement instead. Finish by checking security groups, IAM access and the cost of extra resilient components against the requirements.
The lecture traces an AZ-resilience requirement through the web tier, subnet boundaries and database choice.
How MySummaries helps
Build a revision board from your own AWS notes and reference material, then use it to generate recall cards, written practice and examiner-voice audio. For this task, that means keeping architecture decisions and their constraints together, reviewing facts you repeatedly miss, and practising concise scenario reasoning. Explore MySummaries.