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

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

Đề mô tả một data engineer phải theo dõi hiệu năng truy vấn trên cụm Amazon Redshift hằng ngày và gửi báo cáo cuối ngày, gồm hai loại thông tin tách bạch:

1. Những truy vấn chạy lâu có vấn đề về hiệu năng
2. Những transaction đang giữ lock trên các bảng

Cụm từ quyết định nằm ở vế thứ hai: "currently hold locks on tables". Chữ currently loại ngay mọi bảng thuộc họ STL_* khỏi vế này — trong Redshift, tiền tố STL_ là log lịch sử của những gì đã xảy ra, còn thông tin trạng thái đang diễn ra thuộc về các view SVV_*. Vì vậy vế hai bắt buộc phải là SVV_TRANSACTIONS, và câu hỏi rút gọn xuống còn: giữa STL_ALERT_EVENT_LOG và STL_QUERY_METRICS, cái nào cho biết truy vấn có vấn đề hiệu năng?

Đó là điểm phân biệt thứ hai: đề không hỏi "truy vấn tốn bao nhiêu CPU", mà hỏi truy vấn nào chạy kém và cần sửa — tức là cần một nguồn đã chẩn đoán sẵn, chứ không chỉ là số đo thô.

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

Đáp án đúng là C — STL_ALERT_EVENT_LOG, SVV_TRANSACTIONS.

STL_ALERT_EVENT_LOG: khi một truy vấn chạy, Amazon Redshift tự đánh giá xem nó có chạy hiệu quả không. Nếu phát hiện truy vấn kém hiệu quả, Redshift ghi lại query ID kèm khuyến nghị cải thiện hiệu năng vào bảng hệ thống này. Đây chính là nơi đầu tiên cần xem khi gặp truy vấn chạy lâu hoặc kém hiệu quả — nó không chỉ nói "chậm", mà còn nói chậm vì lý do gì, đúng thứ mà một báo cáo gửi team lead cần có.

SVV_TRANSACTIONS: ghi nhận thông tin về các transaction đang giữ lock trên bảng trong database. Đây là view dùng để nhận diện transaction còn mở và tình trạng tranh chấp lock (lock contention) — khớp nguyên văn yêu cầu thứ hai của đề.

Hai đối tượng này phủ đúng hai vế, mỗi vế một cái, không thừa không thiếu.

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

A. STL_USAGE_CONTROL, STL_SESSIONS — sai cả hai vế. STL_USAGE_CONTROL chứa thông tin được ghi lại khi một usage limit bị chạm tới (hạn mức sử dụng), chẳng liên quan gì tới chất lượng truy vấn. STL_SESSIONS dùng để tìm session chạy lâu, không phải transaction đang giữ lock — một session mở lâu không đồng nghĩa với việc nó đang khoá bảng nào.

B. STL_PLAN_INFO, STL_SESSIONS — đây là phương án dễ nhầm nhất ở vế đầu. STL_PLAN_INFO cho phép xem kết quả EXPLAIN của một truy vấn dưới dạng tập dòng dữ liệu, tức là một cách khác để đọc query plan. Nó hữu ích khi bạn đã biết truy vấn nào cần mổ xẻ và muốn đào sâu, nhưng nó không tự chỉ ra truy vấn nào đang có vấn đề — không có bước chẩn đoán, không có khuyến nghị. Dùng nó để dựng báo cáo hằng ngày thì phải tự đọc plan từng câu một. Vế hai lại lặp lại lỗi của phương án A với STL_SESSIONS.

D. STL_QUERY_METRICS, SVV_TRANSACTIONS — vế hai đúng, nên đây là phương án gần đúng nhất và là bẫy chính của câu. Nó hỏng ở vế đầu: STL_QUERY_METRICS chứa số đo (metrics) như số dòng đã xử lý, mức dùng CPU, I/O, dung lượng đĩa — cho các truy vấn đã chạy xong trong những query queue do người dùng định nghĩa (service class). Đó là dữ liệu thô về mức tiêu thụ tài nguyên, không phải kết luận "truy vấn này kém hiệu quả và đây là cách sửa". Ngoài ra phạm vi của nó bị giới hạn trong các hàng đợi do người dùng định nghĩa, nên không phải truy vấn nào cũng xuất hiện ở đó.

📌 Điểm cần nhớ

• Tiền tố quyết định ngữ nghĩa thời gian: STL_* là log những gì đã xảy ra; SVV_* là view phản ánh trạng thái đang diễn ra. Đề nào có chữ currently, open, in progress thì nghiêng về SVV_*.
• Muốn biết transaction nào đang giữ lock / tranh chấp lock trên Redshift, SVV_TRANSACTIONS là chỗ tra thẳng.
• Phân biệt chẩn đoán với đo đạc: STL_ALERT_EVENT_LOG nói truy vấn kém ở đâu và nên sửa thế nào; STL_QUERY_METRICS chỉ cho số liệu tiêu thụ tài nguyên của truy vấn đã hoàn tất. Đề hỏi "performance issues" → chọn cái có khuyến nghị.
• STL_SESSIONS là về session chứ không phải lock, còn STL_PLAN_INFO là cách đọc EXPLAIN sau khi đã khoanh vùng được truy vấn — cả hai đều là bước sau, không phải bước phát hiện vấn đề.

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

Đề mô tả một tình huống rất cụ thể: kỹ sư dữ liệu muốn Amazon Athena tạo một table cho mỗi file đang nằm dưới cùng một prefix trong Amazon S3. Câu CREATE TABLE chạy thành công, cột và kiểu dữ liệu đều đúng, nhưng SELECT trả về zero records.

Cụm từ quyết định là "a table for each file stored under the same prefix". Đây chính là nguyên nhân, không phải chi tiết trang trí: Athena không đọc theo file, nó đọc theo prefix. Khi khai báo LOCATION, Athena quét toàn bộ mọi thứ nằm dưới prefix đó. Nhiều file cùng nằm chung một prefix nghĩa là nhiều table cùng trỏ về một vùng dữ liệu chồng lấn — và cách Athena xử lý tình huống này dẫn tới kết quả rỗng.

Câu hỏi cũng nói rõ nó hỏi "the right way to configure the Amazon S3 location path", tức là đang tìm cách bố trí đúng, chứ không phải liệt kê các lỗi có thể xảy ra. Ba phương án còn lại đều là những cấu hình gây ra lỗi zero records, chỉ có một phương án mô tả cách sắp xếp đúng.

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

Đáp án đúng theo tệp là D — Create individual S3 prefixes for each table, dạng s3://doc-example-bucket/table1/table1.csv và s3://doc-example-bucket/table2/table2.csv.

Mỗi table lúc này có prefix riêng của nó: table1/ chứa đúng dữ liệu của table1, table2/ chứa đúng dữ liệu của table2. LOCATION của mỗi table trỏ tới đúng một thư mục logic không chồng lấn với table khác. Đây chính là mô hình mà Athena (và Glue Data Catalog) được thiết kế để làm việc: một table ↔ một prefix, và mọi object dưới prefix đó là dữ liệu của table đó.

Bố trí lại theo cách này giải quyết trực tiếp vấn đề mà đề nêu — đó cũng là hướng khắc phục được nêu trong tài liệu hỗ trợ của AWS về việc Athena trả về kết quả rỗng.

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

A — s3://doc-example-bucket/myprefix//input//

Đây là một nguyên nhân thật gây zero records, nhưng là một nguyên nhân khác, không phải nguyên nhân trong đề. Athena không hỗ trợ LOCATION chứa dấu gạch chéo kép (//); một path như vậy sẽ trả về kết quả rỗng. Đề bài không nói gì tới double slash — nó nói tới nhiều file cùng một prefix. Và quan trọng hơn: phương án này mô tả một cấu hình hỏng, trong khi câu hỏi đang tìm cách cấu hình đúng. Cách chữa cho trường hợp double slash là copy file sang vị trí không có gạch chéo kép.

B — s3://doc-example-bucket/athena/inputdata/_file1

Cũng là một nguyên nhân zero records có thật, nhưng lại càng không khớp đề. File có tên bắt đầu bằng dấu gạch dưới (_) hoặc dấu chấm (.) bị Athena coi là placeholder và bị bỏ qua khi xử lý query. Nếu toàn bộ file dưới path đều có tên kiểu đó thì kết quả đương nhiên rỗng. Đây là bẫy hay gặp, nhưng gợi ý đây là "cách cấu hình đúng" thì sai hoàn toàn — đặt tên file như vậy chính là tự làm dữ liệu vô hình.

C — s3://doc-example-bucket/table1.csv, s3://doc-example-bucket/table2.csv

Đây là phương án gần đúng nhất và nguy hiểm nhất, vì nó mô tả đúng tình huống đề đang gặp — nhiều file phẳng nằm chung một prefix (ở đây là gốc bucket). Nó hỏng ở chỗ: đó chính là triệu chứng, không phải cách chữa. Glue crawler vẫn tạo ra các table riêng cho dữ liệu nằm cùng một prefix, nên bước CREATE TABLE trông có vẻ trót lọt — đúng như đề mô tả — nhưng khi query trong Athena thì trả về zero records. Chọn C là chọn lại đúng cái bố cục đang gây lỗi. Phương án D là bản sửa của chính C.

📌 Điểm cần nhớ

• Athena đọc theo prefix, không đọc theo file. Quy tắc bố trí an toàn là một table ↔ một prefix riêng; đừng để nhiều table trỏ chung vào một thư mục chứa nhiều file.
• CREATE TABLE thành công không có nghĩa dữ liệu đọc được. Athena là schema-on-read: DDL chỉ ghi metadata vào Data Catalog, mọi lỗi về vị trí và bố cục dữ liệu chỉ lộ ra lúc SELECT.
• Ba nguyên nhân kinh điển của "zero records" trong Athena: nhiều table chung một prefix, LOCATION chứa gạch chéo kép (//), và file có tên bắt đầu bằng _ hoặc . (bị coi là placeholder và bỏ qua).
• Đọc kỹ đề đang hỏi "cách đúng" hay "nguyên nhân". Trong câu này ba distractor đều là những cấu hình gây lỗi có thật — nếu đọc lướt sẽ thấy phương án nào cũng "quen", và rất dễ chọn nhầm phương án mô tả chính triệu chứng đang gặp.

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

Một ngân hàng chuyển các ứng dụng lõi lên cloud và dùng Amazon SQS làm lớp hàng đợi. Đề cho hai con số/ràng buộc và chính chúng quyết định đáp án:

• "a peak rate of about 1000 messages per second" — mức đỉnh khoảng 1000 message mỗi giây.
• "It is important that the messages are processed in order" — thứ tự xử lý phải được giữ nguyên.

Cụm thứ hai loại ngay standard queue, vì standard queue chỉ hứa best-effort ordering. Cụm thứ nhất mới là chỗ phân biệt ba phương án FIFO còn lại giống hệt nhau về loại queue: chúng chỉ khác nhau ở số message gộp trong mỗi operation (batch size). Vậy câu này không hỏi "chọn loại queue nào" mà hỏi "cấu hình batch bao nhiêu để FIFO queue tải nổi mức đỉnh".

Nguyên lý cần nắm: FIFO queue có hạn mức tính theo số operation mỗi giây, không phải theo số message mỗi giây. Gộp nhiều message vào một operation (batch) là cách nhân throughput của FIFO queue lên — mỗi operation gửi/nhận/xoá được tối đa 10 message.

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

D — dùng SQS FIFO queue ở chế độ batch 4 message mỗi operation.

Theo lời giải gốc, FIFO queue mặc định hỗ trợ tới 300 operation mỗi giây (send, receive hoặc delete). Batch tối đa 10 message mỗi operation cho ra tối đa 3.000 message mỗi giây. Với batch 4:

300 operation/giây × 4 message/operation = 1.200 message/giây

1.200 > 1.000, tức là vẫn còn dư biên so với mức đỉnh mà đội phát triển dự tính. Đồng thời queue vẫn là FIFO nên yêu cầu giữ nguyên thứ tự — thứ quan trọng nhất với nghiệp vụ ngân hàng lõi — được đáp ứng. D là phương án duy nhất thoả đồng thời cả hai ràng buộc của đề.

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

A — FIFO queue, batch 2 message mỗi operation. Đây là phương án gần đúng nhất: đúng loại queue, đúng ý tưởng dùng batch, chỉ hỏng ở con số. 300 × 2 = 600 message/giây, thiếu so với mức đỉnh 1.000. Khi lưu lượng chạm đỉnh, các lời gọi vượt hạn mức sẽ bị throttle và message dồn lại — hệ thống không sập nhưng không đáp ứng nổi yêu cầu đã nêu.

B — FIFO queue, không batch. Cũng gần đúng vì chọn đúng loại queue giữ thứ tự, nhưng bỏ qua hoàn toàn phần tính toán throughput. Không batch nghĩa là mỗi operation chỉ một message, tức khoảng 300 message/giây — thấp hơn nhiều lần so với 1.000. Đây là bẫy dành cho người đọc lướt, thấy "FIFO" là chọn ngay mà không đọc tới con số peak rate.

C — standard queue. Standard queue có throughput gần như không giới hạn nên thừa sức tải 1.000 message/giây, và nếu đề chỉ nói về hiệu năng thì đây sẽ là lựa chọn tốt. Nhưng nó chỉ đảm bảo best-effort ordering: message thỉnh thoảng đến không đúng thứ tự đã gửi. Với ứng dụng ngân hàng lõi, xử lý sai thứ tự các giao dịch là lỗi nghiệp vụ nghiêm trọng. Ràng buộc "processed in order" trong đề loại thẳng phương án này, bất kể nó nhanh đến đâu.

📌 Điểm cần nhớ

• Ordering trước, throughput sau. Khi đề nói rõ "in order" / "strictly ordered", standard queue bị loại ngay từ vòng đầu; phần còn lại của câu hỏi mới là chuyện cấu hình FIFO queue sao cho đủ tải.
• Hạn mức của FIFO queue đếm theo operation, không đếm theo message. Vì vậy batching là đòn bẩy chính: throughput ≈ (số operation/giây) × (số message mỗi batch), với batch tối đa 10 message mỗi operation.
• Khi các phương án chỉ khác nhau ở một con số, phải làm phép nhân. Ở đây batch 2 cho 600, batch 4 cho 1.200 — chỉ batch 4 vượt được mức đỉnh 1.000, nên đó là phương án duy nhất đúng.
• Chọn con số vừa đủ dư biên, không chọn con số lớn nhất có thể. Đề hỏi cấu hình đáp ứng được peak rate, và batch 4 là mức thoả yêu cầu được nêu trong các phương án — nguyên tắc là đối chiếu từng con số với ngưỡng đề đưa ra chứ không mặc định "càng lớn càng tốt".

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

Đề mô tả một công ty bán lẻ để dữ liệu khách hàng trong một S3 bucket duy nhất. Nhân viên phân tích ở nhiều quốc gia khác nhau cùng truy cập kho dữ liệu đó, và đội governance cần bảo đảm mỗi analyst chỉ xem được dữ liệu khách hàng của quốc gia mình phụ trách.

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

• "can only access customer data from their respective countries" — quốc gia là một thuộc tính nằm trong từng dòng dữ liệu, không phải một ranh giới hạ tầng. Nói cách khác, đây là bài toán row-level security: cùng một tập dữ liệu, mỗi người thấy một tập con các dòng.
• "with minimal operational effort" — mọi phương án đòi tách dữ liệu ra nhiều nơi rồi duy trì việc tách đó mãi mãi đều bị loại, kể cả khi về mặt kỹ thuật chúng có thể chặn đúng.

Ghép hai ràng buộc lại: cần một cơ chế lọc theo dòng, áp lên nguyên trạng dữ liệu đang nằm sẵn trong S3, không phải chép hay chia lại dữ liệu.

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

D. Đăng ký S3 bucket làm data lake location trong AWS Lake Formation và dùng row-level security của Lake Formation.

AWS Lake Formation là dịch vụ quản trị tập trung cho data lake trên S3 cùng metadata trong AWS Glue Data Catalog. Điểm mấu chốt: Lake Formation có mô hình permission riêng bổ sung cho IAM, cho phép grant/revoke quyền ở mức chi tiết theo kiểu gần giống một hệ quản trị CSDL quan hệ.

Trong mô hình đó có data filters — cho phép giới hạn quyền truy cập theo tổ hợp cột và dòng. Đây chính là thứ khớp thẳng với yêu cầu của đề: định nghĩa filter kiểu "chỉ các dòng có country = quốc gia của analyst này", gán cho từng nhóm analyst, và dữ liệu vẫn nằm nguyên một chỗ trong S3. Lake Formation cũng nêu rõ row-level và cell-level security là công cụ dùng để bảo vệ dữ liệu nhạy cảm như PII — mà dữ liệu khách hàng trong đề đúng là loại đó.

Về operational effort: sau khi đăng ký bucket làm data lake location, việc phân quyền là thao tác grant/revoke trên Lake Formation. Không phải chép dữ liệu, không phải tạo thêm bucket, không phải viết logic đồng bộ khi có quốc gia mới.

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

B. S3 Access Point + policy để lọc dữ liệu động theo quốc gia của người đọc — đây là phương án gần đúng nhất và cũng là cái bẫy chính. S3 Access Points là thứ có thật và rất hữu ích: mỗi access point mang một access policy riêng cho từng use case hoặc từng ứng dụng, phục vụ một người dùng hay cả nhóm, kể cả xuyên tài khoản, và quản lý tách bạch nhau. Nhưng access point policy hoạt động ở mức đối tượng S3 — nó nói được "ai được đọc prefix nào, object nào". Nó không đọc được bên trong nội dung file để lọc dòng theo quốc gia của người gọi. Yêu cầu "dynamically filter data" trong phương án này đơn giản là điều S3 Access Point không làm được.

C. Tạo một bucket riêng cho dữ liệu khách hàng của mỗi quốc gia — về lý thuyết chặn được, nhưng đâm thẳng vào ràng buộc "minimal operational effort". Nó biến một kho dữ liệu thành N kho: phải định tuyến dữ liệu mới vào đúng bucket, duy trì N bộ policy, thêm bucket mỗi khi có thị trường mới, và mọi truy vấn phân tích trên toàn cầu đều phải ghép dữ liệu từ nhiều bucket lại. Đây là cách chia dữ liệu theo hạ tầng để giải một bài toán vốn thuộc về tầng phân quyền dữ liệu.

A. Chuyển dữ liệu sang các AWS Region gần từng quốc gia rồi giới hạn quyền theo Region — sai vì cùng lý do với C, và còn nặng hơn. Mỗi S3 bucket gắn với một Region cụ thể, nên phương án này cũng kéo theo việc tạo nhiều bucket, cộng thêm chi phí và độ phức tạp của việc di chuyển dữ liệu qua Region. Ngoài ra nó nhầm lẫn hai chuyện khác nhau: đề nói về quốc gia mà analyst phục vụ, tức là thuộc tính của dữ liệu và của người dùng, chứ không phải vị trí địa lý lưu trữ. Vị trí lưu trữ không tự động trở thành ranh giới phân quyền đúng.

📌 Điểm cần nhớ

• Khi đề yêu cầu lọc theo dòng (mỗi người thấy một tập con dòng của cùng một bảng) trên dữ liệu S3 phục vụ analytics, Lake Formation với data filters / row-level security gần như luôn là câu trả lời. IAM và bucket policy chỉ chặn được ở mức object trở lên.
• S3 Access Points ≠ lọc nội dung. Chúng tách bạch việc quản lý quyền truy cập cho nhiều ứng dụng trên cùng một bucket, chứ không nhìn vào bên trong dữ liệu. Thấy phương án nào nói access point policy "lọc dòng theo người gọi" thì đó là mô tả sai chức năng.
• Cụm "minimal operational effort" là bộ lọc để loại các phương án dựa trên việc nhân bản hạ tầng (nhiều bucket, nhiều Region, nhiều bản sao dữ liệu). Nhân bản chặn được quyền, nhưng đẻ ra công việc duy trì vĩnh viễn.
• Lake Formation bổ sung chứ không thay thế IAM: quyền cuối cùng là sự kết hợp của hai mô hình, và data filters còn hỗ trợ cả column-level lẫn cell-level — hữu ích cho các câu về che PII.

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

Đề mô tả một khối lượng lớn file khoảng 10 MB trên Amazon S3, phải giữ đủ 5 năm rồi mới được xoá. Câu hỏi là chọn giải pháp MOST cost-effective — tức rẻ nhất mà vẫn thoả mọi ràng buộc, chứ không phải rẻ nhất tuyệt đối.

Có ba cụm từ trong đề quyết định đáp án, và mỗi cụm loại đúng một phương án:

• "frequently accessed in the first 30 days ... rarely accessed after the first 30 days" → cần một lifecycle rule chuyển storage class ở mốc 30 ngày. Cả bốn phương án đều làm việc này, nên cụm này chỉ dựng khung.
• "immediate accessibility is always required" → sau 30 ngày file vẫn phải lấy về ngay lập tức, độ trễ mili giây. Đây là cụm giết chết mọi lớp lưu trữ kiểu archive.
• "critical business data that is not easy to reproduce" → dữ liệu mất là không dựng lại được, nên phải nằm ở lớp có độ bền trải trên nhiều Availability Zone.
• "stored for 5 years before they can be deleted" → mốc 5 năm là mốc xoá, không phải mốc bắt đầu một vòng đời lưu trữ mới.

Ai đọc lướt sẽ chỉ bắt được cụm đầu và thấy cả bốn phương án đều hợp lý. Ba cụm sau mới là bộ lọc thật.

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

Đáp án đúng là A: lifecycle policy chuyển từ S3 Standard sang S3 Standard-IA sau 30 ngày, rồi xoá file sau 5 năm.

S3 Standard-IA sinh ra đúng cho kiểu dữ liệu "truy cập không thường xuyên nhưng khi cần thì phải có ngay". Nó giữ nguyên độ bền cao, throughput cao và độ trễ thấp như S3 Standard, chỉ khác ở chỗ giá lưu trữ mỗi GB rẻ hơn còn đổi lại có phí retrieval theo GB. Với hồ sơ truy cập trong đề — dùng nhiều 30 ngày đầu, sau đó hiếm khi chạm tới — phần tiết kiệm được trên chi phí lưu trữ suốt gần 5 năm còn lại lớn hơn nhiều so với khoản retrieval hiếm hoi.

Standard-IA cũng lưu dữ liệu trên tối thiểu ba Availability Zone, khớp với yêu cầu "dữ liệu không dễ tái tạo". File 10 MB thoải mái vượt ngưỡng kích thước tối thiểu mà lớp IA tính phí, nên không dính bẫy phí tối thiểu.

Phần xoá cũng đơn giản: lifecycle configuration hỗ trợ cả transition action (chuyển lớp ở ngày 30) lẫn expiration action (xoá ở mốc 5 năm) trong cùng một rule. Không cần script ngoài, không cần dịch vụ nào khác.

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

B — chuyển sang S3 One Zone-IA sau 30 ngày, xoá sau 5 năm. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì One Zone-IA rẻ hơn Standard-IA. Nhưng khác với các storage class còn lại vốn trải dữ liệu trên tối thiểu ba AZ, One Zone-IA chỉ lưu trong một AZ duy nhất. Nó hợp cho bản backup thứ hai của dữ liệu on-premises, hoặc dữ liệu dựng lại được dễ dàng. Đề đã nói thẳng dữ liệu là critical và không dễ tái tạo, nên đánh đổi độ bền lấy giá rẻ ở đây là sai hướng. Rẻ hơn nhưng vi phạm ràng buộc thì không còn là "cost-effective".

C — chuyển sang Standard-IA sau 30 ngày, rồi archive sang S3 Glacier Deep Archive sau 5 năm. Phần đầu giống hệt đáp án đúng nên rất dễ chọn nhầm. Chỗ hỏng nằm ở vế sau: đề nói sau 5 năm file được phép xoá, chứ không đòi giữ tiếp. Archive sang Deep Archive nghĩa là vẫn tiếp tục trả tiền lưu trữ cho dữ liệu chẳng ai cần nữa, cộng thêm chi phí transition. Xoá hẳn thì chi phí về 0. Đây là lỗi đọc sai yêu cầu: biến "được xoá" thành "phải giữ lâu hơn".

D — chuyển sang S3 Glacier Flexible Retrieval sau 30 ngày, xoá sau 5 năm. Cấu trúc lifecycle đúng, giá lưu trữ cũng rẻ hơn Standard-IA. Nhưng Glacier Flexible Retrieval là lớp archive: kể cả với tuỳ chọn lấy dữ liệu nhanh nhất, thời gian phục hồi vẫn tính bằng phút chứ không phải tức thời. Điều đó đâm thẳng vào ràng buộc "immediate accessibility is always required". Đây là phương án rẻ mà không dùng được.

📌 Điểm cần nhớ

• "MOST cost-effective" luôn có nghĩa là rẻ nhất trong số các phương án còn thoả mọi ràng buộc. Đọc ràng buộc trước, lọc phương án, rồi mới so giá — làm ngược lại là rơi vào bẫy One Zone-IA hoặc Glacier.
• "Immediate access" / "milliseconds" loại toàn bộ họ Glacier. Glacier Flexible Retrieval và Deep Archive đều cần thời gian phục hồi; chỉ Standard, Standard-IA, One Zone-IA và Intelligent-Tiering cho truy cập tức thì.
• One Zone-IA chỉ hợp khi dữ liệu tái tạo được. Hễ đề nhấn "critical", "not easy to reproduce", "cannot be recreated" thì gạch One Zone-IA ngay, dù nó rẻ hơn Standard-IA.
• Mốc thời gian trong đề phải map đúng loại lifecycle action. "Chuyển lớp" là transition action, "được phép xoá" là expiration action — đừng biến mốc xoá thành một chặng archive mới, vì đó là thêm chi phí cho dữ liệu không còn giá trị.

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

Đề mô tả một công ty giao dịch chứng khoán: BI chạy trên Amazon Redshift, còn bảng historical trades thì không nằm trong Redshift — nó là dữ liệu Apache Parquet trong S3, thuộc data lake. Đội data engineering phải mở quyền cho sales, nhưng chỉ một vài cột nhất định của bảng đó vì lý do tuân thủ.

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

• "data is stored in Apache Parquet format in an S3 bucket" — dữ liệu nằm ngoài Redshift, nên phải truy vấn qua Redshift Spectrum, và cách khai báo bảng ngoài cho Spectrum là external schema, không phải schema thường trong cluster.
• "access to only a few specific columns" — phân quyền ở mức cột (column-level access control). Đây là chỗ loại được các phương án chỉ cấp quyền ở mức bucket/object trong S3.

Đề còn nói rõ "(Select three)", nghĩa là cần một tổ hợp ba mảnh ghép: IAM role, external schema, và nơi đặt quyền theo cột.

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

Theo tệp, đáp án đúng là A, E, F. Ba phương án này ghép lại thành đúng một chuỗi thiết lập của Redshift Spectrum có kiểm soát ở mức cột:

• F — Tạo IAM role cho Amazon Redshift với policy cho phép Redshift truy cập AWS Lake Formation. Redshift cần một danh tính để đi hỏi quyền. Khi bảng ngoài được Lake Formation quản lý, chính Lake Formation là nơi cấp/từ chối, nên role của Redshift phải được phép làm việc với Lake Formation chứ không phải tự đi thẳng vào dữ liệu.
• E — Tạo external schema trong Redshift bằng chính IAM role đó. Đây là bước bắt buộc để Redshift Spectrum "nhìn thấy" bảng Parquet trong S3. External schema là cầu nối giữa cluster Redshift và catalog chứa định nghĩa bảng; không có nó thì các truy vấn BI hiện có không chạm tới được dữ liệu trong data lake.
• A — Cấp quyền trong Lake Formation cho IAM role của Redshift trên đúng các cột cần thiết. Đây là chỗ ràng buộc tuân thủ được thực thi. Redshift Spectrum hỗ trợ column-level access control cho dữ liệu ở S3 khi dữ liệu đó do Lake Formation quản lý: quản trị viên chỉ định rõ bảng nào, cột nào mà role được đọc (làm trên console Lake Formation, hoặc bằng câu lệnh GRANT trong SQL).

Đọc theo thứ tự: có danh tính (F) → khai báo được bảng ngoài (E) → siết quyền tới từng cột (A). Bỏ bất kỳ mảnh nào thì hoặc không truy vấn được, hoặc truy vấn được nhưng thấy cả những cột không được phép.

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

• B — Tạo IAM role cho Redshift với policy cho phép truy cập S3 bucket chứa dữ liệu bảng historical trades. Đây là phương án gần đúng nhất và cũng là bẫy chính. Nó đúng cho một Spectrum "trần" không có Lake Formation, nhưng ở đây yêu cầu là lọc theo cột — mà quyền S3 thì cấp trên object/prefix, tức là được đọc cả tệp Parquet hoặc không đọc gì cả. Với mô hình đề bài, role phải trỏ về Lake Formation (phương án F) để quyền được phân giải ở tầng bảng/cột.
• C — Cấp quyền trong bucket policy của S3 cho IAM role của Redshift trên các cột cụ thể. Sai ở chỗ cơ bản: bucket policy của S3 không hiểu khái niệm cột. S3 nhìn thấy các đối tượng nhị phân, không nhìn thấy schema bên trong tệp Parquet, nên không có cách nào viết một bucket policy nói "chỉ được đọc cột X và Y". Việc phân quyền theo cột phải nằm ở Lake Formation.
• D — Tạo internal schema trong Redshift bằng IAM role của Redshift. Sai vì internal schema chứa các bảng nằm bên trong cluster Redshift, còn dữ liệu ở đây vẫn nằm nguyên trên S3 và đề không nói gì tới việc nạp dữ liệu vào Redshift. Muốn Spectrum truy vấn dữ liệu S3 thì phải là external schema (phương án E). Ngoài ra, khái niệm "tạo internal schema bằng IAM role" cũng không đúng cách dùng — role gắn với external schema mới có ý nghĩa.

📌 Điểm cần nhớ

• Dữ liệu nằm trong S3, truy vấn từ Redshift ⇒ nghĩ ngay tới Redshift Spectrum + external schema. Thấy "internal schema" trong đề kiểu này thì gần như chắc chắn là mồi nhử.
• Phân quyền theo cột hoặc theo dòng trên data lake là việc của AWS Lake Formation, không phải của IAM policy hay S3 bucket policy — S3 chỉ phân quyền tới mức đối tượng, hoàn toàn mù trước cấu trúc bên trong tệp Parquet.
• Khi bảng do Lake Formation quản lý, IAM role của Redshift phải được cấp quyền truy cập Lake Formation, còn quyền trên dữ liệu thật thì cấp bằng GRANT trong Lake Formation cho chính role đó.
• Dạng câu "(Select three)" về bảo mật thường yêu cầu đủ ba lớp: danh tính (IAM role) → cách nhìn thấy dữ liệu (external schema) → nơi thực thi quyền chi tiết (Lake Formation). Kiểm lại xem tổ hợp mình chọn có thiếu lớp nào không.

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

Đề mô tả một ứng dụng chạy trên Amazon EC2, trước đây ở môi trường staging chỉ sinh dữ liệu tạm, nay chuyển sang production nên dữ liệu phải sống sót ngay cả khi EC2 instance bị terminate. Người kỹ sư phải launch instance mới từ một AMI và cấu hình sao cho dữ liệu được giữ lại vĩnh viễn.

Cụm từ quyết định đáp án là "even if the EC2 instances are terminated" kết hợp với "Apply the default settings". Hai vế này phải đọc cùng nhau:

• "terminated" — không phải stop, không phải reboot. Terminate là vòng đời kết thúc hẳn.
• "default settings" — nghĩa là bạn không được đụng vào cờ Delete on termination, không tự chỉnh gì thêm. Phải chọn kiến trúc lưu trữ mà bản thân mặc định của nó đã bảo toàn dữ liệu.

Điểm phân biệt còn lại nằm ở chỗ dữ liệu ứng dụng được đặt ở đâu: root volume hay data volume, và EBS hay instance store. Bốn phương án chính là bốn tổ hợp của hai trục đó.

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

Đáp án đúng theo tệp là A: launch từ AMI backed by EC2 instance store, rồi attach thêm một Amazon EBS volume để chứa dữ liệu ứng dụng, giữ nguyên default settings.

Lý do bám theo hai quy tắc vòng đời mà tài liệu AWS nêu:

1. Khi instance terminate, mọi dữ liệu trên instance store volume và trong RAM đều bị xoá sạch. Instance store gắn vật lý với host, không phải lưu trữ bền.
2. Với EBS, kết quả phụ thuộc vào thiết lập Delete on termination. Ở mức mặc định: root volume bị xoá, còn data volume được giữ lại. Cụ thể hơn, EBS volume được attach thêm lúc launch, hoặc attach vào một instance đang chạy, vẫn tồn tại sau khi instance biến mất.

Ghép lại: trong phương án A, root device là instance store — nó mất, nhưng đó chỉ là hệ điều hành, dựng lại được từ AMI. Dữ liệu ứng dụng nằm trên EBS volume phụ, và EBS volume phụ thì mặc định không bị xoá khi terminate. Yêu cầu "data persistence với default settings" được thoả mà không cần chỉnh cờ nào.

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

B — AMI backed by EBS, default settings, không attach thêm gì. Đây là phương án nghe hợp lý nhất và cũng là bẫy chính. EBS đúng là lưu trữ bền, nhưng ở đây dữ liệu ứng dụng không có chỗ nào để nằm ngoài root volume. Mà root volume của AMI EBS-backed thì mặc định bị xoá khi terminate — đúng cái default settings mà đề bắt giữ nguyên. Chọn đúng loại lưu trữ nhưng đặt sai vị trí, nên vẫn mất dữ liệu.

C — AMI backed by instance store, default settings, không attach thêm gì. Sai nặng nhất trong bốn phương án. Dữ liệu nằm trên root device là instance store, và instance store thì bị xoá khi terminate — không có tuỳ chọn nào cứu được, vì tính ephemeral là bản chất của instance store chứ không phải một cờ cấu hình. Vừa sai loại lưu trữ, vừa sai vị trí.

D — AMI backed by EBS, attach thêm một instance store volume để chứa dữ liệu. Đây là phương án A bị đảo ngược, và nó hỏng ở hai chỗ độc lập:

• Dữ liệu ứng dụng đặt trên instance store volume → mất khi terminate.
• Root volume là EBS nên cũng bị xoá theo mặc định, tức là kể cả có ghi gì lên root thì cũng không cứu được.

Thêm một điểm kỹ thuật mà giải thích gốc nêu rõ: bạn không thể attach instance store volume như một data volume bổ sung cho instance có root device là EBS. Instance store phải được khai báo trong block device mapping tại thời điểm launch và phụ thuộc vào instance type, không phải thứ gắn vào tuỳ ý như EBS. Nên phương án này không chỉ mất dữ liệu mà còn không dựng được như mô tả.

📌 Điểm cần nhớ

• Nhớ hai mặc định của terminate, vì đề hay khoá bằng cụm "default settings": instance store → mất sạch; EBS root volume → bị xoá; EBS data volume (attach lúc launch hoặc attach sau) → được giữ lại.
• Phân biệt "loại lưu trữ" với "vị trí lưu trữ". Chọn EBS chưa đủ để dữ liệu bền — nếu dữ liệu nằm trên root volume thì mặc định vẫn bay. Câu hỏi kiểu này luôn kiểm tra cả hai trục cùng lúc.
• Instance store là ephemeral theo bản chất, không phải theo cấu hình. Không có cờ nào biến nó thành lưu trữ bền, và nó không attach được vào instance EBS-backed như một data volume rời.
• Đọc kỹ động từ vòng đời: stop và terminate cho kết quả khác nhau với instance store, còn terminate mới là mốc kích hoạt cờ Delete on termination của EBS.

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

Đề mô tả một hệ thống thu thập dữ liệu IoT từ thiết bị ngoài đồng bằng Amazon Kinesis Data Streams (KDS). Vấn đề được nêu là độ trễ trong tốc độ giao dữ liệu giữa producer và consumer.

Cụm từ quyết định đáp án là "Multiple consumer applications are using the incoming data streams" — nhiều ứng dụng consumer cùng đọc một stream. Đây chính là mô tả kinh điển của việc chia sẻ băng thông đọc trên mỗi shard: theo mặc định, thông lượng đọc ra của một shard được chia đều cho tất cả consumer đang đọc stream đó. Càng thêm consumer thì mỗi consumer càng nhận được ít băng thông hơn, và biểu hiện ra ngoài đúng như đề mô tả — dữ liệu tới chậm dần.

Cụm từ thứ hai cần để ý: đề nói "improving the performance", tức là cải thiện kiến trúc hiện có, chứ không phải thay thế nền tảng. Ba trong bốn phương án đều bắt đầu bằng "Swap out Amazon Kinesis Data Streams…" — thay hẳn dịch vụ. Đó là tín hiệu để loại nhóm phương án đó ngay từ vòng đọc đầu tiên.

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

C — Use Enhanced Fanout feature of Amazon Kinesis Data Streams.

Mặc định, thông lượng đọc của mỗi shard là dùng chung giữa mọi ứng dụng consumer. Với nhiều consumer song song, mỗi bên chỉ giành được một phần nhỏ của cùng một đường ống, nên độ trễ tăng lên — đúng triệu chứng trong đề.

Enhanced fan-out giải quyết đúng điểm nghẽn này: developer đăng ký consumer sử dụng enhanced fan-out, và mỗi consumer nhận riêng một đường ống thông lượng đọc trên mỗi shard, thay vì chia sẻ. Thông lượng riêng đó cũng tự mở rộng theo số shard của stream. Kết quả là các consumer không còn tranh nhau băng thông, và độ trễ producer → consumer giảm xuống.

Điểm quan trọng: giải pháp này giữ nguyên kiến trúc KDS hiện có, chỉ bật thêm một tính năng — đúng tinh thần câu hỏi "improving the performance", không phải thay dịch vụ.

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

A — Swap out KDS với Amazon SQS FIFO queues. SQS FIFO được thiết kế để bảo đảm mỗi thông điệp được xử lý đúng một lần, đúng thứ tự gửi. Mô hình của SQS là hàng đợi: thông điệp được một consumer lấy ra rồi biến mất khỏi hàng đợi. Trong khi đó, use-case ở đây là nhiều ứng dụng cùng đọc song song cùng một luồng dữ liệu — mỗi ứng dụng cần thấy toàn bộ bản ghi. SQS FIFO không phục vụ được mô hình đó. Ngoài ra, FIFO đánh đổi thông lượng để lấy thứ tự chặt chẽ, nên với bài toán đang thiếu thông lượng thì đây là hướng ngược.

B — Swap out KDS với Amazon SQS Standard queues. Standard queue cho thông lượng tối đa, thứ tự best-effort và giao ít nhất một lần. Nghe qua thì "thông lượng tối đa" có vẻ hợp với bài toán tốc độ, nên đây là phương án gây nhầm nhiều nhất. Nhưng nó hỏng ở đúng chỗ mà A hỏng: vẫn là mô hình hàng đợi, thông điệp bị một consumer tiêu thụ rồi mất, không hỗ trợ nhiều ứng dụng độc lập cùng đọc lại cùng một dòng dữ liệu. Thông lượng cao không cứu được việc mô hình tiêu thụ sai.

D — Swap out KDS với Amazon Kinesis Data Firehose. Firehose là dịch vụ nạp dữ liệu streaming vào các đích lưu trữ và phân tích, tự mở rộng theo thông lượng, có thể gộp lô, nén, biến đổi và mã hoá dữ liệu trước khi ghi. Nhưng Firehose chỉ ghi ra các đích được hỗ trợ (S3, Redshift, Elasticsearch/OpenSearch, Splunk) — không có khái niệm ứng dụng consumer đọc trực tiếp từ stream. Đó là việc của Kinesis Data Streams. Chuyển sang Firehose không phải là tối ưu hiệu năng, mà là phá bỏ luôn khả năng nhiều consumer đọc song song — thứ mà đề bài đang cần giữ.

📌 Điểm cần nhớ

• Thấy "nhiều consumer cùng đọc một Kinesis Data Stream" kèm than phiền về độ trễ / lag → nghĩ ngay tới enhanced fan-out: chuyển từ thông lượng đọc dùng chung mỗi shard sang đường ống riêng cho từng consumer.
• Kinesis Data Streams vs SQS: KDS cho phép nhiều ứng dụng độc lập đọc cùng một dòng dữ liệu và đọc lại được trong thời gian lưu giữ; SQS (cả Standard lẫn FIFO) là hàng đợi — thông điệp bị tiêu thụ rồi biến mất. Yêu cầu "multiple consumers on the same stream" gần như luôn loại SQS.
• Kinesis Data Streams vs Firehose: Firehose là đường nạp dữ liệu vào đích lưu trữ/phân tích, không phục vụ ứng dụng consumer đọc trực tiếp. Đề nào cần custom consumer xử lý real-time thì Firehose sai.
• Khi đề dùng động từ "improve / optimize" cho một kiến trúc đang chạy, ưu tiên phương án bật tính năng sẵn có của chính dịch vụ đó, cảnh giác với những phương án mở đầu bằng "swap out / replace" — chúng thường là bẫy đổi nền tảng không cần thiết.

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

Đề mô tả một công ty IoT cần chọn database trên AWS và liệt kê bốn ràng buộc chồng lên nhau:

1. Có Auto Scaling và highly available.
2. Xử lý được "any changes in data attributes over time" — tức là cấu trúc dữ liệu (số lượng, kiểu thuộc tính) từ thiết bị IoT sẽ đổi khi công ty cập nhật data feed.
3. Cung cấp được "a continuous stream with details of any changes to the underlying data" — một luồng liên tục mô tả mọi thay đổi trên dữ liệu bên dưới.

Ràng buộc số 1 gần như mọi phương án đều có ở mức độ nào đó, nên nó không phân biệt được gì. Hai cụm quyết định là "changes in data attributes over time" (đòi schema linh hoạt, không cần ALTER TABLE) và "output a continuous stream with details of any changes" (đòi change data capture sẵn có trong chính database). Chỉ một dịch vụ trong danh sách thoả cả hai cùng lúc.

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

Đáp án đúng theo tệp là C — Amazon DynamoDB.

• Schema linh hoạt: DynamoDB là key-value và document database. Ngoài primary key, các item trong cùng một table không bắt buộc có cùng bộ attribute. Khi công ty đổi data feed từ thiết bị IoT — thêm cảm biến mới, bỏ trường cũ — thì cứ ghi item với attribute mới, không cần thay đổi cấu trúc bảng. Đây chính là "handle any changes in data attributes over time".
• Luồng thay đổi liên tục: DynamoDB Streams là dòng thông tin có thứ tự về mọi thay đổi của item trong table. Bật stream trên table thì mỗi lần ứng dụng create/update/delete, DynamoDB ghi một stream record chứa primary key của item bị sửa; cấu hình được để record mang thêm ảnh "before" và "after" của item. Đúng nghĩa "continuous stream with details of any changes to the underlying data".
• Auto Scaling và HA: DynamoDB scale theo chiều ngang, mặc định nhân bản dữ liệu qua nhiều Availability Zone trong Region, và có thể tự điều chỉnh RCU/WCU bằng Auto Scaling. Đây là dịch vụ serverless — không phải provision, vá hay quản lý máy chủ.

Ba yêu cầu, một dịch vụ đáp ứng trọn vẹn.

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

A — Amazon Redshift. Redshift là data warehouse quy mô petabyte, dựng cho việc lưu trữ và phân tích tập dữ liệu lớn theo kiểu analytics. Đề bài không hỏi giải pháp warehousing mà hỏi database vận hành để nhận dữ liệu IoT. Redshift cũng là kho quan hệ theo cột với schema cố định, và bản thân nó không phải nguồn phát luồng thay đổi cho ứng dụng tiêu thụ.

B — Amazon Aurora. Đây là phương án dễ nhầm nhất vì Aurora thật sự có tính sẵn sàng cao và storage tự mở rộng, fault-tolerant, self-healing — nghe rất khớp với vế "Auto Scaling và highly available". Nhưng Aurora là relational database tương thích MySQL/PostgreSQL: thay đổi schema trên cơ sở dữ liệu quan hệ không đơn giản và rất khó duy trì khi yêu cầu về schema đổi liên tục — đúng vế mà đề bài nhấn mạnh. Nó hỏng ở ràng buộc "changes in data attributes over time", chứ không phải ở tính sẵn sàng.

D — Amazon RDS. RDS giúp dựng, vận hành và scale relational database trong cloud, tự động hoá provisioning phần cứng, cài đặt, patching, backup. Vấn đề giống hệt Aurora, thậm chí nặng hơn: mô hình quan hệ với schema cứng, đổi cấu trúc bảng khi data feed từ thiết bị thay đổi là việc tốn kém và khó bảo trì. Và cũng như hai phương án quan hệ kia, đề bài đòi một luồng thay đổi liên tục sẵn có ngay trong database — đó không phải thứ RDS được chọn để làm ở đây.

📌 Điểm cần nhớ

• Cụm "changes in data attributes over time" / "schema thay đổi thường xuyên" trong đề là tín hiệu loại bỏ nhóm relational (RDS, Aurora) và hướng về NoSQL kiểu key-value/document như DynamoDB.
• Cụm "stream of changes", "capture every modification", "before and after image" gắn thẳng với DynamoDB Streams — hãy nhớ nó là tính năng của chính table, chỉ cần bật lên.
• Phân biệt workload vận hành với workload phân tích: đề nói ingest dữ liệu từ thiết bị thì không chọn Redshift, vì Redshift là data warehouse dành cho phân tích tập dữ liệu lớn.
• Khi nhiều phương án cùng thoả một yêu cầu (ở đây là high availability và khả năng scale), yêu cầu đó không phải chỗ để quyết định — hãy tìm ràng buộc mà chỉ một phương án đáp ứng được.

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

Một startup mạng xã hội cần chạy database rollover hằng tuần cho MySQL: một script Python chạy khoảng 5 phút, mỗi tuần một lần, để đẩy dữ liệu tuần cũ ra khỏi database production nhưng vẫn giữ được khả năng truy cập.

Có ba cụm từ trong đề quyết định đáp án, và cần đọc cả ba cùng lúc:

• "serverless cron job" — đề nói thẳng đây phải là giải pháp serverless. Cụm này một mình đã loại hai phương án EC2.
• "typically takes about 5 minutes" — thời gian chạy ngắn, nằm gọn trong giới hạn thực thi của một Lambda function, nên không cần một môi trường chạy dài hạn.
• "MOST cost-efficient and reliable" — vừa rẻ vừa đáng tin cậy. Chữ "reliable" mới là thứ tách Spot Instance ra khỏi cuộc chơi, vì Spot rẻ nhất nhưng không bảo đảm chạy đúng lúc.

Công việc chỉ ngốn khoảng 5 phút mỗi tuần — tức máy sẽ ngồi không gần như toàn bộ thời gian. Đây chính là hình mẫu kinh điển của bài toán "trả tiền theo lần chạy" thay vì "nuôi một server thường trực".

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

A — Amazon EventBridge cron expression gọi AWS Lambda function.

AWS Lambda cho phép chạy code mà không phải cấp phát hay quản lý server, và chỉ tính tiền theo thời gian tính toán thực sự tiêu thụ. Với một job chạy 5 phút mỗi tuần, phần thời gian còn lại hoàn toàn không phát sinh chi phí — đúng nghĩa "MOST cost-efficient".

Phần lập lịch do Amazon EventBridge đảm nhiệm: EventBridge hỗ trợ cả rate expression lẫn cron expression, với tần suất mịn tới từng phút, nên biểu diễn "mỗi tuần một lần vào thời điểm X" là chuyện hiển nhiên. Cặp EventBridge + Lambda vì thế thoả cả ba ràng buộc của đề: serverless, đủ sức chạy script Python 5 phút, và lịch chạy do một dịch vụ managed bảo đảm chứ không phụ thuộc vào việc một máy nào đó có đang sống hay không.

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

B — EC2 Spot Instance + cron ở mức hệ điều hành. Đây là phương án gần đúng nhất về mặt giá: Spot Instance là capacity EC2 đang nhàn rỗi, bán với mức chiết khấu rất sâu so với On-Demand. Nhưng nó hỏng đúng ở chữ "reliable": Spot chỉ chạy khi còn capacity dư, nên không có gì bảo đảm job hằng tuần sẽ thực sự chạy trong khung giờ đã định — instance có thể bị thu hồi hoặc không được cấp đúng lúc, và cron của OS thì chỉ chạy khi máy đang sống. Ngoài ra nó vẫn là EC2, tức vẫn không phải serverless như đề yêu cầu.

C — EC2 On-Demand Instance + cron ở mức hệ điều hành. Về mặt kỹ thuật thì phương án này chạy được: một EC2 On-Demand hoàn toàn có thể thực thi script rollover qua cron của hệ điều hành, và độ tin cậy cũng ổn hơn Spot. Vấn đề là nó vi phạm thẳng yêu cầu "serverless" trong đề, đồng thời bắt bạn trả tiền cho một instance chạy suốt tuần chỉ để dùng 5 phút — trái ngược hẳn với "MOST cost-efficient".

D — Dùng tuỳ chọn time-based schedule ngay trong một AWS Glue job. Đây là bẫy tinh vi nhất, vì AWS Glue cũng là serverless và cũng có lịch chạy theo thời gian, nên nhìn qua thì thoả cụm "serverless cron job". Nó hỏng ở hai điểm khác: Glue là dịch vụ ETL fully managed, sinh ra để xử lý dữ liệu theo lô phục vụ analytics — chạy một script rollover database không phải là việc nó được thiết kế để làm. Và ngay cả khi ép nó chạy được, Glue vẫn đắt hơn Lambda cho một tác vụ ngắn kiểu này. Serverless là điều kiện cần, không phải điều kiện đủ.

📌 Điểm cần nhớ

• Job ngắn, thưa, chạy theo lịch → mặc định nghĩ tới EventBridge (cron/rate expression) + Lambda: đây là cặp đôi chuẩn cho "serverless cron" trên AWS, tính tiền theo thời gian chạy nên gần như bằng không khi ngồi không.
• Đề nhắc "serverless" là đã loại sạch mọi phương án EC2, bất kể On-Demand hay Spot — đừng mất công so giá giữa chúng nữa.
• Spot Instance rẻ nhưng không "reliable": capacity có thể không sẵn hoặc bị thu hồi, nên đừng chọn Spot cho công việc phải chạy đúng khung giờ đã hẹn.
• Serverless ≠ phù hợp. Glue serverless thật, nhưng nó là công cụ ETL theo lô; với script vận hành ngắn, Lambda vừa đúng vai vừa rẻ hơn. Khi hai phương án cùng serverless, hãy so tiếp đúng mục đích sử dụng và chi phí.