BÀI 6. Chiến thuật luyện đề, Lộ trình 4 tuần & Kinh nghiệm thực chiến phòng thi

Sau khi đi qua mindset, phương pháp học, hands-on và những nhóm kiến thức mình tập trung nhiều nhất, bài cuối cùng của series sẽ là giai đoạn mình dành rất nhiều thời gian trước kỳ thi: luyện đề, review lỗ hổng kiến thức và chuẩn bị cho ngày thi thật .

Theo trải nghiệm của mình, đây không đơn giản là giai đoạn “làm thật nhiều đề để xem được bao nhiêu điểm” . Practice question còn giúp mình luyện cách đọc scenario, nhận diện requirement, xử lý distractor và biết chính xác phần kiến thức nào mình vẫn còn chưa chắc.

Trong bài này, mình sẽ chia sẻ những tài liệu mình đã sử dụng, cách mình luyện và review câu sai, roadmap 4 tuần mình gợi ý, cách quản lý thời gian cũng như trải nghiệm thực tế tại Testing Center.

1. Tài liệu và quá trình luyện đề

1.1. Nguồn học lý thuyết

Mình đã tham khảo khá nhiều nguồn, nhưng cuối cùng vẫn giới hạn lại một số tài liệu chính mà cá nhân mình thấy hiệu quả.

Nếu có thời gian hoặc subscription phù hợp thì mình cũng khuyến khích thử AWS Skill Builder, bởi đây là nền tảng học chính thức của AWS và có khá nhiều nội dung từ course, labs, exam preparation cho tới AWS Cloud Quest.

Exam Guide thì theo mình gần như bắt buộc phải đọc.

Mình không đọc một lần rồi thôi mà sử dụng nó như một checklist xuyên suốt quá trình học: sau khi hoàn thành một nhóm kiến thức, mình quay lại task statement để kiểm tra xem còn phần nào mình bỏ sót hay không.

Tutorials Dojo Cheatsheet thì khá phù hợp để review nhanh và làm comparison.

Trong khi đó, AWS Documentation là nơi mình tìm đến khi có một câu hỏi kỹ thuật cụ thể cần xác nhận, chứ mình không đọc Documentation từ đầu đến cuối.

1.2. Tài liệu luyện đề

Các nguồn luyện đề mình sử dụng gồm:

• Tutorials Dojo SAA-C03 Practice Exams
• Practice Exams của Stéphane Maarek
• AWS Skill Builder
• CloudExamPro SAA-C03

CloudExamPro

Đây là một trong những nguồn mình thấy khá tốt.

Điểm mình thích là phần giải thích được trình bày bằng tiếng Việt, các câu có tóm tắt requirement, keyword và architecture minh họa nên khá phù hợp với cách mình học qua question.

Nguồn này đặc biệt hữu ích ở giai đoạn mình chưa tự tin với việc đọc những explanation dài bằng tiếng Anh, bởi mình có thể nhanh chóng hiểu mình đang sai ở concept nào rồi quay lại học tiếp.

Tutorials Dojo

Dojo thì mình cảm thấy phù hợp để luyện khả năng đọc scenario, elimination và sự kiên nhẫn với những câu dài hơn.

Nhiều câu tương đối khó và lời giải cũng khá chi tiết. Đôi lúc đọc explanation của một câu xong cảm giác như vừa học thêm nửa chapter, nhưng bù lại mình học được khá nhiều từ cả đáp án đúng lẫn những option sai.

Nếu có nhiều thời gian để luyện thì theo mình Dojo là một lựa chọn khá phù hợp, vì ngoài full practice test còn có nhiều mode như Review Mode, Topic/Section-Based và Timed Mode để lựa chọn, nên mình có thể vừa luyện đề vừa tập trung review đúng những phần còn yếu.

Stéphane Maarek

Practice Exams | AWS Certified Solutions Architect Associate của Stéphane khá tiện vì mình đã học course trước đó, nên có thể sử dụng để kiểm tra lại toàn bộ kiến thức sau khi hoàn thành những section chính.

Mình thấy rằng bộ đề của Stéphane có nhiều câu khá tricky, thường xuất hiện hai option đều có vẻ hợp lý nên khá tốt để luyện elimination và đọc kỹ requirement. Bộ practice test thường khó hơn đề thật, format và cách đặt scenario tương đối sát với kỳ thi.

AWS Official Practice Material

Nếu có subscription phù hợp trên Skill Builder thì mình nghĩ official practice material rất đáng làm.

Bộ câu hỏi được xây dựng theo style của AWS Certification, nên khá hữu ích để làm quen với cách AWS viết scenario, requirement và distractor.

1.3. Quá trình luyện đề của mình

Trong phần lớn quá trình học, điểm practice của mình thường chỉ quanh 75%, có những bài dao động khoảng 70~80%.

Thời điểm đó mình cũng từng hơi lo khi nhìn người khác chia sẻ mock score 85~90% trong khi mình cứ quanh quẩn ở khoảng 75%.

Nhưng vì lúc đó mình đang vừa học vừa làm câu hỏi nên mình dần nhận ra rằng điểm số ở giai đoạn này chưa phải thứ quan trọng nhất.

Mục tiêu thực sự của mình là:

Mỗi bài test phải giúp mình biết thêm mình đang yếu ở đâu.

Những ngày cuối, mình mới bắt đầu chuyển sang chế độ mô phỏng kỳ thi nghiêm túc hơn:

• Không pause
• Không tra Google
• Không dùng AI
• Không xem explanation giữa bài
• Hoàn thành toàn bộ bài trong khoảng thời gian đã đặt ra

Ở một số đề CloudExamPro, điểm của mình lên khoảng 88~91% và lúc đó mình bắt đầu cảm thấy tự tin hơn để đi thi.

Dù vậy, mình không nghĩ có một mốc cố định kiểu:

“Đạt 75% là chắc chắn pass.”

hay:

“Phải 90% mới nên thi.”

Difficulty giữa các bộ practice khác nhau khá nhiều, và quan trọng hơn là mình có thật sự hiểu reasoning phía sau đáp án hay không.

Một người đạt 90% vì đã làm lại cùng một bộ đề ba lần và nhớ đáp án chưa chắc đã vững kiến thức bằng một người đạt 75% ở bộ câu hỏi hoàn toàn mới nhưng có thể giải thích rõ tại sao từng option đúng hoặc sai.

Vậy mình dựa vào đâu để biết mình đã tương đối sẵn sàng?

Thay vì chỉ nhìn vào một con số, những ngày cuối mình quan tâm nhiều hơn tới một vài dấu hiệu:

• Những câu sai bắt đầu tập trung vào một số edge case thay vì những concept core.
• Gặp một câu mới mình có thể loại được phần lớn distractor bằng reasoning.
• Mình có thể giải thích tại sao đáp án đúng và tại sao các option còn lại sai.
• Những topic từng yếu như IAM, Networking hay Database không còn khiến mình “đứng hình” khi gặp scenario.
• Mình có thể hoàn thành full test trong thời gian dự kiến mà vẫn còn buffer để review.

Khi những dấu hiệu này bắt đầu ổn định, mình cảm thấy đã sẵn sàng và đủ tự tin để đi thi.

1.4. Cách mình review câu sai

Đây là phần mình dành khá nhiều thời gian.

Mỗi khi làm sai, thay vì chỉ đọc đáp án đúng rồi chuyển sang câu tiếp theo, mình thường cố xác định tại sao mình sai.

Nếu sai vì không biết service => Quay lại học theory.

Nếu sai vì nhầm hai service => Làm comparison.

Nếu sai vì bỏ sót keyword => Xem lại cách đọc requirement.

Nếu sai vì không hiểu architecture => Vẽ lại architecture.

Với những câu sai, mình thường ghi lại rất ngắn như sau:

Topic => Mình sai ở đâu => Điều cần nhớ

Ví dụ:

• VPC => quên traffic đang cần private access tới S3 => nghĩ tới Gateway Endpoint

• IAM => bỏ sót explicit deny => Deny luôn được ưu tiên khi evaluate permission

• Route 53 => nhầm Latency-based với Geolocation => performance vs geographic location

• SQS => bỏ sót requirement về ordering => kiểm tra Standard hay FIFO

Sau vài bài test, nhìn lại danh sách này giúp mình nhận ra rằng mình đang sai ngẫu nhiên hay thực sự có một pattern cần quay lại học.

Ngoài ra, những câu mình chọn đúng nhưng không chắc mình vẫn flag để review.

Theo mình, một câu trả lời đúng do may mắn vẫn là một lỗ hổng kiến thức, chỉ là hôm đó lỗ hổng đó chưa trừ điểm mình thôi :))

Mình cũng thường review không chỉ đáp án đúng mà cả những option sai vì một option sai trong câu này hoàn toàn có thể trở thành solution đúng trong một scenario khác. Hiểu tại sao nó sai trong context hiện tại giúp mình phân biệt các service tốt hơn rất nhiều.

2. Cách mình xử lý một câu hỏi SAA

2.1. Những dạng câu mình dễ sai nhất

Multiple-response

Một dạng mình phải cẩn thận hơn là những câu yêu cầu:

Choose TWO

hoặc:

Choose THREE

Khó ở chỗ mình có thể khá chắc một đáp án đúng nhưng lại phân vân giữa hai hoặc ba lựa chọn còn lại. Chỉ cần chọn sai một option thì cả câu vẫn bị tính sai.

Với dạng này, mình thường không cố tìm ngay “hai đáp án đúng”, mà đánh giá từng option độc lập:

• Option này có đáp ứng requirement không?
• Có vi phạm constraint nào của đề không?
• Nó có phụ thuộc vào option khác mới hoạt động không?
• Hai đáp án mình chọn có thực sự cùng giải quyết bài toán hay đang giải quyết hai vấn đề khác nhau?

Sau khi chọn xong, mình luôn kiểm tra lại số lượng đáp án trước khi chuyển câu, vì trong lúc làm nhanh rất dễ chỉ chọn một option rồi quên mất đề yêu cầu Choose TWO.

Những câu có solution gồm nhiều bước

Một dạng khác mình từng khá dễ sai là những câu mà mỗi đáp án không chỉ có một service, mà là một chuỗi gồm nhiều bước hoặc nhiều service kết hợp với nhau.

Ví dụ, đề có thể đưa ra những solution kiểu:

Route 53 => CloudFront => ALB => Auto Scaling => RDS Multi-AZ

hoặc yêu cầu thực hiện nhiều bước migration, encryption, replication hay failover theo một thứ tự cụ thể.

Với những câu như vậy, mình tách từng solution thành các bước:

Step 1 => Step 2 => Step 3 => Step 4

sau đó kiểm tra từng bước xem có hợp lý hay không.

Chỉ cần một bước trong chuỗi sai thì mình có thể loại cả option đó.

Ví dụ một solution gồm bốn bước, ba bước đầu hoàn toàn hợp lý nhưng bước cuối lại không đáp ứng requirement về encryption hoặc high availability thì toàn bộ solution vẫn không phải đáp án đúng.

Cách này giúp mình xử lý những đáp án dài dễ hơn khá nhiều, bởi thay vì phải so sánh bốn paragraph cùng lúc, mình chỉ cần tìm: Bước nào khiến solution này không còn phù hợp?

Những câu có nhiều đáp án đều technically đúng

Đây cũng là dạng mình từng mất khá nhiều thời gian.

Có những câu nhìn qua thì hai hoặc thậm chí ba solution đều có thể triển khai được trên AWS. Khi đó sự khác biệt thường không nằm ở việc:

“Solution này có chạy được hay không?”

mà nằm ở những constraint như:

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

Với dạng này, mình thường làm theo hai vòng.

Vòng 1 : Loại những đáp án không đáp ứng requirement chính.

Sau đó nếu vẫn còn hai lựa chọn hợp lý:

Vòng 2 : Quay lại constraint để tìm solution phù hợp nhất.

Ví dụ, cả hai phương án đều có thể tăng availability cho database: một là tự triển khai MySQL trên nhiều EC2 instance và tự cấu hình replication/failover, hai là sử dụng Amazon RDS Multi-AZ. Nếu đề yêu cầu LEAST operational overhead , RDS Multi-AZ sẽ phù hợp hơn vì AWS quản lý phần replication và failover, thay vì mình phải tự vận hành toàn bộ database cluster.

Câu dài không nhất thiết là câu khó

Một kinh nghiệm khác mình rút ra là không nên bị “ngợp” chỉ vì scenario dài.

Có những câu dài một paragraph nhưng requirement thực tế chỉ xoay quanh một vấn đề khá đơn giản. Ngược lại, đôi khi một câu ngắn lại cần phân biệt rất kỹ hai service gần giống nhau.

Vì vậy, khi gặp câu dài mình không đọc đi đọc lại toàn bộ ngay từ đầu. Mình thường xác định:

Architecture hiện tại => Problem => Requirement => Constraint

rồi mới quay lại những chi tiết cần thiết trong context.

Điều này giúp mình tránh dành quá nhiều thời gian cho những thông tin được đưa vào scenario nhưng không thực sự quyết định đáp án.

2.2. Những phần mình cảm thấy khó nhất

Hai nhóm kiến thức làm mình mất nhiều thời gian nhất là IAM/Authorization và những scenario liên quan đến Networking, Multi-account hoặc Multi-Region .

IAM / Authentication / Authorization

Lý do mình thấy IAM khó là một request có thể chịu tác động của rất nhiều lớp policy khác nhau:

Principal => Identity Policy => Role/Trust Policy => Resource Policy => SCP => KMS Key Policy

Khi có thêm cross-account access, mọi thứ càng dễ rối hơn.

Một phương pháp mình thường sử dụng là vẽ account, principal và resource ra giấy rồi lần lượt tự hỏi:

• Principal nằm ở đâu?
• Resource nằm ở đâu?
• Ai assume role?
• Trust Policy cho phép ai?
• Resource Policy có cần hay không?
• Có explicit deny ở đâu không?

Khi chia bài toán thành từng lớp như vậy thì mình thấy dễ xử lý hơn rất nhiều so với việc cố giữ toàn bộ paragraph trong đầu.

Networking, Multi-account và Multi-Region

Những câu này thường dài vì chứa khá nhiều thành phần cùng lúc:

• CIDR
• VPC
• Peering
• Transit Gateway
• VPN
• Direct Connect
• NAT
• Nhiều account
• Nhiều Region

Trong quá trình học, mình nhận thấy overlapping CIDR là một topic khá thú vị.

Ví dụ, nếu hai VPC đều sử dụng 10.0.0.0/16 thì việc kết nối trực tiếp bằng VPC Peering sẽ gặp vấn đề về routing.

Nếu requirement chỉ cần một application ở VPC này expose một service cho VPC khác thay vì cần full network connectivity thì AWS PrivateLink có thể trở thành một lựa chọn đáng xem xét.

Với Multi-Region, mình thường chia câu hỏi thành một số vấn đề nhỏ:

• User được route sang Region nào?
• Data được replicate bằng gì?
• Nếu primary Region fail thì chuyện gì xảy ra?
• RTO/RPO là bao nhiêu?
• Chi phí có cho phép chạy full capacity ở Region thứ hai không?

Khi tách scenario thành những câu hỏi nhỏ như vậy, một paragraph dài thường trở nên dễ xử lý hơn khá nhiều.

2.3. Cách mình đọc một scenario

Mình thường tách câu hỏi thành hai phần:

Context

Đây là phần mô tả architecture hiện tại:

• Workload đang chạy ở đâu?
• Database gì?
• Traffic như thế nào?
• User nằm ở Region nào?
• System có on-premises hay không?

Requirement

Đây là phần mình đặc biệt chú ý:

• High availability
• Disaster recovery
• Cost optimization
• Lowest latency
• Least operational overhead
• Migrate
• Private connectivity
• Decouple

Mình thường đọc context để tạo một mental picture về hệ thống, sau đó đặc biệt chú ý tới requirement và câu hỏi cuối.

Nếu đề hỏi:

Which solution is the MOST cost-effective…?

thì cụm MOST cost-effective có thể thay đổi cách mình đánh giá những đáp án còn lại.

Tương tự, nếu câu hỏi yêu cầu:

with the LEAST operational overhead…

thì một solution sử dụng nhiều EC2 phải tự quản lý dù technically hoạt động được vẫn có thể chưa phải lựa chọn tốt nhất.

Mình thường suy nghĩ theo thứ tự:

Đáp ứng requirement trước => sau đó mới xét security, availability, operations, performance và cost.

Mình không chọn một service chỉ vì nó serverless, managed hoặc rẻ nhất nếu nó không giải quyết đúng bài toán.

2.4. Keyword giúp tăng tốc, nhưng không phải cheat code

Sau khi làm nhiều câu, mình bắt đầu hình thành một số association:

• Decouple => SQS
• Fan-out => SNS
• Read-heavy database => Read Replica / Cache
• Static content + global users => CloudFront
• Private EC2 cần outbound internet => NAT Gateway
• Private access tới AWS service => VPC Endpoint / PrivateLink tùy trường hợp
• Unpredictable event-driven workload => Lambda có thể phù hợp

Những association này giúp mình thu hẹp search space và tăng tốc khá nhiều.

Tuy nhiên, mình không biến những association này thành công thức học thuộc.

Ví dụ, thấy requirement có “shared filesystem” không có nghĩa lúc nào mình cũng chọn EFS. Nếu nhiều Linux EC2 cần dùng chung filesystem thì EFS có thể rất phù hợp, nhưng nếu workload cần SMB cho Windows thì mình sẽ nghĩ tới FSx for Windows File Server , còn workload HPC cần throughput rất cao và xử lý dữ liệu lớn thì FSx for Lustre lại đáng cân nhắc hơn.

Keyword chỉ giúp mình nghĩ tới một số ứng viên ban đầu. Đáp án cuối cùng vẫn phải dựa trên toàn bộ scenario.

2.5. Quản lý thời gian

Kỳ thi tiêu chuẩn có 130 phút, nhưng trong quá trình luyện mình thường đặt mục tiêu hoàn thành 65 câu trong khoảng 120 phút để tạo một khoảng buffer cho việc review.

Vì tiếng Anh không phải ngôn ngữ mẹ đẻ, mình cũng đăng ký ESL +30 accommodation.

Tuy nhiên, trong lúc luyện mình vẫn cố làm với timing ngắn hơn để không phụ thuộc hoàn toàn vào phần thời gian bổ sung.

Một nguyên tắc khá đơn giản của mình là:

• Câu chắc => làm.

• Câu phân vân => flag.

Đừng để một câu phá nhịp cả bài.

Nếu ngồi 8~10 phút ở một câu rồi nhìn đồng hồ thấy còn 25 câu và 20 phút thì lúc đó architectural thinking rất dễ chuyển thành survival mode :))

3. Roadmap 4 tuần mình gợi ý

Roadmap này chủ yếu dựa trên cách mình đã học và phù hợp hơn với người đã có một chút Cloud foundation.

Nếu bắt đầu hoàn toàn từ đầu thì mình nghĩ hoàn toàn có thể kéo từng giai đoạn dài hơn thay vì cố ép bản thân vào đúng bốn tuần.

Tuần 1 – Core AWS

Mình tập trung vào:

IAM, EC2, EBS, Load Balancer, Auto Scaling, S3, VPC và Route 53.

Mục tiêu của tuần đầu không phải học thật nhanh mà là hình thành được một architecture cơ bản trong đầu:

User => Route 53 => Load Balancer => Auto Scaling EC2 => Database

Mình muốn hiểu từng component tồn tại để làm gì, nó scale như thế nào và nếu nó fail thì chuyện gì xảy ra.

Đây cũng là giai đoạn mình nghĩ khá thích hợp để hands-on những service core.

Tuần 2 – Database, Resiliency và Application Integration

Mình chuyển sang:

RDS, Aurora, DynamoDB, ElastiCache, SQS, SNS, Lambda, Amazon API Gateway, Multi-AZ, Read Replica và Disaster Recovery.

Ở tuần này mình bắt đầu nối các service lại với nhau thay vì học từng service riêng biệt.

Ví dụ:

API Gateway => Lambda => DynamoDB

hoặc:

Producer => SQS => Consumer

Sau mỗi architecture mình thường tự hỏi:

• Có single point of failure không?
• Nếu traffic tăng thì component nào scale?
• Nếu database fail thì sao?
• Có cách nào decouple không?

Chỉ vài câu hỏi như vậy đã giúp mình dần suy nghĩ theo hướng của một scenario SAA hơn.

Tuần 3 – Performance, Networking, Migration và Cost

Mình tập trung vào:

CloudFront, Global Accelerator, Direct Connect, VPN, Transit Gateway, Storage Gateway, DataSync, Kinesis, ECS/Fargate, S3 Storage Classes và EC2 pricing.

Đây cũng là lúc mình tăng dần số lượng practice question và bắt đầu làm nhiều câu tổng hợp hơn.

Ở giai đoạn này, thay vì chỉ kiểm tra:

“Mình có nhớ service này không?”

mình bắt đầu quan tâm nhiều hơn tới:

“Nếu hai hoặc ba service cùng xuất hiện trong một scenario thì mình có phân biệt được chúng hay không?”

Tuần 4 – Practice và vá lỗ hổng

Ở tuần cuối, lượng kiến thức mới mình học giảm đáng kể.

Thời gian chủ yếu dành cho:

• Full Practice Exam
• Review câu sai
• Review câu flag
• Exam Guide
• Comparison table
• Architecture
• Note cá nhân

Hai ngày cuối mình không cố nhồi thêm một đống service mới nữa mà chủ yếu xem lại những nhóm mình từng sai hoặc dễ nhầm như IAM, Networking, Database, S3 và Disaster Recovery.

Theo mình, trước kỳ thi não cần review và nghỉ ngơi hơn là thêm một đợt DDoS kiến thức mới.

4. Những ngày cuối và trải nghiệm kỳ thi

4.1. Một vài ngày trước kỳ thi

Ngày cuối, mình chủ yếu xem lại note tóm tắt và những câu từng sai nhiều lần.

Mình không học thêm quá nhiều hoặc đọc lại toàn bộ slide vì lúc này hiệu quả không còn cao.

Điều mình ưu tiên hơn là ngủ đủ và giữ tâm lý tương đối thoải mái.

Nếu thực sự chưa cảm thấy sẵn sàng thì mình nghĩ reschedule là một lựa chọn hoàn toàn bình thường. Theo policy hiện tại của AWS, một appointment có thể được reschedule tối đa hai lần và việc thay đổi phải thực hiện trước ít nhất 24 giờ. Thông tin policy tại thời điểm đăng ký nên được kiểm tra trực tiếp tại AWS Certifcation – Before Testing vì chính sách có thể thay đổi theo thời gian.

4.2. Chuẩn bị tới Testing Center

Trước ngày thi mình kiểm tra lại:

• Email confirmation
• Ngày giờ
• Địa chỉ Testing Center
• Giấy tờ cần mang theo
• Đường đi

Mình cũng cố gắng đến sớm để tránh những vấn đề không mong muốn.

Nghe thì khá hiển nhiên, nhưng học Disaster Recovery cả tháng rồi sáng ngày thi lại không có phương án dự phòng cho kẹt xe thì cũng hơi buồn :))

4.3. Trải nghiệm tại Testing Center

Testing Center mình thi ở TP.HCM có phòng máy tương đối nhỏ, chỉ khoảng vài máy.

Những thí sinh khác có thể đang thi các chứng chỉ khác nhau và vào hoặc rời phòng ở những thời điểm khác nhau do đó sẽ khiến mình phân tâm, và trong quá trình làm bài vẫn có thể nghe tiếng click chuột, bàn phím hoặc có một chút tiếng ồn bên ngoài phòng thi.

Nếu là người dễ mất tập trung thì mình nghĩ nên chuẩn bị tâm lý trước cho môi trường này.

4.4. Cảm nhận về đề thật

Cảm nhận cá nhân của mình là đề chính thức dễ chịu hơn một số bộ practice test mà mình đã làm.

Điều giúp mình bình tĩnh nhất là hầu hết service và architecture pattern đều đã học qua và tương đối quen thuộc, nên mình không gặp quá nhiều cảm giác đọc một câu rồi tự hỏi:

“Service này là AWS service hay tên Pokémon mới vậy?”

Những câu có requirement rõ ràng mình chọn khá nhanh.

Những câu dài, có nhiều bước hoặc mình vẫn còn phân vân thì mình flag lại rồi tiếp tục, thay vì dành quá nhiều thời gian ngay ở lượt đầu.

Việc đã luyện cách làm như vậy trước kỳ thi giúp mình giữ được nhịp tương đối ổn định.

4.5. Review trước khi submit

Sau khi hoàn thành lượt đầu và quay lại những câu đã flag, mình vẫn còn khoảng 30 phút.

Thay vì submit sớm, mình sử dụng phần thời gian còn lại để chạy lại toàn bộ 65 câu thêm một lần nữa.

Lúc này mình chủ yếu kiểm tra:

• Có click nhầm đáp án không?
• Có bỏ sót MOST hoặc LEAST không?
• Multiple-response có chọn thiếu option không?
• Có câu nào lúc đầu mình hiểu sai requirement không?

Trong quá trình luyện mình từng gặp khá nhiều trường hợp những câu khó thì lại làm đúng, nhưng một câu khá dễ lại mất điểm chỉ vì click nhầm hoặc đọc sót một chữ.

Do đó, nếu vẫn còn thời gian thì mình nghĩ việc review lại toàn bộ khá đáng vì dù sao kỳ thi cũng không có leaderboard cho người bấm Finish nhanh nhất :))

Kết luận

Nhìn lại toàn bộ quá trình chuẩn bị cho SAA, mình thấy practice question không chỉ là công cụ để đo xem mình đã sẵn sàng đi thi hay chưa. Nó còn giúp mình phát hiện lỗ hổng kiến thức, luyện cách đọc scenario, xử lý distractor và dần hình thành cách reasoning ổn định hơn.

Roadmap bốn tuần trong bài chỉ là cách mình đã học và không nhất thiết phù hợp với tất cả mọi người. Điều mình nghĩ quan trọng hơn timeline là đến giai đoạn cuối, mình có thể nhìn một scenario và giải thích được requirement là gì, tại sao solution này phù hợp và vì sao những lựa chọn còn lại chưa tối ưu bằng .

Với mình, kết quả 1000/1000 là một cái kết rất đẹp cho khoảng một tháng ôn tập, nhưng điều đáng giá hơn là sau kỳ thi mình cảm thấy những kiến thức AWS trước đây khá rời rạc đã được kết nối thành một bức tranh rõ ràng hơn về cách thiết kế architecture.

Hy vọng series này có thể giúp mọi người tìm được một cách học phù hợp với bản thân và có thêm một góc nhìn thực tế trong quá trình chuẩn bị cho AWS Certified Solutions Architect – Associate.

Chúc mọi người học tốt và sớm đạt được mục tiêu AWS Certification của mình!