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 IoT muốn hai việc nối tiếp nhau: (1) một hệ thống streaming làm real-time analytics trên dữ liệu IoT được ingest vào, và (2) sau khi phân tích xong thì gửi notification ngược về mobile application của chủ thiết bị.

Cụm từ quyết định nằm ở vế thứ hai: "send these notifications to the mobile applications". Chính câu hỏi cuối cũng nói rõ nó đang hỏi công nghệ nào dùng để gửi notification, chứ không hỏi cách ingest. Cả bốn phương án đều là cặp hai dịch vụ, và ba trong bốn phương án dùng chung một vế đầu là Kinesis Data Streams — nên điểm phân biệt thật sự là vế sau: SES, SQS hay SNS.

Ràng buộc phụ thứ hai: đích đến là mobile app, không phải email, không phải một worker tự đi lấy việc. Notification kiểu đẩy tới nhiều người nhận cùng lúc là mô hình push, pub/sub, chứ không phải mô hình pull từ queue.

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

Đáp án đúng theo tệp là D — Amazon Kinesis Data Streams với Amazon SNS, và nó khớp đúng hai vế của đề:

• Kinesis Data Streams lo phần ingest và phân tích thời gian thực. Đây là dịch vụ được thiết kế để thu thập, xử lý và phân tích dữ liệu streaming ngay khi dữ liệu tới — bao gồm cả IoT telemetry, application log, clickstream — thay vì phải chờ gom đủ dữ liệu rồi mới xử lý. Đúng với yêu cầu "real-time analytics on the ingested IoT data".
• SNS lo phần gửi notification. SNS là dịch vụ nhắn tin pub/sub được quản lý hoàn toàn, cung cấp topic theo mô hình push, many-to-many. Nó là dịch vụ notification đúng nghĩa và hỗ trợ đẩy thông báo tới ứng dụng di động — chính là việc mà đề yêu cầu.

Điểm mấu chốt: Kinesis Data Streams rất tốt cho việc stream sự kiện từ thiết bị IoT, nhưng bản thân nó không có chức năng gửi notification. Ghép Kinesis (vế phân tích) với SNS (vế thông báo) là lời giải đủ cả hai vế của bài toán.

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

A — Kinesis Data Streams với Amazon SES. Vế đầu đúng, vế sau sai. SES là dịch vụ gửi email trên cloud, dành cho email marketing, email giao dịch, email thông báo qua hòm thư. Đề yêu cầu gửi notification tới mobile application, mà SES là email service chứ không phải notification service. Đây là phương án dễ chọn nhầm nhất vì "notification email" nghe cũng giống thông báo — nhưng kênh đến đích không khớp với thứ đề mô tả.

B — SQS với SNS. Vế sau đúng (SNS đúng là dịch vụ notification), nhưng vế đầu hỏng. SQS là message queue được quản lý, dùng để decouple và scale microservice, hệ phân tán, ứng dụng serverless. Queue không phải là công cụ dành cho real-time streaming dữ liệu; nó gửi–lưu–nhận message giữa các thành phần chứ không phục vụ mô hình phân tích luồng dữ liệu liên tục. Chọn B là bỏ mất yêu cầu "streaming system performs real-time analytics" ở đầu đề.

C — Kinesis Data Streams với SQS. Vế đầu đúng, vế sau sai — và sai đúng chỗ mà câu hỏi đang nhắm. Kinesis xử lý streaming rất tốt, nhưng SQS chỉ là dịch vụ queue giúp tách rời kiến trúc hệ thống; nó không gửi được notification. Một consumer nào đó phải chủ động đi lấy message ra khỏi queue, tức là mô hình pull, hoàn toàn ngược với việc đẩy thông báo về máy của người dùng cuối.

📌 Điểm cần nhớ

• Câu hỏi nhiều phương án ghép đôi dịch vụ: xác định vế nào là vế khác nhau giữa các phương án rồi tập trung vào đó. Ở đây ba phương án dùng chung Kinesis, nên bài toán thu về "SES hay SQS hay SNS".
• Phân vai ba dịch vụ nhắn tin: SNS = pub/sub, push, notification tới nhiều người nhận (kể cả mobile app); SQS = queue, pull, decouple giữa các thành phần; SES = email.
• Kinesis Data Streams làm ingest và phân tích real-time, không làm notification. Thấy đề vừa có "streaming/real-time analytics" vừa có "notify", hãy nghĩ tới việc ghép hai dịch vụ, mỗi cái lo một vế.
• Đọc kỹ đích đến của thông báo. "Mobile application" khác "email inbox" — nó loại thẳng SES dù SES cũng gửi được thứ gọi là notification.

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

Đề mô tả một ứng dụng dùng Kinesis Data Streams để xử lý dữ liệu thời gian thực, và cần theo dõi (monitoring) luồng dữ liệu vào/ra để đảm bảo hiệu năng cho cả hệ thống lẫn các ứng dụng phía sau.

Cụm từ quyết định đáp án nằm ở câu: "For a read-intensive requirement, the age for the last record in the data stream for all the GetRecords requests need to be tracked". Có ba ràng buộc chồng lên nhau:

• GetRecords → phía đọc (consumer), không phải phía ghi (PutRecords). Ràng buộc này loại thẳng mọi metric mang tiền tố PutRecords.
• "age" (tuổi) of the last record → đại lượng cần đo là độ trễ tuổi bản ghi, tức bản ghi mà consumer vừa đọc được đã nằm trong stream bao lâu rồi. Đây không phải thời gian thực thi một lời gọi API, cũng không phải số lần bị chặn.
• "stream-level metric" → metric ở cấp stream, đúng nhóm metric mà Kinesis Data Streams đẩy sang CloudWatch.

Chính chữ age là mấu chốt phân biệt với GetRecords.Latency — hai thứ này rất dễ lẫn vì cùng đo bằng đơn vị thời gian và cùng thuộc phía đọc.

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

C — GetRecords.IteratorAgeMilliseconds.

Metric này đo tuổi tính bằng mili giây của bản ghi cuối cùng trong stream, cho tất cả các request GetRecords — đúng nguyên văn yêu cầu của đề. Ý nghĩa của nó: khoảng cách giữa thời điểm bản ghi được đưa vào stream và thời điểm consumer thực sự đọc tới nó.

• Giá trị bằng 0 nghĩa là consumer đang đọc kịp, dữ liệu trong stream là current — không có tồn đọng.
• Giá trị càng thấp càng tốt; giá trị tăng dần nghĩa là consumer đang tụt lại phía sau tốc độ ghi, dữ liệu bị xử lý chậm.
• Cách xử lý khi metric này cao: tăng số consumer để dữ liệu được xử lý nhanh hơn, hoặc tối ưu lại mã ứng dụng consumer để giảm độ trễ xử lý bản ghi.

Vì đề nói rõ là yêu cầu read-intensive và cần biết bản ghi cuối cùng đã "già" bao nhiêu, đây là metric duy nhất trong danh sách diễn tả đúng khái niệm đó.

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

A — PutRecords.Latency: đo thời gian thực hiện mỗi thao tác PutRecords trên stream trong một khoảng thời gian. Sai ở hai tầng: nó thuộc phía ghi (producer) chứ không phải GetRecords, và nó đo thời gian thực hiện lời gọi chứ không đo tuổi bản ghi. Metric này dùng khi cần biết producer đẩy dữ liệu vào có chậm không — giá trị cao thì gom bản ghi lại thành lô/tệp lớn hơn trước khi đưa vào stream.

B — GetRecords.Latency: đây là phương án gần đúng nhất và cũng là bẫy chính. Nó đúng ở chỗ thuộc phía đọc, nhưng hỏng ở chỗ nó đo thời gian mà mỗi thao tác GetRecords mất để hoàn tất, chứ không đo bản ghi cuối cùng đã nằm trong stream bao lâu. Một lời gọi GetRecords có thể chạy rất nhanh (latency thấp) trong khi consumer vẫn tụt lại rất xa so với producer (iterator age rất cao) — hai chỉ số này độc lập với nhau. GetRecords.Latency dùng để xác nhận tài nguyên vật lý hoặc logic xử lý bản ghi có đủ đáp ứng throughput không, và để kiểm tra thiết lập IDLE_TIME_BETWEEN_READS_IN_MILLIS có theo kịp tốc độ stream không.

D — ReadProvisionedThroughputExceeded: đếm số lời gọi GetRecords bị throttle trong một khoảng thời gian, tức số lần vượt giới hạn của service hoặc của shard. Nó đúng phía đọc, nhưng đo số lần bị chặn, không đo tuổi bản ghi. Giá trị 0 nghĩa là consumer không vượt quota; giá trị khác 0 nghĩa là đã chạm trần throughput và cần thêm shard. Đây là chỉ báo về hạn mức, không phải về độ trễ dữ liệu.

📌 Điểm cần nhớ

• Tiền tố của tên metric Kinesis cho biết ngay phía nào: PutRecords.* = producer/ghi, GetRecords.* = consumer/đọc. Đề nhắc GetRecords thì loại sạch nhóm Put trước khi so sánh tiếp.
• Phân biệt ba khái niệm dễ lẫn ở phía đọc: IteratorAge = dữ liệu cũ bao nhiêu (consumer có bị tụt lại không); Latency = một lời gọi API chạy lâu bao nhiêu; ProvisionedThroughputExceeded = bị throttle bao nhiêu lần.
• Từ khoá "age of the last record" / "consumer lag" / "xử lý có theo kịp không" trong đề gần như luôn dẫn tới GetRecords.IteratorAgeMilliseconds.
• IteratorAgeMilliseconds tăng là dấu hiệu consumer chậm hơn producer — hướng xử lý là tăng số consumer hoặc tối ưu mã xử lý, khác hẳn với hướng xử lý khi bị throttle (thêm shard).

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

Đề mô tả một công ty rút khoảng 2 TB dữ liệu mỗi ngày từ nhiều nguồn khác nhau — MySQL, MSSQL Server, Oracle, Vertica, Teradata Vantage — rồi hỏi giải pháp nào vừa tự động phát hiện schema, vừa làm ETL đổ vào Amazon S3.

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

• "undefined or frequently changing data schemas" + "automatically detect the schema": yêu cầu ở đây không phải là "đọc được dữ liệu", mà là tự dò và theo dõi schema thay đổi liên tục. Nghĩa là cần một thành phần crawler có sẵn, ghi metadata vào catalog, chứ không phải code tự viết để so sánh cột.
• "while minimizing operational overhead": đây là cụm phân biệt kinh điển. Nhiều phương án làm được việc, nhưng cụm này loại bỏ mọi phương án bắt bạn tự dựng cluster, tự viết logic dò schema, hoặc tự vận hành hạ tầng.

Thêm một ràng buộc phụ: 2 TB/ngày — khối lượng này loại thẳng những runtime có giới hạn thời gian chạy ngắn.

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

Phương án A — dùng AWS Glue để phát hiện schema và làm ETL bằng Apache Spark.

AWS Glue là dịch vụ ETL serverless, và nó khớp đúng hai vế của đề:

• Phát hiện schema: AWS Glue crawler kết nối tới nguồn dữ liệu, tự suy ra schema và ghi metadata vào AWS Glue Data Catalog. Khi nguồn đổi tên cột hay thêm cột mới, crawler chạy lại sẽ cập nhật phiên bản schema trong Data Catalog — đó chính là cơ chế "tự phát hiện thay đổi đang diễn ra" mà đề đòi hỏi. Bạn không phải viết code so sánh cột nào cả.
• ETL: Glue job chạy trên nền Apache Spark (viết bằng PySpark hoặc Scala), có sẵn connector cho các nguồn JDBC như MySQL, MSSQL Server, Oracle, và đủ sức xử lý khối lượng lớn. Kết quả ghi thẳng xuống S3.

Quan trọng nhất với vế minimizing operational overhead: Glue là serverless — không có cluster nào để provision, patch, scale hay tắt bật. AWS lo phần hạ tầng, bạn chỉ khai báo crawler và job.

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

B — Redshift Spectrum phát hiện schema + stored procedure trong Amazon Redshift làm ETL. Sai ở cả hai vế. Redshift Spectrum dùng để truy vấn dữ liệu đã nằm sẵn trên S3 từ Redshift — nó tiêu thụ metadata (thường là từ chính Glue Data Catalog) chứ không phải công cụ đi dò schema của các cơ sở dữ liệu nguồn như Oracle hay Teradata. Vế thứ hai còn hỏng nặng hơn: stored procedure trong Redshift được viết bằng PL/pgSQL, chạy các câu SQL và logic điều kiện bên trong database. Nó không phải cơ chế để rút dữ liệu từ hàng loạt nguồn ngoài rồi nạp vào S3. Phương án này chỉ là distractor.

C — Amazon EMR phát hiện schema + ETL bằng Apache Spark. Đây là phương án gần đúng nhất, và cần chỉ rõ nó hỏng ở đâu. EMR thực sự chạy được Spark và thực sự xử lý nổi 2 TB/ngày — về mặt kỹ thuật thuần tuý thì làm được. Nhưng nó hỏng ở đúng cụm từ quyết định:

• EMR không có sẵn thành phần tương đương crawler. Muốn tự phát hiện schema và bắt các thay đổi đang diễn ra, bạn phải tự viết một lượng code Spark đáng kể — đọc metadata nguồn, lưu lại, so sánh giữa các lần chạy, xử lý trường hợp đổi tên/thêm cột.
• EMR là mô hình cluster: phải chọn loại instance, cấu hình, theo dõi, nâng cấp phiên bản. Đó là operational overhead thuần tuý mà đề bảo phải tối thiểu hoá.

So với A: cùng dùng Spark, nhưng A cho bạn crawler + Data Catalog sẵn và không có cluster nào phải nuôi. Khi hai phương án cùng làm được việc, cụm "minimizing operational overhead" luôn nghiêng về bên serverless.

D — PySpark phát hiện schema + ETL bằng AWS Lambda. Hỏng ở phần runtime. AWS Lambda có giới hạn thời gian chạy tối đa cho mỗi lần gọi (hiện là 15 phút), cùng giới hạn bộ nhớ và dung lượng lưu trữ tạm. Chạy một pipeline ETL trên 2 TB dữ liệu mỗi ngày trong khuôn khổ đó là không khả thi — Lambda vốn được thiết kế cho tác vụ ngắn, hướng sự kiện, không phải cho big data ETL. Việc phương án này nhắc tới PySpark càng làm nó mâu thuẫn: Spark là engine phân tán cần cluster, không phải thứ gắn tự nhiên vào môi trường thực thi của Lambda.

📌 Điểm cần nhớ

• "Detect schema" + "frequently changing schema" → nghĩ ngay tới AWS Glue crawler + Glue Data Catalog. Đây là cặp từ khoá gần như luôn trỏ về Glue trong đề thi Data Engineer.
• "Minimize operational overhead" là cụm phân biệt serverless với cluster. Khi Glue và EMR cùng làm được việc, cụm này chọn Glue. Ngược lại, nếu đề nhấn vào việc cần tuỳ biến sâu framework, phiên bản Spark cụ thể, hay chạy nhiều engine Hadoop khác, cán cân mới nghiêng về EMR.
• Khối lượng dữ liệu lớn (hàng TB) loại AWS Lambda khỏi vai trò engine ETL — Lambda có giới hạn thời gian chạy cho mỗi lần gọi, phù hợp tác vụ ngắn hướng sự kiện chứ không phải xử lý dữ liệu quy mô lớn.
• Phân biệt vai trò rõ ràng: Redshift Spectrum là để đọc dữ liệu trên S3, không phải để nạp dữ liệu lên S3. Stored procedure trong Redshift là PL/pgSQL chạy trong database, không phải công cụ trích xuất từ nguồn ngoài.

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

Một công ty thương mại điện tử muốn cải thiện hệ thống gợi ý sản phẩm bằng cách đưa dữ liệu của bên thứ ba (third-party datasets) vào nền tảng phân tích sẵn có. Cả bốn phương án đều nói "truy cập và tích hợp third-party datasets", nên tên dịch vụ không phải thứ phân biệt — thứ phân biệt nằm ở hai cụm từ ràng buộc:

• "minimize the effort and time involved in this integration" — giảm công sức và thời gian tích hợp;
• "with the least operational overhead" — ít việc vận hành nhất.

Cụm quyết định là least operational overhead. Đề không hỏi "cách nào lấy được dữ liệu" (nhiều cách lấy được), mà hỏi cách nào dữ liệu tự chảy thẳng vào các dịch vụ phân tích của AWS mà không phải tự dựng đường ống. Với ràng buộc này, phương án phải là một dịch vụ chuyên đăng ký và nhận dữ liệu (data subscription/entitlement), chứ không phải một nơi tình cờ có chứa dữ liệu.

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

A. AWS Data Exchange là dịch vụ sinh ra đúng cho tình huống này: tìm, đăng ký và quản lý quyền dùng dữ liệu (data entitlements) từ các tổ chức khác.

• Ở vai người nhận dữ liệu, mọi data grant và mọi subscription dữ liệu đều được theo dõi và quản lý ở một chỗ duy nhất.
• Khi đã có quyền truy cập một dataset, có thể dùng ngay các dịch vụ analytics và machine learning của AWS hoặc của đối tác để khai thác — không phải viết thêm lớp tích hợp riêng.
• Có thể khám phá và đăng ký thêm dataset mới của bên thứ ba ngay từ danh mục AWS Marketplace.
• Ở vai người gửi dữ liệu, AWS Data Exchange loại bỏ hẳn việc phải xây và duy trì hạ tầng phân phối dữ liệu cùng cơ chế cấp quyền.

Nói gọn: A là phương án duy nhất mà phần "tích hợp" đã được dịch vụ lo sẵn — đúng nghĩa least operational overhead.

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

B. AWS CodeCommit — sai rõ nhất. Đây là dịch vụ quản lý mã nguồn (source control) được quản trị sẵn, bảo mật và co giãn tốt, dùng cho đội phát triển cộng tác trên code. Nó không hề được thiết kế để cung cấp quyền truy cập dữ liệu của bên thứ ba. Không có danh mục dataset, không có cơ chế subscription, không có đường nối sang các dịch vụ analytics.

C. AWS Marketplace — đây là phương án gần đúng nhất và dễ mắc bẫy nhất. Marketplace đúng là nơi tìm phần mềm, dữ liệu và dịch vụ chạy trên AWS, quản lý tập trung, đơn giản hoá việc mua và cấp phép. Nghĩa là bạn có thể tiếp cận dataset của bên thứ ba qua đây. Chỗ nó hỏng là ở vế sau của đề: sau khi có dữ liệu, vẫn phải bỏ công tự xây phần tích hợp để đưa dữ liệu vào dùng được trong các dịch vụ AWS. Marketplace giải quyết khâu tìm và mua; Data Exchange giải quyết cả khâu nhận và dùng. Với tiêu chí "ít vận hành nhất", C thua A.

D. AWS DataSync — cũng gần đúng theo kiểu khác. DataSync là dịch vụ di chuyển và khám phá dữ liệu trực tuyến, giúp đơn giản hoá và tăng tốc việc migrate dữ liệu lên AWS, cũng như chuyển dữ liệu qua lại giữa on-premises, edge, cloud provider khác và các dịch vụ lưu trữ của AWS. Nó là công cụ vận chuyển byte, không phải nơi cung cấp dữ liệu. Kể cả khi bạn dùng nó để kéo được dataset của bên thứ ba về, vẫn cần công sức tích hợp riêng để tiêu thụ dữ liệu đó trong các dịch vụ AWS — lại vi phạm ràng buộc của đề.

📌 Điểm cần nhớ

• Thấy cụm "third-party datasets" + "least operational overhead" trong đề AWS, nghĩ ngay tới AWS Data Exchange. Đây gần như là chữ ký nhận dạng của dịch vụ này.
• Phân biệt Data Exchange với Marketplace: Marketplace là danh mục chung cho phần mềm/dữ liệu/dịch vụ (tìm và mua), còn Data Exchange chuyên về quyền dùng dữ liệu và đưa dữ liệu vào dùng được ngay với analytics/ML của AWS. Data Exchange còn dùng chính danh mục Marketplace để khám phá dataset — hai thứ liên quan nhau nhưng không thay thế nhau.
• DataSync là công cụ di chuyển dữ liệu, không phải nguồn dữ liệu. Nó trả lời câu hỏi "chuyển dữ liệu từ A sang B thế nào", không trả lời "lấy dữ liệu bên ngoài ở đâu".
• CodeCommit là source control, chỉ dành cho mã nguồn — gặp nó trong một câu về dữ liệu phân tích thì gần như chắc chắn là phương án nhiễu.
• Khi nhiều phương án đều "làm được", hãy chấm điểm theo lượng công việc phải tự xây thêm. Phương án nào bắt viết custom integration là phương án thua trong mọi câu có chữ least operational overhead.

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

Một công ty truyền thông muốn thôi tự vận hành hạ tầng IT của mình, và cần archive khoảng 5 petabyte dữ liệu đang nằm ở data center on-premises sang chỗ lưu trữ dài hạn, bền bỉ. Câu hỏi: cách di chuyển khối dữ liệu đó tối ưu chi phí nhất (MOST cost-optimal).

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

• "5 petabytes" — khối lượng khổng lồ, chuyển một lần. Đây là ngưỡng mà truyền qua đường mạng trở nên phi lý cả về thời gian lẫn tiền bạc; các phương án dựa trên network link bị loại ngay ở đây.
• "archive ... for durable long-term storage" — đích đến là lớp lưu trữ archive, tức Amazon S3 Glacier. Nhưng đích đến cuối cùng không có nghĩa là dữ liệu đổ thẳng vào đó được — chi tiết này chính là thứ tách hai phương án Snowball Edge gần như y hệt nhau (B và D).

Nói cách khác đề bài kiểm hai thứ cùng lúc: chọn đúng phương tiện vận chuyển, rồi chọn đúng đường đi của dữ liệu sau khi thiết bị về tới AWS.

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

Đáp án đúng là B: chuyển dữ liệu on-premises vào nhiều thiết bị AWS Snowball Edge Storage Optimized, gửi về AWS, copy dữ liệu vào Amazon S3, rồi tạo lifecycle policy để chuyển dữ liệu sang Amazon S3 Glacier.

AWS Snowball Edge Storage Optimized là lựa chọn dành đúng cho việc chuyển an toàn và nhanh chóng từ hàng chục terabyte tới hàng petabyte dữ liệu lên AWS. Mỗi thiết bị mang theo dung lượng HDD lớn, kèm vCPU, SSD và kết nối mạng tốc độ cao để phục vụ cả việc nạp dữ liệu quy mô lớn lẫn tiền xử lý tại chỗ. Với 5 PB thì dùng nhiều thiết bị song song — đúng như phương án mô tả.

Mấu chốt thứ hai: không thể copy dữ liệu từ thiết bị Snowball Edge thẳng vào Amazon S3 Glacier. Dữ liệu từ thiết bị luôn hạ cánh vào một S3 bucket trước. Muốn nó nằm ở lớp archive thì phải gắn lifecycle policy trên bucket đó để transition sang S3 Glacier. Phương án B là phương án duy nhất mô tả đúng chuỗi này, nên nó vừa khả thi về mặt kỹ thuật, vừa tối ưu chi phí cho một lần chuyển dữ liệu duy nhất.

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

A — AWS Direct Connect rồi transfer vào S3 Glacier. AWS Direct Connect cho phép thiết lập một kết nối mạng chuyên dụng giữa mạng của bạn và một Direct Connect location, và có thể chia thành nhiều virtual interface bằng VLAN chuẩn 802.1q. Vấn đề: Direct Connect đòi hỏi đầu tư tiền bạc đáng kể và mất hơn một tháng để thiết lập. Dựng cả một kết nối chuyên dụng chỉ để phục vụ một lần chuyển dữ liệu là không hợp lý về chi phí. Đây là phương án "nghe có vẻ mạnh" nhưng sai ở chỗ nó giải bài toán kết nối lâu dài, trong khi đề chỉ cần di trú một lần.

C — AWS Site-to-Site VPN rồi transfer vào S3 Glacier. Site-to-Site VPN kết nối an toàn mạng on-premises hoặc chi nhánh với Amazon VPC. Nó phù hợp khi bạn có nhu cầu cần ngay và yêu cầu băng thông thấp đến vừa phải. Với 5 PB thì băng thông của VPN hoàn toàn không tương xứng — đây là phương án yếu nhất trong bốn phương án về mặt khối lượng dữ liệu.

D — Snowball Edge rồi copy thẳng vào S3 Glacier. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi: chọn đúng phương tiện vận chuyển (Snowball Edge Storage Optimized, nhiều thiết bị), chỉ hỏng đúng ở bước cuối. Như đã nêu, không thể copy dữ liệu từ thiết bị Snowball Edge trực tiếp vào Amazon S3 Glacier — dữ liệu phải vào S3 trước, rồi mới dùng lifecycle policy để đưa sang Glacier. Thiếu bước trung gian đó, phương án mô tả một luồng không thực hiện được.

📌 Điểm cần nhớ

• Khối lượng dữ liệu là tín hiệu chọn phương tiện: hàng chục TB đến hàng PB, chuyển một lần → nghĩ tới Snowball Edge, không nghĩ tới đường mạng.
• Direct Connect giải bài toán kết nối chuyên dụng lâu dài, tốn kém và mất nhiều thời gian dựng; Site-to-Site VPN hợp với nhu cầu gấp và băng thông thấp–vừa. Cả hai đều không phải công cụ cho một lần di trú quy mô petabyte.
• Dữ liệu từ Snowball Edge luôn đáp xuống Amazon S3 trước; muốn vào S3 Glacier thì dùng lifecycle policy để transition. Bất kỳ phương án nào nói "copy thẳng từ Snowball vào Glacier" đều sai.
• Khi hai phương án chỉ khác nhau ở bước cuối cùng, hãy đọc kỹ bước đó thay vì dừng lại ở chỗ chúng giống nhau — đó thường là chỗ đề giấu điểm phân biệt.

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

Đề mô tả một công ty truyền thông số muốn bỏ hạ tầng IT tự vận hành, và cần đưa khoảng 9 PB dữ liệu từ data center on-premises lên AWS để lưu trữ dài hạn. Câu hỏi yêu cầu cách nhanh nhất và tối ưu chi phí nhất để vừa di chuyển vừa lưu trữ khối dữ liệu này.

Có hai cụm từ quyết định, và bốn phương án được dựng ra đúng để thử cả hai:

1. "about 9 PB" — con số này nằm dưới ngưỡng mà AWS khuyến nghị dùng Snowmobile. Hướng dẫn của AWS là dùng Snowmobile cho tập dữ liệu từ 10 PB trở lên tại một địa điểm duy nhất; dưới mức đó thì Snowball là lựa chọn phù hợp. 9 PB rơi ngay dưới lằn ranh, nên mọi phương án Snowmobile bị loại.
2. "storing this data" với đích đến là Glacier Deep Archive — điểm này thử kiến thức về đường đi của dữ liệu: Snowball Edge ghi dữ liệu vào S3, không ghi thẳng vào Glacier Deep Archive. Muốn xuống Deep Archive phải qua lifecycle policy trên bucket S3.

Nói cách khác, đề tách bài toán thành hai lựa chọn độc lập: thiết bị nào (Snowball Edge vs Snowmobile) và đích ghi nào (S3 rồi lifecycle vs thẳng Glacier). Chỉ một phương án đúng cả hai.

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

Đáp án B — dùng nhiều thiết bị Snowball Edge Storage Optimized, chép dữ liệu vào Amazon S3, rồi tạo lifecycle policy chuyển sang Glacier Deep Archive.

• Snowball Edge Storage Optimized là lựa chọn AWS đưa ra cho nhu cầu chuyển từ vài chục TB đến mức petabyte một cách an toàn và nhanh. Mỗi thiết bị cung cấp dung lượng HDD dùng được lớn cùng vCPU, SSD và kết nối mạng tốc độ cao để phục vụ chuyển dữ liệu quy mô lớn và tiền xử lý. Với 9 PB thì phải dùng nhiều thiết bị song song — và chính việc chạy song song nhiều thiết bị là thứ khiến phương án này nhanh.
• Đường đi S3 → lifecycle → Glacier Deep Archive là cách duy nhất hợp lệ với Snowball Edge. Dữ liệu từ thiết bị đổ vào bucket S3, sau đó rule lifecycle tự động chuyển các object xuống Deep Archive — tầng lưu trữ rẻ nhất của S3, đúng với yêu cầu "durable long-term storage" và "MOST cost-optimal".

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

A — Snowmobile → S3 → lifecycle sang Glacier Deep Archive. Đây là phương án gần đúng nhất: phần đích đến (S3 rồi lifecycle) hoàn toàn hợp lệ. Nó hỏng ở thiết bị. Snowmobile là dịch vụ chuyển dữ liệu quy mô exabyte, dành cho tập dữ liệu từ 10 PB trở lên tại một địa điểm; với 9 PB thì AWS khuyến nghị Snowball. Huy động cả một Snowmobile cho khối dưới ngưỡng vừa không phải khuyến nghị của AWS vừa không tối ưu chi phí.

C — Snowmobile → chép thẳng vào Glacier Deep Archive. Điểm cần lưu ý: phần kỹ thuật của phương án này không sai — với Snowmobile, dữ liệu có thể nhập thẳng vào Glacier. Nhưng nó vẫn hỏng ở đúng chỗ như phương án A: 9 PB nằm dưới ngưỡng khuyến nghị dùng Snowmobile, nên thiết bị đã chọn sai ngay từ đầu. Đây là bẫy dành cho người nhớ được "Snowmobile ghi thẳng Glacier được" mà quên mất ràng buộc dung lượng trong đề.

D — Snowball Edge → chép thẳng vào Glacier Deep Archive. Chọn đúng thiết bị nhưng sai đường đi. Không thể chép dữ liệu trực tiếp từ Snowball Edge vào Glacier Deep Archive — thiết bị Snowball Edge đổ dữ liệu vào S3, và chỉ từ đó mới xuống được Deep Archive bằng lifecycle policy. Phương án này mô tả một thao tác không tồn tại.

📌 Điểm cần nhớ

• Ngưỡng ~10 PB tại một địa điểm là lằn ranh Snowmobile / Snowball. Từ 10 PB trở lên ở một nơi → Snowmobile; dưới mức đó, hoặc dữ liệu nằm rải rác nhiều địa điểm → nhiều thiết bị Snowball Edge. Đề luôn cài con số ngay sát ngưỡng để phân biệt.
• Snowball Edge chỉ ghi vào S3, không ghi thẳng vào Glacier. Muốn tới Glacier hay Glacier Deep Archive thì bắt buộc phải qua lifecycle policy trên bucket. Snowmobile thì ngược lại — nhập thẳng vào Glacier được.
• Snowball Edge Storage Optimized là biến thể dành riêng cho khối lượng dữ liệu lớn (hàng chục TB đến petabyte); nhiều thiết bị chạy song song chính là cách rút ngắn thời gian di chuyển.
• Khi đề hỏi "quickest and MOST cost-optimal", hãy tách thành hai lựa chọn riêng — thiết bị vận chuyển và tầng lưu trữ đích — rồi loại từng phương án theo từng tiêu chí, thay vì đọc cả câu như một khối.

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

Đề bài yêu cầu mount một network file system lên các Linux instance, trong đó dữ liệu ban đầu được truy cập thường xuyên rồi sau đó ít dần, và hỏi giải pháp tiết kiệm chi phí nhất.

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

• "mount a network file system on Linux instances" — đây là ràng buộc cứng, loại trước tiên. Nó đòi hỏi một dịch vụ file storage nói được giao thức NFS, để nhiều Linux instance cùng mount một cây thư mục chung. Ràng buộc này một mình đã gạt được ba trong bốn phương án.
• "frequently at first, and then infrequently" — đây là ràng buộc chi phí, dùng để chọn đúng storage class trong nhóm dịch vụ đã lọt qua vòng đầu. Mẫu truy cập "nóng rồi nguội" chính là mô tả kinh điển của một tier Infrequent Access.

Bẫy của câu này nằm ở chỗ vế thứ hai nghe rất giống mô tả của S3 Intelligent-Tiering, khiến người làm bài dễ bỏ qua vế thứ nhất.

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

B — Amazon EFS Infrequent Access.

Amazon EFS là dịch vụ elastic NFS file system được quản lý hoàn toàn, dùng trực tiếp với các dịch vụ AWS và cả tài nguyên on-premises. Đây là dịch vụ ở phạm vi Region, lưu dữ liệu trong và giữa nhiều Availability Zone để đạt tính sẵn sàng và độ bền cao. Vì nó là file system nói giao thức NFS, nhiều Linux instance mount được cùng lúc — đúng thứ đề bài yêu cầu.

EFS Infrequent Access (EFS IA) là storage class của chính EFS, tối ưu tỷ lệ giá/hiệu năng cho những file không được truy cập hằng ngày, với giá lưu trữ thấp hơn đáng kể so với EFS Standard. Nghĩa là đáp án này thoả cả hai ràng buộc cùng lúc: vẫn là file system mount được, mà lại rẻ hơn khi dữ liệu chuyển sang giai đoạn ít truy cập.

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

A — Amazon S3 Glacier Deep Archive. Đây là storage class của S3 dành cho lưu trữ dài hạn và sao lưu, giá cực thấp, độ bền rất cao, đáp ứng được các yêu cầu tuân thủ khắt khe. Nhưng nó vẫn là object storage/archival, không phải file system — không mount được như một network file system trên Linux instance. Ngoài ra Deep Archive dành cho dữ liệu gần như không đụng tới, còn đề nói giai đoạn đầu dữ liệu được truy cập thường xuyên, nên nó sai ở cả hai mặt.

C — Amazon EBS io1/io2. EBS volume là ổ đĩa mạng gắn vào EC2 instance đang chạy, giúp dữ liệu tồn tại kể cả sau khi instance bị terminate. Vấn đề là EBS là block storage, không phải file storage: nó cung cấp một block device cho instance, còn file system thì do hệ điều hành tự tạo bên trên — nó không phải "network file system" theo nghĩa đề bài. Thêm nữa io1/io2 là dòng volume hiệu năng cao dành cho workload IOPS lớn, tức là hướng ngược hẳn với yêu cầu "MOST cost-effective" cho dữ liệu càng ngày càng ít dùng.

D — Amazon S3 Intelligent-Tiering. Đây là phương án gần đúng nhất, và chỗ hỏng của nó rất đáng nhớ. Về phần chi phí thì nó khớp với đề: Intelligent-Tiering tự động chuyển dữ liệu sang access tier tiết kiệm hơn khi dữ liệu nguội đi, không ảnh hưởng hiệu năng và không cần vận hành thủ công — đúng kiểu "nóng rồi nguội". Nhưng nó hỏng ở ràng buộc đầu tiên: S3 là object storage, không mount được thành network file system trên Linux instance. Chọn D là đọc đúng vế thứ hai của đề mà bỏ mất vế thứ nhất.

📌 Điểm cần nhớ

• Khi đề nói "mount a network file system", hãy lọc theo loại storage trước, lọc theo chi phí sau: file storage (EFS) ≠ object storage (S3, Glacier) ≠ block storage (EBS). Ràng buộc loại storage thường một mình đã cắt được đa số phương án.
• Nhiều dịch vụ AWS có storage class riêng cho dữ liệu ít truy cập — EFS có Infrequent Access, S3 có Intelligent-Tiering và Glacier. Mẫu "truy cập nhiều rồi ít dần" là gợi ý chọn tier, không phải gợi ý đổi sang họ dịch vụ khác.
• EBS gắn vào instance như một block device và cần OS tạo file system bên trên; EFS là file system dùng chung, mount được từ nhiều instance. Đề nào nhấn mạnh "shared"/"mount"/"NFS" thì hướng về EFS.
• Cẩn thận với phương án chỉ khớp một nửa đề bài (như S3 Intelligent-Tiering ở đây): khớp phần chi phí nhưng trượt phần giao thức truy cập vẫn là sai.

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

Đề mô tả nhiều team trong cùng một công ty dùng Amazon Athena để chạy truy vấn ad-hoc trên dữ liệu nằm trong một bucket Amazon S3. Chi phí Athena đang cao, và công ty cần hai thứ cùng lúc:

1. Đặt giới hạn lượng dữ liệu mỗi team được quét (Athena tính tiền theo số byte scan, nên đây vừa là chuyện chi phí vừa là chuyện quản trị).
2. Mỗi team không được thấy queries, query results, và query history của team khác.

Cụm từ quyết định đáp án là "query history" (kết hợp với "limit on the amount of data that can be scanned") và "least operational and cost overhead". Query history không phải là dữ liệu trong S3, cũng không phải là bảng trong data catalog — nó là metadata do chính Athena quản lý. Vì vậy mọi phương án cố kiểm soát nó bằng công cụ ở tầng S3 hay tầng bảng/cột đều trượt. Chỉ có một cấu trúc trong Athena vừa cô lập được lịch sử truy vấn, vừa đặt được ngưỡng dữ liệu quét: workgroup.

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

Đáp án đúng là C — Create an Athena workgroup for each team and apply tags. Use these tags in a new IAM policy to configure appropriate permissions to the workgroups.

Workgroup trong Athena sinh ra đúng để tách người dùng, team, ứng dụng hoặc workload khỏi nhau. Nó khớp cả hai yêu cầu của đề:

• Cô lập truy vấn và lịch sử: queries, query results và query history thuộc về workgroup nào thì chỉ nhìn thấy được trong phạm vi workgroup đó. Workgroup là một resource thật trong AWS, nên có thể dùng resource-level identity-based IAM policy để quyết định ai được vào workgroup nào. Đây là cách duy nhất trong danh sách kiểm soát được truy cập tới query history.
• Kiểm soát chi phí: workgroup cho phép cấu hình limit trên lượng dữ liệu được scan — theo từng query hoặc theo cả workgroup. Vượt ngưỡng thì có thể kích hoạt hành động, ví dụ gửi thông báo qua Amazon SNS. Metrics liên quan tới truy vấn cũng xem được trong Amazon CloudWatch, nên chi phí theo dõi được theo từng team.

Phần tag trong phương án là cách làm quy mô hoá phân quyền: gắn tag lên workgroup rồi viết IAM policy điều kiện theo tag, thay vì liệt kê từng ARN workgroup trong policy. Đây chính là "least operational overhead" — thêm team mới chỉ cần tạo workgroup và gắn đúng tag, không phải sửa policy.

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

A — S3 Access Points. Access point là tính năng của S3: mỗi access point có access control policy riêng, giúp chia sẻ một dataset lớn cho hàng trăm ứng dụng mà không phải viết một bucket policy khổng lồ, và có thể ràng buộc access point chỉ dùng được từ trong một VPC. Nhưng nó chỉ chi phối truy cập tới object trong S3. Query history của Athena không nằm ở đó, nên access point policy không đụng tới được. Ngoài ra phương án này cũng không có cơ chế nào giới hạn số byte Athena được scan.

B — IAM group cho mỗi team với custom IAM policy. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì phần cuối cùng của lời giải đúng cũng dùng IAM. Chỗ hỏng nằm ở chỗ: IAM policy chỉ cấp/chặn quyền trên resource đã tồn tại. Nếu không có workgroup thì mọi người cùng ở chung một không gian truy vấn, và không có resource nào để IAM chia tách query history theo team. IAM group tự nó cũng không có nút nào để đặt ngưỡng dữ liệu quét — đó là thiết lập nằm bên trong workgroup. Nói cách khác, B thiếu đúng cái mảnh mà C bổ sung; IAM là công cụ đi kèm workgroup chứ không thay thế được workgroup.

D — AWS Lake Formation. Lake Formation quản lý phân quyền ở mức database, table và column cho dữ liệu trong data lake khi đọc bằng Athena, nên nghe rất hợp với "phân quyền cho từng team". Nhưng nó hỏng ở hai điểm đúng vào yêu cầu của đề: vị trí lưu query result của Athena trong S3 không đăng ký được với Lake Formation — quyền truy cập chỗ đó do IAM policy trên S3 quyết định; và permission của Lake Formation không áp dụng cho query history của Athena. Lake Formation cũng không phải nơi đặt giới hạn lượng dữ liệu Athena được scan. Muốn kiểm soát query history thì vẫn phải quay về workgroup.

📌 Điểm cần nhớ

• Đề nhắc tới query history / query results / giới hạn dữ liệu scan của Athena → gần như chắc chắn câu trả lời là Athena workgroup. Đây là chữ ký nhận dạng rõ nhất của dạng câu này.
• Phân biệt ba tầng kiểm soát khi làm việc với Athena: Lake Formation lo quyền ở mức database/table/column, S3 (bucket policy, Access Points) lo quyền trên object, còn workgroup lo phạm vi truy vấn — lịch sử, kết quả, và hạn mức chi phí. Chúng không thay thế được nhau.
• Workgroup là một resource, nên IAM policy áp được ở mức resource. IAM và workgroup là cặp bổ sung: workgroup tạo ra ranh giới, IAM quyết định ai bước qua được ranh giới đó.
• Gắn tag lên resource rồi viết IAM policy theo tag là mẫu chuẩn để giảm chi phí vận hành khi số team còn tăng — gặp cụm "least operational overhead" trong đề thì đây thường là hướng đúng.

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

Đề mô tả một ứng dụng real-time streaming trên AWS: dữ liệu được nạp vào liên tục, và mỗi khi có dữ liệu thì một job chạy 30 phút mới xong. Hệ thống thường xuyên bị latency cao vì khối lượng dữ liệu đổ về quá lớn. Cần chọn hai bước để dựng giải pháp mới.

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

• "real-time streaming" — lớp ingestion phải là dịch vụ nhận luồng dữ liệu thời gian thực, không phải công cụ di chuyển database.
• "takes 30 minutes to complete" — con số này không phải cho vui. Nó là cái bẫy chính, dùng để loại một lựa chọn compute nghe rất "đúng bài serverless".
• "scalable and serverless" — chữ serverless loại thẳng mọi phương án bắt bạn tự provision và quản lý máy chủ.

Câu hỏi cần một dịch vụ cho lớp nạp dữ liệu + một dịch vụ cho lớp xử lý, cả hai đều phải serverless.

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

Đáp án đúng theo tệp là A và B.

A — Amazon Kinesis Data Streams để ingest dữ liệu. Kinesis Data Streams là dịch vụ streaming thời gian thực, được thiết kế đúng cho việc thu liên tục lượng lớn dữ liệu từ rất nhiều nguồn (clickstream, event từ database, giao dịch tài chính, log hệ thống, dữ liệu vị trí…). Dữ liệu vào stream sẵn sàng cho consumer gần như tức thì, phù hợp với các use case real-time. Đây là lớp ingestion khớp với chữ "real-time streaming" trong đề.

B — AWS Fargate với Amazon ECS để xử lý dữ liệu. Fargate là compute engine serverless cho container, dùng được với cả ECS lẫn EKS. Bạn không phải provision hay quản lý máy chủ, chỉ khai báo tài nguyên cho từng ứng dụng và trả tiền theo đó. Quan trọng nhất với câu này: task chạy trên Fargate không bị giới hạn thời gian kiểu function, nên job 30 phút chạy trọn vẹn được. Ghép lại: Kinesis Data Streams làm lớp nạp, ứng dụng container trên ECS/Fargate làm lớp xử lý — cả hai đều serverless và đều co giãn được để giải quyết vấn đề latency.

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

C — AWS Database Migration Service (DMS) để ingest dữ liệu. DMS là công cụ di chuyển database sang AWS một cách nhanh chóng và an toàn. Nó làm việc với nguồn là các database engine, không phải là lớp thu nhận luồng sự kiện thời gian thực từ hàng loạt nguồn phát. Dùng DMS ở đây là đặt sai dịch vụ vào sai tầng kiến trúc.

E — AWS Lambda với AWS Step Functions để xử lý dữ liệu. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì Lambda + Step Functions đúng là serverless, đúng là co giãn tự động, và là lựa chọn quen thuộc cho xử lý stream. Chỗ hỏng nằm đúng ở con số trong đề: Lambda có thời gian chạy tối đa 15 phút cho một lần thực thi, hết hạn là Lambda chấm dứt function. Job trong đề cần 30 phút — gấp đôi trần đó, nên một lần gọi Lambda không thể hoàn thành job. Step Functions điều phối được nhiều bước nhưng không nới trần thời gian của bản thân từng Lambda function, và đề cũng không nói job này chia nhỏ được. Vì thế Lambda bị loại.

D — EC2 instances trong Auto Scaling group để xử lý dữ liệu. Phương án này giải quyết được vế "scalable" (Auto Scaling co giãn theo tải) và chạy được job 30 phút, nhưng nó vi phạm thẳng yêu cầu serverless: bạn vẫn phải provision instance, chọn kiểu máy, vá hệ điều hành và quản lý vòng đời máy chủ. Đề nêu rõ cần một giải pháp serverless, nên EC2 bị loại vì lý do mô hình vận hành chứ không phải vì năng lực kỹ thuật.

📌 Điểm cần nhớ

• Câu hỏi kiến trúc streaming thường tách làm hai tầng: ingestion và processing. Đọc đề là phải xác định ngay mỗi phương án đang thuộc tầng nào — chọn hai dịch vụ cùng một tầng là sai ngay cả khi cả hai đều tốt.
• Mọi con số thời gian trong đề đều là ràng buộc, không phải chi tiết trang trí. Thấy job chạy dài hơn giới hạn thực thi tối đa của Lambda là dấu hiệu chuyển sang container (Fargate/ECS) hoặc compute chạy dài khác.
• "Serverless" là từ khóa loại trừ. Đề nhắc chữ này thì EC2 và Auto Scaling group bị loại tự động, dù chúng hoàn toàn làm được việc.
• Phân biệt đúng bản chất dịch vụ: Kinesis Data Streams = luồng sự kiện thời gian thực, DMS = di chuyển database. Hai thứ này không thay thế nhau dù cùng có chữ "dữ liệu chảy từ nguồn vào AWS".

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

Đề mô tả một bảng DynamoDB lưu lịch sử chơi game của người dùng. Dữ liệu chỉ cần giữ một tuần, nhưng thực tế bảng đang tích tụ nhiều tháng. Công ty muốn một cách rẻ để bảng chỉ còn dữ liệu tuần gần nhất.

Cụm từ quyết định nằm ở câu hỏi cuối: "requires the MINIMUM development effort and ongoing maintenance". Đây không phải câu hỏi "cách nào làm được" — cả bốn phương án đều xoá được dữ liệu cũ. Ràng buộc phân biệt là công sức lập trình và công sức vận hành lâu dài. Thêm hai chi tiết củng cố: dữ liệu nằm trong chính DynamoDB (không phải S3, không phải data lake), và điều kiện xoá là theo tuổi của từng item — đúng mô hình mà DynamoDB đã có sẵn tính năng dựng sẵn.

Khi đề nhấn "minimum development effort", lựa chọn đúng gần như luôn là tính năng có sẵn (managed feature) của chính dịch vụ đang dùng, chứ không phải đoạn code do mình viết ra, dù đoạn code đó ngắn tới đâu.

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

Đáp án B — thêm thuộc tính lưu thời điểm hết hạn và bật Time to Live (TTL) trên bảng.

DynamoDB TTL là tính năng gắn liền trong dịch vụ, dùng để đánh dấu item nào không còn cần nữa. Cách hoạt động:

• Bạn thêm một attribute chứa mốc thời gian hết hạn (dạng epoch timestamp) cho từng item, rồi chỉ định attribute đó khi bật TTL trên bảng.
• Sau khi bật, DynamoDB chạy một tiến trình nền quét theo từng partition, liên tục đánh giá trạng thái hết hạn của các item.
• Item quá hạn sẽ được xoá mà không tiêu tốn write throughput của bảng — đây chính là phần "cost-effective" mà đề nhắc tới.

Tổng công sức của bạn: ghi thêm một attribute lúc insert item, và bật một tuỳ chọn cấu hình trên bảng. Không viết code xoá, không lịch chạy, không hạ tầng để trông coi. Đó là đáp án tối thiểu cả về development effort lẫn ongoing maintenance — đúng hai tiêu chí đề đặt ra.

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

A — Thêm attribute hết hạn rồi dùng Glue job xoá item cũ hơn một tuần. Về mặt kỹ thuật là làm được, nhưng đây là phương án nặng nhất trong nhóm. Bạn phải xây dựng và bảo trì một Glue job chỉ để tỉa bớt bảng DynamoDB, và job đó chạy hằng ngày nên phát sinh chi phí riêng. Glue vốn là công cụ ETL cho khối lượng xử lý dữ liệu lớn, dùng nó cho việc dọn item hết hạn là dùng búa tạ đập hạt dẻ. Trớ trêu ở chỗ phương án này thêm đúng attribute mà TTL cần, rồi lại tự đi viết cơ chế xoá thay vì bật TTL.

C — Thêm created_at rồi cron job trên EC2 gọi script Python mỗi ngày. Phương án tệ nhất về maintenance. Bạn phải provision một EC2 instance, viết script Python, và từ đó gánh toàn bộ vòng đời của máy chủ đó: vá lỗi hệ điều hành, xử lý khi instance chết, theo dõi xem cron có thực sự chạy không, IAM cho instance. Instance chạy suốt ngày chỉ để làm một việc vài giây mỗi 24 giờ nên chi phí cũng vô lý. Vừa nhiều development effort, vừa nhiều ongoing maintenance — trượt cả hai tiêu chí.

D — Thêm created_at rồi CloudWatch Events rule gọi Lambda mỗi ngày. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Nó serverless, không có máy chủ để bảo trì, rẻ hơn hẳn EC2 — nhiều người dừng ở đây. Nhưng nó vẫn hỏng ở đúng chỗ đề hỏi: bạn vẫn phải viết custom code cho Lambda function để quét và xoá item, rồi bảo trì đoạn code đó về sau (xử lý phân trang khi quét, giới hạn thời gian chạy của function, lỗi khi xoá theo lô). Chi phí thực thi Lambda cũng bị tính riêng. So với TTL — nơi bạn không viết một dòng logic xoá nào — D vẫn nhiều development effort hơn. "Ít công hơn C" không đủ; đề hỏi MINIMUM.

📌 Điểm cần nhớ

• Xoá dữ liệu hết hạn trong DynamoDB theo tuổi từng item = TTL. Đây là phản xạ mặc định; TTL xoá item mà không tiêu tốn write throughput của bảng.
• "MINIMUM development effort / ongoing maintenance" là từ khoá loại trừ mọi phương án phải tự viết code, kể cả code serverless. Thứ tự công sức tăng dần thường là: tính năng có sẵn của dịch vụ → Lambda theo lịch → job ETL (Glue) → cron trên EC2 tự quản.
• Cẩn thận với phương án "gần đúng" kiểu CloudWatch Events + Lambda. Nó đúng về mặt kiến trúc và sẽ chạy được, nhưng khi đề so sánh công sức thì bất kỳ custom code nào cũng thua một tuỳ chọn cấu hình bật-là-xong.
• Bất cứ khi nào phương án tự dựng EC2 để chạy cron xuất hiện trong câu hỏi về cost/effort, gần như chắc chắn đó là đáp án sai — nó kéo theo toàn bộ gánh nặng vận hành một máy chủ.