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

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

Đề mô tả một stream duy nhất của Amazon Kinesis Data Streams với 2 shard, nhận dữ liệu từ 30 sensor thuộc hai phương tiện: Vehicle A có 20 sensor, Vehicle B có 10 sensor. Partition key được sinh theo tên phương tiện — tức chỉ có đúng hai giá trị khác nhau. Kết quả: dữ liệu của Vehicle A nghẽn, dữ liệu của Vehicle B thì không.

Cụm từ quyết định đáp án nằm ở hai chỗ, phải đọc cùng nhau:

• "Two partition keys are generated based on the name of the vehicles" — nguyên nhân gốc. Kinesis băm partition key để chọn shard, nên chỉ hai key nghĩa là toàn bộ 20 sensor của A dồn vào một shard, còn 10 sensor của B nằm ở shard kia. Đây chính là hot shard / hot partition.
• "The overall stream throughput has been validated to be less than the assigned Kinesis Data Streams throughput" — tổng dung lượng đã đủ. Vấn đề không phải thiếu capacity mà là phân bổ lệch.

Thêm ràng buộc của câu hỏi: "without increasing the total cost and complexity" — loại thẳng mọi phương án thêm shard hoặc thêm stream.

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

C — Đổi partition key sang sensor ID thay vì tên phương tiện.

Mỗi sensor có một ID duy nhất, nên dùng sensor ID làm partition key sẽ tạo ra 30 giá trị key khác nhau thay vì 2. Hàm băm của Kinesis phân bố các key này lên khoảng không gian hash và chia đều cho hai shard hiện có, nên tải của Vehicle A không còn dồn hết vào một shard — dữ liệu của cả A và B trộn lẫn và trải ra cả hai shard.

Đây là cách chữa đúng bản chất vấn đề: đề đã xác nhận tổng throughput vẫn nằm dưới mức 2 shard cung cấp, nên chỉ cần dùng hết capacity đang có là đủ. Giải pháp này không thêm shard, không thêm stream nên chi phí và độ phức tạp giữ nguyên — khớp đúng ràng buộc của đề. Thay đổi nằm hoàn toàn ở phía producer, chỉ là đổi giá trị truyền vào PartitionKey khi gọi PutRecord/PutRecords.

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

A — Tạo stream mới cho Vehicle A với 20 shard. Đây là phương án sai kiểu "đọc nhầm số sensor thành số shard": 20 sensor không có nghĩa là cần 20 shard, vì shard được tính theo throughput chứ không theo số nguồn phát. Nó vi phạm trực tiếp cả hai vế của đề — tăng mạnh chi phí (thêm cả một stream với rất nhiều shard) và tăng độ phức tạp (hai stream, hai consumer path phải quản lý). Tệ hơn, nó không sửa nguyên nhân gốc: nếu Vehicle A vẫn dùng tên phương tiện làm partition key thì trên stream mới, cả 20 sensor lại đổ vào đúng một shard, 19 shard còn lại nằm không và nghẽn vẫn nguyên đó.

B — Tăng số shard của stream hiện tại. Đây là phương án gần đúng nhất và là bẫy chính. Tăng shard đúng là làm nhẹ tình trạng nghẽn phần nào, nhưng nó trả tiền để lách qua một vấn đề phân bổ, trong khi đề đã nói rõ tổng throughput chưa chạm trần capacity đang có — nghĩa là capacity không thiếu. Với chỉ hai giá trị partition key, mỗi key vẫn ánh xạ về đúng một shard duy nhất bất kể có bao nhiêu shard; thêm shard chỉ khiến các shard dư ra hoàn toàn rỗng chứ không san được tải của Vehicle A. Và nó vi phạm thẳng vế "without increasing the total cost".

D — Tạo stream mới cho Vehicle B với 10 shard. Sai nặng nhất về mặt logic vì tách nhầm phương tiện: Vehicle B là bên không bị nghẽn. Tách B ra một stream riêng chẳng giải phóng được gì cho A — A vẫn ở lại stream cũ, vẫn một partition key, vẫn dồn vào một shard, và nghẽn không hề suy suyển. Ngoài ra vẫn dính đúng lỗi tốn kém và phức tạp như phương án A.

📌 Điểm cần nhớ

• Trong Kinesis Data Streams, partition key quyết định record rơi vào shard nào thông qua hàm băm. Partition key có ít giá trị (tên phương tiện, mã vùng, "default"…) là công thức tạo ra hot shard.
• Đề bài nói "tổng throughput vẫn dưới mức đã cấp" là tín hiệu rõ ràng rằng lỗi nằm ở phân bổ chứ không phải capacity — khi đó đáp án là sửa partition key, không phải thêm shard.
• Partition key nên chọn trường có cardinality cao và phân bố đều (ví dụ sensor ID duy nhất) để tải trải đều trên mọi shard.
• Khi câu hỏi kèm ràng buộc "without increasing cost and complexity", mọi phương án thêm shard hoặc thêm stream gần như chắc chắn là distractor; hãy tìm phương án chỉ sửa cấu hình phía producer.

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

Đề mô tả một data engineer cần nhận luồng dữ liệu streaming vào AWS và phân tích real-time, trong đó có time-based aggregations trên cửa sổ thời gian dài tới 45 phút, đòi hỏi high fault tolerance, và chốt lại bằng câu hỏi kinh điển: "while minimizing the operational overhead".

Có ba cụm từ quyết định, và phải đọc đủ cả ba mới loại được hết phương án:

• "real-time" (chứ không phải near real-time) — cụm này một mình đã loại được Firehose.
• "time-based aggregations over periods of up to 45 minutes" — đây là bài toán windowing có trạng thái: hệ thống phải giữ state của cửa sổ suốt 45 phút rồi mới phát kết quả. Không phải xử lý từng bản ghi độc lập.
• "minimizing the operational overhead" — tiêu chí xếp hạng cuối cùng giữa những phương án về mặt kỹ thuật đều "làm được nếu bạn tự viết code".

Mấu chốt: cả ba phương án Kinesis Data Streams + consumer đều có thể làm ra kết quả, nhưng bạn phải tự viết logic windowing, tự lo checkpoint/state để chịu lỗi. Đề hỏi cái nào ít vận hành nhất, nên câu trả lời phải là dịch vụ đã có sẵn cơ chế window và fault tolerance.

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

B — Amazon Managed Service for Apache Flink.

Apache Flink là engine xử lý luồng có windowing và stateful processing là tính năng gốc: các operator map, keyBy, aggregations, windows, joins đều được hỗ trợ sẵn. Cửa sổ 45 phút chỉ là một tham số khai báo, không phải thứ bạn phải tự dựng bằng tay bằng cách gom bản ghi vào một kho tạm nào đó.

Về fault tolerance, Flink có cơ chế checkpoint state của cửa sổ, nên khi một node hỏng giữa chừng, trạng thái tích luỹ 45 phút không mất trắng — đây đúng là điều đề yêu cầu và cũng là phần khó nhất nếu tự làm.

Về operational overhead, bản Managed Service của AWS lo phần chạy liên tục ứng dụng streaming và tự co giãn theo lượng dữ liệu đến. Bạn không quản lý cluster, không vá máy chủ, không tự viết logic scale. Đó là lý do nó thắng cả ba phương án còn lại theo đúng tiêu chí đề đặt ra.

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

A — Kinesis Data Firehose + Lambda transformation. Đây là phương án sai về bản chất, không chỉ sai về mức độ tiện. Firehose là dịch vụ delivery hoạt động theo cơ chế gom lô (buffering) trước khi ghi ra đích, nên nó chỉ phục vụ near real-time, không phải real-time như đề đòi. Ngoài ra, Lambda transformation trong Firehose chạy trên từng lô bản ghi đi qua và không giữ trạng thái giữa các lô — nó không có khái niệm cửa sổ 45 phút. Lambda này để làm sạch/biến đổi bản ghi, không phải để tổng hợp theo thời gian.

C — Kinesis Data Streams + Lambda consumer. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Kinesis Data Streams đúng là real-time, và Lambda map được vào stream (qua standard iterator dùng chung throughput, hoặc dedicated consumer với enhanced fan-out). Nhưng Lambda là stateless: mỗi lần gọi chỉ thấy lô bản ghi của chính nó. Muốn tổng hợp theo cửa sổ 45 phút, bạn phải tự viết code và tự dựng nơi lưu state trung gian, tự xử lý chuyện bản ghi đến trễ, tự lo khôi phục state khi hỏng. Toàn bộ phần đó là operational overhead mà đề bảo phải giảm thiểu — trong khi Flink cho sẵn.

D — Kinesis Data Streams + consumer app trên EC2. Cũng làm được, nhưng tệ hơn C ở tiêu chí của đề. Bạn vừa phải viết code windowing 45 phút giống hệt phương án C, vừa gánh thêm việc quản lý chính EC2 instance: giám sát, vá lỗi, co giãn, và tự lo phương án dự phòng khi instance chết — mà đề lại yêu cầu high fault tolerance. Đây là phương án nhiều việc vận hành nhất trong bốn phương án.

📌 Điểm cần nhớ

• Thấy "real-time" + aggregation theo cửa sổ thời gian (windowing) trong đề thi AWS Data Engineer, nghĩ ngay tới Amazon Managed Service for Apache Flink — nó là dịch vụ duy nhất trong hệ sinh thái Kinesis có windowing và stateful processing dựng sẵn.
• Phân biệt Kinesis Data Streams (real-time) với Kinesis Data Firehose (near real-time, gom lô để giao dữ liệu). Chỉ riêng chữ "real-time" trong đề đã đủ loại Firehose.
• Lambda là stateless — nó tuyệt vời cho biến đổi từng bản ghi, nhưng bất kỳ đề nào yêu cầu tích luỹ trạng thái qua một khoảng thời gian đều đang gợi ý bạn tránh Lambda.
• Cụm "minimizing the operational overhead" là tiêu chí xếp hạng, không phải tiêu chí loại trừ: khi nhiều phương án đều khả thi về kỹ thuật, hãy chọn cái mà AWS đã làm sẵn phần khó thay vì cái bạn phải tự viết code hoặc tự nuôi máy chủ.

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

Đề mô tả một hệ thống IoT thu thập clickstream events thời gian thực từ cảm biến nhúng trong thiết bị điện tử tiêu dùng. Điểm mấu chốt nằm ở hai cụm từ trong đoạn cuối:

• "Each of these groups would work independently and would need real-time access to this clickstream data" — ba nhóm (data science, thuật toán, dashboard) đều cần cùng một luồng dữ liệu, mỗi nhóm đọc riêng, không nhóm nào làm mất phần của nhóm kia.
• "provide a simultaneous feed of the data stream to the downstream applications" — dữ liệu phải được nhiều consumer đọc đồng thời và độc lập.

Đây chính là ràng buộc phân biệt các phương án. Cả bốn dịch vụ đều "xử lý được dữ liệu đến liên tục", nhưng chỉ một dịch vụ có mô hình stream có thể đọc lại, nhiều ứng dụng đọc song song trên cùng bản ghi. Cụm "capture the clickstream events from the source" cũng quan trọng: câu hỏi đòi lớp thu nhận (ingestion) chứ không phải lớp phân tích hay lớp nạp vào kho dữ liệu.

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

C — Amazon Kinesis Data Streams (KDS).

KDS là dịch vụ streaming thời gian thực, có độ bền và khả năng mở rộng lớn, thu nhận liên tục dữ liệu từ rất nhiều nguồn: clickstream của website, event stream của cơ sở dữ liệu, giao dịch tài chính, log IT, dữ liệu định vị — đúng loại nguồn mà đề mô tả. Dữ liệu thu được sẵn sàng cho tiêu thụ chỉ sau vài mili-giây, đủ cho các bài toán real-time dashboard, phát hiện bất thường, định giá động.

Điểm quyết định: KDS giữ bản ghi trong stream và cho phép nhiều Kinesis Application đọc cùng một stream đồng thời, độc lập với nhau, cũng như đọc lại (replay) bản ghi theo đúng thứ tự. Kinesis Client Library (KCL) đưa mọi bản ghi cùng một partition key về cùng một record processor, nên việc dựng nhiều ứng dụng đọc chung một stream (đếm, tổng hợp, lọc) trở nên dễ dàng. Đây chính xác là kịch bản AWS khuyến nghị dùng KDS: một ứng dụng cập nhật dashboard thời gian thực, một ứng dụng khác lưu trữ dữ liệu sang Amazon Redshift, cả hai đọc chung một stream đồng thời và độc lập.

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

A — Kinesis Data Analytics. Đây là dịch vụ phân tích dữ liệu streaming: viết truy vấn SQL hoặc ứng dụng Java trên luồng dữ liệu, với các toán tử và mẫu dựng sẵn để tổ chức, biến đổi, tổng hợp dữ liệu. Nó nằm sau lớp thu nhận — bạn phải chỉ cho nó nguồn streaming đã có, viết truy vấn, rồi chỉ định đích. Nó không phải nơi "capture the clickstream events from the source". Phương án này gần đúng ở chỗ nó thật sự làm việc với dữ liệu thời gian thực, nhưng hỏng ở vai trò: nó là một consumer/processor, không phải lớp lưu trữ luồng để nhiều nhóm cùng đọc.

B — Kinesis Data Firehose. Đây là cách đơn giản nhất để nạp dữ liệu streaming vào các kho dữ liệu và công cụ phân tích: S3, Redshift, Elasticsearch Service, Splunk. Nó tự động co giãn theo throughput, không cần quản trị, biết batch/nén/mã hoá trước khi ghi vào đích. Vấn đề: mô hình của Firehose là luồng chảy vào một đích đã cấu hình, phục vụ near real-time analytics trên đích đó — không phải mô hình để nhiều ứng dụng downstream cùng đăng ký đọc trực tiếp một cách độc lập. Vì Firehose dùng để load dữ liệu vào data store, nó không đáp ứng yêu cầu "simultaneous feed" của đề.

D — Amazon SQS. SQS là hàng đợi thông điệp quản lý toàn phần, dùng để tách rời và mở rộng microservices, hệ phân tán, ứng dụng serverless. Standard queue cho throughput tối đa, thứ tự best-effort, giao ít nhất một lần; FIFO queue đảm bảo xử lý đúng một lần theo đúng thứ tự gửi. Điểm chết ở đây là ngữ nghĩa hàng đợi: một thông điệp không thể được nhiều consumer khác nhau tiêu thụ cùng lúc — consumer nào lấy được thì thông điệp đó bị giấu đi rồi xoá. Ba nhóm trong đề sẽ tranh nhau bản ghi thay vì mỗi nhóm nhìn thấy toàn bộ dòng dữ liệu.

📌 Điểm cần nhớ

• Thấy cụm "multiple applications consume the same data concurrently and independently" (hoặc "simultaneous feed", "replay") → nghĩ ngay Kinesis Data Streams. Đây là dấu hiệu nhận biết mạnh nhất trong đề thi.
• Phân vai ba dịch vụ Kinesis trong cùng một đường ống: Data Streams = thu nhận và giữ luồng cho nhiều consumer; Data Firehose = nạp luồng vào đích lưu trữ/phân tích; Data Analytics = truy vấn, biến đổi, tổng hợp trên luồng.
• Phân biệt stream với queue: stream giữ bản ghi cho nhiều consumer đọc song song và đọc lại được; queue (SQS) giao thông điệp cho một consumer rồi xoá. Yêu cầu "fan-out cho nhiều nhóm độc lập" loại SQS ngay.
• Đọc kỹ động từ trong đề — capture from the source hỏi về lớp ingestion, analyze hỏi về lớp xử lý, load into hỏi về lớp giao dữ liệu tới đích. Chọn dịch vụ theo đúng lớp mà đề đang hỏi.

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

Một công ty đang chuyển dữ liệu từ data center on-premises lên AWS Cloud và dự định dùng nhiều thiết bị AWS Snow Family cùng lúc. Câu hỏi thu về đúng một điểm: thiết bị nào của Snow Family hỗ trợ tính năng storage clustering?

Cụm từ quyết định là "storage clustering" — tức khả năng ghép nhiều thiết bị lại thành một cụm (rack-mounted, gộp chung dung lượng và độ bền dữ liệu) thay vì mỗi thiết bị chạy độc lập. Chi tiết "multiple AWS Snow Family devices" ở câu đầu chỉ là bối cảnh dẫn dắt tới cụm từ này; đừng để nó kéo suy nghĩ sang "thiết bị nào chứa được nhiều dữ liệu nhất" — dung lượng và clustering là hai chuyện khác nhau.

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

D — AWS Snowball Edge Compute Optimized.

AWS Snowball Edge có hai biến thể thiết bị: Storage Optimized và Compute Optimized. Cả hai đều là thiết bị vừa làm data migration vừa làm edge computing, và cả hai đều có thể gắn rack rồi ghép cụm (cluster) với nhau để dựng một hạ tầng lưu trữ – tính toán tạm thời lớn hơn ngay tại chỗ, trước khi gửi thiết bị về AWS.

Bản Compute Optimized nghiêng về sức tính toán: nhiều vCPU hơn, có tuỳ chọn GPU cho các bài toán machine learning hay phân tích video ở nơi mạng chập chờn hoặc không có mạng. Bản Storage Optimized thì nghiêng về dung lượng lưu trữ block/object tương thích Amazon S3. Nhưng tiêu chí mà đề hỏi — storage clustering — thuộc về dòng Snowball Edge nói chung, nên D thoả mãn.

Lưu ý cách ra đề: trong danh sách phương án chỉ có một thiết bị thuộc dòng Snowball Edge, nên dù bản Storage Optimized cũng cluster được thì nó không xuất hiện để tranh chấp. D là lựa chọn duy nhất khớp.

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

A — AWS Snowcone. Đây là thiết bị nhỏ nhất trong Snow Family: gọn, bền, dễ mang theo, dùng để thu thập và chuyển dữ liệu về AWS bằng cách gửi thiết bị hoặc trực tuyến qua AWS DataSync. Nó là phương án gần đúng nhất theo nghĩa "cũng là Snow Family, cũng chuyển dữ liệu", nhưng Snowcone không có tuỳ chọn storage clustering — nó được thiết kế cho tình huống một thiết bị đơn lẻ ở nơi chật hẹp hoặc di động, không phải để dựng cụm.

B — AWS Snowmobile. Đây là container chở hàng dài 45 feet, dùng cho các đợt di chuyển quy mô nhiều petabyte đến exabyte và đóng cửa cả data center. Xe đến tận nơi và xuất hiện như một network-attached data store để truyền dữ liệu tốc độ cao, sau đó chạy về AWS Region để nạp vào Amazon S3. Đây là bẫy dễ mắc nhất: nghe "lớn nhất" nên tưởng "đầy đủ tính năng nhất". Nhưng Snowmobile không cung cấp tuỳ chọn storage clustering — bản thân nó đã là một khối lớn duy nhất, không phải mô hình ghép nhiều đơn vị nhỏ.

C — AWS Snowmobile Storage Compute. Dịch vụ này không tồn tại. Đây là tên bịa, ghép chữ từ "Snowmobile" với hậu tố "Storage/Compute" của Snowball Edge để đánh vào người nhớ mang máng. Gặp một tên nghe lạ mà không nằm trong danh mục Snow Family thật (Snowcone, Snowball Edge, Snowmobile) thì loại ngay.

📌 Điểm cần nhớ

• Snow Family gồm ba dòng thật: Snowcone (nhỏ, di động), Snowball Edge (hai biến thể Storage Optimized và Compute Optimized), Snowmobile (container quy mô rất lớn). Bất kỳ tên nào ngoài ba dòng này trong đề trắc nghiệm gần như chắc chắn là distractor.
• Storage clustering là đặc trưng của dòng Snowball Edge — các thiết bị này gắn rack và ghép cụm được để dựng hạ tầng tạm thời lớn hơn; Snowcone và Snowmobile thì không.
• Đừng suy tính năng theo kích cỡ thiết bị. Snowmobile lớn nhất nhưng không cluster được; "to hơn" không đồng nghĩa "nhiều tính năng hơn".
• Phân biệt hai biến thể Snowball Edge theo trọng tâm, không theo tính năng cluster: Compute Optimized thiên về vCPU và tuỳ chọn GPU cho ML / phân tích video ở môi trường mất kết nối; Storage Optimized thiên về dung lượng block và object storage tương thích S3 cho việc chuyển dữ liệu lớn. Khả năng ghép cụm thì cả hai đều có.

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

Đề mô tả một data warehouse chạy trên Amazon Redshift. Dữ liệu cũ hơn một năm sẽ được chuyển sang Amazon S3 để giảm chi phí, vì báo cáo phân tích hằng ngày chỉ dùng dữ liệu trong vòng một năm gần nhất.

Hai cụm từ quyết định đáp án nằm ở đây:

• "retain the ability to cross-reference this historical data along with the daily reports" — nhóm phân tích phải đối chiếu được dữ liệu lịch sử cùng lúc với dữ liệu nóng đang nằm trong Redshift. Nói cách khác, cần join được giữa dữ liệu trên S3 và bảng trong Redshift trong cùng một truy vấn SQL.
• "LEAST amount of effort and MINIMUM cost" — không được nạp lại dữ liệu vào Redshift, vì nạp là tốn cả công vận hành lẫn dung lượng lưu trữ trong cluster, đúng thứ mà bài toán đang muốn cắt bỏ.

Ràng buộc thứ nhất loại các phương án truy vấn tách rời hai kho; ràng buộc thứ hai loại các phương án phải nạp dữ liệu ngược trở lại. Chỉ một lựa chọn thoả cả hai.

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

Đáp án đúng: C — Amazon Redshift Spectrum.

Redshift Spectrum cho phép tạo external table trong Redshift trỏ thẳng tới dữ liệu có cấu trúc hoặc bán cấu trúc nằm trên S3, không cần nạp dữ liệu vào bảng Redshift. Dữ liệu lịch sử cứ nằm yên trên S3 với chi phí lưu trữ rẻ, còn cluster chỉ giữ dữ liệu một năm gần nhất.

Điểm mấu chốt khớp với đề: vì external table là đối tượng nhìn thấy được từ chính Redshift, nhóm phân tích viết một câu SQL duy nhất join bảng lịch sử trên S3 với bảng nóng trong cluster. Đây chính xác là yêu cầu "cross-reference" mà đề đặt ra.

Về chi phí và hiệu năng, Redshift Spectrum chạy trên lớp máy chủ chuyên dụng tách rời khỏi cluster của bạn, và đẩy phần lớn công việc nặng — lọc theo điều kiện (predicate filtering) và tổng hợp (aggregation) — xuống lớp Spectrum. Nhờ vậy truy vấn kiểu này tiêu tốn năng lực xử lý của cluster ít hơn nhiều so với truy vấn thông thường. Công sức triển khai cũng nhỏ nhất trong bốn lựa chọn: chỉ định nghĩa external schema và external table, không có ETL pipeline nào phải xây và bảo trì.

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

A — Dùng AWS Glue ETL job nạp dữ liệu lịch sử từ S3 vào Redshift, chạy xong truy vấn ad-hoc thì xoá đi. Phương án này vẫn cross-reference được, nên nó không sai về mặt chức năng — nó hỏng ở tiêu chí effort và cost. Bạn phải dựng và duy trì một Glue ETL job, rồi mỗi lần cần dữ liệu cũ lại nạp vào rồi xoá đi. Nạp dữ liệu lịch sử vào Redshift chỉ để phục vụ một quy trình ad-hoc một lần là tốn kém, trong khi Redshift Spectrum cho cùng kết quả với chi phí thấp hơn. Ngoài ra chu trình nạp–xoá lặp đi lặp lại đi ngược hẳn mục tiêu ban đầu là dọn dữ liệu cũ khỏi cluster.

B — Dùng lệnh COPY của Redshift nạp dữ liệu lịch sử từ S3 vào, chạy xong thì xoá. Đây là bản "ít công hơn" của A: COPY đơn giản hơn một Glue job thật, nhưng bản chất vẫn là nạp dữ liệu vào cluster. Tức là vẫn phải trả tiền lưu trữ và tài nguyên trong Redshift cho khối dữ liệu lịch sử, vẫn phải chờ quá trình nạp, và vẫn phải nhớ xoá sau khi dùng xong. Đề nói rõ mục đích chuyển sang S3 là để tiết kiệm chi phí, nên mọi phương án kéo dữ liệu trở lại đều tự mâu thuẫn với đề bài.

D — Truy vấn dữ liệu lịch sử bằng Amazon Athena, báo cáo hằng ngày vẫn chạy trên Redshift, khi cần đối chiếu thì xuất ra file phẳng rồi phân tích tiếp. Đây là phương án gần đúng nhất và cũng là bẫy chính. Athena là dịch vụ truy vấn tương tác, serverless, chạy SQL chuẩn trực tiếp trên dữ liệu S3 và chỉ trả tiền theo truy vấn — nghe rất hợp với dữ liệu lịch sử. Chỗ hỏng nằm ở vế sau của phương án: dữ liệu lịch sử ở một nơi (Athena/S3), báo cáo hằng ngày ở một nơi khác (Redshift), nên muốn đối chiếu thì phải xuất ra flat file rồi ghép tay. Đó là một bước thủ công lặp lại mỗi ngày, khó bảo trì và dễ sai — trái hẳn với yêu cầu "LEAST amount of effort". Spectrum bỏ được đúng bước thủ công đó vì nó đưa dữ liệu S3 vào ngay trong engine đang chạy báo cáo.

📌 Điểm cần nhớ

• Thấy đề nêu "query dữ liệu trên S3 mà không cần nạp vào Redshift" kèm nhu cầu join với bảng đang có trong cluster → gần như chắc chắn là Redshift Spectrum.
• Redshift Spectrum và Athena đều đọc SQL trực tiếp trên S3; điểm phân biệt là nơi chạy truy vấn. Cần kết hợp dữ liệu S3 với dữ liệu trong Redshift trong cùng một câu lệnh → Spectrum. Chỉ phân tích dữ liệu S3 độc lập, không dính tới cluster → Athena.
• Khi đề đã nói rõ mục tiêu là giảm chi phí bằng cách đưa dữ liệu ra khỏi kho, mọi phương án nạp ngược dữ liệu vào kho (COPY, Glue ETL) đều tự phản lại đề — kể cả khi chúng cho ra kết quả truy vấn đúng.
• Cụm "LEAST effort / MINIMUM cost" là tín hiệu ưu tiên giải pháp không có ETL pipeline và không có bước thủ công định kỳ; một phương án đòi xuất file rồi ghép tay hầu như luôn là đáp án sai trong dạng đề này.

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

Đề mô tả một công ty dịch vụ tài chính phải lưu activity logs của khách hàng để đáp ứng yêu cầu tuân thủ. Có bốn ràng buộc được nêu ra, nhưng chỉ hai trong số đó thực sự phân biệt được các phương án:

• "retain the logs for 5-10 years" — dữ liệu lưu rất lâu, đọc gần như không bao giờ, chỉ khi bị audit.
• "data size is expected to be in Petabytes" — quy mô lớn, nên chi phí lưu trữ mỗi GB-tháng là thứ chi phối tổng hoá đơn, chứ không phải chi phí lấy dữ liệu ra.
• "accessible within a timeframe of up to 48 hours" — đây là cụm từ quyết định. Người ra đề cố tình nới lỏng thời gian truy xuất tới tận 48 giờ, tức là chấp nhận độ trễ tính bằng ngày.
• "MOST cost-effective" — trong bốn phương án đều là S3 và đều "highly available and durable", nên tiêu chí lựa chọn duy nhất còn lại là giá.

Ghép ba mảnh lại: dữ liệu khổng lồ + gần như không đọc + chấp nhận chờ tới 48 giờ ⇒ chọn storage class có giá lưu trữ thấp nhất, kể cả khi nó chậm nhất.

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

D. Amazon S3 Glacier Deep Archive.

Đây là storage class dành riêng cho dữ liệu lưu trữ dài hạn, chỉ được truy cập một tới hai lần mỗi năm — đúng khớp với hồ sơ tuân thủ chỉ mở ra khi có audit. Trong toàn bộ họ storage class của S3, Glacier Deep Archive có giá lưu trữ mỗi GB-tháng thấp nhất, thấp hơn cả S3 Glacier Flexible Retrieval, và được AWS định vị là phương án thay thế cho băng từ lưu ngoài trung tâm dữ liệu.

Về thời gian lấy dữ liệu: Deep Archive trả dữ liệu trong khoảng 12 giờ với Standard retrieval, và với Bulk retrieval thì dữ liệu về trong vòng 48 giờ. Yêu cầu "up to 48 hours" của đề vừa đủ nằm trong khả năng của storage class này — nói cách khác, đề đã được viết để khớp chính xác với biên độ chậm nhất của Deep Archive. Vì cả bốn phương án đều nằm trên S3 nên độ bền và tính sẵn sàng đều đạt yêu cầu, và tiêu chí "MOST cost-effective" đẩy lựa chọn về phía lớp rẻ nhất.

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

A. Amazon S3 Glacier Flexible Retrieval — đây là phương án gần đúng nhất và là bẫy chính. Nó cũng là archive class, cũng rẻ, và bulk retrieval của nó cũng nằm trong ngưỡng 48 giờ. Chỗ nó hỏng: Flexible Retrieval được thiết kế cho trường hợp một phần dữ liệu có thể cần lấy ra trong vài phút (expedited retrieval), và bạn phải trả cho khả năng nhanh đó bằng giá lưu trữ cao hơn Deep Archive. Đề bài không hề đòi hỏi lấy dữ liệu trong vài phút — nó nói rõ chấp nhận tới 48 giờ. Trả tiền cho tốc độ mình không dùng, trên quy mô Petabyte, thì không còn là "most cost-effective".

B. Amazon S3 Glacier Instant Retrieval — class này dành cho dữ liệu hiếm khi truy cập nhưng khi cần thì phải có ngay lập tức, với độ trễ mili-giây tương đương S3 Standard-IA. Nó rẻ hơn S3 Standard-IA nhưng vẫn đắt hơn Deep Archive cả về lưu trữ lẫn chi phí truy cập dữ liệu. Chọn nó nghĩa là mua độ trễ mili-giây cho dữ liệu mà đề nói rõ là chờ hai ngày cũng được.

C. Amazon S3 Standard storage — sai rõ ràng nhất. Standard là class cho dữ liệu truy cập thường xuyên, giá lưu trữ mỗi GB-tháng cao nhất trong nhóm này. Với Petabyte dữ liệu giữ 5–10 năm mà gần như không ai đọc, đây là phương án đắt nhất theo cấp số nhân. Yêu cầu truy xuất được nới tới 48 giờ chính là tín hiệu đề bài phát ra để loại Standard ngay từ đầu.

📌 Điểm cần nhớ

• Thời gian truy xuất cho phép là chiếc chìa khoá chọn S3 storage class. Đọc thấy "milliseconds" → Instant Retrieval hoặc Standard-IA; "vài phút" → Flexible Retrieval; "vài giờ tới 48 giờ" → Deep Archive.
• Trong họ S3, S3 Glacier Deep Archive là lớp có giá lưu trữ thấp nhất; đổi lại nó có thời gian lấy dữ liệu dài nhất và thời gian lưu tối thiểu dài nhất.
• Khi đề nhấn "MOST cost-effective" kèm khối lượng dữ liệu rất lớn và tần suất đọc rất thấp, chi phí lưu trữ áp đảo chi phí truy xuất — chọn lớp rẻ nhất còn đáp ứng được deadline truy xuất, đừng chọn lớp nhanh hơn mức cần thiết.
• Bốn phương án cùng nằm trên S3 nghĩa là độ bền và tính sẵn sàng không phải tiêu chí phân biệt; đừng để cụm "highly available and durable" trong đề đánh lạc hướng sang S3 Standard.

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

Đề mô tả một công ty có dữ liệu nằm rải ở bốn nơi: file JSON và .csv trong Amazon S3, Amazon RDS for Microsoft SQL Server, Amazon DynamoDB (provisioned capacity mode) và một cluster Amazon Redshift. Yêu cầu: cho các data scientist truy vấn tất cả các nguồn này bằng cú pháp giống SQL.

Cụm từ quyết định đáp án là "least operational overhead" — ít công vận hành nhất. Cả bốn phương án đều bắt đầu giống hệt nhau (dùng AWS Glue crawler + Glue Data Catalog), nên điểm khác biệt duy nhất nằm ở nửa sau: dùng công cụ truy vấn nào, và có phải làm thêm bước biến đổi dữ liệu hay không. Ràng buộc thứ hai đáng chú ý là dữ liệu để nguyên tại chỗ ở nhiều nguồn khác nhau — nghĩa là cần khả năng truy vấn liên nguồn (federated query), chứ không phải gom hết về một định dạng.

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

Đáp án đúng theo tệp là A: dùng Glue crawler nạp metadata vào Glue Data Catalog, rồi truy vấn bằng Amazon Athena — SQL chuẩn cho nguồn có cấu trúc, PartiQL cho dữ liệu JSON.

Athena là dịch vụ serverless: không có cluster nào để dựng, để chỉnh cỡ hay để tắt bật, nên phần "operational overhead" gần như bằng không. Với dữ liệu ngoài S3, Athena Federated Query dùng các data source connector chạy trên AWS Lambda để dịch giữa Athena và nguồn đích; AWS có sẵn connector dựng trước cho DynamoDB và cho các nguồn quan hệ tương thích JDBC như RDS. Athena còn hỗ trợ federated query pass-through, cho phép đẩy nguyên câu truy vấn xuống nguồn gốc để tận dụng ngôn ngữ và khả năng riêng của nó — với DynamoDB thì đó chính là PartiQL.

Kết quả: một điểm truy vấn duy nhất, cú pháp SQL-like, dữ liệu để nguyên tại chỗ, không phải xây dựng thêm đường ống nào.

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

• B — Glue job đổi JSON sang .csv rồi query bằng Athena: đây là phương án gần đúng nhất vì đích đến vẫn là Athena, nhưng nó thêm hẳn một bước ETL không cần thiết. Athena vốn đọc được JSON trực tiếp, nên việc chuyển đổi chỉ tạo thêm job phải viết, phải lập lịch, phải theo dõi khi hỏng — đúng thứ mà "least operational overhead" loại ra. Ngoài ra nó cũng không giải quyết được phần dữ liệu nằm trong RDS, DynamoDB và Redshift.

• C — Dùng Amazon Redshift Spectrum thay Athena: cũng gần đúng, vì Redshift Spectrum cũng đọc Glue Data Catalog và cũng chạy SQL trên dữ liệu ở S3. Chỗ hỏng là Redshift Spectrum phải có một cluster Redshift làm điểm vào — tức là phải dựng, cấu hình và duy trì hạ tầng đó. So với Athena serverless, đây rõ ràng là nhiều công vận hành hơn, nên thua ở đúng tiêu chí đề đặt ra.

• D — Glue job đổi cả JSON lẫn .csv sang parquet rồi query bằng Athena: hỏng cùng kiểu với B, thậm chí nặng hơn vì phải biến đổi cả hai định dạng. Chuyển sang parquet là kỹ thuật tối ưu hiệu năng và chi phí quét dữ liệu hợp lệ trong nhiều bối cảnh, nhưng đề không hỏi về hiệu năng — đề hỏi về công vận hành ít nhất. Thêm một tầng ETL để giải một bài toán mà Athena đọc thẳng được là việc thừa.

📌 Điểm cần nhớ

• Khi đề nhấn "least operational overhead" và các phương án chỉ khác nhau ở công cụ truy vấn, ưu tiên dịch vụ serverless: Athena không cần cluster, Redshift Spectrum thì cần.
• Athena Federated Query (connector chạy trên Lambda) là câu trả lời mặc định cho bài toán "truy vấn nhiều nguồn khác nhau bằng SQL mà không di chuyển dữ liệu" — có sẵn connector cho DynamoDB và các nguồn JDBC như RDS.
• PartiQL là ngôn ngữ để truy vấn dữ liệu bán cấu trúc/JSON và DynamoDB; thấy JSON + DynamoDB trong đề thì PartiQL thường là mảnh ghép đúng.
• Mọi phương án chèn thêm một Glue job biến đổi định dạng (sang .csv hay parquet) đều làm tăng công vận hành. Nó chỉ đúng khi đề hỏi về hiệu năng hoặc chi phí quét dữ liệu, không đúng khi đề hỏi về vận hành nhẹ nhàng.

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

Đề mô tả một công ty truyền thông có khoảng 8 TB dữ liệu nằm trong data center on-premises, gồm đủ loại định dạng (video, text, ảnh…), muốn đưa lên Amazon S3. Có ba ràng buộc quan trọng nằm ngay trong đề:

• "on-premises data center → Amazon S3": đây là bài toán di chuyển dữ liệu từ hạ tầng riêng lên AWS, không phải bài toán tăng tốc truy cập hay biến đổi dữ liệu.
• "Approximately 2% of the data changes every day and needs to be updated to Amazon S3": không phải chuyển một lần rồi thôi. Cần cơ chế chuyển liên tục, chỉ phần thay đổi, tức là đồng bộ gia tăng.
• "automate the entire process to run on a schedule" và "MOST operationally efficient": dịch vụ phải tự có lịch chạy và tự làm phần việc nặng, chứ không phải thứ mà ta phải tự dựng thêm nhiều mảnh hạ tầng mới dùng được.

Cụm quyết định đáp án chính là "on-premises → S3, thay đổi hằng ngày, theo lịch, ít vận hành nhất". Ba yếu tố này gộp lại chỉ đúng một loại dịch vụ: dịch vụ truyền/đồng bộ dữ liệu giữa on-premises và AWS Storage.

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

D — AWS DataSync

DataSync là dịch vụ trực tuyến chuyên để tự động hoá và tăng tốc việc di chuyển dữ liệu giữa on-premises và các dịch vụ lưu trữ của AWS. Nó đọc được từ NFS share, SMB share, HDFS, self-managed object storage… và ghi sang Amazon S3, Amazon EFS, các loại Amazon FSx (Windows File Server, Lustre, OpenZFS, NetApp ONTAP).

Đúng với từng ràng buộc của đề:

• Nguồn là hệ thống file on-premises với đủ loại định dạng — DataSync làm việc ở mức file/object, nó không quan tâm bên trong là video hay text, nên "multiple other formats" không phải vấn đề.
• Nó hỗ trợ ongoing transfers (chuyển liên tục, lặp lại) chứ không chỉ một lần, đúng cho phần 2% dữ liệu đổi mỗi ngày.
• Nó có sẵn khả năng chạy theo lịch, nên yêu cầu "automate the entire process to run on a schedule" được đáp ứng bằng chính cấu hình của dịch vụ, không cần viết thêm hệ thống điều phối.

Vì phần lớn công việc nặng (dò tìm thay đổi, truyền song song, xác thực dữ liệu, lập lịch) do dịch vụ lo, đây là phương án operationally efficient nhất trong bốn lựa chọn.

❌ 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à cũng dễ chọn nhầm nhất, vì Glue đúng là có job chạy theo lịch. Nhưng Glue sinh ra để ETL — trích xuất, biến đổi, nạp dữ liệu có cấu trúc — chứ không phải để đồng bộ khối file nhị phân. Muốn Glue đọc được dữ liệu nằm trong data center riêng thì phải dựng thêm cả một chuỗi hạ tầng: kết nối VPN hoặc AWS Direct Connect, JDBC connection, cấu hình elastic network interfaces (ENIs) cùng security group của chúng, rồi nhiều bước thiết lập khác. Đề hỏi "MOST operationally efficient", mà Glue lại là phương án tốn công vận hành nhất — nó hỏng đúng ở chữ đó.

B — Amazon S3 Transfer Acceleration Cũng liên quan tới S3 và cũng nói chuyện "nhanh hơn", nên trông có vẻ hợp lý. Nhưng đây là tính năng tối ưu tốc độ truy cập, dùng edge location để tăng tốc việc tải lên/tải xuống object lớn ở khoảng cách xa. Nó không tự phát hiện file nào đã đổi, không có lịch chạy, không tự động hoá quy trình — bạn vẫn phải có một công cụ khác đứng ra quyết định chuyển cái gì và chuyển khi nào. Đề cần một dịch vụ migration, không phải một bộ tăng tốc đường truyền.

C — AWS Global Accelerator Đây là dịch vụ networking cho ứng dụng công khai: nó cấp hai địa chỉ IP tĩnh toàn cầu làm cửa vào cố định, trỏ tới các endpoint như Application Load Balancer, Network Load Balancer, EC2 instance hay elastic IP, nhằm cải thiện tính sẵn sàng và độ trễ khi người dùng truy cập ứng dụng. Nó hoàn toàn không phải công cụ di chuyển dữ liệu, và cũng không có khái niệm đồng bộ file lên S3. Phương án này lạc hẳn chủ đề, chỉ giống các phương án kia ở chỗ cùng có chữ "accelerator".

📌 Điểm cần nhớ

• Đọc thấy on-premises → dịch vụ lưu trữ AWS (S3/EFS/FSx), lặp lại hoặc theo lịch thì gần như luôn là AWS DataSync. Đây là dấu hiệu nhận dạng mạnh nhất của dịch vụ này.
• Phân biệt rõ ba nhóm dễ lẫn: DataSync = di chuyển dữ liệu, S3 Transfer Acceleration = tăng tốc truy cập object trên S3, Global Accelerator = tăng tốc và ổn định đường mạng tới ứng dụng public. Hai cái sau không di chuyển dữ liệu giúp bạn.
• Glue là ETL, không phải công cụ đồng bộ file. Khi nguồn nằm on-premises, Glue kéo theo VPN/Direct Connect, JDBC, ENI — hễ đề nhấn "most operationally efficient" thì đó là điểm trừ, không phải điểm cộng.
• Cụm "changes every day / ongoing / on a schedule" trong đề là tín hiệu loại bỏ mọi phương án chỉ chuyển được một lần hoặc cần người điều phối thủ công.

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

Bộ phận HR cần một dashboard trực quan hoá dữ liệu tuyển dụng theo lịch sử. Ba ràng buộc được nêu ra, và chính chúng quyết định đáp án:

1. "Access to all dashboards should be through Microsoft Active Directory" — người dùng phải đăng nhập bằng danh tính Active Directory sẵn có của công ty, không tạo tài khoản riêng trong công cụ BI.
2. "encrypting data-in-transit and at-rest" — bắt buộc mã hoá cả trên đường truyền lẫn khi lưu trữ.
3. Ngầm định qua các phương án: chọn edition nào của Amazon QuickSight, và cấu hình khoá mã hoá ra sao.

Cụm từ quyết định là "Microsoft Active Directory" đi kèm "at-rest". Cả bốn phương án đều dùng Amazon QuickSight, nên câu hỏi thực chất chỉ hỏi hai điều: Standard hay Enterprise? và khoá do AWS quản lý hay khoá tự nhập vào AWS KMS?

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

Phương án A — QuickSight Enterprise edition, identity federation bằng SAML 2.0, dùng cấu hình mã hoá mặc định.

• Enterprise edition là bản tích hợp được với thư mục danh tính sẵn có, gồm Microsoft Active Directory và single sign-on qua SAML. Đây là edition duy nhất trong các lựa chọn thoả mãn yêu cầu đăng nhập qua Active Directory ở mức đầy đủ.
• SAML 2.0 federation cho phép người dùng đăng nhập bằng chính danh tính doanh nghiệp của họ. Identity provider (ví dụ Microsoft Active Directory Federation Services, Okta, Ping One Federation Server) chịu trách nhiệm xác thực, còn IAM ánh xạ danh tính đó sang QuickSight. Người dùng bấm một lần là vào thẳng dashboard, và việc ai được vào QuickSight vẫn do IdP của công ty kiểm soát.
• Mã hoá: Enterprise edition cung cấp thêm mã hoá at-rest, và mã hoá in-transit vốn có sẵn. Vì vậy cấu hình mặc định đã đủ — không cần thao tác thêm gì về khoá.

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

B — Standard edition + SAML 2.0 + mã hoá mặc định. Đây là phương án gần đúng nhất, vì QuickSight hỗ trợ identity federation ở cả Standard lẫn Enterprise, nên nửa đầu của phương án nghe hoàn toàn hợp lý. Chỗ hỏng nằm ở edition: Standard edition không tích hợp với Microsoft Active Directory, và không có mã hoá at-rest. Nó trượt cả hai ràng buộc chính của đề cùng lúc.

C — Standard edition + AD Connector + khoá tự nhập vào AWS KMS. Sai gấp đôi. Thứ nhất, vẫn là Standard edition, nên vẫn vướng đúng hai vấn đề của phương án B: không tích hợp Active Directory, không có mã hoá at-rest. Thứ hai, phần cấu hình khoá là bất khả thi — mọi khoá liên quan tới QuickSight đều do AWS quản lý, người dùng không nhập khoá của mình vào để QuickSight dùng.

D — Enterprise edition + AD Connector + khoá tự nhập vào AWS KMS. Phương án này chọn đúng edition, nên trông rất hợp lý và là bẫy chính của câu hỏi. Nhưng nó hỏng ở vế mã hoá: QuickSight không cho phép chỉ định khoá do khách hàng cung cấp — toàn bộ khoá gắn với QuickSight đều nằm dưới sự quản lý của AWS. Yêu cầu "customer-provided keys imported into AWS KMS" không phải là thứ bạn cấu hình được cho QuickSight, nên dù edition đúng thì cả phương án vẫn sai.

📌 Điểm cần nhớ

• Standard vs Enterprise là ranh giới hay được hỏi nhất về QuickSight. Hễ đề nhắc tới Microsoft Active Directory hoặc encryption at rest, câu trả lời phải là Enterprise edition. Standard không có cả hai.
• Identity federation bằng SAML 2.0 có ở cả hai edition — nên chỉ riêng cụm "SAML" không đủ để loại một phương án. Phải đọc tiếp xem edition là gì.
• Khoá mã hoá của QuickSight do AWS quản lý. Bất kỳ phương án nào nói "customer-provided keys imported into AWS KMS" cho QuickSight đều loại được ngay, không cần đọc phần còn lại.
• Khi đề đã nêu yêu cầu mã hoá mà phương án đúng lại ghi "default encryption settings", đó không phải là thiếu sót — với Enterprise edition thì mặc định đã bao gồm mã hoá at-rest và in-transit.

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

Đề hỏi dịch vụ AWS nào vừa thu nhận (capture) clickstream event từ nguồn, vừa cung cấp một luồng dữ liệu song song (concurrent feed) cho nhiều ứng dụng phía sau, với yêu cầu tính sẵn sàng cao và chịu lỗi.

Cụm từ quyết định là "provide a concurrent feed of the data stream to the downstream applications" — tức là nhiều ứng dụng tiêu thụ cùng một luồng dữ liệu, đồng thời và độc lập với nhau. Đây chính là ràng buộc tách bốn phương án ra: cả ba phương án còn lại đều dính dáng tới dữ liệu streaming, nhưng không cái nào cho phép nhiều consumer cùng đọc chung một stream một cách độc lập.

Cụm thứ hai đáng chú ý là "capture ... from the source" — vai trò ở đây là thu nhận và giữ luồng, chứ không phải phân tích hay nạp vào kho đích.

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

D — Amazon Kinesis Data Streams (KDS) là dịch vụ streaming thời gian thực, có khả năng mở rộng lớn và bền vững, được thiết kế đúng cho việc thu nhận liên tục các nguồn như website clickstream, database event stream, giao dịch tài chính, log IT, dữ liệu vị trí.

Điểm mấu chốt khớp với đề: KDS được khuyến nghị khi bạn cần nhiều ứng dụng cùng tiêu thụ một stream đồng thời. Ví dụ điển hình là một ứng dụng cập nhật dashboard thời gian thực trong khi ứng dụng khác lưu trữ dữ liệu sang Amazon Redshift — cả hai đọc cùng một stream, song song và độc lập.

Ngoài ra KDS bảo đảm thứ tự bản ghi, cho phép đọc lại (replay) bản ghi theo đúng thứ tự cũ cho nhiều ứng dụng Kinesis khác nhau. Kinesis Client Library (KCL) đưa mọi bản ghi cùng một partition key về cùng một record processor, giúp dựng nhiều ứng dụng đọc chung stream để đếm, tổng hợp, lọc. Dữ liệu thu về sẵn sàng trong vòng mili-giây, phục vụ dashboard thời gian thực, phát hiện bất thường, định giá động.

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

A — Amazon Kinesis Data Firehose. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: nó cũng nhận dữ liệu streaming, cũng được quản lý hoàn toàn, cũng tự co giãn theo throughput. Chỗ nó hỏng là vai trò: Firehose là đường nạp (load) dữ liệu streaming vào các data store và công cụ phân tích — Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, Splunk — có thể batch, nén, mã hoá trước khi ghi. Nó là ống dẫn tới đích, không phải một luồng để nhiều ứng dụng downstream cùng cắm vào đọc song song, và cũng không có khái niệm replay bản ghi như KDS. Đề yêu cầu "concurrent feed to downstream applications", không phải "load vào kho đích".

B — Amazon Simple Queue Service (SQS). Là dịch vụ hàng đợi tin nhắn được quản lý, dùng để tách rời và mở rộng microservice, hệ phân tán, ứng dụng serverless. Standard queue cho throughput tối đa, thứ tự best-effort, giao ít nhất một lần; FIFO queue bảo đảm xử lý đúng một lần theo đúng thứ tự gửi. Nhưng với SQS, một message không thể được nhiều consumer tiêu thụ cùng lúc — đọc xong là message bị ẩn rồi xoá. Mô hình đó ngược hẳn với yêu cầu "concurrent feed" trong đề.

C — Amazon Kinesis Data Analytics. Đây là công cụ phân tích dữ liệu streaming theo thời gian thực: viết truy vấn SQL hoặc ứng dụng Java để tổ chức, biến đổi, tổng hợp, phân tích dữ liệu. Nó nằm ở vị trí người tiêu thụ stream chứ không phải nơi thu nhận và phân phát stream; bản thân nó cần một nguồn streaming được thiết lập trước. Chọn nó là nhầm tầng xử lý với tầng thu nhận.

📌 Điểm cần nhớ

• Nhiều consumer đọc song song, độc lập, có thứ tự và replay được → Kinesis Data Streams. Đây là dấu hiệu nhận dạng gần như tuyệt đối trong đề thi.
• Firehose = load vào data store (S3, Redshift, Elasticsearch Service, Splunk); Data Streams = xử lý streaming thời gian thực. Thấy đích đến là một kho dữ liệu thì nghĩ Firehose; thấy "downstream applications" số nhiều thì nghĩ Data Streams.
• Kinesis Data Analytics là tầng phân tích, đứng sau một nguồn stream — đừng chọn nó khi đề hỏi cái gì thu nhận dữ liệu.
• SQS không cho nhiều consumer đọc cùng một message. Hàng đợi để tách rời thành phần, không phải để fan-out một luồng sự kiện tới nhiều ứng dụng đọc đồng thời.