AWS SAA-C03 Cheat Sheet 2026

Storage decision tree

• Need a shared file system across multiple EC2 instances (Linux)? → EFS.
• Need a shared file system, Windows-native? → FSx for Windows File Server.
• Block storage attached to a single EC2 instance? → EBS — then pick gp3 (general purpose), io2 (high IOPS, mission-critical databases), st1 (throughput-heavy, big sequential reads), or sc1 (cold, infrequent access, cheapest).
• Object storage, accessed frequently? → S3 Standard.
• Object storage, access pattern unknown or changing? → S3 Intelligent-Tiering.
• Object storage, accessed rarely but needed fast when it is? → S3 Standard-IA or One Zone-IA (One Zone if you can tolerate losing an AZ's copy).
• Archival, retrieval in minutes to hours acceptable? → S3 Glacier Flexible Retrieval or Glacier Instant Retrieval.
• Archival, retrieval in hours is fine, lowest possible cost? → S3 Glacier Deep Archive.

Database decision tree

• Relational, need automatic failover with zero data loss? → RDS Multi-AZ (or Aurora, which has its own faster replication model).
• Relational, need to scale read traffic, manual promotion acceptable? → RDS read replica.
• Need the highest relational performance and availability AWS offers? → Aurora.
• Key-value or document data, need single-digit-millisecond latency at scale? → DynamoDB.
• Unpredictable or spiky DynamoDB traffic? → On-demand capacity mode over provisioned.
• In-memory caching layer in front of a database? → ElastiCache (Redis for persistence/complex data structures, Memcached for simple, multi-threaded caching).

Load balancer and traffic decision tree

• HTTP/HTTPS traffic, need path- or host-based routing? → Application Load Balancer (ALB).
• Extreme performance, TCP/UDP, need to preserve client IP? → Network Load Balancer (NLB).
• Deploying third-party virtual appliances (firewalls, IDS/IPS)? → Gateway Load Balancer (GWLB).
• Global content delivery, reduce latency for static/dynamic content? → CloudFront in front of the origin (S3 or ALB).

Walking through a scenario with these trees

Say a question describes an application storing user-uploaded documents: accessed constantly for the first week after upload, rarely after that, but must be retrievable within minutes if requested, and the company wants the lowest possible ongoing storage cost. Working the storage tree top to bottom: it is object storage, not a file system multiple instances need to share, so S3 is already the family. Access pattern shifts from frequent to rare on a predictable schedule, and Storage classes need to be applied automatically as the object ages — that is a lifecycle policy, not Intelligent-Tiering (Intelligent-Tiering fits when the access pattern is unpredictable, not merely time-based).

The "retrievable within minutes" constraint rules out Glacier Deep Archive (hours) and points to S3 Standard-IA or Glacier Instant Retrieval for the post-week-one tier. Reading the constraint carefully — minutes, not hours — is what separates the correct answer from a superficially similar but wrong one that would technically be cheaper. This is the exact reasoning pattern the decision trees above are meant to shortcut once they are second nature.

Domain reference

Trap patterns to watch for

• “Automatic failover” language: almost always points to Multi-AZ, not a read replica.
• “MOST cost-effectively” language: re-read every answer choice for a cheaper option before picking one that merely works.
• “LEAST operational overhead” language: usually points toward a managed service (Aurora, Lambda, Fargate) over a self-managed one (self-managed database on EC2, EC2 Auto Scaling with manual patching).
• Security group vs NACL questions: security groups are stateful (return traffic automatically allowed) and instance-level; NACLs are stateless (return traffic needs an explicit rule) and subnet-level.
• Encryption key control questions: if the scenario requires the company to control or revoke a key directly, the answer is a KMS customer managed key, not an AWS managed key or SSE-S3.

Common wrong-answer patterns

Beyond the specific traps listed above, a few wrong-answer shapes recur often enough to be worth naming. First, the “sounds bigger, must be better” trap: a larger instance, a pricier storage tier, or a more expensive database option is rarely the right answer to a cost-optimization or even a resilience question, because AWS designs these scenarios to reward the option that fits the constraint precisely, not the option that throws more resources at the problem.

Second, the “manual process disguised as a solution” trap: an answer involving a person running a script, checking a dashboard, or performing a manual failover will almost always lose to a managed or automated equivalent when the question asks for “least operational overhead” or similar language, even if the manual option is technically cheaper up front.

Third, the “right service, wrong configuration” trap: two answer choices might both name the correct service (RDS, S3, an ALB) but differ in a configuration detail — Multi-AZ enabled or not, a specific storage class, a particular routing rule — and the question is really testing whether you know the configuration detail, not whether you recognize the service name. Read past the service name to the configuration specifics before committing to an answer.