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

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

Đề mô tả một kho dữ liệu audit trên Amazon S3, dung lượng hàng trăm Terabyte, và hỏi storage class rẻ nhất phù hợp. Có ba cụm từ trong đề quyết định đáp án, phải đọc đủ cả ba:

• "accesses the audit reports only twice in a financial year" — tần suất truy cập cực thấp, một năm đúng hai lần. Đây là định nghĩa sách giáo khoa của "infrequent access".
• "should be available with milliseconds latency" — khi cần thì phải lấy ra ngay, không chấp nhận thời gian khôi phục tính bằng giờ. Cụm này loại thẳng nhóm archive.
• "AWS Step Functions... has failover and retry scenarios built into the solution" — đây là cụm từ tinh tế nhất, và nó tồn tại trong đề chỉ để xử lý điểm yếu duy nhất của đáp án đúng: availability thấp hơn S3 Standard. Có retry sẵn thì lần lấy dữ liệu hỏng sẽ được gọi lại tự động, nên availability thấp hơn không còn là rào cản.

Ba ràng buộc gộp lại: truy cập hiếm + latency mili giây + chấp nhận được availability thấp hơn → chọn lớp lưu trữ có giá GB/tháng thấp nhất trong nhóm truy cập tức thời.

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

A — Amazon S3 Standard-Infrequent Access (S3 Standard-IA)

S3 Standard-IA sinh ra đúng cho kịch bản "ít khi đụng tới nhưng khi đụng thì phải có ngay". Nó giữ nguyên độ bền, throughput và độ trễ mili giây của S3 Standard, nhưng đổi lấy giá lưu trữ mỗi GB thấp hơn, bù lại có phí lấy dữ liệu tính theo GB.

Với hàng trăm TB mà mỗi năm chỉ đọc hai lần, phép tính rất rõ: chi phí lưu trữ chạy liên tục 12 tháng trên khối dữ liệu khổng lồ, còn phí retrieval chỉ phát sinh hai lần. Giảm được đơn giá lưu trữ là giảm được phần chi phí chiếm gần như toàn bộ hoá đơn.

Điểm đánh đổi của Standard-IA là availability được thiết kế thấp hơn S3 Standard (bền vững thì như nhau — dữ liệu không mất, chỉ là khả năng phục vụ tại một thời điểm kém hơn). Đề đã chủ động vô hiệu hoá nhược điểm này bằng câu "failover and retry scenarios built into the solution": Step Functions gặp lỗi sẽ tự gọi lại cho tới khi lấy được dữ liệu.

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

B — Amazon S3 Glacier Deep Archive Về giá lưu trữ thì đây là lớp rẻ nhất, nên thoạt nhìn có vẻ khớp với chữ "MOST cost-effective". Nhưng nó là lớp archive: muốn đọc dữ liệu phải qua bước restore, thời gian khôi phục tính bằng giờ chứ không phải mili giây. Yêu cầu "available with milliseconds latency" loại nó ngay, bất kể rẻ đến đâu. Đây là bẫy kinh điển: rẻ nhất không phải lúc nào cũng là cost-effective nhất khi có ràng buộc kỹ thuật đi kèm.

C — Amazon S3 Standard Đúng về mặt kỹ thuật: latency mili giây, availability cao nhất, không có phí retrieval. Nhưng nó được định giá cho dữ liệu truy cập thường xuyên. Trả đơn giá lưu trữ cao nhất suốt cả năm cho khối dữ liệu hàng trăm TB mà mỗi năm chỉ mở ra hai lần là lãng phí trực tiếp. Câu hỏi hỏi lớp cost-effective nhất, không hỏi lớp an toàn nhất, nên Standard bị loại vì tiền chứ không vì tính năng.

D — Amazon S3 Intelligent-Tiering Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Intelligent-Tiering cũng cho latency mili giây, cũng tự đẩy object ít dùng xuống tầng rẻ hơn. Vấn đề: nó thu thêm phí giám sát và tự động hoá tính trên mỗi object, và giá trị nó mang lại là khỏi phải biết trước access pattern. Ở đây access pattern đã biết chắc chắn rồi — hai lần một năm, không mập mờ gì cả. Trả thêm phí monitoring để một cơ chế tự động khám phá ra điều mình đã biết là chi phí thừa. Đặt Standard-IA trực tiếp cho kết quả tương đương mà không gánh khoản phí đó.

📌 Điểm cần nhớ

• Chọn S3 storage class là bài toán ba biến: tần suất truy cập, yêu cầu độ trễ, và mức availability chấp nhận được. Đọc thiếu một biến là chọn sai.
• Cụm "milliseconds latency" hoặc "immediate/instant access" trong đề luôn loại nhóm cần restore như Glacier Deep Archive, kể cả khi đề nhấn mạnh chữ "cheapest".
• Access pattern đã biết rõ → chọn lớp cố định (Standard-IA). Access pattern không đoán được hoặc thay đổi → Intelligent-Tiering. Phí monitoring của Intelligent-Tiering chỉ đáng trả khi bạn thật sự không biết trước.
• Chi tiết về retry/failover trong kiến trúc không phải để trang trí: nó là tín hiệu cho phép bạn hạ tiêu chuẩn availability xuống để đổi lấy giá rẻ hơn.
• Standard-IA đánh đổi ở availability, không phải ở durability — dữ liệu vẫn bền như S3 Standard.

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

Đề mô tả một bảng staging trong DynamoDB chứa khoảng 1 triệu bản ghi, và mỗi đêm lúc 3:00 AM toàn bộ dữ liệu trong bảng đó phải bị xoá sạch rồi nạp lại từ đầu.

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

• "all ... records ... should be deleted" — xoá toàn bộ bảng, không phải xoá một tập con theo điều kiện. Không có bản ghi nào cần giữ lại.
• "efficient way to delete with minimal costs" — tiêu chí chấm không phải là "cách nào chạy được", mà là cách rẻ nhất và nhanh nhất.

Đây chính là ràng buộc phân biệt các phương án. Cả ba phương án A, B, D đều "xoá được dữ liệu", nhưng chúng khác nhau hoàn toàn về mô hình chi phí: trong DynamoDB, mọi thao tác đọc và ghi ở cấp item đều tiêu tốn capacity (RCU/WCU) và bị tính tiền, còn thao tác ở cấp table thì không tính theo số item. Khi đề nói "xoá hết" cộng với "chi phí tối thiểu", nó đang đẩy ta ra khỏi tầng item và lên tầng table.

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

A. Delete then re-create the table là đáp án đúng theo tệp.

Thao tác DeleteTable xoá bảng cùng toàn bộ item bên trong nó bằng một lời gọi duy nhất. Sau khi gửi yêu cầu, bảng chuyển sang trạng thái DELETING cho tới khi DynamoDB hoàn tất; sau đó ta gọi CreateTable để dựng lại bảng rỗng và nạp dữ liệu mới.

Điểm mấu chốt: DeleteTable là thao tác ở cấp control-plane, không phải là một triệu lệnh xoá item. Ta không phải đọc (scan) một triệu bản ghi để biết chúng là gì, cũng không phải phát sinh một triệu lượt ghi để xoá từng cái. Vì bảng ở đây là staging table — dữ liệu vốn được nạp lại hằng đêm — nên việc mất sạch nội dung cũ không gây vấn đề gì; đó đúng là điều nghiệp vụ mong muốn. Kết hợp lại, đây là cách xoá nhanh nhất và rẻ nhất trong danh sách.

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

B. Scan and delete items individually — Đây là phương án chạy được nhưng đắt và chậm nhất. Nó phải Scan toàn bảng để lấy khoá của từng item (tốn read capacity trên cả 1 triệu bản ghi), rồi phát ra 1 triệu lệnh DeleteItem riêng lẻ (tốn write capacity trên từng item). Với bảng cỡ này, Scan là thao tác rất chậm, và tổng chi phí đọc + ghi vượt xa một lời gọi DeleteTable. Nó vi phạm thẳng cả hai vế "efficient" và "minimal costs" của đề.

D. Scan and delete items using batch mode — Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Dùng BatchWriteItem gom nhiều lệnh xoá vào một request đúng là tốt hơn xoá từng cái một về mặt số lượng lời gọi mạng. Nhưng nó hỏng ở chỗ chi phí không hề giảm: batch chỉ gộp request lại, mỗi item bị xoá vẫn tiêu thụ write capacity riêng của nó, và ta vẫn phải Scan toàn bộ bảng trước để biết khoá cần xoá. Nghĩa là vẫn nguyên đủ 1 triệu lượt đọc và 1 triệu lượt ghi — chỉ đóng gói lại cho gọn. So với DeleteTable vốn không tính theo số item, nó vẫn đắt hơn hẳn.

C. Use the purge table option — Phương án này sai vì DynamoDB không có thao tác nào tên là "purge table". Đây là một lựa chọn bịa ra để làm nhiễu. Trong đề thi AWS, kiểu bẫy này khá phổ biến: một cái tên nghe rất hợp lý, mô tả đúng thứ bạn đang muốn làm, nhưng không tồn tại trong API thật.

📌 Điểm cần nhớ

• Khi đề DynamoDB nói xoá toàn bộ bảng kèm yêu cầu chi phí thấp, câu trả lời gần như luôn là DeleteTable + CreateTable, chứ không phải quét rồi xoá từng item.
• Phân biệt thao tác cấp table (DeleteTable, CreateTable) với thao tác cấp item (DeleteItem, BatchWriteItem): loại đầu không tính chi phí theo số bản ghi, loại sau thì có — đó là gốc rễ của khác biệt về chi phí.
• BatchWriteItem giảm số lời gọi, không giảm capacity tiêu thụ. Đừng nhầm "gom batch" với "rẻ hơn"; mỗi item trong batch vẫn tính write capacity riêng.
• Scan là thao tác tốn kém trên bảng lớn vì phải duyệt toàn bộ dữ liệu — thấy Scan xuất hiện trong một phương án tối ưu chi phí thì nên nghi ngờ ngay.
• Cảnh giác với các phương án mang tên nghe hợp lý nhưng không tồn tại trong API (ví dụ "purge table") — đây là dạng distractor thường gặp.

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

Kiến trúc trong đề xếp theo đúng một thứ tự: CloudFront distribution đứng ngoài cùng, phía sau là Application Load Balancer đóng vai custom origin, và cuối cùng mới tới các EC2 instance. Điểm mấu chốt: đội kỹ thuật đã gắn AWS WAF vào chính CloudFront distribution đó. Đề nói rõ có một địa chỉ IP cụ thể đang tấn công dồn dập để lấy dữ liệu nhạy cảm.

Cụm từ quyết định đáp án là "has also set up an AWS Web Application Firewall (AWS WAF) with Amazon CloudFront distribution" và "from a specific IP address". Hai chi tiết này đi cùng nhau: công cụ lọc theo IP đã nằm sẵn ở lớp ngoài cùng, và thứ cần chặn lại đúng là một IP đơn lẻ — nghĩa là câu hỏi không hỏi "nên dựng thêm gì", mà hỏi dùng cái đang có ở đúng lớp nào để chặn.

Một chi tiết nữa cần để ý: traffic tới EC2 không đi thẳng từ kẻ tấn công. Nó đi qua CloudFront rồi qua ALB, nên ở tầng EC2, địa chỉ nguồn mà instance nhìn thấy không còn là IP của kẻ tấn công nữa. Đây là lý do khiến mọi phương án đặt luật ở sát instance đều lệch hướng ngay từ nguyên lý, chưa cần bàn tới chuyện chúng có làm được kỹ thuật đó hay không.

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

Đáp án đúng theo tệp là D — Create an IP match condition in the AWS WAF to block the malicious IP address.

AWS WAF là web application firewall bảo vệ ứng dụng web và API khỏi các web exploit phổ biến, cho phép bạn viết security rule để chặn những khuôn mẫu tấn công quen thuộc (SQL injection, cross-site scripting) cũng như những khuôn mẫu traffic do chính bạn định nghĩa. Trong đó, khi muốn cho phép hoặc chặn request dựa trên IP nguồn, bạn tạo một hay nhiều IP match condition — mỗi condition liệt kê được rất nhiều địa chỉ IP hoặc dải IP (con số giới hạn cụ thể có thể đổi theo thời gian, nhưng quy mô đủ lớn cho tình huống này).

Đặt IP match condition vào web ACL của WAF gắn trên CloudFront nghĩa là request độc hại bị chặn ngay tại edge, trước khi chạm tới ALB và trước khi chạm tới EC2. Đây cũng là lớp duy nhất trong kiến trúc còn nhìn thấy IP thật của người gọi. Thêm vào đó, WAF đã được cài đặt sẵn — việc cần làm chỉ là thêm một condition, không phải dựng hạ tầng mới.

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

A — Deny rule trong Security Group của từng instance. Đây là phương án dễ chọn nhầm nhất vì Security Group đúng là thứ lọc traffic ở tầng instance. Nhưng nó hỏng ở một điểm căn bản: Security Group không có luật deny. Security Group chỉ chấp nhận rule kiểu allow, và mọi thứ không được allow thì mặc định bị chặn — không có cách nào diễn đạt "chặn riêng IP này, cho phép phần còn lại". Yêu cầu của đề không diễn đạt được bằng công cụ này.

B — Deny rule trong network ACL "associated with each of the instances". Network ACL đúng là có luật deny, nên thoạt nhìn nó khắc phục được điểm yếu của phương án A. Nhưng chỗ hỏng nằm ở vế sau: network ACL không gắn vào instance, nó gắn vào subnet trong VPC. Cách diễn đạt trong phương án mô tả một quan hệ không tồn tại, nên phương án bị loại.

C — Mở ticket nhờ AWS support xử lý IP độc hại. Bảo vệ ứng dụng của bạn là trách nhiệm của bạn, không phải của AWS. Bạn đã có sẵn công cụ để tự chặn, nên đây không phải việc để mở ticket. Phương án này cũng bỏ lỡ tính khẩn cấp: đợi bên thứ ba phản hồi trong khi cuộc tấn công đang diễn ra là để ngỏ cửa lâu hơn mức cần thiết.

📌 Điểm cần nhớ

• Security Group chỉ có allow, network ACL mới có deny. Bất kỳ câu nào yêu cầu "chặn riêng một IP" mà phương án đề nghị deny rule trong Security Group đều sai từ gốc.
• Network ACL gắn với subnet, Security Group gắn với instance/ENI. Phương án mô tả sai chỗ gắn kết là dấu hiệu loại trừ nhanh, không cần đọc tiếp.
• Chặn càng gần rìa càng tốt. Khi có CloudFront ở trước, IP thật của kẻ tấn công chỉ còn nhìn thấy được ở lớp edge; lọc ở tầng EC2 vừa muộn vừa nhìn sai địa chỉ nguồn.
• AWS WAF + IP match condition là công cụ chuẩn để chặn theo IP cho ứng dụng đứng sau CloudFront hoặc ALB; nếu đề nói WAF đã được cài sẵn, đó gần như luôn là gợi ý về đáp án.

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

Đề mô tả một công ty truyền thông cần đổi giải pháp sao lưu hằng đêm trên AWS. Chính sách mới đặt ra bốn ràng buộc:

1. Dữ liệu phải nằm bền vững ở ít nhất hai Region cách xa nhau về địa lý (Production và DR).
2. Quy trình sao lưu ở cả hai Region phải hoàn toàn tự động.
3. Ở Production Region, bản sao lưu phải khôi phục được ngay lập tức (restored immediately).
4. Ở DR Region, khôi phục trong vòng 24 giờ là đủ.

Và câu hỏi chốt lại: MOST cost-effective — rẻ nhất trong số các phương án vẫn thoả mọi ràng buộc trên.

Cụm từ quyết định nằm ở hai chỗ đối lập nhau: "available to be restored immediately for the Production Region" loại mọi thiết kế đặt lớp lưu trữ lạnh ở Production, còn "within 24 hours in the DR Region" cho phép — và vì đang tối ưu chi phí nên gần như bắt buộc — dùng Glacier Deep Archive ở DR. Ràng buộc thứ ba, tinh vi hơn, là chữ "immediately move this data to Amazon Glacier Deep Archive" trong lifecycle policy ở DR: vì dữ liệu chỉ nằm ở lớp trung gian đúng một khoảnh khắc rồi chuyển đi, lớp trung gian nào có ràng buộc thời gian lưu tối thiểu sẽ vẫn bị tính tiền cho cả quãng thời gian tối thiểu đó dù dữ liệu đã rời đi. Đó chính là chỗ phân biệt A với C — hai phương án chỉ khác nhau đúng một từ.

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

Đáp án đúng theo tệp là C: ghi backup vào S3 bucket A dùng S3 Standard ở Production Region, bật Cross-Region Replication (CRR) sang S3 bucket B cũng dùng S3 Standard ở DR Region, rồi đặt lifecycle policy ở DR để chuyển dữ liệu ngay sang Glacier Deep Archive.

• S3 Standard ở Production cho phép đọc lại ngay, đáp ứng "restore immediately".
• CRR là cơ chế sao chép tự động, bất đồng bộ giữa hai bucket ở hai Region khác nhau — đúng yêu cầu "fully automated" cho cả hai Region, không cần script tự viết.
• Glacier Deep Archive ở DR là lớp rẻ nhất, và độ trễ khôi phục của nó vẫn nằm gọn trong hạn 24 giờ mà đề cho phép.
• Mấu chốt chi phí: S3 Standard không có ràng buộc thời gian lưu tối thiểu, nên khi lifecycle policy đẩy dữ liệu sang Deep Archive ngay lập tức, ta gần như không trả gì cho quãng "quá cảnh" ở bucket B. Mặc định replica giữ nguyên storage class của nguồn, nhưng ở đây chính cái mặc định đó lại là lựa chọn rẻ nhất.

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

A — CRR sang S3 Standard-IA rồi lifecycle chuyển ngay sang Deep Archive. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Về mặt chức năng nó chạy được: Production vẫn Standard, DR vẫn kết thúc ở Deep Archive. Nó hỏng ở chỗ chi phí: S3 Standard-IA có ràng buộc thời lượng lưu tối thiểu (tính phí như thể đối tượng nằm đủ 30 ngày). Vì lifecycle policy chuyển dữ liệu đi ngay, mỗi đối tượng chỉ ở IA vài phút nhưng vẫn bị tính đủ phí tối thiểu — đắt hơn hẳn so với đi qua S3 Standard. Trực giác "IA rẻ hơn Standard" đúng cho dữ liệu nằm lâu, sai hoàn toàn cho dữ liệu chỉ quá cảnh.

B — Ghi thẳng vào Glacier Deep Archive ở Production rồi nhân bản sang Deep Archive ở DR. Đúng là rẻ nhất về đơn giá lưu trữ, nhưng nó vi phạm ràng buộc cứng của đề: Deep Archive có độ trễ first-byte tính bằng giờ, nên Production không thể khôi phục ngay lập tức. Một phương án rẻ mà không thoả yêu cầu thì bị loại trước khi xét tới giá — "cost-effective" luôn được đọc là "rẻ nhất trong số các phương án hợp lệ".

D — Ghi backup lên một EBS volume lớn gắn vào backup server, cron job hằng đêm chụp snapshot rồi copy sang DR Region. Hỏng ở hai mặt. Về độ bền: dữ liệu trên EBS volume chỉ được nhân bản trong phạm vi một Availability Zone, nên bản gốc không đạt mức bền vững mà chính sách đòi (snapshot thì nằm trên S3 và bền, nhưng volume thì không). Về chi phí: nó cõng thêm tiền một EBS volume dung lượng lớn cùng backup server, đồng thời không tối ưu lưu trữ ở DR vì dữ liệu nằm ở dạng snapshot chứ không được đẩy xuống Deep Archive. Cron job tự viết cũng là phần tự động hoá phải tự bảo trì, so với CRR là dịch vụ quản lý sẵn.

📌 Điểm cần nhớ

• Đọc kỹ hạn khôi phục của từng Region: "immediately" loại lớp archive, "trong 24 giờ" mở cửa cho Glacier Deep Archive. Yêu cầu về thời gian luôn được xét trước yêu cầu về giá.
• Lớp lưu trữ có thời lượng lưu tối thiểu (Standard-IA, các lớp archive) không hề rẻ khi dữ liệu chỉ quá cảnh. Nếu lifecycle policy chuyển đi ngay, hãy chọn S3 Standard làm trạm trung chuyển.
• Cross-Region Replication là câu trả lời chuẩn cho cặp yêu cầu "hai Region cách xa nhau" + "hoàn toàn tự động"; replica mặc định giữ nguyên storage class của nguồn nhưng có thể khai khác đi.
• Khi hai phương án chỉ khác nhau một từ, chính từ đó là toàn bộ câu hỏi — ở đây là storage class của bucket đích.

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

Bối cảnh: Kinesis Data Firehose ghi dữ liệu JSON thô vào một S3 bucket, đội dữ liệu dùng Apache Spark SQL trên Amazon EMR để phân tích, và EMR lấy metadata từ AWS Glue Data Catalog. Một AWS Glue crawler chạy mỗi 4 giờ để cập nhật schema trong catalog. Vấn đề: đôi khi đội phân tích thấy dữ liệu cũ.

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

• "runs every four hours" — nguyên nhân gốc là độ trễ giữa lúc dữ liệu mới rơi vào S3 và lúc catalog biết tới nó. Firehose ghi liên tục nhưng crawler chỉ chạy theo lịch, nên trong khoảng giữa hai lần chạy, Spark SQL đọc catalog vẫn thấy trạng thái cũ. Vì vậy hướng đúng phải là bỏ lịch định kỳ, chuyển sang chạy theo sự kiện.
• "uses Apache Spark SQL to analyze this data via Amazon EMR" — đây là ràng buộc về công cụ phân tích. Bất kỳ phương án nào thay công cụ khác thay vì sửa vấn đề catalog đều lệch đề.

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

B — Gọi Glue crawler bằng một AWS Lambda function được kích hoạt bởi S3 event notification S3:ObjectCreated:* trên bucket.

Glue crawler là chương trình kết nối tới data store (ở đây là S3), chạy qua danh sách classifier để xác định schema của dữ liệu, rồi tạo/cập nhật bảng metadata trong Glue Data Catalog. Crawler gọi được theo yêu cầu (on-demand), không nhất thiết phải chạy theo lịch.

S3 phát event notification S3:ObjectCreated:* mỗi khi Firehose ghi xong một đối tượng mới. Dùng event đó kích hoạt một Lambda function, và Lambda gọi crawler, ta được chuỗi: dữ liệu mới đến → crawler chạy ngay → catalog cập nhật → Spark SQL trên EMR đọc được dữ liệu hiện tại. Cách này loại bỏ hẳn khoảng trễ theo lịch, vì việc cập nhật catalog bám theo chính sự xuất hiện của dữ liệu chứ không bám theo đồng hồ. Đây cũng là kiến trúc data lake serverless điển hình mà AWS khuyến nghị: dùng trigger cho Data Catalog và các ETL job.

Quan trọng: phương án này giữ nguyên Spark SQL trên EMR — nó sửa đúng chỗ hỏng (độ mới của catalog) mà không đụng tới yêu cầu về công cụ phân tích.

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

A — CloudWatch Events với biểu thức rate(5 minutes) để chạy Glue crawler mỗi 5 phút. Đây là phương án gần đúng nhất về mặt ý tưởng (rút ngắn chu kỳ), nhưng hỏng ở khâu kỹ thuật: CloudWatch Events không hỗ trợ Glue crawler làm kiểu đích (destination type) để gọi trực tiếp. Không thể trỏ thẳng một rule vào crawler như cách trỏ vào Lambda. Đó chính là lý do phương án B phải chèn Lambda vào giữa — Lambda là thứ gọi được crawler. Ngoài ra, kể cả nếu chạy được, 5 phút vẫn là lịch cố định, vẫn còn khoảng trễ, không đảm bảo "luôn có dữ liệu hiện tại".

C — Đổi lịch chạy crawler từ 4 giờ xuống 1 phút. Sai vì độ chính xác tối thiểu của lịch cho Glue crawler là 5 phút, không đặt được 1 phút. Phương án này không cấu hình nổi. Và giống A, nó vẫn là tư duy "rút ngắn chu kỳ" — chỉ làm cửa sổ dữ liệu cũ nhỏ đi chứ không đóng lại, đồng thời crawl liên tục trên toàn bucket là kiểu chạy tốn kém, lãng phí khi phần lớn lần chạy không có gì mới.

D — Dùng Amazon Athena để phân tích trực tiếp dữ liệu hiện tại trong S3. Đây là phương án đổi công cụ chứ không sửa vấn đề. Đề đã nêu rõ việc phân tích phải làm bằng Apache Spark SQL trên Amazon EMR; thay bằng Athena là bỏ qua ràng buộc của bài toán. Thêm nữa, Athena cũng dùng Glue Data Catalog làm metastore, nên nếu catalog vẫn cũ thì đổi sang Athena chưa chắc giải quyết được gì.

📌 Điểm cần nhớ

• Khi triệu chứng là "đôi khi thấy dữ liệu cũ" với kiến trúc crawler chạy theo lịch, nguyên nhân gần như luôn là độ trễ của lịch. Lời giải đúng thường là chuyển từ schedule sang event-driven, chứ không phải rút ngắn chu kỳ.
• Mẫu kiến trúc cần thuộc: S3 ObjectCreated:* event notification → Lambda → gọi Glue crawler on-demand. Lambda ở đây không thừa — nó là cầu nối vì không phải dịch vụ nào cũng gọi crawler trực tiếp được.
• Glue crawler có giới hạn về độ chính xác lịch chạy (không xuống được mức từng phút), nên mọi phương án đề xuất lịch siêu dày cần bị nghi ngờ ngay.
• Đọc kỹ ràng buộc về công cụ phân tích đã chốt trong đề (ở đây là Spark SQL trên EMR). Phương án đề nghị thay bằng dịch vụ khác thường là distractor, dù dịch vụ đó tự nó hợp lý.

🧩 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 phân tích trên Amazon Redshift. Cụm có hai bảng lớn hàng triệu dòng (orders và product — đóng vai trò fact và dimension lớn) cùng vài bảng nhỏ chứa dữ liệu hỗ trợ. Câu hỏi: khi lập kế hoạch chọn distribution style, đâu là những điểm mấu chốt cần cân nhắc? (Chọn hai)

Cụm từ quyết định nằm ở mục tiêu được nêu ngay trong đề: "to optimize query speed" — tối ưu tốc độ truy vấn. Trong Redshift, thứ giết chết tốc độ truy vấn nhiều nhất khi join là redistribution: dữ liệu phải chạy qua mạng giữa các compute node ngay lúc truy vấn chạy. Vậy nên mọi phương án đúng đều phải xoay quanh nguyên tắc giảm thiểu data movement, tức đặt sẵn dữ liệu ở đúng nơi cần có trước khi truy vấn chạy. Chi tiết "a few small tables with supporting data" cũng là gợi ý trực tiếp cho nhóm bảng nên cân nhắc ALL distribution.

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

E — Phân bố dữ liệu sao cho các dòng tham gia join đã nằm sẵn cùng node với dòng đối ứng ở bảng kia (collocation). Đây là mục tiêu số một của việc chọn distribution style. Khi các dòng tham gia join hoặc aggregate đã được collocate trên cùng node slice, query optimizer không cần redistribute nhiều dữ liệu lúc truy vấn chạy. Ít dữ liệu chạy qua mạng đồng nghĩa với truy vấn nhanh hơn — đúng yêu cầu "optimize query speed" của đề.

C — Nếu một dimension table không thể collocate với fact table hoặc các bảng join quan trọng khác, dùng ALL distribution cho bảng đó. Fact table chỉ có một distribution key, nên luôn tồn tại những dimension table không cách nào collocate được theo key. Giải pháp được AWS khuyến nghị là chuyển những bảng đó sang ALL distribution: một bản sao toàn bộ bảng được đặt trên mọi node, nhờ đó join luôn có sẵn dữ liệu tại chỗ, không cần redistribute. Đổi lại, ALL làm tăng nhu cầu lưu trữ, tăng thời gian load và chi phí bảo trì — vì vậy nó là lựa chọn cân nhắc cho bảng nhỏ, không phải cho bảng hàng triệu dòng.

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

A — "Choose a column with low cardinality in the filtered result set". Ngược hẳn với khuyến nghị: nên chọn cột có high cardinality trong tập kết quả đã lọc. Đây là phương án dễ nhầm nhất vì nó có đúng một nửa ý — cardinality thật sự là tiêu chí chọn dist key, nhưng chiều của nó bị đảo. Ví dụ trong tài liệu AWS: phân bố bảng sales theo cột date thường cho phân bố khá đều, nhưng nếu bạn hay lọc theo một khoảng ngày hẹp thì phần lớn dòng còn lại chỉ nằm trên một nhóm slice giới hạn, gây skew — một số slice làm việc nặng trong khi số còn lại rảnh rỗi.

D — "A fact table with multiple distribution keys is useful when multiple dimension tables have to be joined to it". Sai ở tiền đề kỹ thuật: fact table chỉ có thể có đúng một distribution key. Không tồn tại khái niệm "multiple distribution keys" để mà hữu ích. Bảng nào join theo key khác thì đơn giản là không collocate với fact table, và cách xử lý đúng là chọn một dimension để collocate — dựa trên tần suất join và kích thước các dòng tham gia join — rồi cân nhắc ALL cho phần còn lại (chính là phương án C).

B — "Small Dimension tables should be marked to use KEY distribution style, which will cause them to be replicated to each physical node". Phương án này ghép sai style với hành vi. Với KEY distribution, các dòng được phân bố theo giá trị của một cột; leader node đặt các giá trị khớp nhau lên cùng một node slice — đó là cơ chế collocate, không phải nhân bản. Việc "sao chép toàn bộ bảng sang mọi node" là hành vi của ALL distribution. Bảng nhỏ đúng là ứng viên tốt để nhân bản, nhưng phải khai ALL chứ không phải KEY, nên câu này sai ở chính phần định nghĩa.

📌 Điểm cần nhớ

• Mục tiêu duy nhất của việc chọn distribution style là giảm data movement lúc truy vấn chạy — đặt dữ liệu sẵn ở nơi nó cần có, thay vì để optimizer redistribute.
• Phân biệt dứt khoát ba style: KEY = phân bố theo giá trị một cột để collocate; ALL = nhân bản toàn bộ bảng lên mọi node; EVEN = chia đều theo vòng, dùng khi bảng không tham gia join theo key rõ ràng.
• Một bảng chỉ có một distribution key. Khi nhiều dimension cùng join vào fact table, hãy chọn một dimension để collocate theo KEY và cân nhắc ALL cho các dimension nhỏ còn lại.
• Cột làm dist key nên có high cardinality trên tập kết quả đã lọc, để tránh skew dồn tải vào vài slice.
• ALL không miễn phí: tốn thêm dung lượng trên mọi node, load chậm hơn và bảo trì nặng hơn — chỉ đáng dùng với bảng nhỏ, ít thay đổi.

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

Đề mô tả một công ty game cần dựng live leaderboard (bảng xếp hạng thời gian thực), và liệt kê ba yêu cầu: high availability, low latency, real-time processing. Nhưng cụm từ quyết định nằm ngay câu đầu tiên, trước cả danh sách yêu cầu:

"evaluating multiple in-memory data stores"

Đây mới là ràng buộc phân loại. Cả năm phương án đều lặp lại y hệt một mệnh đề "as it meets the in-memory, high availability, low latency requirements" — nghĩa là mọi phương án đều tự nhận mình là in-memory. Việc của người làm bài là kiểm chứng lời tự nhận đó: dịch vụ nào thực sự phục vụ dữ liệu từ bộ nhớ, dịch vụ nào là database lưu trên đĩa.

Nếu bỏ qua chữ "in-memory" và chỉ đọc "high availability, low latency", thì DynamoDB và Aurora đều thoả — và câu hỏi trở nên không có đáp án phân biệt được. Chính vì vậy "in-memory" là bộ lọc duy nhất có giá trị ở đây. Đề yêu cầu chọn hai, nên cần đúng hai dịch vụ có tầng in-memory thật sự.

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

C — ElastiCache Redis. Đây là in-memory data store đúng nghĩa: dữ liệu nằm trong RAM, độ trễ ở mức dưới mili-giây. Redis còn có sẵn kiểu dữ liệu sorted set — cấu trúc sinh ra cho bài toán xếp hạng: chèn điểm và đọc top-N theo thứ tự mà không phải sort lại toàn bộ. Gaming leaderboard là một trong những use case được AWS nêu thẳng cho ElastiCache for Redis, bên cạnh caching, chat/messaging, geospatial, real-time analytics, session store. Về high availability, ElastiCache for Redis chạy được ở dạng cụm có replica và failover, nên đáp ứng luôn vế còn lại.

D — DynamoDB với DynamoDB Accelerator (DAX). DynamoDB một mình là key-value/document database với hiệu năng mili-giây một chữ số, nhưng không phải in-memory. Điểm mấu chốt là DAX: đây là caching service tương thích DynamoDB, đặt một tầng in-memory trước bảng DynamoDB. Chính DAX kéo phương án này qua được bộ lọc "in-memory" mà DynamoDB trần không qua nổi. Kết hợp lại, DynamoDB + DAX vừa có tính bền vững và khả năng sẵn sàng của DynamoDB, vừa có tốc độ đọc từ bộ nhớ của DAX.

Hai phương án này khác nhau ở chỗ: C là in-memory store dùng làm nguồn dữ liệu chính, D là database bền vững cộng thêm tầng cache in-memory. Đề chỉ hỏi giải pháp nào đáp ứng yêu cầu, không hỏi giải pháp nào rẻ hơn hay đơn giản hơn, nên cả hai đều được tính đúng.

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

A — DynamoDB (không có DAX). Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. DynamoDB thật sự có high availability, thật sự có low latency ở mức mili-giây một chữ số, và mô hình key-value hoàn toàn hợp với leaderboard. Chỗ nó hỏng: DynamoDB không phải in-memory database. Nó lưu dữ liệu trên đĩa và có độ bền cao; muốn có in-memory thì phải gắn thêm DAX — và đó chính là phương án D. Việc đề tách A và D thành hai lựa chọn riêng là dấu hiệu rất rõ rằng chữ "in-memory" mới là thứ đang được kiểm tra.

B — RDS Aurora. Aurora là relational database tương thích MySQL và PostgreSQL, có kiến trúc lưu trữ phân tán, chịu lỗi và tự phục hồi, tự mở rộng dung lượng. Nó mạnh về availability, nhưng vẫn là database trên đĩa chứ không phải in-memory. Ngoài ra mô hình quan hệ cũng không phải lựa chọn tự nhiên cho leaderboard cập nhật liên tục — nhưng lý do loại bỏ chính thức vẫn là vế in-memory.

E — AWS Neptune. Neptune là graph database được quản lý, dùng cho dữ liệu có quan hệ chằng chịt (mạng xã hội, phát hiện gian lận, recommendation dựa trên đồ thị). Nó nhanh và tin cậy, nhưng không phải in-memory, và mô hình đồ thị cũng không phải thứ bài toán xếp hạng theo điểm số cần tới. Đây là phương án dễ loại nhất trong bốn phương án sai.

📌 Điểm cần nhớ

• Khi mọi phương án đều lặp lại cùng một câu biện minh ("as it meets the in-memory, high availability, low latency requirements"), câu biện minh đó chính là danh sách tiêu chí cần kiểm chứng, không phải thông tin cho sẵn. Đừng tin lời tự nhận của phương án.
• Phân biệt cho rõ: ElastiCache là in-memory data store; DAX là tầng cache in-memory riêng cho DynamoDB; DynamoDB, Aurora, Neptune đều là database lưu trên đĩa, dù độ trễ của chúng có thấp.
• Khi thấy cặp phương án "dịch vụ X" và "dịch vụ X + cache", gần như chắc chắn đề đang kiểm tra một yêu cầu mà chỉ tầng cache mới đáp ứng được — hãy đi tìm yêu cầu đó trong đề.
• Gaming leaderboard là use case kinh điển của Redis nhờ kiểu dữ liệu sorted set; gặp từ khoá "leaderboard", "real-time ranking", "session store" thì nghĩ tới ElastiCache for Redis trước.
• Đọc kỹ "(Select two)": chọn thiếu hoặc chọn thừa đều bị tính sai, và ở câu này hai đáp án đúng đến từ hai hướng kiến trúc khác nhau chứ không phải hai biến thể của cùng một hướng.

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

Đề mô tả một bảng DynamoDB được provisioning thủ công, và yêu cầu tính số Read Capacity Units (RCUs) cần thiết cho một khối lượng đọc cụ thể.

Ba cụm từ trong đề quyết định toàn bộ phép tính, thiếu bất kỳ cụm nào là ra số khác:

• "10 ... reads per second" — tần suất đọc mỗi giây.
• "strongly consistent" — kiểu nhất quán. Đây là cụm phân biệt quan trọng nhất: cùng một khối lượng, strongly consistent read tốn gấp đôi eventually consistent read.
• "8 KB in size each" — kích thước mỗi item, dùng để tính số đơn vị dung lượng cho một lần đọc.

Đề đang hỏi về read, không phải write, nên không đụng gì tới WCU. Và vì bảng ở chế độ provisioned nên con số này là thứ phải khai báo trước, chứ không phải để DynamoDB tự co giãn.

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

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

Định nghĩa của một RCU trong DynamoDB: một RCU cho phép một strongly consistent read mỗi giây với item tối đa 4 KB, hoặc hai eventually consistent read mỗi giây với cùng cỡ item đó. Item lớn hơn 4 KB thì tiêu tốn thêm RCU, làm tròn lên theo bội số 4 KB.

Tính theo hai bước:

1. Số RCU cho mỗi lần đọc: 8 KB / 4 KB = 2 RCU cho một item, vì đây là strongly consistent read nên không có ưu đãi chia đôi.
2. Nhân với tần suất: 2 × 10 reads/second = 20 RCU.

Vậy bảng cần 20 RCU.

Lưu ý cách kiểm tra nhanh: nếu đề đổi thành eventually consistent, con số sẽ chia đôi còn 10 — chính vì thế cụm "strongly consistent" là chỗ ra đề gài bẫy.

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

• A — 10: Đây là kết quả của việc tính đúng cỡ item (8 KB → 2 đơn vị) nhưng rồi áp nhầm luật eventually consistent, tức lấy 2 × 10 / 2 = 10. Cách chia đôi đó chỉ hợp lệ khi đề cho phép đọc nhất quán cuối cùng; ở đây đề ghi rõ strongly consistent nên không được chia. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Một kiểu sai khác cũng ra 10: quên hẳn kích thước item, lấy thẳng 10 reads/second × 1 RCU — cũng sai vì item 8 KB vượt ngưỡng 4 KB.

• B — 40: Nhân dư một lần hệ số 2. Người làm bài thường ra con số này khi vừa nhân 2 vì item 8 KB, lại nhân thêm 2 lần nữa vì tưởng strongly consistent read "tốn gấp đôi" so với mức cơ sở. Thực tế strongly consistent read chính là mức cơ sở của định nghĩa RCU; eventually consistent mới là loại được ưu đãi gấp đôi thông lượng. Hiểu ngược chiều quan hệ này là ra 40.

• D — 5: Chia đôi hai lần, hoặc lấy 10 / 2 rồi bỏ qua kích thước item. Con số này thấp hơn nhu cầu thật tới bốn lần — nếu khai đúng bằng 5 RCU thì lượng đọc thực tế sẽ vượt hạn mức và request bị throttling. Không có cách diễn giải nào của đề dẫn tới 5.

📌 Điểm cần nhớ

• Đơn vị gốc cần thuộc: 1 RCU = 1 strongly consistent read/giây cho item tới 4 KB, hoặc 2 eventually consistent read/giây. Với write, 1 WCU = 1 write/giây cho item tới 1 KB — hai mốc kích thước khác nhau, đừng lẫn.
• Công thức ba bước cho mọi câu dạng này: làm tròn lên kích thước item / 4 KB → nhân số read mỗi giây → chia 2 chỉ khi đề nói eventually consistent.
• Strongly consistent là mức cơ sở, không phải mức bị phạt. Eventually consistent mới là loại nhận được gấp đôi thông lượng trên cùng một RCU. Nhớ đúng chiều này loại được ngay các phương án nhân dư như 40.
• Luôn làm tròn lên, không làm tròn xuống: item 5 KB vẫn tốn 2 RCU cho một strongly consistent read, chứ không phải 1,25.
• Đọc kỹ đề xem đang hỏi read hay write, và có phải chế độ provisioned hay không — cách tính RCU/WCU chỉ có ý nghĩa với bảng provisioned capacity.

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

Đề mô tả một nhóm phát triển đặt các Amazon EC2 instance trong private subnet và muốn dùng VPC endpoint để truy cập một số dịch vụ AWS một cách riêng tư. Nhưng ràng buộc thật sự nằm ở cụm từ:

"the two AWS services that support Gateway Endpoints"

Đây mới là chỗ quyết định. Đề không hỏi "dịch vụ nào truy cập được qua VPC endpoint" — nếu hỏi vậy thì cả năm phương án đều đúng, vì SNS, SQS, Kinesis đều có VPC endpoint. Đề hỏi hẹp hơn một bậc: dịch vụ nào hỗ trợ loại Gateway Endpoint, chứ không phải Interface Endpoint.

VPC endpoint có hai loại, và chúng khác nhau về bản chất kỹ thuật:

• Gateway Endpoint: là một gateway mà bạn khai làm target cho một route trong route table của subnet. Không có ENI, không tốn IP trong subnet.
• Interface Endpoint (AWS PrivateLink): là một Elastic Network Interface mang địa chỉ IP riêng lấy từ dải IP của subnet, đóng vai trò điểm vào cho traffic tới dịch vụ.

Chi tiết "private subnet" trong đề chỉ là bối cảnh giải thích vì sao họ cần endpoint (không có internet gateway, NAT device, VPN hay Direct Connect), chứ không phải yếu tố phân biệt đáp án. Đọc lướt qua chữ "Gateway" là sẽ chọn nhầm.

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

Đáp án đúng theo tệp là A (Amazon DynamoDB) và D (Amazon S3) — đúng hai dịch vụ như đề yêu cầu.

Đây là danh sách dịch vụ hỗ trợ Gateway Endpoint theo tài liệu AWS về VPC endpoint: Amazon S3 và Amazon DynamoDB. Cơ chế hoạt động: bạn tạo Gateway Endpoint rồi thêm một route trong route table của private subnet, trỏ prefix list của dịch vụ đó về endpoint. EC2 instance trong private subnet gọi tới S3 hoặc DynamoDB sẽ đi theo route này, traffic không rời khỏi mạng của Amazon, và instance không cần public IP.

Riêng Amazon S3 là trường hợp đặc biệt: nó hỗ trợ cả hai loại — gateway endpoint và interface endpoint. Interface endpoint cho S3 mở rộng thêm khả năng của gateway endpoint bằng cách dùng private IP để định tuyến request tới S3 từ trong VPC, từ on-premises, hoặc từ VPC ở Region khác qua VPC peering / AWS Transit Gateway. Nhưng vì đề chỉ hỏi "có hỗ trợ Gateway Endpoint hay không", S3 vẫn nằm trong đáp án.

Endpoint là thiết bị ảo, được scale ngang, dự phòng và có tính sẵn sàng cao, nên không tạo thêm rủi ro sẵn sàng hay nút thắt băng thông cho traffic trong VPC.

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

B. Amazon SNS — SNS có hỗ trợ VPC endpoint, nhưng chỉ ở dạng Interface Endpoint (AWS PrivateLink). Muốn EC2 trong private subnet publish message tới SNS mà không qua internet, bạn tạo một ENI trong subnet chứ không thêm route vào route table. Đây là phương án gần đúng theo nghĩa "vẫn giải quyết được bài toán private subnet" — nó chỉ sai đúng ở chỗ loại endpoint mà đề chỉ định.

C. Amazon Kinesis — cùng một lý do. Kinesis truy cập riêng tư qua Interface Endpoint, không phải Gateway Endpoint. Không có route table entry nào cho Kinesis.

E. Amazon SQS — cũng chỉ hỗ trợ Interface Endpoint. SQS hay bị chọn nhầm vì nó đi cặp với SNS trong rất nhiều kiến trúc và người học quen nghĩ "dịch vụ AWS phổ biến thì chắc có gateway endpoint". Phổ biến không liên quan gì tới loại endpoint.

Điểm chung của cả ba phương án sai: chúng đều truy cập được từ private subnet một cách riêng tư, đều không cần internet gateway hay NAT — nên nếu chỉ đọc phần bối cảnh mà bỏ qua chữ "Gateway", cả năm phương án trông đều hợp lý.

📌 Điểm cần nhớ

• Chỉ Amazon S3 và Amazon DynamoDB hỗ trợ Gateway Endpoint. Mọi dịch vụ khác trong đề thi mà hỏi về VPC endpoint đều là Interface Endpoint (PrivateLink). Đây là danh sách ngắn, nên học thuộc rẻ hơn suy luận.
• Phân biệt hai loại bằng cơ chế: Gateway Endpoint = một entry trong route table, không tốn IP subnet; Interface Endpoint = một ENI mang private IP lấy từ dải IP của subnet.
• S3 hỗ trợ cả hai loại. Chọn interface endpoint cho S3 khi cần truy cập từ on-premises hoặc từ VPC ở Region khác qua VPC peering / Transit Gateway — gateway endpoint không phục vụ các đường đó.
• Đọc kỹ từ khoá loại endpoint trong đề. Câu hỏi "truy cập riêng tư từ private subnet" và câu hỏi "hỗ trợ Gateway Endpoint" có tập đáp án hoàn toàn khác nhau, dù bối cảnh mô tả giống hệt.

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

Đề mô tả một data lake trên Amazon S3 chia làm hai vùng: raw zone (dữ liệu nguồn vừa đổ về) và curated zone (dữ liệu đã qua AWS Glue ETL). Mỗi vùng phình thêm 2 TB mỗi ngày, và câu hỏi yêu cầu chọn hai biện pháp tối ưu chi phí lưu trữ.

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

1. "the source data needs to be kept for a minimum of 5 years" — dữ liệu raw zone bị ràng buộc tuân thủ, không được xoá. Cụm này giết ngay mọi phương án xoá dữ liệu.
2. "The data engineering team runs ad-hoc queries only on the data in the curated zone using Athena" — chữ only là bản lề. Raw zone không ai truy vấn → có thể đẩy xuống tầng lưu trữ lạnh nhất. Curated zone thì ngược lại: phải luôn sẵn sàng cho Athena → không được archive.
3. "MOST cost-optimal" — với curated zone, khi không thể đổi storage class thì đòn bẩy chi phí còn lại là giảm số byte phải lưu, tức là định dạng ghi ra.

Nói gọn: raw zone giải bằng storage class, curated zone giải bằng định dạng file. Hai vùng, hai công cụ khác nhau.

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

E — Lifecycle policy chuyển raw zone sang Glacier Deep Archive sau 1 ngày. S3 Lifecycle là tập luật để S3 tự động chuyển đối tượng sang storage class rẻ hơn (hoặc hết hạn) theo tuổi của đối tượng. Raw zone thoả đúng hồ sơ của dữ liệu archive: bắt buộc giữ lâu vì compliance, nhưng không phục vụ truy vấn nào. Glacier Deep Archive là tầng rẻ nhất trong họ S3, đánh đổi bằng thời gian khôi phục dài — đánh đổi đó chấp nhận được vì dữ liệu này chỉ nằm đó để chứng minh tuân thủ. Chuyển sau 1 ngày nghĩa là dữ liệu vẫn còn ở tầng nóng đủ lâu để Glue ETL job đọc và xử lý sang curated zone, rồi mới hạ xuống tầng lạnh.

B — Glue ETL job ghi curated zone bằng định dạng nén. Curated zone bị Athena truy vấn thường xuyên nên phải nằm ở tầng truy cập tức thì. Đòn bẩy chi phí duy nhất còn lại là dung lượng thực tế. Ghi ra bằng định dạng nén giảm đáng kể số byte lưu trữ so với text thô, và vì Athena tính tiền theo lượng dữ liệu quét, ít byte hơn còn kéo theo chi phí truy vấn thấp hơn — nén giúp cả hai đầu.

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

A — Glue ETL ghi curated zone bằng CSV. Đây là phương án gần đúng nhất và cũng là bẫy trực tiếp của B: nó đúng chỗ (curated zone, dùng Glue), nhưng sai ở lựa chọn định dạng. CSV là text thô, không nén — cùng một tập dữ liệu sẽ chiếm nhiều dung lượng hơn hẳn so với bản nén. Đề hỏi MOST cost-optimal, mà A và B là hai lựa chọn loại trừ nhau trên cùng một trục; B tốt hơn nên A bị loại.

C — Lambda xoá dữ liệu raw zone sau 1 ngày. Đây là phương án rẻ nhất về chi phí lưu trữ, và chính vì thế nó là bẫy nếu đọc lướt qua ràng buộc. Nhưng đề nói rõ dữ liệu nguồn phải giữ tối thiểu 5 năm vì lý do compliance. Xoá sau 1 ngày là vi phạm trực tiếp yêu cầu bắt buộc. Trong đề thi, một phương án phá vỡ ràng buộc compliance thì bị loại ngay bất kể nó rẻ đến đâu — tối ưu chi phí chỉ được xét trong phạm vi các phương án còn hợp lệ.

D — Lifecycle chuyển curated zone sang Glacier Deep Archive sau 1 ngày. Đúng công cụ nhưng nhắm sai vùng dữ liệu. Curated zone là nơi đội kỹ thuật chạy ad-hoc query bằng Athena; đẩy nó xuống Glacier Deep Archive sau 1 ngày là làm hỏng chính chức năng nghiệp vụ của data lake — dữ liệu ở tầng archive không truy vấn trực tiếp được, phải khôi phục trước, mà quá trình đó mất thời gian và phát sinh chi phí retrieval. Rẻ hơn về lưu trữ nhưng phá vỡ yêu cầu sử dụng, nên không phải là giải pháp.

📌 Điểm cần nhớ

• Đọc mẫu hình truy cập trước khi chọn storage class. Dữ liệu không ai đọc → hạ tầng lạnh bằng S3 Lifecycle. Dữ liệu phục vụ Athena → giữ ở tầng truy cập tức thì, tối ưu bằng cách khác.
• Ràng buộc compliance là bộ lọc cứng, không phải yếu tố cân đo. Thấy "must be retained for N years" là loại ngay mọi phương án xoá dữ liệu, kể cả khi đề nhấn mạnh "cost-optimal".
• Với dữ liệu phải nằm ở tầng nóng, đòn bẩy chi phí là định dạng. Nén làm giảm cả chi phí lưu trữ S3 lẫn chi phí Athena, vì Athena tính tiền theo lượng dữ liệu quét.
• Câu "Select two" thường ghép một biện pháp cho mỗi vùng dữ liệu. Nếu hai phương án bạn chọn cùng tác động lên một vùng, hãy kiểm tra lại — nhiều khả năng bạn bỏ sót vùng còn lại.