Ngân hàng đề — AWS Certified Cloud Practitioner

🧩 Phân tích nội dung câu hỏi

Đề bài đặt bối cảnh: một Cloud Practitioner đang re-architecting a monolithic application (tái kiến trúc một ứng dụng khối), và hỏi AWS khuyến nghị những nguyên tắc thiết kế (design principles) nào cho kiến trúc trên cloud. Chọn HAI.

Hai cụm từ quyết định đáp án:

• "design principles ... AWS recommend" — câu hỏi không hỏi "cách nào chạy được", mà hỏi khuyến nghị chính thức của AWS, tức là ngôn ngữ của AWS Well-Architected Framework. Bất kỳ phương án nào mô tả thói quen vận hành kiểu on-premises truyền thống đều bị loại ngay, dù về mặt kỹ thuật vẫn "làm được".
• "monolithic application" — điểm xuất phát là một khối duy nhất, các thành phần dính chặt vào nhau. Việc tái kiến trúc một monolith có đúng hai hướng đi kinh điển: tách các thành phần ra cho bớt phụ thuộc lẫn nhau và cho hệ thống co giãn được theo tải. Cụm từ này chính là thứ chỉ thẳng vào B và E.

Bốn trong năm phương án đều là cặp đối lập nhau từng đôi một (scalability tự động ↔ scalability thủ công; loose coupling ↔ phụ thuộc vào từng thành phần riêng lẻ). Nhận ra thế đối lập đó là đủ để chốt đáp án mà không cần nhớ nguyên văn tài liệu.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B và E.

B — Design for scalability. AWS khuyến nghị thiết kế ứng dụng scale horizontally (thêm bớt nhiều đơn vị nhỏ) để tăng khả năng sẵn sàng của tổng thể workload, và việc scale này nên tự động hoá bất cứ khi nào có thể. Với một monolith vừa được tách ra, đây là nguyên tắc cho phép hệ thống hấp thụ tải tăng đột biến mà không phải dựng sẵn hạ tầng dư thừa quanh năm.

E — Implement loose coupling. Các thành phần trung gian như queuing system, streaming system, workflow và load balancer chính là cách hiện thực hoá loose coupling. Khi các thành phần chỉ nói chuyện với nhau qua một giao diện được định nghĩa rõ ràng thay vì gọi thẳng vào nhau, hành vi của một thành phần được cô lập khỏi những thành phần phụ thuộc nó — một phần chậm hoặc chết không kéo sập phần còn lại. Kết quả là hệ thống vừa resilient (bền hơn trước sự cố) vừa agile (đổi hoặc thay từng phần mà không phải đụng cả khối). Đây đúng là thứ mà việc tái kiến trúc một monolith nhắm tới.

❌ Vì sao các phương án còn lại sai

A — Use self-managed servers. AWS không khuyến nghị tự quản lý server. Định hướng của AWS là ưu tiên serverless và các dịch vụ được quản lý khi có thể, để phần vận hành hạ tầng (vá lỗi, thay máy hỏng, mở rộng) chuyển sang phía AWS. Phương án này mô tả đúng cái mô hình on-premises mà việc re-architecting đang muốn thoát ra.

C — Implement manual scalability. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nó có chữ "scalability" giống hệt đáp án B. Chỗ hỏng nằm ở từ "manual": AWS khuyến nghị không dùng quy trình thủ công, mọi thứ nên được tự động hoá tối đa. Scale bằng tay nghĩa là phải có người trực để nhận ra tải tăng và bấm nút — hệ thống co giãn chậm hơn tải thực tế, và mỗi lần bấm là một cơ hội sai sót của con người. Nói cách khác: hướng đi đúng (scale), cách làm sai (thủ công).

D — Rely on individual components. Phương án này là mặt đối lập trực tiếp của E. Phụ thuộc vào một thành phần đơn lẻ nghĩa là thành phần đó trở thành điểm chết duy nhất — nó hỏng thì cả ứng dụng hỏng theo. Thực hành đúng là xây redundancy vào hệ thống, để sự cố của một thành phần riêng lẻ không ảnh hưởng tới hoạt động của ứng dụng. Đây không phải best practice, và nó cũng đi ngược đúng cái lý do người ta bỏ monolith.

📌 Điểm cần nhớ

• Trong đề Cloud Practitioner, hễ phương án chứa chữ "manual", "self-managed" hoặc mô tả một thao tác cần người trực, gần như chắc chắn đó là phương án sai — AWS luôn nghiêng về automation và managed/serverless.
• Loose coupling được hiện thực hoá bằng các thành phần trung gian như queue, streaming, workflow, load balancer; giá trị của nó là cô lập lỗi giữa các thành phần, đổi lấy resiliency và agility.
• Scalability đúng nghĩa của AWS là scale horizontally và tự động — thêm nhiều đơn vị nhỏ, chứ không phải làm to một máy hay tự tay điều chỉnh.
• Khi hai phương án chỉ khác nhau một tính từ (scalability vs manual scalability), tính từ đó chính là chỗ đề bài đặt bẫy — đọc kỹ nó trước khi chọn.

🧩 Phân tích nội dung câu hỏi

Đề hỏi: những cách nào giúp tăng cường bảo mật cho việc truy cập AWS Management Console? (Chọn HAI).

Cụm từ quyết định là "access to the AWS Management Console" — tức là bảo vệ hành vi đăng nhập của con người vào giao diện web quản trị AWS. Đây không phải câu hỏi về bảo mật đường truyền, không phải bảo mật lưu trữ thông tin bí mật của ứng dụng, cũng không phải bảo mật luồng mạng tới máy chủ. Chỉ cần bám đúng cụm này là bốn phương án gần giống nhau (mỗi cái đều là một dịch vụ bảo mật thật của AWS) lập tức tách ra: cái nào tác động lên danh tính người đăng nhập thì đúng, cái nào tác động lên tầng khác thì sai.

Chi tiết thứ hai đáng chú ý: đề nói "improve the security of access" — cải thiện, chứ không phải thay thế hoàn toàn. Nghĩa là hai câu trả lời được cộng thêm vào cơ chế đăng nhập bằng username/password sẵn có, không phải một dịch vụ khác đứng ra thay việc đăng nhập.

✅ Vì sao đáp án đúng là đúng

A. AWS Multi-Factor Authentication (AWS MFA) AWS khuyến nghị bật MFA cho tất cả người dùng trong tài khoản. Với MFA, người dùng có một thiết bị sinh ra mã trả lời cho thử thách xác thực. Để đăng nhập thành công cần cả hai: thông tin đăng nhập của người dùng (something you know) và mã do thiết bị sinh ra (something you have). Nhờ vậy, nếu mật khẩu hoặc access key của một người bị lộ, tài nguyên trong tài khoản vẫn an toàn vì kẻ tấn công thiếu yếu tố thứ hai. Đây đúng là biện pháp tác động thẳng vào cửa đăng nhập Management Console.

E. Strong password policies Chính sách mật khẩu mạnh áp đặt các yêu cầu như độ dài tối thiểu, độ phức tạp (chữ hoa, chữ thường, số, ký tự đặc biệt) và hạn chế dùng lại mật khẩu cũ. Nó nâng chi phí của việc đoán/brute-force mật khẩu và giảm thiệt hại khi một mật khẩu bị rò rỉ ở nơi khác. Cũng như MFA, nó tác động trực tiếp lên bước đăng nhập Console.

Hai phương án này bổ sung cho nhau: một cái làm mật khẩu khó bẻ hơn, một cái làm mật khẩu bị bẻ cũng chưa đủ để vào.

❌ Vì sao các phương án còn lại sai

B. AWS Secrets Manager — Đây là phương án dễ nhầm nhất, vì nó nghe rất giống "quản lý thông tin đăng nhập". Nhưng Secrets Manager phục vụ việc lưu trữ, xoay vòng (rotate), quản lý và truy xuất các bí mật của ứng dụng — database credentials, API key và các loại secret khác trong suốt vòng đời của chúng. Nó bảo vệ bí mật mà code dùng để gọi dịch vụ khác, chứ không hề can thiệp vào việc một con người gõ mật khẩu để đăng nhập Management Console. Sai ở chỗ nhầm đối tượng được bảo vệ: ứng dụng ≠ người đăng nhập Console.

C. Security group rules — Security group là firewall ảo hoạt động ở tầng mạng, dùng để giới hạn traffic đi vào/ra các EC2 instance của bạn. Đúng là một biện pháp bảo mật, nhưng nó nằm trong VPC và điều khiển luồng mạng tới tài nguyên; nó không kiểm soát ai được đăng nhập vào giao diện quản trị AWS. Sai ở chỗ nhầm tầng: tầng mạng thay vì tầng danh tính.

D. AWS Certificate Manager — Dịch vụ này dùng để tạo và quản lý chứng chỉ SSL/TLS phục vụ kết nối HTTPS. Nó bảo vệ dữ liệu trên đường truyền (chống nghe lén, chống giả mạo máy chủ) cho các dịch vụ của bạn. Có liên quan tới bảo mật, nhưng chứng chỉ TLS không quyết định ai được phép đăng nhập; hơn nữa bản thân Management Console đã chạy trên HTTPS do AWS vận hành, không phải thứ bạn cấp chứng chỉ vào. Sai ở chỗ nhầm mục tiêu: mã hoá đường truyền thay vì xác thực danh tính.

📌 Điểm cần nhớ

• Với câu hỏi kiểu "bảo mật truy cập vào Management Console", hãy chỉ giữ lại những phương án tác động lên danh tính và quá trình đăng nhập: MFA và chính sách mật khẩu. Đây là cặp câu trả lời kinh điển của kỳ thi Cloud Practitioner.
• MFA dựa trên nguyên tắc kết hợp hai yếu tố khác loại — something you know (mật khẩu) và something you have (thiết bị sinh mã) — nên mật khẩu bị lộ vẫn chưa đủ để vào tài khoản.
• Phân biệt rõ ba tầng hay bị trộn lẫn trong đề AWS: Security group = kiểm soát traffic mạng tới EC2; AWS Certificate Manager = chứng chỉ SSL/TLS cho HTTPS; AWS Secrets Manager = lưu và xoay vòng bí mật cho ứng dụng. Không cái nào là cơ chế đăng nhập Console.
• Mẹo loại trừ nhanh: đọc kỹ đối tượng mà đề muốn bảo vệ (người dùng Console, dữ liệu trên đường truyền, instance, hay bí mật của ứng dụng) rồi ghép với dịch vụ đúng tầng — phần lớn phương án nhiễu trong nhóm Security, Identity & Compliance sai vì lệch tầng chứ không sai về bản chất dịch vụ.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống vận hành: một Cloud Practitioner phát hiện các IP address thuộc sở hữu của AWS đang cố gắng flood các port trên hệ thống của công ty. Câu hỏi là: báo sự việc này cho ai?

Cụm từ quyết định đáp án nằm ở hai chi tiết ghép lại:

• "IP addresses that are owned by AWS" — nguồn tấn công xuất phát từ bên trong hạ tầng AWS, tức là ai đó đang dùng tài nguyên AWS (nhiều khả năng là một EC2 instance của khách hàng khác) để làm việc xấu.
• "attempt to flood ports" — đây là hành vi lạm dụng (abuse), không phải một sự cố kỹ thuật của chính hệ thống công ty, cũng không phải một câu hỏi về kiến trúc hay hợp đồng.

Ghép lại: đây là một abuse report về tài nguyên AWS bị lạm dụng. Bốn phương án đều là những "bộ phận của AWS" mà người mới học rất dễ nhầm, nên phải phân biệt theo đúng chức năng từng bộ phận chứ không theo cảm giác "cái nào nghe có vẻ liên quan tới bảo mật".

✅ Vì sao đáp án đúng là đúng

C — AWS Trust & Safety team.

Đây chính là bộ phận AWS lập ra để tiếp nhận các báo cáo lạm dụng khi tài nguyên AWS bị dùng vào mục đích xấu: quét/flood port, tấn công từ chối dịch vụ, phát tán spam, malware, lừa đảo, nội dung vi phạm. Kênh liên hệ là Report Amazon AWS abuse form hoặc email abuse@amazonaws.com.

Điểm mấu chốt là quyền hành động: chỉ Trust & Safety mới truy ngược được từ IP sang tài khoản AWS đứng sau và áp dụng biện pháp với tài khoản đó. Không bộ phận nào trong ba phương án còn lại có thẩm quyền này.

Khi gửi báo cáo, nên kèm đầy đủ bằng chứng: log ở dạng plaintext, email header (nếu là abuse qua email), dấu thời gian, IP nguồn — thiếu bằng chứng thì báo cáo khó được xử lý.

❌ Vì sao các phương án còn lại sai

A — AWS Partner Network (APN). Đây là chương trình đối tác: tập hợp các công ty tư vấn và nhà cung cấp phần mềm hợp tác với AWS, kèm các cấp bậc và lợi ích dành cho đối tác. APN là một kênh kinh doanh/hệ sinh thái, không phải nơi tiếp nhận sự cố bảo mật. Gửi báo cáo abuse tới đây thì không có ai xử lý.

B — AWS Technical Account Manager (TAM). Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. TAM là người hỗ trợ kỹ thuật được chỉ định riêng cho khách hàng ở mức support cao cấp: tư vấn kiến trúc, tối ưu chi phí, chuẩn bị cho các sự kiện tăng tải, làm cầu nối với AWS. TAM hỏng ở hai chỗ: (1) TAM chỉ có với một số mức support nhất định — không phải khách hàng nào cũng có, trong khi kênh báo abuse thì mọi người đều dùng được, kể cả người không phải khách hàng AWS; (2) TAM chăm sóc tài khoản của bạn, còn vấn đề ở đây nằm ở tài khoản của người khác. TAM cùng lắm chuyển tiếp thông tin, chứ đúng địa chỉ vẫn là Trust & Safety.

D — AWS Professional Services. Đây là đội ngũ tư vấn triển khai có tính phí: giúp khách hàng di chuyển workload lên cloud, thiết kế và xây dựng giải pháp. Họ làm dự án theo hợp đồng, không trực chiến sự cố và cũng không có thẩm quyền xử lý tài khoản vi phạm. Đây là mối quan hệ tư vấn, hoàn toàn lệch khỏi tình huống trong đề.

📌 Điểm cần nhớ

• Tài nguyên AWS bị dùng để tấn công → AWS Trust & Safety, qua form report abuse hoặc abuse@amazonaws.com. Đây là phản xạ cần có với mọi câu hỏi chứa từ khoá "abuse", "IP owned by AWS", "port flooding", "spam/malware phát ra từ AWS".
• Phân biệt rõ vai trò bốn nhóm hay bị trộn lẫn trong đề thi: APN = đối tác, TAM = hỗ trợ kỹ thuật riêng cho tài khoản của chính bạn, Professional Services = tư vấn triển khai có phí, Trust & Safety = xử lý lạm dụng.
• Phân biệt hướng của vấn đề: sự cố nằm trong tài khoản của chính mình thì đi đường AWS Support/TAM; hành vi xấu phát ra từ tài khoản của người khác thì đi đường abuse report.
• Khi gửi abuse report, luôn kèm bằng chứng dạng văn bản thuần (log, email header, mốc thời gian) — chi tiết này hay xuất hiện trong các câu hỏi biến thể cùng chủ đề.

🧩 Phân tích nội dung câu hỏi

Đề hỏi: những phát biểu nào là đúng về Consolidated Billing? — và bắt chọn HAI phương án.

Cụm từ quyết định nằm ngay ở tên tính năng: "Consolidated" — nghĩa là gộp lại. Toàn bộ mục đích của Consolidated Billing là gộp nhiều AWS account trong một tổ chức lại để chỉ nhận một hoá đơn duy nhất, và để usage của các account được cộng dồn khi tính giá.

Vì vậy năm phương án ở đây chia đúng làm hai nhóm:

• Nhóm nói về phí phải trả cho chính tính năng này (A, B) — Consolidated Billing là tính năng đi kèm, không tính phí riêng.
• Nhóm nói về cách hoá đơn được phát hành (C, E) — đây là cặp đối nghịch nhau: "một hoá đơn cho mỗi account" so với "một hoá đơn cho nhiều account". Chỉ một trong hai đúng, và chính chữ consolidated trong đề chỉ thẳng ra vế nào.

Phương án D đứng riêng, nói về lợi ích tính giá theo khối lượng.

✅ Vì sao đáp án đúng là đúng

Theo tệp, đáp án đúng là D và E.

E — "You receive a single bill for multiple accounts": đây là lợi ích one bill được nêu thẳng trong tài liệu AWS. Thay vì mỗi account tự nhận hoá đơn riêng, account quản lý (management account) nhận một hoá đơn gộp cho toàn bộ account trong tổ chức. Nhờ vậy bộ phận kế toán chỉ phải xử lý một chứng từ, đồng thời vẫn theo dõi và tải về được dữ liệu chi phí – mức sử dụng đã gộp của tất cả account.

D — "You can combine usage and share volume pricing discounts": đây là lợi ích combined usage. AWS cộng dồn mức sử dụng của tất cả account trong tổ chức lại rồi mới áp bậc giá. Nhiều dịch vụ AWS có cơ chế volume pricing (dùng càng nhiều thì đơn giá bậc sau càng rẻ), nên khi gộp usage, tổng khối lượng chạm được bậc giá tốt hơn so với từng account đứng riêng lẻ. Tương tự, phần giảm giá của Reserved Instance cũng được chia sẻ trong tổ chức. Kết quả là chi phí chung của cả công ty/phòng ban thấp hơn so với để các account tách rời.

Điểm chung của cả hai đáp án đúng: chúng đều là hệ quả trực tiếp của việc gộp — gộp hoá đơn (E) và gộp mức sử dụng (D).

❌ Vì sao các phương án còn lại sai

A — "You pay a fee per linked account": sai. Consolidated Billing không thu phí theo số account được liên kết vào tổ chức. Đây là phương án đánh vào tâm lý "tính năng quản trị thì chắc phải tốn tiền". Bạn vẫn trả tiền cho tài nguyên AWS mà từng account tiêu thụ, nhưng bản thân việc gộp hoá đơn thì không phát sinh khoản phí riêng nào.

B — "You are charged a fee per user": sai vì hai lý do. Thứ nhất, giống A, không có phí cho tính năng này. Thứ hai, đơn vị cũng sai: Consolidated Billing làm việc ở cấp account, không phải cấp user — mô hình tính tiền của AWS gắn với tài nguyên tiêu thụ, không phải với số người dùng như phần mềm SaaS bán theo đầu người.

C — "You receive one bill per AWS account": đây là phương án gần đúng và dễ mắc bẫy nhất, vì nó mô tả đúng tình trạng khi KHÔNG dùng Consolidated Billing. Nó hỏng ở chỗ nói ngược hoàn toàn ý nghĩa của tính năng: mục đích của Consolidated Billing chính là để bạn thôi nhận nhiều hoá đơn riêng lẻ. C và E loại trừ nhau, nên chọn C là tự mâu thuẫn với E. Lưu ý: bạn vẫn xem được chi tiết chi phí tách theo từng account, nhưng đó là phần theo dõi/phân tích trong dữ liệu chi phí, khác với việc phát hành hoá đơn riêng cho mỗi account.

📌 Điểm cần nhớ

• Consolidated Billing = một hoá đơn + usage được cộng dồn. Nhớ đúng hai lợi ích cốt lõi này là xử lý được phần lớn câu hỏi về chủ đề này: one bill, easy tracking, combined usage.
• Tính năng này không có phí riêng. Gặp phương án nào nói "phí theo account" hay "phí theo user" gắn với Consolidated Billing thì loại ngay.
• Gộp usage đem lại lợi ích tài chính thật: chạm bậc volume pricing tốt hơn và chia sẻ được phần giảm giá của Reserved Instance trong toàn tổ chức.
• Cẩn thận với cặp phương án đối nghịch. Khi đề đưa cả "one bill per account" lẫn "single bill for multiple accounts", chúng không thể cùng đúng — hãy quay lại chính tên tính năng trong đề để chọn vế phù hợp.
• Phân biệt hoá đơn với báo cáo chi phí: gộp hoá đơn không có nghĩa là mất khả năng nhìn chi phí của từng account; việc theo dõi chi tiết theo account vẫn còn.

🧩 Phân tích nội dung câu hỏi

Đề hỏi: khi tính Total Cost of Ownership (TCO) để so sánh hạ tầng on-premises với AWS Cloud, những khoản chi phí on-premises nào bắt buộc phải đưa vào phép tính. Chọn HAI phương án.

Cụm từ quyết định là "when comparing against the AWS Cloud" — đây là bài toán so sánh, không phải bài toán liệt kê mọi chi phí IT. Một phép so sánh chỉ có ý nghĩa ở phần chi phí thay đổi khi chuyển sang cloud. Nguyên tắc rút ra từ đó:

Đưa vào TCO những khoản bạn đang trả ở on-premises nhưng sẽ không còn trả (hoặc giảm hẳn) khi lên AWS. Khoản nào vẫn tiếp tục phải trả ở cả hai bên thì để ra ngoài, vì nó xuất hiện ở cả hai cột và triệt tiêu nhau.

Vậy cách phân loại năm phương án không phải là "cái nào tốn tiền" — cả năm đều tốn tiền — mà là "cái nào biến mất khi lên cloud".

✅ Vì sao đáp án đúng là đúng

Đáp án theo tệp: A và C.

C — Physical compute hardware. Đây là khoản kinh điển bị loại bỏ hoàn toàn khi chuyển sang AWS. Ở on-premises bạn phải mua server vật lý, trả tiền trước theo chu kỳ làm mới phần cứng, cộng thêm bảo hành, không gian đặt máy, điện và làm mát. Trên AWS bạn thuê năng lực tính toán theo mức sử dụng và không sở hữu phần cứng nào cả. Chi phí này tồn tại ở cột on-premises và bằng không ở cột AWS, nên bỏ qua nó là làm sai lệch toàn bộ phép so sánh.

A — Network infrastructure in the data center. Cùng một lập luận. Switch, router, cáp, thiết bị mạng trong trung tâm dữ liệu là tài sản bạn phải mua và duy trì ở on-premises. Khi hạ tầng chạy trên AWS, phần mạng trong data center do AWS lo; bạn không còn mua và thay thế thiết bị mạng vật lý nữa. Đây lại là một khoản chỉ có ở một bên.

❌ Vì sao các phương án còn lại sai

B — Database schema development. Thiết kế lược đồ CSDL là công việc gắn với ứng dụng, không gắn với nơi ứng dụng chạy. Dù database nằm trên server trong phòng máy hay trên AWS, vẫn có người phải thiết kế bảng, quan hệ, index. Chi phí này xuất hiện y hệt ở cả hai cột nên không tạo ra khác biệt trong phép so sánh.

D — Project management services. Đây là phương án dễ gây nhầm nhất vì nghe rất "chi phí vận hành IT" và thực tế là có tốn tiền thật. Nhưng quản lý dự án là chi phí nhân sự vẫn tiếp diễn sau khi lên cloud — dự án vẫn cần người điều phối, lập kế hoạch, theo dõi tiến độ. Nó hỏng đúng ở chỗ đó: tốn tiền nhưng không thay đổi khi đổi nền tảng, nên đưa vào chỉ làm cả hai cột cùng phồng lên mà kết luận không đổi.

E — Operating system administration. Cũng là một phương án gần đúng và cũng hỏng theo cùng kiểu với D. Nhiều người nghĩ "lên cloud thì đỡ phải quản trị hệ thống", nhưng với mô hình chạy máy ảo thì việc vá lỗi, cập nhật, cấu hình hệ điều hành vẫn thuộc trách nhiệm của khách hàng — đó chính là ranh giới trong shared responsibility model. Chi phí quản trị OS tiếp tục tồn tại trên AWS, nên nó không phải khoản cần đưa vào TCO khi so sánh.

📌 Điểm cần nhớ

• Câu hỏi TCO trong đề AWS gần như luôn xoay quanh một câu hỏi lọc duy nhất: khoản chi này có biến mất khi lên cloud không? Có → đưa vào. Không → bỏ ra.
• Chi phí phần cứng vật lý (compute, storage, network trong data center) và các khoản đi kèm việc sở hữu phòng máy là nhóm mặc định có đưa vào TCO.
• Chi phí nhân lực và công việc ứng dụng (quản trị OS, quản lý dự án, phát triển, thiết kế schema) là nhóm mặc định không đưa vào, vì chúng tiếp tục tồn tại trên AWS.
• Đừng nhầm "chi phí lớn" với "chi phí liên quan". Một khoản có thể rất tốn kém mà vẫn vô nghĩa trong phép so sánh nếu nó xuất hiện ở cả hai bên.
• Lý do quản trị OS không biến mất chính là shared responsibility model: AWS lo hạ tầng vật lý, khách hàng vẫn lo hệ điều hành và những gì chạy bên trên nó.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một người dùng muốn biết dịch vụ nào bảo vệ khỏi tấn công DDoS (Distributed Denial of Service) nhắm vào các dịch vụ AWS.

Cụm từ quyết định là "protect from DDoS attacks". Đây không phải câu hỏi về "chặn truy cập trái phép" hay "phát hiện hành vi bất thường" — hai khái niệm rất dễ nhầm với DDoS. DDoS là kiểu tấn công làm ngập lụt tài nguyên bằng lưu lượng khổng lồ từ nhiều nguồn, khiến dịch vụ không còn phục vụ được người dùng thật. Vì lưu lượng đến từ vô số IP hợp lệ về mặt kỹ thuật, cách chống không phải là "viết luật chặn IP" mà phải là một dịch vụ chuyên biệt biết nhận diện và hấp thụ lưu lượng tấn công ở quy mô lớn.

Chú ý thêm cụm "directed at AWS services" — câu hỏi ở tầm dịch vụ được quản lý (managed) của AWS, chứ không phải một cấu hình bên trong VPC do bạn tự viết luật.

✅ Vì sao đáp án đúng là đúng

D — AWS Shield là dịch vụ được quản lý chuyên dụng để chống DDoS cho ứng dụng chạy trên AWS. Đây là dịch vụ duy nhất trong danh sách được thiết kế đúng cho mục đích này.

Điểm cần nắm:

• Shield cung cấp phát hiện luôn bật (always-on detection) và giảm thiểu tự động ngay trên đường truyền (automatic inline mitigation) — lưu lượng tấn công bị xử lý trước khi kịp làm sập ứng dụng, giảm thời gian chết và độ trễ.
• Vì cơ chế là tự động, bạn không cần liên hệ AWS Support mới được bảo vệ.
• Shield có hai bậc: Standard và Advanced. Bậc Standard là mức bảo vệ nền tảng, còn Advanced là gói nâng cao dành cho khối lượng công việc cần mức bảo vệ và hỗ trợ sâu hơn.

❌ Vì sao các phương án còn lại sai

A — Network access control list (ACL). Network ACL tồn tại bên trong một VPC, hoạt động như một firewall stateless cho lưu lượng ra vào các subnet. Nó cho phép hay từ chối theo luật bạn viết sẵn (IP, cổng, giao thức). Đây là phương án gần đúng ở chỗ nó có chặn được lưu lượng — nhưng nó hỏng ở chỗ: luật phải do bạn định nghĩa trước, còn tấn công DDoS đến từ hàng loạt nguồn thay đổi liên tục và ở quy mô mà một bộ luật tĩnh trong subnet không thể theo kịp. Nó không phát hiện, không tự thích ứng, không "giảm thiểu".

B — Security group. Security group là firewall stateful, gắn ở mức instance để ngăn truy cập không mong muốn tới các instance trong VPC. Cũng như Network ACL, đây là công cụ kiểm soát truy cập theo luật do bạn khai báo, không phải cơ chế chống DDoS. Điểm hỏng giống hệt: nó trả lời câu hỏi "ai được phép kết nối", chứ không trả lời "làm sao chịu được lượng kết nối hợp lệ về hình thức nhưng khổng lồ về số lượng".

C — Amazon GuardDuty. GuardDuty là dịch vụ phát hiện mối đe doạ thông minh (intelligent threat detection). Đây là phương án dễ nhầm nhất vì nó cũng nằm trong nhóm security và cũng "tự động", nhưng vai trò của nó là phát hiện và cảnh báo về hành vi đáng ngờ, chứ không liên quan tới việc chống DDoS. Phát hiện ≠ giảm thiểu: GuardDuty báo cho bạn biết có chuyện, Shield mới là thứ đứng ra hứng lưu lượng.

📌 Điểm cần nhớ

• DDoS → AWS Shield. Đây là cặp từ khoá nên nhớ máy móc: thấy "DDoS" trong đề thi Cloud Practitioner, gần như chắc chắn đáp án là Shield.
• Phân biệt ba nhóm dịch vụ security hay bị trộn lẫn: kiểm soát truy cập theo luật (Security group, Network ACL), phát hiện mối đe doạ (GuardDuty), và giảm thiểu tấn công (Shield). Mỗi nhóm trả lời một câu hỏi khác nhau.
• Stateful vs stateless: Security group là stateful và gắn ở mức instance; Network ACL là stateless và gắn ở mức subnet. Cả hai đều nằm trong phạm vi VPC.
• Phát hiện không phải là bảo vệ. Một dịch vụ chỉ sinh cảnh báo (như GuardDuty) không bao giờ là câu trả lời cho đề hỏi "protect from" — hãy tìm dịch vụ thực sự can thiệp vào lưu lượng.
• Shield có hai bậc Standard và Advanced; cơ chế bảo vệ là always-on và tự động, không cần mở ticket với AWS Support.

🧩 Phân tích nội dung câu hỏi

Đề hỏi: dịch vụ nào cho phép cấu hình hạn mức chi phí và mức sử dụng tuỳ chỉnh (custom cost and usage limits) và bật cảnh báo khi vượt ngưỡng đã định (alerts when defined thresholds are exceeded).

Cụm từ quyết định là "configure custom … limits" cộng với "enable alerts … thresholds are exceeded". Đây là hai hành động rất cụ thể, và chúng đều mang tính chủ động, hướng tương lai: người dùng tự đặt ra một con số ngưỡng trước, rồi hệ thống theo dõi và báo khi chạm ngưỡng đó.

Đây chính là chỗ phân biệt với các phương án còn lại. Nhiều dịch vụ trong nhóm quản lý chi phí của AWS đều "liên quan tới tiền", nhưng phần lớn chúng chỉ cho xem, phân tích hoặc gộp hoá đơn — tức là nhìn về quá khứ. Chỉ một dịch vụ trong danh sách có khái niệm "ngưỡng do bạn đặt" và "cảnh báo khi vượt".

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C — AWS Budgets.

AWS Budgets được sinh ra đúng cho việc này: bạn tạo một budget để theo dõi cost và usage của mình, tự đặt ngưỡng theo ý muốn. Khi chi phí hoặc mức sử dụng thực tế — hoặc mức dự báo (forecasted) — vượt qua ngưỡng đã đặt, AWS Budgets gửi cảnh báo cho bạn qua email hoặc thông báo SNS.

Ngoài chi phí và mức sử dụng, AWS Budgets còn theo dõi được mức utilization và coverage của Reserved Instances và Savings Plans, và cảnh báo khi các chỉ số đó tụt xuống dưới ngưỡng bạn mong muốn. Nói cách khác, mô hình của nó luôn là: ngưỡng do bạn định + cảnh báo khi vượt qua ngưỡng đó — khớp từng chữ với đề bài.

❌ Vì sao các phương án còn lại sai

A. AWS Trusted Advisor — Đây là dịch vụ đưa ra khuyến nghị theo best practices của AWS (chi phí, hiệu năng, bảo mật, khả năng chịu lỗi, hạn mức dịch vụ). Nó có nhóm kiểm tra về tối ưu chi phí, chẳng hạn chỉ ra tài nguyên đang bị bỏ không — nên nhiều người thấy "có dính tới chi phí" là chọn. Nhưng Trusted Advisor không cho bạn tự đặt một ngưỡng chi tiêu tuỳ chỉnh rồi báo khi vượt. Nó khuyên bạn nên làm gì, chứ không canh con số bạn đưa ra.

B. Consolidated billing — Đây là tính năng gắn với AWS Organizations: gộp hoá đơn của nhiều tài khoản thành viên thành một hoá đơn duy nhất dưới tài khoản quản lý. Nó giải quyết bài toán gom chi phí (và chia sẻ mức giảm giá theo bậc dùng nhiều), chứ hoàn toàn không có khái niệm ngưỡng hay cảnh báo. Đề không hề nhắc tới nhiều tài khoản, nên đây cũng không phải hướng đề đang hỏi.

D. Cost Explorer — Đây là phương án gần đúng nhất và dễ bẫy nhất, vì nó cũng nằm trong AWS Cost Management và cũng làm việc với đúng dữ liệu cost và usage. Chỗ nó hỏng nằm ở động từ trong đề: Cost Explorer dùng để explore — xem biểu đồ, lọc, nhóm theo dịch vụ hay theo tag để hiểu tiền đã đi đâu. Đó là công cụ phân tích và trực quan hoá những gì đã phát sinh trong tài khoản. Nó không phải nơi bạn khai báo một hạn mức tuỳ chỉnh và bật cảnh báo tự động khi vượt — việc đó thuộc về AWS Budgets. Mẹo phân biệt: Cost Explorer trả lời "tôi đã tiêu bao nhiêu, vào đâu?", còn AWS Budgets trả lời "báo cho tôi khi tôi tiêu quá mức này".

📌 Điểm cần nhớ

• Thấy từ khoá budget / threshold / limit / alert / notify trong đề chi phí AWS → nghĩ ngay tới AWS Budgets. Đây là dịch vụ duy nhất trong nhóm cost management có mô hình "ngưỡng do người dùng đặt + cảnh báo khi vượt".
• Phân biệt bằng hướng thời gian: Cost Explorer nhìn về quá khứ (phân tích chi phí đã phát sinh), AWS Budgets nhìn về hiện tại và tương lai (theo dõi ngưỡng, cảnh báo cả trên số forecasted).
• Consolidated billing luôn gắn với AWS Organizations và nhiều tài khoản — đề không nói tới nhiều tài khoản thì gần như chắc chắn không phải nó.
• Trusted Advisor là khuyến nghị best practices trên nhiều mảng (cost, security, performance, fault tolerance, service limits). Nó gợi ý cách tiết kiệm, chứ không giám sát ngưỡng chi tiêu do bạn đặt.

🧩 Phân tích nội dung câu hỏi

Đề bài hỏi: theo AWS shared responsibility model, đâu là ví dụ về trách nhiệm của khách hàng (customer responsibility) khi dùng AWS Cloud.

Cụm từ quyết định đáp án là "customer responsibility". Toàn bộ mô hình shared responsibility được AWS chia làm hai vế, và mọi câu hỏi kiểu này chỉ là bài tập xếp một hạng mục vào đúng vế:

• Security of the cloud — AWS chịu: phần cứng, trung tâm dữ liệu, mạng lưới vật lý, hạ tầng ảo hoá, Regions/Availability Zones/edge locations.
• Security in the cloud — khách hàng chịu: những gì khách hàng cấu hình và điều khiển được — dữ liệu, hệ điều hành khách, IAM, mã hoá, và cấu hình mạng như security group / firewall.

Vậy phép thử để lọc bốn phương án rất gọn: hạng mục này khách hàng có bấm nút chỉnh được trong console/API của mình không? Nếu có, đó là trách nhiệm khách hàng. Nếu nó là thứ AWS xây dựng và vận hành mà khách hàng không bao giờ chạm tới, đó là trách nhiệm AWS.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C — Firewall configuration.

Cấu hình firewall là ví dụ kinh điển của "security in the cloud". AWS cung cấp cơ chế — security group, network ACL — nhưng cách đặt luật là do khách hàng quyết định: mở cổng nào, cho dải IP nào vào, chặn cái gì. AWS không biết ứng dụng của bạn cần mở cổng 443 hay 22, và cũng không tự sửa luật giùm bạn. Nếu ai đó mở SSH ra toàn Internet (0.0.0.0/0) rồi bị xâm nhập, đó là lỗi cấu hình của khách hàng chứ không phải sự cố của AWS.

Đây chính là đặc điểm phân biệt: hạng mục này nằm trong tay khách hàng, được điều chỉnh bởi khách hàng, nên trách nhiệm cũng thuộc về khách hàng.

❌ Vì sao các phương án còn lại sai

A — Global infrastructure. Hạ tầng toàn cầu (Regions, Availability Zones, edge locations, đường mạng xương sống nối chúng) là thứ AWS xây, sở hữu và vận hành. Khách hàng chỉ chọn triển khai vào Region nào, chứ không xây hay bảo vệ hạ tầng đó. Đây là security of the cloud — trách nhiệm AWS.

B — Physical security. An ninh vật lý của trung tâm dữ liệu: kiểm soát ra vào, camera, bảo vệ, huỷ ổ đĩa khi loại bỏ. Khách hàng thậm chí không được phép bước vào data center của AWS. Đây là phần AWS chứng minh qua các chương trình tuân thủ/kiểm toán, không phải việc khách hàng làm. Cũng là security of the cloud.

C — Firewall configuration. Đáp án đúng, đã phân tích ở trên.

D — Managing edge locations. Đây là phương án dễ gây lưỡng lự nhất, vì edge location gắn với dịch vụ mà khách hàng có dùng và có cấu hình. Nhưng cần tách rõ hai việc: cấu hình một distribution chạy trên mạng edge là việc của khách hàng, còn quản lý bản thân các edge location — dựng site, vận hành phần cứng, bảo trì, mở rộng mạng lưới — thuộc về AWS và nằm trong hạ tầng toàn cầu. Đề dùng đúng chữ "managing edge locations", tức là vận hành hạ tầng, nên thuộc vế AWS.

📌 Điểm cần nhớ

• Ghi nhớ hai cụm từ khoá: "security OF the cloud" = AWS, "security IN the cloud" = customer. Chỉ cần một giới từ là phân loại được gần như mọi câu về shared responsibility model.
• Phép thử nhanh: khách hàng có tự chỉnh được hạng mục đó qua console/CLI/API không? Có → trách nhiệm khách hàng (firewall/security group, IAM, mã hoá dữ liệu, vá hệ điều hành khách). Không → trách nhiệm AWS (phần cứng, an ninh vật lý, hạ tầng ảo hoá, hạ tầng toàn cầu).
• Bất cứ phương án nào nói về hạ tầng vật lý hoặc mạng lưới toàn cầu (data center, Region, AZ, edge location) gần như luôn thuộc AWS trong dạng câu hỏi này.
• Cẩn thận với những phương án lập lờ giữa cấu hình dịch vụ và vận hành hạ tầng đỡ dịch vụ đó: cấu hình thuộc khách hàng, còn vận hành hạ tầng thuộc AWS. Đọc kỹ động từ trong phương án (configure so với manage/maintain) để tách hai vế.

🧩 Phân tích nội dung câu hỏi

Đề hỏi: một Amazon EC2 instance chạy Amazon Linux 2 AMI được tính tiền theo đơn vị (increment) nào?

Cụm từ quyết định đáp án ở đây là "Amazon Linux 2 AMI" — tức là instance chạy Linux. AWS tính tiền EC2 theo đơn vị khác nhau tuỳ hệ điều hành của AMI: các instance chạy Linux (và một số hệ điều hành khác) được tính theo giây, với một mức tối thiểu ban đầu, trong khi nhiều AMI thương mại có bản quyền tính theo giờ. Nếu đề chỉ nói chung chung "an EC2 instance" thì câu hỏi mới mơ hồ; việc nêu đích danh Amazon Linux 2 chính là mấu chốt để loại "Per hour".

Cụm thứ hai đáng chú ý là "billed in what increment" — đề hỏi về đơn vị thời gian sử dụng, không hỏi về thứ được đo (dung lượng, số CPU). Đây là chỗ phân biệt giữa hai nhóm phương án: A và C nói về thời gian, B và D nói về tài nguyên.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là C — Per second.

EC2 instance chạy Linux được tính tiền theo từng giây, kèm một mức tối thiểu tính cho lần khởi chạy đầu tiên (khoảng một phút). Nghĩa là nếu bạn chạy instance trong 90 giây rồi tắt, bạn trả tiền cho 90 giây chứ không bị làm tròn lên cả một giờ.

Ý nghĩa thực tế của cách tính này rất lớn với các khối lượng công việc ngắn và co giãn liên tục: batch job, môi trường test dựng lên rồi phá đi, hay auto scaling thêm bớt instance suốt ngày. Với cách tính theo giờ, mỗi lần bật một instance chạy vài phút vẫn phải trả trọn một giờ, nên người dùng có xu hướng giữ máy chạy cho "đỡ phí". Tính theo giây thì việc tắt máy khi không dùng luôn có lợi ngay lập tức — đúng tinh thần pay-as-you-go mà kỳ thi Cloud Practitioner nhấn mạnh.

❌ Vì sao các phương án còn lại sai

A. Per hour — Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì đó đúng là cách EC2 tính tiền trong nhiều năm đầu, và giá EC2 tới giờ vẫn niêm yết dưới dạng "$X/giờ". Chỗ nó hỏng: giá niêm yết theo giờ khác với đơn vị tính tiền (increment). AWS lấy đơn giá theo giờ rồi chia nhỏ ra theo số giây thực tế đã dùng. Đề hỏi "billed in what increment", tức hỏi đơn vị làm tròn khi tính hoá đơn, nên câu trả lời phải là giây. Ngoài ra, với AMI Linux như Amazon Linux 2 thì đơn vị theo giờ không còn áp dụng.

B. Per GB — Đây là đơn vị tính tiền của dung lượng lưu trữ, không phải của compute. Cụ thể, Amazon EBS tính theo số GB dung lượng đã cấp phát mỗi tháng; data transfer cũng tính theo GB. Một instance EC2 gần như luôn đi kèm EBS volume, nên trên hoá đơn bạn sẽ thấy dòng tính theo GB — nhưng đó là dòng của EBS, không phải của bản thân instance. Đề hỏi riêng về instance nên GB không phải câu trả lời.

D. Per CPU — Không có mô hình tính tiền nào của EC2 lấy số CPU làm đơn vị hoá đơn. Số vCPU và dung lượng bộ nhớ là thứ quyết định instance type, và instance type quyết định đơn giá; nhưng thứ được nhân với đơn giá đó là thời gian chạy, chứ không phải số CPU. Nói cách khác, CPU ảnh hưởng tới giá một cách gián tiếp qua việc chọn loại máy, chứ nó không phải increment tính tiền. Chọn D là nhầm giữa "yếu tố ảnh hưởng giá" và "đơn vị tính tiền".

📌 Điểm cần nhớ

• Với câu hỏi về billing của EC2, luôn đọc kỹ hệ điều hành trong đề: AMI Linux như Amazon Linux 2 được tính theo giây (có mức tối thiểu ban đầu), còn một số AMI thương mại có bản quyền vẫn tính theo giờ. Đề nêu tên AMI không phải để trang trí.
• Phân biệt đơn giá niêm yết với đơn vị tính tiền: EC2 báo giá "mỗi giờ" nhưng tính tiền theo giây. Từ khoá "increment" trong đề hỏi cái thứ hai.
• Phân biệt đơn vị của compute và của storage: EC2 instance tính theo thời gian chạy, Amazon EBS tính theo GB dung lượng đã cấp phát. Thấy "per GB" trong câu hỏi về EC2 instance thì gần như chắc chắn đó là bẫy trỏ sang EBS.
• Số vCPU và RAM chỉ quyết định instance type và đơn giá, không bao giờ là đơn vị nhân trên hoá đơn. Đừng chọn phương án kiểu "per CPU" hay "per core".

🧩 Phân tích nội dung câu hỏi

Đề mô tả hai khả năng đi liền nhau: người dùng truy cập được bao nhiêu tài nguyên tuỳ theo nhu cầu ("access to as many resources as they need"), và tăng giảm quy mô nhanh chóng ("scale up and down quickly"). Câu hỏi yêu cầu gọi tên lợi ích (benefit) của AWS Cloud tương ứng.

Cụm từ quyết định là "scale up and down quickly" — chú ý là up and down, tức lấy thêm tài nguyên khi cần và trả lại khi không cần nữa, và làm việc đó nhanh. Đây chính là định nghĩa của elasticity. Nếu đề chỉ nói "tiết kiệm chi phí" thì mới là một lợi ích khác; ở đây trọng tâm hoàn toàn nằm ở khả năng co giãn tài nguyên theo nhu cầu, không phải cách trả tiền, không phải độ ổn định của hệ thống.

✅ Vì sao đáp án đúng là đúng

A – Elasticity là khả năng lấy tài nguyên khi cần và giải phóng tài nguyên khi không còn cần đến nữa. Diễn đạt này khớp từng vế với đề bài: "as many resources as they need" ứng với việc cấp thêm, còn "scale up and down" ứng với cả chiều cấp thêm lẫn chiều thu về. Trong mô hình cloud, người dùng không phải mua sẵn phần cứng cho mức tải đỉnh rồi để không lúc tải thấp — tài nguyên được cấp phát và thu hồi theo nhu cầu thực tế. Đó là thứ mà thuật ngữ elasticity mô tả, và cũng là lợi ích được liệt kê trong tài liệu về lợi thế của điện toán đám mây của AWS.

❌ Vì sao các phương án còn lại sai

B – Pay-as-you-go pricing: đây là phương án gần đúng nhất và dễ gây nhầm, vì trong thực tế elasticity và pay-as-you-go thường đi kèm nhau (co giãn xuống thì hoá đơn giảm theo). Nhưng pay-as-you-go nói về mô hình chi trả — chuyển từ chi phí đầu tư trả trước (CAPEX) sang chi phí vận hành theo mức dùng (OPEX). Nó trả lời câu hỏi "trả tiền thế nào", không trả lời câu hỏi "có lấy thêm hay trả lại tài nguyên được không, nhanh đến đâu". Đề bài không hề nhắc tới chi phí hay hoá đơn, nên phương án này hỏng ở chỗ lệch chủ đề.

C – Reliability: reliability là khả năng một workload thực hiện đúng chức năng của nó một cách chính xác và nhất quán vào thời điểm được kỳ vọng. Nó nói về việc hệ thống hoạt động đúng và không hỏng, liên quan tới khôi phục sau lỗi và chịu đựng sự cố. Một hệ thống hoàn toàn có thể rất reliable mà lại chạy trên hạ tầng cứng nhắc, không co giãn được. Đề bài không nhắc gì tới lỗi, gián đoạn hay tính nhất quán của dịch vụ.

D – Economy of scale: đây là lợi ích về giá thành nhờ quy mô — vì AWS có lượng khách hàng rất lớn nên chi phí hạ tầng được phân bổ ra, và mỗi người dùng cá lẻ trả ít hơn so với tự dựng hạ tầng riêng. Cũng như B, nó là chuyện tiền bạc chứ không phải chuyện khả năng co giãn kỹ thuật. Ngoài ra economy of scale là lợi ích đến từ phía nhà cung cấp và người dùng hưởng thụ động, còn elasticity là thứ người dùng chủ động thao tác.

📌 Điểm cần nhớ

• Elasticity = lấy thêm khi cần + trả lại khi không cần, và làm nhanh. Thấy cụm "scale up and down", "acquire and release resources", "match demand" trong đề thì nghĩ ngay tới elasticity.
• Phân biệt rõ nhóm lợi ích kỹ thuật (elasticity, agility, reliability, global reach) với nhóm lợi ích tài chính (pay-as-you-go, economy of scale). Đề hỏi về khả năng co giãn thì loại thẳng nhóm tài chính, dù chúng có hệ quả về chi phí.
• Pay-as-you-go là câu chuyện CAPEX → OPEX; economy of scale là giá rẻ nhờ AWS gộp nhu cầu của rất nhiều khách hàng. Hai khái niệm này hay bị dùng lẫn lộn trong đề Cloud Practitioner.
• Reliability thuộc về "chạy đúng và ổn định", không phải "chạy được ở mọi quy mô". Đừng chọn reliability chỉ vì đề nghe có vẻ nói về một hệ thống tốt.