GĐ28 — AWS SAA: lộ trình học và tư duy kiến trúc

Nhánh AWS Certified Solutions Architect – Associate cho FE engineer chuyển Fullstack và build AI SaaS. Học cách giải thích lựa chọn kiến trúc trước khi luyện thi. Mốc đối chiếu tài liệu: 05/10/2026, phiên bản SAA-C03.

Kiểm chứng ngày 2026-10-05 (đọc trang chính thức; không chạy lệnh nào trên AWS): exam guide SAA-C03 và bốn trang domain (1, 2, 3, 4) cho task, tỷ trọng, số câu và cách tính điểm; trang thông tin kỳ thi cho thời lượng, hình thức thi và ngôn ngữ; chính sách trước khi thi và sau khi thi cho thời gian thêm, đổi lịch, thi lại; danh sách in-scope và out-of-scope; đổi instance type EC2. Các mục viết từ trước giữ nguồn riêng ở cuối mỗi mục.

1. Bắt đầu ở đâu và học đến mức nào?#

Đọc GĐ16 — AWS nền tảng trước để hiểu EC2, IAM, S3, RDS, Lambda, CloudWatch và VPC. Nhánh này mở rộng từ “deploy được API” sang “chọn một kiến trúc đáp ứng yêu cầu và biết cái giá của nó”. Không cần hoàn thành GĐ17–27 trước khi bắt đầu.

Bạn cần hiểu HTTP/TLS, IP/subnet, SQL, Docker và API bất đồng bộ ở mức căn bản. Nếu gặp từ chưa hiểu, quay lại Systems Foundation, DevOps hoặc System Design.

Chương	Nội dung	Kết quả học
GĐ28 — chương này	Bản đồ SAA, yêu cầu, Well-Architected	Đọc yêu cầu và xác định tiêu chí quyết định
GĐ29	IAM, mã hóa, VPC, hybrid, DNS/edge	Vẽ đường mạng và quyền cho từng request
GĐ30	Compute, load balancing, queue, HA/DR	Chỉ ra điểm lỗi và cơ chế phục hồi
GĐ31	Object/block/file, SQL/NoSQL, cache/analytics	Chọn data store theo access pattern
GĐ32	Chi phí, vận hành, migration, dịch vụ mở rộng	So sánh tổng chi phí và công sức vận hành
GĐ33	Lab, case study, câu hỏi và đáp án	Chứng minh hiểu bằng sơ đồ, kết quả lab, giải thích

Sáu chương hướng tới các task của bốn domain và có bản đồ dịch vụ để tra cứu thêm, nhưng không bảo đảm phủ hết exam guide: bảng ngay bên dưới đối chiếu từng task với mục dạy và nêu khoảng trống còn lại. Đây là tài liệu học bằng tiếng Việt; danh mục AWS chính thức vẫn là nguồn để kiểm tra phạm vi trước ngày thi. Dịch vụ có tên trong phạm vi không đồng nghĩa xuất hiện trong mọi đề.

Bảng phủ: task của exam guide so với các chương#

Đối chiếu ngày 2026-10-05 với từng trang domain của exam guide. Cột "Mục dạy" nêu mục có nội dung chính của task; cột "Khoảng trống" nêu phần exam guide có tên mà guide chưa dạy hoặc mới nhắc tên (đối chiếu bằng tìm từ khóa trong GĐ28 đến GĐ32 và đọc lại mục liên quan). Cột "Lab" theo bản hiện tại của GĐ33 (Lab A S3/IAM, B VPC/ALB/Auto Scaling, C SQS, D RDS, E CloudFront, F chi phí); kiểm lại GĐ33 nếu nó đổi.

Task	Mục dạy	Khoảng trống	Lab
1.1 Secure access to AWS resources	GĐ29 mục 1 (IAM, Cognito, federation, Identity Center, root, Control Tower), GĐ29 mục 2 (allow/deny, cross-account), mục 5 và mục 6 ở chương này	Multi-account/SCP ở mức khái niệm; Directory Service chỉ một dòng ở GĐ32 mục 9	A
1.2 Secure workloads and applications	GĐ29 mục 4 đến mục 6 (VPC, SG/NACL, NAT, endpoint), mục 7 (VPN, Direct Connect), mục 9 (WAF, Shield, GuardDuty, Macie), mục 3 (secret)	WAF/Shield mới ở mức chọn dịch vụ, chưa cấu hình rule	B
1.3 Data security controls	GĐ29 mục 3 (KMS, ACM, xoay vòng), GĐ31 mục 2, mục 3, mục 5 (mã hóa S3, lifecycle, mã hóa RDS), mục 6 (backup)	Phân loại dữ liệu và compliance chỉ ở mức nhận diện (Macie ở GĐ29 mục 9, Artifact ở GĐ32 mục 9)	A
2.1 Scalable and loosely coupled	GĐ30 mục 1, mục 3 đến mục 7 (compute, ALB, Auto Scaling, Lambda/API Gateway, SQS, SNS, EventBridge, Step Functions), GĐ31 mục 5 (read replica), mục 8 (cache), GĐ29 mục 8 (CDN)	"Migrate applications into containers" chưa có mục; Transfer Family chỉ ở GĐ32 mục 7; stateful và stateless chỉ nhắc trong GĐ30	B, C
2.2 Highly available / fault-tolerant	GĐ30 mục 8 và mục 9 (HA, RTO/RPO, DR), GĐ31 mục 5, mục 6 (Multi-AZ, RDS Proxy, backup), GĐ32 mục 6 (X-Ray, tracing), mục 5 chương này	Quota chung có một đoạn ở mục 6 chương này, chưa nói riêng quota ở môi trường standby, chưa có ví dụ; dịch vụ AI managed (Comprehend, Polly) chỉ nhận diện ở GĐ32 mục 9	C, D
3.1 High-performing storage	GĐ31 mục 1 đến mục 4 (object/block/file, S3, classes, EBS, EFS, FSx)	Các kiểu FSx chỉ ở mức chọn; hybrid storage chỉ ở GĐ32 mục 7	A
3.2 High-performing and elastic compute	GĐ30 mục 1, mục 2, mục 4, mục 5 (family, ASG, Lambda memory)	EMR, Batch chỉ nhận diện; AWS Auto Scaling (scaling plans): tình trạng chưa xác minh (xem GĐ30 mục 4)	B
3.3 High-performing databases	GĐ31 mục 5 đến mục 8 (RDS/Aurora, proxy, DynamoDB RCU/WCU, ElastiCache), GĐ32 mục 7, mục 8 (migration)	Migration đồng nhất và dị thể mới ở mức công cụ (DMS), chưa có bài chuyển engine	D
3.4 High-performing network	GĐ29 mục 4, mục 6 đến mục 8, GĐ30 mục 3 (ALB/NLB/GWLB)	Quy hoạch CIDR và IP chi tiết nằm ở GĐ01, không lặp lại ở nhánh này	B, E
3.5 Data ingestion and transformation	GĐ31 mục 9 (Athena, Glue, Redshift, EMR, Parquet), GĐ30 mục 7 (Kinesis, Firehose, MSK), GĐ32 mục 7 (DataSync, Storage Gateway)	Xây và bảo mật data lake (Lake Formation) mới nêu tên; chưa có ví dụ chuyển csv sang parquet	không có
4.1 Cost-optimized storage	GĐ31 mục 3 (class, lifecycle), GĐ32 mục 3, mục 5, mục 7; Requester Pays ở GĐ32 mục 9	Storage auto scaling cho RDS chưa có; so sánh gói upload theo lô chưa có ví dụ	A, F
4.2 Cost-optimized compute	GĐ32 mục 2, GĐ30 mục 1 đến mục 3, mục 5, hibernation ở GĐ30 mục 2, scale dọc và ngang ở mục con bên dưới	"Virtualization" (Nitro, phần cứng) chưa có; edge processing chỉ qua GĐ29 mục 8	B, F
4.3 Cost-optimized databases	GĐ32 mục 3, GĐ31 mục 5, mục 7, GĐ32 mục 8	Kiểu dữ liệu time series và columnar: columnar có ở Redshift (GĐ31 mục 9), time series chưa có mục (Timestream không có trong danh sách in-scope ngày đọc)	D, F
4.4 Cost-optimized network	GĐ32 mục 4 (NAT, endpoint, CDN), GĐ29 mục 6 đến mục 8, throttling ở GĐ30 mục 5	Chọn băng thông VPN so với tốc độ Direct Connect mới ở mức khái niệm	F

Dịch vụ có trong danh sách in-scope mà trước đây chưa có chỗ nào: Well-Architected Tool, Serverless Application Repository, Data Exchange, EKS Distro, VMware Cloud on AWS; nay mỗi dịch vụ có một dòng ở GĐ32 mục 9. Mỗi khi bảng báo "chưa có", học từ trang domain tương ứng của exam guide rồi tự ghi ngày đối chiếu.

2. Kỳ thi và bản đồ bốn domain#

SAA-C03 có câu hỏi chọn một hoặc nhiều đáp án. Tổng 65 câu, 130 phút; 50 câu tính điểm và 15 câu thử nghiệm không được đánh dấu. Điểm đạt là 720 trên thang 100–1.000, không được suy ra thành “đúng 72% câu hỏi”. AWS khuyến nghị khoảng một năm kinh nghiệm thiết kế giải pháp AWS; đó là mức kinh nghiệm khuyến nghị để chuẩn bị.

Domain	Tỷ trọng điểm	Task cần hiểu	Học chính ở
Secure architectures	30%	1.1 Truy cập tài nguyên; 1.2 Bảo vệ workload; 1.3 Bảo vệ dữ liệu	GĐ29, GĐ31
Resilient architectures	26%	2.1 Loosely coupled/scalable; 2.2 Highly available/fault-tolerant	GĐ30, GĐ31, GĐ33
High-performing architectures	24%	3.1 Storage; 3.2 Compute; 3.3 Database; 3.4 Network; 3.5 Ingestion/transformation	GĐ29–31
Cost-optimized architectures	20%	4.1 Storage; 4.2 Compute; 4.3 Database; 4.4 Network	GĐ32, GĐ33

Nguồn: Exam guide SAA-C03, thông tin kỳ thi. Kiểm tra lại mã đề, thời lượng, phí và danh mục dịch vụ khi đăng ký; không chọn khóa học chỉ vì tên “AWS”.

Ngày thi, cách tính điểm và thủ tục#

Tất cả số liệu dưới đây đọc ngày 2026-10-05; AWS có thể đổi, nên mở lại các trang nguồn khi đặt lịch.

Việc	Theo trang chính thức
Số câu và thời lượng	65 câu trong 130 phút; 50 câu tính điểm, 15 câu thử nghiệm không được đánh dấu (exam guide, thông tin kỳ thi)
Dạng câu hỏi	Một đáp án đúng trong bốn lựa chọn; hoặc hai đáp án đúng trở lên trong năm lựa chọn trở lên
Câu bỏ trống	Tính là sai; không bị trừ điểm khi đoán, nên không để trống
Điểm	Thang quy đổi 100 đến 1.000, điểm đạt tối thiểu 720; mô hình compensatory: không cần đạt riêng từng domain, chỉ cần đạt điểm tổng
Tỷ trọng	30%, 26%, 24%, 20% của nội dung được tính điểm (scored content) cho bốn domain theo thứ tự trong bảng trên
Hình thức thi	Trung tâm Pearson VUE hoặc online có giám sát; có 10 ngôn ngữ, gồm tiếng Anh (thông tin kỳ thi); không có tiếng Việt trong danh sách đó
Thêm thời gian	Người không bản ngữ tiếng Anh thi bằng tiếng Anh được xin thêm 30 phút, chỉ cần yêu cầu một lần trong tài khoản AWS Certification (trước khi thi)
Đổi lịch	Mỗi lịch thi đổi được hai lần; lần thứ ba phải hủy rồi đặt lịch mới (cùng trang)
Kết quả	Có trong tài khoản AWS Certification trong vòng năm ngày làm việc (sau khi thi)
Thi lại	Chờ tối thiểu 14 ngày sau lần trượt, không giới hạn số lần, mỗi lần đóng đủ lệ phí; đã đạt thì không thi lại cùng đề trong 2 năm (cùng trang)

Hệ quả khi học: 130 phút cho 65 câu là trung bình 2 phút mỗi câu (phép chia, bao gồm cả 15 câu không tính điểm mà bạn không phân biệt được), nên câu tình huống dài phải đọc theo quy trình năm bước ở mục 3 thay vì đọc lại nhiều lần. Vì có câu thử nghiệm không đánh dấu và điểm được quy đổi, không có cách đổi chính xác "số câu đúng" thành 720; điểm của đề luyện không phải điểm thi. Trang Technologies and Concepts cũng thuộc exam guide; đọc trước ngày thi cùng danh sách in-scope.

3. Đọc yêu cầu trước khi chọn dịch vụ#

Ví dụ tự xây: “API cho 10.000 người dùng” chưa đủ để chọn EC2 hay Lambda. 10.000 tài khoản, 10.000 concurrent users và 10.000 request/giây là ba tải khác nhau.

Lập bảng yêu cầu trước:

Trục	Câu hỏi cần trả lời	Ví dụ yêu cầu có thể kiểm tra
Tải	Trung bình, peak, thời gian burst?	100 RPS trung bình, peak 1.000 RPS trong 10 phút
Độ trễ	Đo ở client hay origin, percentile nào?	p95 API dưới 300 ms trong Region
Dữ liệu	Quan hệ, kích thước, truy vấn, consistency?	Giao dịch billing dùng transaction; file lưu object
Availability	Chịu mất process, máy, AZ hay Region?	Mất một AZ vẫn phục vụ core API
Recovery	Chấp nhận mất dữ liệu/ngừng dịch vụ bao lâu?	RPO 15 phút, RTO 2 giờ
Security	Ai truy cập gì; dữ liệu nhạy cảm nào?	DB private, ứng dụng dùng role, tenant isolation
Chi phí	Ngân sách và phần tải ổn định?	Ước lượng riêng fixed cost, request, transfer
Vận hành	Team có thời gian quản OS/cluster không?	Hai dev, ưu tiên managed service

Quy trình giải một tình huống:

Gạch chân ràng buộc bắt buộc: protocol, recovery target, quyền, Region, access pattern.
Xác định mục tiêu tối ưu: ít vận hành, ít chi phí hay độ trễ thấp nhất.
Loại phương án vi phạm ràng buộc trước khi so giá.
Vẽ request/data flow; chỉ rõ nơi retry, cache, mã hóa và kiểm tra quyền.
Nêu trade-off và một phép thử chứng minh phương án đáp ứng yêu cầu.

“Managed” giảm việc quản hạ tầng, vẫn cần schema, quyền, capacity, backup, alarm và xử lý lỗi ứng dụng. “Serverless” mô tả cách vận hành compute, không bảo đảm mọi workload rẻ hơn.

Scale ngang và scale dọc#

Exam guide nêu "horizontal scaling and vertical scaling" ở task 2.1 và 4.2. Scale dọc là đổi sang tài nguyên lớn hơn cho cùng một nút; scale ngang là thêm nút và chia tải. Bản chất khác nhau ở giới hạn và cái giá:

	Scale dọc	Scale ngang
Làm gì	Đổi instance type/class lớn hơn	Thêm instance, task, replica sau load balancer
EC2	Phải stop instance rồi đổi type, nên có downtime; public IPv4 không phải Elastic IP sẽ bị thu hồi và cấp địa chỉ mới sau khi stop và start; không đổi được type của Spot instance (tài liệu)	ASG thêm instance theo metric, ví dụ ALB request count (GĐ30 mục 4)
Trần	Kích thước lớn nhất của loại máy; vẫn là một nút, một failure domain	Quota, số IP trong subnet, kết nối đến database (mục 6)
Điều kiện app	Gần như không đổi code	Phải stateless: session và file đưa ra ngoài (ElastiCache, DynamoDB, S3)
Database	Đổi DB instance class (modify instance) cho writer	Read replica chỉ chia tải đọc (GĐ31 mục 5); chia ghi cần thiết kế khóa như DynamoDB (GĐ31 mục 7)

Quy tắc chọn: scale dọc nhanh và đơn giản cho hệ thống nhỏ nhưng dừng ở trần phần cứng và không tăng availability; scale ngang cần app không giữ state trong nút nhưng cho phép chịu mất nút và AZ. Đề thi hay nêu "ứng dụng ghi session vào RAM" để kiểm tra bạn có nhận ra điều kiện này; đây là cách đọc đề, chưa có nguồn AWS chính thức. Xem thêm GĐ21 mục 3 về scale dọc so với ngang ở mức nguyên lý và GĐ19 mục 7 về chế độ hỏng. Việc đổi DB instance class dùng thao tác modify DB instance; trang này không nêu thời gian gián đoạn, nên mức downtime cụ thể: chưa xác minh.

4. Well-Architected: sáu góc nhìn cho cùng một hệ thống#

Pillar	Câu hỏi khi review SaaS
Operational excellence	Deploy/rollback thế nào; ai đọc alarm; có runbook không?
Security	Role tối thiểu, phân quyền tenant, mã hóa, audit và quản secret?
Reliability	Nếu dependency chết thì chuyện gì xảy ra; restore đã thử chưa?
Performance efficiency	Có đo bottleneck trước khi tăng máy/chuyển database không?
Cost optimization	Tài nguyên nhàn rỗi, data transfer, log và commitment có hợp lý?
Sustainability	Có tránh compute/storage dư thừa và tận dụng tài nguyên hiệu quả?

Tự xây một decision record ngắn cho mỗi lab: yêu cầu → hai lựa chọn → lựa chọn cuối → trade-off → cách đo. Ví dụ chọn RDS PostgreSQL vì billing có quan hệ và transaction; chưa chọn DynamoDB vì chưa thiết kế được access pattern và muốn giữ SQL tooling.

Nguồn: AWS Well-Architected Framework.

5. Region, AZ, edge và failure domain#

Region là khu vực địa lý triển khai. Availability Zone (AZ) là ranh giới hạ tầng độc lập trong Region; edge location phục vụ dịch vụ như CDN gần người dùng. VPC thuộc Region, subnet thuộc một AZ. Không gọi một public subnet là “subnet toàn Region”.

Ví dụ: hai instance trong một subnet vẫn có cùng failure domain AZ. Để chịu sự cố AZ, phân bố compute và dữ liệu theo khả năng multi-AZ của từng dịch vụ. Backup ở cùng Region chưa đáp ứng yêu cầu phục hồi khi mất Region.

Chọn Region theo người dùng, data residency, dịch vụ hỗ trợ và chi phí. Không tự chọn multi-Region nếu yêu cầu chỉ là chịu mất một AZ: vận hành, replication và xử lý ghi trùng sẽ phức tạp hơn.

Nguồn: AWS Regions và AZ.

6. Shared responsibility và giới hạn dịch vụ#

AWS bảo vệ hạ tầng cloud; bạn bảo vệ cấu hình và dữ liệu của workload. Với EC2, bạn còn quản OS, bản vá và process. Với managed database/Lambda, AWS quản nhiều lớp hơn; bạn vẫn quản quyền, secret, dữ liệu, code và kết nối mạng theo dịch vụ.

Quota là giới hạn như số tài nguyên, concurrency, throughput. Một số tăng được qua Service Quotas, một số là giới hạn cố định. “Auto Scaling” không làm quota, subnet IP hay database connection trở nên vô hạn.

Với mọi sơ đồ, thêm câu hỏi: scale đến đâu, quota ở đâu, khi bị throttle thì retry/buffering thế nào? Đừng retry vô hạn khi dependency đã quá tải.

Nguồn: Shared responsibility, Service Quotas.

7. Nhịp học gợi ý cho người đã vững JS/TS#

Đây là ước lượng học cá nhân, không phải thời gian AWS bảo đảm:

Nhịp	Việc làm	Bằng chứng trước khi đi tiếp
Tuần 1	GĐ16 + GĐ28	Vẽ API/database/upload; phân biệt Region/AZ
Tuần 2–3	GĐ29	Giải thích IAM allow/deny và đường mạng
Tuần 4–5	GĐ30	Chọn compute; giải thích failover, retry, queue
Tuần 6–7	GĐ31	So sánh storage/DB theo bốn access pattern
Tuần 8	GĐ32	Bảng chi phí và phương án migration
Tuần 9–10	GĐ33	Lab có evidence, case study và error notebook

Nếu mục tiêu hiện tại là tham khảo, đọc theo thứ tự này và làm bài tập trên giấy trước. Khi quyết định thi, dùng exam guide và bộ câu hỏi chính thức trong AWS Skill Builder để kiểm tra khoảng trống. Không dùng việc nhớ đáp án làm bằng chứng đã hiểu.

Lời giải và cách kiểm tra: bài tập trên giấy tuần 1 (vẽ API, database, upload)

Chưa chạy trên AWS thật: đây là bài vẽ và lập luận; mọi sự kiện đối chiếu tài liệu AWS (URL ở cuối khối).

Hướng làm

Viết bảng yêu cầu 8 trục như mục 3 cho một SaaS giả định: ví dụ "ứng dụng quản lý tài liệu, 100 RPS trung bình, peak 1.000 RPS, p95 dưới 300 ms, mất một AZ vẫn phục vụ, RPO 15 phút, RTO 2 giờ, đội hai người".
Gạch chân ràng buộc bắt buộc (mất một AZ, RPO/RTO) và mục tiêu tối ưu (ít vận hành).
Vẽ một Region, hai AZ, chỉ rõ ai là failure domain.
Viết một decision record: yêu cầu, hai lựa chọn, lựa chọn cuối, trade-off, cách đo.

Sơ đồ (đáp án mẫu, không phải đáp án duy nhất)

textReady

                  Region +----------------------------------------------------+ | VPC 10.20.0.0/16                                   | |        Internet --> ALB (subnet public A + B)      | |                        |            |              | | +---------- AZ-A ------+--+ +-------+-- AZ-B -----+ | | | app task (private)      | | app task (private)  | | | | RDS primary             | | RDS standby         | | | +-------------------------+ +---------------------+ | |   App --> S3 (dịch vụ Region, không nằm trong AZ)  | +----------------------------------------------------+ Upload: client xin presigned URL từ API, PUT thẳng lên S3.

Kết quả mong đợi

Mỗi hộp có nhãn AZ hoặc "Region"; không hộp nào mang nhãn "toàn Region" mà thật ra chỉ ở một AZ.
Có ít nhất một câu trả lời cho "mất AZ-A thì gì còn chạy": ALB còn node và target ở AZ-B; RDS Multi-AZ chuyển sang standby; S3 Standard lưu dữ liệu ở từ ba AZ trở lên.
Decision record mẫu: chọn RDS PostgreSQL Multi-AZ thay vì DynamoDB vì billing cần transaction/quan hệ và chưa có access pattern ổn định; cách đo: thử failover và đo thời gian phục hồi so với RTO.

Tín hiệu trong đề thi và cách loại phương án (đây là cách đọc, chưa phải ngân hàng câu hỏi)

Tín hiệu trong đề	Ý nghĩa	Phương án thường bị loại vì
"least operational overhead"	Ưu tiên dịch vụ managed/serverless	Tự cài và vá phần mềm trên EC2
"most cost-effective"	Thỏa ràng buộc rồi mới so giá	Phương án rẻ nhưng vi phạm RPO/RTO hoặc availability
"highly available"	Không có single point of failure ở một AZ	Mọi thứ ở một AZ; replica đọc được nhưng không failover tự động
"decouple"	Đặt queue/event giữa các thành phần	Gọi đồng bộ trực tiếp giữa hai tầng

Lỗi hay gặp

Vẽ subnet trải qua nhiều AZ (subnet thuộc đúng một AZ, mục 5).
Gọi "multi-AZ" cho hai instance trong cùng một subnet.
Backup cùng Region rồi cho rằng đã đủ cho sự cố mất Region.

Nguồn: RDS Multi-AZ DB instance, S3 storage classes (cột Availability Zones), ALB cần ít nhất hai subnet ở hai AZ. Cách đọc tín hiệu đề là kinh nghiệm luyện thi, chưa có nguồn AWS chính thức.

8. Tự kiểm tra#

Phân biệt “học SAA” với “hoàn thành một lần deploy”.

Đáp án
Một lần deploy chứng minh một cấu hình chạy được. SAA đo việc chọn phương án đúng ràng buộc (bảo mật, chịu lỗi, hiệu năng, chi phí) và loại phương án sai. Sai thường gặp: coi "chạy được" là "đáp ứng yêu cầu". Xem GĐ28 mục 3.
Giải thích bốn domain và tìm được chương tương ứng.

Đáp án
Secure 30% (GĐ29, GĐ31), Resilient 26% (GĐ30, GĐ31, GĐ33), High-performing 24% (GĐ29–31), Cost-optimized 20% (GĐ32, GĐ33). Tổng 100%. Đạt 720/1000 là thang điểm quy đổi, không phải "72% số câu". Xem bảng ở mục 2.
Viết yêu cầu đo được cho một SaaS của mình.

Đáp án
Mẫu: "100 RPS trung bình, peak 1.000 RPS trong 10 phút; p95 dưới 300 ms trong Region; mất một AZ vẫn phục vụ core API; RPO 15 phút, RTO 2 giờ; DB private; hai dev nên ưu tiên managed". Mỗi vế phải có số hoặc điều kiện kiểm được. Sai thường gặp: "hệ thống nhanh, bảo mật, rẻ".
Chỉ ra failure domain của app, database, storage.

Đáp án
App trên một instance: instance (và AZ của nó). Hai instance ở hai AZ: chịu mất một AZ. RDS Single-AZ: một AZ; Multi-AZ: có standby ở AZ khác. S3 Standard: dữ liệu lưu ở từ ba AZ trở lên; One Zone-IA chỉ một AZ. Xem GĐ28 mục 5.
Giải thích managed service còn để lại trách nhiệm gì cho developer.

Đáp án
IAM và secret, schema và truy vấn, kích thước/capacity, backup và thử restore, alarm, retry và xử lý lỗi trong code, chi phí. Với RDS: AWS lo vá engine và phần cứng, bạn vẫn lo kết nối, index, kích cỡ instance. Xem mục 6.
Chọn hai kiến trúc và giải thích tại sao loại một phương án.

Đáp án
Ví dụ: ECS Fargate hay EC2 tự quản cho API chạy liên tục, tiêu chí "ít vận hành": chọn Fargate, loại EC2 tự quản vì phải vá OS và quản capacity. Luôn nêu ràng buộc nào loại phương án trước khi so giá. Xem mục 3 (quy trình năm bước).
Ứng dụng giữ session trong RAM của từng instance; bạn thêm instance thứ hai sau ALB và người dùng bị đăng xuất ngẫu nhiên. Vì sao, và sửa thế nào?

Đáp án
ALB chia request tới hai instance, nhưng session chỉ nằm ở instance đã tạo ra nó; request tới instance kia không thấy session. Thêm nút chỉ hiệu quả khi app không giữ state trong nút. Cách sửa: đưa session ra ngoài instance (ElastiCache hoặc DynamoDB, xem GĐ31 mục 8 về cache) rồi mới scale ngang. Sticky session (ALB stickiness) chỉ che triệu chứng: session vẫn mất khi instance bị scale in hoặc thay, và tải dễ lệch. Đây là hạn chế của scale ngang; scale dọc (instance lớn hơn) tránh được lỗi này nhưng vẫn là một nút và EC2 phải stop khi đổi type. Xem mục con "Scale ngang và scale dọc" ở mục 3. Sai thường gặp: coi Auto Scaling tự giải quyết state.
Bạn làm đề luyện đúng 74% số câu. Có kết luận được bạn sẽ đạt 720 điểm không?

Đáp án
Không. Điểm thi là thang quy đổi 100 đến 1.000 và exam guide chỉ nói điểm đạt tối thiểu là 720; trong đề có 15 câu không tính điểm và không được đánh dấu, nên không có phép đổi chính xác từ số câu đúng sang điểm. Điểm đề luyện của bên thứ ba cũng không dùng cùng thang. Dùng kết quả luyện để tìm domain yếu (đối chiếu bảng phủ ở mục 1), không để dự đoán kết quả. Thi theo mô hình compensatory nên không cần đạt riêng từng domain, vẫn nên tránh bỏ trống domain có tỷ trọng lớn. Xem mục con "Ngày thi, cách tính điểm và thủ tục" ở mục 2.

Tiếp: GĐ29 — Security & Networking.