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

High-signal SAA-C03 reference: VPC/networking patterns, IAM/KMS/S3 security, storage and database selection, HA/DR strategies, observability essentials, and cost optimization levers.

On this page

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


Quick facts (SAA-C03)

ItemValue
Questions65 (multiple-choice + multiple-response)
Time130 minutes
Passing score720 (scaled 100–1000)
Cost150 USD
DomainsD1 Secure 30% • D2 Resilient 26% • D3 High-Performing 24% • D4 Cost-Optimized 20%

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.

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)

EndpointServicesWhat it doesCost note
Gateway endpointS3, DynamoDBAdds route-table entries; stays on AWS networkNo hourly charge
Interface endpoint (PrivateLink)Most AWS servicesENI in subnets; private service accessHourly + data processing

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


Security layers: SG vs NACL (keep it simple)

ControlLevelStateful?Typical best practice
Security groupENI/resourceYesPrimary control; reference SG‑to‑SG
NACLSubnetNoKeep simple unless compliance requires

Multi-VPC connectivity (choose the right primitive)

NeedBest-fitWhy
Few VPCs, simple linksVPC peeringLow latency; simple
Many VPCs (sprawl), transitive routingTransit GatewayHub-and-spoke; scalable
Expose a service privately without routing everythingPrivateLinkStrong isolation; no CIDR coordination

Hybrid connectivity (associate-level)

OptionBest forNotes
Site-to-Site VPNQuick setup, encrypted tunnelUses internet; can be used as DX backup
Direct Connect (DX)Predictable bandwidth/latencyOften paired with VPN for HA

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)

ServiceBest forKey idea
Route 53DNS routing and failoverDNS‑based; health checks; TTL matters
CloudFrontCDN caching + origin failover for HTTP(S)Faster global content delivery
Global AcceleratorStatic anycast IPs + fast failoverGreat for TCP/UDP and fast regional failover

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”

Policy/controlAnswers “who?”Answers “what can they do?”Common exam gotcha
Trust policyWho can assume a roleNoToo-broad principals
Identity policyNoPrincipal permissionsMissing conditions/least privilege
Resource policyWho can access the resourceResource permissionsForgetting to add cross-account principal
SCP (Organizations)Org guardrailRestrictsExplicit deny blocks everything
KMS key policyKey admin/useKey permissionsIAM allow isn’t enough if key policy blocks

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


KMS + encryption (common patterns)

NeedBest-fitNotes
Simple default encryptionSSE-S3S3-managed keys
Audit/control requirementsSSE-KMSWatch key policy principals
Strict key custodyCloudHSM / client-sideMore complexity

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)

ServiceWhat it’s “for” on SAA
WAFL7 protections (IP blocks, rate limiting, OWASP-style rules)
ShieldDDoS protection (Standard by default)
GuardDutyThreat detection using logs (findings)
Security HubAggregate/standardize findings and posture
InspectorVulnerability findings for compute/container images
MacieFind sensitive data in S3

3) Compute and scaling — ELB/ASG patterns

Load balancer choice (frequent)

NeedPickNotes
HTTP/HTTPS, L7 routingALBPath/host routing, WAF integration
TCP/UDP, very high throughputNLBStatic IPs per AZ, low latency
Inline appliancesGWLBInsert firewalls/IDS appliances

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)

OptionBest forWhy it wins
EC2Full OS control and flexibilityBroadest compatibility
ECS/FargateContainers with low opsNo server management with Fargate
EKSKubernetes standardizationEcosystem + portability (more ops)
LambdaEvent-driven + bursty workloadsMinimal ops; scales fast

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)

RequirementBest-fitWhy
Durable object storageS3Highly durable, cheap, scalable
Boot / per-instance block volumeEBSLow-latency block storage for EC2
Shared POSIX file systemEFSMulti-AZ shared file storage
Windows file shares / high-perf fileFSxManaged Windows/Lustre/etc

EBS volume types (quick selection)

TypeBest forNotes
gp3General purposeDefault choice; tune IOPS/throughput
io2High IOPS + critical workloadsHigher cost; consistent performance
st1Throughput-heavy HDDGood for large sequential workloads
sc1Lowest-cost HDDCold throughput workloads
Instance storeTemporary scratchFast but ephemeral (data lost on stop/terminate)

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


S3 storage classes (fast selection)

RequirementService/ClassNotes
Hot object storageS3 StandardDefault
Unknown access patternsS3 Intelligent‑TieringMonitoring fee
Infrequent access, multi-AZ durabilityS3 Standard‑IARetrieval fee
Infrequent access, single AZS3 One Zone‑IACheaper; less resilient
ArchiveS3 Glacier / Deep ArchiveRetrieval time trade-offs

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)

FeatureMulti-AZRead replica
Primary purposeHA/failoverRead scaling
WritesOne primaryStill one primary
FailoverAutomaticManual promotion (generally)

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)

NeedBest-fit
Relational + joins + transactionsRDS/Aurora
Massive key-value scaleDynamoDB
Sub-millisecond cacheElastiCache
DynamoDB read cacheDAX

ElastiCache: Redis vs Memcached (SAA-level)

ServiceBest forNotes
RedisRich features + durability optionsReplication, multi-AZ patterns, data structures
MemcachedSimple cacheVery simple, no persistence

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)

StrategyTypical RTOTypical RPOCostNotes
Backup/RestoreHighHoursLowCheapest; slowest recovery
Pilot LightMediumMinutes–hoursMedMinimal core in DR
Warm StandbyLowMinutesMed+Scaled-down prod running
Multi-site active-activeVery lowSecondsHighComplex; highest cost

Multi-Region data options (high yield)

Data layerMulti-Region option
S3CRR
DynamoDBGlobal tables
AuroraAurora Global Database

DR routing: Route 53 policy selection

Routing policyBest for
FailoverActive-passive DR
WeightedCanary / migrations
LatencyLowest latency routing per user
GeolocationCompliance/content by country

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)

PatternProsCons
Active-passiveCheaper; simpler operationsHigher RTO; failover/failback steps
Active-activeLowest downtime; global performanceMost complex; highest cost

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

ServiceThink “this answers…”
CloudWatch“How is it performing?” (metrics/logs/alarms)
CloudTrail“Who did what?” (API audit trail)
Config“What changed?” (config history + compliance)
X-Ray“Where is latency?” (distributed traces)

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

PatternOptionNotes
Steady baselineSavings PlansFlexible discount for compute
Predictable, fixed needsReserved InstancesStrong discount for known shape
Fault-tolerantSpotBiggest savings; design for interruption

Cost visibility tools (what to reach for)

ToolBest for
Cost ExplorerTrend analysis and spend breakdown
BudgetsAlerts on spend/usage thresholds
Cost Anomaly DetectionUnexpected spend spikes
Compute OptimizerRightsizing recommendations
Trusted AdvisorBest-practice checks (cost/security/perf)
Cost and Usage Report (CUR)Most detailed cost dataset export

Cost levers by area (fast table)

AreaLeverExample
ComputeRight-size + GravitonSmaller instance families, Graviton where supported
ComputeSpot for fault-tolerantBatch/worker tier with Spot + scaling
StorageS3 lifecycle tieringMove logs to IA/Glacier
Storagegp3 tuningTune IOPS/throughput instead of overprovisioning
NetworkEndpoints over NATS3/DynamoDB via Gateway endpoints
EdgeCache at CloudFrontReduce origin load and egress

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.