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

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

Đề mô tả một công ty ad-tech chuyển hạ tầng on-premises lên AWS. Ứng dụng chủ lực dùng một database PostgreSQL rất lớn, và team muốn cài database đó trên EC2 instance với loại storage tối ưu cho EBS volume gắn kèm.

Cụm từ quyết định đáp án nằm gọn trong một vế: "maintain consistent performance with high IOPS" — hiệu năng ổn định (consistent) kèm IOPS cao. Hai chữ này phải đọc cùng nhau:

• high IOPS loại ngay nhóm HDD, vì HDD được thiết kế cho throughput (MiB/s) chứ không phải IOPS.
• consistent loại nốt phương án SSD còn lại không cam kết mức IOPS cố định.

Thêm một chi tiết nữa: đề nói massive database. Đây là dấu hiệu khối lượng công việc transactional nặng, nhiều thao tác đọc/ghi nhỏ và liên tục — đúng đặc trưng workload mà EBS phân loại là "IOPS-dominant".

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

Đáp án đúng theo tệp là A — Amazon EC2 với EBS volume loại Provisioned IOPS SSD (io1).

EBS chia volume thành hai nhóm theo đặc tính hiệu năng:

• SSD-backed: tối ưu cho workload transactional, thao tác đọc/ghi thường xuyên với I/O size nhỏ, nơi IOPS là chỉ số hiệu năng chi phối.
• HDD-backed: tối ưu cho workload streaming lớn, nơi throughput (MiB/s) mới là thước đo phù hợp chứ không phải IOPS.

PostgreSQL chạy trên EC2 rơi vào nhóm thứ nhất. Trong nhóm SSD, io1 là loại duy nhất cho phép khai báo (provision) trước mức IOPS mong muốn và AWS cam kết duy trì đúng mức đó — chính là chữ "consistent" mà đề yêu cầu. io1 được AWS định vị cho các ứng dụng nghiệp vụ quan trọng cần IOPS bền vững, và tài liệu liệt kê thẳng nhóm database lớn làm ví dụ: MongoDB, Cassandra, Microsoft SQL Server, MySQL, PostgreSQL, Oracle. Đề bài gần như trùng khớp từng chữ với mô tả use case này.

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

B — Throughput Optimized HDD (st1)

Đây là volume HDD-backed, tối ưu cho throughput với workload streaming truy cập tuần tự — log processing, data warehouse quét khối lượng lớn, big data. Nó có hiệu năng tốt, nhưng tốt ở chiều đo khác hẳn cái đề hỏi. Database PostgreSQL đọc/ghi ngẫu nhiên với I/O size nhỏ, đúng kiểu mà HDD xử lý kém nhất. Chọn st1 là tối ưu sai chỉ số.

C — Cold HDD (sc1)

Cũng là HDD-backed, và nằm ở đáy bảng hiệu năng — thiết kế cho dữ liệu ít truy cập, ưu tiên chi phí thấp trên mỗi GB. Đây là phương án xa yêu cầu nhất: vừa sai nhóm (HDD, không phải IOPS-oriented), vừa sai mục đích (dữ liệu lạnh, trong khi đề nói database đang chạy sản xuất cho ứng dụng chủ lực).

D — General Purpose SSD (gp2)

Đây là phương án gần đúng nhất và là bẫy thật sự của câu này. gp2 đúng nhóm SSD, đúng định hướng IOPS, và trên thực tế phục vụ được rất nhiều database. Nó hỏng ở chữ "consistent": gp2 không cho phép khai báo mức IOPS mong muốn — hiệu năng cơ sở gắn với dung lượng volume, và phần vượt lên trên mức đó dựa vào cơ chế tích luỹ credit. Khi credit cạn vì tải nặng kéo dài, volume tụt về mức baseline. Với một "massive" PostgreSQL chạy liên tục, đó chính là kiểu tụt hiệu năng khó lường mà đề yêu cầu tránh. Ngoài ra, khi nhu cầu vượt ngưỡng mà một volume general purpose phục vụ được, io1 là loại được AWS chỉ định để đi tiếp — gp2 không có cách nào "đặt hàng" một con số IOPS cụ thể.

📌 Điểm cần nhớ

• Đọc chỉ số hiệu năng mà đề nêu ra trước khi chọn volume: nhắc tới IOPS thì nhìn nhóm SSD (gp2, io1); nhắc tới throughput MiB/s hoặc dữ liệu streaming tuần tự thì nhìn nhóm HDD (st1, sc1). Đây là bước lọc nhanh nhất, cắt ngay một nửa số phương án.
• "Consistent / sustained / predictable IOPS" là từ khoá riêng của Provisioned IOPS SSD. Chỉ io1 (và họ Provisioned IOPS nói chung) cho phép khai báo trước mức IOPS và giữ đúng mức đó; gp2 thì hiệu năng phụ thuộc dung lượng và cơ chế credit.
• Database transactional trên EC2 = SSD, vì đặc trưng I/O là nhiều thao tác nhỏ, ngẫu nhiên, liên tục. AWS liệt kê thẳng PostgreSQL, MySQL, Oracle, SQL Server, MongoDB, Cassandra trong nhóm use case của Provisioned IOPS.
• Phân biệt st1 với sc1 để không mất điểm ở câu khác: cả hai đều là HDD, nhưng st1 dành cho dữ liệu truy cập thường xuyên theo kiểu streaming, còn sc1 dành cho dữ liệu lạnh, ít truy cập, ưu tiên giá rẻ. Đề nào nói "infrequently accessed" thì đó là sc1.

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

Một công ty thương mại điện tử đang dùng Amazon Kinesis Data Streams để thu clickstream thời gian thực từ website. Yêu cầu gồm ba phần:

1. Phân tích near real-time dữ liệu streaming,
2. Kết hợp nó với dữ liệu của ngày hôm trước (tức là dữ liệu đã nằm sẵn trong kho),
3. Dữ liệu streaming phải được lưu trong Amazon Redshift Serverless.

Cụm từ quyết định đáp án là "LEAST operational overhead" đi kèm ràng buộc "stored in Amazon Redshift Serverless". Cả bốn phương án đều xoay quanh Redshift, nên điều phân biệt chúng không phải là "có chạy được không" mà là: phương án nào thực sự đưa dữ liệu từ Kinesis Data Streams vào trong Redshift với ít mắt xích trung gian nhất. Hai phương án đầu tiên bị loại vì bản chất là query dữ liệu ở nơi khác chứ không lưu vào Redshift; phương án còn lại bị loại vì thêm một chặng dịch vụ không cần thiết.

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

Đáp án đúng: C — Use the streaming ingestion feature of Amazon Redshift.

Streaming ingestion là tính năng cho phép Redshift (cả bản provisioned lẫn Redshift Serverless) nhận trực tiếp dữ liệu từ Kinesis Data Streams hoặc Amazon MSK vào một materialized view. Sau khi cấu hình, việc refresh materialized view sẽ nạp dữ liệu stream vào kho với độ trễ thấp và thông lượng cao.

Nó khớp chính xác cả ba yêu cầu của đề:

• Near real-time analytics: đây đúng là use case mà tính năng này nhắm tới — dữ liệu sinh liên tục (IoT, telemetry, clickstream) và phải xử lý ngay sau khi sinh ra.
• Kết hợp với dữ liệu hôm trước: vì dữ liệu stream nằm trong một materialized view bên trong Redshift, ta join nó với các bảng lịch sử sẵn có bằng SQL thông thường.
• Ít vận hành nhất: cấu hình này bỏ qua hàng loạt bước trung gian — không cần đẩy qua Data Firehose, không cần đáp dữ liệu xuống S3, và không cần viết/chạy lệnh COPY, vì materialized view được refresh thẳng từ stream.

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

A — Federated queries của Amazon Redshift. Federated query cho phép Redshift truy vấn live data trong các cơ sở dữ liệu vận hành bên ngoài (kiểu RDS/Aurora), kết hợp với dữ liệu trong Redshift và S3. Nó là công cụ đọc dữ liệu từ database, không phải từ một stream. Kinesis Data Streams không phải là nguồn mà federated query kết nối tới được, nên phương án này không hề đưa clickstream vào Redshift — đây là distractor thuần túy.

B — Đẩy Kinesis Data Streams sang Kinesis Data Firehose rồi dùng tích hợp Firehose → Redshift Serverless. Đây là phương án gần đúng nhất, và nó thực sự chạy được: dữ liệu cuối cùng vẫn vào được Redshift Serverless. Chỗ nó hỏng nằm ở đúng tiêu chí mà đề nhấn mạnh — LEAST operational overhead. Phương án này thêm một hop không cần thiết (một delivery stream nữa phải tạo, cấu hình, giám sát và trả tiền), trong khi streaming ingestion cho phép đi thẳng từ Kinesis Data Streams vào Redshift. Khi đề so sánh hai giải pháp cùng đạt kết quả, số mắt xích phải vận hành chính là thứ phân định.

D — Amazon Redshift Spectrum. Spectrum dùng để truy vấn dữ liệu có cấu trúc và bán cấu trúc trong các file nằm trên Amazon S3, mà không cần load vào bảng Redshift. Hai vấn đề: (1) nguồn của nó là file trên S3, không phải stream — Spectrum không xử lý được dữ liệu streaming từ nguồn ngoài; (2) ngay cả khi có dữ liệu trên S3, Spectrum không lưu dữ liệu vào Redshift, trong khi đề yêu cầu rõ dữ liệu streaming phải được lưu trong Redshift Serverless.

📌 Điểm cần nhớ

• Kinesis Data Streams → Redshift mà đề đòi "ít vận hành nhất": nghĩ ngay tới Redshift streaming ingestion qua materialized view, không cần Firehose, không cần đáp xuống S3, không cần COPY.
• Phân biệt ba tính năng đọc dữ liệu ngoài của Redshift theo nguồn: Spectrum đọc file trên S3; Federated query đọc database vận hành bên ngoài; Streaming ingestion đọc stream (Kinesis Data Streams, Amazon MSK). Không cái nào thay thế được cái nào.
• Khi hai phương án cùng ra kết quả đúng, cụm "LEAST operational overhead" biến câu hỏi thành bài toán đếm số dịch vụ trung gian — phương án thêm một chặng như Firehose sẽ thua phương án tích hợp trực tiếp.
• Đọc kỹ động từ trong đề: "stored in" đòi dữ liệu phải nằm trong Redshift, nên mọi phương án chỉ query tại chỗ (Spectrum, federated query) đều trượt ngay từ yêu cầu lưu trữ.

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

Đề mô tả một pipeline rất quen thuộc: dữ liệu người dùng chảy vào, được làm sạch/chuẩn hoá định dạng vài cột, rồi lưu xuống Amazon S3. Nếu chỉ đọc tới đó thì cả bốn phương án đều "làm được việc" — đó chính là bẫy.

Cụm từ quyết định nằm ở câu tưởng như phụ: "A single data record might range in size from 500 KB to 10 MB". Đây là ràng buộc về kích thước một bản ghi, và nó loại thẳng những dịch vụ có trần kích thước record nhỏ hơn 10 MB. Phần "clean/standardize" chỉ là nhiễu — dịch vụ nào cũng gắn được bước biến đổi (Lambda, Kinesis Data Analytics, consumer application). Cái không thương lượng được là con số 10 MB.

Vậy câu hỏi thật sự là: dịch vụ ingest nào chấp nhận được một record cỡ 10 MB?

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

Đáp án đúng là B — Amazon MSK (Managed Streaming for Apache Kafka).

MSK là dịch vụ Apache Kafka được quản lý: bạn tạo một topic cho dữ liệu thô, producer ghi bản ghi vào topic, và một consumer application viết bằng Apache Kafka consumer API (chạy trên EC2) đọc ra, biến đổi rồi ghi xuống S3.

Điểm mấu chốt: giới hạn kích thước message của MSK rộng hơn hẳn Kinesis — theo tài liệu giới hạn của MSK, record tối đa ở mức 100 MB, thừa sức chứa bản ghi 10 MB của đề. Đây đúng là lý do bài chọn MSK thay vì các phương án Kinesis, chứ không phải vì Kafka "mạnh hơn" hay "linh hoạt hơn".

Kiến trúc đề xuất cũng hoàn chỉnh về mặt xử lý: Kafka lưu record dưới dạng key + value + timestamp trong topic, producer và consumer tách rời nhau, nên bước chuẩn hoá định dạng cột nằm gọn trong consumer application trước khi ghi vào S3.

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

A — Kinesis Data Streams + Kinesis Data Analytics. Đây là phương án gần đúng nhất về mặt kiến trúc: có stream để ingest, có Kinesis Agent để ghi vào stream, có ứng dụng analytics để biến đổi rồi đẩy sang S3. Nó hỏng đúng ở một chỗ: kích thước tối đa của một data blob trong một record của Kinesis Data Streams là 1 MB (trước base64-encoding). Bản ghi 10 MB của đề vượt trần này, nên luồng chết ngay từ bước ghi vào stream — không cần bàn tới phần transform phía sau.

D — Kinesis Data Firehose + Lambda transform. Cũng là kiến trúc hợp lý và thậm chí đơn giản hơn A: Firehose có sẵn cơ chế gọi Lambda để cleanse/transform rồi giao thẳng vào S3. Nhưng nó vướng đúng cùng một bức tường: kích thước tối đa của một record gửi tới Firehose, trước base64-encoding, là 1.000 KiB. Bản ghi 10 MB không lọt qua. Phần "delivered to S3" rất hấp dẫn nên đây là mồi nhử mạnh nhất của câu này.

C — SQS + Lambda ghi lên S3. Sai ở hai tầng. Thứ nhất, SQS là hàng đợi message dùng để tách rời (decouple) các thành phần của ứng dụng phân tán, kèm các cấu trúc middleware như dead-letter queue và poison-pill management — nó không phải giải pháp xử lý luồng dữ liệu thời gian thực. Thứ hai, phương án này còn không mô tả bước chuẩn hoá định dạng nào: Lambda chỉ "read events... and upload the events to S3", tức là bỏ luôn yêu cầu làm sạch dữ liệu mà đề nêu rõ.

📌 Điểm cần nhớ

• Khi đề nêu kích thước một bản ghi bằng con số cụ thể, đó gần như luôn là ràng buộc dùng để loại phương án — hãy đối chiếu với giới hạn record của từng dịch vụ ingest trước khi so sánh kiến trúc.
• Kinesis Data Streams và Kinesis Data Firehose đều có trần record ở mức khoảng 1 MB; bản ghi lớn hơn thế thì cả hai đều bị loại cùng lúc, dù phần transform phía sau (Kinesis Data Analytics hay Lambda) trông rất hợp lý.
• Amazon MSK chấp nhận message lớn hơn nhiều (tài liệu giới hạn ghi mức 100 MB), nên nó là lựa chọn cho streaming ingest với record cỡ vài MB trở lên.
• SQS không phải dịch vụ stream processing: nó dùng để decouple các thành phần ứng dụng. Thấy đề yêu cầu pipeline dữ liệu thời gian thực mà phương án đưa SQS ra thì thường là mồi nhử — nhất là khi phương án đó còn bỏ quên bước biến đổi dữ liệu.

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

Đề mô tả một vòng đời dữ liệu ba giai đoạn rất rõ ràng trên Amazon S3:

• 0 – 6 tháng: truy cập nhiều lần mỗi ngày → giữ nguyên S3 Standard.
• 6 tháng – 3 năm: truy cập khoảng một đến hai lần mỗi tháng.
• Sau 3 năm: truy cập một đến hai lần mỗi năm.

Yêu cầu là dựng S3 Lifecycle policy sao cho "ensuring high availability while seeking cost-effectiveness" — vừa giữ tính sẵn sàng cao, vừa rẻ.

Hai cụm từ quyết định đáp án:

1. "ensuring high availability" — loại thẳng mọi storage class chỉ lưu trong một Availability Zone.
2. "accessed only once or twice annually" kèm việc đề không hề nói gì tới yêu cầu lấy dữ liệu nhanh (không có ràng buộc về first-byte latency, không nói "phải lấy về trong vài phút"). Không có ràng buộc tốc độ lấy về nghĩa là chọn tầng lưu trữ rẻ nhất cho giai đoạn cuối.

Ngoài ra, dữ liệu giai đoạn giữa vẫn cần truy cập tức thì khi cần (millisecond) dù ít lần — đó là đúng định nghĩa của lớp Infrequent Access.

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

Đáp án đúng là A: chuyển sang S3 Standard-IA sau 6 tháng, rồi chuyển sang S3 Glacier Deep Archive sau 3 năm.

• S3 Standard-IA được thiết kế đúng cho dữ liệu sống lâu nhưng ít được truy cập. Đối tượng vẫn đọc được với độ trễ mili giây giống S3 Standard, đổi lại giá lưu trữ thấp hơn và có thêm phí retrieval mỗi lần lấy dữ liệu. Với tần suất một–hai lần mỗi tháng, phần tiết kiệm được ở giá lưu trữ lớn hơn nhiều so với phí retrieval hiếm hoi. Quan trọng hơn, S3 Standard-IA lưu dữ liệu trên nhiều Availability Zone, nên đáp ứng được yêu cầu high availability trong đề.
• S3 Glacier Deep Archive là lớp lưu trữ rẻ nhất trong các storage class của S3, dành cho dữ liệu gần như không bao giờ đụng tới. Nó có thời gian lưu tối thiểu dài (180 ngày) và thời gian lấy dữ liệu mặc định tính bằng giờ — cả hai đều không thành vấn đề với dữ liệu đã quá 3 năm và chỉ đọc một–hai lần mỗi năm. Vì đề không đặt ràng buộc nào về tốc độ lấy về, chọn tầng rẻ nhất là lựa chọn tối ưu chi phí.

Kết hợp hai bước này bám sát đúng ba giai đoạn truy cập mà đề mô tả, đồng thời không hy sinh tính sẵn sàng.

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

B — S3 One Zone-IA sau 6 tháng, Glacier Deep Archive sau 3 năm. Đây là phương án gần đúng nhất và cũng là bẫy chính: nửa sau hoàn toàn giống đáp án đúng, giá lưu trữ của One Zone-IA lại còn rẻ hơn Standard-IA. Chỗ hỏng nằm ở nửa đầu: S3 One Zone-IA chỉ lưu dữ liệu trong một Availability Zone duy nhất. Nếu AZ đó gặp sự cố, dữ liệu không truy cập được — trực tiếp vi phạm yêu cầu "ensuring high availability" viết rõ trong đề. One Zone-IA chỉ hợp lý khi dữ liệu có thể tái tạo lại được (bản sao thứ cấp, dữ liệu trung gian), không phải trường hợp này.

C — S3 Intelligent-Tiering sau 6 tháng, Glacier Deep Archive sau 3 năm. Intelligent-Tiering tự theo dõi access pattern và tự động dời đối tượng giữa các access tier, đổi lại mất một khoản phí monitoring/automation nhỏ tính theo từng đối tượng mỗi tháng. Giá trị của nó nằm ở chỗ khi bạn không biết trước dữ liệu sẽ được truy cập thế nào. Ở đây thì ngược lại: đề đã nêu access pattern rất rõ và ổn định theo mốc thời gian. Trả tiền cho việc dò tìm một thứ đã biết chắc là chi phí thừa, nên phương án này thua về mặt cost-effectiveness dù vẫn giữ được high availability.

D — S3 Standard-IA sau 6 tháng, Glacier Flexible Retrieval sau 3 năm. Nửa đầu đúng hệt đáp án A, chỗ hỏng nằm ở nửa sau. S3 Glacier Flexible Retrieval dành cho kho lưu trữ mà một phần dữ liệu có thể cần lấy về trong vài phút (expedited retrieval cho phép lấy trong khoảng 1–5 phút), thời gian lưu tối thiểu 90 ngày. Khả năng lấy nhanh đó có giá của nó: chi phí lưu trữ cao hơn Glacier Deep Archive. Đề không đưa ra bất kỳ yêu cầu nào về tốc độ lấy dữ liệu, nên trả thêm tiền cho tính năng không dùng tới là kém tối ưu. Đây là kiểu sai "không sai về kỹ thuật nhưng đắt hơn mức cần thiết" — vẫn là sai trong một câu hỏi yêu cầu cost-effectiveness.

📌 Điểm cần nhớ

• Cụm "high availability" trong đề bài S3 gần như luôn là tín hiệu loại S3 One Zone-IA, vì lớp này chỉ nằm trong một AZ. Đọc thấy One Zone-IA thì việc đầu tiên là kiểm tra đề có nhắc tới availability hay khả năng tái tạo dữ liệu không.
• Chọn giữa Glacier Flexible Retrieval và Glacier Deep Archive phụ thuộc vào yêu cầu thời gian lấy dữ liệu, không phụ thuộc tần suất. Đề không nói gì về tốc độ lấy về → chọn Deep Archive vì rẻ nhất. Đề nói "cần lấy trong vài phút" → mới dùng Flexible Retrieval.
• S3 Intelligent-Tiering hợp với access pattern không biết trước hoặc thay đổi thất thường. Khi đề đã mô tả rõ ràng từng mốc thời gian, dùng Lifecycle rule tường minh vừa rẻ hơn vừa đúng ý đồ câu hỏi.
• S3 Standard-IA vẫn cho đọc với độ trễ mili giây như S3 Standard, chỉ khác ở giá lưu trữ thấp hơn kèm phí retrieval. "Infrequent Access" nói về tần suất truy cập, không có nghĩa là truy cập chậm.

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

Đề mô tả một công ty gọi xe dùng Amazon DynamoDB làm nơi lưu dữ liệu, với ba đặc điểm về tải:

• Ban đêm không dùng bảng — lưu lượng gần như bằng 0.
• Ban ngày lưu lượng đọc/ghi thường không đoán trước được (unpredictable).
• Khi có đỉnh tải thì đỉnh đó đến rất nhanh (spikes happen very quickly).

Cụm từ quyết định là "unpredictable" cộng với "spikes happen very quickly". Đây chính xác là hai chữ mà tài liệu DynamoDB dùng để phân định hai chế độ read/write capacity: provisioned dành cho tải đoán trước được, tăng dần đều; on-demand dành cho tải không đoán trước được, bùng lên trong vài giây tới vài phút. Câu hỏi không hỏi về sao chép đa Region, cũng không hỏi về cách truy vấn theo khoá khác — nó chỉ hỏi về capacity mode. Nhận ra điều đó là loại ngay được hai phương án lạc đề.

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

C — Set up Amazon DynamoDB table in the on-demand capacity mode.

On-demand là chế độ tính tiền theo từng request đọc/ghi, không cần hoạch định capacity trước. Với chế độ này, DynamoDB cấp phát năng lực ngay khi cần: không có khái niệm capacity đã đặt trước, không phải chờ Amazon CloudWatch chạm ngưỡng rồi mới kích hoạt việc chỉnh bảng. Nhờ vậy nó khớp cả ba đặc điểm trong đề:

• Tải không đoán trước được → không cần dự báo con số RCU/WCU nào cả.
• Đỉnh đến rất nhanh → không có độ trễ của vòng "đo → báo động → chỉnh bảng".
• Đêm không dùng → trả tiền theo lượng dùng thật, không nuôi capacity ngồi không.

Tài liệu AWS nêu thẳng ba trường hợp nên chọn on-demand: bảng mới với workload chưa rõ, lưu lượng ứng dụng không đoán trước được, và muốn chỉ trả cho phần thực dùng. Trường hợp trong đề rơi đúng vào vế thứ hai.

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

B — Provisioned capacity mode với auto-scaling — đây là phương án gần đúng nhất và là bẫy chính. Auto-scaling có điều chỉnh capacity theo lưu lượng, nhưng nó hoạt động gián tiếp: dùng scaling policy của Application Auto Scaling, dựa trên các CloudWatch alarm theo dõi consumed capacity, rồi mới cập nhật bảng. Chuỗi này cần thời gian để phản ứng, nên nó phù hợp với tải tăng dần chứ không kịp với đỉnh "bùng lên rất nhanh" như đề mô tả. Trong lúc chờ scale, capacity bị thiếu hụt và request bị throttle — đúng thứ ảnh hưởng trực tiếp tới trải nghiệm người dùng của một ứng dụng gọi xe. Provisioned (kể cả có auto-scaling) chỉ nên chọn khi lưu lượng đoán trước được và có thể dự báo để kiểm soát chi phí.

A — Global table ở chế độ provisioned capacity — sai ở hai lớp. Thứ nhất, global table giải quyết bài toán đa Region: sao chép bảng tự động sang các Region bạn chọn, cho phép đọc/ghi cục bộ nhanh ở nhiều nơi và giữ ứng dụng còn sống khi một Region gặp sự cố. Đề không hề nhắc tới người dùng ở nhiều Region hay yêu cầu chịu lỗi cấp Region. Thứ hai, phương án này vẫn để bảng ở provisioned mode, tức là giữ nguyên đúng điểm yếu đã phân tích ở B mà còn cộng thêm chi phí và độ phức tạp của replication.

D — Bảng kèm global secondary index (GSI) — lạc chủ đề. GSI là index có partition key và sort key khác với bảng gốc, nằm ở không gian partition riêng và scale tách khỏi bảng gốc; nó tồn tại để phục vụ các mẫu truy vấn khác với khoá chính. Đề không nói gì về việc cần truy vấn theo thuộc tính khác. Thêm GSI không giúp bảng chịu được tải không đoán trước — bản thân GSI cũng cần capacity, nên nếu bảng vẫn ở provisioned mode thì vấn đề không đổi, thậm chí có thêm một chỗ nữa để bị throttle.

📌 Điểm cần nhớ

• Với DynamoDB, câu hỏi có chữ "unpredictable" / "spiky" / "unknown workload" / "new table" thì đáp án gần như luôn là on-demand capacity mode; câu có "predictable" / "consistent" / "ramps gradually" / "forecast to control cost" thì mới là provisioned.
• Auto-scaling không thay thế được on-demand khi đỉnh tải đến trong vài giây: nó phản ứng qua CloudWatch alarm rồi mới cập nhật bảng, nên luôn có độ trễ.
• Phân biệt rõ ba khái niệm dễ trộn lẫn trong cùng một bộ đáp án: capacity mode (chịu tải, chi phí), global table (đa Region, tính sẵn sàng), GSI (mẫu truy vấn theo khoá khác). Chúng giải quyết ba bài toán khác nhau, chọn nhầm là lạc đề chứ không phải "chưa tối ưu".
• Khi bảng có khoảng thời gian dài không dùng, mô hình trả theo request thường hợp lý hơn việc duy trì capacity đặt sẵn.

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

Đề mô tả một website VueJS gọi REST API qua Amazon API Gateway. Data engineer cần một Python script chạy theo yêu cầu (on demand) khi API Gateway gọi tới, và kết quả của script phải trả ngược về API Gateway.

Cụm từ quyết định nằm ở câu hỏi cuối: "most efficient solution... with minimal operational overhead". Đây là kiểu ràng buộc rất quen trong đề AWS — nó không hỏi "cách nào chạy được Python", vì cả bốn phương án đều chạy được Python. Nó hỏi cách nào ít việc vận hành nhất.

Cụm thứ hai đáng chú ý là "executed on demand" — script chỉ chạy khi có request, không phải một dịch vụ chạy thường trực. Đó là đúng mô hình sự kiện của một hàm serverless, chứ không phải mô hình cluster luôn bật.

Sau khi hai cụm này loại bớt, hai phương án Lambda còn lại chỉ khác nhau ở cách giữ hàm ở trạng thái sẵn sàng (warm) — và đó mới là chỗ phân biệt thật sự.

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

Đáp án đúng theo tệp là D — AWS Lambda Python function với provisioned concurrency.

Lambda là backend tự nhiên của API Gateway: bạn chỉ đưa mã Python lên, không quản lý máy chủ, không vá hệ điều hành, không lo scaling — đúng nghĩa "minimal operational overhead".

Phần provisioned concurrency xử lý nốt vế "efficient". Trong Lambda, concurrency là số request đang được xử lý đồng thời, và có hai kiểu điều khiển:

• Reserved concurrency — số instance đồng thời tối đa dành riêng cho hàm đó; hàm khác không dùng được phần này. Cấu hình reserved concurrency không phát sinh phí thêm.
• Provisioned concurrency — số execution environment đã được khởi tạo sẵn, ở trạng thái sẵn sàng đáp ứng request ngay lập tức. Cấu hình provisioned concurrency có phát sinh chi phí thêm.

Vì các môi trường thực thi đã được khởi tạo trước, hàm luôn "ấm" và phản hồi ngay khi API Gateway gọi tới. Đây là cơ chế chính thức, do chính Lambda cung cấp để đạt điều mà phương án A cố làm bằng mẹo.

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

A — Lambda + EventBridge Scheduler gọi mỗi phút để giữ hàm warm. Đây là phương án gây nhiễu (distractor) và là phương án gần đúng nhất: nó chọn đúng dịch vụ (Lambda), đúng kiến trúc, chỉ sai ở cách giữ ấm. Bạn không thể giữ Lambda warm bằng cách gọi định kỳ qua EventBridge Scheduler mỗi phút. Ping định kỳ chỉ chạm tới một môi trường thực thi tại một thời điểm, trong khi cơ chế đúng đã có sẵn dưới dạng provisioned concurrency. Chọn A là tự dựng thêm một lịch chạy phải theo dõi và bảo trì — tức là thêm operational overhead, ngược hẳn yêu cầu của đề.

B — Python script trên ECS Fargate cluster. Fargate đã bỏ được việc quản lý EC2, nên nghe có vẻ "serverless". Nhưng dùng cả một ECS cluster chỉ để chạy một Python script làm backend REST API là overkill cho tình huống này: vẫn phải đóng gói container image, định nghĩa task/service, quản lý vòng đời cluster và ghép nối với API Gateway. So với việc dán mã Python vào một Lambda function, khối lượng vận hành lớn hơn hẳn.

C — Python script trên ECS cluster chạy trên EC2 instances. Tệ hơn B ở đúng chỗ đề quan tâm. Ngoài toàn bộ công việc container của B, bạn còn gánh thêm tầng EC2: chọn kiểu instance, vá hệ điều hành, scaling nhóm instance, giám sát sức khoẻ máy. Đây là phương án có operational overhead cao nhất trong bốn phương án, nên bị loại đầu tiên.

📌 Điểm cần nhớ

• Thấy cụm "least/minimal operational overhead" kèm một đoạn mã nhỏ chạy sau API Gateway → nghĩ Lambda trước, ECS/EC2 gần như luôn là bẫy overkill.
• Phân biệt hai kiểu concurrency của Lambda: reserved = trần số instance đồng thời dành riêng, không tính phí thêm; provisioned = môi trường thực thi khởi tạo sẵn để phản hồi tức thì, có tính phí thêm.
• Muốn Lambda phản hồi ngay, dùng provisioned concurrency — tính năng có sẵn của dịch vụ. Mẹo "ping định kỳ để giữ warm" bằng EventBridge Scheduler là phương án sai kinh điển trong đề thi.
• Khi hai phương án cùng chọn đúng dịch vụ, điểm phân biệt nằm ở cách cấu hình, không nằm ở kiến trúc — đọc kỹ nửa sau của từng phương án.
• Xếp hạng operational overhead để loại nhanh: Lambda < ECS Fargate < ECS trên EC2.

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

Đề mô tả một website đào tạo IT được host tĩnh trên Amazon S3. Lượng request tăng gần 300%, và chi phí đội lên không phải vì lưu trữ mà vì "S3 outbound data costs" — tức phí data transfer out từ S3 ra Internet.

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

• "outbound data costs" — vấn đề là băng thông đi ra, không phải dung lượng lưu trữ. Mọi phương án kiểu "đổi chỗ chứa dữ liệu" đều không chạm tới nguyên nhân.
• "reduce costs while keeping the latency low" — ràng buộc kép: vừa phải rẻ hơn, vừa không được làm chậm đi. Một phương án chỉ rẻ mà tăng độ trễ cũng bị loại.

Kết hợp hai điều kiện đó, câu hỏi thực chất đang mô tả đúng bài toán mà một CDN sinh ra để giải: cache nội dung ở gần người dùng để vừa cắt lưu lượng đi ra từ origin, vừa rút ngắn quãng đường mạng.

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

D — Configure Amazon CloudFront to distribute the data hosted on Amazon S3 cost-effectively.

CloudFront là dịch vụ CDN của AWS, phân phối nội dung tĩnh và động qua mạng lưới Edge Location trải khắp thế giới. Đặt CloudFront trước bucket S3 (S3 làm origin) giải quyết đồng thời cả hai ràng buộc trong đề:

• Về chi phí: phần lớn request được phục vụ từ bản cache tại edge, nên số lần phải lấy dữ liệu từ S3 giảm mạnh. Quan trọng hơn, data transfer từ S3 sang CloudFront không tính phí, và giá data transfer out của CloudFront thường rẻ hơn phục vụ trực tiếp từ S3. Bạn chỉ trả cho phần dữ liệu CloudFront trả ra Internet cộng phí request.
• Về độ trễ: request của người dùng được định tuyến tới Edge Location gần nhất. Nếu file đã có trong cache, nó được trả ngay từ đó. Nếu chưa, CloudFront lấy từ origin S3 rồi cache lại, để lần kế tiếp trong khu vực đó được phục vụ tại chỗ.

Đây chính là mô hình AWS khuyến nghị cho website tĩnh trên S3: giữ nguyên S3 làm nơi chứa, thêm CloudFront làm lớp phân phối.

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

A — Amazon EFS. EFS là file system NFS dùng chung, mount vào EC2 instance. Nó không phải là endpoint phục vụ web cho người dùng Internet — muốn dùng vẫn phải dựng EC2 đứng trước. Ngoài ra EFS đắt hơn cả EBS lẫn S3 tính trên mỗi GB, nên trong một câu hỏi lấy mục tiêu là giảm chi phí thì đây là hướng ngược lại.

B — Lưu dữ liệu trên EBS volume gắn vào EC2. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất: EBS nhanh và không quá đắt. Nhưng nó hỏng ở ba điểm. Thứ nhất, EBS volume chỉ truy cập được thông qua EC2 instance — bạn phải trả thêm tiền chạy EC2 24/7 và tự lo scaling khi traffic tăng 300%. Thứ hai, EBS gắn với một Region cụ thể, người dùng ở xa vẫn phải đi hết quãng đường mạng tới Region đó, nên ràng buộc "keep the latency low" không được cải thiện. Thứ ba, và cơ bản nhất: đổi chỗ chứa dữ liệu không xoá được phí outbound — dữ liệu đi ra Internet từ EC2 vẫn bị tính phí data transfer out.

C — S3 Batch Operations. Đây là distractor thuần tuý. S3 Batch Operations dùng để thực hiện thao tác hàng loạt trên số lượng lớn object đã có trong bucket (copy, đặt tag, gọi Lambda, khôi phục từ Glacier…). Nó là công cụ quản trị dữ liệu, hoàn toàn không liên quan tới việc phân phối nội dung tới người dùng cuối. Mô tả "đọc dữ liệu hàng loạt một lần để giảm số lời gọi tới bucket" không phản ánh đúng cách website phục vụ request — mỗi người xem vẫn tạo ra request riêng, không gộp lại được.

📌 Điểm cần nhớ

• Đọc kỹ loại chi phí mà đề nêu. Chi phí lưu trữ thì hướng giải quyết là storage class / lifecycle policy; chi phí outbound data transfer thì hướng giải quyết là caching và CDN. Hai bài toán khác hẳn nhau.
• S3 + CloudFront là cặp mặc định cho website tĩnh: không mất phí truyền dữ liệu từ S3 sang CloudFront, giảm tải cho origin, và phục vụ từ edge nên độ trễ thấp. Gặp đề vừa đòi giảm cost vừa đòi giữ latency thấp cho nội dung tĩnh, hãy nghĩ tới CloudFront trước.
• EBS và EFS đều cần EC2 đứng trước mới phục vụ được và đều bị bó trong một Region. Chúng không phải phương án thay thế cho việc phân phối nội dung ra Internet, và không rẻ hơn S3.
• Cảnh giác với các phương án nghe có vẻ "tối ưu" nhưng thuộc nhóm chức năng khác — S3 Batch Operations là thao tác quản trị hàng loạt, không phải cơ chế phục vụ nội dung. Nếu một phương án không tác động vào đúng nguyên nhân đề nêu, nó sai bất kể nghe hợp lý đến đâu.

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

Đề mô tả một công ty y tế đổ dữ liệu sức khoẻ người dùng lên Amazon S3 hằng ngày và dùng Amazon Athena để truy vấn. Glue crawler được dựng lên để tự động hoá việc lập catalog, nhưng nó chạy vài giờ mà vẫn chưa xác định được schema của data store. Câu hỏi: làm gì để sửa?

Cụm từ quyết định đáp án nằm ở giữa đoạn mô tả, không phải ở phần than phiền về hiệu năng: "Any user health information older than a week is never used in the queries." Đây là chi tiết duy nhất trong đề nói về thành phần dữ liệu, và nó nói thẳng rằng có một khối lớn dữ liệu trong S3 hoàn toàn không phục vụ truy vấn nào. Crawler thì không biết điều đó — mặc định nó liệt kê và đọc mọi thứ trong đường dẫn được trỏ tới, kể cả phần dữ liệu cũ vô dụng.

Cụm thứ hai đáng chú ý: "running for several hours and is still unable to identify the schema". Crawler không báo lỗi, không sai quyền, không sai định dạng — nó chỉ chưa xong. Đó là dấu hiệu của bài toán khối lượng phải quét, chứ không phải bài toán cấu hình sai. Ghép hai cụm lại: phải giảm khối lượng crawler phải xử lý, mà cách hợp lệ là cắt đi phần dữ liệu đề đã nói rõ là không cần.

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

B — Use an exclude pattern for the Glue crawler to filter out the unwanted files.

Exclude pattern là cơ chế sẵn có của Glue crawler để bảo nó bỏ qua những file hoặc đường dẫn nhất định. Tác dụng trực tiếp: crawler phải liệt kê ít file hơn, và với mỗi file mới nó cũng không phải đọc phần đầu để suy ra schema. Ít file phải liệt kê và đọc thì lượt chạy kết thúc nhanh hơn — đúng thứ đang thiếu ở đây.

Chi tiết trong đề khớp hoàn hảo với cơ chế này: dữ liệu cũ hơn một tuần không bao giờ được truy vấn, nên loại chúng khỏi phạm vi crawl không mất mát gì về mặt nghiệp vụ. Tài liệu AWS cũng nêu đúng kiểu dùng này — exclude pattern để loại metafile và những file đã crawl rồi. Đây là hành động đúng chỗ: sửa phạm vi crawler làm việc, chứ không cố làm cho nó chạy nhanh hơn trên cùng một khối dữ liệu.

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

A — Tăng tham số Scanning rate của Glue Crawler.

Đây là phương án gài bẫy khéo nhất, vì cái tên nghe đúng y hệt vấn đề: crawler quét chậm thì tăng tốc độ quét. Nhưng Scanning rate chỉ định phần trăm read capacity units được crawler sử dụng, và tham số này chỉ có với data store là DynamoDB. Trong đề, data store là Amazon S3 — tham số đó thậm chí không áp dụng được, nên không có gì để chỉnh. Bài học: đọc tên tham số thì phải kiểm luôn nó thuộc loại nguồn dữ liệu nào.

C — Chia file lớn thành nhiều file nhỏ để giảm chi phí đọc file lớn.

Phương án này đảo ngược đúng cơ chế làm việc của crawler. Crawler phải liệt kê từng file và đọc megabyte đầu tiên của mỗi file mới. Chi phí vì thế tỷ lệ với số lượng file chứ không phải với kích thước từng file. Chẻ nhỏ file ra làm số file tăng lên, tức là số lần liệt kê và số lần đọc đầu file đều tăng — crawler chạy lâu hơn, không phải nhanh hơn. Đây là chỗ mà trực giác "file nhỏ thì đọc nhanh" dẫn người học đi sai hướng.

D — File nén như Apache Parquet crawl lâu hơn, nên dùng file không nén.

Vế đầu của câu này đúng một nửa và chính chỗ đó khiến nó nguy hiểm: file nén nói chung đúng là tốn thời gian hơn, vì crawler phải tải về và giải nén trước khi đọc được megabyte đầu hoặc liệt kê file. Nhưng ví dụ đưa ra lại sai: với Apache Parquet, Apache Avro và Apache ORC, crawler không đọc megabyte đầu tiên mà đọc thẳng metadata lưu sẵn trong từng file. Ba định dạng này mang schema theo mình, nên chúng nằm ngoài vấn đề mà phương án đang mô tả. Ngoài ra đề bài không hề nói dữ liệu đang ở định dạng nén nào, nên đây là suy diễn thêm dữ kiện không có.

📌 Điểm cần nhớ

• Chi phí của Glue crawler bám theo số lượng file phải liệt kê và số file mới phải đọc, không bám theo kích thước từng file. Vì vậy nhiều file nhỏ luôn tốn hơn ít file lớn cùng tổng dung lượng — mọi phương án đề nghị "chẻ nhỏ file cho nhanh" đều đáng nghi.
• Exclude pattern là công cụ chuẩn để thu hẹp phạm vi crawl. Khi đề bài nêu rõ có một phần dữ liệu không bao giờ được truy vấn tới, đó gần như luôn là gợi ý dẫn tới exclude pattern.
• Scanning rate chỉ dành cho data store DynamoDB. Gặp tham số này trong câu hỏi mà nguồn dữ liệu là Amazon S3 thì loại ngay, dù tên gọi nghe rất khớp với triệu chứng.
• Parquet, Avro và ORC là ngoại lệ về cách crawler đọc schema: crawler lấy metadata nhúng sẵn trong file thay vì đọc megabyte đầu. Đừng xếp chúng chung với các file nén thông thường khi cân nhắc chi phí crawl.
• Khi crawler chỉ chậm chứ không lỗi, hãy tìm cách giảm khối lượng nó phải xử lý, đừng đi tìm nút vặn tốc độ — thường nút đó không tồn tại cho nguồn dữ liệu đang dùng.

Đáp án

D — AWS SECRETS MANAGER.

Vì sao đúng

⚠ Secrets Manager đáp ứng đúng hai yêu cầu của đề: | Yêu cầu | Secrets Manager làm gì | |---|---| | ⚠ Lưu trữ AN TOÀN | ⚠ mã hoá bằng KMS, kiểm soát truy cập bằng chính sách IAM | | ⚠ TỰ ĐỘNG XOAY VÒNG thông tin đăng nhập | ⚠ tính năng đặc trưng, không dịch vụ nào khác trong bốn phương án có | | ⚠ Tích hợp sẵn với RDS, Redshift, DocumentDB | ⚠ xoay vòng mật khẩu cơ sở dữ liệu không cần viết mã | | ⚠ Có SDK lấy bí mật ngay lúc chạy | ⚠ ứng dụng không cần lưu mật khẩu ở đâu cả | | ⚠ Kết luận | ⚠ cụm "automatic rotation" trong đề chỉ thẳng tới dịch vụ này |

⚠ Vì sao xoay vòng tự động quan trọng: ⚠ mật khẩu không đổi trong nhiều năm là rủi ro lớn nhất trong mọi hệ thống dữ liệu ⚠ — ⚠ và xoay vòng thủ công thì hoặc không ai làm, hoặc làm rồi quên cập nhật một ứng dụng nào đó và gây sự cố.

Vì sao các phương án khác sai

• C (AWS Systems Manager Parameter Store) — ⚠ phương án gây nhiễu mạnh nhất vì ⚠ Parameter Store CŨNG lưu được chuỗi bí mật, cũng mã hoá được bằng KMS với kiểu SecureString, và ở tầng miễn phí thì rẻ hơn hẳn Secrets Manager: ⚠ nhưng ⚠ Parameter Store KHÔNG có xoay vòng tự động sẵn có ⚠; ⚠ muốn xoay vòng thì phải tự viết hàm Lambda và tự lập lịch, tức là tự dựng lại đúng thứ mà Secrets Manager đã cho sẵn; ⚠ quy tắc phân biệt gọn: cần XOAY VÒNG thì chọn Secrets Manager, chỉ cần lưu tham số cấu hình thông thường thì Parameter Store là đủ và rẻ hơn.

• A (Amazon S3 với mã hoá phía máy chủ) — ⚠ S3 mã hoá được nhưng nó là kho lưu trữ đối tượng đa dụng; ⚠ nó không có khái niệm vòng đời của bí mật, không xoay vòng, và cấp quyền ở mức đối tượng cho từng bí mật là rất rườm rà.

• B (AWS KMS) — ⚠ KMS quản lý KHOÁ MÃ HOÁ, không lưu bí mật; ⚠ nó là dịch vụ mà Secrets Manager DÙNG ở bên dưới để mã hoá — liên hệ #1468 cùng lô.

Ghi nhớ

⚠ Secrets Manager và Parameter Store, bảng so sánh: | Yếu tố | Secrets Manager | Parameter Store | |---|---|---| | ⚠ Xoay vòng tự động | ⚠ CÓ sẵn — điểm quyết định | ⚠ không, phải tự viết | | ⚠ Chi phí | ⚠ tính tiền theo từng bí mật | ⚠ có bậc miễn phí | | ⚠ Tích hợp cơ sở dữ liệu | ⚠ sẵn cho RDS, Redshift, DocumentDB | ⚠ không | | ⚠ Sao chép sang vùng khác | ⚠ có | ⚠ hạn chế | | ⚠ Phù hợp nhất cho | ⚠ mật khẩu, khoá API, chuỗi kết nối | ⚠ tham số cấu hình, đường dẫn, cờ bật tắt | | ⚠ Cách chọn trong thực tế | ⚠ nhiều nhóm dùng CẢ HAI: Parameter Store cho cấu hình thường, Secrets Manager riêng cho những bí mật thật sự cần xoay vòng — như vậy vừa an toàn vừa không tốn tiền cho hàng trăm tham số vô hại |

⚠ Xoay vòng hoạt động thế nào: | Bước | Nội dung | |---|---| | ⚠ 1. Tạo thông tin đăng nhập mới | | | ⚠ 2. Đặt nó vào cơ sở dữ liệu | | | ⚠ 3. Kiểm tra bộ mới có đăng nhập được không | | | ⚠ 4. Chuyển nhãn AWSCURRENT sang bộ mới | | | ⚠ Vì sao có bốn bước | ⚠ nếu bước kiểm tra thất bại thì bí mật cũ vẫn còn hiệu lực, nên ứng dụng không bị mất kết nối — đây là điều mà một kịch bản xoay vòng tự viết rất hay bỏ sót |

⚠ Thực hành tốt cho kỹ sư dữ liệu: | Việc | Nội dung | |---|---| | ⚠ Không bao giờ nhúng mật khẩu vào mã hay tệp cấu hình | ⚠ liên hệ #1467 cùng lô | | ⚠ Lấy bí mật lúc chạy qua SDK | | | ⚠ Cấp quyền đọc bí mật theo nguyên tắc tối thiểu | | | ⚠ Bật xoay vòng cho mọi mật khẩu cơ sở dữ liệu | | | ⚠ Theo dõi việc truy cập bí mật bằng CloudTrail | ⚠ liên hệ #1555 cùng lô | | ⚠ Ý nghĩa chung | ⚠ một bí mật được quản lý tốt là bí mật mà không lập trình viên nào từng nhìn thấy giá trị của nó |

Từ khoá nhận diện:

"lưu trữ an toàn kèm xoay vòng tự động" → ⚠ AWS SECRETS MANAGER "Parameter Store" → ⚠ lưu được nhưng KHÔNG tự xoay vòng "KMS" → ⚠ quản lý khoá mã hoá, không lưu bí mật "S3 có mã hoá" → ⚠ kho lưu trữ đa dụng, không quản lý vòng đời bí mật

Ba việc kiểm chứng: | Việc | Cách | |---|---| | Mật khẩu cơ sở dữ liệu của bạn đổi lần cuối khi nào | | | Có mật khẩu nào đang nằm trong mã nguồn hay biến môi trường không | | | Bạn đã bật xoay vòng cho những bí mật quan trọng nhất chưa | |

Và lý do việc xoay vòng phải là tự động chứ không thể là kỷ luật: mọi quy trình bảo mật phụ thuộc vào việc con người nhớ làm đều đặn đều sẽ hỏng — chỉ khác nhau ở chỗ hỏng sớm hay hỏng muộn.

Đáp án

B — Amazon API Gateway kết hợp Amazon Kinesis Data Analytics

Vì sao đúng

Đề đòi ba thứ cùng lúc: dữ liệu thời gian thực, truy cập qua REST API, và phục vụ nền tảng phân tích. Kết hợp này phủ cả ba:

• API Gateway — cung cấp endpoint REST để nền tảng phân tích lấy dữ liệu, đúng chữ "REST API" trong đề.
• Kinesis Data Analytics — xử lý luồng dữ liệu vị trí liên tục bằng SQL hoặc Apache Flink, tính được các chỉ số theo cửa sổ thời gian (vị trí mới nhất, tốc độ trung bình, xe đi lệch tuyến) ngay khi dữ liệu chảy qua, không phải chờ nạp vào kho rồi mới truy vấn.

Điểm mấu chốt: dữ liệu vị trí xe tải trong giờ cao điểm là luồng liên tục, và giá trị của nó nằm ở việc phân tích ngay chứ không phải lưu lại rồi hỏi sau.

Vì sao các phương án khác sai

• A. API Gateway kết hợp AWS Lambda — làm được phần API, nhưng Lambda xử lý từng yêu cầu riêng lẻ; nó không có khái niệm cửa sổ thời gian hay tổng hợp trên luồng. Đây là phương án nhiễu chính vì cặp API Gateway–Lambda là mẫu quen thuộc nhất.
• C. QuickSight kết hợp Redshift — QuickSight là bảng điều khiển cho người xem, không phải REST API; Redshift cũng là kho dữ liệu cho phân tích theo lô.
• D. Athena kết hợp S3 — truy vấn dữ liệu đã nằm yên trên S3; độ trễ tính bằng giây tới phút, không đáp ứng được yêu cầu thời gian thực.