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

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

Đề hỏi: dịch vụ nào giúp xác định chính xác người dùng nào đã xoá (terminate) một Amazon RDS DB instance.

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

• "identify a specific user" — cần biết ai thực hiện, tức là danh tính người gọi (IAM user/role), địa chỉ IP nguồn, thời điểm.
• "who terminated" — đây là một hành động quản trị trên API của AWS, không phải một chỉ số hiệu năng, không phải một lỗ hổng bảo mật, cũng không phải một khuyến nghị tối ưu.

Ghép lại, đề đang mô tả đúng định nghĩa của một audit log các lời gọi API: ai gọi, gọi cái gì, lúc nào, từ đâu. Bốn phương án đều là dịch vụ giám sát/quản trị của AWS nên trông rất giống nhau; chỉ có ràng buộc "xác định người dùng cụ thể đã thực hiện hành động" mới tách được chúng ra.

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

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

CloudTrail là dịch vụ phục vụ governance, compliance, operational auditing và risk auditing cho tài khoản AWS. Nó ghi lại (log), theo dõi liên tục và lưu giữ hoạt động của tài khoản liên quan đến các hành động trên toàn bộ hạ tầng AWS.

Điểm mấu chốt: CloudTrail cung cấp event history cho hoạt động của tài khoản, bao gồm các hành động thực hiện qua AWS Management Console, AWS SDK, công cụ dòng lệnh (CLI) và các dịch vụ AWS khác. Việc xoá một RDS DB instance — dù bấm nút trên Console hay chạy lệnh CLI — đều là một lời gọi API và vì thế nằm trong event history đó, kèm thông tin về danh tính đã thực hiện lời gọi.

Nhờ vậy CloudTrail đáp ứng đúng cả hai vế của đề: nó cho biết hành động gì đã xảy ra và ai là người thực hiện. Event history này cũng chính là thứ giúp đơn giản hoá phân tích bảo mật, theo dõi thay đổi tài nguyên và khắc phục sự cố, đồng thời phát hiện hoạt động bất thường trong tài khoản.

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

A. Amazon Inspector — Inspector là dịch vụ đánh giá bảo mật tự động cho tài nguyên trên cloud. Nó đi tìm lỗ hổng và vấn đề cấu hình bảo mật của tài nguyên, tức là trả lời câu hỏi "tài nguyên này có điểm yếu nào không". Nó không ghi lại nhật ký ai đã gọi API nào, nên không thể chỉ ra người dùng đã xoá DB instance. Đây là phương án dễ bị chọn nhầm vì chữ "security" khiến người học nghĩ tới điều tra sự cố — nhưng điều tra "ai làm" thuộc về audit log, không thuộc về quét lỗ hổng.

C. AWS Trusted Advisor — Trusted Advisor đưa ra khuyến nghị để xây dựng tài nguyên AWS theo best practice (chi phí, hiệu năng, bảo mật, khả năng chịu lỗi, hạn mức). Nó là công cụ tư vấn hướng tới tương lai: "bạn nên sửa gì". Nó hoàn toàn không phải bản ghi lịch sử hành động, nên không truy được ai đã xoá cái gì trong quá khứ.

D. Amazon CloudWatch — Đây là phương án gần đúng nhất và nguy hiểm nhất, vì CloudWatch cũng là dịch vụ giám sát và cũng lưu trữ log. Nhưng CloudWatch phục vụ giám sát hiệu năng: metric, alarm, dashboard, và log do chính ứng dụng/dịch vụ phát ra. Nó cho bạn biết cái gì đã xảy ra với tài nguyên (CPU tăng vọt, instance biến mất khỏi biểu đồ metric), chứ không cho biết danh tính người gọi API đã gây ra điều đó. Nói ngắn gọn: CloudWatch trả lời "chuyện gì đang xảy ra", CloudTrail trả lời "ai đã làm chuyện đó". Đề hỏi specific user, nên phải là CloudTrail.

📌 Điểm cần nhớ

• Thấy từ khoá "who / which user / audit / API call / thay đổi tài nguyên do ai gây ra" → nghĩ ngay tới AWS CloudTrail. Thấy "performance / metric / alarm / utilization" → Amazon CloudWatch. Đây là cặp đối lập bị hỏi đi hỏi lại trong đề Cloud Practitioner.
• CloudTrail ghi nhận hành động bất kể thực hiện qua Console, CLI, SDK hay dịch vụ AWS khác — nên "người đó bấm tay trên Console" không phải lý do để loại CloudTrail.
• Inspector = đánh giá bảo mật tự động cho tài nguyên; Trusted Advisor = khuyến nghị theo best practice. Cả hai đều mang màu "bảo mật/quản trị" nhưng không có chức năng nhật ký hành động, nên luôn bị loại ở dạng câu hỏi truy vết.
• Mẹo phân loại nhanh nhóm dịch vụ quản trị: CloudTrail nhìn về quá khứ và nhìn vào con người, CloudWatch nhìn vào trạng thái tài nguyên, Trusted Advisor nhìn về tương lai và đưa lời khuyên, Inspector nhìn vào điểm yếu của tài nguyên.

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

Đề hỏi: một công ty dự định chuyển việc phát triển ứng dụng lên AWS, họ đạt được lợi ích gì khi phát triển và chạy ứng dụng trên AWS Cloud so với on-premises? Chọn HAI.

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

• "benefits ... compared to on-premises" — đề đang hỏi về lợi ích của mô hình cloud (đúng nghĩa các advantages of cloud computing), chứ không hỏi AWS làm hộ khách hàng những việc gì.
• "developing and running applications" — chủ thể của ứng dụng vẫn là công ty. Đây chính là ranh giới shared responsibility model: AWS chịu trách nhiệm security of the cloud (hạ tầng vật lý, ảo hoá, hạ tầng toàn cầu), còn khách hàng chịu trách nhiệm security in the cloud (ứng dụng, dữ liệu, cấu hình, bản vá trong OS/ứng dụng của mình).

Ba phương án sai đều rơi vào cùng một cái bẫy: chúng mô tả AWS như một bên làm thay toàn bộ, hoặc mô tả một hành vi tự động xảy ra mà không cần cấu hình. Cả hai kiểu phát biểu đó đều vượt quá những gì AWS thực sự cam kết.

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

C — "AWS can accommodate large changes in application demand." Hạ tầng toàn cầu của AWS có quy mô và lượng năng lực dư rất lớn, nên khi nhu cầu ứng dụng tăng vọt hay giảm mạnh, bạn vẫn xin thêm hoặc trả lại tài nguyên được — thường là gần như trong suốt đối với ứng dụng. Đây chính là elasticity, một trong những lợi ích cốt lõi mà on-premises không có: ở trung tâm dữ liệu riêng, bạn phải mua sắm phần cứng trước, chờ hàng, lắp đặt, và hoặc là mua dư (lãng phí) hoặc mua thiếu (nghẽn khi tải cao).

E — "AWS makes it easy to implement high availability." AWS cung cấp sẵn nhiều lựa chọn để dựng kiến trúc sẵn sàng cao: nhiều Availability Zone trong một Region, nhiều Region trên khắp thế giới, cùng các dịch vụ lưu trữ bền, message bus và database được thiết kế cho tính sẵn sàng. Trên on-premises, muốn có mức dự phòng tương đương thì phải tự xây thêm site thứ hai và tự lo đường truyền, điện, làm mát — rất đắt và rất chậm.

Chú ý cách diễn đạt của cả hai đáp án đúng: chúng nói AWS giúp bạn làm dễ hơn / có thể đáp ứng được, chứ không nói AWS tự làm thay bạn. Đó là dấu hiệu nhận biết đáp án đúng trong nhóm câu hỏi kiểu này.

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

A — "AWS automatically replicates all data globally." Sai ở chữ "automatically" và "globally". Dữ liệu không tự nhân bản ra phạm vi toàn cầu; bạn phải tự cấu hình thì mới có (ví dụ bật sao chép giữa các Region cho dịch vụ hỗ trợ). Đây là phương án gần đúng nhất trong ba phương án sai, vì AWS thật sự có cơ chế bền dữ liệu — nhưng độ bền trong phạm vi một Region khác hẳn với "tự động sao chép mọi dữ liệu ra toàn cầu". Phát biểu này còn nguy hiểm về mặt vận hành: tin vào nó là bạn sẽ không dựng chiến lược sao lưu/khôi phục nào cả.

B — "AWS takes care of application security patching." Nửa đúng nửa sai, và phần sai là phần quan trọng. Theo shared responsibility model, AWS lo bản vá cho hạ tầng bên dưới — phần cứng, mạng, lớp ảo hoá, và phần mềm của các dịch vụ managed mà AWS vận hành. Nhưng ứng dụng của bạn thì AWS không vá: mã nguồn, thư viện phụ thuộc, framework, và cả hệ điều hành khách trên EC2 đều thuộc trách nhiệm của khách hàng. Đề nói rõ công ty đang "developing applications" — chính phần AWS không đụng tới.

D — "AWS will fully manage the entire application." Sai rõ ràng nhất. AWS cung cấp hạ tầng và dịch vụ nền tảng, nhưng không quản lý ứng dụng của bạn. Ngay cả với các dịch vụ managed nhất, AWS vận hành dịch vụ, còn logic nghiệp vụ, dữ liệu và cấu hình vẫn là việc của bạn. Chữ "fully" và "entire" là dấu hiệu loại bỏ.

📌 Điểm cần nhớ

• Ranh giới shared responsibility là chìa khoá của cả nhóm câu này: AWS lo security of the cloud, khách hàng lo security in the cloud — bao gồm ứng dụng, dữ liệu và bản vá bên trong ứng dụng/OS khách.
• Cảnh giác với các từ tuyệt đối trong phương án: "automatically", "all", "globally", "fully", "entire". Ở đề Cloud Practitioner, chúng gần như luôn báo hiệu phương án sai vì AWS hiếm khi cam kết kiểu bao trọn.
• Lợi ích của cloud so với on-premises thường được diễn đạt là "AWS giúp bạn làm được / làm dễ hơn" (elasticity, high availability, hạ tầng toàn cầu), chứ không phải "AWS làm thay bạn".
• High availability và elasticity là hai lợi ích khác nhau, đừng gộp: HA nói về chịu lỗi (nhiều AZ, nhiều Region), elasticity nói về co giãn theo tải. Câu này chọn cả hai vì đề hỏi lợi ích chung, nhưng nhiều câu khác chỉ hỏi đúng một trong hai.

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

Đề hỏi: lợi ích nào của AWS cho phép doanh nghiệp thay chi phí cố định trả trước (upfront fixed expenses) bằng chi phí biến đổi (variable expenses) khi dùng dịch vụ công nghệ theo nhu cầu.

Cụm từ quyết định đáp án là "replace upfront fixed expenses with variable expenses" — nguyên văn một trong sáu lợi thế của điện toán đám mây mà AWS công bố: "Trade capital expense for variable expense". Cụm "on-demand technology services" là gợi ý thứ hai: chỉ trả tiền khi thực sự tiêu thụ tài nguyên.

Câu này thuộc kiểu "ánh xạ một mô tả về đúng tên gọi lợi thế". Bốn phương án đều là lợi ích có thật của AWS, nhưng chỉ một phương án nói về cách trả tiền; ba phương án còn lại nói về độ sẵn sàng, phạm vi địa lý và quy mô. Hễ thấy đề nhắc tới chuyển đổi CapEx → OpEx, hãy tìm phương án mô tả mô hình thanh toán.

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

B — Pay-as-you-go pricing.

Trong mô hình truyền thống, doanh nghiệp phải bỏ vốn lớn mua máy chủ và xây data center trước khi biết mình sẽ dùng bao nhiêu — đó chính là chi phí cố định trả trước. Với AWS, bạn chỉ trả tiền khi tiêu thụ tài nguyên và chỉ trả đúng phần đã tiêu thụ. Chi phí vì thế đi theo mức sử dụng thực tế, tức là biến đổi theo nhu cầu chứ không còn là khoản đầu tư cố định nằm ngoài tầm kiểm soát.

Đây đúng là biểu hiện của lợi thế "Trade capital expense for variable expense" trong tài liệu Six Advantages of Cloud Computing của AWS. Cụm từ trong đề gần như dịch thẳng từ tên lợi thế này, nên ánh xạ là một–một.

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

A — High availability. Nói về việc thiết kế ứng dụng để duy trì hoạt động với thời gian gián đoạn tối thiểu ngay cả khi có sự cố. Đây là thuộc tính về độ tin cậy của kiến trúc, hoàn toàn không liên quan tới cách tính tiền. Chọn phương án này là nhầm giữa "hệ thống chạy ổn định" và "chi phí trả theo mức dùng".

C — Global reach. Gắn với lợi thế "Go global in minutes": triển khai ứng dụng ra nhiều Region trên thế giới rất nhanh, nhờ đó giảm độ trễ cho người dùng ở xa. Phương án này có chạm tới yếu tố chi phí ("với chi phí tối thiểu"), nhưng bản chất nó nói về phạm vi địa lý và trải nghiệm người dùng, không phải về việc chuyển chi phí cố định thành chi phí biến đổi.

D — Economies of scale. Đây là phương án gây nhiễu mạnh nhất, vì nó đúng là một lợi thế về chi phí. Chỗ nó hỏng: economies of scale nói về việc đơn giá biến đổi rẻ hơn so với tự làm — do AWS gộp nhu cầu của hàng trăm nghìn khách hàng nên đạt được quy mô lớn hơn, và phần tiết kiệm đó chuyển thành giá pay-as-you-go thấp hơn. Nghĩa là nó tác động lên mức giá, còn đề hỏi về hình thái chi phí (cố định trả trước → biến đổi). Hai thứ này liên quan nhưng khác nhau: economies of scale làm chi phí biến đổi rẻ đi, chứ không phải thứ biến chi phí cố định thành chi phí biến đổi.

📌 Điểm cần nhớ

• Sáu lợi thế của cloud là bộ câu hỏi ruột của kỳ thi Cloud Practitioner. Nên thuộc cách ánh xạ: trade capital expense for variable expense → pay-as-you-go; go global in minutes → global reach; benefit from massive economies of scale → giá biến đổi thấp hơn tự làm.
• Phân biệt rõ hình thái chi phí và mức giá: pay-as-you-go trả lời câu hỏi "trả tiền theo kiểu gì", economies of scale trả lời "trả bao nhiêu cho mỗi đơn vị".
• Khi đề nhắc "upfront", "capital expense", "CapEx", "on-demand" — hãy tìm phương án nói về mô hình thanh toán, không chọn các lợi ích kỹ thuật như high availability.
• Trong nhóm phương án cùng là lợi ích có thật, phương án đúng là phương án khớp với đúng khía cạnh mà đề nêu, không phải phương án "nghe có lợi nhất".

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

Đề mô tả một công ty cần một dashboard để báo cáo (dashboard for reporting) khi dùng giải pháp business intelligence (BI). Câu hỏi là dịch vụ AWS nào phục vụ được nhu cầu đó.

Cụm từ quyết định là "dashboard for reporting" đi kèm "business intelligence solution". Cả bốn phương án đều nằm trong nhóm phân tích dữ liệu của AWS, nhưng chỉ một trong số đó là công cụ trình bày dữ liệu ra biểu đồ, bảng báo cáo cho người xem. Ba phương án còn lại làm những khâu khác của chuỗi dữ liệu: thu thập, lưu trữ, truy vấn. Khi đề hỏi thẳng về BI dashboard, thứ cần tìm là lớp trực quan hoá cuối cùng, không phải lớp dữ liệu bên dưới.

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

B. Amazon QuickSight — đây chính là dịch vụ business intelligence của AWS. QuickSight cho phép tạo và xuất bản các BI dashboard tương tác: biểu đồ, bảng, bộ lọc, và các insight do machine learning sinh ra. Dashboard của QuickSight xem được từ nhiều loại thiết bị và có thể nhúng (embed) vào ứng dụng, cổng thông tin hay website của công ty.

QuickSight là dịch vụ serverless — người dùng không phải dựng máy chủ báo cáo, không phải cài phần mềm BI, chỉ kết nối tới nguồn dữ liệu rồi dựng dashboard. Với một câu hỏi ở mức Cloud Practitioner, ánh xạ cần nhớ rất thẳng: "business intelligence" và "dashboard" trên AWS → Amazon QuickSight.

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

A. Amazon Athena — dịch vụ chạy truy vấn SQL trực tiếp trên dữ liệu nằm trong Amazon S3, không cần nạp dữ liệu vào cơ sở dữ liệu trước. Đây là phương án dễ nhầm nhất vì Athena đúng là công cụ phân tích và có giao diện chạy query trả về kết quả dạng bảng. Nhưng kết quả truy vấn không phải là dashboard: Athena không dựng biểu đồ, không có bộ lọc tương tác, không xuất bản báo cáo cho người dùng nghiệp vụ xem. Nó là lớp truy vấn, còn đề hỏi lớp trình bày.

C. Amazon Kinesis — dịch vụ dùng để thu thập và xử lý dữ liệu streaming (luồng dữ liệu liên tục theo thời gian thực: log, telemetry, click-stream). Nó nằm ở đầu vào của chuỗi dữ liệu, lo việc đưa dữ liệu vào hệ thống. Kinesis hoàn toàn không có chức năng tạo báo cáo hay dashboard BI cho người dùng cuối, nên lệch hẳn khỏi yêu cầu của đề.

D. Amazon Redshift — đây là phương án gần đúng thứ hai và cũng hay gây nhầm, vì Redshift là data warehouse, mà kho dữ liệu vốn gắn liền với hoạt động BI trong các kiến trúc truyền thống. Chỗ hỏng nằm ở vai trò: Redshift lưu trữ và truy vấn dữ liệu quy mô lớn, nó là nguồn dữ liệu, chứ bản thân không phải là dashboard. Trên thực tế hai dịch vụ này thường đi cùng nhau — QuickSight kết nối tới Redshift để vẽ dashboard trên dữ liệu trong kho. Nhưng đề chỉ hỏi thành phần tạo ra dashboard, nên câu trả lời phải là QuickSight.

📌 Điểm cần nhớ

• Bắt từ khoá theo cặp: "business intelligence" / "dashboard" / "report/visualization" → Amazon QuickSight. Đây là ánh xạ cố định, xuất hiện rất nhiều trong đề Cloud Practitioner.
• Phân biệt các dịch vụ theo vị trí trong chuỗi dữ liệu: Kinesis thu thập (ingest streaming) → S3/Redshift lưu trữ → Athena/Redshift truy vấn → QuickSight trình bày. Đề hỏi khâu nào thì chọn dịch vụ của khâu đó.
• Athena vs Redshift: Athena chạy SQL trên dữ liệu trong S3 và không cần hạ tầng cố định; Redshift là data warehouse để lưu và phân tích dữ liệu quy mô lớn. Cả hai đều trả kết quả truy vấn, không trả dashboard.
• Việc các dịch vụ kết hợp được với nhau (QuickSight đọc dữ liệu từ Redshift, từ Athena) không biến chúng thành cùng một chức năng — với câu trắc nghiệm, luôn chọn dịch vụ trực tiếp đảm nhiệm yêu cầu mà đề nêu.

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

Đề hỏi: dịch vụ AWS-managed nào dùng để xử lý khối lượng dữ liệu rất lớn bằng một hosted Hadoop framework.

Cụm từ quyết định đáp án là "hosted Hadoop framework". Đây không phải câu hỏi chung chung kiểu "dịch vụ nào phân tích dữ liệu lớn" — nếu vậy thì Athena và Redshift đều cãi được. Đề chỉ đích danh một framework cụ thể: Hadoop. Chỉ có đúng một dịch vụ trong danh sách là bản Hadoop được AWS dựng sẵn và vận hành hộ; ba dịch vụ còn lại đều là engine riêng của AWS, không phải Hadoop.

Cụm thứ hai đáng chú ý là "process" (xử lý) chứ không phải "query" (truy vấn) hay "store" (lưu trữ). "Process vast amounts of data" gợi tới xử lý theo cụm máy tính phân tán, tức là các job chạy trên nhiều node — đúng mô hình của Hadoop/MapReduce, khác với việc chạy một câu SQL lên dữ liệu có sẵn.

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

C. Amazon EMR (Elastic MapReduce) là dịch vụ web cho phép doanh nghiệp, nhà nghiên cứu, chuyên viên phân tích và lập trình viên xử lý lượng dữ liệu rất lớn một cách dễ dàng và tiết kiệm chi phí. Điểm mấu chốt: EMR chạy một hosted Hadoop framework trên nền Amazon EC2 và Amazon S3 — EC2 làm các node tính toán trong cluster, S3 làm nơi chứa dữ liệu vào/ra.

"AWS-managed" ở đây có nghĩa là AWS lo phần dựng cluster, cài đặt và cấu hình framework, còn người dùng chỉ việc nộp job. Đó chính xác là điều đề bài mô tả: một Hadoop framework được host sẵn, dùng để process vast amounts of data.

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

A. Amazon Athena — Đây là phương án gần đúng nhất về mặt "phân tích dữ liệu lớn", và nhiều người chọn nhầm vì Athena cũng làm việc với dữ liệu trên S3 ở quy mô lớn. Nhưng Athena là dịch vụ truy vấn tương tác, serverless, dùng standard SQL để query và phân tích dữ liệu nằm trong Amazon S3. Nó hỏng ở đúng chỗ đề hỏi: người dùng không hề nhận được một Hadoop cluster nào, không có node nào để nhìn thấy, và giao diện làm việc là câu SQL chứ không phải job trên Hadoop framework. Đề hỏi "hosted Hadoop framework", Athena không phải thứ đó.

B. Amazon Redshift — Cũng là một phương án dễ nhầm vì Redshift xử lý được lượng dữ liệu rất lớn. Nhưng Redshift là dịch vụ data warehousing nhanh, đơn giản, tiết kiệm chi phí. Nó hỏng ở hai điểm: bản chất là kho dữ liệu để chạy phân tích/báo cáo bằng SQL trên dữ liệu đã được nạp vào và cấu trúc hóa, chứ không phải nền tảng chạy Hadoop job; và đề bài không hề nhắc tới data warehouse hay nhu cầu báo cáo BI. Chọn Redshift là đọc lướt qua chữ "vast amounts of data" mà bỏ mất chữ "Hadoop".

D. Amazon DynamoDB — Sai rõ ràng nhất trong bốn phương án. DynamoDB không phải hosted Hadoop framework, nó là một cơ sở dữ liệu NoSQL. Vai trò của nó là lưu và truy xuất bản ghi theo khóa với độ trễ thấp, tức là thuộc nhóm lưu trữ dữ liệu, không thuộc nhóm xử lý/phân tích dữ liệu lớn mà đề đang hỏi. Không có chi tiết nào trong đề trỏ tới nó.

📌 Điểm cần nhớ

• Thấy từ khóa Hadoop, MapReduce, Spark, cluster xử lý dữ liệu lớn trong đề thi AWS → nghĩ ngay tới Amazon EMR. Đây là mối liên kết một-một mà đề Cloud Practitioner hay dùng.
• Phân biệt theo cách làm việc, không chỉ theo quy mô dữ liệu: EMR = framework xử lý phân tán (Hadoop) trên cluster EC2 + S3; Athena = query SQL serverless trực tiếp trên S3; Redshift = data warehouse.
• DynamoDB thuộc nhóm cơ sở dữ liệu NoSQL — nó trả lời cho câu hỏi "lưu ở đâu", không trả lời cho câu hỏi "xử lý bằng gì".
• Khi nhiều phương án cùng "xử lý được dữ liệu lớn", hãy tìm danh từ riêng kỹ thuật trong đề (ở đây là Hadoop). Danh từ riêng gần như luôn là cái chốt phân biệt, còn các tính từ chung chung như "vast", "fast", "cost-effective" thì phương án nào cũng khớp được.

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

Đề bài đặt ra một tình huống rất cụ thể: cần chuyển 70 TB dữ liệu từ data center on-premises lên AWS Cloud, trong hoàn cảnh "slow and unreliable internet connection" — đường truyền Internet vừa chậm vừa không ổn định.

Cụm từ quyết định đáp án chính là "slow and unreliable internet connection" đi kèm với khối lượng 70 TB. Đây là ràng buộc phân biệt: nó loại bỏ mọi phương án truyền dữ liệu qua đường mạng, bất kể phương án đó có tối ưu băng thông tốt đến đâu. Nếu đề chỉ nói "70 TB" mà không nhắc tới chất lượng đường truyền, thì một dịch vụ đồng bộ qua mạng vẫn có thể là câu trả lời hợp lý. Chính vế "chậm và không tin cậy" mới buộc ta phải chọn hướng vận chuyển vật lý (offline transfer) thay vì truyền online.

Ngoài ra, con số 70 TB còn dùng để chọn đúng thiết bị trong họ sản phẩm vận chuyển vật lý — một thiết bị Snowball Edge có dung lượng đủ để chứa trọn khối dữ liệu này trong một lần, không cần chia nhỏ.

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

Đáp án đúng: A — AWS Snowball.

AWS Snowball là phương thức chuyển dữ liệu bằng thiết bị vật lý: AWS gửi thiết bị tới data center của khách hàng, khách hàng chép dữ liệu vào thiết bị, rồi gửi trả về AWS để nạp vào S3. Toàn bộ quá trình di chuyển khối dữ liệu diễn ra ngoài đường Internet, nên chất lượng đường truyền không còn là vấn đề — đúng với ràng buộc "slow and unreliable" trong đề.

Về dung lượng, một thiết bị Snowball Edge chứa được tới khoảng 80 TB, tức là một thiết bị duy nhất đủ cho 70 TB của công ty, không cần ghép nhiều thiết bị hay chia nhiều đợt.

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

B — Amazon S3 Glacier. Đây là lớp lưu trữ lưu trữ dài hạn (archive) trên S3, dùng để cất dữ liệu ít truy cập với chi phí thấp. Nó trả lời câu hỏi "cất dữ liệu ở đâu sau khi đã lên cloud", chứ không trả lời câu hỏi "làm sao đưa 70 TB từ on-premises lên cloud". Glacier hoàn toàn không phải là một phương tiện vận chuyển dữ liệu.

C — AWS DataSync. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. DataSync đúng là dịch vụ chuyên dùng để di chuyển dữ liệu từ on-premises lên AWS, tự động hóa và tăng tốc quá trình copy tốt hơn nhiều so với script thủ công. Nhưng chỗ nó hỏng nằm đúng ở ràng buộc của đề: DataSync truyền dữ liệu qua đường mạng. Đường truyền đã chậm và không tin cậy thì DataSync cũng không thể tạo ra băng thông mà công ty không có. Nó tối ưu việc dùng đường truyền, chứ không thay thế được đường truyền.

D — AWS Storage Gateway. Storage Gateway là dịch vụ kết nối hệ thống lưu trữ on-premises với storage trên cloud theo dạng hybrid — máy chủ tại chỗ vẫn dùng giao thức lưu trữ quen thuộc (file, volume, tape) trong khi dữ liệu được đẩy dần lên AWS. Đây là mô hình lưu trữ lai chạy lâu dài, và cũng vẫn phụ thuộc vào kết nối mạng. Nó không phải công cụ cho một đợt di chuyển khối lượng lớn một lần qua đường truyền yếu.

📌 Điểm cần nhớ

• Trong đề thi AWS, hễ xuất hiện cặp tín hiệu "khối lượng dữ liệu rất lớn" + "đường truyền chậm/không ổn định/băng thông hạn chế" thì gần như chắc chắn đáp án thuộc họ Snow (vận chuyển vật lý), không phải dịch vụ truyền qua mạng.
• Phân biệt rõ ba nhóm dễ lẫn: DataSync = truyền qua mạng có tối ưu; Storage Gateway = kết nối lưu trữ hybrid lâu dài qua mạng; Snowball = vận chuyển vật lý, không dùng Internet cho khối dữ liệu.
• S3 Glacier là nơi chứa dữ liệu, không phải cách chuyển dữ liệu. Câu hỏi dạng "which service to transfer" thì mọi phương án là lớp lưu trữ đều có thể loại ngay.
• Khi chọn thiết bị trong họ Snow, hãy đối chiếu dung lượng đề bài đưa ra với sức chứa từng loại: Snowcone dành cho khối dữ liệu nhỏ (cỡ vài TB), còn Snowball Edge dành cho khối vài chục TB như trường hợp 70 TB này.

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

Đề mô tả một tập đoàn có nhiều phòng ban, mỗi phòng ban dùng AWS account riêng, và muốn "customize billing data" cho khớp logic showback/chargeback nội bộ. Nhưng cụm từ quyết định nằm ở câu tiếp theo:

"group accounts with similar financial owners and generate a distinct Cost and Usage Report (CUR) for each group"

Hai yêu cầu này đi cùng nhau và chính là ranh giới phân biệt bốn phương án:

1. Gom account thành nhóm theo chủ sở hữu tài chính (billing group).
2. Sinh ra một CUR riêng cho từng nhóm — tức là tạo dữ liệu hoá đơn mới, chứ không phải xem/lọc/vẽ biểu đồ trên dữ liệu chi phí có sẵn.

Ba phương án còn lại đều là công cụ quan sát và kiểm soát chi phí: chúng đọc dữ liệu billing thật của AWS Organization và trình bày lại. Chỉ một dịch vụ trong danh sách có khả năng dựng lại dữ liệu billing theo logic riêng của doanh nghiệp rồi xuất thành CUR độc lập.

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

C — AWS Billing Conductor. Đây là dịch vụ billing tuỳ biến, sinh ra đúng cho tình huống showback/chargeback của tổ chức nhiều account. Nó cho phép:

• Định nghĩa billing group: gom các AWS account thuộc cùng một chủ sở hữu tài chính vào một nhóm.
• Đặt pricing rule riêng cho từng nhóm (ví dụ áp mức giá hoặc tỷ lệ khác với giá AWS tính thật) — đây chính là chỗ "customize billing data to match their specific business logic".
• Thêm custom line item để cộng/trừ những khoản mà hoá đơn AWS gốc không có (chi phí nội bộ, phân bổ dùng chung...).
• Và quan trọng nhất với đề bài: mỗi billing group có một Cost and Usage Report riêng, phản ánh dữ liệu đã được tuỳ biến của nhóm đó.

Điểm cần nắm về bản chất: Billing Conductor không thay đổi số tiền AWS thật sự thu của payer account. Nó tạo ra một "phiên bản hoá đơn thứ hai" theo góc nhìn nội bộ, để phòng tài chính dùng khi tính tiền lại cho các phòng ban. Đó chính xác là định nghĩa của showback/chargeback.

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

A — AWS Billing and Cost Management. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì Billing Conductor về mặt tổ chức nằm trong họ AWS Cost Management. Nhưng bản thân AWS Billing and Cost Management là bảng điều khiển chung để theo dõi mức sử dụng và hoá đơn, xem invoice, quản lý phương thức thanh toán, bật CUR. Nó cho bạn xem hoá đơn AWS đã tính, chứ không cung cấp cơ chế định nghĩa billing group với pricing rule riêng rồi sinh nhiều CUR song song. Chọn A tức là dừng lại ở mức "công cụ billing chung chung" mà bỏ qua ràng buộc distinct CUR for each group.

B — AWS Budgets. Sai vì Budgets là công cụ đặt ngưỡng và cảnh báo: bạn khai một mức chi phí hoặc mức sử dụng mục tiêu, khi thực tế vượt qua (hoặc dự báo sẽ vượt qua) thì nó bắn thông báo. Nó có thể lọc theo account, tag hay dịch vụ để đặt ngưỡng riêng cho từng phòng ban, và đó là lý do nó trông có vẻ liên quan. Nhưng Budgets không tạo ra dữ liệu hoá đơn tuỳ biến và không sinh CUR — nó chỉ nói "đã tiêu quá mức", không nói "phòng ban này phải trả bao nhiêu theo giá nội bộ".

D — AWS Cost Explorer. Sai vì Cost Explorer là công cụ trực quan hoá và phân tích chi phí theo thời gian: vẽ biểu đồ, nhóm theo dịch vụ/account/tag, xem xu hướng, dự báo. Nó cũng có khả năng "gom nhóm" nhưng chỉ là gom để hiển thị trong báo cáo phân tích, không phải gom thành đơn vị tính tiền có pricing rule riêng. Cost Explorer đọc dữ liệu chi phí gốc chứ không sửa nó, và không xuất ra một CUR riêng cho từng nhóm như đề yêu cầu.

📌 Điểm cần nhớ

• Thấy "showback / chargeback" kèm "billing group" hoặc "CUR riêng cho từng nhóm" trong đề AWS → nghĩ ngay tới AWS Billing Conductor. Đây gần như là chữ ký nhận dạng của dịch vụ này.
• Phân biệt theo động từ của yêu cầu: xem/phân tích chi phí → Cost Explorer; cảnh báo khi vượt ngưỡng → AWS Budgets; xem hoá đơn và quản lý thanh toán → Billing and Cost Management; tạo lại dữ liệu billing theo logic riêng → Billing Conductor.
• Billing Conductor tạo ra hoá đơn nội bộ để phân bổ chi phí, không làm thay đổi số tiền AWS thực tế tính cho payer account — nhớ điều này để không chọn nhầm khi đề nói về "giảm hoá đơn thật".
• Khi hai phương án cùng thuộc một họ dịch vụ (Billing and Cost Management vs Billing Conductor), hãy bám vào ràng buộc cụ thể nhất trong đề — ở đây là "distinct CUR for each group" — thay vì chọn cái tên nghe bao quát hơn.

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

Đề mô tả một tech startup mới thành lập đang tìm một program của AWS cung cấp gói gồm: AWS credits, training, technical support và các nguồn lực khác để giúp họ xây dựng doanh nghiệp của mình.

Cụm từ quyết định đáp án là "newly founded tech startup" kết hợp với "AWS credits". Cả bốn phương án đều là những chương trình/nền tảng có thật của AWS, nhưng chỉ có một chương trình vừa nhắm đúng đối tượng startup, vừa cấp credits. Hai chi tiết này khoá chặt đáp án: đối tượng thụ hưởng (startup, không phải sinh viên, không phải đối tác) và hình thức hỗ trợ (credits + training + technical support gói chung).

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

C — AWS Activate for Startups.

Đây là chương trình AWS dựng riêng cho các startup ở giai đoạn đầu, nhằm cho họ hạ tầng chi phí thấp, dễ dùng để phát triển và mở rộng. Gói quyền lợi của chương trình đúng bằng danh sách mà đề bài liệt kê: AWS credits để bù chi phí hạ tầng lúc chưa có doanh thu, training để đội kỹ thuật non trẻ học nhanh, technical support để gỡ vướng khi kiến trúc còn đang định hình, cùng các nguồn lực khác đi kèm. Đề bài gần như đọc thẳng từ mô tả chương trình, nên không cần suy diễn thêm.

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

A — AWS Partner Network. Đây là phương án gần đúng nhất và dễ bẫy, vì APN cũng có credits, training, hỗ trợ kỹ thuật và cả hỗ trợ marketing/go-to-market. Chỗ nó hỏng nằm ở đối tượng: APN dành cho các partner — công ty xây dựng giải pháp hoặc dịch vụ dựa trên AWS để bán lại cho khách hàng khác, tức là hợp tác kinh doanh với AWS. Một startup mới thành lập chỉ đang muốn dựng sản phẩm của chính mình thì chưa nằm trong nhóm đó; APN phù hợp với doanh nghiệp đã có sản phẩm và có mô hình đối tác rõ ràng hơn.

B — AWS Educate. Cũng có yếu tố training và tài nguyên học tập, nên nhìn qua thì khớp một phần đề bài. Nhưng nó nhắm vào khối giáo dục — sinh viên và giảng viên — để tăng tốc việc học về cloud, chứ không phải để một công ty vận hành workload production. Đề bài nói rõ mục tiêu là "help them build their business", đây là ngữ cảnh kinh doanh chứ không phải học tập.

C là đáp án đúng, đã giải thích ở trên.

D — AWS Marketplace. Đây không phải một program hỗ trợ mà là một danh mục số để khách hàng tìm, mua, triển khai và quản lý phần mềm, dịch vụ và dữ liệu của bên thứ ba. Một startup hoàn toàn có thể dùng Marketplace như một nguồn lực hữu ích, nhưng bản chất nó là kênh mua bán phần mềm — nó không cấp credits, không cấp training, không cấp technical support theo kiểu chương trình bảo trợ. Sai ngay ở loại hình, không chỉ sai ở đối tượng.

📌 Điểm cần nhớ

• Câu hỏi về AWS program thì hãy phân loại theo đối tượng thụ hưởng trước tiên: Activate → startup, Educate → sinh viên và giảng viên, Partner Network → đối tác xây dựng và bán giải pháp trên AWS.
• Từ khoá "AWS credits" đi cùng "startup" gần như luôn trỏ về AWS Activate for Startups.
• AWS Marketplace không phải chương trình hỗ trợ — nó là danh mục mua bán phần mềm của bên thứ ba. Gặp nó trong danh sách phương án của câu hỏi về "program offering credits/training/support" thì loại được ngay.
• Nhiều phương án cùng có "training" và "support"; điều phân biệt chúng là ai được nhận và nhận để làm gì, chứ không phải danh sách quyền lợi.

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

Đề hỏi: dịch vụ AWS nào dùng để nạp dữ liệu từ Amazon S3, biến đổi (transform) nó, rồi chuyển sang một đích khác.

Cụm từ quyết định là "load data … transform it … move it to another destination" — đó chính là định nghĩa nguyên văn của một quy trình ETL (Extract, Transform, Load). Đề không hỏi "phân tích dữ liệu", không hỏi "lưu trữ để chạy truy vấn SQL", cũng không hỏi "xử lý dữ liệu thời gian thực". Nó mô tả một đường ống di chuyển và biến đổi dữ liệu giữa các kho.

Điểm bẫy: cả bốn phương án đều thuộc nhóm AWS Analytics và đều có thể đọc dữ liệu từ S3. Vì vậy "đọc được S3" không phân biệt được gì cả. Thứ phân biệt là vai trò chính của mỗi dịch vụ trong kiến trúc dữ liệu: kho dữ liệu (warehouse), khung xử lý phân tán, luồng thời gian thực, hay dịch vụ ETL.

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

D — AWS Glue.

AWS Glue là dịch vụ ETL được quản lý của AWS, sinh ra đúng để làm việc mà đề mô tả: lấy dữ liệu từ nguồn (Amazon S3, Amazon RedShift, các cơ sở dữ liệu khác), áp dụng bước biến đổi, rồi ghi kết quả sang đích khác. Nó chuẩn bị và nạp dữ liệu cho mục đích phân tích.

Ba từ khoá của đề — load, transform, move to another destination — ánh xạ một–một vào ba chữ E–T–L. Khi đề bài của kỳ thi Cloud Practitioner đọc như một định nghĩa sách giáo khoa của ETL, câu trả lời hầu như luôn là AWS Glue.

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

A — Amazon RedShift. Đây là data warehouse, tức là đích đến của dữ liệu chứ không phải công cụ vận chuyển và biến đổi. Bạn nạp dữ liệu vào RedShift từ các nguồn khác (ví dụ cơ sở dữ liệu SQL giao dịch) rồi chạy phân tích trên đó bằng SQL và công cụ Business Intelligence. Đây là phương án gần đúng nhất về mặt "có dính tới nạp dữ liệu", nhưng nó hỏng ở chỗ: RedShift là nơi dữ liệu dừng lại để được truy vấn, không phải dịch vụ có nhiệm vụ đẩy dữ liệu tới một đích khác. Đề nói rõ "move it to another destination" — RedShift chính là destination.

B — Amazon Kinesis. Dùng cho dữ liệu luồng thời gian thực (real-time streaming): thu thập, xử lý và phân tích dữ liệu ngay khi nó phát sinh. Đề bài không có bất kỳ dấu hiệu nào của streaming — không nói "real-time", "liên tục", "sự kiện đang chảy tới". Nguồn dữ liệu ở đây là S3, tức dữ liệu đã nằm yên trong kho (dữ liệu at-rest), đúng địa hạt của xử lý theo lô chứ không phải luồng.

C — Amazon EMR. Là khung Hadoop được quản lý chạy trên EC2 và S3, dùng để phân tích dữ liệu quy mô lớn. Đây cũng là phương án dễ nhầm, vì EMR đọc S3 và về mặt kỹ thuật người ta có thể viết job biến đổi dữ liệu trên đó. Nhưng theo cách phân loại mà kỳ thi dùng: EMR định vị là công cụ analyzing data, không phải dịch vụ ETL, và nó đòi bạn quản lý cụm cùng framework xử lý. Khi trong danh sách đã có một dịch vụ ETL đúng nghĩa và được quản lý hoàn toàn (Glue), thì Glue mới là câu trả lời được mong đợi.

📌 Điểm cần nhớ

• Thấy ba động từ extract / transform / load (hoặc "lấy dữ liệu từ X, biến đổi, đưa sang Y") trong đề → nghĩ ngay AWS Glue.
• Phân biệt theo vai trò trong kiến trúc, đừng phân biệt theo "có đọc được S3 không": Glue = ETL (đường ống), RedShift = data warehouse (đích để truy vấn SQL/BI), EMR = khung Hadoop để phân tích, Kinesis = dữ liệu luồng thời gian thực.
• Real-time / streaming → Kinesis; dữ liệu đã nằm sẵn trong S3 và xử lý theo lô → Glue. Chỉ cần dò xem đề có chữ "real-time" hay không là loại được một phương án.
• "Move it to another destination" là dấu hiệu loại bỏ các dịch vụ vốn đóng vai điểm cuối của dữ liệu (như RedShift) — dịch vụ đúng phải là thứ đứng giữa nguồn và đích.

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

Đề hỏi: dịch vụ AWS nào dùng để thiết lập kết nối mạng an toàn giữa mạng on-premises và AWS.

Cụm từ quyết định đáp án là "establish a secure network connection between an on-premises network and AWS" — gồm hai phần phải thoả cùng lúc:

• "between an on-premises network and AWS": đây là bài toán kết nối hai mạng ở hai nơi khác nhau (trung tâm dữ liệu của bạn ↔ hạ tầng AWS), tức là cần một đường ống nối qua Internet, chứ không phải một thứ nằm gọn bên trong AWS.
• "secure": đường ống đó phải được mã hoá, chứ không phải trao đổi dữ liệu trần trụi qua Internet công cộng.

Đây là kiểu câu rất hay gặp ở Cloud Practitioner: các phương án đều là dịch vụ mạng/bảo mật nghe hợp lý, nhưng chỉ một cái làm đúng việc nối hai mạng lại với nhau. Hãy đọc chữ "connection" và "between … and …" như một bộ lọc: dịch vụ nào không tạo ra đường nối giữa hai đầu thì loại.

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

Đáp án đúng theo tệp là D — Virtual Private Network.

AWS Virtual Private Network (AWS VPN) là nhóm giải pháp sinh ra đúng để thiết lập kết nối an toàn giữa mạng on-premises, văn phòng chi nhánh, thiết bị người dùng và mạng toàn cầu của AWS. Đường hầm (tunnel) được mã hoá đi qua Internet công cộng, nên dữ liệu giữa data center của bạn và AWS không lộ ra dạng thô — chính là hai yêu cầu "connection" + "secure" mà đề nêu.

Nói ngắn gọn: VPN là cái cầu, và cầu chính là thứ đề đang hỏi.

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

A. AWS Web Application Firewall (WAF) — Đây là dịch vụ bảo vệ ứng dụng web khỏi các kiểu tấn công phổ biến (khai thác lỗ hổng web). Nó lọc và chặn request đi vào ứng dụng của bạn theo bộ quy tắc. WAF có chữ "Firewall" nên dễ bị chọn nhầm khi thấy đề nhắc "secure", nhưng nó không tạo ra bất kỳ kết nối nào giữa hai mạng — nó chỉ đứng gác trước một ứng dụng đã có sẵn. Sai ở chỗ nhầm "bảo vệ lưu lượng" với "tạo đường kết nối".

B. Amazon Virtual Private Cloud (VPC) — Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. VPC là mạng ảo riêng của bạn bên trong AWS — nơi bạn đặt subnet, route table, các tài nguyên. Nó là đích đến, không phải phương tiện để đi tới đích. Bạn tạo VPC rồi mới gắn AWS VPN vào VPC đó để mạng on-premises nói chuyện được với nó. Chỉ có VPC mà không có VPN thì vẫn chưa có đường nối nào từ data center của bạn sang AWS. Chữ "Virtual Private" giống nhau ở hai phương án B và D chính là chỗ đề cố tình làm rối — phân biệt bằng chữ cuối: Cloud (một mạng) so với Network connection (đường nối giữa các mạng).

C. AWS Mobile Hub — Dịch vụ dùng để xây dựng, kiểm thử và theo dõi ứng dụng di động có sử dụng một hoặc nhiều dịch vụ AWS. Hoàn toàn không thuộc nhóm networking, không liên quan gì tới kết nối on-premises. Đây là phương án gây nhiễu rõ ràng nhất, loại được ngay từ cái nhìn đầu tiên.

📌 Điểm cần nhớ

• "On-premises ↔ AWS" + "secure" = VPN. Đây gần như là một phản xạ nên có: khi đề nói tới nối trung tâm dữ liệu riêng vào AWS bằng đường mã hoá qua Internet, VPN là câu trả lời.
• Phân biệt VPC và VPN — đừng để hai chữ viết tắt gần giống nhau đánh lừa. VPC là mạng ảo của bạn bên trong AWS (nơi tài nguyên nằm); VPN là đường kết nối an toàn đi vào mạng đó. Chúng bổ sung cho nhau chứ không thay thế nhau: bạn nối AWS VPN vào Amazon VPC.
• Chữ "Firewall" trong tên dịch vụ không có nghĩa nó tạo kết nối. AWS WAF lọc lưu lượng web ở lớp ứng dụng, chống các kiểu khai thác web phổ biến — nó là lớp phòng thủ đặt trước ứng dụng, không phải phương tiện liên kết hai mạng.
• Đọc động từ trong đề để chọn nhóm dịch vụ. "Establish a connection" → nhóm kết nối mạng; "protect / filter" → nhóm bảo mật; "build / test / monitor an app" → nhóm công cụ phát triển (như AWS Mobile Hub). Chỉ cần khớp đúng động từ với nhóm là loại được phần lớn phương án nhiễu.