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

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

Đề hỏi: theo AWS Shared Responsibility Model, đâu là một shared control?

Cụm từ quyết định đáp án là "shared control" — không phải "AWS responsibility", cũng không phải "customer responsibility". Mô hình chia trách nhiệm của AWS có ba nhóm:

• Inherited controls: khách hàng thừa hưởng hoàn toàn từ AWS (bảo vệ vật lý, hạ tầng).
• Customer specific controls: hoàn toàn thuộc về khách hàng.
• Shared controls: áp dụng cho cả lớp hạ tầng lẫn lớp khách hàng, nhưng ở hai ngữ cảnh hoàn toàn tách biệt. AWS lo phần kiểm soát cho hạ tầng của mình, còn khách hàng phải tự triển khai kiểm soát tương ứng bên trong phần họ dùng.

Ba ví dụ kinh điển về shared control mà tài liệu AWS nêu ra: patch management, configuration management, và awareness and training. Chỉ cần nhận ra bốn phương án đang trộn lẫn ba nhóm này là câu hỏi tự phân loại được.

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

Đáp án đúng theo tệp là D — Awareness and training.

Đây là shared control theo đúng định nghĩa hai ngữ cảnh tách biệt:

• Phía AWS: AWS đào tạo nhân viên của chính AWS — nhận thức an ninh, quy trình xử lý dữ liệu, trách nhiệm vận hành hạ tầng.
• Phía khách hàng: khách hàng phải đào tạo nhân viên của mình — cách dùng tài khoản AWS an toàn, không chia sẻ credential, nhận biết phishing, tuân thủ chính sách nội bộ.

Cùng một loại kiểm soát ("awareness and training"), nhưng mỗi bên chịu trách nhiệm cho phạm vi con người của riêng mình. AWS không thể đào tạo nhân viên của bạn, và bạn cũng không thể đào tạo nhân viên của AWS. Đó chính là dấu hiệu của shared control.

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

A — Client-side data encryption. Đây là trách nhiệm hoàn toàn của khách hàng, không chia sẻ. Cả client-side lẫn server-side data encryption đều nằm ở phía khách hàng: bạn quyết định có mã hoá hay không, chọn thuật toán, và đặc biệt là quản lý khoá. AWS cung cấp công cụ, nhưng việc bật và cấu hình mã hoá là của bạn — AWS không có vai trò song song nào ở đây, nên không phải shared control.

B — Protection of infrastructure. Đây là trách nhiệm hoàn toàn của AWS — bảo vệ vật lý data center, phần cứng, mạng lõi, tầng ảo hoá. Khách hàng không được vào data center và không có cách nào tham gia. Đây là inherited control: bạn thừa hưởng nó chứ không chia sẻ nó.

C — Operating system patching. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Ở mức khái quát, patch management đúng là một shared control: AWS vá hệ điều hành nền của hạ tầng và các managed service, còn khách hàng vá guest OS của mình. Nhưng đề không viết "patch management" — đề viết cụ thể "operating system patching", tức là vá guest OS trên các instance của khách hàng. Đọc ở mức cụ thể đó thì nó rơi hẳn về phía customer responsibility, không còn là kiểm soát chia sẻ nữa. Đây đúng là mẫu câu đòi đọc kỹ mức độ khái quát của từ ngữ: cùng một chủ đề, đổi cách diễn đạt là đổi luôn phân loại.

📌 Điểm cần nhớ

• Shared control = cùng một loại kiểm soát, hai ngữ cảnh tách biệt. AWS làm cho hạ tầng của AWS, khách hàng làm cho phần khách hàng dùng. Ba ví dụ chuẩn cần thuộc: patch management, configuration management, awareness and training.
• Đọc kỹ mức khái quát của từ ngữ. "Patch management" là shared control, nhưng "operating system patching" (guest OS) là customer responsibility. Đề thi hay dùng đúng chiêu này để tách hai phương án gần nhau.
• Bất cứ thứ gì thuộc về vật lý, phần cứng, data center, hoặc tầng ảo hoá đều là AWS-only (inherited control), không bao giờ là shared control.
• Mã hoá dữ liệu và quản lý khoá luôn nghiêng về phía khách hàng, cả client-side lẫn server-side — AWS cung cấp công cụ chứ không quyết định thay bạn.

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

Đề hỏi: khi một tổ chức áp dụng AWS Cloud Adoption Framework (AWS CAF) để chuyển dịch lên cloud, hai nhóm nào nhiều khả năng là primary stakeholders trong quá trình đó.

Cụm từ quyết định là "primary stakeholders" đi kèm bối cảnh "leverages the AWS Cloud Adoption Framework for migrating to the cloud". AWS CAF là một khung hoạch định và định hướng chuyển đổi — nó giúp tổ chức nhìn ra khoảng cách giữa hiện trạng và trạng thái mong muốn, rồi vạch lộ trình. Vì vậy "primary stakeholder" ở đây mang nghĩa người đặt ra định hướng chiến lược và thiết kế kiến trúc mục tiêu, chứ không phải người thực thi từng bước hay người ký duyệt ngân sách.

Chú ý thêm: cả năm phương án đều là những vai trò có mặt thật trong một dự án migration. Đề không hỏi "ai tham gia", mà hỏi ai là bên liên quan chính. Đó chính là ràng buộc tách các phương án gần giống nhau.

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

Theo tệp, đáp án đúng là D. IT Architects và E. Chief Information Officers (CIOs).

• CIOs là người đứng đầu về công nghệ thông tin trong tổ chức. Họ giám sát toàn bộ quá trình chuyển dịch và bảo đảm chiến lược IT bám sát mục tiêu kinh doanh của doanh nghiệp. AWS CAF vốn được dựng để nối hai đầu đó lại với nhau, nên người giữ vai trò này đương nhiên là stakeholder chính.
• IT Architects là người thiết kế hạ tầng cloud sao cho hiện thực hoá được chiến lược IT một cách hiệu quả. Họ biến định hướng của CIO thành kiến trúc mục tiêu cụ thể — chính là phần việc mà AWS CAF hướng tới khi bàn về trạng thái tương lai của tổ chức.

Cặp CIO + IT Architect vì thế phủ đúng hai lớp mà AWS CAF quan tâm: định hướng và thiết kế.

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

• A. Project Managers — đây là phương án gần đúng nhất, và cũng dễ chọn nhầm nhất. Project Manager có thể là stakeholder, đặc biệt trong các cuộc migration lớn phải điều phối nhiều đội cùng lúc. Nhưng vai trò của họ thiên về quản lý tiến độ và điều phối nguồn lực, chứ không phải đặt ra định hướng chiến lược. Họ vận hành kế hoạch do người khác vạch ra — nên là bên liên quan, nhưng không phải bên liên quan chính theo cách đề hỏi.
• B. Chief Financial Officers (CFOs) — CFO đúng là có tham gia, ở khía cạnh ngân sách và cân nhắc chi phí. Nhưng AWS CAF trong ngữ cảnh câu hỏi này bàn về khía cạnh kỹ thuật và chiến lược của việc chuyển dịch, và CFO thường không phải người dẫn dắt phần đó. Đây là bẫy kinh điển: thấy "migration tốn tiền" nên chọn CFO.
• C. Engineers — Engineer nằm ở giai đoạn thực thi: dựng hạ tầng, viết mã, chuyển workload. Đó là công việc diễn ra sau khi định hướng và kiến trúc đã chốt. Họ không tham gia vào quá trình hoạch định chiến lược và ra quyết định mà CIO cùng IT Architect đảm nhận, nên không được xem là stakeholder chính ở tầng khung chuyển đổi.

Điểm chung của ba phương án sai: cả ba đều có mặt trong dự án, nhưng đứng ở tầng thực thi (Engineers), tầng điều phối (Project Managers), hoặc tầng tài chính (CFOs) — không phải tầng chiến lược - kiến trúc.

📌 Điểm cần nhớ

• AWS CAF là khung hoạch định chuyển đổi, không phải quy trình thi công. Câu hỏi về CAF hầu như luôn hướng về chiến lược và thiết kế, không hướng về thao tác kỹ thuật.
• Khi đề dùng chữ "primary stakeholders", hãy loại ngay những vai trò chỉ thực thi (Engineers) hay chỉ điều phối (Project Managers) — dù họ thật sự có tham gia dự án.
• Cặp CIO (định hướng) + IT Architect (thiết kế) là cặp mặc định cho các câu hỏi về bên liên quan trong AWS CAF.
• Đừng chọn CFO chỉ vì đề nhắc tới migration hay chi phí; CFO gắn với ngân sách, không gắn với khía cạnh kỹ thuật - chiến lược của khung chuyển đổi.

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

Đề hỏi: statement nào KHÔNG mô tả đúng cloud computing. Chữ quyết định nằm ở từ "NOT" viết hoa trong đề — đây là câu hỏi đảo ngược. Ba phương án sẽ là những mô tả đúng về cloud computing, và phương án cần chọn là cái sai. Đọc lướt rồi chọn "câu nghe hợp lý nhất" là rơi bẫy ngay.

Ràng buộc phân biệt thứ hai nằm trong chính phương án B: thứ tự của cụm "swap variable expense for capital expense". AWS có một câu nói gần như y hệt trong tài liệu Six Advantages of Cloud Computing, nhưng theo chiều ngược lại: trade capital expense for variable expense. B đảo hai vế nên trở thành mô tả sai — nó mô tả mô hình mua máy chủ đặt tại chỗ chứ không phải mô hình cloud.

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

Đáp án đúng theo tệp là B — "Cloud computing allows you to swap variable expense for capital expense".

Capital expense (CapEx) là khoản chi một lần để sở hữu tài sản: mua máy chủ, mua thiết bị mạng, dựng data center. Variable expense (OpEx) là khoản chi vận hành, trả theo mức dùng thực tế. Cloud computing đưa người dùng đi từ CapEx sang OpEx: không mua tài sản, chỉ trả cho lượng compute và storage đã tiêu thụ. B mô tả chiều ngược lại, tức là bỏ chi phí biến đổi để quay về chi phí đầu tư ban đầu — đó chính là thứ cloud loại bỏ, nên B không mô tả được cloud computing và là đáp án phải chọn.

Có một điểm dễ gây phân vân: khi mua reserved capacity, người dùng được chọn trả trước một phần hoặc toàn bộ. Nhìn thì giống một khoản chi lớn ban đầu, nhưng bản chất vẫn là chi phí vận hành — người dùng không sở hữu và không khấu hao tài sản đó, họ chỉ trả trước cho quyền sử dụng. Nên trường hợp này không biến B thành đúng.

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

Cả ba đều là mô tả hợp lệ về cloud computing, nên đều sai trong một câu hỏi "NOT".

A — "Cloud computing is the on-demand delivery of compute power": đây gần như là định nghĩa chuẩn của cloud computing. On-demand nghĩa là lấy tài nguyên khi cần, trả lại khi không cần, không phải đặt hàng và chờ lắp đặt. Câu này đúng, nên không phải đáp án.

C — "With cloud computing you get to benefit from massive economies of scale": nhà cung cấp gom nhu cầu của rất nhiều khách hàng lại nên mua sắm và vận hành hạ tầng ở quy mô mà một tổ chức đơn lẻ không đạt tới được, phần tiết kiệm đó phản ánh vào giá. Đây là một trong các lợi ích được AWS nêu thẳng trong tài liệu, nên là mô tả đúng.

D — "With cloud computing you can increase your speed and agility": tài nguyên có sẵn trong vài phút thay vì vài tuần đặt mua phần cứng, nên chi phí thử nghiệm giảm mạnh và đội ngũ triển khai nhanh hơn. Cũng là lợi ích chính thức, mô tả đúng.

Phương án dễ nhầm nhất với B chính là C và D — không phải vì nội dung chúng sai, mà vì thí sinh đọc vội câu "NOT" rồi tìm phương án "nghe lạ nhất". Cả ba A, C, D đều lấy nguyên văn từ danh sách lợi ích của AWS; chỉ B là câu bị đảo chiều.

📌 Điểm cần nhớ

• Gặp từ NOT / EXCEPT / LEAST viết hoa trong đề: đọc lại lần hai và xác định rõ mình đang tìm cái sai. Đây là kiểu bẫy phổ biến nhất ở AWS Certified Cloud Practitioner.
• Chiều đúng luôn là trade capital expense for variable expense — bỏ chi phí đầu tư ban đầu, chuyển sang trả theo mức dùng. Bất kỳ phương án nào viết ngược lại đều sai.
• Reserved capacity trả trước vẫn là operating expense, vì người dùng không sở hữu và không khấu hao tài sản. Trả trước ≠ CapEx.
• Nhóm mô tả hợp lệ hay được lấy từ danh sách lợi ích của cloud: on-demand delivery, economies of scale, speed and agility, thôi đoán dung lượng cần chuẩn bị, đi ra toàn cầu nhanh hơn, thôi tốn tiền vận hành data center. Thuộc nhóm này thì gần như chắc chắn là phương án đúng, tức không phải đáp án của câu hỏi "NOT".

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

Đề mô tả một công ty eCommerce khởi nghiệp cần nhanh chóng đưa tính năng mới lên website theo cách lặp (iterative), rút ngắn thời gian ra thị trường, rồi hỏi đặc tính nào của AWS Cloud cho phép điều đó.

Cụm từ quyết định là "quickly deliver ... in an iterative manner, minimizing the time to market". Đây là câu hỏi về tốc độ thử nghiệm và triển khai, không phải về chịu lỗi, không phải về khả năng co giãn theo tải. Bốn phương án đều là những đặc tính "đẹp" của cloud và rất dễ nhầm, nên phải bám vào việc: điều gì làm cho khoảng cách từ ý tưởng tới chạy thật ngắn lại?

Một dấu hiệu phụ: đề không nói gì về lượng truy cập tăng giảm, cũng không nói gì về downtime hay mất dữ liệu. Thiếu hai tín hiệu đó chính là cách loại bỏ các phương án còn lại.

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

Đáp án đúng theo tệp là B — Agility.

Trong môi trường cloud, tài nguyên IT mới chỉ cách một cú nhấp chuột: thời gian để cấp phát tài nguyên cho lập trình viên rút từ hàng tuần xuống còn vài phút. Không phải chờ mua phần cứng, chờ lắp đặt, chờ cấu hình trung tâm dữ liệu.

Hệ quả là chi phí và thời gian để thử nghiệm giảm mạnh — dựng môi trường thử, chạy thử một tính năng, thấy không ổn thì bỏ đi và làm lại. Đó chính xác là cái mà "iterative" và "minimizing time to market" trong đề mô tả. Agility (tính linh hoạt, nhanh nhẹn) là tên gọi chuẩn của đặc tính này trong tài liệu về sáu lợi thế của điện toán đám mây mà AWS công bố.

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

A — High availability. Đây là khả năng hệ thống tiếp tục phục vụ khi một thành phần hỏng, gắn với resilience (khả năng chống chịu). Nó giúp website không sập, chứ không giúp đội phát triển ra tính năng mới nhanh hơn. Đề không hề nhắc tới downtime hay yêu cầu về thời gian hoạt động.

C — Reliability. Đây là mức độ hệ thống hoạt động đúng và ổn định theo thời gian. Cũng là một đặc tính tốt, nhưng không hỗ trợ gì cho việc đưa tính năng ra thị trường nhanh hơn — một hệ thống rất tin cậy vẫn có thể mất hàng tháng để triển khai tính năng mới nếu quy trình cấp phát tài nguyên chậm. Đây và phương án A gần như cùng nhóm ý nghĩa, và cùng bị loại vì cùng một lý do.

D — Elasticity. Đây là phương án gần đúng nhất và cũng là bẫy chính. Elasticity là khả năng tự động tăng giảm tài nguyên theo nhu cầu thực tế, nhờ đó không phải đoán trước dung lượng cần dùng. Với một trang eCommerce, elasticity rất có ích khi lượng khách tăng vọt vào mùa cao điểm — nhưng đó là chuyện xử lý tải, không phải chuyện tốc độ phát triển tính năng. Đề bài không hề đề cập tới biến động lưu lượng hay chuyện dư/thiếu công suất, nên tín hiệu để chọn elasticity không tồn tại.

📌 Điểm cần nhớ

• Agility = nhanh thử nghiệm, nhanh ra thị trường. Cứ thấy "time to market", "experiment", "iterate", "innovate faster", "deploy new features quickly" thì nghĩ ngay tới agility.
• Elasticity = khớp tài nguyên với nhu cầu. Tín hiệu là "spikes in traffic", "unpredictable demand", "avoid over-provisioning", "không phải đoán dung lượng".
• High availability và reliability thuộc nhóm chống chịu lỗi, tín hiệu là downtime, failover, fault tolerance, uptime — không liên quan tới tốc độ phát triển.
• Với dạng câu hỏi "đặc tính nào của cloud", hãy tìm danh từ mô tả kết quả kinh doanh trong đề (nhanh ra mắt / chịu tải / không sập) rồi ánh xạ sang đúng một thuật ngữ, thay vì cân nhắc xem phương án nào "nghe hợp lý hơn" — cả bốn đều hợp lý về mặt chung chung.

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

Đề hỏi: loại Elastic Load Balancer nào hoạt động ở mức kết nối TCP ("operates at the TCP connection level").

Cụm từ quyết định đáp án là "at the TCP connection level" — tức tầng 4 (layer 4) của mô hình OSI, nơi thiết bị chỉ nhìn thấy địa chỉ IP, cổng và trạng thái kết nối TCP, chứ không đọc nội dung ứng dụng bên trong. Chú ý thêm chữ "type of Elastic Load Balancer": câu hỏi giới hạn trong họ ELB của AWS, nên bất kỳ phương án nào không phải là một loại ELB đều bị loại ngay từ đầu, không cần bàn tới tầng nào.

Đây là kiểu câu phân biệt các phương án gần giống nhau bằng tầng xử lý. Muốn chọn đúng, phải nhớ mỗi loại load balancer nhìn thấy cái gì: chỉ header TCP/IP, hay đọc được cả HTTP/HTTPS.

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

Đáp án đúng theo tệp là A — Network Load Balancer (NLB).

NLB hoạt động ở tầng 4 của mô hình OSI. Nó điều hướng kết nối dựa trên thông tin ở mức kết nối TCP — địa chỉ IP nguồn/đích và cổng — chứ không mở gói tin ra để đọc đường dẫn URL hay header HTTP. Đúng nguyên văn thứ đề bài mô tả: "operates at the TCP connection level".

Vì chỉ xử lý ở tầng transport, NLB là lựa chọn cho lưu lượng không phải HTTP, hoặc khi cần chuyển tiếp kết nối TCP thuần với độ trễ thấp. Nhưng ở tầm Cloud Practitioner, điều cần khớp chỉ là: NLB ↔ layer 4 ↔ TCP.

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

B — Classic Load Balancer (CLB). Đây là phương án gần đúng nhất và là cái bẫy thật sự của câu hỏi. CLB có xử lý được TCP và SSL, tức là nó có chạm tới tầng 4. Nhưng nó không dừng ở đó: CLB còn xử lý cả HTTP và HTTPS, tức vừa tầng 4 vừa tầng 7. Đề hỏi loại load balancer hoạt động ở mức kết nối TCP như đặc trưng định danh của nó, và CLB không phải là câu trả lời sạch cho điều đó — nó là loại thế hệ cũ ôm cả hai tầng. Khi một câu hỏi trắc nghiệm buộc chọn một, phương án mô tả đúng và chỉ đúng tầng được hỏi sẽ thắng phương án mô tả một phần.

C — Application Load Balancer (ALB). Sai vì ALB xử lý ở tầng ứng dụng (layer 7). Nó đọc được thông tin trong header HTTP/HTTPS, nên định tuyến được theo đường dẫn hay theo host. Chính khả năng "nhìn vào nội dung HTTP" đó khiến nó nằm ở tầng cao hơn hẳn mức kết nối TCP mà đề đang hỏi. Nhớ theo tên gọi: Application → application layer.

D — Amazon Route 53 Load Balancer. Sai vì không tồn tại tính năng nào tên như vậy. Route 53 là dịch vụ DNS, nó không phải một loại Elastic Load Balancer. Route 53 có thể tạo ra hiệu ứng phân tải theo kiểu riêng thông qua multivalue answer routing — trả về nhiều bản ghi cho một truy vấn DNS — nhưng đó là định tuyến ở tầng DNS, không phải một load balancer trong họ ELB và cũng không hoạt động ở mức kết nối TCP. Phương án bịa tên dịch vụ như thế này khá phổ biến trong đề Cloud Practitioner, loại được ngay khi nhận ra tên không có thật.

📌 Điểm cần nhớ

• Ghép tên với tầng OSI: Network Load Balancer → tầng 4 (TCP); Application Load Balancer → tầng 7 (HTTP/HTTPS). Tên dịch vụ đã nói ra tầng của nó.
• Classic Load Balancer là loại thế hệ cũ trải trên cả hai tầng (TCP/SSL và HTTP/HTTPS). Nó là mồi nhử ở mọi câu hỏi phân biệt tầng — khi đề chỉ tay vào đúng một tầng, chọn NLB hoặc ALB chứ đừng chọn CLB.
• Từ khoá trong đề chỉ thẳng đáp án: thấy "TCP connection", "layer 4", "non-HTTP traffic" → nghĩ NLB. Thấy "URL path", "host header", "HTTP/HTTPS", "layer 7" → nghĩ ALB.
• Route 53 là DNS, không phải ELB. Nó có thể phân tán truy vấn bằng multivalue answer routing, nhưng không bao giờ là câu trả lời cho câu hỏi "loại Elastic Load Balancer nào". Cảnh giác với các phương án ghép tên dịch vụ có thật vào một tính năng không có thật.

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

Đề bài đặt bối cảnh: công ty vừa mới chuyển sang AWS, và câu hỏi là CTO có thể theo dõi chi phí (monitor the organization's costs) của tổ chức bằng cách nào.

Cụm từ quyết định ở đây là "monitor … costs" — theo dõi chi phí đang phát sinh, tức là chi phí thật đã và đang tiêu, chứ không phải:

• theo dõi hành động trên tài khoản (ai làm gì, lúc nào),
• ước tính trước chi phí của một kiến trúc chưa triển khai,
• hay gộp hoá đơn của nhiều tài khoản lại với nhau.

Ba phương án sai đều rơi đúng vào ba nhóm vừa kể. Chỉ cần bám vào động từ "monitor" đi kèm danh từ "costs" là loại được chúng.

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

A – AWS Cost Explorer. Đây là công cụ chuyên để xem và phân tích chi phí cùng mức sử dụng theo thời gian. Nó vẽ ra biểu đồ và bảng số liệu cho phép nhìn xu hướng chi tiêu, đồng thời bóc tách xem khoản tiền đó đến từ đâu — theo dịch vụ, theo tài khoản, theo tag, theo vùng. Đúng như phần giải thích gốc nêu: Cost Explorer "enables you to visualize your usage patterns over time and to identify your underlying cost drivers".

Với một CTO vừa đưa công ty lên AWS, nhu cầu là nhìn thấy tiền đang chảy đi đâu và có tăng bất thường không — đó chính xác là việc Cost Explorer sinh ra để làm. Nó nhìn vào dữ liệu chi phí thực tế đã phát sinh, nên là công cụ monitoring, khác hẳn công cụ ước tính.

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

B – AWS CloudTrail. Đây là dịch vụ ghi lại nhật ký hoạt động API trong tài khoản: ai đã gọi lệnh gì, lên tài nguyên nào, từ đâu, lúc nào. Nó phục vụ kiểm toán (audit), điều tra sự cố bảo mật và truy vết thay đổi cấu hình. Rất hữu ích để biết ai đã bật cái EC2 instance đắt tiền kia, nhưng bản thân CloudTrail không hiển thị số tiền, không có biểu đồ chi phí. Nhầm lẫn hay gặp: thấy chữ "trail/monitor" là chọn, trong khi đối tượng nó theo dõi là hành động, không phải chi phí.

C – AWS Simple Monthly Calculator. Đây là công cụ ước tính chi phí trước khi triển khai — bạn khai mình định dùng bao nhiêu EC2, bao nhiêu dung lượng lưu trữ, nó tính ra hoá đơn dự kiến hàng tháng. Phần giải thích gốc nói rõ: nó "shows you how much you would pay in AWS if you move your resources". Chú ý thì tương lai giả định "would pay" — đó là dự toán cho kịch bản chưa xảy ra. Đề bài lại nói công ty đã migrate xong rồi, nên nhu cầu không còn là ước tính nữa mà là theo dõi số thật. Đây là phương án gần đúng nhất về mặt "chủ đề chi phí", nhưng sai hẳn về mặt thời điểm sử dụng.

D – AWS Consolidated Billing. Đây là tính năng của AWS Organizations, cho phép gộp hoá đơn của nhiều tài khoản liên kết về một tài khoản trả tiền duy nhất, và nhờ gộp mức sử dụng lại mà được hưởng ưu đãi theo bậc khối lượng. Nó giải quyết bài toán cấu trúc thanh toán, không phải bài toán phân tích và giám sát. Consolidated Billing cho bạn một hoá đơn thay vì mười hoá đơn, nhưng không tự nó cho bạn biểu đồ xu hướng hay chỉ ra đâu là dịch vụ ngốn tiền nhất. Trên thực tế hai thứ này thường đi cùng nhau — gộp hoá đơn rồi dùng Cost Explorer để phân tích — nhưng công cụ theo dõi mà câu hỏi cần vẫn là Cost Explorer.

📌 Điểm cần nhớ

• Phân biệt "ước tính trước" và "theo dõi sau": Simple Monthly Calculator (và các công cụ dạng pricing calculator) dùng khi chưa triển khai; Cost Explorer dùng khi đã có chi phí thật phát sinh. Đề bài luôn cài sẵn manh mối thì của động từ — "đã migrate", "would pay", "sắp triển khai".
• CloudTrail theo dõi hành động, không theo dõi tiền. Hễ thấy CloudTrail xuất hiện trong một câu hỏi về chi phí thì gần như chắc chắn đó là phương án gây nhiễu; miền của nó là audit và bảo mật.
• Consolidated Billing là chuyện cấu trúc thanh toán, không phải chuyện phân tích. Nó thuộc AWS Organizations, giải quyết "gộp hoá đơn nhiều tài khoản và hưởng chiết khấu khối lượng".
• Từ khoá gợi nhớ cho Cost Explorer: visualize, trend theo thời gian, cost drivers, bóc tách theo dịch vụ/tài khoản/tag. Gặp bất kỳ cụm nào trong số đó thì Cost Explorer thường là đáp án.

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

Đề hỏi: theo AWS Shared Responsibility Model, ai chịu trách nhiệm phần nào — và yêu cầu chọn HAI phương án đúng.

Cụm từ quyết định nằm ngay ở tên mô hình: ranh giới giữa "security OF the cloud" (AWS lo) và "security IN the cloud" (khách hàng lo). Nhưng để chọn đúng giữa năm phương án gần giống nhau, cụm từ thật sự phân biệt lại nằm trong chính từng phương án — cặp chữ infrastructure so với configuration / protection:

• Danh từ chỉ hạ tầng vật lý (compute infrastructure, networking infrastructure, edge locations) → luôn thuộc về AWS. Khách hàng không sờ được vào thiết bị mạng, máy chủ vật lý hay tòa nhà edge location.
• Danh từ chỉ cấu hình và bảo vệ dữ liệu do khách hàng đặt ra (network and firewall configuration, networking traffic protection) → luôn thuộc về khách hàng.

Bốn trong năm phương án ở đây được dựng theo đúng kiểu bẫy phổ biến: lấy một hạng mục có thật trong mô hình rồi gán nhầm bên chịu trách nhiệm. Vì vậy mẹo làm bài là đọc danh từ trước, xác định nó thuộc lớp nào, rồi mới kiểm xem chủ ngữ (AWS hay Customers) có khớp không.

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

Đáp án đúng là D và E.

D — "Customers are responsible for networking traffic protection." Bảo vệ lưu lượng mạng là việc khách hàng làm bên trong môi trường của mình: bật mã hóa cho dữ liệu khi truyền, đặt security group và Network ACL để quyết định luồng nào được đi qua. AWS cung cấp sẵn các công cụ đó nhưng không biết ứng dụng của bạn cần mở cổng nào cho ai — nên trách nhiệm cấu hình và bảo vệ thuộc về khách hàng.

E — "AWS are responsible for networking infrastructure." Thiết bị mạng nền tảng — router, switch, đường truyền giữa các Availability Zone, hệ thống cáp trong data center — do AWS vận hành và bảo trì. Đây chính là phần "protecting the infrastructure that runs all of the services offered in the AWS Cloud" trong định nghĩa của mô hình.

Hai đáp án này ghép lại thành đúng một cặp minh họa trọn vẹn ranh giới: cùng chủ đề networking, nhưng một bên là hạ tầng (AWS) và một bên là bảo vệ lưu lượng (khách hàng).

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

A — "Customers are responsible for compute infrastructure." Sai ở chủ ngữ. Compute infrastructure là máy chủ vật lý, phần cứng ảo hóa, hypervisor chạy trong data center của AWS — khách hàng không quản lý được lớp này. Khách hàng chịu trách nhiệm với những gì chạy trên compute (hệ điều hành khách, bản vá, ứng dụng, dữ liệu), chứ không phải bản thân hạ tầng compute. Đây là phương án gần đúng nhất nếu đọc lướt, vì chữ "compute" khiến người học nhớ tới EC2 — nhưng hạng mục được nêu là infrastructure, không phải guest OS.

B — "Customers are responsible for edge locations." Sai ở chủ ngữ. Edge locations là các điểm hiện diện vật lý của AWS trên toàn cầu, thuộc cùng nhóm với Regions và Availability Zones — tức là phần "hardware / global infrastructure" mà AWS xây, vận hành và bảo vệ. Khách hàng có thể sử dụng edge locations (ví dụ khi phân phối nội dung), nhưng dùng không đồng nghĩa với chịu trách nhiệm vận hành.

C — "AWS are responsible for network and firewall configuration." Sai ở chủ ngữ, và đây là bẫy nguy hiểm nhất vì nó rất giống đáp án E. Khác biệt nằm ở chữ configuration: cấu hình mạng và firewall — đặt subnet, bảng định tuyến, quy tắc security group, Network ACL — là quyết định của khách hàng theo nhu cầu ứng dụng. AWS chỉ đưa ra công cụ; nếu bạn mở firewall ra toàn Internet thì đó là lựa chọn của bạn, không phải lỗi của AWS. Đảo chủ ngữ của C lại thành "Customers" là ta có một đáp án đúng thứ ba — chính vì vậy phương án này được dựng ra để đánh lừa.

📌 Đ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 tảng, Regions/AZ/edge locations); khách hàng lo security IN the cloud (dữ liệu, cấu hình, quyền truy cập, mã hóa).
• Đọc danh từ hạng mục trước, chủ ngữ sau. Từ khóa infrastructure, hardware, facilities, edge locations → AWS. Từ khóa configuration, protection, encryption, data, access management → khách hàng.
• Cặp networking infrastructure (AWS) và network/firewall configuration + networking traffic protection (khách hàng) là bẫy kinh điển — cùng chủ đề mạng nhưng khác lớp trách nhiệm.
• Được sử dụng một thành phần không có nghĩa là chịu trách nhiệm cho nó; edge location và compute infrastructure đều rơi vào nhầm lẫn này.
• Trách nhiệm của khách hàng thay đổi theo từng dịch vụ: dịch vụ càng được quản lý nhiều thì phần khách hàng phải lo càng ít, nhưng dữ liệu và phân quyền thì luôn thuộc về khách hàng.

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

Đề hỏi: trong các tuỳ chọn truy xuất dữ liệu (data access option / retrieval option) của Amazon S3 Glacier, tuỳ chọn nào lấy được dữ liệu từ một archive trong vòng 1–5 phút?

Cụm từ quyết định đáp án là "1-5 minutes". Glacier không phải kho lưu trữ đọc tức thì như S3 Standard: khi muốn lấy archive ra, bạn phải tạo một retrieval job và chờ. Thời gian chờ đó phụ thuộc vào tuỳ chọn truy xuất bạn chọn, và mỗi tuỳ chọn có một khoảng thời gian đặc trưng cùng một mức giá tương ứng — nhanh thì đắt, chậm thì rẻ.

Vậy đây là dạng câu ánh xạ tên tuỳ chọn ↔ khoảng thời gian. Chỉ cần nhớ đúng bộ tên của Glacier là loại được ngay các phương án bịa. Chú ý thêm chi tiết "from an archive" — Glacier gọi đối tượng lưu trữ là archive, không gọi là object như S3 thường, đây là dấu hiệu đề đang nói đúng về Glacier chứ không phải lớp lưu trữ nào khác.

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

Đáp án đúng là B — Expedited.

Expedited retrieval sinh ra đúng cho tình huống mà đề mô tả: thỉnh thoảng có một yêu cầu gấp cần lấy nhanh một phần nhỏ trong kho archive. Với hầu hết archive (trừ những archive rất lớn, cỡ từ 250 MB trở lên), dữ liệu truy xuất bằng Expedited thường sẵn sàng trong khoảng 1–5 phút. Đây chính là con số đề bài nêu, nên Expedited là lựa chọn khớp trực tiếp.

Đổi lại tốc độ đó là chi phí trên mỗi lần truy xuất cao hơn các tuỳ chọn còn lại — đó là lý do Expedited được mô tả là dành cho nhu cầu khẩn cấp, không thường xuyên, chứ không phải để dùng làm chế độ mặc định cho mọi lần đọc.

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

• A — Accelerated: không tồn tại trong bộ tuỳ chọn truy xuất của Glacier. Đây là tên bịa, ăn theo cảm giác "accelerate = tăng tốc" nên nghe rất hợp lý với một câu hỏi về tốc độ. AWS có dùng chữ "Accelerated" ở dịch vụ khác (ví dụ S3 Transfer Acceleration — tăng tốc truyền dữ liệu qua edge location), nên thí sinh dễ nhầm sang; nhưng nó không phải một retrieval option của Glacier.

• C — Standard: đây là tuỳ chọn có thật, và là bẫy nguy hiểm nhất trong câu này vì nó là chế độ truy xuất mặc định, quen thuộc nhất. Nhưng nó hỏng ở đúng chỗ đề nhấn: thời gian. Standard mất khoảng 3–5 giờ, không phải 1–5 phút. Cùng dãy số "3-5" nhưng khác đơn vị — đọc lướt qua chữ minutes trong đề là chọn nhầm ngay. Standard hợp cho nhu cầu lấy dữ liệu bình thường, không gấp, với chi phí thấp hơn Expedited.

• D — Express: cũng không tồn tại như một retrieval option của Glacier. Chữ "Express" xuất hiện ở chỗ khác trong hệ sinh thái AWS storage (tên lớp lưu trữ hiệu năng cao S3 Express One Zone), nên nghe rất "đúng giọng AWS" và dễ được chọn theo cảm tính. Nhưng khi nói về việc lấy dữ liệu ra khỏi một archive trong Glacier thì không có chế độ nào tên là Express.

📌 Điểm cần nhớ

• Với Glacier, hãy học thuộc bộ tên các retrieval option đi cùng bậc thời gian của nó: Expedited = vài phút, Standard = vài giờ, và bậc rẻ nhất/chậm nhất dành cho khối lượng lớn mất tới cỡ nửa ngày. Nhớ bậc độ lớn (phút / giờ) quan trọng hơn nhớ con số chính xác.
• Trong câu hỏi loại này, đơn vị thời gian mới là từ khoá, không phải con số. "3–5 hours" và "1–5 minutes" trông rất giống nhau khi đọc nhanh — luôn khoanh lại chữ minutes / hours trong đề trước khi chọn.
• Đề trắc nghiệm AWS rất hay chèn tên nghe có vẻ đúng nhưng không tồn tại (ở đây là Accelerated và Express, mượn âm hưởng từ Transfer Acceleration và S3 Express One Zone). Trước khi so sánh chi tiết kỹ thuật, hãy loại ngay những cái tên không có thật.
• Nguyên tắc chung của Glacier: truy xuất càng nhanh thì càng đắt. Vì vậy khi đề nhấn "urgent", "as fast as possible", "within minutes" thì nghiêng về Expedited; khi đề nhấn "lowest cost", "not time-sensitive" thì nghiêng về các tuỳ chọn chậm hơn.

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

Đề hỏi: dịch vụ AWS nào được thiết kế để dùng cho operational analytics?

Cụm từ quyết định là "operational analytics" — phân tích vận hành. Đây không phải một cách nói chung chung cho "phân tích dữ liệu", mà là một nhóm việc rất cụ thể: theo dõi ứng dụng (application monitoring), phân tích log (log analytics), phân tích luồng click của người dùng (clickstream analytics). Đặc trưng chung của nhóm này là dữ liệu chảy vào liên tục và người vận hành cần tìm kiếm, lọc, tổng hợp gần thời gian thực để biết hệ thống đang chạy ra sao ngay lúc này.

Bốn phương án đều là dịch vụ trong nhóm Analytics của AWS, nên phải phân biệt bằng đúng chữ operational đó, chứ không phải bằng "cái nào phân tích được dữ liệu".

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

A – Amazon Elasticsearch Service là đáp án đúng.

Đây là dịch vụ quản lý cho Elasticsearch, và mảng dùng chính thức của nó đúng là operational analytics: giám sát ứng dụng, phân tích log, phân tích clickstream. Nó cho phép search, explore, filter, aggregate và visualize dữ liệu ở mức gần thời gian thực (near real-time).

Ba từ khoá khớp thẳng vào đề: search (tìm trong khối log khổng lồ), aggregate (đếm số lỗi 5xx theo phút), và near real-time (thấy sự cố khi nó đang xảy ra, chứ không phải báo cáo cuối ngày). Đó chính là điều một đội vận hành cần, và cũng là điều ba dịch vụ còn lại không được thiết kế để làm.

(Lưu ý cho người học: dịch vụ này về sau được đổi tên thành Amazon OpenSearch Service. Đề thi và tài liệu cũ vẫn dùng tên Elasticsearch Service — gặp tên nào cũng hiểu là cùng một dịch vụ.)

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

B – Amazon QuickSight. Đây là dịch vụ business analytics trên nền cloud: dựng biểu đồ và dashboard đẹp, xem được từ trình duyệt hay điện thoại. Phương án này gần đúng ở chỗ nó cũng "visualize" dữ liệu, nên rất dễ chọn nhầm. Chỗ hỏng là đối tượng và mục đích: QuickSight phục vụ người ra quyết định kinh doanh nhìn số liệu tổng hợp, còn nó không phải công cụ tìm kiếm và lọc log để chẩn đoán một sự cố đang diễn ra. QuickSight là tầng trình bày, không phải tầng phân tích vận hành.

C – Amazon Athena. Athena dùng để truy vấn dữ liệu trực tiếp trong S3 và Glacier bằng SQL chuẩn. Nó rất tiện vì không cần dựng máy chủ, nhưng mô hình của nó là ad-hoc query trên dữ liệu đã nằm sẵn trong kho lưu trữ. Với operational analytics, bạn cần tra cứu tương tác trên dòng dữ liệu vừa đổ về, chứ không phải chạy một câu SQL trên dữ liệu đã lưu trữ — sai ở mô hình truy cập dữ liệu, không phải sai ở "không phân tích được".

D – Amazon EMR. EMR là dịch vụ quản lý cho big data processing với Spark và Hadoop, xử lý khối lượng dữ liệu rất lớn. Đây là công cụ mạnh nhất trong bốn phương án về khả năng tính toán, nhưng lại lệch nhất so với đề: nó nghiêng về xử lý theo lô (batch) và các pipeline biến đổi dữ liệu nặng, đòi có cụm máy và có công việc được lập trình sẵn. Không ai mở EMR ra để tra một dòng log lúc hệ thống đang đỏ.

📌 Điểm cần nhớ

• "Operational analytics" = Elasticsearch Service (nay là OpenSearch Service): application monitoring, log analytics, clickstream analytics. Thấy ba cụm này trong đề thì nghĩ ngay tới nó.
• Phân biệt bốn dịch vụ Analytics theo vai trò, không theo "có phân tích được hay không": Elasticsearch Service = tìm kiếm và tổng hợp gần thời gian thực; QuickSight = dashboard cho người dùng nghiệp vụ; Athena = SQL trực tiếp trên S3; EMR = Spark/Hadoop cho xử lý dữ liệu lớn.
• Từ khoá bẫy hay gặp: "visualize" xuất hiện ở cả Elasticsearch Service lẫn QuickSight. Phân biệt bằng chữ đứng cạnh — near real-time, log, search thì chọn Elasticsearch Service; dashboard, business, báo cáo thì chọn QuickSight.
• Với dòng câu hỏi "dịch vụ nào được thiết kế cho X", hãy tìm mục đích thiết kế gốc của dịch vụ, đừng chọn dịch vụ chỉ vì nó có thể làm được X bằng cách vòng vèo.

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

Đề hỏi: theo shared responsibility model, nhiệm vụ bảo mật và tuân thủ nào AWS chịu trách nhiệm?

Cụm từ quyết định đáp án là "AWS is responsible for". Cả bốn phương án đều là việc thật sự phải làm khi vận hành hệ thống trên AWS — không có phương án nào vô nghĩa. Điều duy nhất phân biệt chúng là ai làm: AWS hay khách hàng.

Shared responsibility model chia đôi rất rõ:

• AWS lo "security OF the cloud" — hạ tầng vật lý: nhà máy dữ liệu, phần cứng, mạng, lớp ảo hoá, và firmware của host chạy EC2.
• Khách hàng lo "security IN the cloud" — mọi thứ họ đặt lên trên: guest OS, dữ liệu, quyền truy cập, mã hoá.

Mẹo đọc đề nhanh: hỏi "khách hàng có chạm tay được vào thứ này không?" Chạm được thì đó là việc của khách hàng.

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

A – Updating Amazon EC2 host firmware.

Host firmware là phần mềm nằm trên chính máy chủ vật lý đang chạy hypervisor và cho ra các EC2 instance. Khách hàng không có bất kỳ đường nào để nhìn thấy hay cập nhật lớp này — nó nằm dưới ranh giới ảo hoá, ẩn hoàn toàn khỏi instance. Vì nó thuộc hạ tầng vật lý, nó rơi đúng vào phần "security of the cloud" mà AWS cam kết bảo trì và vá lỗi.

Đây cũng là điểm phân biệt kinh điển mà đề hay khai thác: host (AWS lo) khác guest (khách hàng lo).

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

B – Updating operating systems. Đây là phương án gần đúng nhất và là bẫy chính của câu, vì "cập nhật OS" nghe giống việc bảo trì hạ tầng. Nhưng với EC2, hệ điều hành bên trong instance là guest OS — khách hàng có quyền root/administrator, tự cài phần mềm, tự quyết lịch vá. AWS chỉ phát hành AMI ở trạng thái tại thời điểm dựng; từ lúc instance khởi chạy, mọi bản vá OS là việc của khách hàng. So với A, khác biệt nằm ở đúng một chữ: A nói host firmware, B nói OS chung chung mà trong ngữ cảnh EC2 phải hiểu là guest.

C – Granting access to individuals and services. Cấp quyền cho người dùng và cho service là việc khách hàng làm bằng IAM: tạo user, role, policy, quyết ai được đụng vào tài nguyên nào. AWS cung cấp công cụ IAM (và bảo mật cho chính dịch vụ IAM), nhưng nội dung phân quyền thì AWS không biết và không được phép quyết thay. Đây là ví dụ tiêu biểu của "security in the cloud".

D – Encrypting data in transit. Mã hoá dữ liệu — cả lúc lưu (at rest) lẫn lúc truyền (in transit) — là trách nhiệm khách hàng. AWS cung cấp phương tiện (TLS endpoint, KMS, tuỳ chọn mã hoá trên các dịch vụ lưu trữ), nhưng việc bật chúng lên, chọn khoá, ép client dùng HTTPS là quyết định của khách hàng. Một bucket hay một kết nối để trần thì AWS không tự mã hoá thay.

📌 Điểm cần nhớ

• "Security OF the cloud" = AWS (phần cứng, mạng vật lý, cơ sở hạ tầng, hypervisor, host firmware). "Security IN the cloud" = khách hàng (guest OS, dữ liệu, IAM, mã hoá, cấu hình).
• Với EC2 luôn tách bạch host và guest: hễ đề nhắc tới lớp vật lý/host thì là AWS; hễ nhắc tới thứ bên trong instance thì là khách hàng.
• Dữ liệu và quyền truy cập gần như luôn thuộc về khách hàng — thấy phương án nói về IAM, phân quyền, mã hoá at rest/in transit thì loại khỏi nhóm "AWS chịu trách nhiệm".
• AWS cung cấp công cụ không đồng nghĩa với AWS chịu trách nhiệm sử dụng công cụ đó đúng cách. Đây là chỗ nhiều phương án nhiễu dựa vào.