← Whitepapers and FAQs

SAA0 Cheat sheet — Whitepapers and FAQs

Every figure verified 2026-09-21 against the pages cited in the lessons. Items marked [unverified] were not retrieved from the page I fetched — go and read them; do not learn them from here.

Well-Architected: the six pillars

Tie-break rule: when two options meet the requirement, less operational overhead wins. Managed > self-managed > serverless > not running it.

Six general design principles

1. Stop guessing your capacity needs → Auto Scaling / serverless beats a fixed fleet
2. Test systems at production scale → on-demand test env, then decommission
3. Automate with architectural experimentation in mind → IaC, and cite revertibility
4. Consider evolutionary architectures
5. Drive architectures using data
6. Improve through game days → testing the DR plan, not documenting it

Well-Architected Tool: at no charge.

Seven security design principles

1. Implement a strong identity foundation — least privilege, separation of duties, centralise identity, "eliminate reliance on long-term static credentials"
2. Maintain traceability — real time, and "automatically investigate and take action"
3. Apply security at all layers — edge, VPC, LB, instance, OS, application, code
4. Automate security best practices — controls as code in version-controlled templates
5. Protect data in transit and at rest — ⚠️ classify first, then encrypt/tokenise/access-control
6. Keep people away from data — Session Manager, not SSH. Under-used tie-breaker.
7. Prepare for security events — "Run incident response simulations"

Seven security best practice areas

Security foundations · Identity and access management · Detection · Infrastructure protection · Data protection · Incident response (no direct SAA-C03 task statement) · Application security

⚠️ "AWS Security Best Practices" as a standalone whitepaper surfaces only as archived 2018/2020 PDFs. Use the Security Pillar (publication date 2024-11-06).

EC2

⚠️ Spot needs interruption tolerance — "most cost-effective" never licenses breaking a functional requirement. [unverified] Spot interruption notice period · placement groups (cluster/spread/partition)

S3

Durability: 99.999999999% (11 nines).

⚠️ Any answer resting on "S3 is eventually consistent" is out of date. Durability = will the bytes exist. Availability = can you reach them now. They differ. [unverified] per-class minimum storage durations (30/90/180 day figures) · Glacier retrieval times

VPC — the four hard constraints ⭐

1. ⭐ "A subnet must reside within a single Availability Zone." → VPC is Regional, subnet is zonal. Multi-AZ = multi-subnet.

2. ⭐ "Amazon reserves the first four (4) IP addresses and the last one (1) IP address of every subnet." → 5 gone, not 2.

   /28	/27	/26	/24
   11 usable	27	59	251

3. ⭐ VPC CIDR: "/28 … and /16 in size." → /8 impossible, /29 impossible.

4. ⭐ "Transitive peering relationships are not supported." → A↔B, B↔C ⇒ A cannot reach C. 10 VPCs fully meshed = 45 connections. Answer: Transit Gateway.

NAT gateway: outbound only; "resources in a private subnet to access the Internet".

[unverified] SG/NACL rule quotas · VPCs per Region · CIDR expansion · endpoint details · TGW specifics

Route 53

Three services: DNS + domain registration + health checks.

⚠️ Latency-based optimises; geolocation controls. For a regulatory requirement, latency-based is the trap — "probably routes there" is not a control.

⭐ Alias records: Route 53–specific; work at the zone apex (a CNAME cannot); auto-track the resource's changing IPs; no additional charge for ELB / CloudFront / Beanstalk / API Gateway / VPC endpoint targets. → example.com → ALB = alias record, and it's free.

[unverified] Route 53 availability percentage · private hosted zones · Resolver endpoints · health check types · DNSSEC

RDS

Engines: PostgreSQL · MySQL · MariaDB · SQL Server · Oracle · Db2 · Aurora

⭐ "A Multi-AZ standby cannot serve read requests. Multi-AZ deployments are designed to provide enhanced database availability and durability, rather than read scaling benefits."

→ "Single point of failure and read load" needs both. → "Read replicas for HA" is wrong — async, manual promotion.

⚠️ 90-day retention is impossible with automated backups → manual snapshots or AWS Backup. [unverified] backup window I/O behaviour · snapshot-vs-backup on deletion · PITR granularity · encrypting existing instances · Multi-AZ DB cluster

SQS

"a message queue service … through a polling model … to decouple sending and receiving components." (Polling = pull. Push is SNS/EventBridge.)

• Visibility timeout — "prevents other consuming components from receiving and processing a message". ⚠️ Shorter than processing time ⇒ duplicate processing.
• Long polling — "doesn't return a response until a message arrives … or the long poll times out", at no additional charge. → the answer to empty receives / cost.
• Dead-letter queue — for messages the consumer "is unable to consume … successfully". Without one, a poison message retries until retention expires.

[unverified] visibility timeout max · default visibility timeout · max long-poll wait · delay queues · FIFO group/dedup IDs · encryption

The traffic-spike pattern (four facts, one design)

1. Decouple with SQS → a spike becomes a backlog, not a failure
2. Read replicas → read-heavy load
3. Multi-AZ → the failover requirement (separately; it does nothing for reads)
4. Idempotent consumers → because standard queues are at-least-once

Three sentences to carry

1. A subnet is zonal; a VPC is Regional. Every multi-AZ design is a multi-subnet design.
2. Peering isn't transitive → Transit Gateway.
3. A Multi-AZ standby serves no reads → read replicas are a different tool.