BÀI 2. Phương pháp ôn tập hiệu quả trong 1 tháng: Cách ghi chú ngắn gọn & Tận dụng AI

Sau khi đã chia sẻ về cách mình thay đổi mindset khi tiếp cận SAA ở Bài 1 , phần tiếp theo mình muốn nói kỹ hơn về cách mình thực sự học trong khoảng một tháng ôn tập.

Với lượng kiến thức khá lớn của SAA, mình nhận ra rằng chỉ dành nhiều thời gian thôi chưa chắc đã hiệu quả. Điều quan trọng hơn là biết phần nào cần học kỹ, ghi chú như thế nào để có thể review nhanh, xử lý ngay những concept chưa hiểu và bắt đầu luyện câu hỏi đủ sớm để phát hiện lỗ hổng kiến thức.

1. Học lý thuyết và ghi chú

Mình ôn trong khoảng một tháng và do thời gian tương đối có hạn nên trong giai đoạn học lý thuyết, trung bình mỗi ngày mình dành khoảng 6~7 tiếng cho SAA. Đây là cường độ tương đối cao, nhưng lúc đó mình có khá nhiều thời gian rảnh nên có thể tập trung gần như toàn bộ vào việc học.

Nguồn học chính mình lựa chọn là khóa Ultimate AWS Certifed Solutions Architect Associate của Stéphane Maarek trên Udemy.

Mình chọn khóa này sau khi tham khảo các review trong cộng đồng. Điều mình thích là nội dung được trình bày tương đối cô đọng, video dễ theo dõi, giọng của Stéphane khá dễ nghe, đồng thời khóa học đi kèm bộ slide rất đầy đủ nên mình có thể sử dụng luôn làm nguồn review thay vì phải tự tìm thêm quá nhiều tài liệu bên ngoài.

Mình thường xem video kết hợp với slide. Những section mà kiến thức đã khá quen thì mình tăng tốc video hoặc đọc slide nhanh hơn, trong khi những phần như IAM, VPC, RDS, Disaster Recovery hay các service có nhiều lựa chọn dễ nhầm thì mình dành thời gian lâu hơn.

Trong lúc học, mình có thói quen ghi note khá nhiều. Tuy nhiên, mình không ghi lại nguyên văn toàn bộ slide vì nếu làm vậy thì cuối cùng mình chỉ đang tạo ra một bản slide thứ hai bằng chữ viết tay.

Thay vào đó, với mỗi service mình thường ghi lại một số điểm chính như:

• Service này giải quyết vấn đề gì?
• Use case phổ biến là gì?
• Có limitation nào đáng chú ý?
• Có Multi-AZ hoặc Multi-Region hay không?
• Security/encryption hoạt động thế nào?
• Dễ nhầm với service nào?

Ví dụ với SQS, thay vì ghi một đoạn rất dài, note của mình có thể đơn giản là:

Queue => asynchronous => decouple => producer/consumer scale độc lập => Visibility Timeout => DLQ => Standard/FIFO.

Mình cũng ghi những service khác theo cách tương tự. Ví dụ:

RDS Multi-AZ => HA => standby => automatic failover => không dùng để scale read

Read Replica => read scaling => asynchronous replication => có thể promote

CloudFront => CDN => edge cache => HTTP/HTTPS => static/dynamic content => origin

Cách ghi như vậy giúp mình tạo được một mental model khá rõ mà không cần đọc lại quá nhiều chữ.

Sau này khi gặp một scenario mô tả producer tạo request nhanh hơn consumer có thể xử lý, mình không cần cố nhớ lại cả slide về SQS mà chỉ cần liên kết tình huống đó với ý buffer => decouple => scale độc lập.

Theo mình, mục tiêu của note không phải là lưu lại toàn bộ những gì mình đã học, mà là giúp mình gợi nhớ nhanh những điểm quan trọng nhất khi cần review.

2. Cách mình sử dụng AI trong quá trình học

Một công cụ mình sử dụng khá thường xuyên trong quá trình học là AI.

Thay vì đọc một phần trong slide chưa hiểu rồi bỏ qua với suy nghĩ “để lát xem lại”, mình thường cố xử lý ngay tại thời điểm đó.

Mình nhận ra rằng nếu bỏ qua một concept khó rồi tiếp tục học, các phần phía sau đôi khi lại phụ thuộc vào chính concept đó. Kết quả là mình không chỉ chưa hiểu phần trước mà những phần sau cũng bắt đầu trở nên khó hiểu hơn.

Ví dụ, trong quá trình học mình từng hỏi khá nhiều những câu kiểu:

• Vì sao RDS Multi-AZ không dùng để scale read?
• Tại sao Security Group được gọi là stateful còn Network ACL là stateless?
• Khi nào nên dùng NAT Gateway và khi nào nên dùng VPC Endpoint?
• CloudFront và Global Accelerator đều có edge location thì tại sao use case lại khác nhau?
• IAM Role, Resource Policy, Trust Policy và SCP tương tác với nhau như thế nào?

Mình thường yêu cầu AI giải thích trước theo cách đơn giản, sau đó cho thêm một ví dụ hoặc vẽ architecture để mình dễ hình dung hơn.

Có những concept khi đọc một paragraph dài mình vẫn cảm thấy khá mơ hồ, nhưng khi nhìn nó dưới dạng một flow hoặc một architecture đơn giản thì mọi thứ lại rõ hơn rất nhiều.

Tuy nhiên, mình không xem câu trả lời đầu tiên của AI là nguồn sự thật tuyệt đối.

Nếu nội dung liên quan đến service behavior, limit, security hoặc một feature cụ thể, mình thường tiếp tục kiểm tra lại bằng AWS Documentation.

Cách mình sử dụng thường khá đơn giản: AI để hiểu nhanh => AWS Docs để xác nhận.

Nếu mô tả cụ thể hơn thì workflow mình thường dùng sẽ giống như: Concept chưa hiểu => Nhờ AI giải thích đơn giản => Yêu cầu ví dụ/architecture => So sánh với service dễ nhầm => Kiểm tra lại AWS Docs => Tự ghi note bằng vài keyword

Ví dụ, nếu mình chưa hiểu rõ NAT Gateway và VPC Endpoint, mình không dừng lại ở việc hỏi định nghĩa của hai service. Mình thường hỏi tiếp khi nào nên dùng từng cái, cho một scenario để phân biệt, sau đó kiểm tra lại behavior quan trọng trong AWS Documentation rồi mới ghi vào note cá nhân.

Theo trải nghiệm của mình, AI cực kỳ hữu ích trong việc rút ngắn thời gian tìm hiểu và giúp mình tiếp cận những concept khó theo cách dễ hiểu hơn. Nhưng với những thông tin kỹ thuật có thể thay đổi theo thời gian, AWS Documentation vẫn là nguồn mình ưu tiên để xác nhận lại.

3. Học lý thuyết song song với Practice Question

Một điểm nữa mình thấy khá hiệu quả là không đợi học xong toàn bộ course mới bắt đầu luyện câu hỏi.

Ban đầu mình cũng có suy nghĩ nên học hết lý thuyết trước rồi mới giải đề để tránh cảm giác “chưa học mà đã làm”.

Nhưng sau đó mình nhận ra rằng nếu học liên tục quá nhiều service, những phần đầu có thể đã bắt đầu mờ đi trước khi mình học tới phần cuối.

Vì vậy, sau khi hoàn thành một nhóm kiến thức, mình bắt đầu làm một số question liên quan để kiểm tra xem mình thực sự hiểu tới đâu.

Ở giai đoạn đầu mình chủ yếu làm question theo topic hoặc nhóm service , chứ chưa vội làm full 65 câu như một kỳ thi thật. Full Practice Exam mình dành nhiều hơn cho giai đoạn sau khi đã đi qua phần lớn nội dung.

Ví dụ, sau khi học các Route 53 routing policy, nếu chỉ đọc riêng từng loại thì mình cảm thấy khá dễ hiểu.

Nhưng khi gặp một scenario hỏi nên route user tới Region có network latency thấp nhất , đồng thời trong đáp án lại xuất hiện cả Latency-based Routing và Geolocation Routing, mình buộc phải hiểu rõ mục tiêu của từng policy thay vì chỉ nhớ tên.

Đây là lúc mình nhận ra khá nhiều trường hợp mình tưởng là đã hiểu một service, nhưng khi hai hoặc ba lựa chọn gần giống nhau cùng xuất hiện thì vẫn bắt đầu phân vân.

Chính những câu như vậy giúp mình phát hiện sớm những phần kiến thức còn chưa chắc.

Vì vậy, mình dần không còn xem practice question chỉ là một phép đo trước ngày thi. Với mình, nó trở thành một phần của quá trình learning.

Có những concept mình xem video hai lần vẫn thấy khá bình thường, nhưng chỉ cần làm sai một câu đủ “đau” về concept đó thì lần sau lại nhớ rất lâu.

Theo mình, practice question có hai vai trò khác nhau:

• Trong giai đoạn học : dùng để tìm lỗ hổng kiến thức.
• Trong giai đoạn cuối : dùng để kiểm tra readiness và luyện chiến thuật làm bài.

Ở giai đoạn này, điều mình quan tâm nhiều hơn không phải là điểm số mà là: Sau câu hỏi này, mình phát hiện ra mình chưa hiểu điều gì?

4. Khả năng đọc tiếng Anh cũng khá quan trọng

SAA không yêu cầu mình phải giỏi tiếng Anh, nhưng reading comprehension ảnh hưởng khá rõ đến tốc độ và độ chính xác khi làm bài.

Một scenario có thể khá dài, nhưng đôi khi sự khác biệt giữa hai đáp án lại chỉ nằm ở một vài từ trong requirement như:

MOST cost-effective

hoặc:

LEAST operational overhead

Nếu bỏ sót hoặc hiểu sai những cụm này thì dù kiến thức AWS của mình đúng, mình vẫn có thể chọn sai solution.

Ví dụ, hai architecture có thể đều technically giải quyết được bài toán, nhưng nếu đề yêu cầu LEAST operational overhead, một solution sử dụng nhiều EC2 phải tự quản lý có thể không còn là lựa chọn tốt nhất khi bên cạnh nó có một managed service phù hợp hơn.

Vì vậy, quá trình luyện câu hỏi của mình cũng đồng thời là quá trình luyện khả năng đọc scenario: xác định context, tìm requirement chính và chú ý tới những từ có thể làm thay đổi hoàn toàn tiêu chí lựa chọn đáp án.

Theo mình, đây là một kỹ năng khá dễ bị bỏ qua. Đôi lúc vấn đề không phải là mình không biết AWS service nào phù hợp, mà đơn giản là mình đã đọc sai thứ câu hỏi đang thực sự yêu cầu.

Kết luận

Trong khoảng một tháng ôn SAA, mình không học tất cả mọi thứ với cùng một cách. Những phần đã quen mình đi nhanh hơn, những concept khó thì xử lý ngay bằng AI và AWS Documentation, còn note được giữ càng ngắn gọn càng tốt để phục vụ cho việc review sau này.

Một thay đổi cũng khá quan trọng là mình bắt đầu practice question từ sớm thay vì đợi tới cuối course. Nhờ vậy, câu hỏi không chỉ dùng để kiểm tra điểm số mà còn giúp mình phát hiện những chỗ mình tưởng đã hiểu nhưng thực tế vẫn còn khá mơ hồ.

Ở Bài 3 , mình sẽ chuyển từ phần học lý thuyết sang hands-on: những service mình thấy đáng thực hành, những kiến thức mình nhớ lâu hơn sau khi tự cấu hình và một phần rất thực tế khi học AWS – quản lý chi phí và cleanup resource sau mỗi bài lab.