AWS SAA-C03 Cheat Sheet: Architecture Decisions and Exam Traps

Keep this cheat sheet open while drilling questions. SAA-C03 is about trade-offs: availability, performance, cost, operations, and security.

Use the study plan to sequence the guide, then use this page for compressed recall once the chapter lessons are familiar.

If you want a quick architecture cue map, use the constraint flow and pattern sections below before mixed scenario drills.

Quick facts (SAA-C03)

I verified these current AWS exam facts on May 24, 2026.

Domain weights and review priority

SAA-C03 is a design-tradeoff exam. The best answer is rarely the most powerful service; it is the lowest-complexity architecture that satisfies the named security, resilience, performance, cost, and operational constraints.

Architecture proof stack

SAA-C03 questions usually compare architectures that are all technically possible. The winning answer is the one that proves the named constraint with the least unnecessary complexity. Before choosing, walk the scenario through this stack:

1. Constraint: identify whether the deciding word is secure, highly available, fault tolerant, low latency, scalable, least operational effort, lowest cost, or private.
2. Failure domain: decide whether the design must survive instance, AZ, Region, dependency, deployment, or access-control failure.
3. Access path: prove who or what talks to the service, over which network path, with which identity/resource/KMS controls.
4. Data behavior: match storage, database, cache, replication, backup, lifecycle, consistency, and recovery choices to the access pattern.
5. Operational effort: prefer managed or serverless services when they satisfy the requirement; keep self-managed designs only when the stem requires control.
6. Cost driver: optimize the largest waste source first: idle compute, NAT/data transfer, wrong storage tier, overprovisioned database, or inefficient scans.
7. Evidence: keep answers that can be verified with health checks, logs, metrics, failover behavior, backup/restore proof, or cost visibility.

If two answers both work, choose the one that satisfies the constraint with fewer moving parts, narrower permissions, simpler operations, and clearer failure behavior.

Official task compression

Design Secure Architectures covers secure access, secure workloads, and data protection controls. Separate identity, resource, network, and KMS key-policy controls before choosing a service.

Design Resilient Architectures covers loose coupling, scalability, high availability, fault tolerance, and disaster recovery. Remove single points of failure, decouple components, and match RTO/RPO to the least complex recovery pattern.

Design High-Performing Architectures covers scalable storage, elastic compute, databases, networking, ingestion, and latency/throughput choices. Pick purpose-built services from access pattern, data shape, latency, throughput, and scaling metric.

Design Cost-Optimized Architectures covers storage, compute, database, and network cost design. Optimize the largest cost driver first: idle capacity, wrong storage tier, NAT/data transfer, overprovisioned databases, inefficient scans, or logging volume.

SAA-C03 boundary cues

AWS frames SAA-C03 as an associate solutions-architecture exam. Use that boundary to reject distracting answers:

• If the answer solves the problem with a large custom platform when a managed service fits, it is usually too operationally heavy.
• If the answer says highest availability but only adds backups or snapshots, it probably misses live failover or Multi-AZ/Multi-Region behavior.
• If the answer says private access but routes through public internet/NAT when a VPC endpoint or PrivateLink pattern fits, it is usually weaker.
• If the answer says lowest cost but ignores NAT processing, data transfer, storage class, overprovisioning, or query-scan cost, it is incomplete.
• If the answer says secure but only changes IAM and ignores resource policies, KMS key policies, network path, or logging, it is too narrow.

How SAA-C03 questions work (fast strategy)

• Read the last sentence first: it usually contains the deciding constraint (lowest cost, least ops, highest availability, most secure).
• If multiple answers “work”, the best answer is typically the one with managed services + least operational overhead.
• If the question mentions private subnets, assume no direct internet access unless NAT/endpoints are included.
• If you see AccessDenied, separate concerns: identity policy vs resource policy vs KMS key policy.
• AWS notes that the exam may use short service names with a Help-button reference list. Map short names back to the architecture role before choosing.

Question-type traps

Unanswered questions are incorrect and there is no penalty for guessing. With 65 questions in 130 minutes, your average budget is exactly 2 minutes per question; mark long architecture stems once you have narrowed the choice.

Constraint-first elimination flow

    flowchart TD
	  Q["Read the last sentence first"] --> C["Find the deciding constraint"]
	  C --> A["Availability / resilience?"]
	  C --> P["Performance / scale?"]
	  C --> S["Security / private access?"]
	  C --> K["Cost / least ops?"]
	  A --> E["Eliminate answers that miss that constraint"]
	  P --> E
	  S --> E
	  K --> E
	  E --> W["Choose the lowest-complexity answer that still works"]

Rule: if the answer is more elaborate but does not better satisfy the named constraint, reject it.

What to notice:

• many SAA-C03 mistakes happen before service selection because the real constraint was missed
• the best answer is often the managed service or simpler architecture that still satisfies that constraint

Scenario eliminations

Architecture evidence map

SAA-C03 answer sequence

Use this when the stem is a design trade-off problem rather than a pure service lookup.

    flowchart TD
	  S["Scenario"] --> C["Find the deciding constraint"]
	  C --> A["Availability, performance, security, or cost?"]
	  A --> P["Pick the smallest managed architecture that works"]
	  P --> O["Check operational effort and failure domains"]
	  O --> E["Reject answers that miss the named constraint"]

Final 20-minute recall (exam day)

Cue -> best answer (pattern map)

Constraint collision chooser

Must-memorize SAA defaults

Last-minute traps

• Choosing NAT when endpoint is the private/cheaper answer for S3/DynamoDB.
• Confusing Multi-AZ (HA) with read replicas (read scale/DR).
• Picking custom/self-managed stacks when managed service meets the requirement.
• Ignoring data transfer and cross-AZ costs in architecture choices.

1) VPC and networking — patterns that win

Subnets, routing, and egress (defaults you get tested on)

• Public subnet: route table has 0.0.0.0/0 → IGW.
• Private subnet: no IGW route; outbound internet needs NAT Gateway (typically one per AZ for HA).
• Avoid cross-AZ hairpinning (SPOF + cross-AZ charges): private subnets in AZ‑A should use NAT in AZ‑A.

Gateway vs Interface endpoints (huge cost + security lever)

Exam cue: “Private subnets must access S3/DynamoDB” → Gateway endpoint (not NAT).

Security layers: SG vs NACL (keep it simple)

Multi-VPC connectivity (choose the right primitive)

Hybrid connectivity (associate-level)

Exam cue: If the scenario says “quickly establish connectivity,” VPN is common. If it says “consistent performance,” Direct Connect is common.

Edge + global routing (Route 53 vs CloudFront vs Global Accelerator)

Networking decision ladder

Reference diagram: common “best answer” VPC layout

    flowchart LR
	  U[Users] --> ALB["ALB (Public Subnets)"]
	  ALB --> App1["App (Private AZ1)"]
	  ALB --> App2["App (Private AZ2)"]
	  App1 & App2 --> RDS["RDS/Aurora (Multi-AZ)"]
	  App1 & App2 --> S3["S3 via Gateway Endpoint"]
	  App1 & App2 --> DDB["DynamoDB via Gateway Endpoint"]
	  App1 --> NAT1["NAT GW (AZ1)"]
	  App2 --> NAT2["NAT GW (AZ2)"]

2) Security and identity — IAM, KMS, logging

IAM: policy types and “what breaks access”

High-yield rule: Explicit Deny wins. If you see Organizations in a scenario, consider SCP effects.

AccessDenied triage

    flowchart TD
	  D["AccessDenied"] --> I["Identity policy"]
	  I --> R["Resource policy"]
	  R --> K["KMS key policy or grants"]
	  K --> O["SCP or explicit deny"]

Fast rule:

• if the resource is S3, SQS, SNS, or KMS, do not stop at the identity policy
• if encryption is involved, the KMS layer may be the actual blocker
• if AWS Organizations is in the scenario, an SCP may override what looks like a valid IAM allow

KMS + encryption (common patterns)

Common failure mode: service can’t decrypt because the KMS key policy doesn’t allow the calling principal/service.

Security design chooser

S3 security: “best answer” checklist

• Turn on S3 Block Public Access (account + bucket).
• Prefer private buckets + controlled access (roles, bucket policies, access points).
• Require TLS (aws:SecureTransport) and require encryption where needed.

Require TLS for all S3 requests (copy-ready):

 1{
 2  "Version": "2012-10-17",
 3  "Statement": [
 4    {
 5      "Sid": "DenyInsecureTransport",
 6      "Effect": "Deny",
 7      "Principal": "*",
 8      "Action": "s3:*",
 9      "Resource": [
10        "arn:aws:s3:::my-bucket",
11        "arn:aws:s3:::my-bucket/*"
12      ],
13      "Condition": { "Bool": { "aws:SecureTransport": "false" } }
14    }
15  ]
16}

Require access via a specific VPC endpoint (copy-ready):

 1{
 2  "Version":"2012-10-17",
 3  "Statement":[{
 4    "Sid":"DenyNotFromVPCE",
 5    "Effect":"Deny",
 6    "Principal":"*",
 7    "Action":"s3:*",
 8    "Resource":[
 9      "arn:aws:s3:::my-bucket",
10      "arn:aws:s3:::my-bucket/*"
11    ],
12    "Condition":{"StringNotEquals":{"aws:sourceVpce":"vpce-1234567890abcdef0"}}
13  }]
14}

CloudFront note: for private S3 origins, use Origin Access Control (OAC) (don’t make the bucket public).

Security services (recognize the role)

3) Compute and scaling — ELB/ASG patterns

Load balancer choice (frequent)

Auto Scaling “best answers”

• ASG across multiple AZs.
• Health checks: use ELB health checks to replace unhealthy instances.
• Prefer stateless app tiers; store session state externally (ElastiCache/DynamoDB) when needed.

Compute chooser (EC2 vs containers vs serverless)

Exam cue: If the scenario says “least operational overhead,” managed options (Fargate/Lambda/managed data stores) usually beat self-managed EC2.

4) Storage — object vs block vs file, and S3 class selection

Storage type picker (very common)

EBS volume types (quick selection)

Exam cue: EBS is AZ-scoped. For multi-AZ shared storage, EFS/FSx is the usual answer.

S3 storage classes (fast selection)

Exam cue: “Long-term retention / compliance” → Glacier + lifecycle + (sometimes) Object Lock.

S3: durability + resilience patterns

• Versioning + lifecycle rules (protect against deletes and ransomware scenarios).
• CRR/SRR for replication needs (cross-region or same-region).
• Object Lock (WORM) for immutability requirements.

Backups (fast picks)

• EBS snapshots are incremental; copy snapshots cross-region for DR.
• AWS Backup helps centralize backup policies across common services.
• For databases, prefer managed backup features (RDS automated backups/snapshots).

5) Databases and caching — RDS/Aurora vs DynamoDB

RDS: Multi-AZ vs read replicas (classic SAA)

Rule: Multi-AZ is about availability; read replicas are about scale.

Aurora (why it’s often a “best answer”)

• Higher throughput than standard RDS engines (common exam framing).
• Multiple read replicas for read scaling (and faster reads in the same region).
• Aurora Global Database for low-latency global reads and faster cross-region DR.

When to choose what (fast)

ElastiCache: Redis vs Memcached (SAA-level)

DynamoDB: what wins questions

• Prefer Query over Scan.
• Choose partition keys to avoid hot partitions.
• Use GSIs for new access patterns.
• Use On‑Demand for spiky traffic; Provisioned + Auto Scaling for steady predictable workloads.

6) Resilience and DR — RTO/RPO patterns

HA patterns (default architecture)

• Multi-AZ for app tiers (ALB + ASG across AZs).
• Databases: Multi-AZ where required (RDS/Aurora).
• Use queues/caching to absorb spikes and failures.

Resilience evidence checklist

DR strategies (know the table)

Multi-Region data options (high yield)

DR routing: Route 53 policy selection

Exam cue: If you need faster failover with static anycast IPs, consider Global Accelerator. If you need caching + origin failover for HTTP(S), consider CloudFront.

Active-passive vs active-active (quick framing)

DR sketch (active-passive)

    flowchart LR
	  Users --> R53[Route 53]
	  R53 -->|Primary| A[Region A]
	  R53 -->|Failover| B[Region B]
	  A --> AppA[App + DB]
	  B --> AppB[Warm standby]

7) Observability and operations — what each tool answers

Exam cue: if the requirement is auditing and investigations, CloudTrail is usually the anchor.

High-yield alarms to know

• ALB: HTTPCode_Target_5XX_Count, TargetResponseTime
• ASG/EC2: CPU (and memory via agent), status checks
• SQS: queue depth/age (backpressure signals)
• DynamoDB: throttles, consumed capacity (hot partitions/underprovisioned)

8) Cost optimization — fast wins (and common traps)

Compute purchase options (memorize the “when”)

Cost visibility tools (what to reach for)

Cost trap ladder

If monthly spend is the explicit constraint, check these in order:

1. Is the architecture paying for the wrong connectivity path?
2. Is it paying for premium compute or storage that the workload does not need?
3. Is it paying for idle baseline capacity that should use commitments or elastic scaling?
4. Is it paying for repeat reads or transfer that caching, endpoints, or lifecycle policies would remove?

Cost levers by area (fast table)

Cost “gotchas”

• Single NAT for all private subnets: SPOF + cross-AZ charges.
• Heavy NAT usage to reach S3/DynamoDB: often replace with Gateway endpoints.
• Cross-AZ data transfer and inter-region replication costs add up fast.
• Logging retention and high-volume logs can become a surprise bill.

9) Common pitfalls (exam bait)

• Assuming PrivateLink exists for S3/DynamoDB (use Gateway endpoints).
• ALB/ASG only in one AZ (not HA).
• Confusing RDS Multi-AZ (HA) with read replicas (scale).
• KMS key policy missing explicit principals (service can’t use key).
• Overly strict NACLs breaking stateful flows (SG-first is usually best).
• Choosing Scan over Query on DynamoDB.

10) Mini runbooks (copy/paste patterns)

Cross-account role assumption (trust policy):

1{
2  "Version":"2012-10-17",
3  "Statement":[{
4    "Effect":"Allow",
5    "Principal":{"AWS":"arn:aws:iam::222233334444:role/TeamRole"},
6    "Action":"sts:AssumeRole"
7  }]
8}

Route 53 failover (pseudo steps):

11) Create primary A/AAAA alias to ALB in Region A with Health Check.
22) Create secondary A/AAAA alias to ALB in Region B with Health Check.
33) Set routing policy to Failover: Primary / Secondary.
44) Verify health checks and simulate failover.

Final tip

If multiple answers work, pick the one that best matches the explicit constraint (for example: lowest cost or least operational effort) while still meeting availability and security requirements.

Quiz