บทที่ 14: Exam Scenarios, Decision Frameworks & Final Review

1. วัตถุประสงค์บท

บทนี้เป็น บทสังเคราะห์ (capstone) ของทั้งเล่ม ทำหน้าที่ต่างจากบทที่ 01–13 อย่างชัดเจน: บทที่ 01 วาง กรอบคิดและวิธีทำข้อสอบ (mindset), บทที่ 02–13 เป็นเจ้าของ ความรู้เชิงบริการ รายโดเมน ส่วนบทที่ 14 นี้ ไม่แนะนำเนื้อหาใหม่ แต่ประกอบชิ้นส่วนทั้งหมดเข้าเป็น “เครื่องมือตัดสินใจ” ที่พร้อมหยิบใช้ในห้องสอบ และฝึกเดินโจทย์ยาว multi-service แบบข้อสอบจริงตั้งแต่ต้นจนตัดคำตอบ

เมื่อจบบทนี้ ผู้อ่านจะสามารถ:

• ใช้ decision framework แบบ flowchart/ตารางตัดสินใจ สำหรับหกคำถามที่ SAP-C02 ถามซ้ำที่สุด — เลือก database, เลือก compute, เลือก connectivity, เลือก DR strategy, เลือก migration R, เลือก storage — โดยเดินจาก requirement/constraint ไปสู่บริการภายในไม่กี่วินาที
• เดินโจทย์ scenario ยาวแบบข้อสอบจริง (multi-service, cross-domain) ด้วยเทคนิค requirement-first reading (บทที่ 01) แล้ววิเคราะห์ทีละตัวเลือกว่า ทำไมถูก/ทำไมผิด
• จับ cross-domain trade-off ที่ข้อสอบชอบผสม — security + networking + cost, หรือ migration + resilience — ซึ่งเป็นเอกลักษณ์ของระดับ Professional (ต่างจาก Associate ที่ถามบริการเดี่ยว)
• จำ distractor pattern และกับดัก ที่รวบรวมจากทุกบท เพื่อไม่ให้เสียคะแนนกับตัวเลือกที่ “ทำงานได้แต่ไม่ตรง keyword ที่สุด”
• ใช้ keyword → service cheat sheet เป็น lookup table สุดท้าย และเดินตาม readiness checklist ก่อนสอบ

เนื้อหาบทนี้อ้างอิงกลับบทที่ 01–13 ตลอด — ทุกกรอบตัดสินใจมีลิงก์ไปบทเจ้าของเนื้อหาสำหรับทบทวนเชิงลึก ให้ถือบทนี้เป็น “แผนที่” ไม่ใช่ตำราตัวเต็ม

---

2. แนวคิดหลัก

2.1 ปรัชญาของการทำข้อสอบ Professional: จาก keyword สู่ constraint สู่ trade-off

บทที่ 01 วางรากฐานไว้แล้วว่า SAP-C02 ไม่ได้วัด “คุณรู้จักบริการไหม” แต่วัด “คุณเลือกบริการที่ ตรงที่สุด ภายใต้ข้อจำกัดที่ให้มาได้ไหม” โจทย์เกือบทุกข้อมีตัวเลือก 2–3 ตัวที่ ทำงานได้จริงทางเทคนิค (นั่นคือนิยามของ distractor — บทที่ 01) สิ่งที่แยกคำตอบถูกออกจาก distractor คือ keyword บีบ (requirement signal) ที่ซ่อนอยู่ท้ายโจทย์

กระบวนการสังเคราะห์ที่บทนี้ใช้ซ้ำในทุก scenario:

1. อ่าน requirement ท้ายโจทย์ก่อน (requirement-first reading) — คำถามถามอะไร มี keyword อะไร (least operational overhead, most cost-effective, minimal downtime, real-time, no data loss)
2. จับ constraint ที่ซ่อน — ทีมเล็ก = low ops, regulated = encrypt + audit + immutable, cannot modify code = ตัด Refactor, tight deadline = migrate-then-modernize
3. เดิน decision framework ของหมวดที่ตรง (database/compute/connectivity/DR/migration/storage)
4. ตัด distractor 5 ขั้น (บทที่ 01): ตัด technically-wrong → ตัดที่ละเมิด constraint → ตัด over-engineered → ตัด under-engineered → เลือกตัวตรง keyword ที่สุด
5. ตรวจ trade-off — คำตอบที่เลือกแลกอะไรไป และ keyword ยอมรับ trade-off นั้นหรือไม่

2.2 หลักการชั่ง trade-off ด้วย WAF 6 pillars

ทุก decision framework ในบทนี้ยืนอยู่บน Well-Architected Framework 6 pillars (บทที่ 01) ในฐานะ “แกนชั่ง” เมื่อ keyword ขัดกันเอง ให้ดูว่า pillar ไหนถูกเน้น:

keyword ในโจทย์	pillar ที่เน้น	ทิศคำตอบ
least operational overhead, fully managed, no servers to manage	Operational Excellence	managed/serverless (Fargate, Lambda, Aurora Serverless, Intelligent-Tiering)
most cost-effective, minimize cost, reduce spend	Cost Optimization	Spot, tiered storage, Savings Plans, right-size, gateway endpoint
highly available, survive AZ failure, no single point of failure	Reliability	Multi-AZ, ASG, decouple
disaster recovery, survive region failure, RTO/RPO	Reliability	Multi-Region, DR strategy 1 ใน 4
encrypt, audit, compliance, immutable	Security	KMS, CloudTrail, Object Lock/Vault Lock, SCP
sub-millisecond, real-time, high throughput	Performance Efficiency	cache (DAX/ElastiCache), streaming (Kinesis), NLB
carbon, sustainability, efficient resource use	Sustainability	มักตรงกับ Cost/Performance (right-size, Graviton, serverless)

จุดสำคัญ: เมื่อ pillar สอง ตัวขัดกัน (เช่น highly available กับ most cost-effective) ให้เลือกตัวเลือกที่ บาลานซ์ — มักเป็นตัวกลาง (Warm Standby แทน Active-Active) ไม่ใช่สุดขั้วด้านใดด้านหนึ่ง นี่คือหัวใจของการตัด over/under-engineering

2.3 mental model ซ้ำที่บทก่อนตั้งไว้ (นำมาใช้ตัด distractor)

บทก่อนหน้าตั้งแกนตัดสินใจซ้ำ ๆ ที่บทนี้จะเรียกใช้เป็น “ตัวช่วยจำเร็ว”:

• Preventive vs Detective vs Responsive (บทที่ 01/02/09): prevent/block → SCP/IAM/WAF; detect/report → Config/GuardDuty/CloudTrail; respond/auto-remediate → EventBridge + SSM Automation
• กลุ่มผู้ใช้ identity (บทที่ 03): external customer → Cognito; workforce SSO → IAM Identity Center; AD workload → Directory Service
• connectivity (บทที่ 04): 1:1 เล็ก → peering; scale hub → Transit Gateway; per-service/CIDR overlap → PrivateLink; global policy → Cloud WAN
• compute (บทที่ 05): event-driven สั้น → Lambda; container least-ops → Fargate; k8s portability → EKS; คุมเต็ม/Spot/BYOL → EC2
• load balancer (บทที่ 05): L7 path/host + WAF → ALB; L4 static IP/UDP/preserve source → NLB; appliance insertion → GWLB
• integration (บทที่ 05): buffer/point-to-point → SQS; fan-out → SNS; content routing/SaaS event → EventBridge; orchestration → Step Functions
• storage (บทที่ 06): object → S3; block → EBS; file → EFS/FSx
• database (บทที่ 07): data model → category (relational/key-value/in-memory/warehouse/graph…)
• HA vs DR (บทที่ 07/08): Multi-AZ (sync/RPO≈0/AZ failure) vs Multi-Region (async/DR/region failure)
• DR strategy (บทที่ 08): RTO/RPO/cost → Backup&Restore < Pilot Light < Warm Standby < Multi-Site
• MGN vs DRS (บทที่ 08/12): migrate ครั้งเดียว/decommission source vs DR ต่อเนื่อง/failback
• 7 Rs (บทที่ 12): keyword → R
• modernization (บทที่ 13): strangler fig (ไม่ big-bang), migrate-then-modernize (deadline สั้น)

---

3. ตารางเปรียบเทียบบริการ — Decision Frameworks แบบสังเคราะห์

หมวดนี้คือหัวใจของบทสังเคราะห์: หกกรอบตัดสินใจที่ SAP-C02 ถามซ้ำที่สุด นำเสนอเป็น flowchart (ข้อความ) + ตารางตัดสินใจ requirement → บริการ → เหตุผล/trade-off ตาม convention บทที่ 04–13

3.1 Framework 1 — เลือก Database (เจ้าของเนื้อหา: บทที่ 07)

Flowchart:

เริ่ม: data model / access pattern คืออะไร?
│
├─ Relational (ACID, JOIN, schema ชัด)?
│   ├─ ต้อง open-source engine + สูงสุด performance/HA/auto-heal → Amazon Aurora
│   │   ├─ ต้อง cross-region DR (RPO<1s) → Aurora Global Database
│   │   └─ workload spiky/intermittent → Aurora Serverless v2
│   └─ ต้อง engine เฉพาะ (Oracle/SQL Server/legacy) / lift-and-shift → Amazon RDS
│       ├─ HA / failover อัตโนมัติ → Multi-AZ
│       └─ scale reads → read replica (async)
│
├─ Key-value / document, scale ไม่จำกัด, single-digit ms?
│   ├─ → Amazon DynamoDB
│   │   ├─ microsecond read → + DAX
│   │   └─ multi-region active-active → Global Tables
│
├─ In-memory / caching?
│   ├─ cache ชั่วคราว (cache-aside/session) → ElastiCache (Redis/Memcached)
│   └─ durable primary in-memory → MemoryDB for Redis
│
├─ Analytics / OLAP / warehouse?
│   ├─ warehouse ที่ต้อง provision → Amazon Redshift (RA3/Spectrum)
│   └─ ad-hoc query บน S3, serverless → Amazon Athena
│
└─ Purpose-built เฉพาะทาง?
    ├─ graph/relationship → Neptune
    ├─ time-series → Timestream
    ├─ document (MongoDB-compat) → DocumentDB
    └─ wide-column (Cassandra) → Keyspaces

requirement / keyword	บริการ	เหตุผล / trade-off
single-digit millisecond, virtually unlimited scale, key-value	DynamoDB	serverless, ไม่มี connection limit; แลกด้วยต้องออกแบบ partition key ดี (บทที่ 07 — hot partition)
microsecond read latency บน DynamoDB	DynamoDB + DAX	write-through cache, ไม่ต้องเขียน cache logic; แลกด้วยค่า node
multi-region active-active, เขียนได้ทุก region	DynamoDB Global Tables	last-writer-wins; ต่างจาก Aurora Global DB ที่ single-writer
relational + minimal downtime upgrade	RDS Blue/Green หรือ Aurora	switch วินาที + rollback; แลกด้วยต้องรัน 2 env ชั่วคราว
relational + cross-region DR + RPO ต่ำสุด	Aurora Global Database	replicate ที่ storage RPO<1s; secondary read-only จน promote
unpredictable/spiky relational	Aurora Serverless v2	auto-scale ACU; แลกด้วยราคาต่อ ACU สูงกว่า provisioned steady-state
complex JOIN บน petabyte, BI dashboard	Redshift	columnar MPP; ไม่เหมาะ OLTP
query S3 โดยไม่ ETL, serverless, จ่ายต่อ query	Athena	least ops; latency สูงกว่า warehouse ที่ provision
corporate app ที่ cannot change code จาก SQL Server	Aurora PostgreSQL + Babelfish (บทที่ 13)	ลด code change + เลิก license; ต้องรัน assessment ก่อน

จุดหลอกซ้ำ: โจทย์บรรยาย access pattern เป็น key-value/document ชัดเจน แต่ใส่ distractor เป็น RDS — ตัดทันทีด้วยแกน “data model → category” (บทที่ 07). และอย่าสับสน Multi-AZ (HA) กับ read replica (scale reads) — standby ของ Multi-AZ ไม่รับ read

3.2 Framework 2 — เลือก Compute (เจ้าของเนื้อหา: บทที่ 05)

Flowchart:

เริ่ม: ลักษณะ workload?
│
├─ event-driven / spiky / สั้น (<15 นาที) / *least operational overhead*?
│   └─ → AWS Lambda (cold start? → provisioned concurrency)
│
├─ container?
│   ├─ *least operational overhead* / ไม่อยากจัดการ node → Fargate
│   ├─ ต้อง Kubernetes API / Helm / portability → EKS
│   └─ ต้องคุม OS/GPU/Spot ลึก / cost ต่ำสุด steady-state → ECS/EKS บน EC2
│
├─ long-running / steady-state สูงคงที่ / legacy / BYOL license?
│   └─ → EC2 (+ Savings Plans / Dedicated Host สำหรับ BYOL)
│
└─ batch fault-tolerant?
    └─ → EC2 Spot (ASG mixed instances, capacity-optimized) / AWS Batch

requirement / keyword	บริการ	เหตุผล / trade-off
event-driven, spiky, no servers to manage	Lambda	จ่ายต่อ invocation; แลกด้วย 15-min limit + cold start
container + least operational overhead	Fargate	ไม่มี node ให้ patch; แพงกว่า EC2 ต่อ vCPU ที่ utilization สูง
container + Kubernetes/portability	EKS	k8s API; overhead จัดการสูงกว่า ECS/Fargate
steady-state สูง 24/7, cost ต่ำสุด	EC2 + Compute Savings Plans (บทที่ 10)	ส่วนลดสูงสุด; แลกด้วย commitment 1/3 ปี
fault-tolerant batch, cost ต่ำสุด	EC2 Spot + ASG mixed	~90% off; แลกด้วยถูก reclaim (2-min notice)
BYOL license per-core	EC2 Dedicated Host	เห็น socket/core; แพงและ ops สูง

จุดหลอกซ้ำ: tight deadline + modernize → migrate-then-modernize = rehost (EC2 ผ่าน MGN) ก่อน ไม่ใช่กระโดด serverless ทันที (บทที่ 13). และ serverless ไม่ได้แปลว่า Lambda เสมอ — long-running/steady-high-volume → container + Savings Plans ถูกกว่า

3.3 Framework 3 — เลือก Connectivity (เจ้าของเนื้อหา: บทที่ 04)

Flowchart:

เชื่อมอะไรกับอะไร?
│
├─ VPC ↔ VPC ภายใน AWS
│   ├─ แค่ 2-3 VPC, 1:1, ไม่ transitive → VPC Peering
│   ├─ หลาย VPC / ต้อง transitive / segment → Transit Gateway
│   ├─ CIDR overlap / expose แค่ 1 service → PrivateLink (interface endpoint)
│   └─ global หลาย region + central policy → Cloud WAN [uncertain]
│
├─ VPC ↔ AWS service (S3/DynamoDB) แบบ private
│   ├─ S3/DynamoDB → Gateway endpoint (ฟรี)
│   └─ service อื่น → Interface endpoint (PrivateLink, มีค่าใช้จ่าย)
│
└─ On-prem ↔ AWS (hybrid)
    ├─ ต้อง bandwidth คงที่ / latency นิ่ง / throughput สูง → Direct Connect
    │   └─ DX + backup → + Site-to-Site VPN
    ├─ เร็ว/ถูก/ชั่วคราว / backup ของ DX → Site-to-Site VPN
    └─ ต้อง 99.99% → DX Maximum Resiliency (2 location + device redundant)

requirement / keyword	บริการ	เหตุผล / trade-off
หลายสิบ VPC ข้าม account ต้อง route หากัน	Transit Gateway + RAM share (บทที่ 03/04)	transitive hub, segment ด้วย TGW route table; peering full-mesh ไม่ scale
CIDR overlap แต่ต้องเข้าถึง 1 application	PrivateLink	expose per-service ผ่าน NLB; ไม่ต้อง re-IP
private access ไป S3 จาก VPC, cost ต่ำสุด	Gateway endpoint	ฟรี ไม่ผ่าน internet; interface endpoint คิดเงิน
consistent bandwidth, dedicated, low latency hybrid	Direct Connect	ไม่ผ่าน internet; lead time ติดตั้งนาน + แพง
hybrid quick / encrypted over internet / backup DX	Site-to-Site VPN	ตั้งเร็ว; bandwidth/latency ไม่การันตี
stateful firewall inspection multi-AZ ผ่าน TGW	TGW appliance mode (บทที่ 04)	บังคับ symmetric routing กัน asymmetric drop

จุดหลอกซ้ำ: VPC peering non-transitive — ถ้าโจทย์มี VPC A–B–C ต้องคุยกันครบผ่าน hub เดียว = Transit Gateway ไม่ใช่ peering. และ static IP + non-HTTP → Global Accelerator ไม่ใช่ CloudFront (บทที่ 04)

3.4 Framework 4 — เลือก DR Strategy (เจ้าของเนื้อหา: บทที่ 08)

Flowchart:

RTO / RPO ที่ธุรกิจยอมรับได้เท่าไร? cost budget?
│
├─ RTO ชั่วโมง-วัน, cost ต่ำสุด, ข้อมูลไม่ critical มาก
│   └─ Backup & Restore (AWS Backup cross-region copy)
│
├─ RPO ต่ำ (database สด) แต่ RTO สิบนาที-ชั่วโมง ยอมได้, cost ปานกลางต่ำ
│   └─ Pilot Light (DB replicate สด, app tier ปิดรอ scale)
│
├─ RTO นาที, ระบบต้องพร้อมเกือบทันที, ยอมจ่ายรัน scaled-down
│   └─ Warm Standby (full stack เล็ก ๆ รันจริง)
│
└─ RTO/RPO ≈ 0, รับ traffic ทั้งสอง region, cost สูงสุด
    └─ Multi-Site Active-Active

requirement / keyword	strategy/บริการ	เหตุผล / trade-off
lowest cost DR, ยอม RTO เป็นชั่วโมง	Backup & Restore + AWS Backup cross-region	ถูกสุด; ช้าสุด, provision ใหม่ตอนเกิดเหตุ
RPO ต่ำ + budget จำกัด	Pilot Light	DB สด, app ปิด; RTO ยังต้อง scale ขึ้น
minimal downtime DR แต่ไม่ active-active	Warm Standby	full stack เล็กรันจริง (ลด bimodal); จ่ายค่ารันต่อเนื่อง
RTO/RPO near zero, no downtime	Multi-Site Active-Active	รับ traffic ทั้งคู่; ซับซ้อน data consistency + แพงสุด
DR ต่อเนื่องระดับ server (any OS/app) RPO วินาที	AWS Elastic DR (DRS)	continuous block replication + failback; ต่าง MGN
deterministic failover ไม่ติด DNS TTL	Application Recovery Controller (ARC)	routing control ผ่าน data plane; ต้นทุน/ความซับซ้อนเพิ่ม
data replication ต่อบริการ	S3 CRR/RTC, Aurora Global DB, DynamoDB Global Tables, EBS snapshot copy	เลือกตามบริการ (บทที่ 08)

จุดหลอกซ้ำ: สับสน RTO (downtime, มองไปหน้า) กับ RPO (data loss, มองย้อนหลัง) — บทที่ 08. no data loss → RPO≈0 → sync replication (Multi-AZ/Aurora). minimal downtime → RTO ต่ำ → Warm Standby/Active-Active. และ DRS (DR) ≠ MGN (migration) — ถ้าโจทย์พูดเรื่อง DR ต่อเนื่อง/failback ตอบ DRS

3.5 Framework 5 — เลือก Migration R (เจ้าของเนื้อหา: บทที่ 12)

Flowchart:

application นี้ควรทำอย่างไร?
│
├─ ยังใช้อยู่ / มีคุณค่าธุรกิจ / มี dependency ต่อไหม?
│   ├─ ไม่ใช้แล้ว / ซ้ำซ้อน → Retire
│   └─ ยังใช้ + ผูก on-prem/compliance ย้ายไม่ได้ตอนนี้ → Retain
│
├─ ต้องย้ายเร็ว / *tight deadline* / *cannot modify code*?
│   ├─ ย้ายทั้งกล่องไม่แปลง (VMware) → Relocate [uncertain post-Broadcom]
│   └─ lift-and-shift server → Rehost (MGN)
│
├─ ปรับเล็กน้อยระหว่างย้าย (เช่น DB → RDS managed)?
│   └─ Replatform (lift-tinker-and-shift)
│
├─ เปลี่ยนไปใช้ SaaS / COTS?
│   └─ Repurchase (drop-and-shop)
│
└─ มี business driver ชัด (agility/scale) + เวลา/ทีมพร้อม?
    └─ Refactor / Re-architect (บทที่ 13 — strangler fig)

keyword / constraint	R	เหตุผล / trade-off
lift-and-shift, minimize change, fast	Rehost (MGN)	เร็วสุด; ไม่ได้ประโยชน์ cloud-native ทันที
cannot modify application code	ตัด Refactor → Rehost/Replatform	ข้อจำกัดตรง ๆ
managed database ระหว่างย้ายโดยไม่ rewrite	Replatform → RDS	ลด ops; เปลี่ยนน้อย
redundant / ไม่มีใครใช้	Retire	ลด cost/attack surface
compliance ผูก data center / hardware เฉพาะ	Retain	ย้ายไม่ได้/ไม่คุ้ม
tight deadline + modernize มาคู่กัน	Rehost ก่อน → Refactor ทีหลัง (migrate-then-modernize, บทที่ 13)	ลดความเสี่ยง cutover
discovery ก่อนวางแผน (least intrusive)	ADS agentless vs agent-based (บทที่ 12)	agentless VM-level; agent = dependency ลึก
business case/TCO ก่อนย้าย	Migration Evaluator (บทที่ 12)	pre-migration; ต่าง Compute Optimizer (post)

3.6 Framework 6 — เลือก Storage (เจ้าของเนื้อหา: บทที่ 06)

Flowchart:

ต้องการ storage แบบไหน?
│
├─ Object (ไฟล์ทั้งก้อน, static, backup, data lake)?
│   └─ S3 → access pattern?
│       ├─ ไม่รู้/เปลี่ยน → Intelligent-Tiering
│       ├─ hot บ่อย → Standard
│       ├─ archive เข้าถึงนาน ๆ ครั้ง → Glacier Flexible/Deep Archive
│       └─ *immutable/WORM/compliance* → Object Lock Compliance mode
│
├─ Block (attach เป็น disk ให้ 1 instance)?
│   ├─ persistent, database → EBS (gp3 default, io2 Block Express critical)
│   └─ ephemeral scratch/cache ราคาถูกสุด → instance store
│
└─ File (shared filesystem หลาย client)?
    ├─ Linux NFS ทั่วไป, elastic → EFS
    ├─ Windows/SMB + AD → FSx for Windows
    ├─ HPC/ML + S3 integration → FSx for Lustre
    ├─ multi-protocol/NetApp migrate → FSx for ONTAP
    └─ ZFS/Linux NFS latency ต่ำ → FSx for OpenZFS

requirement / keyword	บริการ	เหตุผล / trade-off
unknown/changing access pattern, least ops	S3 Intelligent-Tiering	auto-tier, ไม่มี retrieval fee; มี monitoring fee ต่อ object
lowest cost archive, retrieval นาน ๆ ครั้ง	S3 Glacier Deep Archive	ถูกสุด; retrieval ช้า + min duration 180 วัน
immutable, WORM, regulatory	S3 Object Lock Compliance / Backup Vault Lock (บทที่ 08)	ลบไม่ได้แม้ root; ต้องเปิด versioning
database volume, provision IOPS แยก size	EBS gp3	default; io2 Block Express สำหรับ critical DB
shared file Linux, auto-scale	EFS (Elastic throughput)	multi-AZ; แพงกว่า S3 ต่อ GB
Windows file share + AD ACL	FSx for Windows	SMB/NTFS native
HPC/ML training จาก S3	FSx for Lustre	throughput สูงมาก + S3 lazy-load
petabyte + limited bandwidth offline	Snow Family (บทที่ 06)	offline; คำนวณเวลา vs DataSync online
online bulk transfer on-prem→AWS	DataSync	agent-based, incremental; จำกัดด้วย bandwidth
SFTP endpoint ให้ partner ภายนอก	Transfer Family	managed SFTP → S3/EFS

---

4. สถาปัตยกรรมตัวอย่างและ trade-off — Scenario Walkthroughs

หมวดนี้เดินโจทย์ยาวแบบข้อสอบจริง 10 ข้อ ครอบทุกโดเมนและ cross-domain ทุกข้อใช้ requirement-first reading + วิเคราะห์ทีละตัวเลือก ตาม convention <details> + bullet “ทำไมตัวเลือกอื่นผิด”

Scenario 1 — Multi-account + preventive control (Domain 1)

โจทย์: องค์กรมี 200 account ภายใต้ AWS Organizations ฝ่าย security ต้องการ guarantee ว่า ทุก account จะไม่มีทางสร้าง resource นอก region ap-southeast-1 และ us-east-1 (สำหรับ global service) และต้องการ least operational overhead เมื่อมี account ใหม่ join แนวทางใด เหมาะสุด?

A. เขียน Config rule ตรวจ region ในทุก account แล้ว remediate อัตโนมัติ B. ใช้ SCP ที่ OU root ด้วย aws:RequestedRegion + NotAction ยกเว้น global service; ให้ account ใหม่ inherit อัตโนมัติผ่าน Control Tower C. ตั้ง IAM policy deny region ในทุก user ทุก account D. ใช้ AWS Firewall Manager กำหนด region policy

เฉลย

ตอบ B — keyword guarantee = ต้อง preventive (บล็อกก่อนทำ) → SCP; ทุก account + least ops + account ใหม่ inherit → วางที่ OU root ผ่าน Control Tower (บทที่ 02). ใช้ NotAction ยกเว้น global service (IAM/CloudFront/Route 53) ตามตัวอย่าง SCP บทที่ 02

• A ผิด — Config เป็น detective ตรวจ หลัง เกิด ไม่ guarantee/prevent; remediate มี lag
• C ผิด — IAM policy ต่อ user 200 account = operational overhead มหาศาล และ user ใหม่/root ยังหลุดได้; SCP ครอบทั้ง account
• D ผิด — Firewall Manager คุม WAF/Shield/SG/Network Firewall ไม่ใช่ guardrail จำกัด region ของ API call

Scenario 2 — Cross-account data access (Domain 1, security + IAM)

โจทย์: account A มี S3 bucket ที่ต้องให้ IAM role ใน account B อ่านได้ ทีมเปิด bucket policy ให้ principal ของ account B แล้ว แต่ยังเข้าไม่ได้ ต้องเพิ่มอะไร?

A. ไม่ต้องเพิ่ม — bucket policy พอแล้ว B. เพิ่ม identity-based policy ใน role ของ account B ให้ allow s3:GetObject บน bucket นั้น C. เปิด public access ที่ bucket D. สร้าง VPC peering ระหว่างสอง account

เฉลย

ตอบ B — cross-account access ต้องผ่าน ทั้งสองฝั่ง (AND): resource policy ฝั่ง A และ identity policy ฝั่ง B (บทที่ 03). เปิด bucket policy อย่างเดียวไม่พอ

• A ผิด — same-account เป็น OR/union แต่ cross-account เป็น AND — ต้องมี identity policy ฝั่ง B ด้วย
• C ผิด — public access ละเมิด least privilege และไม่จำเป็น (over-exposed)
• D ผิด — S3 เป็น service endpoint ไม่เกี่ยว VPC peering; การเข้า S3 เป็นเรื่อง IAM/bucket policy ไม่ใช่ network path

Scenario 3 — Networking CIDR overlap หลัง M&A (Domain 1&2)

โจทย์: บริษัทควบรวมอีกบริษัท ทั้งสองมี VPC CIDR ทับกัน (10.0.0.0/16 เหมือนกัน) บริษัทแม่ต้องเข้าถึง เพียง payroll application เดียวของบริษัทลูกแบบ private โดย ไม่ re-IP แนวทางใด?

A. VPC peering ระหว่างสอง VPC B. Transit Gateway เชื่อมทั้งสอง C. PrivateLink — บริษัทลูก expose payroll app หลัง NLB เป็น endpoint service, บริษัทแม่สร้าง interface endpoint D. re-IP VPC ของบริษัทลูกใหม่ทั้งหมด

เฉลย

ตอบ C — CIDR overlap + เข้าถึงแค่ 1 service + ไม่ re-IP = PrivateLink (บทที่ 04). endpoint service ทำงาน per-service ไม่ต้อง route ทั้ง CIDR จึงไม่สน overlap

• A ผิด — peering ต้อง CIDR ไม่ overlap — ใช้ไม่ได้เลย
• B ผิด — TGW ก็ต้อง route CIDR ไม่ overlap เช่นกัน
• D ผิด — re-IP ทั้ง VPC = operational overhead/risk สูงมาก และโจทย์บอก ไม่ re-IP

Scenario 4 — Decoupled ingestion ที่ต้อง order + no loss (Domain 2)

โจทย์: ระบบรับ event จาก IoT ปริมาณสูง ต้องประมวลผล ตามลำดับต่ออุปกรณ์ และ ห้ามสูญหาย แม้ downstream ล่มชั่วคราว มีหลาย consumer ต้องได้ event เดียวกันเพื่อทำงานต่างกัน แนวทางใด?

A. SNS standard topic → หลาย Lambda โดยตรง B. SNS FIFO topic → หลาย SQS FIFO queue (fan-out) แต่ละ queue มี consumer ของตัวเอง + DLQ C. Kinesis Data Firehose → S3 อย่างเดียว D. เขียนตรงเข้า DynamoDB จากทุก device

เฉลย

ตอบ B — ตามลำดับ → FIFO; หลาย consumer ได้ event เดียวกัน → fan-out (SNS→SQS, บทที่ 05); ห้ามสูญหาย + downstream ล่ม → SQS buffer + DLQ; ordering ต่ออุปกรณ์ทำผ่าน MessageGroupId

• A ผิด — SNS→Lambda ตรงไม่มี buffer ถ้า Lambda ล่ม/throttle event หาย และ standard ไม่การันตี order
• C ผิด — Firehose→S3 ไม่ตอบ multi-consumer processing แบบ independent และไม่ใช่ ordering per-device
• D ผิด — เขียนตรง DynamoDB ไม่ decouple, ไม่ buffer, downstream ล่มก็กระทบ ingestion

Scenario 5 — Cross-domain: cost + performance ของ compute steady + spiky (Domain 2&3)

โจทย์: web tier มี baseline คงที่ 24/7 ประมาณ 20 instance และมี spike ช่วง campaign เพิ่มอีก 80 instance แบบคาดเดายาก ต้องการ most cost-effective โดยไม่กระทบ availability แนวทางใด?

A. On-Demand ทั้ง 100 instance B. Reserved Instances ทั้ง 100 C. Compute Savings Plans ครอบ baseline 20 + Spot ผ่าน ASG mixed instances สำหรับ spike (capacity-optimized) + On-Demand base เผื่อ D. Spot ทั้ง 100

เฉลย

ตอบ C — baseline คงที่ → commitment (Compute Savings Plans, ยืดหยุ่นสุด, บทที่ 10); spike คาดเดายาก + fault-tolerant → Spot capacity-optimized ผ่าน ASG mixed instances (บทที่ 05/10); On-Demand base เล็กเผื่อ Spot ถูก reclaim

• A ผิด — On-Demand ทั้งหมดแพงสุดสำหรับ baseline คงที่ (ไม่ cost-effective)
• B ผิด — RI/SP สำหรับ 100 instance รวม spike ที่ไม่คงที่ = จ่าย commitment เกินความจำเป็น (over-commit)
• D ผิด — Spot ทั้งหมดรวม baseline critical เสี่ยง reclaim พร้อมกันกระทบ availability

Scenario 6 — DR ที่ต้อง RPO ต่ำ + budget จำกัด (Domain 3, resilience)

โจทย์: แอป critical ต้อง survive region failure, RPO ≤ 1 นาที แต่ธุรกิจยอม RTO ได้ถึง ~30 นาที และต้องการ cost-effective (ไม่จ่ายรัน full stack สอง region) database เป็น Aurora แนวทางใด?

A. Multi-Site Active-Active สอง region B. Aurora Global Database (secondary read-only) + app tier แบบ Pilot Light (ปิดไว้, launch template/ASG พร้อม scale) + Route 53 failover C. Backup & Restore ข้าม region ด้วย AWS Backup D. Multi-AZ ใน region เดียว

เฉลย

ตอบ B — RPO≤1 นาที → Aurora Global Database (RPO<1s, บทที่ 07/08); RTO ~30 นาทียอมได้ + cost จำกัด → Pilot Light (DB สด, app ปิดรอ scale, บทที่ 08)

• A ผิด — Active-Active ให้ RTO≈0 ที่ เกินความต้องการ (RTO 30 นาทีก็พอ) และแพงสุด (over-engineered)
• C ผิด — Backup & Restore ให้ RPO/RTO เป็นชั่วโมง ไม่ผ่าน RPO≤1 นาที
• D ผิด — Multi-AZ แก้ AZ failure เท่านั้น ไม่ survive region failure (บทที่ 08)

Scenario 7 — Migration 7R + downtime constraint (Domain 4)

โจทย์: บริษัทมี 500 VM บน VMware ต้องปิด data center ใน 6 เดือน ส่วนใหญ่เป็น commercial app ที่ cannot modify code มี database Oracle 3 ตัวที่อยากย้ายไป managed แนวทางรวมที่ เหมาะสุด?

A. Refactor ทุก app เป็น microservices ก่อนย้าย B. Rehost VM ส่วนใหญ่ด้วย MGN (หรือ Relocate ผ่าน VMware Cloud on AWS สำหรับ bulk) + Replatform Oracle → RDS/Aurora ด้วย DMS+SCT; จัด wave ตาม dependency C. Retain ทุกอย่างไว้ที่ data center D. Repurchase ทุก app เป็น SaaS

เฉลย

ตอบ B — cannot modify code + deadline 6 เดือน → Rehost (MGN) เป็นหลัก (บทที่ 12); Oracle → managed = Replatform ด้วย DMS full load+CDC (heterogeneous → SCT ก่อน, บทที่ 07); wave planning ตาม dependency (บทที่ 12)

• A ผิด — Refactor 500 app ใน 6 เดือน + cannot modify code = เป็นไปไม่ได้; ควร migrate-then-modernize (บทที่ 13)
• C ผิด — data center ต้องปิด, Retain ไม่ตอบโจทย์
• D ผิด — Repurchase ทุก app ไม่สมจริง (ไม่ทุก app มี SaaS เทียบเท่า) + เวลาน้อย

Scenario 8 — Cross-domain: security + networking (Domain 1,2,3)

โจทย์: องค์กรต้องการให้ทุก workload เข้าถึง S3 ได้เฉพาะ bucket ภายใน organization เท่านั้น (prevent data exfiltration ไป bucket ภายนอก) และ traffic ต้องไม่ออก internet แนวทางใด?

A. Security Group จำกัด outbound port 443 B. Gateway endpoint สำหรับ S3 + endpoint policy จำกัด aws:PrincipalOrgID/resource เฉพาะ bucket ใน org + SCP/RCP กัน principal ใช้ bucket ภายนอก (data perimeter) C. NAT Gateway + WAF D. เปิด public S3 access เฉพาะ IP office

เฉลย

ตอบ B — ไม่ออก internet → Gateway endpoint (private, ฟรี, บทที่ 04); prevent exfiltration ไป bucket ภายนอก → data perimeter ด้วย endpoint policy + resource condition aws:PrincipalOrgID + RCP (บทที่ 09)

• A ผิด — SG port 443 ไม่แยกแยะ bucket ภายใน/ภายนอก org (คุมแค่ port/IP ไม่ใช่ identity/resource)
• C ผิด — NAT+WAF ยังออก internet และ WAF เป็น L7 inbound ไม่กัน exfiltration ไป S3 ภายนอก
• D ผิด — public access เพิ่ม attack surface, ตรงข้ามเป้าหมาย

Scenario 9 — Observability + operational excellence (Domain 3)

โจทย์: microservices บน ECS Fargate หลายสิบ service มีปัญหา latency สูงเป็นครั้งคราวแต่หา service ต้นเหตุไม่เจอ ทีมต้องการ least operational overhead ในการ pinpoint bottleneck ข้าม service แนวทางใด?

A. เพิ่ม CloudWatch metric alarm บน CPU ทุก service B. เปิด X-Ray/ADOT tracing + ServiceLens service map เพื่อ correlate trace→metric→log C. เขียน log ทุก service ไป S3 แล้ว grep เอง D. เพิ่ม instance size ทุก service

เฉลย

ตอบ B — หา bottleneck ข้าม service = distributed tracing (เสาที่สามของ observability, บทที่ 11) → X-Ray/ADOT + ServiceLens; least ops เพราะ managed

• A ผิด — metric alarm บอก “มีปัญหา” แต่ไม่บอก “service ไหนในเส้น request” (metric ≠ trace, บทที่ 11)
• C ผิด — grep log เองเป็น operational overhead สูงและช้า; ใช้ Logs Insights/tracing แทน
• D ผิด — เพิ่ม size แบบไม่รู้ต้นเหตุ = สิ้นเปลืองและไม่แก้ปัญหา (ตรงข้าม right-size)

Scenario 10 — Cross-domain: migration + resilience + cost (Domain 2,3,4)

โจทย์: หลัง rehost แอปขึ้น EC2 แล้ว ธุรกิจต้องการ (1) DR ข้าม region ที่ cost-effective, (2) database MySQL ที่ HA และ scale reads ได้, (3) ลด cost compute steady-state ทั้งหมดนี้ least operational overhead แนวทางชุดใด?

A. DRS สำหรับ DR + Aurora MySQL (Multi-AZ + read replica) + Compute Savings Plans B. สร้าง region สองแบบ manual snapshot + self-managed MySQL บน EC2 + On-Demand C. Multi-AZ อย่างเดียว + RDS single-AZ + Spot ทั้งหมด D. Active-Active สอง region + DynamoDB Global Tables + RI ทั้งหมด

เฉลย

ตอบ A — DR ต่อเนื่อง cost-effective ระดับ server → DRS (บทที่ 08/12); MySQL HA + scale reads + least ops → Aurora MySQL (Multi-AZ + Aurora Replica, บทที่ 07); steady-state compute cost → Compute Savings Plans (บทที่ 10)

• B ผิด — self-managed MySQL + manual snapshot = operational overhead สูง, On-Demand ไม่ cost-effective
• C ผิด — Multi-AZ ไม่ใช่ DR ข้าม region; single-AZ RDS ไม่ HA; Spot สำหรับ steady-state critical เสี่ยง
• D ผิด — Active-Active + Global Tables เกินความต้องการ (โจทย์ไม่ขอ RTO≈0/active-active) และ MySQL→DynamoDB เปลี่ยน data model โดยไม่จำเป็น (over-engineered)

---

5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ — Distractor Patterns & Traps รวมทั้งเล่ม

หมวดนี้รวบรวม trap ที่ปรากฏซ้ำในส่วน “ข้อผิดพลาดที่พบบ่อย” ของทุกบท จัดกลุ่มเป็น pattern ที่ควรจำเป็นสัญชาตญาณ

5.1 กับดักเชิง mindset (จากบทที่ 01)

1. Over-engineering — เลือกตัวเลือกที่ “แน่นหนาที่สุด” ทั้งที่ keyword ไม่ได้ขอ (เช่น Multi-Site Active-Active ทั้งที่ RTO 30 นาทีก็พอ) ระดับ Pro ให้เลือกตัวที่ พอดีกับ requirement
2. Under-engineering — เลือกตัวถูกสุด/ง่ายสุดที่ละเมิด constraint (เช่น Multi-AZ ตอบโจทย์ region failure)
3. อ่านไม่ครบ constraint — พลาด keyword เดียวท้ายโจทย์ (cannot modify code, without downtime) ที่พลิกคำตอบ — ใช้ requirement-first reading
4. สับสน “ทำงานได้” กับ “ตรงที่สุด” — distractor ทำงานได้จริง แต่ไม่ตรง keyword/pillar ที่เน้น

5.2 กับดักคู่คำที่สับสนบ่อย (cross-chapter)

คู่ที่สับสน	แยกอย่างไร	บทเจ้าของ
RTO vs RPO	RTO = downtime (มองหน้า); RPO = data loss (มองหลัง)	08
Multi-AZ vs Multi-Region	AZ failure/HA/sync vs region failure/DR/async	07,08
Multi-AZ standby vs read replica	standby ไม่รับ read (HA); replica รับ read (scale)	07
MGN vs DRS	migrate ครั้งเดียว/decommission vs DR ต่อเนื่อง/failback	08,12
Migration Evaluator vs Compute Optimizer	pre-migration TCO vs post-migration right-size	12
SCP vs IAM policy	SCP = guardrail ไม่ให้สิทธิ์เอง; IAM = grant	02,03
preventive vs detective	SCP/IAM/WAF (บล็อก) vs Config/GuardDuty (ตรวจ)	01,02,09
Gateway vs Interface endpoint	S3/DynamoDB ฟรี vs service อื่น มีค่าใช้จ่าย	04
peering vs TGW	non-transitive 1:1 vs transitive hub	04
CloudFront vs Global Accelerator	L7/cache/HTTP vs L4/static IP/non-HTTP	04
ALB vs NLB	L7 path/host vs L4 static IP/UDP/preserve source	05
SQS vs SNS vs EventBridge	buffer vs fan-out vs content routing/SaaS	05
Standard vs Express Step Functions	long-running/audit vs high-volume/สั้น	05
Aurora Global DB vs DynamoDB Global Tables	single-writer RPO<1s vs multi-active	07
Cognito vs Identity Center vs Directory Service	customer vs workforce vs AD workload	03
Secrets Manager vs Parameter Store	native rotation vs ฟรี/ไม่ rotation	09
KMS vs CloudHSM	managed multi-tenant vs single-tenant/FIPS L3	09
Savings Plans vs RI	flexibility vs capacity guarantee (zonal RI/ODCR)	10
metric filter vs subscription filter	log→metric vs log→Kinesis/OpenSearch stream	11
Object Lock Governance vs Compliance	override ได้ vs ลบไม่ได้แม้ root	06

5.3 กับดักเชิงบริการที่ข้อสอบชอบซ่อน

• SCP ไม่มีผลกับ management account — ห้ามรัน workload ที่นั่น (บทที่ 02)
• SCP ไม่ให้สิทธิ์เอง — effective = SCP allow ∩ IAM allow; ต้องมี identity policy ด้วย (บทที่ 02/03)
• cross-account resource access = AND — ทั้ง resource policy และ identity policy (บทที่ 03)
• RDS encryption at rest เปิดหลังสร้างไม่ได้ — ต้อง snapshot + copy encrypted + restore (บทที่ 09)
• Savings Plans ไม่ครอบ RDS/Redshift/ElastiCache — ต้อง Reserved แยก (บทที่ 10)
• Savings Plans/regional RI ไม่การันตี capacity — ต้อง zonal RI/ODCR (บทที่ 10)
• memory/disk ไม่ใช่ standard CloudWatch metric — ต้อง unified agent (บทที่ 11)
• DynamoDB LSI สร้างได้เฉพาะตอนสร้าง table; GSI เพิ่มภายหลังได้ (บทที่ 07)
• VPC peering non-transitive + ห้าม CIDR overlap (บทที่ 04)
• Multi-AZ standby ไม่รับ read — ต้องการ scale reads ใช้ replica (บทที่ 07)
• DNS failover ติด TTL — ต้องการ failover เร็ว deterministic ใช้ Global Accelerator/ARC (บทที่ 08)
• Object Lock/Vault Lock ต้องเปิด versioning และ Compliance mode ลบไม่ได้แม้ root (บทที่ 06/08)
• modernize โดยไม่มี business driver / deadline สั้น = กับดัก — ตอบ migrate-then-modernize (บทที่ 13)

---

6. คำถามทบทวน

ข้อ 1. โจทย์ระบุ fully managed, virtually unlimited scale, key-value access, single-digit millisecond latency ควรเลือก database ใด?

A. Amazon RDS MySQL B. Amazon DynamoDB C. Amazon Redshift D. Amazon Aurora

เฉลย

ตอบ B — key-value + unlimited scale + single-digit ms + fully managed = DynamoDB (บทที่ 07)

• A ผิด — RDS relational มี connection/scale ceiling ไม่ใช่ unlimited key-value
• C ผิด — Redshift เป็น OLAP warehouse ไม่ใช่ low-latency key-value
• D ผิด — Aurora relational; แม้ scale ดีแต่ไม่ใช่ key-value unlimited แบบ DynamoDB

ข้อ 2. ต้องการเชื่อม 40 VPC ข้าม 15 account ให้ route หากันได้แบบ transitive และ segment traffic ระหว่างกลุ่ม prod/nonprod ควรใช้?

A. VPC peering full mesh B. Transit Gateway + TGW route tables + RAM sharing C. PrivateLink ทุกคู่ D. VPN ระหว่างทุก VPC

เฉลย

ตอบ B — scale + transitive + segmentation = Transit Gateway (route table แยก prod/nonprod), แชร์ข้าม account ด้วย RAM (บทที่ 03/04)

• A ผิด — peering non-transitive + full mesh 40 VPC = 780 คู่ ไม่ scale
• C ผิด — PrivateLink เหมาะ expose per-service ไม่ใช่ route ทั้ง VPC หากันทั่ว
• D ผิด — VPN mesh ระหว่างทุก VPC ซับซ้อนและ bandwidth จำกัด

ข้อ 3. แอป critical ต้อง no data loss (RPO≈0) เมื่อ AZ ล่ม database เป็น RDS PostgreSQL ควรใช้?

A. Read replica ใน AZ อื่น B. Multi-AZ deployment (synchronous standby) C. Snapshot ทุกชั่วโมง D. Multi-Region read replica

เฉลย

ตอบ B — no data loss + AZ failure = Multi-AZ synchronous (RPO≈0, บทที่ 07/08)

• A ผิด — read replica เป็น async มี lag → RPO>0 (data loss ได้)
• C ผิด — snapshot รายชั่วโมง RPO ถึง 1 ชม.
• D ผิด — cross-region replica async แก้ region ไม่ใช่ AZ และยัง RPO>0

ข้อ 4. ต้องการ most cost-effective สำหรับ batch job ที่ fault-tolerant และ restart ได้ ควรใช้ pricing model ใด?

A. On-Demand B. Standard Reserved Instances C. Spot Instances (capacity-optimized) ผ่าน ASG D. Dedicated Host

เฉลย

ตอบ C — fault-tolerant batch = Spot ~90% off, capacity-optimized ลด interruption (บทที่ 05/10)

• A ผิด — On-Demand แพงสุดสำหรับงานที่ทน interruption ได้
• B ผิด — RI สำหรับ steady-state ไม่ใช่ batch ชั่วคราว (จ่าย commitment เกิน)
• D ผิด — Dedicated Host แพงและเกินความจำเป็น

ข้อ 5. ต้องการ prevent ไม่ให้ member account ปิด CloudTrail และ detect resource ที่ไม่เข้ารหัส ควรใช้อะไรตามลำดับ?

A. Config rule ทั้งสอง B. SCP (deny cloudtrail:StopLogging) + Config rule detect unencrypted C. IAM policy + GuardDuty D. SCP ทั้งสอง

เฉลย

ตอบ B — prevent = SCP (preventive); detect = Config rule (detective) (บทที่ 01/02/09)

• A ผิด — Config detect ได้ แต่ prevent ปิด CloudTrail ไม่ได้ (detective ไม่บล็อก)
• C ผิด — IAM ไม่ครอบทั้ง account เท่า SCP; GuardDuty ตรวจ threat behavior ไม่ใช่ encryption compliance
• D ผิด — SCP prevent ได้ แต่ detect unencrypted resource เป็นงานของ Config ไม่ใช่ SCP

ข้อ 6. บริษัทมี SQL Server on-prem อยากย้ายไป AWS โดย minimize license cost และ minimal code change ควรทำอย่างไร?

A. Rehost ขึ้น EC2 พร้อม SQL Server license เดิม B. Migrate ไป Aurora PostgreSQL ด้วย Babelfish (รัน SCT assessment ก่อน) C. Refactor เป็น microservices + DynamoDB D. Retain ไว้ on-prem

เฉลย

ตอบ B — minimize license (เลิก SQL Server license) + minimal code change = Babelfish for Aurora PostgreSQL (T-SQL/TDS compat, บทที่ 07/13)

• A ผิด — ยังจ่าย SQL Server license (ไม่ minimize license)
• C ผิด — Refactor + เปลี่ยน data model = code change มหาศาล (ตรงข้าม minimal)
• D ผิด — Retain ไม่ย้าย ไม่ตอบโจทย์

ข้อ 7. ต้องการเก็บ log แบบ immutable เพื่อ compliance ป้องกันแม้ admin/root ลบ ควรใช้?

A. S3 Standard + bucket policy deny delete B. S3 + Object Lock Compliance mode (versioning เปิด) หรือ AWS Backup Vault Lock Compliance C. S3 Glacier D. EBS snapshot

เฉลย

ตอบ B — immutable + ลบไม่ได้แม้ root = Object Lock Compliance mode / Vault Lock Compliance (WORM, บทที่ 06/08)

• A ผิด — bucket policy admin/root แก้ได้ ไม่ immutable จริง
• C ผิด — Glacier ถูกแต่ไม่ได้ให้ WORM/immutability โดยตัวเอง
• D ผิด — EBS snapshot ไม่ใช่ WORM immutable log store

ข้อ 8. microservices ต้อง orchestrate workflow หลายขั้นที่มี audit trail และรันได้นานเป็นชั่วโมง มี compensating action เมื่อ step ล้ม ควรใช้?

A. Step Functions Standard (Saga pattern) B. Step Functions Express C. SQS chain D. Lambda เรียก Lambda ต่อกันเอง

เฉลย

ตอบ A — long-running + audit + compensating = Step Functions Standard + Saga (บทที่ 05/13)

• B ผิด — Express จำกัด 5 นาที ไม่มี history เต็ม (สำหรับ high-volume สั้น)
• C ผิด — SQS chain ไม่มี orchestration/audit/compensation ในตัว
• D ผิด — Lambda เรียกกันเองไม่มี state management/retry/audit ที่ชัด (glue code เยอะ)

ข้อ 9. ต้องการ shell เข้า EC2 ใน private subnet โดย no bastion, no inbound port, มี audit log ควรใช้?

A. เปิด SSH port 22 จาก office IP B. SSM Session Manager C. ตั้ง bastion host D. VPN + SSH

เฉลย

ตอบ B — no bastion/no inbound + audit = SSM Session Manager (บทที่ 11)

• A ผิด — เปิด port 22 = inbound port (ตรงข้าม no inbound)
• C ผิด — bastion = สิ่งที่โจทย์บอก no
• D ผิด — VPN+SSH ยังต้องเปิด port และไม่ least ops

ข้อ 10. ต้องการ DR สำหรับ physical/virtual server หลากหลาย OS แบบ continuous replication RPO วินาที และ failback ได้ ควรใช้?

A. AWS Application Migration Service (MGN) B. AWS Elastic Disaster Recovery (DRS) C. AWS Backup D. Aurora Global Database

เฉลย

ตอบ B — DR ต่อเนื่อง + RPO วินาที + failback = DRS (บทที่ 08/12)

• A ผิด — MGN สำหรับ migration ครั้งเดียว + decommission source ไม่ใช่ DR ต่อเนื่อง/failback
• C ผิด — Backup ให้ RPO เป็นชั่วโมง ไม่ใช่ continuous วินาที
• D ผิด — Aurora Global DB เฉพาะ Aurora database ไม่ครอบ server ทั้งเครื่องหลาย OS

ข้อ 11. (multiple response — เลือก 2) ต้องการลด data transfer cost และเข้าถึง S3/DynamoDB แบบ private จาก VPC ควรทำอะไร (เลือกสอง)?

A. สร้าง Gateway endpoint สำหรับ S3 B. สร้าง Gateway endpoint สำหรับ DynamoDB C. เพิ่ม NAT Gateway D. เปิด public IP ให้ทุก instance

เฉลย

ตอบ A และ B — Gateway endpoint (S3, DynamoDB) ฟรี + private + ลด NAT/egress cost (บทที่ 04/06/10)

• C ผิด — NAT Gateway เพิ่ม cost (per-GB) และ traffic ยังออก path ที่คิดเงิน
• D ผิด — public IP เพิ่ม attack surface และไม่ลด transfer cost/ไม่ private

ข้อ 12. องค์กรต้องการ enforce ให้ทุก account ใหม่ที่ join OU ได้รับ baseline security (CloudTrail, Config, guardrails) อัตโนมัติ least operational overhead ควรใช้?

A. เขียน script ตั้งค่าเองทุก account B. AWS Control Tower (Account Factory + guardrails) บน Organizations C. CloudFormation รันมือทีละ account D. IAM Identity Center อย่างเดียว

เฉลย

ตอบ B — landing zone อัตโนมัติ + guardrails + account ใหม่ enroll ได้ทันที = Control Tower (บทที่ 02)

• A ผิด — script เองไม่ least ops และ drift ง่าย
• C ผิด — รัน CFN มือทีละ account ไม่ scale (StackSets service-managed ดีกว่า แต่ Control Tower ครอบทั้ง baseline)
• D ผิด — Identity Center เป็นแค่ SSO ไม่ใช่ baseline security landing zone ทั้งชุด

---

7. Cross-references

บทนี้เป็นบทสังเคราะห์ จึงอ้างอิงกลับทุกบท — ใช้เป็นดัชนีทบทวนเชิงลึกและ keyword cheat sheet สุดท้ายก่อนสอบ

7.1 ดัชนีบทเจ้าของเนื้อหา (ทบทวนเชิงลึก)

• บทที่ 01 — Exam blueprint, keyword→pillar mapping, requirement-first reading, เทคนิคตัดตัวเลือก 5 ขั้น, over/under-engineering (รากฐานของทุก scenario ในบทนี้)
• บทที่ 02 — Organizations/OU/SCP, Control Tower, preventive vs detective vs proactive (Scenario 1, 12)
• บทที่ 03 — IAM evaluation, cross-account AND, Identity Center/Cognito/Directory Service (Scenario 2)
• บทที่ 04 — VPC/CIDR, peering/TGW/PrivateLink, DX/VPN, endpoints, CloudFront vs GA (Framework 3, Scenario 3, 8, 11)
• บทที่ 05 — Lambda/Fargate/EKS/EC2, ALB/NLB/GWLB, SQS/SNS/EventBridge/Step Functions (Framework 2, Scenario 4, 5, 8)
• บทที่ 06 — S3 classes/Object Lock, EBS/EFS/FSx, DataSync/Snow (Framework 6, Scenario 7 question)
• บทที่ 07 — database category, Multi-AZ vs replica, Aurora Global DB, DynamoDB, DMS/SCT (Framework 1, Scenario 6, 10)
• บทที่ 08 — RTO/RPO, 4 DR strategies, Multi-AZ vs Multi-Region, DRS vs MGN, ARC (Framework 4, Scenario 6, 10)
• บทที่ 09 — KMS/CloudHSM, Secrets vs Parameter Store, GuardDuty/Config/Macie, data perimeter (Scenario 8, 12)
• บทที่ 10 — On-Demand/Savings Plans/RI/Spot, cost governance, right-size (Framework 2, Scenario 5, 10)
• บทที่ 11 — observability 3 เสา, SSM, IaC/StackSets, deployment strategies (Scenario 9)
• บทที่ 12 — CAF/7 Rs/MGN/discovery/wave planning (Framework 5, Scenario 7)
• บทที่ 13 — strangler fig, A2C, serverless refactor, Babelfish, migrate-then-modernize (Scenario 7, ข้อ 6)

7.2 Keyword → Service Cheat Sheet (lookup สุดท้าย)

keyword ในโจทย์	บริการ/แนวทางที่มักเป็นคำตอบ
least operational overhead, fully managed	serverless/managed: Fargate, Lambda, Aurora Serverless, S3 Intelligent-Tiering, Control Tower
most cost-effective, reduce cost	Spot, Savings Plans, tiered storage, gateway endpoint, right-size (Compute Optimizer)
real-time, streaming	Kinesis Data Streams, DynamoDB Streams
near real-time, load เข้า store อัตโนมัติ	Kinesis Data Firehose
sub-millisecond / microsecond read	ElastiCache / DAX (บน DynamoDB)
single-digit millisecond key-value	DynamoDB
decouple / buffer	SQS (point-to-point), SNS (fan-out), EventBridge (routing)
no data loss / RPO≈0	synchronous replication: Multi-AZ, Aurora
minimal downtime migration	DMS full load + CDC; RDS Blue/Green
minimal downtime deployment	blue/green, canary + auto-rollback
survive region failure / disaster recovery	Multi-Region + 1 ใน 4 DR strategies; DRS
highly available / survive AZ failure	Multi-AZ, ASG across AZ
static IP + non-HTTP / fast failover	Global Accelerator
cache static content / L7 edge	CloudFront
CIDR overlap + 1 service	PrivateLink
transitive / hub หลาย VPC	Transit Gateway
dedicated bandwidth hybrid	Direct Connect
immutable / WORM / regulatory	S3 Object Lock / Backup Vault Lock (Compliance)
encrypt + control key/rotate/audit	KMS customer managed key
single-tenant HSM / FIPS L3	CloudHSM
rotate credential automatically	Secrets Manager
detect threat behavior	GuardDuty
sensitive data / PII discovery in S3	Macie
CVE vulnerability scan	Inspector
config compliance	AWS Config
prevent / block (guardrail)	SCP / IAM / WAF
DDoS protection + cost protection	Shield Advanced
no bastion shell	SSM Session Manager
distributed bottleneck / trace	X-Ray / ServiceLens
cannot modify code	ตัด Refactor → Rehost/Replatform
lift-and-shift	Rehost (MGN)
tight deadline + modernize	migrate-then-modernize
incrementally decompose monolith	strangler fig + Refactor Spaces
air-gapped / offline petabyte	Snow Family
external partner SFTP	Transfer Family
corporate AD / workload domain join	Directory Service (Managed Microsoft AD)
existing IdP / workforce SSO	IAM Identity Center
app end-user sign-in	Cognito
guarantee capacity	zonal RI / ODCR

7.3 Final Readiness Checklist ก่อนสอบ

ความรู้เชิงบริการ (ต้องแยกคู่สับสนได้ทันที):

• แยก RTO vs RPO, Multi-AZ vs Multi-Region, standby vs read replica ได้ทันที
• แยก MGN vs DRS, Migration Evaluator vs Compute Optimizer
• แยก SCP vs IAM, preventive vs detective vs responsive
• แยก Savings Plans vs RI (และรู้ว่า SP ไม่ครอบ RDS/Redshift/ElastiCache)
• แยก gateway vs interface endpoint, peering vs TGW vs PrivateLink, CloudFront vs GA
• แยก ALB vs NLB vs GWLB, SQS vs SNS vs EventBridge vs Step Functions
• เดิน 6 decision frameworks (database/compute/connectivity/DR/migration/storage) ได้จากความจำ
• จำ 7 Rs และ keyword → R ได้ครบ
• จำ 4 DR strategies เรียงตาม cost/RTO/RPO ได้

เทคนิคทำข้อสอบ (บทที่ 01):

• ฝึก requirement-first reading — อ่านคำถามท้ายก่อนเสมอ
• จับ over/under-engineering — เลือกตัว “พอดี” ไม่ใช่ “แน่นสุด”
• จับ constraint ซ่อนท้ายโจทย์ (cannot modify code, without downtime, no data loss)
• multiple response = ต้องถูกครบทุกตัว (no partial credit)

กลยุทธ์วันสอบ (บทที่ 01):

• บริหารเวลา ~2.4 นาที/ข้อ (75 ข้อ / 180 นาที); flag ข้อยากไว้ก่อน กลับมาทีหลัง
• เกณฑ์ผ่าน 750/1000 (scaled/compensatory) — ไม่ต้องผ่านราย domain แต่ตอบให้ครบทุกข้อ (ไม่มีติดลบ)
• ตัดเหลือ 2 ตัวก่อนแล้วชั่ง trade-off ด้วย pillar ที่ keyword เน้น
• อ่านทุกตัวเลือกก่อนตอบ — ตัวที่ 4 อาจตรงกว่าตัวที่ 2

แนวทางทบทวนวันสุดท้าย:

1. อ่าน keyword → service cheat sheet (7.2) และตารางคู่สับสน (5.2) รอบเดียวให้ขึ้นใจ
2. ทวน 6 decision framework flowchart (ส่วนที่ 3) — ปิดตาเดินให้ได้
3. อย่าอ่านบริการใหม่ที่ไม่เคยเจอ — เสริมความมั่นใจในสิ่งที่รู้แล้ว
4. พักผ่อนให้พอ — ข้อสอบ 180 นาทีต้องใช้สมาธิต่อเนื่องยาว

สรุปแกนของทั้งเล่ม: SAP-C02 วัดการ เลือกที่ตรงที่สุดภายใต้ข้อจำกัด ไม่ใช่ท่องบริการ ทุกคำตอบคือการชั่ง trade-off ระหว่าง 6 pillars ตาม keyword ที่โจทย์เน้น — จับ keyword, จับ constraint, เดิน framework, ตัด distractor, ตรวจ trade-off แล้วเลือกตัวที่พอดี ขอให้สอบผ่าน