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

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

Một công ty sản xuất đang giữ dữ liệu tại chỗ (on-premises) trong một SMB file share và muốn migrate khối dữ liệu đó lên AWS để có khả năng mở rộng và phân tích tốt hơn. Đề hỏi thẳng: dịch vụ nào của AWS giúp thực hiện việc chuyển dữ liệu từ SMB file share lên cloud.

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

• "migrate their on-premises data ... to AWS" — đây là một cuộc di chuyển dữ liệu, tức là chuyển hẳn dữ liệu sang AWS, chứ không phải dựng một mô hình hybrid để ứng dụng tại chỗ tiếp tục đọc/ghi qua cloud.
• "facilitate the transfer" cộng với ba tiêu chí efficient, secure, minimize downtime — thứ cần tìm là một dịch vụ thực hiện việc truyền dữ liệu, biết nói giao thức SMB ở đầu nguồn, chứ không phải một thiết bị vận chuyển hay một đường truyền mạng.

Hai ràng buộc này loại được cả ba phương án còn lại, vì mỗi phương án đều lệch đúng một trong hai điểm: hoặc không phải "migrate hẳn", hoặc không phải "thứ thực hiện việc truyền".

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

D — AWS DataSync là dịch vụ chuyên để truyền dữ liệu giữa hệ thống lưu trữ tại chỗ và các dịch vụ lưu trữ của AWS. Nó hỗ trợ trực tiếp SMB file share làm nguồn và Amazon S3 làm đích — khớp chính xác cặp nguồn–đích mà đề mô tả, không cần bước trung gian nào.

DataSync phù hợp với cả ba tiêu chí trong đề:

• Efficient: agent của DataSync tự lo song song hoá và tối ưu việc truyền, nên nhanh hơn nhiều so với chép tay bằng script.
• Secure: dữ liệu được mã hoá khi truyền.
• Minimize downtime: chạy được theo lịch và truyền tăng dần (incremental) — lần chạy sau chỉ chuyển phần thay đổi, nên có thể chép phần lớn dữ liệu trong lúc hệ thống vẫn hoạt động rồi chỉ dừng ngắn ở lần đồng bộ cuối.

Ngoài ra DataSync còn có kiểm tra tính toàn vẹn dữ liệu (data validation) và giới hạn băng thông (bandwidth throttling) — hai thứ khiến nó là công cụ migration đúng nghĩa chứ không chỉ là một lệnh copy.

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

A — AWS Snowball Edge: đây là thiết bị vật lý được gửi tới nơi đặt hệ thống, nạp dữ liệu vào rồi chuyển ngược về AWS. Nó chỉ hợp lý khi đường truyền mạng không đủ tốt cho việc chuyển online — băng thông quá thấp hoặc khối dữ liệu quá lớn so với thời gian cho phép. Đề bài không hề nói mạng có vấn đề, mà lại nhấn mạnh "minimize downtime"; trong khi đó Snowball phải chờ vận chuyển vật lý hai chiều nên thời gian hoàn tất dài hơn hẳn. Đây là phương án đúng cho một tình huống khác, không phải tình huống này.

B — AWS Storage Gateway (File Gateway): đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì File Gateway đúng là có nói giao thức SMB. Nhưng nó hỏng ở chỗ mục đích sử dụng: File Gateway sinh ra cho kịch bản hybrid — ứng dụng tại chỗ tiếp tục truy cập qua SMB/NFS trong khi dữ liệu được lưu ở cloud và có cache cục bộ. Nghĩa là nó tạo ra một liên kết thường trực giữa on-premises và AWS, chứ không phải một cuộc migration có điểm kết thúc. Đề bài nói "migrate", tức là chuyển xong thì thôi; chọn B là biến một dự án di chuyển dữ liệu thành một kiến trúc hybrid phải vận hành mãi.

C — AWS Direct Connect: đây là kết nối mạng chuyên dụng tới AWS, cho băng thông ổn định và không đi qua Internet công cộng. Vấn đề là Direct Connect chỉ là con đường, không phải cái xe — bản thân nó không đọc SMB file share, không biết tệp nào đã chép, không kiểm tra toàn vẹn, không đồng bộ tăng dần. Trong thực tế Direct Connect được dùng kèm với một dịch vụ truyền dữ liệu như DataSync, chứ không thay thế được nó. Đề hỏi dịch vụ nào thực hiện việc chuyển, nên C trả lời sai câu hỏi.

📌 Điểm cần nhớ

• DataSync = migration online từ file share (SMB/NFS) lên AWS. Thấy đề có "on-premises file share" + "transfer/migrate to S3" + "minimize downtime" thì DataSync gần như luôn là đáp án.
• Phân biệt Storage Gateway với DataSync theo mục đích, không theo giao thức. Cả hai đều nói SMB, nhưng Storage Gateway là truy cập hybrid lâu dài, còn DataSync là chuyển một lần (hoặc theo lịch) rồi kết thúc.
• Snowball Edge chỉ thắng khi đề nói rõ mạng yếu — băng thông hạn chế, địa điểm hẻo lánh, hoặc dữ liệu quá lớn so với thời hạn. Không có tín hiệu đó thì đừng chọn thiết bị vật lý.
• Direct Connect là hạ tầng mạng, không phải công cụ truyền dữ liệu. Nó cải thiện chất lượng đường truyền nhưng không tự chuyển được tệp nào; câu hỏi dạng "dịch vụ nào để chuyển dữ liệu" thì Direct Connect luôn là mồi nhử.

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

Đề mô tả một công ty muốn chuyển cơ sở dữ liệu Oracle đang chạy tại chỗ (on-premises) sang Amazon Aurora PostgreSQL. Đây là hai engine khác nhau — Oracle sang PostgreSQL — nên đây là một cuộc di chuyển heterogeneous, không phải sao chép một-một.

Ba cụm từ trong đề quyết định đáp án:

• "both the database schema and the data" — cần hai việc riêng biệt: chuyển đổi lược đồ và chuyển dữ liệu. Phương án nào chỉ giải quyết một vế là hỏng.
• "with minimal downtime" — cần công cụ chép được dữ liệu trong khi nguồn vẫn đang phục vụ, tức có cơ chế bám theo thay đổi phát sinh chứ không phải dump một lần rồi tắt máy.
• "a tool to convert the source database schema to be compatible with" — đề nói thẳng là cần một công cụ chuyển đổi lược đồ. Cụm này loại luôn mọi phương án phải viết tay logic chuyển đổi.

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

D — AWS Database Migration Service (DMS) cho dữ liệu + AWS Schema Conversion Tool (SCT) cho lược đồ.

Đây đúng là cặp công cụ AWS thiết kế cho tình huống này, mỗi cái lo một vế của đề:

• SCT đọc lược đồ Oracle nguồn, tự động chuyển các đối tượng (bảng, kiểu dữ liệu, index, view, thủ tục) sang dạng tương thích Aurora PostgreSQL, và đánh dấu những phần không tự chuyển được để người vận hành xử lý tay. Chính phần báo cáo đánh giá này là thứ khiến nó đáp ứng được yêu cầu "a tool to convert the source database schema".
• DMS lo phần chép dữ liệu, hỗ trợ Oracle làm nguồn và Aurora PostgreSQL làm đích. DMS chép dữ liệu hiện có rồi tiếp tục theo dõi thay đổi phát sinh trên nguồn, nên ứng dụng chỉ cần cắt sang đích ở thời điểm cuối — đây chính là cách đạt minimal downtime.

Thứ tự làm việc cũng khớp: dựng lược đồ đích bằng SCT trước, rồi mới đổ dữ liệu vào bằng DMS.

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

B — AWS Glue cho cả hai việc. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì Glue có di chuyển dữ liệu được: crawler đọc được nguồn JDBC, job ETL ghi được vào đích. Nhưng nó hỏng ở hai chỗ. Thứ nhất, Glue là dịch vụ ETL cho phân tích dữ liệu, không có chức năng chuyển đổi lược đồ Oracle sang PostgreSQL — Data Catalog chỉ ghi nhận siêu dữ liệu (metadata) chứ không dịch kiểu dữ liệu hay thủ tục lưu trữ sang phương ngữ đích. Thứ hai, job Glue chạy theo lô, không có cơ chế bám thay đổi liên tục như DMS, nên không đáp ứng được yêu cầu downtime tối thiểu.

C — Amazon RDS cho dữ liệu + AWS Lambda cho lược đồ. Sai cả hai vế. RDS là dịch vụ vận hành cơ sở dữ liệu — nó là nơi database chạy, không phải công cụ để chuyển dữ liệu giữa hai nền tảng khác nhau; đặt RDS vào vai "data migration" là nhầm lẫn giữa đích đến và phương tiện. Lambda thì là dịch vụ chạy mã không máy chủ: về lý thuyết bạn có thể tự viết mã dịch lược đồ trong đó, nhưng đề yêu cầu một công cụ có sẵn làm việc chuyển đổi, chứ không phải một nền tảng để tự viết lấy.

A — S3 Transfer Acceleration cho dữ liệu + Amazon Athena cho lược đồ. Lệch xa nhất. Transfer Acceleration chỉ là tính năng tăng tốc tải tệp lên S3 qua mạng biên — nó không biết gì về database, không đọc được bảng Oracle. Athena là dịch vụ truy vấn SQL trên dữ liệu nằm trong S3; nó đọc dữ liệu chứ không chuyển đổi lược đồ và cũng không ghi vào Aurora. Cặp này giải quyết một bài toán hoàn toàn khác: đưa tệp lên S3 rồi truy vấn tại chỗ.

📌 Điểm cần nhớ

• Đề nhắc hai engine khác nhau (Oracle → PostgreSQL, SQL Server → Aurora, v.v.) thì phản xạ là cặp SCT + DMS: SCT lo lược đồ, DMS lo dữ liệu.
• Cụm "minimal downtime" trong bài di chuyển database gần như luôn trỏ về DMS, vì nó chép dữ liệu ban đầu rồi tiếp tục bám theo thay đổi cho tới lúc cắt sang đích.
• AWS Glue không phải công cụ migration database. Nó là ETL phục vụ phân tích; thấy nó đứng cạnh DMS trong cùng một câu hỏi về di chuyển database thì Glue thường là mồi nhử.
• Phân biệt rõ đích đến với phương tiện: RDS/Aurora là nơi database chạy, DMS mới là thứ đưa dữ liệu tới đó. Phương án nào lấy tên một dịch vụ lưu trữ đặt vào vai "công cụ migration" là sai ngay từ cách đặt vấn đề.

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

Đề bài mô tả một tình huống rất cụ thể: cần trích ra một cột duy nhất từ một tập dữ liệu lớn định dạng Apache Parquet nằm trong bucket Amazon S3.

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

• "one-time extraction" — đây là việc làm một lần, không phải nhu cầu phân tích lặp đi lặp lại. Mọi thứ phải dựng sẵn trước khi truy vấn được (database, table, cluster) đều trở thành chi phí thuần tuý, dùng xong bỏ.
• "minimal setup and execution time" và "least operational overhead" — tiêu chí chấm điểm không phải là dịch vụ nào mạnh nhất hay phổ biến nhất, mà là cái nào cần chuẩn bị ít nhất.

Cả bốn phương án đều làm được việc đọc một cột từ Parquet trên S3 bằng SQL. Đây là kiểu câu mà mọi phương án đều đúng về mặt kỹ thuật, và ràng buộc "một lần + ít chuẩn bị nhất" mới là thứ tách chúng ra. Ai chỉ đọc "query Parquet trên S3 bằng SQL" rồi phản xạ chọn Athena sẽ trượt đúng bẫy này.

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

Đáp án đúng theo tệp là A — dùng S3 Select.

S3 Select cho phép gửi thẳng một biểu thức SQL đơn giản tới chính object trong S3 để lấy về một phần dữ liệu thay vì tải nguyên object. Điểm mấu chốt hợp với đề bài:

• Không phải dựng gì cả. Không tạo database, không định nghĩa table, không chạy crawler, không cấp phát cluster. Việc lọc diễn ra ngay trong phạm vi dịch vụ S3.
• Không có compute resource nào phải quản lý, nên gần như không có operational overhead — đúng tiêu chí đề nêu.
• Đây chính là kiểu tác vụ S3 Select sinh ra để phục vụ: lấy nhanh một tập con dữ liệu khi chưa cần tới cả một quy trình ETL đầy đủ.

Với một cột, một lần, trên Parquet — S3 Select là con đường ngắn nhất từ lúc bắt đầu tới lúc có dữ liệu trong tay.

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

B — Amazon Athena. Đây là phương án gần đúng nhất và cũng là bẫy chính. Athena thật sự truy vấn được Parquet trong S3 bằng SQL chuẩn, không cần server, và nếu nhu cầu là truy vấn lặp lại thì nó mới là lựa chọn đúng. Nó hỏng ở chỗ điều kiện tiên quyết: Athena truy vấn theo table, nên trước hết phải tạo database, định nghĩa table, và chạy crawler nếu schema chưa có sẵn trong catalog. Với một lần lấy một cột, khối lượng chuẩn bị đó lớn hơn hẳn việc gửi thẳng một câu SELECT vào object. So với tiêu chí "ít setup nhất", Athena thua — dù nó không hề "sai" về mặt khả năng.

C — EMR cluster với Hive. Nặng nhất trong bốn phương án. Phải cấp phát cluster, cấu hình Hive, chờ cluster khởi động, rồi sau đó còn phải nhớ tắt đi. Toàn bộ chi phí đó chỉ để chạy một câu SELECT một cột đúng một lần. EMR hợp lý khi có khối lượng xử lý lớn và kéo dài; ở đây nó đi ngược hẳn yêu cầu "minimal setup and execution time".

D — Redshift Spectrum. Cho phép truy vấn dữ liệu S3 từ Redshift, nhưng nó là phần mở rộng của Redshift, không phải dịch vụ đứng một mình. Muốn dùng phải có Redshift đang hoạt động, cộng thêm việc khai báo external schema và external table trỏ vào dữ liệu S3. Spectrum có giá trị khi cần kết hợp dữ liệu trong warehouse với dữ liệu trong data lake, hoặc phục vụ phân tích thường xuyên — không phải cho một lần trích cột rồi thôi.

📌 Điểm cần nhớ

• Khi đề nhấn "one-time" cộng với "least operational overhead", hãy xếp hạng phương án theo thứ tự phải chuẩn bị, không theo sức mạnh: S3 Select (không chuẩn bị) < Athena (table + có thể cần crawler) < Redshift Spectrum (cần Redshift + external table) < EMR (cấp phát và cấu hình cả cluster).
• Athena và S3 Select không thay thế nhau. Athena hợp với truy vấn lặp lại, join nhiều nguồn, dữ liệu trải trên nhiều object; S3 Select hợp với việc bốc nhanh một tập con từ object khi chưa muốn dựng metadata gì cả.
• Redshift Spectrum không tồn tại độc lập — mọi phương án nhắc tới nó đều kéo theo yêu cầu ngầm là phải có Redshift, đó thường là chỗ để loại nó trong các câu ưu tiên "ít vận hành".
• EMR gần như không bao giờ là đáp án cho việc làm một lần. Thấy "one-time" hoặc "ad-hoc" đi cùng "minimal setup", có thể gạch EMR ngay từ vòng đầu để tập trung so ba phương án còn lại.

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

Đề mô tả một công ty fintech đang chạy cụm Amazon Redshift với node kiểu dense compute (DC2). Yêu cầu: cụm phải tự động có thêm sức xử lý truy vấn khi tải thay đổi, cho cả read và write.

Cụm từ quyết định đáp án là "automatically add additional query processing power" — tức là hệ thống phải tự bổ sung năng lực xử lý truy vấn khi có đợt tải dồn, không cần người vận hành ra tay. Chú ý nó không nói "đổi số node", cũng không nói "sắp xếp lại hàng đợi truy vấn cho hiệu quả hơn" — nó nói thêm năng lực. Hai chữ "dynamically" và "automatically" loại luôn những phương án phải kích hoạt thủ công, còn chữ "additional" loại những phương án chỉ tối ưu trong phạm vi tài nguyên đang có.

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

A — Activate concurrency scaling trong cấu hình WLM của cụm Redshift.

Concurrency scaling là tính năng của Amazon Redshift dành đúng cho tình huống này: khi lượng truy vấn dồn lên vượt sức của cụm chính, Redshift tự động và trong suốt đưa thêm cụm tính toán vào phục vụ, rồi thu lại khi hết đợt cao điểm. Người dùng không phải đổi endpoint, không phải sửa ứng dụng, không phải bấm nút gì.

Đây cũng là tính năng bật ngay trong cấu hình workload management (WLM) — bạn bật concurrency scaling cho một queue, và truy vấn đủ điều kiện trong queue đó sẽ được đẩy sang cụm phụ khi cụm chính bận. Cách bật khớp đúng chữ trong phương án A.

Về phạm vi, concurrency scaling xử lý được cả read và write, đúng như đề yêu cầu "cả read và write capacities" — đây là điểm phân biệt quan trọng, vì thời gian đầu tính năng này chỉ phục vụ truy vấn đọc.

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

B — Automatic WLM để quản lý hàng đợi truy vấn động. Đây là phương án gần đúng nhất và là cái bẫy chính. Automatic WLM đúng là "dynamic": nó tự phân bổ bộ nhớ và mức đồng thời cho các truy vấn thay vì bắt bạn khai tay từng queue. Nhưng nó chỉ sắp xếp lại tài nguyên đang có của cụm — chia bánh khéo hơn, không làm cái bánh to ra. Đề đòi additional query processing power, tức là thêm năng lực từ bên ngoài cụm hiện tại, và Automatic WLM không làm chuyện đó. Trên thực tế hai thứ này bổ trợ nhau: bạn dùng WLM để quản lý queue, rồi bật concurrency scaling trên queue đó để có thêm sức.

C — Gán Elastic IP cho từng node. Sai hoàn toàn về bản chất. Elastic IP là địa chỉ IPv4 tĩnh dùng cho cấu hình mạng, không liên quan gì tới năng lực tính toán của một data warehouse. Chữ "Elastic" trong tên là bẫy chữ nghĩa thuần tuý — nó nói về việc gán/gỡ địa chỉ, không nói về co giãn tài nguyên xử lý.

D — Elastic Resize để đổi số node theo nhu cầu. Đây là phương án gần đúng thứ hai và cũng thật sự thay đổi năng lực tính toán — Elastic Resize thêm hoặc bớt node của cụm, và với DC2 thì đây là cách hợp lệ để đổi kích thước cụm. Nhưng nó hỏng ở hai chỗ so với đề: thứ nhất, đây là thao tác resize chính cụm chứ không phải bổ sung năng lực tạm thời cho một đợt truy vấn dồn; thứ hai, nó không phải cơ chế tự động phản ứng theo tải truy vấn như concurrency scaling — resize là một hành động có chủ đích lên cấu hình cụm, và trong lúc thực hiện cụm bị ảnh hưởng. Đề nhấn "automatically add additional query processing power", chứ không phải "thay đổi kích thước cụm".

📌 Điểm cần nhớ

• "Thêm năng lực" khác "chia lại năng lực". Concurrency scaling thêm tài nguyên từ ngoài cụm; WLM (kể cả Automatic WLM) chỉ phân phối lại tài nguyên đang có. Thấy chữ "additional" hay "burst" trong đề là nghiêng về concurrency scaling.
• "Tự động theo tải" khác "resize cụm". Elastic Resize đổi số node của chính cụm và là thao tác lên hạ tầng; concurrency scaling phản ứng theo đợt truy vấn và trong suốt với ứng dụng.
• Concurrency scaling được bật qua cấu hình WLM. WLM và concurrency scaling không đối lập — chúng đi cùng nhau, nên đừng loại A chỉ vì thấy chữ "WLM" trong đó.
• Cảnh giác bẫy chữ "Elastic". Elastic IP thuộc phạm vi mạng của EC2, không dính gì tới co giãn năng lực Redshift; tên nghe giống nhau không có nghĩa là cùng nhóm chức năng.

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

Một tổ chức tài chính lưu các tệp chứa dữ liệu khách hàng nhạy cảm, trong đó có PII, trên Amazon S3. Họ muốn tự động phát hiện (discover), phân loại (classify) và bảo vệ dữ liệu nhạy cảm đó.

Cụm từ quyết định đáp án là "automatically discover, classify" dữ liệu nhạy cảm đang nằm trong S3. Đây không phải bài toán chặn truy cập, chặn tấn công, hay phát hiện hành vi bất thường — mà là bài toán nhìn vào bên trong nội dung của object trong S3 để biết tệp nào chứa PII. Cả bốn phương án đều là dịch vụ bảo mật của AWS, nhưng chỉ một dịch vụ làm việc ở tầng nội dung dữ liệu; ba dịch vụ còn lại làm việc ở tầng mạng, request, hoặc hành vi.

Thêm một manh mối nữa: đề nhắc tới compliance và PII. Khi câu hỏi ghép "S3 + PII + phân loại dữ liệu", nó đang mô tả gần như nguyên văn phạm vi của một dịch vụ duy nhất.

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

Đáp án đúng là C — Amazon Macie.

Macie là dịch vụ bảo mật dữ liệu chuyên quét nội dung object trong Amazon S3, dùng machine learning và pattern matching để nhận diện và phân loại dữ liệu nhạy cảm như PII (tên, số điện thoại, số căn cước, thông tin thẻ, thông tin tài chính). Nó khớp từng vế của đề:

• Discover: Macie quét các bucket S3 để tìm object nào thực sự chứa dữ liệu nhạy cảm, thay vì chỉ nhìn tên tệp hay tag.
• Classify: kết quả được phân loại theo kiểu dữ liệu nhạy cảm phát hiện được.
• Protect / compliance: Macie đánh giá, kiểm tra và báo cáo về dữ liệu tìm thấy, kèm phát hiện (findings) để đội bảo mật xử lý — đúng thứ mà một tổ chức tài chính cần để chứng minh tuân thủ quy định bảo vệ dữ liệu.

Điểm mấu chốt: Macie là dịch vụ duy nhất trong bốn phương án đọc nội dung dữ liệu trong S3 để trả lời câu hỏi "tệp này có PII không".

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

A — AWS WAF áp quy tắc lọc web cho truy cập vào S3 bucket. WAF là web application firewall, bảo vệ ứng dụng web khỏi các kiểu khai thác phổ biến (SQL injection, XSS, request độc hại) bằng cách lọc HTTP request đi qua các resource mà nó gắn vào. Nó làm việc với request, không hề biết bên trong object có gì. Dù có chặn được truy cập bất hợp lệ, WAF không bao giờ trả lời được "bucket này có bao nhiêu tệp chứa PII" — nó không discover, không classify.

B — AWS Shield Advanced chống DDoS nhắm vào dữ liệu trong S3. Đây là phương án lệch xa nhất khỏi đề. Shield Advanced chuyên giảm thiểu tấn công DDoS ở tầng mạng và tầng transport, tức bảo vệ tính sẵn sàng của dịch vụ. Đề không nói gì về việc bị tấn công làm gián đoạn truy cập; đề nói về tính bảo mật của nội dung dữ liệu. Hai vấn đề hoàn toàn khác nhau, và Shield không có bất kỳ khả năng phân loại dữ liệu nào.

D — Amazon GuardDuty giám sát liên tục và phát hiện mối đe doạ trên dữ liệu S3. Đây là phương án gần đúng nhất và cũng là cái bẫy chính của câu hỏi. GuardDuty đúng là dịch vụ bảo mật giám sát liên tục, đúng là có phần liên quan tới S3, nên đọc lướt rất dễ chọn nhầm. Nhưng GuardDuty phát hiện hành vi độc hại hoặc trái phép — ví dụ mẫu truy cập bất thường, thông tin xác thực có dấu hiệu bị lộ, truy cập từ nguồn đáng ngờ. Nó trả lời câu hỏi "có ai đang làm điều đáng ngờ với dữ liệu không", chứ không trả lời "dữ liệu này là loại gì, có nhạy cảm không". Nó không mở object ra để phân loại PII. Đề yêu cầu discover và classify, và đó chính là chỗ GuardDuty hỏng.

📌 Điểm cần nhớ

• Thấy từ khoá "discover / classify sensitive data / PII" gắn với S3 → nghĩ ngay tới Amazon Macie. Đây là cặp từ khoá – dịch vụ gần như một-đối-một trong đề thi AWS.
• Phân biệt bốn dịch vụ bảo mật theo tầng chúng làm việc: Macie ở tầng nội dung dữ liệu, GuardDuty ở tầng hành vi/mối đe doạ, WAF ở tầng HTTP request của ứng dụng web, Shield ở tầng mạng (DDoS/tính sẵn sàng).
• GuardDuty và Macie hay bị nhầm vì cả hai đều "giám sát bảo mật liên quan tới S3". Mẹo tách: GuardDuty theo dõi ai đang làm gì, Macie xem dữ liệu là gì.
• Ngữ cảnh compliance + dữ liệu tài chính/PII thường nghiêng về công cụ phân loại và báo cáo dữ liệu, chứ không phải công cụ phòng thủ tấn công.

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

Đề mô tả dữ liệu vận hành đang nằm trong S3 Standard với một vòng đời ba giai đoạn rất rõ ràng: truy cập thường xuyên trong 6 tháng đầu, thỉnh thoảng truy cập trong 18 tháng tiếp theo (tức tới mốc 2 năm), sau đó gần như không đụng tới nữa. Câu hỏi yêu cầu chọn S3 Lifecycle policy phù hợp.

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

• "maintains high availability throughout the data lifecycle" — yêu cầu độ sẵn sàng cao trong suốt vòng đời. Cụm này loại thẳng lớp lưu trữ chỉ đặt dữ liệu trong một Availability Zone.
• "rarely accessed thereafter" + "cost-effective" — sau 2 năm dữ liệu gần như không dùng tới, nên phải rơi vào lớp lưu trữ dài hạn rẻ nhất, chấp nhận thời gian khôi phục lâu.

Ngoài ra, việc access pattern đã được "data usage analysis" xác định rõ ràng theo mốc thời gian cũng là một tín hiệu: không cần lớp tự động dò tìm tầng lưu trữ.

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

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

Nó khớp từng khúc của vòng đời trong đề:

• 0–6 tháng: giữ nguyên S3 Standard cho giai đoạn truy cập thường xuyên.
• 6 tháng–2 năm: S3 Standard-IA sinh ra đúng cho dữ liệu ít được truy cập nhưng vẫn cần lấy ra ngay khi cần. Giá lưu trữ thấp hơn S3 Standard, đổi lại có phí truy xuất mỗi lần đọc — hợp với "occasionally accessed". Quan trọng hơn, Standard-IA lưu dữ liệu trên nhiều Availability Zone, nên vẫn đáp ứng yêu cầu high availability.
• Sau 2 năm: S3 Glacier Deep Archive là lớp lưu trữ có chi phí lưu trữ thấp nhất trong họ S3, thiết kế cho dữ liệu lưu trữ dài hạn gần như không đọc tới. Dữ liệu vẫn còn nguyên và lấy lại được, chỉ là thời gian khôi phục dài hơn hẳn — đánh đổi hoàn toàn chấp nhận được với "rarely accessed".

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

A — Standard-IA sau 6 tháng, rồi S3 Glacier sau 2 năm. Đây là phương án gần đúng nhất, và nửa đầu của nó giống hệt đáp án D. Chỗ hỏng nằm ở nửa sau: S3 Glacier (lớp Glacier Flexible Retrieval) được thiết kế cho dữ liệu lưu trữ mà thỉnh thoảng vẫn cần lấy ra tương đối nhanh, nên giá lưu trữ cao hơn Glacier Deep Archive. Với dữ liệu "rarely accessed" sau mốc 2 năm, trả thêm tiền lưu trữ để đổi lấy tốc độ khôi phục mà không ai dùng đến là đi ngược yêu cầu "cost-effective". Đề không hề nói cần khôi phục nhanh ở giai đoạn cuối.

B — S3 Intelligent-Tiering sau 6 tháng, rồi Glacier Deep Archive sau 2 năm. Intelligent-Tiering tự động dịch chuyển object giữa các access tier dựa trên hành vi truy cập thực tế, và nó là lựa chọn tốt khi access pattern không rõ hoặc thay đổi thất thường. Nhưng ở đây đề đã nói thẳng access pattern được phân tích và xác định rõ theo mốc 6 tháng / 24 tháng. Khi đã biết trước, việc trả thêm phí giám sát và tự động hoá theo từng object của Intelligent-Tiering là chi phí thừa — chỉ cần một lifecycle rule chuyển thẳng sang Standard-IA là đạt cùng kết quả với giá tốt hơn.

C — S3 One Zone-IA sau 6 tháng, rồi Glacier Deep Archive sau 2 năm. Phương án này rẻ hơn D ở chặng giữa, và đó chính là cái bẫy. One Zone-IA chỉ lưu dữ liệu trong một Availability Zone duy nhất, nên độ sẵn sàng thấp hơn Standard-IA và dữ liệu có nguy cơ mất nếu AZ đó gặp sự cố. Nó vi phạm trực tiếp ràng buộc "maintains high availability throughout the data lifecycle" mà đề nêu ra. One Zone-IA chỉ hợp lý với dữ liệu tái tạo lại được, không hợp với dữ liệu vận hành như tình huống này.

📌 Điểm cần nhớ

• Cụm "high availability" trong đề bài gần như luôn là dấu hiệu loại S3 One Zone-IA — lớp này đánh đổi độ bền vùng lấy giá rẻ, chỉ dùng cho dữ liệu có thể tạo lại.
• Phân biệt hai lớp archive: S3 Glacier Flexible Retrieval cho dữ liệu lưu trữ nhưng đôi khi cần lấy tương đối nhanh; S3 Glacier Deep Archive cho dữ liệu gần như không đụng tới và là lớp rẻ nhất. Đề nói "rarely accessed" + "cost-effective" thì chọn Deep Archive.
• Access pattern đã biết rõ → dùng S3 Lifecycle transition tường minh. Access pattern không đoán được → dùng S3 Intelligent-Tiering. Intelligent-Tiering không phải đáp án mặc định cho mọi câu hỏi tối ưu chi phí S3.
• Khi nhiều phương án chỉ khác nhau một mắt xích, hãy đối chiếu từng chặng thời gian trong đề với từng chặng trong phương án — đáp án sai thường chỉ hỏng đúng một chặng, như A hỏng ở chặng cuối và C hỏng ở chặng giữa.

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

Một startup có frontend Vue.js gọi backend qua Amazon API Gateway, và cần chạy một Python script xử lý dữ liệu theo từng request rồi trả kết quả về. Câu hỏi yêu cầu chọn cách tiếp cận "most efficiently".

Ba cụm từ trong đề quyết định đáp án:

• "serverless application" — hướng thẳng tới mô hình không quản lý máy chủ.
• "executed infrequently" — script chạy thưa thớt, nên bất kỳ thứ gì phải chạy thường trực đều lãng phí.
• "minimizing management overhead is a priority" — ràng buộc mạnh nhất: càng ít việc vá lỗi, cấu hình scaling, quản lý cluster càng tốt.

Cộng thêm chi tiết "return the results": kết quả phải quay về theo đúng request đồng bộ mà API Gateway đang phục vụ, chứ không phải một job chạy nền rồi lấy kết quả sau.

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

C — AWS Lambda function bằng Python, được API Gateway kích hoạt.

Lambda khớp cả ba ràng buộc cùng lúc. Về vận hành, AWS lo toàn bộ hạ tầng bên dưới: không có instance để vá, không có cluster để trông, không có cấu hình auto scaling để chỉnh — đúng nghĩa "minimizing management overhead". Về mô hình chi phí và tần suất, Lambda chỉ chạy khi có request tới, nên với script chạy thưa thớt thì không phải trả cho thời gian nằm không. Về tích hợp, API Gateway có tích hợp sẵn với Lambda: request đi vào, Lambda thực thi, response trả thẳng về cho frontend Vue.js trong cùng lời gọi — không cần dựng thêm lớp trung gian nào. Ngoài ra khi lưu lượng biến động khó đoán, Lambda tự co giãn theo số request mà startup không phải làm gì thêm.

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

A — AWS Fargate chạy container hoá script, rồi trỏ API Gateway vào service đó. Đây là phương án gần đúng nhất, và nó cũng là serverless theo nghĩa không quản lý EC2 instance. Nó hỏng ở chỗ độ nặng so với nhu cầu: Fargate hợp với ứng dụng cần chạy liên tục hoặc cần orchestration phức tạp, còn ở đây chỉ là một script chạy thưa. Đi kèm là việc phải đóng gói container image, quản lý task definition và service, thêm một lớp networking cùng load balancer để API Gateway gọi tới được — toàn bộ đều là management overhead mà đề yêu cầu tối thiểu hoá.

B — Host script trên Amazon EC2 instance, API Gateway gọi vào. Sai rõ nhất với ràng buộc "minimizing management overhead": startup phải tự lo hệ điều hành, bản vá bảo mật, cấu hình scaling và giám sát instance. Thêm nữa, với script chạy thưa thớt thì instance vẫn phải bật để sẵn sàng nhận request, tức là trả tiền cho phần lớn thời gian không làm gì.

D — Viết script thành AWS Glue job, kích hoạt qua API Gateway bằng SDK integration. Glue là dịch vụ ETL được quản lý, sinh ra cho các job xử lý dữ liệu theo lô. Dùng nó cho một script đơn giản là quá tay. Quan trọng hơn, Glue job không phải mô hình request–response: nó được khởi chạy rồi chạy như một job, nên không trả kết quả về cho lời gọi API Gateway một cách trực tiếp và kịp thời như Lambda. Đề nói rõ script phải "return the results" theo request, nên điểm này đủ để loại D.

📌 Điểm cần nhớ

• Cụm "minimize management/operational overhead" trong đề AWS gần như luôn đẩy lựa chọn về phía dịch vụ fully managed; EC2 tự quản lý bị loại đầu tiên.
• Khi có thêm "infrequently" / "unpredictable traffic", Lambda thường thắng cả Fargate: cả hai đều không cần quản lý server, nhưng Lambda không cần đóng gói container, không cần service chạy thường trực.
• Phân biệt theo mô hình phản hồi: cần trả kết quả ngay trong request HTTP → Lambda sau API Gateway. Cần xử lý ETL theo lô, chạy nền → Glue. Đọc kỹ chỗ đề nói kết quả đi về đâu.
• API Gateway + Lambda là cặp mặc định cho backend serverless; các phương án ghép API Gateway với EC2, Fargate hay Glue luôn đòi thêm lớp trung gian hoặc thêm việc vận hành.

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

Một nhóm phân tích dữ liệu có sẵn một tập dữ liệu giao dịch bán hàng lớn nằm trên S3, và họ muốn tạo ra một bảng tổng hợp (summarized table) để phân tích nhanh. Câu hỏi yêu cầu chọn dịch vụ AWS làm việc đó một cách hiệu quả, trực tiếp từ dữ liệu trên S3.

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

• "quick analysis" — nhóm cần kết quả nhanh, không phải dựng một đường ống dữ liệu chạy định kỳ.
• "directly from the S3 dataset" — dữ liệu phải được đọc tại chỗ trên S3, không cần nạp (load) vào một kho dữ liệu khác trước.
• "efficiently create this aggregated table" — tiêu chí là ít công sức vận hành nhất, chứ không phải năng lực xử lý mạnh nhất.

Cả bốn phương án đều làm được việc tổng hợp dữ liệu. Đây là kiểu câu hỏi phân biệt bằng chi phí vận hành (operational overhead): phương án nào cũng cho ra bảng tổng hợp, nhưng chỉ một phương án không bắt bạn dựng và quản lý bất cứ hạ tầng nào.

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

B — Dùng Amazon Athena với câu lệnh CREATE TABLE AS SELECT (CTAS).

Athena là dịch vụ truy vấn serverless, đọc thẳng dữ liệu nằm trên S3 bằng SQL mà không cần nạp dữ liệu đi đâu cả. Tính năng CTAS cho phép tạo một bảng mới từ kết quả của một câu SELECT trên bảng đã có — nghĩa là chỉ cần viết đúng một câu SQL dạng gộp nhóm (ví dụ doanh số theo khu vực và theo nhóm sản phẩm) là ra ngay bảng tổng hợp mong muốn, và kết quả cũng được ghi trở lại S3.

Điều này khớp trọn vẹn với đề bài: không có cluster nào phải khởi tạo, không có job ETL nào phải cấu hình, không có kho dữ liệu nào phải nạp trước. Nhóm chỉ trả tiền cho truy vấn họ chạy, nên với một nhu cầu tổng hợp nhanh và mang tính ad-hoc thì đây là lựa chọn gọn nhất cả về thời gian lẫn chi phí.

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

A — AWS Glue ETL job để transform và aggregate, rồi ghi kết quả về S3. Đây là phương án gần đúng nhất về mặt kỹ thuật: Glue đúng là đọc được S3 và đúng là tạo ra được bảng tổng hợp ghi ngược lại S3. Chỗ nó hỏng là quá nặng so với nhu cầu. Dùng Glue nghĩa là phải định nghĩa job, viết mã transform, cấu hình và chạy job đó — một bộ máy dựng cho các phép biến đổi dữ liệu lặp lại theo lịch. Đề bài chỉ cần một phép gộp nhóm để xem nhanh, và một câu CTAS làm xong việc đó mà không cần dựng job nào.

C — Redshift Spectrum truy vấn dữ liệu S3 rồi tạo bảng tổng hợp trong Redshift. Redshift Spectrum thật sự đọc được dữ liệu trên S3 mà không cần nạp vào, nên phương án này nghe rất hợp lý. Nhưng nó kéo theo một Redshift cluster phải có và phải quản lý — thứ mà Athena hoàn toàn không cần. Ngoài ra Redshift là công cụ hướng tới các khối lượng phân tích phức tạp và chạy thường xuyên, chứ không phải các phép gộp nhanh, làm một lần như trong đề. Chi phí vận hành thừa ra chính là chỗ nó thua B.

D — Cluster Amazon EMR chạy Hive script để tổng hợp, lưu bảng về S3. Đây cũng là một giải pháp chạy được: Hive trên EMR xử lý tốt dữ liệu lớn trên S3 và ghi bảng kết quả về S3. Vấn đề y hệt phương án C — phải cấp phát và quản lý một EMR cluster. So với bản chất serverless của Athena, việc này thêm cả một lớp vận hành (chọn cấu hình cluster, khởi tạo, theo dõi, tắt đi) chỉ để thực hiện một phép tổng hợp mà SQL làm được ngay.

📌 Điểm cần nhớ

• Khi đề nhấn "query dữ liệu trực tiếp trên S3" kèm "nhanh" hoặc "ad-hoc", Athena thường là đáp án — vì nó serverless và không cần nạp dữ liệu đi đâu.
• CTAS trong Athena là công cụ chuẩn để tạo bảng tổng hợp từ kết quả một câu SELECT; nhớ tên tính năng này, vì nó tách Athena khỏi các phương án còn lại trong đúng loại câu hỏi này.
• Khi nhiều phương án đều làm được việc, tiêu chí phân loại thường là operational overhead: giải pháp phải dựng cluster (EMR, Redshift) hay phải cấu hình job (Glue) sẽ thua giải pháp serverless.
• Phân vai để chọn nhanh: Glue = ETL biến đổi dữ liệu lặp lại theo lịch; Redshift/Spectrum = phân tích phức tạp, chạy liên tục trên kho dữ liệu; EMR = xử lý dữ liệu lớn bằng framework như Hive/Spark khi cần kiểm soát cluster; Athena = truy vấn SQL nhanh, không hạ tầng.

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

Đề mô tả một truy vấn Athena trên bảng interaction_data lưu trong S3, gom tổng số lượt tương tác theo từng khách hàng trong năm 2023:

SELECT customer_id, sum(interactions)
FROM interaction_data
WHERE year = 2023
GROUP BY customer_id

Vấn đề: "is not yielding results for some customers known to have interactions in that year" — kết quả thiếu hẳn dòng của một số khách hàng, chứ không phải sai con số. Cụm quyết định nằm ở hai chỗ:

• "not yielding results for some customers" — thiếu bản ghi ở mức khách hàng. GROUP BY chỉ sinh ra dòng cho những customer_id thực sự có dòng dữ liệu lọt qua bộ lọc WHERE. Khách hàng nào không có dòng nào trong interaction_data khớp điều kiện thì đơn giản là biến mất khỏi kết quả — không phải ra 0, mà là không có dòng nào.
• "to correctly reflect the entire dataset" / "includes all relevant customer data" — yêu cầu là danh sách khách hàng đầy đủ, kể cả người có 0 lượt tương tác.

Đây là câu về hình dạng kết quả của phép JOIN/aggregation trong SQL, không phải về cú pháp Athena hay về phân vùng dữ liệu. Hiểu đúng ràng buộc "phải xuất hiện đủ mọi khách hàng" là đủ để loại ba phương án còn lại.

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

A — Thêm LEFT JOIN với một bảng liệt kê toàn bộ khách hàng.

Nguyên lý của LEFT JOIN: giữ lại mọi dòng của bảng bên trái và chỉ ghép thêm dòng khớp từ bảng bên phải; không khớp thì các cột bên phải là NULL. Đặt danh sách khách hàng đầy đủ ở bên trái và interaction_data ở bên phải, kết quả sẽ chứa tất cả khách hàng, kể cả người không có dòng tương tác nào trong 2023 — họ vẫn hiện ra, với NULL (hoặc 0 nếu bọc thêm hàm xử lý null) ở cột tổng.

Điều này xử lý đúng gốc rễ vấn đề mà đề nêu: bảng interaction_data không phải là nguồn đầy đủ về tập khách hàng, nó chỉ chứa các sự kiện tương tác. Muốn báo cáo phủ hết mọi khách hàng thì tập khách hàng phải đến từ một bảng khác, còn interaction_data chỉ đóng vai trò bổ sung số liệu. Đây là mẫu chuẩn trong báo cáo phân tích: lấy bảng chiều (dimension) làm bên trái, bảng sự kiện (fact) làm bên phải.

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

B — Đổi WHERE year = 2023 thành WHERE year >= 2023.

Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì nó có vẻ "mở rộng dữ liệu ra". Nhưng nó mở rộng sai chiều: nó kéo thêm dữ liệu của các năm sau 2023 vào, làm hỏng chính yêu cầu của báo cáo (chỉ tính năm 2023) và cho ra con số bị thổi phồng. Trong khi đó, khách hàng không có dòng nào trong interaction_data thì nới rộng điều kiện WHERE kiểu gì cũng vẫn không có dòng để GROUP BY sinh ra — họ vẫn tiếp tục biến mất. Nới bộ lọc không tạo được dòng từ chỗ không có dòng.

C — Dùng CASE bên trong SUM để xử lý giá trị null ở cột interactions.

Phương án này giải một bài toán khác: nó ảnh hưởng tới giá trị của cột tổng, không ảnh hưởng tới số dòng trả về. Hơn nữa SUM trong SQL vốn đã bỏ qua NULL, nên với một khách hàng có dòng dữ liệu, việc thêm CASE gần như không đổi kết quả. Còn với khách hàng không có dòng nào khớp WHERE, hàm tổng hợp thậm chí không được gọi tới — không có gì để CASE xử lý cả.

D — Dùng subquery lấy distinct customer_id từ chính dữ liệu tương tác rồi tính tổng cho các khách hàng đó.

Đây là phương án hỏng ở một điểm rất cụ thể: tập khách hàng vẫn được lấy từ chính interaction_data. Mà đó đúng là bảng đang thiếu người. Lấy DISTINCT customer_id từ một bảng không chứa khách hàng X thì X vẫn không xuất hiện, dù có bọc thêm bao nhiêu lớp subquery. Nó chỉ viết lại truy vấn cho phức tạp hơn mà cho ra đúng tập kết quả cũ. Muốn có đủ khách hàng thì danh sách khách hàng phải đến từ nguồn bên ngoài bảng sự kiện — đúng như A làm.

📌 Điểm cần nhớ

• GROUP BY chỉ sinh dòng cho các giá trị thực sự tồn tại trong dữ liệu sau khi lọc. Nó không bao giờ tự tạo dòng "0" cho những khoá vắng mặt — muốn có đủ khoá thì phải LEFT JOIN từ một bảng chứa danh sách đầy đủ.
• Phân biệt rõ hai triệu chứng khi đọc đề: thiếu dòng (vấn đề về JOIN / tập khoá) khác hẳn sai giá trị (vấn đề về NULL, kiểu dữ liệu, hoặc điều kiện lọc). Xử lý NULL không bao giờ chữa được chuyện thiếu dòng.
• Bảng sự kiện (fact) như interaction_data không phải là nguồn đầy đủ về tập thực thể. Báo cáo cần phủ hết thực thể thì phải lấy bảng chiều (dimension) làm bên trái của LEFT JOIN.
• Nới lỏng điều kiện WHERE để "bắt thêm dữ liệu" là một sửa chữa nguy hiểm: nó thường phá luôn ràng buộc nghiệp vụ của báo cáo (ở đây là "chỉ năm 2023") mà vẫn không giải quyết được vấn đề gốc.

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

Một công ty truyền thông tải video độ phân giải cao lên một bucket Amazon S3. Ngay khi video được tải lên, một hàm AWS Lambda phải chạy để tạo các bản độ phân giải thấp hơn. Câu hỏi yêu cầu chọn dịch vụ AWS nào dùng để tự động kích hoạt hàm Lambda khi có video mới được upload.

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

• "as soon as a video is uploaded ... an AWS Lambda function is triggered" — nguồn sự kiện là thao tác ghi object vào S3, và đích cần gọi là một hàm Lambda duy nhất.
• "Which AWS service should the company use to automatically trigger the Lambda function" — đề chỉ hỏi cơ chế kích hoạt, không hỏi cách điều phối một quy trình nhiều bước, cũng không hỏi cách xử lý một luồng dữ liệu liên tục.

Đọc kỹ hai cụm này thì bài toán rút gọn còn: nối trực tiếp S3 → Lambda. Mọi phương án thêm một dịch vụ trung gian vào giữa đều đang giải một bài toán rộng hơn đề bài.

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

Đáp án đúng là C — Use Amazon S3 Event Notifications to directly invoke the Lambda function when a new video is uploaded.

Amazon S3 Event Notifications là tính năng có sẵn của chính S3: bạn cấu hình trên bucket rằng khi có sự kiện tạo object mới, S3 sẽ phát thông báo tới một đích được khai báo, và AWS Lambda là một trong những đích được hỗ trợ trực tiếp. Không cần dịch vụ nào đứng giữa.

Điều này khớp chính xác với yêu cầu của đề:

• Sự kiện phát ra ngay khi object được ghi vào bucket, nên video được xử lý gần như tức thì như đề đòi hỏi.
• Đây là tích hợp native giữa S3 và Lambda, ít thành phần nhất, ít chỗ hỏng nhất, và cũng ít việc phải cấu hình nhất.
• Có thể lọc theo tiền tố và hậu tố tên object, nên chỉ những file video trong đúng thư mục mới kích hoạt hàm xử lý.

Nói gọn: đề hỏi "dịch vụ nào để kích hoạt Lambda khi upload lên S3", và S3 Event Notifications chính là tính năng sinh ra để làm đúng việc đó.

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

A — Configure Amazon CloudWatch Events to detect the S3 upload event and trigger the Lambda function. Đây là phương án gần đúng nhất, nên cần nói rõ nó hỏng ở đâu. CloudWatch Events (nay là EventBridge) thật sự có thể bắt các thao tác mức object của S3 và gọi Lambda — nên nó không phải là sai về mặt kỹ thuật. Nhưng đó là con đường gián tiếp: sự kiện phải đi qua thêm một lớp dịch vụ nữa, và bản thân S3 cần được bật gửi sự kiện sang EventBridge thì rule mới bắt được. Với một yêu cầu đơn giản "upload xong thì gọi một hàm", đi vòng qua CloudWatch Events là thêm thành phần mà không đổi lại được gì. EventBridge chỉ xứng đáng khi bạn cần fan-out nhiều đích, cần lọc theo nhiều điều kiện phức tạp, hoặc cần định tuyến sự kiện cho nhiều consumer — đề bài không có nhu cầu nào trong số đó.

B — Set up AWS Step Functions to orchestrate the process, triggering the Lambda function upon S3 object upload. Step Functions là dịch vụ điều phối workflow — nó nối nhiều bước, xử lý rẽ nhánh, retry, chờ đợi giữa các tác vụ. Vấn đề căn bản: Step Functions không phải là nguồn sự kiện của S3. Bản thân nó không "nghe" bucket; muốn state machine chạy khi có upload thì vẫn cần một cơ chế khác kích hoạt nó trước. Ngoài ra đề chỉ có đúng một bước xử lý (tạo bản độ phân giải thấp), không có workflow nào để điều phối cả. Đây là dùng dao mổ trâu để cắt tiết gà.

D — Implement Amazon Kinesis Data Streams to capture upload events and trigger the Lambda function. Kinesis Data Streams dùng cho luồng dữ liệu bản ghi liên tục, thông lượng cao, với khái niệm shard, consumer và thứ tự bản ghi. Nó không được thiết kế để làm bộ bắt sự kiện cho thao tác ghi object trên S3. Muốn ép nó vào bài toán này thì vẫn phải có gì đó đẩy sự kiện upload vào stream trước — tức là quay lại đúng vấn đề ban đầu, chỉ thêm một hệ thống phải vận hành và trả tiền. Phức tạp không cần thiết.

📌 Điểm cần nhớ

• Đề hỏi "cái gì kích hoạt Lambda khi object vào S3" và không có yêu cầu nào khác → mặc định trả lời S3 Event Notifications. Đây là tích hợp native, đích Lambda được hỗ trợ trực tiếp.
• Phân biệt nguồn sự kiện và bộ điều phối: S3 Event Notifications / EventBridge là nguồn sự kiện; Step Functions là bộ điều phối, nó được kích hoạt chứ không tự phát hiện upload.
• EventBridge (CloudWatch Events) không sai, nhưng gián tiếp hơn. Chỉ chọn nó khi đề nêu rõ nhu cầu định tuyến sự kiện tới nhiều đích, lọc phức tạp, hoặc gom sự kiện từ nhiều nguồn khác nhau.
• Kinesis Data Streams thuộc nhóm streaming dữ liệu, không phải nhóm event trigger. Thấy nó xuất hiện trong câu hỏi chỉ có một hành động đơn lẻ trên S3 thì gần như chắc chắn là phương án gây nhiễu.
• Nguyên tắc chung khi làm trắc nghiệm AWS: giữa nhiều phương án đều "chạy được", phương án ít thành phần trung gian nhất và dùng tích hợp có sẵn thường là đáp án.