บทที่ 01: Exam Blueprint & SA-Pro Mindset

Domain: ทุก domain (meta) — บทนี้ไม่ได้สอนบริการรายตัว แต่วาง “กรอบคิด” และ “วิธีทำข้อสอบ” ที่จะใช้ตลอดทั้งเล่ม คำอธิบายเป็นไทย; ชื่อบริการ/ศัพท์เทคนิค/keyword ในโจทย์เป็นอังกฤษเสมอ

---

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

หลังอ่านบทนี้จบ คุณจะสามารถ:

• อธิบายโครงสร้างข้อสอบ SAP-C02 ได้ครบ: 4 domains กับน้ำหนัก, จำนวนข้อ, เวลา, เกณฑ์ผ่าน และความต่างระหว่าง multiple choice กับ multiple response
• “ถอดรหัส” keyword ที่บีบคำตอบในโจทย์ (เช่น least operational overhead, most cost-effective, minimal downtime) และรู้ว่าแต่ละคำมักชี้ไปทางบริการหรือแนวทางแบบใด
• ใช้เทคนิคตัดตัวเลือก (eliminate distractors) อย่างเป็นระบบ แม้ในกรณีที่ “ทุกตัวเลือกทำงานได้จริง” — ซึ่งเป็นลักษณะเฉพาะของข้อสอบระดับ Professional
• ใช้ AWS Well-Architected Framework 6 pillars เป็น “กรอบตัดสินใจ” (decision lens) ไม่ใช่แค่ท่องจำชื่อ pillar
• ปรับ mindset จากระดับ Associate (สั่งการเดี่ยว/เลือกบริการ) ไปสู่ระดับ Professional (ออกแบบระบบข้าม account/region/องค์กร พร้อม trade-off)
• บริหารเวลา 180 นาที และวางแผนเตรียมตัวเชิงกลยุทธ์ก่อนสอบ

บทนี้เป็น “meta-chapter” — เนื้อหาบริการเชิงลึกอยู่ในบท 02–13 ส่วนบท 14 จะนำกรอบคิดในบทนี้ไปประยุกต์กับ scenario เต็มรูปแบบ

---

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

2.1 โครงสร้างข้อสอบ SAP-C02

รายการ	รายละเอียด
รหัสข้อสอบ	SAP-C02 (ปัจจุบันแทน SAP-C01 ที่ปลดระวางแล้ว)
จำนวนข้อ	75 ข้อ — 65 ข้อนับคะแนน + 10 ข้อ unscored (ไม่ระบุว่าข้อไหน)
รูปแบบ	Multiple choice (เลือก 1 จาก 4) และ Multiple response (เลือก 2–3 จาก 5–6)
เวลา	180 นาที
คะแนน	scaled score 100–1000, ผ่านที่ 750
ประเภท	Associate-level prerequisite ไม่บังคับ แต่แนะนำประสบการณ์ 2+ ปีบน AWS
ค่าใช้จ่าย	ประมาณ 300 USD [uncertain: ราคาปรับได้]

จุดที่ต้องเข้าใจเชิงลึก:

• scaled score ไม่ใช่เปอร์เซ็นต์ตรง ๆ — 750/1000 ไม่ได้แปลว่าต้องตอบถูก 75% เพราะแต่ละข้อถ่วงน้ำหนักด้วย psychometric model และมี unscored questions ปน ดังนั้น “ตอบถูกกี่ข้อจึงผ่าน” ไม่มีเลขตายตัว ให้ตั้งเป้าความแม่นสูงเข้าไว้
• compensatory scoring — คะแนนรวมทั้งฉบับตัดสิน ไม่ต้องผ่านทีละ domain การอ่อน domain เดียวไม่ทำให้ตกทันทีถ้า domain อื่นชดเชยได้ แต่ก็ไม่ควรทิ้ง domain ใด domain หนึ่ง
• unscored questions — 10 ข้อที่ AWS ใช้ทดลอง (pretest) ไม่รู้ว่าข้อไหน จึงต้องทำทุกข้อเต็มที่เท่ากัน

น้ำหนัก 4 Domains

Domain	ชื่อ	น้ำหนัก	สาระสำคัญ
1	Design Solutions for Organizational Complexity	26%	multi-account, networking ข้าม org, identity/federation, governance
2	Design for New Solutions	29%	ออกแบบระบบใหม่จากศูนย์: compute/storage/db/security/resilience
3	Continuous Improvement for Existing Solutions	25%	ปรับปรุงของเดิม: performance, cost, reliability, operational excellence
4	Accelerate Workload Migration and Modernization	20%	ย้าย workload เข้า cloud + modernize (7 Rs, migration tools)

ข้อสังเกตเชิงกลยุทธ์: Domain 2 (29%) + Domain 1 (26%) รวมกันเกินครึ่ง (55%) และทั้งคู่เน้น “การออกแบบ” มากกว่าการปฏิบัติ ดังนั้นทักษะหลักที่ทำคะแนนคือ design & architect ไม่ใช่การจำคำสั่ง CLI

2.2 Multiple Choice vs Multiple Response

	Multiple choice	Multiple response
จำนวนตัวเลือก	4 (A–D)	5–6
จำนวนคำตอบที่ถูก	1	2 หรือ 3 (โจทย์จะบอกว่า “select TWO” / “select THREE”)
การให้คะแนน	ถูก/ผิด	ต้องถูก ครบทุกตัว จึงได้คะแนน — ไม่มีคะแนนบางส่วน (no partial credit)
กลยุทธ์	ตัด distractor ให้เหลือคำตอบที่ดีที่สุด	มองแต่ละตัวเลือกเป็นคำถาม true/false อิสระ

เหตุผลเชิงเทคนิค: multiple response มักรวมหลาย requirement (เช่น “ต้อง encrypt at rest และ ต้องมี audit trail”) การมองแต่ละตัวเลือกแยกกันว่า “ข้อนี้ตอบ requirement ไหน” ช่วยกันการเผลอเลือกตัวที่ถูกครึ่งเดียว

2.3 การถอดรหัส Keyword ในโจทย์ (Requirement Signals)

ข้อสอบ Professional จะไม่ถามว่า “บริการนี้คืออะไร” แต่จะให้ scenario ยาว แล้วปิดท้ายด้วย keyword ที่เป็น “เข็มทิศ” ชี้ไปยัง pillar หรือแนวทางที่ต้องให้น้ำหนัก ตารางนี้คือหัวใจของบท — ควรจำให้แม่น:

Keyword ในโจทย์	สิ่งที่โจทย์ให้ความสำคัญ	มักชี้ไปทาง
least operational overhead / least management effort / fully managed	ลดภาระ operations, ไม่อยากดูแล infra เอง	managed/serverless: Lambda, Fargate, Aurora Serverless, DynamoDB, S3, managed services > self-managed on EC2
most cost-effective / minimize cost	ต้นทุนต่ำสุดโดยยังตอบ requirement	Spot, S3 Glacier/Intelligent-Tiering, Savings Plans, serverless (จ่ายตามใช้), right-sizing
highest availability / most resilient / fault tolerant	ทนความล้มเหลว, ไม่ล่ม	Multi-AZ, Multi-Region, Auto Scaling, decoupling ด้วย queue, static stability
minimal downtime / no downtime (ตอน migrate/deploy)	ตัดช่วงหยุดบริการ	blue/green, canary, RDS/Aurora Blue-Green, DMS CDC (ongoing replication), read replica promotion
real-time / sub-second / low latency	ความเร็วตอบสนอง	Kinesis Data Streams, DynamoDB + DAX, ElastiCache, NLB, Global Accelerator, streaming (ไม่ใช่ batch)
near-real-time	ยอมหน่วงระดับวินาที–นาที	Kinesis Data Firehose, Lambda triggers
decouple / loosely coupled	ลด dependency ระหว่าง component	SQS, SNS, EventBridge, Step Functions
durable / no data loss (RPO=0)	ข้อมูลต้องไม่หาย	S3 (11 nines durability), synchronous replication, Aurora Global (RPO ต่ำ), Multi-AZ (sync)
secure / compliance / encrypt / audit	ความปลอดภัย/กำกับ	KMS, CloudTrail, Config, GuardDuty, SCP, least privilege
scalable / unpredictable / spiky traffic	รับโหลดที่คาดเดายาก	serverless, Auto Scaling, DynamoDB on-demand, decoupling
existing on-premises / hybrid	ยังต้องเชื่อม data center เดิม	Direct Connect, Site-to-Site VPN, Storage Gateway, Outposts
migrate with minimal changes / lift-and-shift	ย้ายเร็วโดยไม่แก้ app	Rehost (MGN), Replatform — ไม่ใช่ Refactor
global users / multiple regions	ผู้ใช้กระจายทั่วโลก	CloudFront, Route 53 latency/geo routing, Global Accelerator, DynamoDB Global Tables, Aurora Global

หลักการอ่านโจทย์แบบ requirement-first: อ่าน “คำถามตอนท้าย + keyword บีบ” ก่อน แล้วค่อยย้อนขึ้นไปอ่าน scenario โดยมองหาเฉพาะข้อเท็จจริงที่เกี่ยวกับ requirement นั้น วิธีนี้กัน “ข้อมูลหลอก” (red herring) ที่โจทย์ยัดมาเพื่อกินเวลา

กับดักสำคัญ: โจทย์มักมีหลาย keyword ขัดกัน เช่น “most cost-effective while ensuring highest availability” — ต้องหาคำตอบที่สมดุลทั้งคู่ ไม่ใช่ทุ่มไปทางเดียว ถ้ามีคำว่า while / and / but must ให้ถือเป็น constraint บังคับที่ห้ามละเมิด

2.4 เทคนิคตัดตัวเลือก (Eliminate Distractors)

ในข้อสอบ Professional บ่อยครั้ง ทุกตัวเลือก “ทำงานได้จริง” — ทั้ง 4 ตัวสร้างระบบที่ใช้งานได้ แต่มีแค่ตัวเดียวที่ “ดีที่สุดตาม keyword” กระบวนการตัดที่ใช้ได้ผล:

1. ตัดตัวที่ผิดข้อเท็จจริงเชิงเทคนิค (technically wrong) — เช่น “ใช้ VPC peering แบบ transitive” (peering ไม่ transitive — ดูบท 04), “ใช้ S3 เก็บ block storage สำหรับ boot volume” (ทำไม่ได้), “attach EBS volume ข้าม AZ” (ทำไม่ได้) ตัวเหล่านี้ตัดทิ้งได้ทันที
2. ตัดตัวที่ละเมิด constraint บังคับในโจทย์ — ถ้าโจทย์บอก “must not manage any servers” ให้ตัดทุกตัวเลือกที่มี EC2/self-managed ออก แม้จะทำงานได้
3. ตัดตัวที่ over-engineered เมื่อโจทย์ขอ least effort — ถ้าโจทย์ขอ least operational overhead แล้วมีตัวเลือกที่ต้องเขียน custom orchestration/บริหาร cluster เอง มักผิด
4. ตัดตัวที่ under-engineered เมื่อโจทย์ขอ resilience/scale — เช่น single-AZ, single instance เมื่อโจทย์ขอ high availability
5. เลือกตัวที่ “ตรง keyword ที่สุด” จากที่เหลือ — ถ้าเหลือ 2 ตัวที่ทำได้ทั้งคู่ ให้ถามว่า “ตัวไหนตอบ keyword บีบได้ดีกว่า (ถูกกว่า / จัดการน้อยกว่า / ทนกว่า)”

การจับ constraint ที่ซ่อนในโจทย์ยาว — constraint มักซ่อนในรายละเอียดที่ดูไม่สำคัญ:

• “a small team of two engineers” → บอกเป็นนัยว่าต้องการ low operational overhead (คนน้อย ดูแล infra เยอะไม่ไหว)
• “regulated financial data” / “HIPAA” → ต้อง encryption + audit + อาจต้อง data residency ใน region เดียว
• “existing SAML identity provider” → ต้องใช้ federation ผ่าน IAM Identity Center / SAML (ดูบท 03) ไม่ใช่สร้าง IAM user ใหม่
• “budget is a primary concern” ปนกับ “must handle Black Friday spikes” → ชี้ไป Spot + Auto Scaling หรือ serverless
• “cannot modify the application code” → ตัด Refactor/Re-architect ออก (ดูบท 12–13)

2.5 AWS Well-Architected Framework — 6 Pillars ในฐานะกรอบตัดสินใจ

Well-Architected Framework (WAF) คือ “ปรัชญาเบื้องหลังคำตอบที่ถูก” ของข้อสอบทุกข้อ เมื่อสองตัวเลือกสูสี ให้ถามว่า pillar ไหนที่โจทย์ให้น้ำหนัก แล้วเลือกตัวที่ align กับ pillar นั้น

Pillar	คำถามหลักของ pillar	สัญญาณในโจทย์	design principles สำคัญ
Operational Excellence	รัน/monitor/ปรับปรุงระบบได้ดีแค่ไหน	least operational overhead, automation, IaC, observability	ทำเป็นโค้ด (IaC), เปลี่ยนแบบเล็ก-ย้อนกลับได้, คาดการณ์ความล้มเหลว, เรียนรู้จาก failure
Security	ปกป้องข้อมูล/ระบบ/สิทธิ์อย่างไร	compliance, encrypt, audit, least privilege	least privilege, defense in depth, encrypt at rest/in transit, traceability, ป้องกันทุก layer
Reliability	ระบบฟื้นจากความล้มเหลว/รับโหลดได้ไหม	high availability, fault tolerant, RTO/RPO, disaster recovery	ฟื้นอัตโนมัติ, ทดสอบ recovery, horizontal scaling, หยุด guess capacity, จัดการ change ด้วย automation
Performance Efficiency	ใช้ทรัพยากรตรงกับความต้องการไหม	low latency, real-time, high throughput	ใช้ managed/advanced tech, go global in minutes, serverless, ทดลอง, mechanical sympathy (เลือก resource ให้ตรงงาน)
Cost Optimization	จ่ายเท่าที่จำเป็นไหม	most cost-effective, reduce cost	จ่ายตามใช้จริง, วัด efficiency, เลิก undifferentiated heavy lifting, วิเคราะห์ค่าใช้จ่าย, เลือก pricing model ที่ถูก
Sustainability	ลดผลกระทบสิ่งแวดล้อมไหม	minimize environmental impact, carbon	เลือก region ที่เหมาะ, right-size, ใช้ managed services (utilization สูง), เลิก resource ที่ไม่ใช้

การใช้จริงในห้องสอบ: WAF ไม่ได้บอก “คำตอบเดียว” แต่บอก “วิธีชั่งน้ำหนัก trade-off” เมื่อโจทย์บีบด้วย keyword หนึ่ง pillar หนึ่งจะเด่นขึ้น เช่น keyword “least operational overhead” = Operational Excellence + Cost นำ; keyword “no data loss” = Reliability นำ การรู้ว่า pillar ไหนกำลังนำช่วยตัดตัวเลือกที่ optimize ผิด pillar

Sustainability pillar เพิ่มเข้ามาภายหลัง (pillar ที่ 6) ในข้อสอบยังพบเป็นสัดส่วนน้อย แต่ควรรู้ว่ามันสนับสนุนคำตอบเดียวกับ Cost/Performance เสมอ (right-sizing, managed services, เลิก idle resource) — ไม่ค่อยมีข้อที่ให้เลือกระหว่าง Sustainability กับ pillar อื่นแบบขัดกันตรง ๆ

2.6 Mindset: Associate vs Professional

นี่คือหัวใจที่ทำให้คนสอบ Associate ผ่านมาแล้วตกที่ Professional — เพราะ “วิธีคิด” ต่างกันคนละระดับ

มิติ	Associate (SAA)	Professional (SAP)
ขอบเขต	บริการเดี่ยว/ระบบเดียว/account เดียว	ข้าม account, ข้าม region, ทั้งองค์กร (multi-account org)
ลักษณะคำถาม	“บริการไหนเหมาะกับงานนี้”	“สถาปัตยกรรมไหนดีที่สุดเมื่อชั่ง trade-off หลายด้าน”
ความยาวโจทย์	สั้น–กลาง	ยาวมาก (บางข้อ 1 ย่อหน้า+ constraint ซ้อน)
จำนวนบริการต่อข้อ	1–2	หลายบริการทำงานร่วมกัน
สิ่งที่วัด	ความรู้บริการ	การตัดสินใจเชิงสถาปัตยกรรม + governance + migration + cost ระดับองค์กร
ตัวอย่างประเด็น	“ใช้ ALB หรือ NLB”	“ออกแบบ connectivity ให้ 200 VPC ข้าม 50 account พร้อม centralized egress และ hybrid DX”

การปรับ mindset ที่ต้องทำ:

• คิดในระดับ organization ไม่ใช่ระดับ resource — ทุกคำตอบต้องถามว่า “scale ไปทั้ง org ได้ไหม จัดการรวมศูนย์ได้ไหม”
• ยอมรับว่า ไม่มีคำตอบสมบูรณ์แบบ มีแต่ trade-off — งานของ SA Pro คือเลือก trade-off ที่ตรงกับ business requirement ที่โจทย์ให้
• คิดเรื่อง blast radius, governance, cost ระดับองค์กร, migration path เสมอ ไม่ใช่แค่ “ระบบนี้ทำงานได้ไหม”

---

3. ตารางเปรียบเทียบบริการ

บทนี้เป็น meta-chapter จึงไม่เปรียบเทียบบริการรายตัว (นั่นเป็นหน้าที่บท 02–13) แต่ให้ตาราง “เปรียบเทียบเชิงกลยุทธ์การทำข้อสอบ” ที่ใช้ได้กับทุกข้อ

3.1 Keyword → Pillar ที่นำ → แนวคำตอบ

Keyword บีบ	Pillar ที่นำ	แนวคำตอบที่มัก “ถูก”	แนวคำตอบที่มัก “ผิด” (distractor)
least operational overhead	Operational Excellence	managed/serverless, automation	self-managed cluster, custom scripts, EC2 ที่ต้อง patch เอง
most cost-effective	Cost Optimization	Spot, tiered storage, Savings Plans, pay-per-use	over-provisioned, On-Demand ตลอด, Provisioned สูงเกิน
highest availability	Reliability	Multi-AZ/Region, Auto Scaling, decoupling	single-AZ, single instance, no failover
minimal downtime (migration/deploy)	Reliability + Ops	blue/green, canary, DMS CDC, replica promotion	stop-and-copy, big-bang cutover
real-time / low latency	Performance	streaming, in-memory cache, edge	batch, cron polling, cold-start heavy
secure / compliant	Security	least privilege, KMS, CloudTrail, SCP	broad IAM *, plaintext, hardcoded secrets

3.2 ประเภทกับดัก (Distractor) ที่พบบ่อยทั้งเล่ม

ประเภทกับดัก	ลักษณะ	วิธีจับ
Technically impossible	ตัวเลือกที่ AWS ทำไม่ได้จริง	ต้องรู้ข้อจำกัดบริการ (บท 02–13)
Right service, wrong config	บริการถูกแต่ตั้งค่าผิด (เช่น single-AZ ตอนขอ HA)	อ่าน keyword resilience/scale
Works but over-engineered	ซับซ้อนเกินเมื่อโจทย์ขอ least effort	จับ keyword least overhead
Works but expensive	แพงกว่าเมื่อโจทย์ขอ cost-effective	จับ keyword cost
Outdated/deprecated approach	วิธีเก่าที่ยังทำได้แต่มีตัวเลือก managed ใหม่กว่า	เลือก managed ล่าสุด
Ignores a stated constraint	ละเลย constraint ที่ซ่อนในโจทย์	requirement-first reading

---

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

เนื่องจากบทนี้เป็นเรื่อง “วิธีคิด” ตัวอย่างต่อไปนี้จึงเป็น “ตัวอย่างวิธีวิเคราะห์โจทย์” ไม่ใช่ blueprint สถาปัตยกรรม เพื่อสาธิตกระบวนการตัดสินใจแบบ SA Pro

ตัวอย่างที่ 1 — โจทย์ที่ทุกตัวเลือกทำงานได้ (การใช้ keyword ตัดสิน)

โจทย์ (ย่อ): บริษัทมีทีมวิศวกร 2 คน ต้องรัน batch job ประมวลผลรายวันที่ไม่เร่งด่วน ทนการหยุดกลางคันได้ ต้องการ most cost-effective solution

ตัวเลือกสมมติ:

• A) EC2 On-Demand instances รันตลอดเวลา
• B) EC2 Reserved Instances
• C) EC2 Spot Instances ใน Auto Scaling group
• D) Fargate On-Demand

การวิเคราะห์: ทุกตัวรัน batch ได้จริง แต่ keyword คือ most cost-effective + ข้อเท็จจริง “ไม่เร่งด่วน ทนหยุดกลางคันได้” (fault-tolerant, interruptible) — นี่คือลายเซ็นของ Spot (ดูบท 10) → ตอบ C

ทำไมตัวอื่นผิด:

• A ผิดเพราะ On-Demand แพงสุดและรันตลอดเวลา (ทั้งที่งานเป็นรายวัน) — ละเมิด cost
• B ถูกกว่า A แต่ RI เหมาะกับ workload คงที่ตลอดเวลา ไม่ใช่ batch เป็นครั้ง — และยังแพงกว่า Spot
• D Fargate ลด ops แต่โจทย์ไม่ได้เน้น ops และ Fargate Spot จะถูกกว่า Fargate On-Demand — ตัว D ที่ให้มาเป็น On-Demand จึงแพงกว่า C

Trade-off ที่ยอมรับ: เลือก Spot = ยอมรับความเสี่ยงถูก interrupt (2-min notice) แลกกับราคาถูกสุด ซึ่ง ยอมรับได้ เพราะโจทย์บอกงานทนหยุดได้ — ถ้าโจทย์เปลี่ยนเป็น “must complete by strict deadline” คำตอบจะเปลี่ยน

ตัวอย่างที่ 2 — โจทย์ที่ keyword ขัดกัน (การชั่ง trade-off สองด้าน)

โจทย์ (ย่อ): ระบบ e-commerce ต้องรองรับ traffic พุ่งช่วงโปรโมชัน (spiky, unpredictable) ทีมเล็ก ต้องการ minimize operational overhead และ cost-effective แต่ must not lose orders แม้ backend ล่ม

การวิเคราะห์: keyword สามชั้น — (1) least ops + cost → serverless, (2) spiky → auto scaling/serverless, (3) must not lose orders → decouple ด้วย durable queue คำตอบที่ align: API Gateway + Lambda + SQS (buffer) + Lambda/Fargate worker + DynamoDB on-demand

ทำไมออกแบบนี้:

• SQS ตรงกลางทำหน้าที่ buffer — ถ้า worker/backend ล่ม order ยังค้างใน queue ไม่หาย (ตอบ “must not lose orders” = Reliability)
• serverless ทั้งสาย = ไม่มี server ให้ดูแล (least ops) + จ่ายตามใช้ (cost) + scale เองตาม spike (Performance/Reliability)
• DynamoDB on-demand = ไม่ต้อง provision capacity ล่วงหน้าให้ตรงกับ spike ที่คาดเดายาก

Trade-off: ยอมรับ eventual processing (async, ไม่ real-time ทันที) แลกกับ durability + scale + low ops ถ้าโจทย์เปลี่ยนเป็น “order must confirm in real-time synchronously” การใส่ queue กลางจะขัด requirement และต้องคิดใหม่ (ดู event-driven patterns บท 05)

ตัวอย่างที่ 3 — โจทย์ระดับองค์กร (mindset Professional)

โจทย์ (ย่อ): องค์กรมี 60 AWS accounts กำลังโต ต้องบังคับให้ทุก account ห้ามสร้าง resource นอก region ap-southeast-1 และห้ามปิด CloudTrail โดยต้องการวิธีที่ scales across the organization และ least ongoing effort

การวิเคราะห์: keyword “across the organization” + “60 accounts” = คิดระดับ org ไม่ใช่ราย account → AWS Organizations + Service Control Policies (SCP) (ดูบท 02) วาง SCP ที่ระดับ OU/root เพื่อ deny region อื่นและ deny การ cloudtrail:StopLogging

ทำไมตัวอื่น (สมมติ) ผิด:

• ตั้ง IAM policy รายบุคคลในแต่ละ account → ไม่ scale, ผู้ใช้ที่มีสิทธิ์ยังทำได้, effort สูง (ละเมิด “least ongoing effort”)
• ใช้ AWS Config rule ตรวจจับแล้วแจ้งเตือน → เป็น detective (ตรวจหลังเกิด) ไม่ใช่ preventive โจทย์ต้อง “ห้าม” (ป้องกัน) SCP เป็น guardrail เชิงป้องกันที่เหมาะกว่า
• เขียน Lambda ตรวจทุก account → over-engineered, ต้องดูแลโค้ด, ไม่ใช่ native guardrail

Trade-off: SCP เป็น guardrail ระดับ org ที่ทรงพลังแต่ ไม่ให้สิทธิ์เอง (เป็นเพียงขอบเขตบน) และเขียนผิดอาจ lock ทั้ง org ได้ — จึงต้องออกแบบ OU hierarchy ให้ดี (รายละเอียดกลไก evaluation อยู่บท 02–03) นี่คือตัวอย่างชัดของการคิด “ระดับองค์กร” ที่แยก Professional จาก Associate

---

5. ข้อผิดพลาดที่พบบ่อยในข้อสอบ

1. อ่าน scenario ทั้งหมดก่อนดูคำถาม — เสียเวลาและจำ red herring วิธีถูกคือ requirement-first: ดูคำถาม + keyword ท้ายก่อน แล้วค่อยกวาด scenario หาข้อเท็จจริงที่เกี่ยว
2. มองข้าม keyword บีบ — เลือกคำตอบที่ “ทำงานได้” โดยไม่ถามว่าตรง least cost / least ops / highest availability หรือไม่ ในระดับ Pro ทุกตัวมัก “ทำงานได้” keyword คือสิ่งที่ตัดสิน
3. สับสน preventive vs detective control — SCP/IAM/permission boundary = ป้องกัน (ห้ามทำ); Config/GuardDuty/CloudTrail = ตรวจจับ (รู้หลังเกิด) โจทย์ที่ใช้คำว่า “prevent/enforce/must not” ต้องการ preventive (ดูบท 02, 09)
4. สับสน RTO กับ RPO — RTO = เวลาที่ยอมให้ระบบล่ม (recovery time); RPO = ปริมาณข้อมูลที่ยอมสูญ (recovery point, วัดเป็นเวลาย้อนหลัง) เลือก DR strategy ผิดเพราะสลับสองคำนี้บ่อยมาก (ดูบท 08)
5. เลือก over-engineered เมื่อโจทย์ขอ least effort — เห็น Lambda/custom orchestration แล้วรู้สึก “ฉลาด” ทั้งที่มี managed feature ที่ทำได้ในตัว (เช่น S3 Lifecycle, RDS Blue/Green) การเพิ่ม component = เพิ่ม ops = ผิด keyword
6. ลืมว่า SCP ไม่ให้สิทธิ์ — เข้าใจผิดว่า SCP allow แล้วผู้ใช้จะทำได้เลย จริง ๆ SCP เป็นแค่เพดาน ต้องมี identity-based policy ให้สิทธิ์ด้วย (ดูบท 02–03)
7. มองแค่ระดับ account เดียวในโจทย์ multi-account — เมื่อโจทย์พูดถึงหลาย account/องค์กร คำตอบที่ทำทีละ account มักผิดเพราะไม่ scale ต้องคิด Organizations/StackSets/centralized (mindset Pro)
8. ทุ่มเวลาข้อยากข้อเดียว — โจทย์ยาวข้อหนึ่งอาจกิน 5+ นาที ถ้าติดให้ flag แล้วไปต่อ ทุกข้อคะแนนเท่ากัน การเสียข้อง่าย 3 ข้อท้ายเพราะหมดเวลากับข้อยากข้อเดียวไม่คุ้ม
9. เลือก multiple response ถูกแค่บางตัว — no partial credit ต้องครบ ให้ตรวจแต่ละตัวเลือกเป็น true/false อิสระ
10. เดาว่าฟีเจอร์มีทั้งที่ไม่มั่นใจ — อย่าเลือกคำตอบเพราะ “น่าจะมี” ถ้าไม่แน่ใจว่าบริการทำสิ่งนั้นได้จริง ให้เทียบกับตัวเลือกที่รู้ว่าทำได้แน่ ๆ

---

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

ข้อ 1. เกณฑ์ผ่านของ SAP-C02 คือเท่าใด และหมายความว่าต้องตอบถูก 75% หรือไม่?

เฉลย

ผ่านที่ scaled score 750 จาก 1000 และ ไม่ ได้แปลว่าต้องตอบถูก 75% เพราะเป็น scaled score ที่ผ่าน psychometric weighting และมี 10 ข้อ unscored ปนอยู่ จำนวนข้อที่ต้องถูกจริงไม่มีเลขตายตัว เป็น compensatory scoring (คะแนนรวมทั้งฉบับตัดสิน ไม่ต้องผ่านทีละ domain)

ข้อ 2. โจทย์ลงท้ายว่า “the solution must require the least operational overhead” ระหว่าง (A) รัน Kubernetes cluster บน EC2 ที่จัดการเอง (B) ใช้ Amazon ECS on Fargate — ควรเลือกอะไรและทำไม?

เฉลย

ตอบ B (Fargate) เพราะ keyword least operational overhead ชี้ไป managed/serverless ที่ไม่ต้อง patch/scale/manage node เอง A ต้องดูแล control plane + worker nodes + patching = ops สูง ผิด keyword (แม้ทั้งคู่รัน container ได้จริง)

ข้อ 3. อธิบายความต่างระหว่าง RTO และ RPO และยกตัวอย่าง keyword ในโจทย์ที่ชี้ไปแต่ละตัว

เฉลย

• RTO (Recovery Time Objective) = เวลาสูงสุดที่ยอมให้ระบบไม่พร้อมใช้งานหลังเกิดเหตุ keyword เช่น “restore service within X minutes”, “minimal downtime”
• RPO (Recovery Point Objective) = ปริมาณข้อมูลสูงสุดที่ยอมสูญ วัดเป็นเวลาย้อนหลัง keyword เช่น “no more than 5 minutes of data loss”, “no data loss” (RPO≈0)

การสลับสองคำนี้ทำให้เลือก DR strategy ผิด (ดูบท 08)

ข้อ 4. โจทย์ต้องการ “prevent all member accounts from disabling CloudTrail across the organization with the least ongoing effort” ควรใช้ preventive หรือ detective control และบริการใด?

เฉลย

ใช้ preventive control = Service Control Policy (SCP) ที่ deny cloudtrail:StopLogging/DeleteTrail วางที่ระดับ org/OU คำว่า “prevent” + “across the organization” + “least ongoing effort” ชี้ชัดไป SCP AWS Config เป็น detective (ตรวจหลังเกิด ไม่ป้องกัน) จึงไม่ตรง requirement “prevent” (ดูบท 02, 09)

ข้อ 5. ในข้อสอบพบบ่อยว่า “ทุกตัวเลือกทำงานได้” กระบวนการตัดตัวเลือกที่ควรใช้เป็นอย่างไร (เรียงขั้น)?

เฉลย

1. ตัดตัวที่ผิดข้อเท็จจริงเชิงเทคนิค (ทำไม่ได้จริง)
2. ตัดตัวที่ละเมิด constraint บังคับในโจทย์
3. ตัดตัวที่ over-engineered เมื่อขอ least effort
4. ตัดตัวที่ under-engineered เมื่อขอ resilience/scale
5. จากที่เหลือ เลือกตัวที่ตรง keyword บีบมากที่สุด (ถูกกว่า/ดูแลน้อยกว่า/ทนกว่า)

ข้อ 6. คำว่า “spiky, unpredictable traffic” ปนกับ “must not lose any requests even if the backend fails” ชี้ไปสถาปัตยกรรมแบบใด?

เฉลย

ชี้ไป decoupling ด้วย durable queue (SQS) เป็น buffer หน้า backend + serverless/auto-scaling (“spiky” = scale เอง; “must not lose requests” = queue ทน durable ถ้า backend ล่ม request ยังค้างใน queue) เช่น API Gateway + SQS + Lambda/Fargate worker (ดูบท 05)

ข้อ 7. ความต่างหลักของ mindset ระหว่างข้อสอบ Associate กับ Professional คืออะไร และส่งผลต่อการเลือกคำตอบอย่างไร?

เฉลย

Associate = เลือกบริการสำหรับระบบเดียว/account เดียว; Professional = ออกแบบข้าม account/region/ทั้งองค์กร พร้อมชั่ง trade-off หลายด้าน (governance, blast radius, cost ระดับ org, migration) ผลคือในโจทย์ multi-account คำตอบที่ทำทีละ account มักผิดเพราะไม่ scale ต้องเลือกแนวรวมศูนย์ (Organizations, StackSets, centralized networking)

ข้อ 8. Well-Architected pillar ใดที่ keyword “most cost-effective” ให้ความสำคัญ และเหตุใดการเข้าใจ pillar จึงช่วยตอนที่สองตัวเลือกสูสี?

เฉลย

Cost Optimization เป็น pillar นำ เมื่อสองตัวเลือกทำงานได้ทั้งคู่ การรู้ว่า pillar ไหนกำลังนำ (จาก keyword) ช่วยตัดตัวที่ optimize ผิด pillar เช่น ถ้า keyword คือ cost แต่ตัวเลือกหนึ่ง over-provision เพื่อ performance ที่โจทย์ไม่ได้ขอ ให้เลือกตัวที่ align กับ Cost มากกว่า (จ่ายตามใช้/Spot/tiered storage)

ข้อ 9 (multiple response — เลือก 2). เหตุใดข้อ multiple response จึงต้องระวังเป็นพิเศษ และควรใช้กลยุทธ์ใด? (เลือก 2 ข้อที่ถูก)

• A) ได้คะแนนบางส่วนถ้าตอบถูกครึ่งหนึ่ง
• B) ต้องเลือกถูกครบทุกตัวจึงได้คะแนน (no partial credit)
• C) ควรมองแต่ละตัวเลือกเป็นคำถาม true/false อิสระ
• D) จำนวนคำตอบที่ถูกไม่ระบุในโจทย์ ต้องเดาเอง

เฉลย

ตอบ B และ C — B: no partial credit ต้องครบทุกตัว; C: มองแต่ละตัวแยกเป็น true/false ช่วยความแม่น A ผิด (ไม่มีคะแนนบางส่วน) D ผิด (โจทย์ระบุจำนวนเสมอ เช่น “select TWO”)

---

7. Cross-references

• บทที่ 02 — Multi-Account Governance: กลไก SCP (allow/deny, evaluation), OU hierarchy, preventive guardrails ที่อ้างถึงในตัวอย่างที่ 3 และข้อผิดพลาดข้อ 3, 6
• บทที่ 03 — Identity, Access & Federation: policy evaluation logic (explicit deny > allow), SCP ไม่ให้สิทธิ์เอง, SAML/OIDC federation ที่โยงกับ constraint “existing identity provider”
• บทที่ 04 — Networking at Scale: VPC peering non-transitive (ตัวอย่าง distractor “technically impossible”), Transit Gateway สำหรับ scale ระดับ org
• บทที่ 05 — Compute & Application Integration: decoupling ด้วย SQS/SNS/EventBridge/Step Functions ที่ใช้ในตัวอย่างที่ 2 และคำถามข้อ 6
• บทที่ 08 — Resilience, HA & DR: นิยาม RTO/RPO เชิงลึก และ 4 DR strategies ที่โยงกับ keyword “minimal downtime”/“no data loss” (ข้อผิดพลาดข้อ 4, คำถามข้อ 3)
• บทที่ 09 — Security Architecture: detective vs preventive controls (Config/GuardDuty vs SCP), least privilege ที่เป็นแกน Security pillar
• บทที่ 10 — Cost Optimization: Spot/RI/Savings Plans ที่ใช้ในตัวอย่างที่ 1 และ keyword “most cost-effective”
• บทที่ 12–13 — Migration & Modernization: 7 Rs และ constraint “cannot modify application code” / “lift-and-shift” ที่ถอดจาก keyword ในบทนี้
• บทที่ 14 — Exam Scenarios & Decision Frameworks: นำ keyword→pillar mapping และเทคนิคตัดตัวเลือกในบทนี้ไปใช้กับ scenario เต็มรูปแบบ พร้อมสรุป distractor patterns ทั้งเล่ม