Ngân hàng đề — AWS Certified Data Engineer Associate

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

Đề mô tả một team đang thử nghiệm DynamoDB và phát hiện ra rằng một số thao tác ghi đang đè lên item đã tồn tại có cùng primary key, khiến dữ liệu bị sai lệch. Câu hỏi chốt lại: "Which DynamoDB write option would you select to prevent this kind of overwriting?"

Cụm từ quyết định là "overwriting existing items having that specific primary key" kết hợp với "write option ... to prevent". Hai chi tiết này khoanh vùng rất chặt:

• Vấn đề không nằm ở hiệu năng, không nằm ở chuyện đọc dữ liệu, mà nằm ở chỗ thao tác ghi không kiểm tra trước xem item đã tồn tại hay chưa. Đây chính là hành vi mặc định của PutItem: cùng primary key thì ghi đè, không hỏi han gì.
• Từ "write option" loại thẳng mọi phương án thuộc nhóm đọc dữ liệu.

Vậy thứ cần tìm là một cơ chế cho phép gắn điều kiện vào thao tác ghi, để thao tác chỉ thành công khi điều kiện thoả mãn.

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

D — Conditional writes. DynamoDB hỗ trợ conditional writes cho các thao tác ghi PutItem, UpdateItem và DeleteItem. Một conditional write chỉ thành công khi các thuộc tính của item thoả mãn điều kiện đã khai; không thoả mãn thì DynamoDB trả về lỗi và không ghi gì cả.

Áp vào đúng tình huống của đề: bạn có thể yêu cầu PutItem chỉ được thành công khi chưa tồn tại item nào mang primary key đó. Nếu item đã có sẵn, thao tác bị từ chối thay vì lặng lẽ đè lên dữ liệu cũ — đúng thứ mà đề đang cần ngăn chặn. Tương tự, bạn có thể chặn UpdateItem sửa một item nếu một thuộc tính của nó đang mang giá trị nhất định.

Conditional writes cũng chính là công cụ chuẩn khi nhiều người dùng cùng sửa một item: điều kiện được đánh giá ngay tại thời điểm ghi, nên không có khe hở giữa "đọc để kiểm tra" và "ghi".

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

A — Batch writes. Đây là phương án gần đúng nhất về mặt "cũng là write option", nên dễ bị chọn nhầm. Nhưng batch operations (cả đọc lẫn ghi) sinh ra để giảm số vòng đi lại qua mạng giữa ứng dụng và DynamoDB, và để DynamoDB thực hiện các thao tác riêng lẻ song song mà ứng dụng không phải tự quản lý luồng. Nó chỉ gom nhiều thao tác ghi lại, chứ từng thao tác trong lô vẫn giữ nguyên hành vi ghi đè như cũ. Gom bao nhiêu thao tác cũng không tự sinh ra một điều kiện kiểm tra — vấn đề của đề không hề được giải quyết.

B — Scan operation. Sai ngay ở loại thao tác: Scan là thao tác đọc, nó duyệt qua mọi item trong một table hoặc secondary index và mặc định trả về toàn bộ thuộc tính. Đề hỏi rõ "write option", còn Scan thì không sửa đổi item nào. Đây là phương án nhiễu thuần tuý, không liên quan tới việc cập nhật item.

C — Atomic Counters. Phương án này nguy hiểm vì nghe có vẻ dính tới an toàn dữ liệu khi ghi đồng thời. Nhưng đọc kỹ định nghĩa thì thấy ngược lại: atomic counter là một thuộc tính kiểu số được tăng lên một cách vô điều kiện (unconditionally), không cản trở các request ghi khác. Ví dụ điển hình là đếm số lượt truy cập website — nơi mà mọi lần tăng đều hợp lệ và không cần kiểm tra gì. Chính chữ "unconditionally" khiến nó đối lập với thứ đề cần: đề cần có điều kiện mới cho ghi. Ngoài ra atomic counter chỉ áp cho thuộc tính số, không giúp gì cho việc bảo vệ một item khỏi bị PutItem đè lên.

📌 Điểm cần nhớ

• Hành vi mặc định của PutItem là ghi đè item có cùng primary key. Đề bài nào nhắc tới "overwriting existing item", "lost update", hay "nhiều người cùng sửa một item" thì gần như chắc chắn đáp án là conditional writes.
• Conditional writes áp được cho cả PutItem, UpdateItem và DeleteItem; điều kiện không thoả thì thao tác trả lỗi chứ không ghi một phần.
• Phân biệt theo mục đích thiết kế, đừng phân biệt theo cảm giác: Batch writes = giảm round trip mạng và chạy song song; Atomic Counters = tăng số vô điều kiện; Scan = thao tác đọc toàn bảng.
• Mẹo loại nhanh: đề hỏi "write option" thì gạch ngay mọi phương án thuộc nhóm đọc (Scan, Query) trước khi cân nhắc phần còn lại.

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

Đề mô tả một công ty đang dùng Amazon S3 để chứa media file, log file, audit file, và muốn cấu hình Amazon EMR dùng S3 làm Hadoop storage layer thay cho HDFS.

Cụm từ quyết định đáp án là "as the Hadoop storage layer instead of HDFS" — tức là thay thế hẳn HDFS bằng S3 ở vai trò lớp lưu trữ của Hadoop. Đây không phải câu hỏi "có đọc/ghi dữ liệu trên S3 từ EMR được không" (được, và rất phổ biến), mà là câu hỏi "S3 có đóng vai HDFS được không". Người học rất dễ đọc lướt thành vế đầu rồi chọn ngay một phương án khẳng định.

Ràng buộc kỹ thuật đứng sau chữ instead of: HDFS là một file system hiện thực hoá Hadoop FileSystem API theo mô hình hành vi POSIX, còn S3 là một object store. Hai thứ này đều dùng được với EMR nhưng không thay thế lẫn nhau.

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

Đáp án D — "You can't configure Amazon EMR to use Amazon S3 instead of HDFS as the Hadoop storage layer".

Trên EMR, HDFS và EMRFS (EMR File System — lớp cho phép cluster đọc/ghi trực tiếp xuống S3) cùng tồn tại, chứ không phải cái này thế chỗ cái kia. EMRFS là hiện thực của Hadoop FileSystem API để làm việc với S3, mang lại tiện lợi là dữ liệu bền vững nằm ngoài cluster và có sẵn các tính năng như mã hoá dữ liệu — nhưng bản chất bên dưới vẫn là object store, không có ngữ nghĩa file system kiểu POSIX mà Hadoop trông đợi ở lớp HDFS.

Vì vậy câu trả lời đúng với yêu cầu "cấu hình S3 thay cho HDFS" là: không cấu hình được như vậy. Dùng S3 làm nơi lưu dữ liệu qua EMRFS thì được; xoá HDFS khỏi vai trò storage layer của Hadoop thì không.

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

A — "cấu hình lúc launch EMR cluster": đây là phương án gần đúng nhất và cũng là bẫy chính. Đúng là lúc tạo cluster bạn khai báo được cấu hình liên quan tới S3/EMRFS, nên câu chữ nghe rất hợp lý. Nhưng nó hỏng ở chỗ khẳng định có thể thay HDFS bằng S3 — thời điểm cấu hình (lúc launch hay sau đó) không làm thay đổi sự thật là hai lớp lưu trữ này không hoán đổi cho nhau. Đúng "cách làm", sai "điều làm được".

B — "launch cluster dạng long-running": phương án này gắn khả năng thay thế HDFS vào kiểu vòng đời của cluster (long-running so với transient). Vòng đời cluster ảnh hưởng tới chuyện dữ liệu trên HDFS còn hay mất khi cluster bị terminate — đó là lý do người ta để dữ liệu bền vững trên S3 — nhưng nó không hề mở ra khả năng cho S3 đóng vai storage layer của Hadoop. Đây là distractor thuần tuý: ghép một khái niệm EMR có thật vào một kết luận không liên quan.

C — "dùng Amazon S3 block file system": sai vì nhắc tới một thứ legacy đã bị deprecate. S3 block file system ngày trước sinh ra để hỗ trợ upload vượt giới hạn kích thước một object; từ khi có multipart upload thì nó không còn cần thiết. Ngoài chuyện lỗi thời, nó còn có thể gây race condition làm hỏng file system, nên khuyến nghị là tránh và dùng EMRFS. Và kể cả nếu dùng, nó vẫn không biến S3 thành lớp thay thế HDFS — nên vừa sai về khuyến nghị, vừa sai về kết luận.

📌 Điểm cần nhớ

• HDFS và EMRFS bổ sung cho nhau, không thay thế nhau. EMR luôn có HDFS ở lớp storage; EMRFS là đường để đọc/ghi dữ liệu trên S3.
• File system ≠ object store. HDFS mô phỏng hành vi kiểu POSIX, S3 là kho object — khác biệt này là gốc rễ của mọi câu hỏi dạng "thay HDFS bằng S3 được không".
• Đọc kỹ chữ instead of / replace. Nhiều câu trong Domain này chỉ khác nhau ở việc hỏi "dùng thêm" hay "dùng thay"; nhớ mẫu câu hỏi để không chọn nhầm phương án khẳng định.
• S3 block file system là legacy đã deprecate — thấy tên nó trong phương án thì gần như chắc chắn đó là distractor; lựa chọn được khuyến nghị luôn là EMRFS.

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

Đề mô tả một công ty dùng Amazon Redshift làm data warehouse, có những truy vấn phức tạp chạy đi chạy lại trên khối dữ liệu lớn nên đã dùng materialized view. Yêu cầu: các materialized view này phải được refresh tự động theo một lịch đã định (per a defined schedule), và giải pháp phải tối ưu với ít công sức nhất (LEAST effort).

Có hai cụm từ cùng lúc quyết định đáp án, và bỏ sót cụm nào cũng chọn sai:

1. "per a defined schedule" — refresh theo lịch, tức là theo mốc thời gian do người dùng đặt ra, chứ không phải refresh mỗi khi dữ liệu ở base table thay đổi. Cụm này loại đúng một phương án nghe rất thuyết phục.
2. "LEAST effort" — trong các phương án cùng đạt được kết quả, phương án nào ít thành phần phải tự dựng và tự bảo trì hơn thì thắng. Cụm này phân xử giữa hai phương án đều "chạy được".

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

D — Create a schedule to refresh the materialized views with Amazon Redshift query editor v2.

Amazon Redshift query editor v2 cho phép tạo lịch chạy một câu lệnh SQL ngay trong giao diện — ở đây là câu REFRESH MATERIALIZED VIEW. Người dùng chỉ cần chọn câu lệnh, đặt khoảng thời gian lặp lại theo nhu cầu nghiệp vụ, và xong.

Điểm mấu chốt mà phần giải thích nguồn nêu rõ: khi tới giờ, truy vấn theo lịch đó được Amazon EventBridge kích hoạt và chạy qua Amazon Redshift Data API. Nghĩa là cơ chế bên dưới đúng là thứ phương án C mô tả — nhưng Redshift lo phần dựng sẵn, người dùng không phải tự ghép. Việc duy nhất phải làm thêm là cấp quyền IAM: IAM user tạo lịch và IAM role gắn với lịch phải có quyền dùng EventBridge và Redshift Data API.

Vừa đúng ngữ nghĩa "theo lịch", vừa ít việc phải làm nhất — trúng cả hai ràng buộc của đề.

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

A — Materialized view không thể refresh tự động, phải refresh thủ công. Sai về mặt sự thật. Redshift hỗ trợ cả autorefresh lẫn refresh theo lịch. Đây là distractor thuần túy, chỉ cần biết Redshift có tồn tại hai cơ chế kia là loại được ngay.

B — Đặt auto-refresh cho materialized view bằng CREATE MATERIALIZED VIEW. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất. Tùy chọn autorefresh khi tạo (hoặc sửa) materialized view là có thật, và nếu đề chỉ nói "refresh tự động" thì B sẽ đúng. Nhưng cơ chế của nó là: Redshift refresh ngay khi có thể sau khi base table thay đổi — trigger theo sự kiện dữ liệu, không theo đồng hồ. Đề lại yêu cầu refresh theo lịch định sẵn. Hai mô hình kích hoạt khác hẳn nhau: với autorefresh, tần suất refresh do nhịp thay đổi của base table quyết định, không do người dùng đặt. Vậy nên B hỏng ở đúng chỗ "per a defined schedule".

C — EventBridge kích hoạt Lambda theo lịch, Lambda gọi Redshift Data API để refresh. Phương án này hoàn toàn chạy được và cũng đúng ngữ nghĩa "theo lịch" — nó không sai về kỹ thuật. Nó hỏng ở tiêu chí thứ hai: LEAST effort. Như phần giải thích chỉ ra, đây chính là các bước Redshift query editor v2 đã tự chạy bên trong khi bạn đặt lịch cho truy vấn. Chọn C nghĩa là tự tay dựng lại thứ dịch vụ đã làm sẵn: phải viết và duy trì code Lambda, quản lý rule EventBridge, xử lý lỗi và quyền cho từng mảnh. Cùng một kết quả với nhiều thành phần phải bảo trì hơn — thua D về mặt vận hành.

📌 Điểm cần nhớ

• Với materialized view của Redshift, phân biệt rõ hai cơ chế: autorefresh (kích hoạt khi base table đổi, khai lúc CREATE/ALTER MATERIALIZED VIEW) và scheduled refresh (kích hoạt theo mốc thời gian, đặt trong query editor v2). Đề nói "theo lịch" → chọn cái thứ hai; đề nói "luôn mới nhất so với dữ liệu nguồn" → chọn cái thứ nhất.
• Lịch chạy SQL trong Redshift query editor v2 không phải một dịch vụ khác: bên dưới nó vẫn là EventBridge + Redshift Data API. Nhận ra điều này giúp thấy ngay vì sao phương án "tự dựng EventBridge + Lambda" là làm lại việc đã có.
• Khi đề có từ khóa LEAST effort / LEAST operational overhead, thường sẽ có ít nhất hai phương án cùng đúng về kỹ thuật. Lúc đó tiêu chí không còn là "có chạy không" mà là "ai phải viết code và bảo trì" — tính năng dựng sẵn của dịch vụ thắng giải pháp tự ghép.
• Phương án khẳng định một dịch vụ AWS không làm được một việc phổ biến (kiểu "phải làm thủ công") gần như luôn là distractor.

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

Đề mô tả một tình huống rất gọn: dữ liệu đang nằm trong Amazon DynamoDB, và người dùng cần đọc dữ liệu đó từ một Amazon SageMaker notebook để chạy mô hình machine learning.

Cụm từ quyết định đáp án là "with the LEAST operational effort" — ít công vận hành nhất. Cả bốn phương án đều đưa được dữ liệu tới SageMaker; chúng chỉ khác nhau ở số bước phải dựng và phải trông coi. Khi đề hỏi "least operational effort", tiêu chí không còn là "cách nào chuẩn mực nhất trong kiến trúc dữ liệu lớn" mà là cách nào ít thành phần trung gian nhất.

Chi tiết thứ hai cũng quan trọng: đề nói môi trường đích là notebook. Notebook là môi trường chạy code Python tương tác, tức là nó vốn đã có sẵn AWS SDK và IAM role để gọi thẳng API của các dịch vụ AWS. Ba phương án còn lại đều chèn thêm Amazon S3 vào giữa, dù đề không hề yêu cầu dữ liệu phải nằm ở S3.

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

Đáp án đúng theo tệp là D — đọc trực tiếp từ SageMaker Notebook bằng boto3 client, khởi tạo DynamoDB client và gọi Scan.

Lý do: SageMaker notebook chạy code Python, mà boto3 là SDK chính thức của AWS cho Python. Từ trong notebook, chỉ cần khởi tạo một DynamoDB client rồi gọi thao tác Scan là lấy được dữ liệu — không dựng thêm bất kỳ dịch vụ nào, không sinh thêm bản sao dữ liệu, không có pipeline nào phải bảo trì. Đây chính là định nghĩa của "least operational effort".

Thao tác Scan đọc qua mọi item trong table hoặc trong một secondary index, trả về item cùng các attribute của chúng — đúng với yêu cầu "all the data" mà mô hình ML cần. Nếu muốn DynamoDB trả về ít item hơn, có thể kèm FilterExpression để lọc bớt.

Một lưu ý thực hành mà bản giải thích gốc nhấn mạnh: kết quả trả về ở định dạng JSON, nên trong notebook thường phải chuyển tiếp sang dạng dùng được cho phần còn lại của quy trình, ví dụ đổi thành pandas dataframe. Đây là vài dòng code trong chính notebook, không phải một hệ thống phải vận hành.

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

A — Export table ra file .csv, upload lên S3, rồi đọc S3 từ SageMaker. Đây là phương án "thủ công" nhất. Việc chuyển dữ liệu sang S3 là một bước thừa: nó làm tăng thời gian thực thi và tăng chi phí (lưu trữ thêm một bản sao, cộng thời gian export/upload) mà chẳng đem lại lợi ích nào, vì SageMaker đọc thẳng từ DynamoDB được. Ngoài ra bản sao trên S3 là dữ liệu tĩnh — dữ liệu trong DynamoDB thay đổi thì phải làm lại toàn bộ chu trình.

B — Dùng AWS Data Pipeline console để export DynamoDB sang S3, rồi chuyển JSON thành CSV làm nguồn cho SageMaker. Phương án này hỏng ngay ở phương tiện thực hiện: truy cập AWS Data Pipeline qua console đã bị deprecated từ 2023; việc dùng dịch vụ này về sau chỉ còn qua CLI và API. Một phương án chỉ đường bằng một giao diện không còn dùng được thì không phải là giải pháp cho tình huống này. Ngay cả bỏ qua điểm đó, nó vẫn cõng đủ nhược điểm của A cộng thêm một dịch vụ điều phối phải cấu hình và theo dõi — trái hẳn với "least operational effort".

C — Dùng AWS Glue để chuyển table từ DynamoDB sang S3, rồi đọc S3 từ SageMaker. Đây là phương án gần đúng nhất và cũng dễ bị chọn nhầm nhất, vì Glue đúng là dịch vụ ETL managed và đúng là kết nối được DynamoDB với S3. Nó hỏng ở hai chỗ. Thứ nhất, Glue không tự biết cấu trúc dữ liệu: phải chạy Glue Crawler để nạp table vào AWS Glue Data Catalog trước đã — tức là thêm một thành phần nữa phải cấu hình, lên lịch và theo dõi. Thứ hai, giống A và B, việc đi vòng qua S3 là không cần thiết khi SageMaker đọc thẳng DynamoDB được. Glue là lựa chọn hợp lý khi ta thực sự cần biến đổi dữ liệu quy mô lớn hoặc dựng data lake; ở đây đề chỉ cần đọc dữ liệu vào một notebook.

📌 Điểm cần nhớ

• "LEAST operational effort" là từ khoá xếp hạng, không phải từ trang trí. Khi nó xuất hiện, hãy đếm số dịch vụ và số bước phải dựng ở mỗi phương án — phương án ít mắt xích nhất thường thắng, kể cả khi phương án nhiều mắt xích hơn nghe "chuyên nghiệp" hơn.
• Đừng chèn S3 vào giữa khi không ai yêu cầu. SageMaker notebook chạy Python nên gọi thẳng API dịch vụ nguồn bằng boto3 được; sao chép dữ liệu sang S3 chỉ thêm bản sao, thêm chi phí, thêm độ trễ và thêm chuyện dữ liệu bị cũ.
• Scan đọc toàn bộ item trong table hoặc secondary index, trả kết quả dạng JSON; kèm FilterExpression để DynamoDB trả về ít item hơn. Trong notebook thường phải tự chuyển JSON sang pandas dataframe.
• AWS Glue luôn kéo theo Glue Crawler và Data Catalog. Thấy phương án nào dùng Glue chỉ để "chuyển dữ liệu từ A sang B", hãy tính luôn phần chi phí vận hành ẩn đó vào cán cân so sánh.
• Chú ý phương án mô tả cách dùng đã lỗi thời — như truy cập AWS Data Pipeline qua console. Một cách làm không còn khả dụng thì tự loại, không cần so sánh tiếp về kiến trúc.

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

Một công ty chia sẻ ảnh lưu ảnh đại diện người dùng trong Amazon S3, và có một ứng dụng phân tích ảnh chạy trên bốn EC2 instance. Yêu cầu: mỗi khi có ảnh được upload, thủ tục phân tích chỉ được chạy trên một trong bốn instance đó.

Cụm từ quyết định nằm ở dòng: "trigger an image analysis procedure only on one of the four Amazon EC2 instances for each photo uploaded".

Đây là ràng buộc phân biệt toàn bộ bốn phương án. Câu hỏi không hỏi "làm sao báo cho các EC2 biết có ảnh mới" — nếu chỉ vậy thì SNS cũng xong. Nó hỏi làm sao để đúng một worker xử lý mỗi ảnh, tức là bài toán phân phối công việc (work queue) chứ không phải bài toán phát tán thông báo (pub/sub fan-out). Nhận ra sự khác biệt giữa hai mô hình này là chìa khoá của câu.

Ràng buộc phụ, nhưng cũng quan trọng: các consumer là EC2 instance, không phải Lambda. EC2 là máy chủ tự chạy, nó phải chủ động kéo việc về; không có cơ chế nào của S3 hay EventBridge "gọi thẳng" vào một ứng dụng đang chạy trên EC2.

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

B — S3 Event Notification gửi message vào SQS queue, bốn EC2 instance cùng đọc từ queue đó.

S3 Event Notification cho phép nhận thông báo khi có sự kiện xảy ra trong bucket (ví dụ object được tạo). Bạn khai báo cấu hình thông báo gồm loại sự kiện muốn theo dõi và đích đến. S3 hỗ trợ ba đích: SNS topic, SQS queue, và AWS Lambda. Ở đây ta chọn đích là SQS.

Điểm mấu chốt nằm ở ngữ nghĩa của SQS: mỗi message trong queue chỉ được một consumer nhận về xử lý tại một thời điểm. Khi một instance gọi ReceiveMessage và lấy được message, message đó bị ẩn khỏi các consumer khác trong khoảng visibility timeout, xử lý xong thì instance xoá nó đi. Vì vậy với bốn EC2 cùng poll chung một queue, mỗi ảnh upload sẽ chỉ được đúng một instance trong bốn nhặt lên và phân tích — chính là hành vi đề bài yêu cầu.

Mô hình này cũng hợp với việc consumer là EC2: instance tự poll queue theo nhịp của nó, không cần ai "gọi vào" máy. Kèm theo đó là tính decoupling — instance chết thì message quay lại queue sau visibility timeout và instance khác xử lý tiếp, không mất ảnh nào.

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

A — EventBridge event phản ứng với object upload rồi invoke một trong các EC2 instance. Vế đầu hợp lý (EventBridge bắt được sự kiện upload lên S3), nhưng vế sau không tồn tại: EventBridge không thể invoke một ứng dụng đang chạy bên trong EC2 instance. Target của EventBridge là các dịch vụ AWS (Lambda, SQS, SNS, Step Functions, EC2 API actions như start/stop instance…), chứ không phải tiến trình ứng dụng của bạn. Đây là kiểu phương án nghe rất thuận tai vì đúng nửa đầu — hỏng ở chỗ giả định một khả năng mà dịch vụ không có.

C — Subscribe các EC2 instance vào Amazon S3 Analytics – storage class analysis. Đây là distractor thuần tuý, sai luôn về mục đích dịch vụ. S3 Analytics storage class analysis quan sát mẫu truy cập dữ liệu để giúp bạn quyết định khi nào nên chuyển dữ liệu ít được truy cập từ STANDARD sang STANDARD_IA. Nó là công cụ phân tích chi phí lưu trữ, không phải cơ chế sự kiện, và cũng không có khái niệm "subscribe" EC2 vào nó. Đừng để hai chữ "analysis" trong đề (image analysis) và trong phương án (storage class analysis) đánh lừa.

D — S3 Event Notification gửi message tới SNS topic, subscribe bốn EC2 instance vào topic. Đây là phương án gần đúng nhất và là bẫy chính của câu. Vế S3 Event Notification hoàn toàn hợp lệ — SNS đúng là một đích được hỗ trợ. Chỗ hỏng nằm ở ngữ nghĩa của SNS: nó là dịch vụ pub/sub, mỗi message được fan-out tới tất cả subscriber. Với bốn EC2 cùng subscribe, mỗi ảnh upload sẽ đẩy thông báo tới cả bốn instance, và cả bốn cùng chạy phân tích trên cùng một ảnh. Kết quả là làm việc trùng lặp bốn lần — trái ngược trực tiếp với "only on one of the four" trong đề.

📌 Điểm cần nhớ

• SQS = phân phối công việc, SNS = phát tán thông báo. Đề nói "chỉ một trong N worker xử lý mỗi item" → SQS. Đề nói "tất cả các bên đều cần biết" → SNS. Đây là cặp phân biệt xuất hiện lặp đi lặp lại trong đề thi.
• S3 Event Notification có đúng ba đích cần thuộc: SNS, SQS, Lambda. Phương án nào cho S3 Event Notification bắn thẳng vào một đích khác là sai ngay từ mô tả.
• EventBridge không invoke được ứng dụng chạy trong EC2. Target của nó là các dịch vụ AWS, không phải tiến trình bên trong máy ảo của bạn. Consumer là EC2 thì gần như luôn cần một queue để EC2 tự kéo việc về.
• Cẩn thận với distractor trùng từ khoá nhưng khác miền: "image analysis" trong đề và "storage class analysis" trong phương án không liên quan gì đến nhau.

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

Đề mô tả một tình huống rất cụ thể về Amazon Athena: dữ liệu đang nằm trên S3 dưới dạng file .csv không nén, và truy vấn chạy chậm. Câu hỏi là nên đổi sang cách lưu trữ nào để cải thiện hiệu năng.

Có hai cụm từ trong đề quyết định đáp án, và phải thoả cả hai:

1. "the files queried by Athena were not compressed" — dữ liệu chưa nén. Athena tính chi phí và thời gian theo lượng dữ liệu quét từ S3, nên nén là một nửa lời giải.
2. "users perform most queries by selecting a specific column" — người dùng chỉ chọn một vài cột. Đây là dấu hiệu kinh điển đòi hỏi định dạng cột (columnar): với CSV, Athena buộc phải đọc toàn bộ dòng rồi mới bỏ đi các cột không cần; với định dạng cột, engine chỉ đọc đúng cột được SELECT.

Vì đề nêu cả hai vấn đề, phương án đúng phải xử lý cả hai, chứ không chỉ một. Đó chính là con dao mổ để tách các phương án trông na ná nhau.

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

D — Chuyển sang Apache Parquet và nén bằng Snappy.

Parquet là định dạng lưu trữ theo cột, mã nguồn mở, được Athena hỗ trợ trực tiếp. Khi truy vấn chỉ SELECT vài cột, Athena đọc đúng các khối dữ liệu của những cột đó và bỏ qua phần còn lại — giải quyết vế "users select a specific column".

Snappy giải quyết vế còn lại: dữ liệu nén nhỏ hơn nghĩa là ít byte bị quét từ S3 hơn, kéo theo truy vấn nhanh hơn, lưu lượng mạng từ S3 sang Athena ít hơn và chi phí truy vấn thấp hơn. Snappy được chọn vì nó thiên về tốc độ nén/giải nén hơn là tỷ lệ nén tối đa — đúng thứ cần cho khối lượng công việc truy vấn tương tác.

Về cách làm: có thể chạy CREATE TABLE AS SELECT (CTAS) trong chính Athena và chỉ định định dạng đích là Parquet, hoặc dùng AWS Glue Crawler, để chuyển dữ liệu thô hiện có sang định dạng mới.

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

A — Chuyển sang JSON, nén Snappy. Phương án này có phần nén đúng nhưng sai ở định dạng. JSON vẫn là định dạng theo dòng (row-oriented), không phải columnar — Athena vẫn phải đọc và phân tích cả bản ghi để lấy ra một cột. Nó không tối ưu cho Athena bằng Parquet, và đổi từ CSV sang JSON gần như không giải quyết được vấn đề gốc mà đề nêu ra.

B — Chuyển sang Apache ORC. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. ORC cũng là định dạng cột, cũng được Athena hỗ trợ, file ORC thường nhỏ gọn và có index giúp truy vấn nhanh. Nó xử lý tốt vế "chọn một cột cụ thể". Nhưng nó hỏng ở chỗ thiếu hẳn phần nén — đề nói rõ dữ liệu hiện không được nén, và phương án này không đả động gì tới việc nén. So với D vốn nói đủ cả định dạng cột lẫn nén, B chỉ đáp ứng một nửa yêu cầu nên không phải lựa chọn tốt nhất.

C — Chuyển sang định dạng ZIP. Sai ở tầng căn bản hơn: ZIP không nằm trong các định dạng nén mà Athena hỗ trợ. Ngoài ra ZIP là cách đóng gói/nén tệp, nó không biến dữ liệu thành dạng cột, nên kể cả có được hỗ trợ thì vẫn bỏ sót vế "chọn một cột cụ thể".

📌 Điểm cần nhớ

• Với Athena, hiệu năng và chi phí đều đi theo lượng dữ liệu quét từ S3. Mọi thứ làm giảm số byte phải đọc — định dạng cột, nén, phân vùng — đều là hướng tối ưu đúng.
• Đề nhắc tới việc chỉ chọn vài cột là tín hiệu chọn định dạng columnar (Parquet hoặc ORC), không phải CSV/JSON.
• Khi đề nêu hai vấn đề (chưa nén + chỉ đọc vài cột), hãy chọn phương án xử lý cả hai. Một phương án đúng một nửa như ORC-không-nén vẫn thua phương án đúng trọn vẹn.
• Snappy là lựa chọn quen thuộc đi kèm Parquet cho khối lượng công việc truy vấn tương tác vì ưu tiên tốc độ nén/giải nén; Athena còn hỗ trợ các định dạng phổ biến khác như gzip và zstd, nhưng không hỗ trợ ZIP.
• Muốn chuyển dữ liệu thô sang Parquet/ORC thì dùng CTAS ngay trong Athena hoặc AWS Glue Crawler.

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

Một công ty tài chính đưa bản ghi giao dịch dạng JSON từ CSDL on-premises lên Amazon S3 qua Amazon Kinesis, mỗi bản ghi có 100 cột nhưng chỉ cần 10 cột để phát hiện gian lận. Câu hỏi yêu cầu chọn giải pháp thoả ba ràng buộc cùng lúc:

• lowest-cost — chi phí thấp nhất
• least development work — ít phải viết mã nhất
• out-of-the-box anomaly detection — phát hiện bất thường có sẵn, không tự xây

Cụm quyết định là "out-of-the-box anomaly detection functionality" kết hợp với "least development work". Hai cụm này loại thẳng mọi phương án bắt bạn tự tính anomaly score — dù bằng SQL, bằng Lambda hay bằng mô hình ML tự huấn luyện. Cụm phụ "needs to analyze just ten of these columns" là ràng buộc chi phí: giải pháp tốt phải cắt bớt cột trước khi phân tích, chứ không nuốt cả 100 cột.

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

Đáp án đúng là C: dùng AWS Glue job chuyển JSON sang Apache Parquet, dùng Glue crawler dò schema và dựng AWS Glue Data Catalog, dùng Amazon Athena tạo bảng chỉ gồm tập con các cột cần thiết, rồi dùng Amazon QuickSight với tính năng anomaly detection dựng sẵn bằng machine learning.

Chuỗi này khớp đúng ba ràng buộc:

• Glue job + crawler: Glue là dịch vụ ETL quản lý sẵn — job làm nhiệm vụ chuyển đổi định dạng, crawler kết nối tới data store (ở đây là S3), chạy qua danh sách classifier để xác định schema và tạo bảng metadata trong Data Catalog. Không phải viết mã suy luận schema.
• Parquet + Athena tạo bảng theo tập con cột: Parquet là định dạng cột, còn Athena cho phép định nghĩa bảng chỉ chứa 10 cột cần dùng. Athena là serverless, không có hạ tầng để dựng hay quản lý, và tính tiền theo truy vấn — cộng với việc chỉ đọc phần cột cần thiết, đây chính là vế "lowest-cost" của đề.
• QuickSight ML-powered anomaly detection: đây là vế "out-of-the-box". QuickSight có sẵn khả năng chạy phát hiện bất thường trên số liệu để tìm outlier và xu hướng ẩn, không cần viết mã riêng, không cần chuyên môn ML. Người dùng chỉ cấu hình chứ không phát triển.

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

A — Glue + Athena Catalog rồi dùng Amazon SageMaker. Đây là phương án gần đúng nhất vì phần đầu (Glue job, crawler, Data Catalog) giống hệt đáp án đúng. Nó hỏng ở vế cuối: SageMaker là dịch vụ để xây, huấn luyện và triển khai mô hình ML. Muốn có anomaly detection thì phải tự viết mã, tự phát triển, kiểm thử và deploy mô hình — trái thẳng với "least development work" và "out-of-the-box". QuickSight đã có sẵn thứ mà SageMaker bắt bạn tự làm.

B — Kinesis Data Analytics chạy SQL tính anomaly score, lưu vào S3, QuickSight vẽ biểu đồ. Hỏng ở hai điểm. Thứ nhất, phải tự phát triển truy vấn tùy biến để phân tích dữ liệu vào và tính điểm bất thường — vẫn là development work, không phải tính năng dùng ngay. Thứ hai, nó xử lý toàn bộ các cột của bản ghi thay vì chỉ tập con 10 cột cần cho phân tích, nên không phải là lựa chọn rẻ nhất.

D — Kinesis Data Firehose + Lambda tính anomaly score, lưu vào Amazon RDS, QuickSight đọc từ RDS. Đây là phương án tốn công nhất trong bốn phương án: phải viết một lượng mã tùy biến đáng kể trong hàm Lambda để đọc luồng dữ liệu và tính điểm bất thường cho mọi giao dịch. Giống B, Lambda ở đây soi tất cả các trường chứ không chỉ tập con cần dùng. Việc đổ kết quả sang RDS cũng thêm một tầng hạ tầng có trạng thái phải trả tiền và vận hành, so với việc để dữ liệu nằm yên trên S3 và truy vấn bằng Athena serverless.

📌 Điểm cần nhớ

• Đề nhấn "out-of-the-box" hoặc "least development work" thì tính năng dựng sẵn thắng mọi phương án tự xây: QuickSight built-in ML anomaly detection thắng SageMaker, thắng SQL trong Kinesis Data Analytics, thắng Lambda tự tính điểm.
• SageMaker mạnh nhưng không "sẵn dùng" — nó là bộ công cụ để tự xây mô hình. Thấy SageMaker trong câu hỏi đề cao "ít công phát triển" thì hãy nghi ngờ ngay.
• Chi tiết "chỉ cần 10/100 cột" là gợi ý về chi phí: chuyển sang định dạng cột (Parquet) và tạo bảng Athena chỉ với tập con cột là cách đúng để cắt lượng dữ liệu phải đọc. Phương án nào xử lý cả 100 cột đều thua ở vế "lowest-cost".
• Bộ ba Glue → Athena → QuickSight là khuôn mẫu phân tích serverless quen thuộc: Glue lo ETL và metadata, Athena lo truy vấn trực tiếp trên S3 mà không cần hạ tầng, QuickSight lo trực quan hoá và phần ML sẵn có.

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

Công ty đổ một lượng dữ liệu rất lớn mỗi ngày lên Amazon S3 dưới dạng file .csv, rồi dùng Amazon Athena chạy SQL để làm báo cáo trên dữ liệu lịch sử. Athena vốn chạy tốt, nhưng khi khối lượng dữ liệu tăng vọt thì truy vấn bắt đầu chậm và hiệu năng đi xuống. Câu hỏi: làm gì để tăng hiệu năng truy vấn.

Cụm từ quyết định đáp án là ".csv files" đặt cạnh "huge volume of data" và "query lags". Athena tính chi phí và thời gian theo lượng dữ liệu phải quét từ S3. CSV là định dạng theo dòng (row-based), không nén, nên mỗi truy vấn — dù chỉ cần vài cột — vẫn buộc Athena đọc toàn bộ file. Đây chính là nút thắt, và cách chữa đúng bản chất là đổi định dạng lưu trữ + phân vùng dữ liệu, chứ không phải mẹo viết câu lệnh.

Cụm phụ thứ hai cần để ý: "on a daily basis" — dữ liệu đến liên tục theo ngày, nên giải pháp phải là một quy trình lặp lại tự động, không phải một lần chuyển đổi thủ công.

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

Đáp án đúng là C: dùng AWS Glue ETL job chạy hằng ngày để chuyển các file dữ liệu sang Apache Parquet và phân vùng chúng, kèm AWS Glue crawler chạy định kỳ để tự quét dữ liệu đã phân vùng.

Ba mảnh ghép, mỗi mảnh giải quyết một phần của vấn đề:

• Parquet là định dạng cột (columnar) và có nén. Athena hỗ trợ sẵn các định dạng cột mã nguồn mở như Apache Parquet và Apache ORC. Khi dữ liệu ở dạng cột, truy vấn chỉ đọc đúng những cột nó cần thay vì cả dòng, nên lượng dữ liệu quét từ S3 giảm mạnh — vừa nhanh hơn vừa rẻ hơn, vì Athena tính tiền theo dữ liệu quét.
• Partitioning chia bảng thành nhiều phần gom dữ liệu liên quan theo giá trị cột như ngày, quốc gia, khu vực. Partition đóng vai trò như cột ảo; khi câu truy vấn có điều kiện lọc trên cột phân vùng, Athena bỏ qua hẳn những phần không liên quan. Với báo cáo trên dữ liệu lịch sử — thường lọc theo khoảng thời gian — đây là đòn bẩy hiệu năng lớn nhất.
• Glue crawler tự suy ra schema của database và bảng từ dữ liệu trong S3, rồi lưu metadata vào AWS Glue Data Catalog. Athena dùng chính Data Catalog này để biết dữ liệu nằm ở đâu, đọc thế nào, xử lý ra sao. Chạy crawler định kỳ nghĩa là partition mới mỗi ngày được nhận diện tự động, không phải khai bằng tay.

Glue ETL là công cụ đúng vai: nó là dịch vụ ETL, được thiết kế để đọc dữ liệu nguồn, biến đổi và ghi ra định dạng khác theo lịch.

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

A — Đặt bảng nhỏ bên trái, bảng lớn bên phải khi join trong Athena. Phương án này sai ngược hẳn về mặt kỹ thuật. Quy tắc đúng là đặt bảng lớn bên trái, bảng nhỏ bên phải: engine Presto phân phối bảng bên phải xuống các worker node rồi stream bảng bên trái qua để thực hiện join. Bảng bên phải càng nhỏ thì càng tốn ít bộ nhớ và truy vấn càng nhanh. Ngoài ra, kể cả nếu phát biểu này đúng chiều, nó cũng chỉ là một mẹo tối ưu câu lệnh — không chạm tới nguyên nhân gốc là quét quá nhiều dữ liệu CSV, và đề bài thậm chí không hề nhắc tới join.

B — Glue ETL chuyển sang định dạng ZIP rồi phân vùng, kèm Glue crawler. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: nó có đủ Glue ETL, đủ partitioning, đủ crawler, chỉ sai đúng một chỗ — định dạng ZIP không được Amazon Athena hỗ trợ. Athena không đọc được dữ liệu đóng gói kiểu này, nên toàn bộ đường ống sẽ vô dụng dù các thành phần khác đều hợp lý. Thêm nữa, ZIP thuần túy là nén, nó không đem lại lợi ích columnar — tức là vẫn không giúp Athena bỏ qua những cột không cần đọc, thứ tạo ra phần lớn cải thiện hiệu năng ở phương án C.

D — Dùng chính Athena để trích xuất dữ liệu và lưu thành Parquet hằng ngày, rồi truy vấn dữ liệu đã trích xuất. Đúng định dạng đích (Parquet) nhưng sai công cụ: Athena là dịch vụ truy vấn tương tác, không phải công cụ ETL, nên không phải chỗ để đứng ra chuyển đổi kho dữ liệu .csv hiện có sang Parquet như một quy trình hằng ngày. Phương án này cũng bỏ mất hai mảnh còn lại: không có partitioning và không có crawler cập nhật Data Catalog, nên ngay cả khi có dữ liệu Parquet thì vẫn thiếu cơ chế để Athena cắt bớt dữ liệu quét theo ngày và nhận biết dữ liệu mới.

📌 Điểm cần nhớ

• Athena chậm và đắt là do lượng dữ liệu quét từ S3. Ba đòn bẩy chuẩn của AWS: nén (compress), phân vùng (partition), và chuyển sang định dạng cột (columnar) — Parquet hoặc ORC.
• Thấy đề nói "dữ liệu .csv trên S3 + Athena chậm", hãy tìm ngay phương án có Parquet/ORC + partitioning. Phương án chỉ nén mà không columnar, hoặc dùng định dạng Athena không hỗ trợ (như ZIP), là bẫy.
• Phân chia vai trò cho đúng: Glue ETL biến đổi dữ liệu, Glue crawler suy schema và cập nhật Glue Data Catalog, Athena chỉ truy vấn. Athena không làm ETL.
• Quy tắc join trong Athena/Presto: bảng lớn bên trái, bảng nhỏ bên phải — bảng bên phải được phân phối xuống worker, bảng bên trái được stream qua.

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

Đội data engineering đang chạy ad-hoc query trên Oracle và PostgreSQL của Amazon RDS, và muốn replicate dữ liệu với high availability rồi gom (consolidate) các database đó vào một data warehouse quy mô petabyte bằng cách streaming dữ liệu sang Amazon Redshift.

Cụm từ quyết định đáp án nằm ở câu hỏi cuối: "MOST resource-efficient", "LEAST amount of development time" và "without the need to manage the underlying infrastructure". Cả bốn phương án đều có thể đưa dữ liệu từ RDS về Redshift theo cách nào đó — điểm phân biệt không phải "làm được hay không", mà là phải tự viết bao nhiêu code và phải tự quản lý bao nhiêu hạ tầng. Thêm một chi tiết nữa: nguồn là database quan hệ đang chạy (Oracle, PostgreSQL) và yêu cầu là replicate liên tục, chứ không phải nạp một lô dữ liệu rồi thôi.

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

C. Use AWS Database Migration Service to replicate the data from the databases into Amazon Redshift.

AWS DMS sinh ra đúng cho bài toán này: chuyển và replicate liên tục dữ liệu từ database nguồn sang đích, trong khi database nguồn vẫn hoạt động bình thường, giảm tối đa thời gian gián đoạn của ứng dụng đang dùng database đó. Đây chính là kịch bản "continuous data replication with high availability" mà đề mô tả.

Redshift là một target được DMS hỗ trợ sẵn, nên việc gom nhiều database nguồn về một data warehouse petabyte-scale chỉ là chuyện cấu hình endpoint và task, không phải viết script migration. Cần lưu ý về mặt kiến trúc: khi target là Redshift, DMS đưa dữ liệu qua một Amazon S3 bucket trung gian trước, rồi mới nạp từ S3 vào đúng bảng trong Redshift. Bucket đó do DMS tạo trong cùng Region, và cluster Redshift phải nằm cùng AWS account, cùng Region với replication instance.

Vì tất cả các bước trên đều là managed service với cấu hình khai báo, DMS thỏa mãn đồng thời cả ba ràng buộc: ít công sức phát triển nhất, không phải quản lý cluster, và hỗ trợ replicate liên tục.

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

A. AWS Glue — Đây là phương án gần đúng nhất và dễ mắc bẫy: Glue là dịch vụ ETL fully managed, đúng là không phải quản lý server, và có connector tới cả JDBC source lẫn Redshift. Chỗ nó hỏng là ở ràng buộc "LEAST amount of development time": Glue job là công cụ ETL theo lô (batch), và để copy dữ liệu database sang Redshift bạn phải tự viết script migration cho từng nguồn. So với DMS chỉ cần khai báo endpoint và task replication, Glue tốn công sức phát triển đáng kể hơn — nên thua ở đúng tiêu chí đề nêu.

B. AWS EMR — Sai ở cả hai ràng buộc. EMR là nền tảng big data chạy các công cụ mã nguồn mở (Spark, Hive, HBase, Flink, Hudi, Presto) trên một cluster EC2 mà bạn phải dựng và bảo trì — vi phạm thẳng "without the need to manage the underlying infrastructure". Ngoài ra vẫn phải viết job migration tùy biến để đẩy dữ liệu vào Redshift, nên cũng vi phạm nốt "LEAST development time". EMR mạnh cho phân tích khối lượng lớn, nhưng ở đây nó là con dao mổ trâu và lại phải tự mài.

D. Amazon Kinesis Data Streams — Chữ "streaming" trong đề dễ khiến người học chọn nhầm. KDS là dịch vụ streaming thời gian thực rất mạnh, hợp với clickstream, log, giao dịch tài chính, database event stream. Nhưng nó không phải công cụ replicate database: bạn vẫn phải tự xây producer đọc thay đổi từ Oracle/PostgreSQL và tự xây consumer ghi vào Redshift. Thêm nữa, KDS đòi tự provision số lượng shard phù hợp với lưu lượng dự kiến, và muốn tăng throughput thì phải tăng shard — đó chính là việc quản lý dung lượng hạ tầng mà đề yêu cầu tránh.

📌 Điểm cần nhớ

• Đề nói replicate/migrate dữ liệu từ một database quan hệ đang chạy (RDS, on-premises) sang đích khác → phản xạ đầu tiên là AWS DMS, nhất là khi có thêm "nguồn vẫn phải hoạt động", "continuous replication", "minimal downtime".
• Phân biệt DMS và Glue: cùng là managed, nhưng DMS là replicate database → khai báo là chạy, còn Glue là ETL cần viết script và thiên về batch. Khi đề nhấn "LEAST development time", chọn DMS.
• Cụm "without managing the underlying infrastructure" gần như luôn loại EMR (cluster EC2 phải tự vận hành), và cũng loại các lựa chọn buộc phải tự tính dung lượng như shard của Kinesis Data Streams.
• Chi tiết kiến trúc đáng nhớ khi target là Redshift: DMS đi vòng qua S3 rồi mới nạp vào Redshift, và cluster Redshift phải cùng account, cùng Region với replication instance.
• Từ khóa "streaming" trong đề không tự động đồng nghĩa với Kinesis — hãy đọc xem nguồn dữ liệu là event stream hay là database.

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

Đề mô tả một công ty game cần lưu game state, player data, session history và leaderboard, đòi hỏi mở rộng tới hàng triệu người dùng đồng thời với độ trễ ổn định ở mức single-digit millisecond. Nhưng cụm từ quyết định đáp án không nằm ở đó — nó nằm ở câu: "evaluating multiple in-memory data stores with the ability to power its on-demand, live leaderboard".

Đây là ràng buộc lọc sạch danh sách. Cả năm phương án đều lặp lại đúng một mệnh đề "meets the in-memory, high availability, low latency requirements", tức là ba tiêu chí giống hệt nhau. Ba dịch vụ trong danh sách hoàn toàn có thể đạt high availability và low latency, nên hai tiêu chí sau không phân biệt được gì. Chỉ còn in-memory là chốt chặn: dịch vụ nào thực sự phục vụ dữ liệu từ bộ nhớ RAM chứ không phải từ tầng lưu trữ đĩa? Đọc câu hỏi kiểu này, việc cần làm là bỏ qua phần bối cảnh game dài dòng và bám vào tính từ kỹ thuật mà đề cố ý nhắc lại.

Thêm một chi tiết: đề ghi rõ (Select two) — phải chọn đúng hai phương án, không nhiều hơn.

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

E — ElastiCache for Redis. Đây là in-memory data store đúng nghĩa: toàn bộ dataset nằm trong RAM, nên độ trễ đọc/ghi xuống dưới mức mili giây. Quan trọng hơn, Redis có sẵn kiểu dữ liệu sorted set — chính là cấu trúc mà bảng xếp hạng cần: chèn điểm số kèm thứ hạng, lấy top-N hay lấy hạng của một người chơi đều là thao tác gốc của Redis, không phải quét toàn bộ rồi sắp xếp lại ở tầng ứng dụng. Gaming leaderboard là use case được AWS nêu đích danh cho ElastiCache for Redis, cùng nhóm với session store, real-time analytics và chat/messaging. Redis cũng hỗ trợ replica và failover nên đáp ứng yêu cầu high availability.

B — DynamoDB kèm DynamoDB Accelerator (DAX). Bản thân DynamoDB cho hiệu năng single-digit millisecond ở mọi quy mô, nhưng nó chưa phải in-memory. DAX là caching service tương thích hoàn toàn với DynamoDB, đặt một tầng cache in-memory ngay trước bảng: ứng dụng vẫn gọi DynamoDB API như cũ, không phải viết lại logic cache, mà kết quả đọc được phục vụ từ bộ nhớ. Chính chữ DAX trong phương án B biến nó thành lời giải hợp lệ — nó bổ sung đúng thứ mà đề yêu cầu và phương án A còn thiếu.

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

A — DynamoDB (không có DAX). Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. DynamoDB thật sự đạt high availability và độ trễ single-digit millisecond, nghe rất khớp với đề. Nhưng nó là managed NoSQL database chứ không phải in-memory data store — dữ liệu nằm trên tầng lưu trữ bền vững, không phải trong RAM. Đề đã nói rõ team đang đánh giá in-memory data stores, nên A trượt đúng ở tiêu chí đó. Điểm khác biệt duy nhất giữa A và B là DAX, và đó chính là chỗ B thắng.

C — AWS Neptune. Neptune là graph database, dùng cho dữ liệu quan hệ nhiều bậc như mạng xã hội, gợi ý bạn bè, phát hiện gian lận. Nó không phải in-memory data store, và mô hình graph cũng không phù hợp với bài toán leaderboard vốn chỉ cần sắp xếp theo điểm số. Sai ở cả tiêu chí in-memory lẫn mô hình dữ liệu.

D — RDS Aurora. Aurora là relational database tương thích MySQL và PostgreSQL, có storage phân tán, tự phục hồi, chịu lỗi tốt — nghĩa là high availability thì đạt. Nhưng nó vẫn là database dựa trên tầng lưu trữ, không phải in-memory. Với leaderboard cập nhật liên tục ở quy mô hàng triệu người dùng đồng thời, việc chạy ORDER BY trên bảng quan hệ mỗi lần hiển thị bảng xếp hạng là mô hình sai ngay từ đầu.

📌 Điểm cần nhớ

• Khi đề nhấn mạnh in-memory, chỉ hai thứ trong danh mục AWS đáp ứng: ElastiCache (Redis/Memcached) và DAX (in-memory cache riêng cho DynamoDB). Mọi dịch vụ khác — DynamoDB trần, Aurora, Neptune, Redshift — đều trượt tiêu chí này dù có nhanh đến đâu.
• DynamoDB nhanh nhưng không in-memory. Phân biệt "single-digit millisecond" (DynamoDB) với "sub-millisecond, in-memory" (ElastiCache, DAX) là ranh giới mà đề thi hay dùng để tách hai phương án gần giống nhau.
• Leaderboard ⇒ nghĩ ngay tới Redis sorted set. Đây là cặp bài toán–giải pháp kinh điển; thấy từ "leaderboard", "real-time ranking" trong đề thì ElastiCache for Redis gần như luôn nằm trong đáp án.
• Khi nhiều phương án chép lại y hệt một danh sách tiêu chí, hãy tìm tiêu chí nào chỉ một số ít dịch vụ thoả mãn — đó mới là điều kiện lọc thật, phần còn lại chỉ là nhiễu.