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 đang chạy database thương mại có bản quyền (legacy commercial database) tại data center on-premises và muốn chuyển sang một lựa chọn open-source, tiết kiệm chi phí trên AWS. Câu hỏi yêu cầu chọn hai dịch vụ kết hợp lại để làm việc này.

Có hai cụm từ quyết định đáp án:

1. "legacy commercial" → "open-source": nguồn và đích là hai engine khác nhau (ví dụ Oracle → Aurora/PostgreSQL, SQL Server → MySQL). Đây là heterogeneous migration, không phải homogeneous. Chính vì khác engine mà cấu trúc schema, kiểu dữ liệu và mã trong database không tương thích, nên cần thêm một bước chuyển đổi schema trước khi chuyển dữ liệu.

2. "secondary indexes, foreign keys, and stored procedures": đây là ràng buộc lọc ra phương án gần đúng. Cụm này được đặt vào đề để loại thẳng Basic Schema Copy — nó chính là ba thứ Basic Schema Copy không làm được.

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

Đáp án là C (AWS Schema Conversion Tool) và D (AWS Database Migration Service) — đúng hai bước của một heterogeneous migration:

• AWS SCT chuyển đổi schema và mã của database nguồn sang dạng phù hợp với database đích: bảng, secondary indexes, foreign keys, view, và cả stored procedures — tức là toàn bộ những object phức tạp mà đề nêu đích danh. Đây là bước làm trước.
• AWS DMS sau đó chuyển dữ liệu từ nguồn sang đích. DMS hỗ trợ cả homogeneous (Oracle → Oracle) lẫn heterogeneous migration, tự động lo phần chuyển đổi kiểu dữ liệu trong lúc chạy, và quan trọng là database nguồn vẫn hoạt động bình thường trong suốt quá trình nên downtime của ứng dụng là tối thiểu. Nguồn có thể nằm on-premises, trên EC2 hoặc RDS; đích có thể là database trên EC2 hoặc RDS.

Tách vai trò cho gọn: SCT lo cấu trúc, DMS lo dữ liệu. Thiếu SCT thì schema phức tạp không sang được; thiếu DMS thì có schema rỗng mà không có dữ liệu.

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

A. AWS Snowball Edge — thiết bị vật lý để chuyển khối lượng dữ liệu rất lớn (hàng chục TB đến petabyte) lên AWS khi đường truyền mạng không kham nổi. Bản Storage Optimized còn kèm vCPU và SSD cho việc tiền xử lý tại chỗ. Nhưng nó là công cụ chuyển tệp, không hiểu schema database, không chuyển đổi kiểu dữ liệu, không giữ đồng bộ khi nguồn vẫn đang ghi. Snowball Edge không dùng cho database migration.

B. AWS Glue — dịch vụ ETL được quản lý hoàn toàn, dùng để chuẩn bị và nạp dữ liệu cho mục đích analytics. Glue job hướng tới xử lý batch ETL, không phải công cụ di trú database: nó không chuyển đổi stored procedures, không dựng lại foreign keys, không có cơ chế giữ nguồn hoạt động liên tục như DMS.

E. Basic Schema Copy — đây là phương án gần đúng nhất và cũng là cái bẫy chính. Nó thực sự là một tính năng của DMS, thực sự tạo được schema ở đích, và thực sự dùng cho heterogeneous migration. Nhưng nó chỉ tạo bảng và primary key, và chỉ khi đích chưa có bảng trùng tên. Nó không chuyển secondary indexes, foreign keys hay stored procedures — đúng ba thứ đề bài liệt kê. Basic Schema Copy hợp cho migration thử nghiệm; khi cần quy trình chuyển schema tuỳ biến hơn cho database production có các database object phụ, phải dùng AWS SCT.

📌 Điểm cần nhớ

• Thấy nguồn và đích khác engine (commercial → open-source) thì nghĩ ngay tới quy trình hai bước: SCT trước (schema + code), DMS sau (dữ liệu). Cùng engine thì DMS một mình là đủ.
• Đề nhắc secondary indexes / foreign keys / stored procedures là tín hiệu loại Basic Schema Copy và chọn SCT — Basic Schema Copy chỉ lo bảng và primary key.
• Phân biệt theo loại việc, không theo độ lớn dữ liệu: Snowball Edge chuyển khối tệp lớn, Glue làm ETL cho analytics, còn di trú database là địa hạt riêng của DMS + SCT.
• Điểm bán hàng của DMS là nguồn vẫn chạy trong lúc di trú, nên downtime tối thiểu — hay xuất hiện trong các câu có ràng buộc "minimal downtime".

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

Đề mô tả một đội data engineering muốn phân tích access pattern trên Amazon S3 để quyết định khi nào chuyển dữ liệu sang storage class phù hợp. Rồi hỏi: phát biểu nào đúng về khả năng của Amazon S3 Analytics – Storage Class Analysis?

Cụm từ quyết định nằm ở chính tên tính năng: Storage Class Analysis, chứ không phải "lifecycle policy" hay "storage class nào cũng chuyển được". Bốn phương án đều mở đầu giống hệt nhau — "only provides recommendations for Standard to ..." — nên thứ duy nhất phân biệt chúng là đích đến của khuyến nghị: Standard IA, One-Zone IA, Glacier Flexible Retrieval, hay Glacier Deep Archive.

Đây là dạng câu kiểm tra xem người học có nhớ phạm vi hẹp của tính năng này không. Storage Class Analysis quan sát dữ liệu ít được truy cập (infrequently accessed) trong STANDARD và đưa ra khuyến nghị chuyển sang STANDARD_IA. Nó không phải công cụ tư vấn cho toàn bộ vòng đời dữ liệu.

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

B — Storage class analysis only provides recommendations for Standard to Standard IA classes.

Theo tài liệu AWS, S3 Analytics Storage Class Analysis quan sát access pattern của dữ liệu để giúp xác định khi nào nên chuyển dữ liệu STANDARD ít được truy cập sang STANDARD_IA. Đó chính xác là phạm vi khuyến nghị mà tính năng này đưa ra — không rộng hơn.

Cách hoạt động: sau khi theo dõi pattern truy cập của một tập dữ liệu đã lọc trong một khoảng thời gian, kết quả phân tích được dùng để cải thiện cấu hình lifecycle. Bạn có thể cho nó phân tích toàn bộ object trong một bucket, hoặc dùng filter để nhóm object theo prefix chung, theo object tag, hoặc kết hợp cả hai.

Điểm cần nắm về mặt phân vai: Storage Class Analysis chỉ đề xuất, còn việc chuyển dữ liệu thật sự vẫn do S3 Lifecycle configuration thực hiện. Lifecycle thì chuyển được sang nhiều class khác nhau; nhưng phần phân tích và khuyến nghị thì chỉ nhắm vào cặp STANDARD → STANDARD_IA.

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

A — Standard to Glacier Flexible Retrieval. Đây là phương án dễ gây nhầm vì Glacier Flexible Retrieval đúng là một đích archive rất phổ biến trong lifecycle policy. Nhưng nhầm ở chỗ gán việc của lifecycle cho Storage Class Analysis. Storage Class Analysis quan sát tần suất truy cập để nhận diện dữ liệu "infrequent access" — nó không đưa ra khuyến nghị archive sang Glacier.

C — Standard to Glacier Deep Archive. Sai theo cùng một kiểu như A, và còn xa hơn nữa. Deep Archive dành cho dữ liệu gần như không bao giờ đọc, thường lưu rất dài hạn; quyết định đưa dữ liệu vào đó thường xuất phát từ yêu cầu compliance và chính sách lưu trữ của tổ chức, chứ không phải từ một phân tích access pattern ngắn hạn. Storage Class Analysis không sinh ra khuyến nghị này.

D — Standard to Standard One-Zone IA. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: nó chỉ khác đáp án đúng đúng hai chữ "One-Zone". Cả hai đều là tầng infrequent access, nhưng One-Zone IA lưu dữ liệu trong một Availability Zone duy nhất, tức là đánh đổi độ bền/khả dụng lấy giá rẻ hơn. Việc chấp nhận đánh đổi đó là quyết định thiết kế của bạn về mức rủi ro chấp nhận được với dữ liệu, không phải thứ suy ra được từ access pattern. Storage Class Analysis chỉ nói cho bạn biết "dữ liệu này ít được truy cập" — nên khuyến nghị của nó dừng ở STANDARD_IA.

📌 Điểm cần nhớ

• S3 Analytics Storage Class Analysis chỉ khuyến nghị STANDARD → STANDARD_IA. Thấy phương án nào ghép nó với Glacier, Glacier Deep Archive hay One-Zone IA thì loại ngay.
• Phân tích ≠ thực thi. Storage Class Analysis chỉ quan sát và đề xuất; việc chuyển class thực sự do S3 Lifecycle configuration làm. Lifecycle chuyển được sang nhiều class, nhưng đó không phải phạm vi khuyến nghị của Analytics.
• Có thể thu hẹp phạm vi phân tích bằng filter: toàn bộ bucket, theo prefix, theo object tag, hoặc kết hợp prefix + tag.
• Với các câu mà bốn phương án chỉ khác nhau một cụm từ, hãy khoanh ngay vào phần khác biệt đó thay vì đọc lại toàn bộ câu — ở đây là tên storage class đích.

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

Một công ty thương mại điện tử chạy workload trên các cluster Amazon EMR. Mỗi khi cluster mới được tạo, đội data engineering phải SSH vào master node và cài thủ công các thư viện third-party. Yêu cầu: tìm cách tự động hoá, bỏ hẳn thao tác tay này. Đề yêu cầu chọn hai phương án.

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

• "newly launched clusters" — việc cài đặt phải xảy ra trong quá trình khởi tạo cluster, tự động cho mọi node mới, chứ không phải một hành động con người bấm sau khi cluster đã chạy.
• "third-party libraries" — đây là phần mềm bổ sung nằm ngoài bộ ứng dụng mà EMR cài sẵn, nên phải chèn vào bằng cơ chế tuỳ biến mà EMR hỗ trợ sẵn: custom bootstrap actions hoặc custom AMI.

Hai cơ chế đó chính là hai đáp án. Mọi phương án còn lại đều hoặc vẫn cần người can thiệp, hoặc mô tả một cách làm mà EMR không hỗ trợ.

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

C — Tạo EC2 instance chạy Amazon Linux, cài thư viện lên đó, tạo AMI từ instance này, rồi dùng AMI đó để launch EMR cluster

EMR cho phép launch cluster bằng custom AMI dựa trên Amazon Linux. Bạn dựng một EC2 instance, cài sẵn toàn bộ thư viện third-party cần thiết, chụp lại thành AMI, rồi chỉ định AMI đó khi tạo cluster. Mọi node bung ra từ AMI này đã có sẵn thư viện — không cần cài lại, không cần đăng nhập vào master node. Đây là cách "nướng sẵn" (pre-bake) phần mềm vào image.

E — Đưa script cài đặt lên Amazon S3 và chạy bằng custom bootstrap actions

Bootstrap action là script chạy trên các instance của cluster sau khi EMR launch instance từ AMI Amazon Linux, nhưng trước khi EMR cài các ứng dụng bạn khai báo và trước khi node bắt đầu xử lý dữ liệu. Script được đọc từ S3 và chạy trên mọi node, tự động ở mỗi lần tạo cluster. Đây đúng là chỗ để cài thêm phần mềm hoặc tuỳ biến cấu hình, và nó thay thế trọn vẹn thao tác thủ công hiện tại.

Hai đáp án bổ sung cho nhau: custom AMI nướng sẵn vào image (khởi động nhanh hơn, nhưng phải dựng lại AMI khi đổi thư viện), bootstrap action cài lúc chạy (linh hoạt hơn, sửa script trên S3 là xong).

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

A — Đưa script lên S3 rồi chạy bằng AWS EMR CLI

Đây là phương án gần đúng nhất và dễ mắc bẫy: phần "để script trên S3" hoàn toàn đúng. Chỗ hỏng nằm ở cơ chế chạy. Script trên S3 được nạp vào cluster thông qua custom bootstrap actions — đó mới là cách EMR định nghĩa để tự động cài phần mềm lúc khởi tạo. EMR CLI không phải thứ thay thế được bootstrap actions cho tình huống này; nó là công cụ điều khiển cluster, không phải cơ chế chạy script cài đặt trên từng node lúc cluster bung ra.

B — Tạo EC2 instance, cài thư viện, rồi dùng chính EC2 instance đó để launch EMR cluster

Sai ở một điểm rất cụ thể: bạn không thể dùng trực tiếp một EC2 instance để launch EMR cluster. EMR cần một AMI để tạo node. Phương án này chỉ khác đáp án C đúng một bước — thiếu bước chụp instance thành AMI — và chính bước bị thiếu đó khiến nó không thực hiện được. Cặp B/C là ví dụ điển hình của distractor "thiếu một mắt xích".

D — Đưa script lên DynamoDB và dùng Lambda function chạy chúng để cài thư viện lên EMR cluster

Đây là distractor thuần tuý. Với custom bootstrap actions, script chỉ nạp được từ Amazon S3 — DynamoDB không phải nguồn hợp lệ cho việc này. DynamoDB là NoSQL database dùng cho dữ liệu ứng dụng, không phải nơi lưu và phân phối file script. Việc thêm Lambda vào chuỗi cũng không sửa được vấn đề gốc: cơ chế cài đặt lúc khởi tạo cluster không đi qua đường đó.

📌 Điểm cần nhớ

• Hai cách chính thống để cài phần mềm bổ sung lên EMR cluster: custom bootstrap actions (script trên S3, chạy lúc node khởi tạo) và custom AMI (nướng sẵn thư viện vào image trước khi launch).
• Bootstrap actions chạy sau khi instance được launch từ AMI, nhưng trước khi EMR cài các ứng dụng khai báo và trước khi node xử lý dữ liệu — đúng thời điểm để đặt thư viện dependency vào chỗ.
• Script cho bootstrap actions chỉ đọc được từ Amazon S3. Thấy phương án nào để script ở DynamoDB, EFS hay nơi khác thì loại ngay.
• EMR launch từ AMI, không launch từ một EC2 instance đang chạy. Phương án nào bỏ qua bước tạo AMI là phương án không chạy được — đây là kiểu bẫy "thiếu một bước" hay xuất hiện trong đề.

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

Một công ty có nhiều Lambda function cùng dùng chung một bộ custom Python script do data engineer duy trì. Vấn đề: mỗi khi sửa script dùng chung, hiện tại phải đi cập nhật lại code trong từng function một. Câu hỏi tìm cách giảm công vận hành/bảo trì cho việc cập nhật đó.

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

• "common custom Python scripts" dùng bởi "multiple AWS Lambda functions" — tức là bài toán chia sẻ code dùng chung giữa nhiều function, không phải bài toán đóng gói cho một function.
• "reduce the operational/maintenance work of updating the code ... when a change has to be made" — lời giải phải cho phép sửa một chỗ, mọi function hưởng, chứ không phải sửa rồi build lại từng function.

Ghép hai ràng buộc này lại thì thứ cần tìm là một cơ chế đóng gói code tách rời khỏi function, gắn được cho nhiều function cùng lúc — đúng định nghĩa của Lambda layer.

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

Đáp án C — đóng gói script vào Lambda layers rồi gắn layer đó cho tất cả các function đang dùng script.

Lambda layer là một kho lưu trữ dạng .zip chứa code hoặc dữ liệu bổ trợ: thư viện phụ thuộc, custom runtime, hoặc file cấu hình. Tài liệu AWS nêu thẳng các lý do dùng layer, trong đó có hai lý do khớp chính xác với đề bài:

• Tách phần logic lõi của function ra khỏi phần dependency.
• Chia sẻ dependency giữa nhiều function.

Với layer, bộ script dùng chung nằm ở một artifact duy nhất. Khi script đổi, data engineer chỉ cần publish phiên bản mới của layer rồi trỏ các function sang phiên bản đó — không phải sửa và đóng gói lại code của từng function. Đó chính là phần "giảm operational/maintenance work" mà đề hỏi.

Một chi tiết nên nhớ kèm: mỗi function gắn được tối đa năm layer, và layer chỉ dùng được với function triển khai dạng .zip archive.

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

A — Đóng gói function thành container image rồi thêm Lambda layer vào cấu hình function. Đây là phương án gần đúng nhất và cũng là cái bẫy chính: nó có nhắc tới layer. Nhưng function triển khai dưới dạng container image không hỗ trợ gắn Lambda layer vào cấu hình. Với container image, bạn phải đóng gói runtime và toàn bộ code dependency ngay khi build image — nghĩa là mỗi lần script đổi lại phải build và push lại image cho từng function, đúng thứ công việc mà đề đang muốn loại bỏ. Phương án này vừa sai về mặt kỹ thuật, vừa đi ngược mục tiêu của đề.

B — Đóng gói script vào ephemeral storage (/tmp) rồi chia sẻ qua đó. Lambda cho phép cấu hình dung lượng ephemeral storage /tmp (từ 512 MB tới 10.240 MB) để phục vụ các workload nặng dữ liệu như ETL hay ML inference. Nhưng /tmp là vùng lưu trữ riêng của từng function, gắn với execution environment của chính function đó, không chia sẻ được sang function khác. Toàn bộ cơ chế mà phương án này mô tả không tồn tại.

D — Dùng Lambda Extensions để đưa script dùng chung vào các function. Extensions là cơ chế augment function: tích hợp với công cụ monitoring, observability, security và governance mà bạn ưa dùng — chúng chạy song song vòng đời function để làm những việc kiểu thu thập telemetry hay nạp cấu hình. Đây không phải cơ chế để đưa code nghiệp vụ dùng chung vào function gọi. Chọn D là nhầm mục đích của tính năng.

📌 Điểm cần nhớ

• Đề nói "code/thư viện dùng chung giữa nhiều Lambda function" → phản xạ đầu tiên là Lambda layers.
• Layer chỉ áp dụng cho function dạng .zip. Đề mà nhắc tới container image thì mọi phương án gắn layer đều loại — với container image, dependency phải nằm sẵn trong image.
• Ephemeral storage /tmp là của riêng từng function, dùng làm chỗ ghi tạm cho dữ liệu, không phải kênh chia sẻ code giữa các function.
• Extensions ≠ Layers. Extensions phục vụ monitoring/observability/security/governance; Layers phục vụ chia sẻ code và dependency. Hai tính năng hay bị đặt cạnh nhau trong đề để đánh lừa.
• Khi đề nhấn "reduce operational/maintenance work", hãy chọn phương án cho phép sửa một chỗ rồi lan ra nhiều nơi, chứ không phải phương án buộc build lại từng thành phần.

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

Đề mô tả một hệ thống chạy trên Amazon EC2 với một Amazon EBS volume loại io1 (Provisioned IOPS SSD), và hỏi làm sao giảm chi phí.

Ba chi tiết trong đề quyết định đáp án:

1. "EBS Elastic Volume (io1) accounts for 90% of the cost" — đây là cụm từ quan trọng nhất. Nó chỉ đích danh nơi tiền đang chảy: volume, không phải instance. Mọi phương án không đụng vào io1 đều chỉ gặm được phần 10% còn lại.
2. "both the Amazon EC2 instance and the Amazon EBS volume are under-utilized" — đang trả tiền cho hiệu năng không dùng tới. io1 tính tiền theo IOPS đã provision chứ không theo IOPS thực sự dùng, nên volume nhàn rỗi vẫn tốn đủ tiền.
3. "the Amazon EBS volume has occasional I/O bursts" — chữ occasional (thỉnh thoảng) là ràng buộc phân biệt phương án A với phương án D. Tải không cần hiệu năng cao liên tục, nó chỉ cần hiệu năng cao từng lúc. Đó chính xác là mô hình mà gp2 phục vụ bằng cơ chế credit/burst, còn io1 thì bán hiệu năng ổn định 24/7 — thứ ở đây không cần tới.

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

A — Convert the Amazon EC2 instance EBS volume to gp2

io1 sinh ra cho các tải I/O-intensive nhạy cảm với hiệu năng và tính nhất quán của storage, điển hình là database. Khác với gp2, io1 cho bạn khai một mức IOPS cố định lúc tạo volume và EBS cam kết giao đúng mức đó gần như toàn thời gian. Sự bảo đảm đó chính là thứ bạn trả tiền — và ở đây bạn đang trả cho một thứ không dùng.

gp2 (General Purpose SSD) rẻ hơn io1 cho cùng dung lượng, cho độ trễ mức mili-giây một chữ số, và quan trọng nhất: nó dùng mô hình bucket + credit để cho phép volume burst vượt lên trên mức baseline trong một khoảng thời gian. Baseline của gp2 tỉ lệ tuyến tính theo dung lượng volume.

Ghép hai vế lại: tải ở đây under-utilized phần lớn thời gian → nó tích credit; khi có occasional I/O burst → nó tiêu credit để đạt IOPS cao. Vừa đáp ứng được đỉnh tải, vừa cắt được phần lớn của 90% chi phí. Đây là lý do gp2 là lựa chọn đúng — vừa rẻ hơn io1, vừa vẫn cho burst khi cần.

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

D — Keep the Amazon EBS volume to io1 and reduce the IOPS

Đây là phương án gần đúng nhất, và nó đúng hướng ở chỗ: giảm provisioned IOPS thì hoá đơn io1 giảm thật. Chỗ nó hỏng nằm ở chữ occasional bursts. io1 giao đúng mức IOPS bạn khai, không hơn — không có credit, không có burst. Hạ mức provision xuống ngang mức sử dụng trung bình (vốn đang thấp) nghĩa là đến lúc có burst, volume bị chặn cứng ở trần mới và không có gì để mượn thêm. Bạn tiết kiệm được tiền bằng cách làm hỏng đúng lúc tải cần hiệu năng nhất. Muốn giữ được burst trên io1 thì phải provision theo mức đỉnh — và như vậy thì chẳng tiết kiệm được gì.

C — Change the Amazon EC2 instance type to something much smaller

Đúng là instance đang under-utilized nên về mặt kỹ thuật hạ cỡ được. Nhưng instance chỉ chiếm 10% tổng chi phí. Dù có giảm được nửa phần đó cũng chỉ cắt được 5% hoá đơn, trong khi 90% nằm ở io1 vẫn nguyên vẹn. Câu hỏi hỏi cách giảm chi phí, và phương án này bỏ qua đúng cái khối chi phí lớn nhất mà đề vừa chỉ ra.

B — Don't use an AWS CloudFormation template to create the database as the AWS CloudFormation service incurs greater service charges

Sai ngay ở tiền đề. AWS CloudFormation không tính phí cho bản thân dịch vụ — bạn chỉ trả tiền cho các tài nguyên mà template đó tạo ra, theo đúng mức giá của chính chúng. Tạo cùng một EC2 instance và cùng một io1 volume bằng CloudFormation hay bằng tay thì hoá đơn giống hệt nhau. Chi tiết "managed by AWS CloudFormation" trong đề là thông tin gây nhiễu, không phải nguyên nhân chi phí.

📌 Điểm cần nhớ

• Đọc phân bổ chi phí trước khi chọn cách tối ưu. Đề cho sẵn tỷ lệ 90/10 là để loại thẳng những phương án chỉ chạm vào phần 10% — dù phương án đó tự nó không sai về kỹ thuật.
• io1 bán sự ổn định, gp2 bán sự linh hoạt. Tải cao đều đặn và không được phép tụt → io1. Tải thấp phần lớn thời gian, thỉnh thoảng vọt lên → gp2 với cơ chế credit/burst, rẻ hơn hẳn.
• io1 tính tiền theo IOPS provision, không theo IOPS dùng thật. Vì vậy "under-utilized io1" luôn là dấu hiệu kinh điển của lãng phí trong đề thi AWS.
• CloudFormation tự nó miễn phí. Bất kỳ phương án nào đổ chi phí cho bản thân CloudFormation đều loại được ngay, không cần đọc tiếp.

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

Đề mô tả một công ty CRM có ứng dụng SaaS đẩy các bản cập nhật sang những ứng dụng khác — cả ứng dụng nội bộ (in-house) lẫn ứng dụng của bên thứ ba (third-party). Toàn bộ phần giao tiếp giữa các ứng dụng này đang được chuyển sang dùng dịch vụ AWS, và câu hỏi yêu cầu chọn cách decouple bất đồng bộ (asynchronously decouple).

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

• "asynchronously decouple" — loại thẳng mọi thứ hoạt động theo kiểu đồng bộ (request–response), tức là loại ELB.
• "SaaS application ... feeds updates to other in-house and third-party applications" — đây mới là ràng buộc phân biệt ba phương án còn lại. SNS, SQS và EventBridge đều decouple bất đồng bộ được, nên nếu chỉ đọc vế "asynchronously" thì câu này có ba đáp án đúng. Chính chi tiết nguồn sự kiện là SaaS và có bên thứ ba tham gia mới chọn ra một dịch vụ duy nhất.

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

Đáp án đúng: C — Use Amazon EventBridge to decouple the system architecture.

Amazon EventBridge là dịch vụ event bus dùng để xây dựng ứng dụng phản ứng theo sự kiện (event-driven), và điểm khác biệt của nó so với các phương án còn lại là nó tích hợp trực tiếp với các đối tác SaaS bên thứ ba — đúng thứ mà đề bài mô tả. Ngoài ra EventBridge còn nhận sự kiện từ rất nhiều dịch vụ AWS mà không cần lập trình viên tạo thêm tài nguyên nào trong tài khoản của mình.

EventBridge dùng cấu trúc sự kiện dạng JSON đã định nghĩa sẵn, cho phép tạo rule áp lên toàn bộ nội dung của sự kiện để lọc và định tuyến sự kiện tới target. Target của nó bao gồm cả AWS Lambda, Amazon SQS, Amazon SNS, Kinesis Data Streams và Firehose — nghĩa là EventBridge không thay thế các dịch vụ kia mà đứng ở tầng trên, nhận sự kiện từ SaaS rồi phân phát tới nhiều hệ thống tiêu thụ khác nhau. Đây chính là mô hình "SaaS đẩy cập nhật ra nhiều ứng dụng" trong đề.

Về tính chất, đây là giao tiếp bất đồng bộ: bên phát sự kiện không chờ bên nhận xử lý xong, nên kiến trúc được tách rời đúng nghĩa.

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

A. Elastic Load Balancing (ELB) — Sai rõ nhất. ELB phân phối request tới các target và trả về phản hồi ngay trong cùng một kết nối, tức là kiểu decouple đồng bộ. Nó có tách client khỏi từng instance cụ thể thật, nhưng đề yêu cầu asynchronously decouple, nên ELB không phù hợp với tình huống này.

B. Amazon SNS — Đây là phương án gần đúng nhất và dễ chọn nhầm nhất. SNS đúng là dịch vụ pub/sub bất đồng bộ, cũng dùng để xây dựng kiến trúc hướng sự kiện, cũng fan-out được một thông điệp tới nhiều bên nhận — nghe rất khớp với "SaaS đẩy cập nhật tới nhiều ứng dụng". Chỗ nó hỏng là ở ràng buộc còn lại: SNS không hỗ trợ tích hợp với các dịch vụ SaaS bên thứ ba như EventBridge. Với SNS, ứng dụng SaaS phải tự chủ động gọi vào để publish; không có sẵn đường tích hợp đối tác SaaS như EventBridge cung cấp.

D. Amazon SQS — Cũng là phương án hợp lý về mặt nguyên lý: SQS là dịch vụ hàng đợi thông điệp, hoạt động bất đồng bộ và là ví dụ kinh điển của decoupling trong đề thi AWS. Nhưng SQS không tích hợp trực tiếp với dịch vụ SaaS bên thứ ba. Thêm nữa, mô hình hàng đợi thiên về một nhóm consumer lấy việc ra xử lý, còn tình huống ở đây là một nguồn phát cập nhật ra nhiều hệ thống khác nhau — hợp với event bus hơn. Lưu ý SQS vẫn xuất hiện trong lời giải, nhưng ở vai trò target của EventBridge, chứ không phải là lớp tiếp nhận từ SaaS.

📌 Điểm cần nhớ

• Thấy cụm "third-party SaaS" trong đề AWS là tín hiệu rất mạnh cho EventBridge — đó là dịch vụ event-based tích hợp trực tiếp với các đối tác SaaS, còn SNS và SQS thì không.
• Phân biệt kiểu decoupling trước: ELB = đồng bộ, còn SQS / SNS / EventBridge = bất đồng bộ. Chỉ riêng chữ "asynchronously" đã đủ loại ELB.
• Khi nhiều phương án cùng thoả yêu cầu chung (ở đây là bất đồng bộ), hãy tìm ràng buộc thứ hai trong đề — đề thi hầu như luôn cài một chi tiết để chọn ra đúng một dịch vụ.
• EventBridge không loại trừ SQS/SNS: cả hai đều có thể là target của EventBridge cùng với Lambda, Kinesis Data Streams và Firehose. Ghi nhớ quan hệ tầng này giúp trả lời các câu hỏi kiến trúc kết hợp.

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

Đề mô tả một buổi tập huấn nội bộ, nhưng phần cần đọc kỹ nằm ở câu hỏi cuối: "Can you identify the INVALID lifecycle transitions from the options below? (Select two)".

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

• INVALID (viết hoa trong đề) — đề hỏi ngược. Cả năm phương án đều là những cặp chuyển đổi nghe rất hợp lý, và bốn trong số đó là chuyển đổi hoàn toàn bình thường mà ai cũng gặp khi cấu hình lifecycle rule. Ai đọc lướt thành "valid" sẽ chọn đúng ba phương án còn lại — sai trọn vẹn.
• lifecycle transitions — phạm vi là quy tắc lifecycle tự động của Amazon S3, không phải thao tác đổi storage class bằng tay. Đây là chi tiết dễ nhầm nhất: nhiều chuyển đổi mà lifecycle rule từ chối thì vẫn làm được bằng cách copy đè object hoặc dùng CopyObject với storage class mới. Câu hỏi này chỉ nói về cái đầu tiên.

Điều cần nhớ để giải: Amazon S3 lifecycle đi theo mô hình thác nước (waterfall) — object chảy từ tầng nóng, đắt xuống tầng lạnh, rẻ theo một chiều. Chảy ngược lên tầng nóng hơn, hoặc chảy ngang giữa hai tầng cùng bậc, đều không được lifecycle hỗ trợ.

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

B. S3 One Zone-IA ⇒ S3 Standard-IA — không hợp lệ. S3 One Zone-IA nằm dưới S3 Standard-IA trong thác nước: nó rẻ hơn vì chỉ lưu trong một Availability Zone thay vì nhiều AZ. Chuyển từ One Zone-IA lên Standard-IA là đi ngược dòng, và lifecycle không hỗ trợ. Cùng lý do đó, One Zone-IA cũng không chuyển sang Intelligent-Tiering được. Từ One Zone-IA, lifecycle chỉ đi tiếp xuống các tầng archive.

C. S3 Intelligent-Tiering ⇒ S3 Standard — không hợp lệ, và đây là trường hợp của một luật rộng hơn: không storage class nào chuyển ngược về S3 Standard bằng lifecycle. S3 Standard là điểm xuất phát cao nhất của thác nước, mọi thứ chỉ chảy ra khỏi nó chứ không chảy vào. Muốn đưa object về S3 Standard thì phải copy đè object đó, chứ không đặt được bằng lifecycle rule.

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

A. S3 Standard-IA ⇒ S3 One Zone-IA — đây là chuyển đổi hợp lệ, nên không phải đáp án cho câu hỏi "invalid". Đúng chiều thác nước: từ tầng infrequent-access nhiều AZ xuống tầng infrequent-access một AZ, rẻ hơn và độ bền khả dụng thấp hơn. Chú ý phương án này với phương án B là cùng một cặp storage class nhưng đảo chiều — cặp bẫy chính của câu hỏi. Chỉ chiều B là hỏng.

D. S3 Standard ⇒ S3 Intelligent-Tiering — hợp lệ. S3 Standard chuyển được sang mọi storage class khác, đây là quy tắc dễ nhớ nhất trong nhóm. Riêng cặp này còn là cách dùng phổ biến nhất của Intelligent-Tiering: đẩy dữ liệu mới vào Intelligent-Tiering để S3 tự dịch chuyển tầng theo mức truy cập thực tế.

E. S3 Standard-IA ⇒ S3 Intelligent-Tiering — hợp lệ, và đây là phương án gần đúng nhất, dễ chọn nhầm nhất. Lý do gây nhầm: chiều ngược lại — Intelligent-Tiering ⇒ Standard-IA — thì không hợp lệ. Hai storage class này chỉ đi được một chiều duy nhất là Standard-IA → Intelligent-Tiering. Ai nhớ mang máng "Intelligent-Tiering và Standard-IA không chuyển qua lại được" mà không nhớ chiều nào sẽ chọn nhầm E thay vì C.

📌 Điểm cần nhớ

• Lifecycle của S3 là thác nước một chiều: chảy từ tầng đắt/nóng xuống tầng rẻ/lạnh. Gặp bất kỳ phương án nào chuyển lên tầng nóng hơn, mặc định coi là không hợp lệ.
• Không gì chuyển ngược về S3 Standard bằng lifecycle. Đây là luật tuyệt đối, dùng loại phương án nhanh nhất mà không cần nhớ chi tiết từng cặp.
• Hai cặp bẫy đảo chiều cần thuộc lòng: Standard-IA → One Zone-IA hợp lệ nhưng chiều ngược thì không; Standard-IA → Intelligent-Tiering hợp lệ nhưng chiều ngược thì không. Đề thi rất hay đặt cả hai chiều vào cùng một danh sách phương án.
• S3 One Zone-IA gần như là ngõ cụt theo chiều ngang: từ đó chỉ đi tiếp xuống archive, không quay sang Standard-IA hay Intelligent-Tiering được.
• Phân biệt lifecycle transition với đổi storage class thủ công. Những cặp bị lifecycle từ chối vẫn thực hiện được bằng cách copy đè object — đọc đề thấy chữ "lifecycle" thì trả lời theo luật lifecycle.

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

Một công ty phân tích tài chính có dữ liệu tài chính cá nhân nằm trên Amazon S3, và điểm mấu chốt là dữ liệu đó ở định dạng Microsoft Excel workbook. Câu hỏi yêu cầu tìm một giải pháp serverless để interactively discover, clean and transform (khám phá, làm sạch và biến đổi một cách tương tác) dữ liệu thô này.

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

1. "Microsoft Excel workbook format" — đây là cụm lọc mạnh nhất. Phần lớn dịch vụ truy vấn dữ liệu trên S3 chỉ đọc được CSV, JSON, Parquet, ORC, Avro; Excel không nằm trong danh sách đó.
2. "discover, clean and transform" — đề không hỏi truy vấn hay phân tích bằng SQL, mà hỏi công cụ chuẩn bị dữ liệu (data preparation): làm sạch, chuẩn hoá, biến đổi dữ liệu thô.

Ai chỉ đọc lướt thấy "serverless + S3 + analyze" sẽ phản xạ chọn Athena. Nhưng hai ràng buộc trên loại Athena ngay.

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

D — AWS Glue DataBrew là công cụ chuẩn bị dữ liệu trực quan (visual data preparation), chạy serverless, sinh ra đúng để người dùng làm sạch và chuẩn hoá dữ liệu thô mà không phải viết code.

• Nó cho phép interactively discover, visualize, clean và transform dữ liệu thô — trùng khớp từng chữ với yêu cầu trong đề.
• DataBrew còn đưa ra gợi ý thông minh giúp phát hiện các vấn đề chất lượng dữ liệu vốn khó tìm và tốn thời gian sửa.
• Có sẵn hơn 250 phép biến đổi kiểu point-and-click: loại bỏ null, thay giá trị thiếu, sửa schema không nhất quán, tạo cột mới từ hàm, v.v.
• Quan trọng nhất: với tệp trên Amazon S3 (hoặc tải lên từ máy), DataBrew hỗ trợ định dạng Microsoft Excel, bên cạnh CSV, JSON, ORC và Parquet.

Đây là phương án duy nhất vừa serverless, vừa là công cụ chuẩn bị dữ liệu tương tác, vừa đọc được Excel.

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

C — Amazon Athena (phương án gần đúng nhất, và cũng là bẫy chính). Athena đúng là dịch vụ truy vấn tương tác, serverless, chạy thẳng trên dữ liệu trong S3 bằng SQL chuẩn — nghe rất khớp với "interactively" và "serverless". Chỗ hỏng nằm ở định dạng tệp: Athena hỗ trợ CSV, TSV, tệp phân tách tuỳ biến, JSON, các định dạng họ Hadoop (ORC, Apache Avro, Parquet), cùng log kiểu Logstash, AWS CloudTrail, Apache WebServer. Athena không truy vấn được tệp Microsoft Excel workbook. Ngoài ra Athena thiên về truy vấn/đọc, không phải công cụ làm sạch và biến đổi dữ liệu thô.

B — Amazon Redshift Spectrum. Spectrum cho phép truy vấn dữ liệu có cấu trúc và bán cấu trúc trực tiếp từ tệp trên S3 mà không cần nạp vào bảng Redshift — nghe cũng hợp lý về mặt "không cần di chuyển dữ liệu". Nhưng Redshift không đọc trực tiếp tệp Excel; nó chỉ làm việc với CSV, AVRO, JSON, PARQUET và ORC. Thêm nữa, Redshift Spectrum gắn với một cluster Redshift, nên cũng không phải lựa chọn thuần serverless như đề đòi hỏi, và nó không phải công cụ chuẩn bị dữ liệu tương tác.

A — AWS Glue Data Catalog. Data Catalog chứa các tham chiếu tới dữ liệu dùng làm nguồn và đích cho job ETL của AWS Glue. Nó là một chỉ mục (index) về vị trí, schema và runtime metrics của dữ liệu — thứ bạn cần để dựng data warehouse hay data lake. Nhưng bản thân Data Catalog không phải là công cụ phân tích hay biến đổi dữ liệu; nó chỉ mô tả dữ liệu nằm ở đâu và có cấu trúc gì, còn việc đọc và xử lý phải do dịch vụ khác đảm nhận. Chọn A là nhầm siêu dữ liệu với công cụ xử lý dữ liệu.

📌 Điểm cần nhớ

• Định dạng tệp là bộ lọc mạnh nhất trong loại câu này. Thấy "Microsoft Excel" trên S3 thì gần như chắc chắn loại Athena và Redshift Spectrum — cả hai đều chỉ đọc CSV/JSON/Parquet/ORC/Avro và họ hàng. DataBrew là dịch vụ đọc được Excel.
• Phân biệt "query" với "prepare". Đề dùng động từ clean, transform, prepare → nghĩ tới AWS Glue DataBrew (giao diện trực quan, không cần code). Đề dùng query bằng SQL, ad-hoc → nghĩ tới Athena.
• Glue Data Catalog là metadata, không phải engine xử lý. Nó lưu vị trí và schema để dịch vụ khác dùng; bản thân nó không phân tích hay biến đổi được dữ liệu.
• Redshift Spectrum gắn với cluster Redshift, nên khi đề nhấn mạnh "serverless" thì đây thường không phải đáp án, kể cả khi dữ liệu vẫn nằm nguyên trên S3.

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

Đề mô tả: đội phát triển phát hiện một lượng lớn bất thường các lời gọi AWS API bất hợp lệ (illegal API queries) trong tuần — chỉ thấy được khi gộp log lại để làm báo cáo tuần. Không có thiệt hại, nhưng ban quản lý muốn một giải pháp tự động cảnh báo gần thời gian thực (near-real-time) nếu chuyện đó lặp lại.

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

• "illegal API queries" — tức là các lời gọi API bị lỗi/bị từ chối, nghĩa là ta phải bắt theo mã lỗi (error code) trong log gọi API, chứ không phải theo hạn mức dịch vụ.
• "automated solution that can trigger near-real-time warnings" — phải là cảnh báo tự động, gần thời gian thực, không phải báo cáo hay dashboard do người mở ra xem.

Nguồn dữ liệu duy nhất ghi lại chi tiết lời gọi API trong tài khoản AWS là AWS CloudTrail. Vậy câu hỏi thực chất là: đưa CloudTrail vào đâu để có cảnh báo tự động theo mã lỗi.

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

Đáp án đúng theo tệp là B: tạo CloudWatch metric filter trên log CloudTrail đã được đẩy sang CloudWatch Logs, lọc theo các error code cần theo dõi, rồi tạo CloudWatch Alarm dựa trên tần suất của metric đó để gửi thông báo qua Amazon SNS.

Chuỗi này khớp từng chữ với yêu cầu của đề:

• CloudTrail tích hợp sẵn với CloudWatch Logs, nên dữ liệu lời gọi API chảy vào liên tục thay vì chỉ nằm chờ trong S3 tới cuối tuần.
• Metric filter biến dữ liệu log dạng chữ thành metric số — đúng cơ chế để đếm số lần xuất hiện của các mã lỗi ủy quyền/gọi sai.
• Alarm đặt trên metric đó tự kích hoạt khi tần suất vượt ngưỡng, và SNS đưa cảnh báo tới đúng đội — toàn bộ chạy tự động, không cần dựng hạ tầng riêng.

Đây chính là mẫu chuẩn mà tài liệu AWS mô tả cho việc giám sát lỗi ủy quyền (authorization failures) từ CloudTrail.

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

A — Trusted Advisor publish metric sang CloudWatch, alarm theo nhóm Service Limits. Đây là phương án gần đúng nhất về mặt kiến trúc: Trusted Advisor thật sự có publish kết quả kiểm tra sang CloudWatch và ta thật sự đặt được alarm trên đó. Nhưng nó hỏng ở thứ được đo: nhóm Service Limits chỉ báo khi ta chạm hoặc vượt hạn mức dịch vụ. Đề không nói tới hạn mức — nó nói tới các lời gọi bất hợp lệ. Số lời gọi lỗi có thể tăng vọt bất thường mà chẳng bao giờ chạm ngưỡng quota nào, và alarm này sẽ im lặng suốt. Sai tín hiệu, dù đúng công cụ.

C — CloudTrail stream sang Kinesis, dùng stream-level metric để trigger Lambda. Sai ngay ở bước đầu: CloudTrail không stream trực tiếp sang Kinesis. Đích đến của một trail là S3 bucket và CloudWatch Logs. Ngoài ra, kể cả nếu đường đi tồn tại thì stream-level metric của Kinesis đo sức khỏe của chính stream (lượng dữ liệu vào/ra, throttling), chứ không biết gì về nội dung sự kiện — nó không phân biệt được lời gọi thành công với lời gọi lỗi. Hai tầng sai chồng lên nhau.

D — Athena query log CloudTrail trong S3, QuickSight dựng dashboard. Về kỹ thuật thì chạy được: CloudTrail ghi log xuống S3 và Athena query trực tiếp trên đó là cách phân tích rất phổ biến. Nhưng nó hỏng đúng ở yêu cầu cốt lõi: đây là mô hình phân tích và trực quan hóa theo yêu cầu, ai đó phải chủ động chạy query hoặc mở dashboard ra nhìn. Nó không tự cảnh báo và không gần thời gian thực — nghĩa là lặp lại đúng cái vấn đề đề bài đang muốn thoát ra: phát hiện muộn cả tuần khi làm báo cáo.

📌 Điểm cần nhớ

• Chi tiết lời gọi API trong tài khoản AWS = CloudTrail. Thấy đề nói "API activity", "who did what", "unauthorized calls" thì CloudTrail gần như luôn là nguồn dữ liệu.
• Chuỗi kinh điển cho cảnh báo theo nội dung log: CloudTrail → CloudWatch Logs → metric filter (biến chữ thành số) → alarm → SNS. Nhớ nguyên chuỗi này vì nó xuất hiện lại ở rất nhiều câu giám sát/bảo mật.
• Phân biệt "alerting" với "reporting": Athena + QuickSight là phân tích và trực quan hóa; đề nào có chữ near-real-time, automated warning, notify the team thì loại ngay nhóm dashboard/báo cáo.
• Đích đến của một CloudTrail trail chỉ có S3 và CloudWatch Logs — mọi phương án vẽ đường thẳng từ CloudTrail sang một dịch vụ khác nên bị nghi ngờ trước tiên.
• Trusted Advisor + CloudWatch alarm là để canh service quota, không phải để bắt hành vi bất thường theo mã lỗi. Đúng công cụ nhưng sai chỉ số vẫn là đáp án sai.

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

Một công ty dịch vụ tài chính cần chia sẻ hàng trăm nghìn giao dịch với nhiều ứng dụng nội bộ, đồng thời loại bỏ dữ liệu nhạy cảm trước khi lưu bản đã làm sạch vào một document database để tra cứu độ trễ thấp.

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

• "near-real-time" — loại thẳng mọi phương án xử lý theo lô (batch).
• "share ... with multiple internal applications" — cần một stream cho phép nhiều consumer độc lập cùng đọc chung một dòng dữ liệu.
• "remove sensitive details before storing" — việc làm sạch phải xảy ra trên đường đi, chứ không phải ghi thô xuống trước rồi mới sửa lại.

Cụm phân biệt mạnh nhất là "multiple internal applications": đây chính là chỗ tách Kinesis Data Streams khỏi Kinesis Data Firehose.

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

Đáp án đúng là A: đẩy giao dịch vào Amazon Kinesis Data Streams, dùng AWS Lambda như một consumer để bóc dữ liệu nhạy cảm rồi ghi bản đã làm sạch vào Amazon DynamoDB; các ứng dụng nội bộ đăng ký làm các consumer khác để đọc giao dịch thô ngay trên stream.

Kinesis Data Streams là dịch vụ streaming cho phép xây các ứng dụng xử lý dữ liệu theo thời gian gần thực, và AWS lo phần hạ tầng, lưu trữ, mạng cũng như cấu hình để đáp ứng mức thông lượng của luồng dữ liệu — không phải tự cấp phát hay bảo trì máy móc.

Điểm mấu chốt: một data stream phục vụ được nhiều consumer song song, mỗi bên đọc cùng dữ liệu theo tiến độ riêng của mình. Nhờ vậy một kiến trúc duy nhất đáp ứng cả hai yêu cầu của đề — Lambda là một consumer lo việc làm sạch và ghi vào DynamoDB, còn các ứng dụng nội bộ là những consumer khác nhận giao dịch thô. DynamoDB đúng là "document database" mà đề yêu cầu, phục vụ tra cứu độ trễ thấp.

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

B — Kinesis Data Firehose + Lambda + DynamoDB. Đây là phương án gần đúng nhất và cũng là bẫy chính. Firehose có tích hợp Lambda để biến đổi dữ liệu trên đường đi, nên vế "làm sạch" nghe rất hợp lý. Chỗ hỏng nằm ở vế sau: Firehose là dịch vụ delivery kiểu ETL — nó nhận, biến đổi và giao dữ liệu tới một đích lưu trữ, chứ không phải một stream để các ứng dụng đăng ký đọc. Bạn không thiết lập được nhiều consumer đọc từ một delivery stream của Firehose như với Data Streams. Yêu cầu "chia sẻ với nhiều ứng dụng nội bộ" vì thế không đáp ứng được.

C — Ghi thô vào DynamoDB, đặt "rule" tự xoá dữ liệu nhạy cảm, chia sẻ qua DynamoDB Streams. Sai ở hai tầng. Thứ nhất, DynamoDB không có loại rule nào tự cập nhật item mỗi khi có item mới được ghi; muốn làm vậy phải dùng trigger để gọi ra một dịch vụ bên ngoài như Lambda, rồi Lambda mới làm sạch và cập nhật lại. Thứ hai, ngay cả khi dựng được, luồng này vẫn kém: cùng một item bị ghi rồi lại ghi đè lần nữa chỉ để làm sạch — thừa thao tác, và trái với yêu cầu "làm sạch trước khi lưu" của đề. Dữ liệu nhạy cảm đã kịp nằm trong bảng một khoảng thời gian.

D — Gom lô vào flat file trên S3, S3 event gọi Lambda làm sạch, ghi DynamoDB, chia sẻ qua DynamoDB Streams. Vướng ngay từ chữ đầu tiên: "Batch process". Đề yêu cầu giải pháp near-real-time cho cả việc làm sạch, xử lý lẫn lưu trữ giao dịch; gom giao dịch thành tệp rồi mới xử lý đưa vào độ trễ của cả chu kỳ gom lô. Các phần còn lại của phương án có thể chạy được về mặt kỹ thuật, nhưng ràng buộc thời gian trong đề đã đủ để loại.

📌 Điểm cần nhớ

• "Multiple consumers" trên một luồng → Kinesis Data Streams. Firehose là đường giao dữ liệu tới đích lưu trữ, không phải nơi nhiều ứng dụng cùng đăng ký đọc.
• "Near-real-time" là tín hiệu loại batch. Thấy "batch process", gom thành flat file, hay xử lý theo chu kỳ thì gần như chắc chắn sai với đề dạng này.
• "Làm sạch trước khi lưu" nghĩa là biến đổi trên đường đi, không phải ghi thô xuống rồi cập nhật lại — mẫu ghi-rồi-sửa vừa thừa vừa để lộ dữ liệu nhạy cảm trong khoảng giữa.
• DynamoDB không tự biến đổi dữ liệu. Mọi logic "khi có item mới thì làm gì đó" đều phải qua trigger gọi Lambda; phương án nào nói DynamoDB tự làm là mô tả một tính năng không tồn tại.