BÀI 1: Tổng quan SAA-C03 & Thay đổi Mindset để chinh phục 1000/1000

Đây là bài đầu tiên trong series chia sẻ lại hành trình mình ôn tập và tham gia kỳ thi AWS Certified Solutions Architect – Associate (SAA-C03).

Trước khi đi sâu vào cách mình học, hands-on, luyện đề hay những nhóm kiến thức mình tập trung nhiều nhất, mình nghĩ có một thứ quan trọng hơn cần nói trước: cách mình nhìn về kỳ thi SAA đã thay đổi như thế nào trong quá trình học .

1. Bắt đầu hành trình SAA-C03

Tổng quan về kỳ thi

AWS Certifed Solutions Architect – Associate là chứng chỉ Associate tập trung vào khả năng thiết kế các giải pháp trên AWS dựa trên những yêu cầu cụ thể về security, resiliency, performance và cost optimization.

Tại thời điểm mình viết bài, kỳ thi SAA-C03 gồm 65 câu hỏi trong 130 phút, với hai dạng chính là multiple choice và multiple response.

Trong 65 câu này, 50 câu được tính vào điểm số và 15 câu là unscored questions được AWS sử dụng để đánh giá cho các kỳ thi trong tương lai. Những câu unscored không được đánh dấu riêng nên khi làm bài mình vẫn phải xem tất cả các câu như nhau.

Kết quả được tính theo thang điểm 100~1000, với mức điểm tối thiểu để pass là 720. AWS cũng không trừ điểm khi đoán đáp án, trong khi câu bỏ trống sẽ được tính là sai.

Theo Exam Guide chính thức, phần nội dung được chấm điểm hiện chia thành bốn domain

2. Thay đổi cách mình nhìn về SAA

2.1. Từ Definition sang Requirement

Lúc mới học, mình thường tiếp cận AWS theo kiểu: EC2 là gì? S3 dùng để làm gì? EFS có những feature nào?

Cách học này giúp mình xây foundation, nhưng với SAA thì như vậy vẫn chưa đủ, bởi đề thi thường không hỏi trực tiếp definition của một service mà đặt nó vào một scenario cụ thể.

Ví dụ, thay vì hỏi: Amazon EFS dùng để làm gì?

Đề có thể mô tả nhiều Linux EC2 instance chạy trên các Availability Zone khác nhau và cần truy cập chung một filesystem có khả năng tự động scale.

Lúc này, điều quan trọng không phải là mình thuộc một câu định nghĩa về EFS, mà là nhận ra những requirement như Linux, shared filesystem, Multi-AZ và scalability đang hướng tới giải pháp nào.

Vì vậy mình dần chuyển cách học từ:

Service => Definition

sang:

Requirement => Service phù hợp => Vì sao phù hợp

Thay đổi này tuy khá đơn giản nhưng giúp mình xử lý scenario tốt hơn rất nhiều khi bắt đầu luyện đề.

2.2. Học service trong một Architecture

Sau khi hiểu từng service, bước tiếp theo của mình là đặt chúng vào một hệ thống hoàn chỉnh.

Thay vì chỉ hỏi:

• EC2 là gì?
• RDS là gì?
• Load Balancer dùng để làm gì?

Mình bắt đầu nhìn chúng dưới góc độ của một architecture:

User => Load Balancer => EC2/Auto Scaling => Database

Sau đó mình tự hỏi:

• Nếu một EC2 instance fail thì hệ thống có tiếp tục hoạt động không?
• Nếu traffic tăng đột ngột thì component nào cần scale?
• Database có đang trở thành single point of failure hay không?
• State của application đang được lưu ở đâu?
• Các thành phần đang phụ thuộc vào nhau như thế nào?

Khi đặt service vào một flow như vậy, mình bắt đầu hiểu rõ hơn vai trò của từng thành phần thay vì chỉ nhớ riêng lẻ definition và feature của chúng.

Một service có thể khá dễ hiểu khi đứng một mình, nhưng trong SAA điều quan trọng hơn là nó phối hợp với những service khác như thế nào để tạo thành một architecture đáp ứng được requirement.

Khi học theo cách này, các service không còn là những mảnh kiến thức rời rạc nữa mà bắt đầu liên kết với nhau thành một hệ thống. Đây cũng là lúc mình cảm thấy SAA thú vị hơn khá nhiều so với việc chỉ học definition và feature.

2.3. Comparison giúp xử lý những đáp án dễ nhầm

Một khó khăn khác của SAA là có khá nhiều service hoặc feature nhìn qua khá giống nhau.

Ví dụ:

• SQS vs SNS => Queue/decoupling vs Pub/Sub/fan-out
• RDS Multi-AZ vs Read Replica => High Availability vs Read Scaling
• CloudFront vs Global Accelerator => Content delivery/cache vs Network acceleration
• DataSync vs Storage Gateway => Data transfer vs Hybrid storage
• NAT Gateway vs VPC Endpoint => Internet egress vs Private access tới AWS services

Nếu học riêng từng service, mình có thể hiểu cả hai nhưng vẫn phân vân khi chúng cùng xuất hiện trong một câu hỏi.

Chẳng hạn, mình biết cả Multi-AZ và Read Replica đều liên quan đến việc có thêm database instance. Nhưng điểm giúp mình chọn đúng lại nằm ở requirement:

Database cần failover khi có sự cố? => Multi-AZ

Database đang quá tải vì lượng read lớn? => Read Replica

Vì vậy, trong quá trình học mình review khá nhiều bảng A vs B (bảng so sánh này mình sẽ đề cập trong các bài sau). Mục tiêu không phải nhớ thêm thật nhiều feature, mà là trả lời được một câu đơn giản:

Hai lựa chọn này khác nhau ở điểm nào và khi nào mình chọn cái nào?

Những comparison này sau đó cũng trở thành một trong những loại note mình review nhiều nhất ở giai đoạn cuối, vì chỉ cần nhìn lại điểm khác nhau cốt lõi giữa hai service là mình có thể recall khá nhanh cả use case của chúng.

Theo mình, đây là một trong những cách hiệu quả nhất để xử lý distractor trong đề SAA.

2.4. Đừng học thuộc đáp án

Đây là một trong những điều mình nghĩ quan trọng nhất.

Nếu mình chỉ nhớ: “Câu này giống câu Dojo lần trước, đáp án là C.” Thì chỉ cần đề thay high availability thành read performance là toàn bộ reasoning đã có thể thay đổi.

Thứ mình cần hiểu là:

Vì sao C đúng?

thay vì chỉ nhớ:

C là đáp án.

Sự khác biệt nghe có vẻ nhỏ, nhưng theo mình nó quyết định khá nhiều việc mình thật sự hiểu concept hay chỉ đang nhớ lại một câu hỏi mình từng gặp.

Practice question vì vậy không nên trở thành một bộ flashcard khổng lồ gồm “câu hỏi => đáp án”. Giá trị lớn hơn nằm ở reasoning phía sau mỗi lựa chọn.

2.5. Đúng chưa đủ, phải phù hợp nhất

Một điều mình nhận ra rõ hơn khi bắt đầu luyện nhiều scenario là trong SAA, đôi khi có hơn một solution technically có thể hoạt động.

Lúc đó, câu hỏi không còn đơn giản là:

“Phương án này có giải quyết được bài toán hay không?”

mà là:

“Trong những phương án đều có thể hoạt động, phương án nào phù hợp nhất với requirement của đề?”

Sự khác biệt thường nằm ở những constraint như:

• MOST cost-effective
• LEAST operational overhead
• MINIMUM changes
• Highest availability
• Lowest latency

Vì vậy, sau khi xác định được requirement chính, mình thường làm thêm một bước:

Loại những solution không đáp ứng bài toán => so sánh những solution còn lại theo constraint

Ví dụ, hai architecture đều có thể đáp ứng yêu cầu về availability, nhưng nếu một phương án cần tự quản lý nhiều thành phần hơn trong khi đề yêu cầu LEAST operational overhead , thì tiêu chí vận hành có thể trở thành yếu tố quyết định.

Điều này cũng giúp mình tránh một thói quen khá dễ mắc phải khi học AWS: nhìn thấy một service “xịn”, managed hoặc serverless rồi mặc định cho rằng đó là đáp án tốt hơn.

Trong SAA, một solution tốt không nhất thiết là solution sử dụng service mới nhất hay nhiều feature nhất.

Nó đơn giản là solution đáp ứng requirement tốt nhất với trade-off phù hợp nhất .

Kết luận

Nhìn lại giai đoạn đầu học SAA, thay đổi lớn nhất đối với mình không nằm ở việc nhớ thêm thật nhiều AWS service, mà ở cách mình tiếp cận chúng. Thay vì chỉ học definition và feature, mình bắt đầu nhìn service trong một architecture, so sánh những lựa chọn gần giống nhau và luôn xác định requirement trước khi chọn solution.

Theo mình, khi đã hình thành được cách suy nghĩ này, việc học và xử lý các scenario SAA trở nên rõ ràng hơn khá nhiều. Đây cũng là foundation mình sử dụng xuyên suốt trong quá trình ôn tập sau đó.

Ở Bài 2 , mình sẽ chia sẻ cụ thể hơn cách mình học SAA trong khoảng một tháng, cách ghi chú ngắn gọn, cách mình tận dụng AI và cách kết hợp lý thuyết với practice question trong quá trình học.