AWS Certified Solutions Architect - Associate cheat sheet
Amazon Web Services
Free to share. Examworthy is not affiliated with or endorsed by Amazon Web Services; SAA-C03 and related marks belong to their respective owners.
At a glance
Format: Multiple choice and multiple response
Domain weight map
Heaviest first - spend your time hereHow this exam thinks
SAA-C03 is a pick-the-right-design exam: almost every question is a scenario with security, resilience, performance, and cost constraints, and the right answer is the managed AWS service or pattern that satisfies all of them with the least operational overhead.
Spot the trap
Tempting wrong answers, and why they failTempting but wrong
Putting an IAM user's access key and secret in EC2 user data at launch removes static credentials from an application.
Why it fails
User data still injects a long-lived static key that can leak. Relocating the key does not remove it. Use an IAM role via an instance profile so credentials are temporary and rotated automatically.
Design Secure Architectures
Tempting but wrong
An Application Load Balancer with connection draining will queue surplus requests until a worker is free, so no orders are lost during a spike.
Why it fails
An Application Load Balancer distributes synchronous requests but does not durably buffer them. When no healthy target can respond, requests time out and orders are still lost. Durable buffering needs Amazon SQS, not a load balancer.
Design Resilient Architectures
Tempting but wrong
Enabling Amazon S3 Versioning spreads request load and raises the per-prefix throughput ceiling.
Why it fails
S3 Versioning keeps prior copies of an object for recovery. It does not change how S3 partitions request capacity by prefix, so the throughput ceiling on a hot prefix is unchanged. To raise throughput, distribute keys across multiple prefixes.
Design High-Performing Architectures
Tempting but wrong
Keeping everything in S3 Standard and relying on volume discounts as the bucket grows minimises cost for unpredictable access.
Why it fails
S3 Standard applies the full frequent-access price to every object, including cold ones that are rarely read. Volume discounts do not change that per-GiB rate enough to optimise a mix of hot and cold data. S3 Intelligent-Tiering moves each object to a cheaper tier automatically when it cools.
Design Cost-Optimized Architectures
Tempting but wrong
Attaching an IAM role with AdministratorAccess to EC2 is fine as long as it avoids stored keys.
Why it fails
The role does remove static keys, but AdministratorAccess grants far more than the read access needed and badly violates least privilege. Scope the role policy to s3:GetObject on the specific bucket only.
Design Secure Architectures
Tempting but wrong
Publishing each order to an Amazon SNS topic with every worker subscribed lets the fastest worker process it while the others ignore it.
Why it fails
Amazon SNS pushes a copy of each message to every subscriber, so all workers would process the same order rather than sharing the load. SNS also does not buffer messages for slow consumers to pull later. A pull-based Amazon SQS queue is what hands each order to one worker.
Design Resilient Architectures
Tempting but wrong
Switching an Amazon S3 bucket to the Intelligent-Tiering storage class lets frequently accessed objects serve a higher request rate.
Why it fails
S3 Intelligent-Tiering moves objects between access tiers to optimise storage cost. All tiers share the same per-prefix request model, so it does not lift the throughput limit on a hot prefix. Spreading keys across prefixes is what raises the request rate.
Design High-Performing Architectures
Tempting but wrong
Putting all objects in S3 Standard-Infrequent Access on upload is the cheapest way to store data with unpredictable access.
Why it fails
Standard-IA has a lower storage rate but charges a per-gigabyte retrieval fee on every read. Objects downloaded many times in the first week would rack up retrieval charges, which is exactly what a no-retrieval-fee requirement forbids. S3 Intelligent-Tiering avoids retrieval fees entirely.
Design Cost-Optimized Architectures
Key terms
Exam-day rules
- Read the scenario for its constraint first. The security, availability, performance, or cost limit named in the question is what picks the answer, so find it before you judge the options.
- When two services both work, default to the managed, least-overhead one. AWS prefers managed services and well-architected defaults; reach for the manual option only when the scenario names a reason such as an existing engine to preserve.
- Treat broad permissions as a wrong answer. Any option granting AdministratorAccess or embedding long-lived keys is the trap; least privilege through a scoped IAM role almost always wins the security questions.
- Let the access pattern pick storage and databases. Shared file access means EFS, object means S3, key-value at scale means DynamoDB, relational that idles means Aurora Serverless v2; do not default to the service you know best.
- Watch the cost-versus-durability trap. When a question stresses lowest cost but the data is irreplaceable or must survive a zone failure, the cheapest class (One Zone-IA) is usually the wrong answer; Standard-IA is the fit.
Revision schedule
- Day 1Map the blueprint and book a date
- Week 1Build the service-selection maps
- Weeks 1 to 3Go deep on secure and resilient design (Domains 1 and 2)
- Weeks 3 to 4Lock storage, database, and performance selection (Domain 3)
- Week 4Cover cost optimisation and its traps (Domain 4)