SAA-C03 Cheatsheet — High-Yield Patterns, Decision Tables & Snippets

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

Quick facts (SAA-C03)

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.

Final 20-minute recall (exam day)

Cue -> best answer (pattern map)

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)

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.

KMS + encryption (common patterns)

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

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.

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 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