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

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

Đề mô tả một tổ chức đang di chuyển hệ thống lên AWS Cloud và nêu hai nhu cầu tách bạch:

1. Trong quá trình migration, cần consulting và guidance cho các ứng dụng.
2. Sau khi migration xong, cần phản hồi trong vòng 30 phút khi hệ thống business-critical bị hỏng.

Cụm từ quyết định đáp án là "a response within 30 minutes in the event of a business-critical system failure". Đây là ràng buộc duy nhất phân biệt được các AWS Support plan gần giống nhau, bởi vì cả bốn plan có tính phí đều cho mở case kỹ thuật — khác nhau ở mức độ nghiêm trọng (severity) cao nhất mà plan đó chấp nhận và thời gian phản hồi cam kết cho mức đó.

Chú ý chữ "within 30 minutes" — đây là trần trên chứ không phải con số phải khớp chính xác. Plan nào phản hồi nhanh hơn hoặc bằng 30 phút đều thoả. Đó là lý do câu hỏi có hai đáp án đúng chứ không phải một.

Vế "consulting và guidance" là điều kiện phụ, hai plan cao cấp đều đáp ứng, nên nó không phải chỗ để loại phương án.

✅ Vì sao đáp án đúng là đúng — C và D

C. AWS Enterprise Support — đây là plan cao nhất, cam kết thời gian phản hồi cho case business-critical system down ở mức nhanh nhất trong tất cả các plan, dưới 15 phút. Nhanh hơn mốc 30 phút đề yêu cầu, nên thoả. Plan này cũng đi kèm mức tư vấn kiến trúc và hướng dẫn sâu nhất, đáp ứng luôn vế consulting/guidance.

D. AWS Enterprise On-Ramp Support — plan này sinh ra cho đúng nhóm khách hàng như trong đề: đang chuyển lên cloud, cần hỗ trợ cấp doanh nghiệp nhưng chưa cần tới toàn bộ Enterprise Support. Nó cho mở case ở mức business-critical system down với cam kết phản hồi dưới 30 phút — đúng bằng mốc đề nêu, nên thoả.

Điểm chung khiến hai plan này đúng và ba plan kia sai: chỉ Enterprise On-Ramp và Enterprise mới hỗ trợ mức severity "business-critical system down". Các plan thấp hơn không có mức severity đó, nên không có cam kết phản hồi nào để so với con số 30 phút cả.

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

A. AWS Business Support — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Business Support có hỗ trợ kỹ thuật 24/7, có hướng dẫn kiến trúc ở mức chung, nên vế "consulting và guidance" thoạt nhìn có vẻ đạt. Nó hỏng ở đúng vế thứ hai: mức severity cao nhất mà Business Support chấp nhận là production system down, với cam kết phản hồi dưới 1 giờ — không có mức business-critical system down. Một giờ vượt xa mốc 30 phút, và quan trọng hơn là loại case mà đề mô tả còn không mở được trên plan này.

B. AWS Basic Support — plan miễn phí đi kèm mọi tài khoản AWS. Nó không cho mở case hỗ trợ kỹ thuật; thứ duy nhất mở case được là các vấn đề về billing và account. Ngoài ra chỉ có tài liệu, whitepaper, diễn đàn cộng đồng và một phần AWS Trusted Advisor. Không có cam kết phản hồi kỹ thuật nào, cũng không có consulting — trượt cả hai yêu cầu của đề.

E. AWS Developer Support — thiết kế cho môi trường thử nghiệm và phát triển, không phải production. Mức severity cao nhất là system impaired, với cam kết phản hồi trong khoảng thời gian tính bằng giờ (dưới 12 giờ), lại chỉ trong giờ làm việc chứ không phải 24/7. Không có cam kết nào cho hệ thống business-critical bị down. Cách xa mốc 30 phút.

📌 Điểm cần nhớ

• Bốn plan tính phí xếp theo thứ tự tăng dần: Developer → Business → Enterprise On-Ramp → Enterprise. Nhớ đúng thứ tự này là giải được phần lớn câu hỏi về AWS Support.
• Phân biệt các plan bằng mức severity cao nhất được phép mở case, chứ đừng học thuộc riêng con số phút/giờ: chỉ Enterprise On-Ramp và Enterprise mới có mức business-critical system down; Business dừng ở production system down; Developer dừng ở system impaired.
• Đề hỏi "within X" là hỏi trần trên — mọi plan nhanh hơn hoặc bằng X đều đúng. Đây là lý do dạng câu này thường có hai đáp án: một plan khớp đúng mốc và một plan cao hơn nó.
• AWS Basic Support chỉ mở case được cho billing/account, không hỗ trợ kỹ thuật. Thấy Basic trong danh sách mà đề đòi hỗ trợ kỹ thuật thì loại ngay.
• Enterprise On-Ramp là đáp án hay bị bỏ sót vì ra đời sau ba plan kia; nó nhắm đúng vào tình huống "đang migrate lên cloud, cần hỗ trợ mạnh nhưng chưa cần Enterprise đầy đủ".

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

Đề hỏi: "Which service can be used to manage configuration versions?" — dịch vụ nào dùng để quản lý các phiên bản cấu hình.

Cụm từ quyết định đáp án là "configuration versions". Đây không phải câu hỏi về bảo mật chung chung, cũng không phải về triển khai hay tuân thủ pháp lý. Nó hỏi rất hẹp: dịch vụ nào ghi lại cấu hình của tài nguyên AWS theo thời gian, để bạn biết một resource hôm nay đang được cấu hình ra sao và trước đây nó từng ra sao.

Bốn phương án đều thuộc nhóm Management & Governance / Security nên nghe qua đều "liên quan tới cấu hình" theo một nghĩa nào đó. Cách phân biệt là hỏi lại: dịch vụ nào lưu lịch sử thay đổi (history) của cấu hình? Chỉ có một dịch vụ làm đúng việc đó.

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

Đáp án đúng theo tệp là A — AWS Config.

AWS Config là dịch vụ được quản lý hoàn toàn, cung cấp ba thứ:

• Resource inventory — danh mục tài nguyên AWS bạn đang có;
• Configuration history — lịch sử cấu hình của từng tài nguyên, tức là chính "configuration versions" mà đề nhắc tới;
• Configuration change notifications — thông báo khi cấu hình bị thay đổi.

Nhờ vậy AWS Config trả lời được câu hỏi kiểu "security group này được mở port ra Internet từ lúc nào, ai đổi, trước đó nó thế nào" — đúng nghĩa quản lý phiên bản cấu hình, và cũng là nền tảng để phục vụ mục tiêu security và regulatory compliance.

Từ khoá cần ghim: Config → configuration history. Chỉ cần thấy "configuration history / configuration change / configuration versions" trong đề là nghĩ ngay tới AWS Config.

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

B — AWS Artifact. Đây là kho tài liệu tuân thủ tập trung: nơi bạn tải các báo cáo, chứng nhận và attestation của AWS (loại tài liệu bạn đưa cho auditor). Nó có "phiên bản tài liệu", và chữ compliance khiến nó nghe gần với Config — nhưng Artifact nói về giấy tờ tuân thủ của bản thân AWS, không hề chạm tới cấu hình tài nguyên trong tài khoản của bạn. Không có inventory, không có lịch sử thay đổi resource.

C — AWS Service Catalog. Đây là phương án gây nhầm nhiều nhất, vì Service Catalog thực sự có khái niệm sản phẩm và phiên bản. Nhưng nó dùng để tạo và quản lý catalog các dịch vụ CNTT đã được phê duyệt cho người dùng trong tổ chức — virtual machine images, servers, phần mềm, database, cho tới cả kiến trúc ứng dụng nhiều tầng. Trọng tâm là cho phép triển khai cái gì, tức kiểm soát ở đầu vào trước khi tài nguyên được tạo. Nó không ghi lại việc một tài nguyên đang chạy bị đổi cấu hình sau đó — mà đó mới là điều đề hỏi.

D — Amazon Inspector. Là dịch vụ đánh giá bảo mật tự động, quét ứng dụng đã triển khai trên AWS để tìm lỗ hổng và vấn đề an ninh, giúp cải thiện security và compliance. Nó cho ra phát hiện bảo mật (findings), không phải lịch sử cấu hình. Điểm chung duy nhất với đáp án đúng là chữ "compliance", và chỉ dựa vào chữ đó mà chọn là rơi đúng bẫy của câu hỏi.

📌 Điểm cần nhớ

• AWS Config = configuration history. Đề nhắc tới inventory tài nguyên, lịch sử cấu hình, hay thông báo khi cấu hình đổi → chọn AWS Config.
• Phân biệt theo thời điểm tác động: Service Catalog kiểm soát trước khi tạo tài nguyên (được phép dựng cái gì), AWS Config theo dõi sau khi tài nguyên đã tồn tại (nó đã thay đổi thế nào).
• AWS Artifact là kho tài liệu, không phải công cụ giám sát. Nó cung cấp chứng nhận/attestation của AWS cho mục đích audit, không đụng tới tài nguyên trong tài khoản bạn.
• Amazon Inspector tìm lỗ hổng bảo mật, không lưu phiên bản cấu hình. Chữ "compliance" xuất hiện ở nhiều dịch vụ AWS nên không đủ để chọn đáp án — phải bám vào động từ chính của đề (ở đây là manage configuration versions).

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

Đề hỏi: những khoản nào cần đưa vào một bản phân tích TCO (total cost of ownership)? — chọn HAI.

Cụm từ quyết định nằm ở chính chữ TCO. Trong bối cảnh AWS, một bản TCO analysis không phải là "liệt kê mọi chi phí công ty đang chi", mà là công cụ so sánh chi phí vận hành IT tại on-premises hôm nay với chi phí vận hành cùng khối lượng công việc đó trên cloud. Từ đó suy ra tiêu chí lọc duy nhất, và cũng là mẹo làm câu này:

Khoản chi đó có thay đổi (mất đi hoặc giảm) khi chuyển lên cloud không?

• Có thay đổi → thuộc về TCO, vì nó chính là phần chênh lệch cần đo.
• Vẫn phải trả y nguyên dù ở on-premises hay trên cloud → không đưa vào, vì cộng vào cả hai vế thì phép so sánh không đổi mà chỉ thêm nhiễu.

Bốn trên năm phương án đều là "chi phí công ty thật sự phải trả", nên nếu đọc đề là "chi phí nào có thật" thì phương án nào cũng đúng. Ràng buộc phân biệt là chữ ownership — chi phí sở hữu và vận hành hạ tầng, tức là những khoản gắn với việc tự nuôi một data center.

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

Theo tệp, đáp án là D — Facility equipment installation và E — Data center security costs.

• D. Facility equipment installation — chi phí lắp đặt thiết bị trong cơ sở hạ tầng: đưa rack vào phòng máy, đi dây, lắp nguồn, lắp hệ thống làm mát và các thiết bị phụ trợ. Đây là khoản chi tồn tại chỉ vì bạn tự sở hữu phần cứng. Chuyển sang cloud, phần cứng thuộc về AWS, khoản này biến mất khỏi bảng chi của bạn — đúng là thứ TCO analysis sinh ra để lượng hóa.
• E. Data center security costs — chi phí bảo vệ vật lý data center: kiểm soát ra vào, camera, nhân sự trực, các biện pháp an ninh cho tòa nhà. Cũng vậy: đây là gánh nặng của việc tự vận hành cơ sở, và theo mô hình shared responsibility, an ninh vật lý của hạ tầng là phần AWS chịu trách nhiệm. Khoản này rời khỏi bảng chi của bạn khi lên cloud.

Cả hai đều là chi phí hạ tầng vật lý — đúng loại chi phí mà một so sánh on-premises ↔ cloud phải đặt lên bàn cân.

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

• A. Application development — đây là phương án gây phân vân nhất, vì phát triển ứng dụng rõ ràng tốn tiền thật và nằm trong ngân sách IT. Chỗ nó hỏng: ứng dụng vẫn phải được phát triển và bảo trì sau khi đã chuyển lên cloud. Khoản chi này xuất hiện ở cả hai vế của phép so sánh nên triệt tiêu lẫn nhau, không phản ánh lợi ích hay thiệt hại của việc di chuyển. Nó là chi phí làm phần mềm, không phải chi phí sở hữu hạ tầng.
• B. IT Manager salary — cùng một kiểu bẫy, ở mức tinh hơn: lương thuộc chi phí nhân sự IT, dễ nghĩ là "chi phí vận hành IT nên phải tính". Nhưng người quản lý IT vẫn tiếp tục làm việc và vẫn nhận lương khi hệ thống chạy trên cloud — vai trò đổi nội dung công việc chứ khoản chi không mất đi. Không tạo ra chênh lệch thì không đưa vào bản so sánh.
• C. Company wide marketing — phương án dễ loại nhất: marketing toàn công ty không liên quan gì đến hạ tầng IT, không hề bị ảnh hưởng bởi quyết định chuyển lên cloud. Nó không thuộc phạm vi TCO của IT theo bất kỳ cách đọc nào.

📌 Điểm cần nhớ

• TCO là một phép so sánh, không phải một bảng liệt kê chi phí. Với mỗi phương án, hãy tự hỏi: khoản này có khác đi khi chuyển lên cloud không? Không khác → loại.
• Chi phí gắn với cơ sở vật chất luôn là ứng viên đúng: lắp đặt thiết bị, điện, làm mát, không gian phòng máy, an ninh vật lý, bảo trì phần cứng. Đó chính là phần AWS gánh thay bạn.
• Chi phí nhân sự và chi phí làm phần mềm thường là bẫy: lương nhân viên IT, phát triển ứng dụng — chúng còn nguyên sau khi di chuyển, nên không thuộc phép so sánh.
• Chi phí ngoài phạm vi IT (marketing, bán hàng, hành chính) không bao giờ nằm trong TCO của một dự án chuyển đổi hạ tầng. Gặp phương án kiểu này thì loại ngay để rút gọn danh sách.

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

Đề hỏi: dịch vụ AWS nào giúp liên tục audit (continuously audit) việc sử dụng AWS để đơn giản hoá việc đánh giá rủi ro và mức độ tuân thủ (assess risk and compliance) với các quy định pháp lý và tiêu chuẩn ngành?

Cụm từ quyết định là "continuously audit your AWS usage" đi kèm "assess risk and compliance with regulations and industry standards". Đây là mô tả gần như nguyên văn định vị của AWS Audit Manager. Cả bốn phương án đều là dịch vụ có dính tới "kiểm tra"/"tuân thủ" theo nghĩa nào đó, nên phải phân biệt bằng mục tiêu cuối cùng của việc kiểm tra:

• Kiểm tra để khuyến nghị tối ưu → Trusted Advisor
• Kiểm tra để theo dõi cấu hình tài nguyên và thay đổi → Config
• Tải sẵn báo cáo tuân thủ do AWS phát hành → Artifact
• Thu thập bằng chứng liên tục, dựng theo khung tiêu chuẩn để phục vụ cuộc audit → Audit Manager

Chữ khoá phân biệt mạnh nhất là "regulations and industry standards": đề đang nói tới việc chứng minh tuân thủ theo một khung tiêu chuẩn cụ thể, chứ không phải xem tài nguyên của mình đang cấu hình ra sao.

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

D — AWS Audit Manager.

Audit Manager sinh ra đúng cho bài toán này: nó liên tục audit việc sử dụng AWS của bạn để đơn giản hoá việc đánh giá rủi ro và tuân thủ với các quy định và tiêu chuẩn ngành. Điểm cốt lõi là nó tự động thu thập bằng chứng (evidence collection) từ hoạt động thực tế trong tài khoản AWS và ánh xạ bằng chứng đó vào các khung tiêu chuẩn (frameworks) dựng sẵn, thay vì để bạn phải tự đi gom log, chụp màn hình và tổng hợp thủ công mỗi kỳ audit.

Nói cách khác, ba phương án còn lại cho bạn dữ liệu hoặc tài liệu; Audit Manager cho bạn quy trình audit đã được tự động hoá, biến dữ liệu vận hành thành bằng chứng có tổ chức để nộp cho kiểm toán viên. Đó chính là "simplify how you assess risk and compliance" mà đề nhắc tới.

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

A — AWS Trusted Advisor. Sai vì Trusted Advisor đưa ra khuyến nghị thực hành tốt theo hướng dẫn kiến trúc của AWS: tiết kiệm chi phí, hiệu năng, khả năng chịu lỗi, hạn mức dịch vụ và một số hạng mục bảo mật. Nó có "kiểm tra" thật, nhưng đầu ra là lời khuyên cải thiện hệ thống, không phải bằng chứng tuân thủ theo một quy định hay tiêu chuẩn ngành nào. Nó không có khái niệm khung tiêu chuẩn để ánh xạ bằng chứng vào.

B — AWS Config. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Config có đánh giá và audit cấu hình tài nguyên AWS, có rule để kiểm tra tài nguyên có tuân thủ quy tắc bạn đặt ra hay không. Nhưng trọng tâm của Config là kiểm kê tài nguyên (resource inventory) và quản lý thay đổi (change management) — trả lời câu hỏi "tài nguyên này hiện cấu hình thế nào, trước đó ra sao, ai đổi lúc nào". Nó dừng ở mức trạng thái kỹ thuật của tài nguyên, không tự dựng hồ sơ audit theo khung quy định để phục vụ đánh giá rủi ro và tuân thủ. Config là nguồn dữ liệu tốt cho việc audit, còn Audit Manager mới là thứ tổ chức việc audit.

C — AWS Artifact. Cũng dễ nhầm vì tên gắn liền với compliance. Nhưng Artifact là kho truy cập theo yêu cầu các báo cáo bảo mật và tuân thủ của chính AWS (loại tài liệu chứng minh hạ tầng AWS đạt chuẩn) cùng một số thoả thuận trực tuyến. Nó nói về tuân thủ ở phía AWS, tải về tài liệu tĩnh — hoàn toàn không phải cơ chế liên tục audit việc sử dụng AWS của bạn. Chữ "continuously audit your AWS usage" trong đề loại thẳng Artifact.

📌 Điểm cần nhớ

• "Continuously audit… assess risk and compliance with regulations and industry standards" → phản xạ chọn AWS Audit Manager. Dấu hiệu phụ mạnh không kém: automated evidence collection và frameworks.
• Phân biệt cặp hay bị lẫn: Config = trạng thái + lịch sử thay đổi của tài nguyên; Audit Manager = bằng chứng + hồ sơ cho cuộc audit theo khung tiêu chuẩn.
• Artifact = tải báo cáo tuân thủ của AWS (tài liệu tĩnh, theo yêu cầu), không phải audit hoạt động của bạn. Thấy "on-demand access to compliance reports/agreements" mới chọn Artifact.
• Trusted Advisor = khuyến nghị best practice (chi phí, hiệu năng, khả năng chịu lỗi, hạn mức, bảo mật cơ bản), không sinh ra bằng chứng tuân thủ.
• Mẹo chung cho nhóm câu này: đọc đầu ra mà đề mong muốn — lời khuyên, ảnh chụp cấu hình, tài liệu có sẵn, hay bằng chứng cho kiểm toán viên — rồi khớp với dịch vụ.

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

Đề hỏi: phát biểu nào đúng về AWS Shared Responsibility Model — mô hình chia trách nhiệm bảo mật giữa AWS và khách hàng.

Cụm từ quyết định nằm ngay trong chính mô hình mà đề nhắc tới, và nó gói gọn trong hai giới từ:

• "Security of the Cloud" — thuộc về AWS: hạ tầng vật lý và nền tảng chạy dịch vụ, gồm phần cứng, phần mềm nền, mạng, cùng các cơ sở vật chất — tức là regions, availability zones và edge locations.
• "Security in the Cloud" — thuộc về khách hàng: những gì khách hàng đặt lên trên hạ tầng đó — dữ liệu, cấu hình, quyền truy cập, và cả việc vá hệ điều hành của instance mình tự quản.

Mỗi phương án trong câu này đều là một cặp "chủ thể + hạng mục". Chỉ cần soi từng cặp xem hạng mục đó nằm ở tầng hạ tầng hay tầng khách hàng là phân biệt được ngay. Đây là kiểu câu kiểm tra đúng một điều: bạn có phân biệt được "of" với "in" hay không.

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

A. AWS are responsible for the security of regions and availability zones.

Regions và availability zones là hạ tầng toàn cầu của AWS — trung tâm dữ liệu, nguồn điện, làm mát, an ninh vật lý, mạng lõi kết nối giữa các AZ. Khách hàng chọn được region và AZ để triển khai, nhưng không có quyền truy cập vật lý và không vận hành thứ gì bên trong đó. Toàn bộ phần này rơi vào "Security of the Cloud", tức trách nhiệm của AWS. Đây chính là điều mô hình mô tả, nên A là phát biểu đúng.

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

B. AWS are responsible for encrypting customer data.

Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì AWS có cung cấp công cụ mã hoá (khoá KMS, tuỳ chọn encryption trên nhiều dịch vụ lưu trữ). Nhưng "cung cấp công cụ" khác với "chịu trách nhiệm". Việc bật mã hoá, chọn dùng khoá nào, quản lý vòng đời khoá và quyết định dữ liệu nào cần mã hoá là do khách hàng làm. Dữ liệu khách hàng luôn thuộc về khách hàng — đây là hạng mục nằm rõ ràng nhất trong "Security in the Cloud". AWS sẽ không tự mã hoá dữ liệu giúp bạn.

C. Customers are responsible for security of the cloud.

Phương án này đảo ngược đúng một giới từ. "Security of the cloud" là phần của AWS; phần của khách hàng là "security in the cloud". Câu chữ nghe rất giống bản gốc nên dễ gật đầu cho qua nếu đọc lướt — đây chính là lý do phải để ý giới từ chứ không chỉ để ý danh từ "security" và "cloud".

D. Customers are responsible for patching storage systems.

Sai ở chỗ "storage systems" ở đây là hệ thống lưu trữ nền của AWS — phần cứng và phần mềm hạ tầng chạy các dịch vụ lưu trữ. Khách hàng không hề chạm tới lớp đó, nên không thể vá nó; AWS vá và bảo trì. Chỗ dễ nhầm: khách hàng có trách nhiệm vá hệ điều hành của chính instance mình quản lý. Nhưng vá OS của mình khác hẳn với vá hạ tầng lưu trữ bên dưới dịch vụ — đề nói về vế thứ hai.

📌 Điểm cần nhớ

• "Of" là AWS, "in" là khách hàng. Security of the Cloud = hạ tầng (regions, AZ, edge locations, phần cứng, mạng lõi, cơ sở vật chất). Security in the Cloud = dữ liệu, cấu hình, quyền truy cập, OS do khách hàng tự quản.
• Dữ liệu khách hàng luôn thuộc khách hàng. AWS đưa công cụ mã hoá, nhưng bật nó lên và quản lý khoá là việc của bạn — mọi phương án nói "AWS chịu trách nhiệm với dữ liệu khách hàng" đều sai.
• Phân biệt hai loại "patching". Vá OS trên instance mình tự quản → khách hàng. Vá hạ tầng nền (máy chủ vật lý, hệ thống lưu trữ, phần mềm nền của dịch vụ) → AWS.
• Đọc kỹ giới từ và chủ thể trong từng phương án. Câu về Shared Responsibility Model thường chỉ đảo một chữ so với phát biểu gốc; bẫy nằm ở "of/in" hoặc ở việc hoán đổi "AWS ↔ Customers", chứ không nằm ở kiến thức kỹ thuật sâu.

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

Đề nêu một tình huống rất ngắn: công ty muốn đẩy VPC flow logs vào Amazon S3, và hỏi hành động nào thuộc trách nhiệm của công ty (customer) theo Shared Responsibility Model.

Cụm từ quyết định đáp án là "the company is responsible for" đặt cạnh "under the Shared Responsibility Model". Nghĩa là đề không hỏi "việc gì cần làm để đẩy log", mà hỏi "trong danh sách này, việc nào rơi về phía khách hàng chứ không phải AWS".

Chi tiết thứ hai cũng quan trọng: dịch vụ đích là S3 — một managed service. Với S3, ranh giới trách nhiệm nằm ở mức dữ liệu và cấu hình, không phải ở mức hạ tầng hay hệ điều hành. Ai nắm chắc điều này thì ba phương án sai tự rụng.

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

C. Managing the encryption options on the S3 bucket.

Theo mô hình chia sẻ trách nhiệm, khách hàng chịu trách nhiệm về security in the cloud — tức là dữ liệu họ đưa lên và cách họ bảo vệ dữ liệu đó. Cụ thể với một S3 bucket, phần thuộc về khách hàng gồm bucket policy, quyền truy cập (permissions/IAM), và tuỳ chọn mã hoá cho dữ liệu nằm trong bucket.

VPC flow logs khi đã ghi vào S3 thì trở thành dữ liệu của khách hàng. AWS cung cấp sẵn các cơ chế mã hoá phía server cho S3, nhưng việc chọn dùng cơ chế nào và bật nó lên là quyết định cấu hình của khách hàng. Đây chính là hành động duy nhất trong bốn phương án nằm ở phía "in the cloud".

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

A. Managing the data in transit. — Đây là phương án gần đúng nhất và là bẫy chính. Trong nhiều ngữ cảnh khác, bảo vệ dữ liệu trên đường truyền đúng là việc của khách hàng. Nhưng ở đây luồng dữ liệu là VPC flow logs đi tới S3, tức là đi trong hạ tầng mạng nội bộ của AWS (AWS backbone), chứ không phải một kết nối do khách hàng tự thiết lập. Đoạn truyền đó đã được AWS xử lý và mã hoá, khách hàng không có chỗ nào để can thiệp hay cấu hình. Không cấu hình được thì không thể là trách nhiệm.

B. Managing the operating system updates on the S3 bucket. — Sai ở hai tầng. Thứ nhất, S3 là managed object storage, khách hàng không hề được tiếp xúc với hệ điều hành bên dưới; bạn chỉ làm việc qua console, CLI hoặc API. Thứ hai, cách diễn đạt "operating system on the S3 bucket" tự nó đã vô nghĩa — bucket là một namespace lưu trữ, không phải một máy chủ. Vá hệ điều hành là trách nhiệm khách hàng ở mô hình EC2 (IaaS), không phải ở S3.

D. Managing the infrastructure that runs the S3 bucket. — Đây đúng là mô tả của security of the cloud, tức phần AWS chịu trách nhiệm: phần cứng, phần mềm nền, mạng, và các cơ sở dữ liệu vật lý. Khách hàng không nhìn thấy cũng không tác động được vào lớp này. Phương án này chọn nhầm phía của ranh giới.

📌 Điểm cần nhớ

• Ranh giới cốt lõi: AWS lo security of the cloud (hạ tầng vật lý, phần cứng, mạng nền), khách hàng lo security in the cloud (dữ liệu, cấu hình, quyền truy cập, mã hoá).
• Với các managed service như S3, trách nhiệm của khách hàng dừng ở mức cấu hình và dữ liệu — mọi phương án nhắc tới OS, patching hay hạ tầng vật lý đều thuộc AWS.
• Một mẹo loại trừ nhanh: nếu khách hàng không có nút nào để bấm, không có API nào để gọi thì việc đó không thể là trách nhiệm của khách hàng.
• "Data in transit" không phải lúc nào cũng là việc của khách hàng — phải xem đoạn truyền đó chạy trong hạ tầng AWS hay do khách hàng tự dựng.

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

Đề hỏi: dịch vụ nào có thể thêm vào một database để cải thiện hiệu năng cho một số request?

Cụm từ quyết định nằm ở hai chỗ:

• "can be added to a database" — dịch vụ này không phải là database, mà là thứ đặt phía trước một database đã có. Nó bổ sung cho database chứ không thay thế.
• "for some requests" — chỉ một phần request nhanh lên, chứ không phải toàn bộ. Đây chính là dấu hiệu của cache: chỉ những request đọc dữ liệu đã nằm sẵn trong cache mới được phục vụ nhanh; request đọc dữ liệu chưa có trong cache, và mọi request ghi, vẫn phải xuống database gốc.

Ghép hai ràng buộc lại, đề đang mô tả một lớp caching đặt trước database — không phải một database khác, không phải một hệ thống lưu trữ file.

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

B — Amazon ElastiCache.

ElastiCache là dịch vụ caching in-memory do AWS quản lý. Kiến trúc điển hình là đặt ElastiCache đứng trước database (ví dụ RDS): ứng dụng hỏi ElastiCache trước, nếu dữ liệu có sẵn trong bộ nhớ (cache hit) thì trả về ngay mà không cần chạm tới database; nếu không có (cache miss) thì mới truy vấn database rồi nạp kết quả vào cache cho lần sau.

Điều này khớp chính xác với hai cụm từ trong đề:

• Nó được "added to" database — database gốc vẫn còn nguyên đó, ElastiCache chỉ là một lớp bổ sung phía trước.
• Nó cải thiện "some requests" — cụ thể là các read request trúng cache. Đọc từ bộ nhớ (RAM) nhanh hơn nhiều so với đọc qua truy vấn database thông thường, nhưng phần request còn lại vẫn đi đường cũ.

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

A — Amazon EFS. EFS là Elastic File System, một hệ thống file dùng chung có thể mount vào nhiều instance. Nó thuộc nhóm lưu trữ (storage), hoàn toàn không phải dịch vụ caching, và không phải thứ bạn đặt trước một database để tăng tốc truy vấn. Sai ngay ở bản chất dịch vụ.

C — Amazon RDS. Đây là phương án dễ nhầm nhất vì nó có liên quan trực tiếp tới database. Nhưng RDS chính là database kiểu quan hệ (SQL), không phải thứ "thêm vào phía trước một database khác" để tăng tốc. Quan hệ đúng là ngược lại: RDS đóng vai back-end database, còn ElastiCache mới là lớp đặt trước RDS để cải thiện hiệu năng nhờ in-memory caching. Chỗ hỏng của phương án này là vai trò trong kiến trúc, không phải là nó "vô can" với database.

D — Amazon RedShift. Cũng là một phương án nghe hợp lý vì RedShift nổi tiếng nhanh với truy vấn lớn. Nhưng RedShift là một data warehouse dùng để chạy analytics trên dữ liệu — bản thân nó là nơi lưu trữ và phân tích dữ liệu, không phải lớp cache gắn thêm vào một database đang chạy. Chọn nó là hiểu "cải thiện hiệu năng" thành "chuyển sang một hệ thống phân tích khác", trong khi đề yêu cầu thêm vào chứ không phải thay bằng.

📌 Điểm cần nhớ

• Cụm "added to a database" / "in front of the database" trong đề bài gần như luôn trỏ tới ElastiCache — dịch vụ caching in-memory, không phải một database mới.
• Cụm "some requests" hoặc "read-heavy" là dấu hiệu của cache: chỉ read trúng cache mới nhanh, write và cache miss vẫn xuống database gốc.
• Phân biệt vai trò trong kiến trúc: RDS là database quan hệ (back-end), RedShift là data warehouse cho analytics, EFS là file system dùng chung, ElastiCache là lớp cache. Cùng nhóm "lưu trữ/dữ liệu" nhưng giải quyết bài toán khác nhau.
• Khi hai phương án đều "nhanh", hãy hỏi: đề muốn bổ sung vào hệ thống hiện có hay thay thế nó? Từ khoá "added to" loại ngay mọi phương án đòi đổi cả database.

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

Đề hỏi: "Which of the following can be assigned to an IAM user? (Select TWO.)" — thứ gì có thể gán cho một IAM user.

Cụm từ quyết định đáp án là "assigned to an IAM user". Đây không phải câu hỏi "AWS có những cơ chế xác thực nào", mà hẹp hơn nhiều: thứ đó phải là thông tin đăng nhập (credential) mà chính dịch vụ IAM quản lý và đính vào đối tượng user. Danh sách phương án cố tình trộn lẫn nhiều loại "khoá" và "mật khẩu" khác nhau trong hệ sinh thái AWS — chứng chỉ SSL/TLS, key pair của EC2, mật khẩu hệ điều hành Linux — những thứ nghe rất giống credential nhưng thuộc về dịch vụ khác hoặc thuộc về hệ điều hành bên trong instance, không phải thuộc tính của IAM user.

Nói cách khác, phép thử để loại phương án là: thứ này có nằm trong tab thông tin của một IAM user không? Nếu nó sống ở EC2, ở ACM, hay bên trong hệ điều hành khách, thì câu trả lời là không.

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

Theo tệp, đáp án đúng là B và E. Một IAM user đại diện cho một con người hoặc một dịch vụ, và IAM cấp cho đối tượng đó đúng hai kiểu thông tin đăng nhập tương ứng với hai cách làm việc với AWS:

• B — An access key ID and secret access key: đây là credential cho truy cập bằng chương trình (programmatic access). Cặp khoá này dùng để ký request gửi tới AWS API, và là thứ mà AWS CLI, các SDK cùng nhiều công cụ phát triển đọc để xác thực. Nó được sinh ra và gắn trực tiếp vào IAM user.
• E — A password for access to the management console: đây là credential cho truy cập bằng giao diện web, tức đăng nhập vào AWS Management Console. Mật khẩu console cũng là một thuộc tính do IAM quản lý trên chính user đó.

Hai phương án này khớp đúng với sự phân đôi kinh điển của IAM user: console password để người dùng bấm chuột, access key để máy gọi API. Đó chính là lý do đề yêu cầu chọn hai phương án.

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

• A — An SSL/TLS certificate: sai. Chứng chỉ SSL/TLS dùng để mã hoá kết nối tới một endpoint (website, load balancer…), tức là gắn với tài nguyên phục vụ lưu lượng, không phải với danh tính của một người dùng. Bạn không thể "gán một chứng chỉ SSL/TLS cho một IAM user" theo cách gán mật khẩu hay access key. Đây là phương án bẫy vì chứng chỉ đúng là một thứ có yếu tố mật mã học và có liên quan tới bảo mật, nhưng nó nằm sai tầng trong đề bài.
• C — A password for logging into Linux: sai, và đây là phương án gần đúng nhất về mặt cảm giác. Nó đúng là một mật khẩu, nhưng là mật khẩu của hệ điều hành khách bên trong một instance, do chính hệ điều hành đó quản lý trong tệp người dùng của nó. IAM không nhìn thấy và không quản lý tài khoản hệ điều hành. Chỗ nó hỏng nằm ở phạm vi kiểm soát: IAM cấp quyền cho các lời gọi tới AWS, còn việc bạn là ai sau khi đã vào trong máy ảo là chuyện của hệ điều hành.
• D — A key pair: sai, và cũng là phương án gần đúng. Key pair là cặp khoá công khai/bí mật dùng với Amazon EC2, theo cơ chế mã hoá khoá công khai để truy cập an toàn vào instance. Người học rất dễ nhầm key pair với "access key ID và secret access key" ở phương án B vì cả hai đều là cặp khoá và đều nghe như credential. Khác biệt: key pair gắn với instance EC2 và dùng để vào máy, còn access key gắn với IAM user và dùng để ký request API.

📌 Điểm cần nhớ

• Một IAM user chỉ nhận đúng hai loại credential từ IAM: console password (truy cập giao diện) và access key ID + secret access key (truy cập bằng chương trình qua API/CLI/SDK).
• Phân biệt rạch ròi access key (thuộc IAM user, ký request API) với key pair (thuộc EC2, để truy cập vào instance) — đây là cặp đối lập bị hỏi lại nhiều nhất.
• IAM kiểm soát danh tính ở tầng AWS API; mọi thứ nằm bên trong hệ điều hành của instance (tài khoản Linux, mật khẩu hệ điều hành) đều ngoài phạm vi IAM.
• SSL/TLS certificate gắn với tài nguyên phục vụ lưu lượng, không gắn với danh tính người dùng — thấy nó xuất hiện trong câu hỏi về IAM user thì gần như chắc chắn là phương án nhiễu.

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

Đề hỏi: dịch vụ AWS nào cho phép thêm chức năng đăng ký người dùng (user sign-up), đăng nhập (sign-in) và kiểm soát truy cập (access control) vào ứng dụng web và mobile?

Cụm từ quyết định nằm ở phần cuối đề bài: "to web and mobile apps". Đây mới là ràng buộc phân biệt bốn phương án, vì cả bốn đều thuộc nhóm Security, Identity, & Compliance. Đề không hỏi về danh tính của nhân viên nội bộ, không hỏi về quản lý khoá mã hoá, cũng không hỏi về tài liệu tuân thủ — nó hỏi về danh tính của người dùng cuối (end user) trong ứng dụng do bạn tự viết.

Cụm thứ hai đáng chú ý là bộ ba "sign up, sign-in and access control" đi liền nhau: dịch vụ cần tìm phải lo trọn vòng đời của user cuối, từ lúc tạo tài khoản, tới lúc đăng nhập, tới lúc cấp quyền truy cập tài nguyên. Chỉ một dịch vụ trong danh sách được thiết kế cho đúng chuỗi việc đó.

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

D — Amazon Cognito là đáp án đúng theo tệp, và cũng đúng theo nguyên lý.

Amazon Cognito là dịch vụ quản lý danh tính người dùng cuối cho ứng dụng web và mobile. Nó cung cấp sẵn phần đăng ký, đăng nhập và kiểm soát truy cập mà lập trình viên chỉ việc gắn vào ứng dụng, không phải tự xây kho mật khẩu, tự xử lý xác thực hay tự phát hành token.

Hai điểm mạnh mà nguồn giải thích nhấn mạnh:

• Quy mô rất lớn — Cognito được thiết kế để phục vụ tới hàng triệu người dùng, đúng với đặc thù ứng dụng công cộng trên Internet.
• Liên kết danh tính (federation) — hỗ trợ đăng nhập bằng social identity provider như Facebook, Google, Amazon, và hỗ trợ enterprise identity provider thông qua SAML 2.0.

Chính vế "web and mobile apps" cộng với khả năng đăng nhập bằng tài khoản mạng xã hội là dấu hiệu nhận dạng Cognito rõ nhất trong đề thi Cloud Practitioner.

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

A — AWS Artifact. Đây là nguồn tài nguyên trung tâm về thông tin tuân thủ (compliance): nơi bạn tải các báo cáo kiểm toán và tài liệu chứng nhận của AWS. Nó phục vụ đội pháp chế, kiểm toán, bảo mật của tổ chức bạn — hoàn toàn không liên quan tới việc đăng nhập của người dùng cuối. Phương án này chỉ có mặt vì nó cũng nằm trong nhóm Security & Compliance.

B — AWS CloudHSM. Là hardware security module trên cloud, giúp bạn tự sinh và sử dụng khoá mã hoá của riêng mình trong AWS Cloud. Đây là chuyện mã hoá và quản lý khoá, không phải chuyện danh tính. Dễ loại vì nó không đụng gì tới sign-up hay sign-in.

C — AWS Directory Service. Đây là phương án gần đúng nhất và cũng là bẫy chính — nó thật sự là dịch vụ về danh tính, nên nhiều người dừng lại ở đó. Nhưng AWS Directory Service (AWS Managed Microsoft AD) phục vụ workload và tài nguyên AWS có nhận thức về directory, tức là cho bạn dùng Active Directory được quản lý trong AWS Cloud. Đối tượng của nó là danh tính nội bộ doanh nghiệp — nhân viên, máy tính đã join domain, ứng dụng gắn với Windows/AD. Nó không phải công cụ để lập trình viên gắn màn hình đăng ký và đăng nhập vào một ứng dụng mobile công cộng. Sai ở chỗ đối tượng người dùng, không sai ở chỗ "có phải dịch vụ danh tính hay không".

📌 Điểm cần nhớ

• Thấy cụm "web and mobile apps" đi cùng "sign-up / sign-in" → nghĩ ngay tới Amazon Cognito. Đây là mẫu câu hỏi lặp lại rất nhiều lần trong đề Cloud Practitioner.
• Phân biệt theo đối tượng danh tính: Cognito = người dùng cuối của ứng dụng bạn viết; AWS Directory Service = danh tính nội bộ doanh nghiệp kiểu Active Directory. Cả hai đều là "identity" nhưng phục vụ hai nhóm người khác nhau.
• CloudHSM thuộc nhóm mã hoá và quản lý khoá, Artifact thuộc nhóm tài liệu tuân thủ — cả hai chỉ là nhiễu khi đề hỏi về xác thực người dùng.
• Cognito hỗ trợ social identity provider (Facebook, Google, Amazon) và enterprise identity provider qua SAML 2.0; đề nào nhắc tới "đăng nhập bằng Facebook/Google" trong ứng dụng thì đáp án gần như chắc chắn là Cognito.

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

Đề mô tả tình huống: một system administrator phát hiện nhiều EC2 instance đã bị terminate, và nhiệm vụ của họ là xác định user nào hoặc AWS API call nào đã thực hiện việc đó.

Cụm từ quyết định đáp án là "identify the user or AWS API call that terminated these instances". Hai chi tiết cần bám vào:

• "user" — phải truy ra được danh tính (IAM principal) đứng sau hành động.
• "API call" — phải có bản ghi của chính lời gọi API (TerminateInstances).

Đây là câu hỏi về audit trail / nhật ký hành vi trong tài khoản, không phải về quét lỗ hổng, không phải về khuyến nghị tối ưu, cũng không phải về điều tra mối đe doạ nâng cao. Ai đã làm gì, lúc nào, từ đâu — đó chính xác là bài toán của một service ghi lại lời gọi API.

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

Đáp án đúng theo tệp là D — AWS CloudTrail.

CloudTrail theo dõi các API call được thực hiện trong một AWS account. Với mỗi sự kiện, nó ghi lại: lời gọi API nào được thực hiện, địa chỉ IP mà lời gọi xuất phát, và IAM principal nào đã khởi tạo hành động đó.

Ánh xạ thẳng vào yêu cầu của đề: khi ai đó terminate EC2 instance, thao tác ấy đi qua API TerminateInstances. CloudTrail ghi lại sự kiện này kèm danh tính người gọi — nên system administrator chỉ cần tra trong CloudTrail là trả lời được cả hai vế "user nào" và "API call nào". Không service nào khác trong danh sách làm đúng việc ghi nhật ký API call theo principal như vậy.

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

A — Amazon Inspector. Đây là công cụ đánh giá lỗ hổng (vulnerability assessment) được quản lý hoàn toàn. Nó soi tình trạng bảo mật của workload — phần mềm có lỗ hổng đã biết hay không, cấu hình có phơi ra ngoài hay không. Nó không theo dõi ai đang thực hiện hành động gì trong tài khoản. Inspector có thể nói cho bạn biết một instance có rủi ro, nhưng không nói được ai đã bấm nút xoá nó.

B — Amazon Detective. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì tên gọi lẫn mục đích đều nghe rất "điều tra". Detective tự động thu thập log từ các tài nguyên AWS rồi dùng machine learning, phân tích thống kê và lý thuyết đồ thị để dựng một tập dữ liệu liên kết, giúp tiến hành điều tra bảo mật nhanh và hiệu quả hơn. Chỗ nó hỏng so với đề: Detective là lớp phân tích đặt trên dữ liệu đã có, chứ bản thân nó không phải nguồn ghi lại API call trong tài khoản. Đề chỉ hỏi một việc đơn giản và trực tiếp — tìm user và API call đã terminate instance — thì thứ cần dùng là chính nguồn nhật ký, không phải công cụ phân tích tương quan phía trên.

C — AWS Trusted Advisor. Trusted Advisor đưa ra khuyến nghị giúp bạn tuân theo best practice của AWS. Nó chạy các check để đánh giá tài khoản, chỉ ra cách tối ưu hạ tầng, cải thiện bảo mật và hiệu năng, giảm chi phí, và theo dõi service quota. Toàn bộ đầu ra của nó là lời khuyên hướng tới tương lai, không phải nhật ký sự kiện đã xảy ra trong quá khứ. Nó không có khái niệm "ai đã gọi API nào lúc mấy giờ".

📌 Điểm cần nhớ

• Đề bài xuất hiện các từ khoá "who did it", "which user", "API call", "audit", "trace an action" → nghĩ ngay tới AWS CloudTrail. Đây là mẫu câu hỏi lặp lại rất nhiều trong kỳ thi.
• Phân biệt bốn service này bằng câu hỏi mà chúng trả lời: CloudTrail = "ai đã gọi API gì"; Inspector = "workload của tôi có lỗ hổng nào"; Detective = "phân tích sâu một sự cố bảo mật từ dữ liệu đã thu thập"; Trusted Advisor = "tôi nên cải thiện gì cho đúng best practice".
• Khi hai phương án đều nghe giống "bảo mật/điều tra" (như CloudTrail và Detective), hãy hỏi: đề cần nguồn ghi nhận sự kiện gốc hay cần công cụ phân tích trên dữ liệu đó? Câu hỏi truy vết một hành động cụ thể luôn rơi về nguồn nhật ký.
• Ghi nhớ ba trường thông tin CloudTrail cung cấp cho mỗi sự kiện — API call, IP nguồn, và IAM principal — vì nhiều câu hỏi được diễn đạt qua một trong ba trường này thay vì gọi tên trực tiếp.