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

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

Đề mô tả một pipeline đã có sẵn: clickstream đổ vào raw zone của S3 data lake. Việc cần làm thêm chỉ là chạy SQL-based data sanity checks trên chính vùng dữ liệu thô đó — nghĩa là kiểm tra chất lượng, đếm dòng, soi giá trị lạ, chứ không phải dựng một hệ phân tích thường trực.

Cụm từ quyết định nằm ở câu hỏi cuối: "cost-effective and easy to maintain". Cả bốn phương án đều chạy được SQL trên dữ liệu đó nếu bạn chịu bỏ công, nên năng lực kỹ thuật không phải thứ phân biệt chúng. Thứ phân biệt là: phương án nào không bắt bạn di chuyển dữ liệu và không bắt bạn nuôi một cụm hạ tầng.

Chú ý thêm cụm "Load the incremental raw zone data ... on an hourly basis" lặp lại ở ba phương án B, C, D. Đó là dấu hiệu tự tố: mỗi phương án đó đều thêm một job nạp dữ liệu định kỳ — tức thêm code phải viết, thêm lịch phải canh, thêm chỗ để hỏng.

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

A — Amazon Athena là dịch vụ truy vấn tương tác, chạy standard SQL trực tiếp trên dữ liệu nằm sẵn trong S3. Ba điểm khớp thẳng vào yêu cầu của đề:

• Không phải chuyển dữ liệu đi đâu cả. Dữ liệu đã ở raw zone của S3; Athena đọc tại chỗ. Bỏ luôn toàn bộ lớp job nạp dữ liệu hằng giờ mà B, C, D đều phải có.
• Serverless — không có cluster để cấp phát, chỉnh cỡ hay vá. Đây chính là vế "easy to maintain".
• Trả tiền theo truy vấn đã chạy. Sanity check là loại việc chạy từng đợt, không liên tục; mô hình tính tiền theo lượt dùng hợp với nó hơn hẳn mô hình nuôi hạ tầng chạy 24/7. Đây là vế "cost-effective".

Athena được thiết kế đúng cho các việc kiểu này: soi log, phân tích ad-hoc, truy vấn tương tác — mà kiểm tra tính đúng đắn của dữ liệu thô là một dạng ad-hoc query điển hình.

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

B — Nạp vào RDS hằng giờ. Đây là phương án tốn công nhất trong ba cái sai. RDS không tự đọc được S3, nên bạn phải tự viết job di chuyển dữ liệu — một Lambda function hoặc một tiến trình chạy trên EC2 — rồi tự lo lịch chạy, tự lo retry, tự lo khi job hỏng lúc 2 giờ sáng. Toàn bộ phần đó là development effort và maintenance mà đề bảo phải tránh. Chưa kể RDS là engine giao dịch, không phải chỗ dành cho quét toàn bộ clickstream thô.

C — Nạp vào Redshift hằng giờ. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì Redshift đúng là chạy SQL rất tốt trên dữ liệu quy mô lớn. Nhưng nó hỏng ở hai chỗ: (1) vẫn phải dựng và duy trì cluster — theo dõi kích cỡ, canh tài nguyên, xử lý khi cluster thiếu chỗ; (2) vẫn phải viết quy trình nạp dữ liệu định kỳ, tốn thời gian phát triển đáng kể. Redshift là data warehouse cho phân tích lâu dài, còn ở đây ta chỉ muốn kiểm tra vài phép sanity check trên vùng dữ liệu thô — nuôi cả một warehouse cho việc đó là dùng dao mổ trâu.

D — Nạp vào cụm EMR Spark rồi dùng SparkSQL. SparkSQL hoàn toàn chạy được các phép kiểm tra này, nên về mặt kỹ thuật phương án không sai. Nó hỏng ở chỗ EMR nghĩa là bạn quản lý hạ tầng bên dưới: cụm chạy trên các EC2 instance, có cỡ cụm để chọn, có framework để cấu hình, có việc bật/tắt cụm để tối ưu chi phí. Câu hỏi yêu cầu ít công phát triển và ít bảo trì nhất — EMR đứng ở đầu đối diện của thang đo đó so với Athena.

📌 Điểm cần nhớ

• Khi đề nói "cost-effective and easy to maintain" (hoặc "least operational overhead", "least development effort"), hãy loại ngay các phương án cần nuôi cluster (Redshift, EMR) hoặc cần tự viết job di chuyển dữ liệu.
• Dữ liệu đã nằm trong S3 + cần SQL là chữ ký kinh điển của Athena. Phương án nào bắt bạn chuyển dữ liệu ra khỏi S3 trước khi truy vấn đều đang thêm việc không cần thiết.
• Cụm từ "Load the incremental data ... on an hourly basis" trong một phương án là dấu hiệu cảnh báo: nó ngầm kéo theo một pipeline ETL phải xây và phải trông.
• Phương án chạy được không đồng nghĩa với phương án đúng. Trong bài thi kiểu này, hầu hết phương án đều khả thi về kỹ thuật; ràng buộc về chi phí và công vận hành mới là thứ chọn ra đáp án.

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

Đề mô tả một tình huống rất cụ thể: dữ liệu giao dịch nằm trong Amazon RDS và Amazon Redshift ở us-east-1, còn đội ở Ấn Độ dựng Amazon QuickSight ở ap-south-1. Vấn đề đang gặp là connectivity issues giữa QuickSight ở ap-south-1 và Redshift ở us-east-1.

Cụm từ quyết định đáp án là hai Region khác nhau — QuickSight ở ap-south-1, Redshift ở us-east-1 — cộng với chuyện đây là lỗi kết nối, không phải lỗi hiệu năng hay lỗi truy vấn. Ràng buộc này loại ngay mọi phương án dựa trên kết nối riêng tư trong phạm vi một Region, và cũng loại phương án nào đòi dời dữ liệu sang Region khác thay vì mở đường cho QuickSight đi tới.

Điều cần nhớ: QuickSight kết nối tới Redshift ở Region khác qua đường công khai của AWS, và thứ chặn nó lại là security group của cluster Redshift chưa cho phép dải địa chỉ mà QuickSight của Region kia dùng để gọi ra.

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

A — Configure a new security group for Amazon Redshift in us-east-1 with an inbound rule authorizing access from the appropriate CIDR address block for the Amazon QuickSight servers in ap-south-1.

Để QuickSight kết nối được tới một Redshift cluster, ta phải tạo cho cluster đó một security group có inbound rule cho phép dải CIDR của các máy chủ QuickSight thuộc Region tương ứng. Mỗi Region của QuickSight có dải địa chỉ riêng, nên khi QuickSight nằm ở ap-south-1 thì phải mở đúng dải CIDR của ap-south-1 chứ không phải của us-east-1.

Điểm mạnh của cách này là nó áp dụng được bất kể Redshift cluster có nằm trong VPC hay không — tài liệu QuickSight có hướng dẫn riêng cho cả hai trường hợp "cluster trong VPC" và "cluster không trong VPC". Đây là cách xử lý chuẩn, đúng bản chất của vấn đề: lỗi kết nối do luồng vào bị chặn, thì mở đúng luồng vào đó.

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

B — VPC endpoint từ QuickSight VPC ở ap-south-1 sang Redshift VPC ở us-east-1. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nghe rất "đúng bài bảo mật". Nhưng nó hỏng ở hai chỗ. Thứ nhất, VPC endpoint chỉ dùng để truy cập tài nguyên nằm cùng Region với endpoint — QuickSight ở ap-south-1 còn Redshift ở us-east-1, nên về mặt kỹ thuật không dựng được đường này. Thứ hai, chỉ bản QuickSight Enterprise mới tích hợp được với Amazon VPC, nên phương án còn kèm một điều kiện tiên quyết mà đề không hề nói tới.

C — NACL cho Redshift ở us-east-1 với inbound rule cho dải CIDR của QuickSight. Phương án này chỉ khác A ở đúng một từ: NACL thay vì security group. Nhưng NACL gắn với subnet, mà subnet lại nằm trong VPC — nó là lớp tường lửa tùy chọn ở mức subnet. Trong khi đó cả Redshift cluster lẫn QuickSight đều có thể được tạo ngoài VPC, nên NACL không phải là cơ chế đúng để mở quyền truy cập cho QuickSight trong tình huống tổng quát này. Đây chính là chỗ ràng buộc "irrespective of whether the cluster is in a VPC" phân biệt A với C.

D — Cross-Region snapshot hằng ngày sang ap-south-1, restore cluster rồi nối QuickSight vào cluster mới. Sai ở cả cách làm lẫn cách chọn. Về cách làm, không có kiểu đặt snapshot cross-Region trực tiếp trong Redshift: phải cấu hình automated snapshot ở chính Region của cluster, rồi bật cho Redshift tự động copy snapshot (automated hoặc manual) sang một Region đích khác — có Region nguồn và Region đích chứ không phải chụp thẳng sang Region kia. Về cách chọn, kể cả khi làm đúng quy trình copy đó thì ta cũng đang duy trì thêm một cluster Redshift thứ hai chỉ để phục vụ một dashboard — tốn kém, dữ liệu lại trễ theo nhịp snapshot, trong khi vấn đề gốc chỉ là một inbound rule chưa được mở.

📌 Điểm cần nhớ

• QuickSight nối tới Redshift thì thứ phải chỉnh là security group của cluster Redshift, với inbound rule cho dải CIDR của QuickSight thuộc đúng Region mà QuickSight đang chạy — không phải Region của Redshift.
• Security group và NACL không thay thế nhau trong tình huống này: NACL sống ở mức subnet nên chỉ tồn tại khi có VPC, còn cách làm bằng security group áp dụng được cho cả cluster trong lẫn ngoài VPC.
• VPC endpoint là công cụ trong phạm vi một Region. Thấy đề nói hai Region khác nhau mà phương án đề nghị VPC endpoint nối chéo Region thì loại ngay. Ngoài ra, tích hợp QuickSight với VPC là tính năng của bản Enterprise.
• Với Redshift, cross-Region là kết quả của việc bật copy snapshot sang Region đích, không phải một tùy chọn "chụp thẳng sang Region khác". Và nhân bản cả cluster sang Region khác chỉ để chạy dashboard là giải pháp đắt đỏ so với việc mở đúng quyền truy cập mạng.

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

Một startup y tế cần tuân thủ các quy định về compliance cho dữ liệu lưu trên Amazon S3. Yêu cầu then chốt được nêu rất rõ: "provide adequate protection against accidental deletion of objects" — bảo vệ chống xoá nhầm object.

Cụm từ quyết định đáp án là "protection against accidental deletion". Chữ protection (bảo vệ, ngăn chặn) khác hẳn detection (phát hiện) hay recovery bằng quy trình con người. Đề hỏi hai thứ:

• cơ chế kỹ thuật của chính S3, chứ không phải quy trình hành chính hay thông báo sau sự việc;
• cơ chế phải tác động vào thời điểm xoá hoặc trước đó, để hoặc chặn được lệnh xoá, hoặc giữ lại dữ liệu sau khi lệnh xoá đã chạy.

Thêm nữa, đề ghi (Select two), nên đáp án phải là hai tính năng bổ sung cho nhau chứ không phải hai cách nói lại cùng một ý.

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

D — Enable versioning on the Amazon S3 bucket. Versioning giữ nhiều phiên bản của cùng một object trong cùng một bucket. Khi bucket đã bật versioning, hành vi xoá thay đổi về bản chất: S3 không xoá dữ liệu đi thật, mà chèn một delete marker trở thành version hiện hành. Bản ghi cũ vẫn nằm nguyên đó và khôi phục được. Tương tự với ghi đè — ghi đè tạo ra version mới chứ không huỷ version cũ. Đây chính là lưới an toàn cho tình huống "lỡ tay xoá".

B — Enable MFA delete on the Amazon S3 bucket. MFA delete bổ sung một lớp xác thực thứ hai trước khi object bị xoá vĩnh viễn khỏi bucket. Người thao tác phải cung cấp mã từ thiết bị MFA thì lệnh xoá vĩnh viễn mới được chấp nhận. Nếu versioning lo phần "khôi phục lại được", thì MFA delete lo phần "không xoá hẳn được nếu chỉ vô ý bấm nhầm" — hai lớp đúng theo tinh thần chống xoá nhầm mà đề yêu cầu.

Hai phương án này còn gắn với nhau về mặt kỹ thuật: MFA delete là thiết lập trên bucket đã bật versioning, nên chọn cả hai là bộ đôi tự nhiên chứ không trùng lặp.

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

A — Đổi cấu hình trên S3 console để bắt người dùng xác nhận thêm khi xoá object. Đây là phương án nghe hợp lý nhất trong nhóm sai, vì "hộp thoại xác nhận" đúng là thứ hay dùng để chống thao tác nhầm. Nhưng S3 không có thiết lập nào cho phép bật kiểu xác nhận bổ sung này — nó không phải là một tuỳ chọn cấu hình tồn tại trên dịch vụ. Ngoài ra, ngay cả nếu có, nó chỉ áp dụng cho đường console mà không ràng buộc được các lệnh xoá đi qua API, CLI hay SDK.

C — Tạo event trigger khi object bị xoá, gửi SNS email cho IT manager. Sai vì thời điểm. Event notification chỉ bắn ra sau khi object đã bị xoá — lúc email tới hòm thư của IT manager thì việc đã rồi. Đây là cơ chế phát hiện và giám sát, hữu ích cho audit, nhưng không hề bảo vệ dữ liệu như đề đòi hỏi. Đề dùng chữ "protection", không phải "notification".

E — Lập quy trình xin phê duyệt của quản lý trước khi xoá object. Đây thuần tuý là quy trình hành chính, không được S3 hay bất kỳ cơ chế kỹ thuật nào cưỡng chế. Ai có quyền xoá vẫn xoá được mà chẳng cần ai duyệt; và bản thân "xoá nhầm" theo định nghĩa là hành vi ngoài ý muốn, một quy trình giấy tờ không ngăn được cú click sai. Trong bài thi AWS, phương án dạng "thiết lập một quy trình con người" gần như luôn là distractor khi đề đang hỏi biện pháp kỹ thuật.

📌 Điểm cần nhớ

• Đề hỏi "protection against accidental deletion" trên S3 thì cặp câu trả lời kinh điển là versioning + MFA delete: một cái giữ lại bản cũ để khôi phục, một cái thêm rào chắn trước lệnh xoá vĩnh viễn.
• Phân biệt prevention với detection: mọi phương án dựa trên event notification / SNS chỉ báo sau khi sự việc xảy ra, nên không đáp ứng được yêu cầu bảo vệ.
• Quy trình phê duyệt của con người không phải là biện pháp kiểm soát kỹ thuật — khi đề hỏi cách cấu hình dịch vụ để đảm bảo compliance, loại các phương án kiểu này trước tiên.
• Với bucket bật versioning, lệnh xoá chỉ tạo ra delete marker; dữ liệu gốc vẫn còn dưới dạng version cũ và khôi phục được. Đây là nền tảng để hiểu vì sao MFA delete được thiết lập trên bucket có versioning.

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

Một công ty dịch vụ tài chính muốn dựng kiến trúc data mesh với ba yêu cầu đi liền nhau: centralized data governance, analysis, và access control. Công ty đã chốt dùng AWS Glue cho data catalog và ETL. Câu hỏi: chọn hai dịch vụ AWS bổ sung để hiện thực hoá data mesh này.

Cụm từ quyết định là "centralized data governance ... and access control" đi kèm với việc AWS Glue Data Catalog đã có sẵn. Data mesh nghĩa là từng domain (business unit) tự sở hữu và tự vận hành data product của mình, nhưng việc cấp quyền và chia sẻ giữa các domain phải được quản trị tập trung và có thể giám sát, kiểm toán. Vế thứ hai bị nhiều người bỏ qua: đề nói tới cả analysis, tức là ngoài lớp quản trị còn phải có lớp lưu trữ + truy vấn cho data product.

Vì Glue Data Catalog đã được chốt, thứ ta cần là (1) lớp phân quyền chi tiết gắn trên chính catalog đó, và (2) nơi để dữ liệu và cách phân tích nó. Đây chính là lý do câu hỏi cần hai đáp án chứ không phải một.

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

A — AWS Lake Formation để centrally govern, secure và globally share data. Lake Formation là lớp quản trị đặt ngay trên dữ liệu data lake nằm ở Amazon S3 và trên metadata trong AWS Glue Data Catalog. Nó cho phép fine-grained access control ở mức database, table, cột — đúng thứ mà một công ty dịch vụ tài chính cần. Quan trọng hơn với data mesh: Lake Formation có tag-based access control (LF-tags). Data steward gắn tag theo phân loại nghiệp vụ lên tài nguyên, rồi viết policy trên vài chục tag logic thay vì trên hàng nghìn tài nguyên có tên cụ thể. Cách này gỡ được "role explosion", tách việc tạo policy khỏi việc tạo tài nguyên — policy viết trước cũng được, tài nguyên mới sinh ra chỉ cần gắn đúng tag là tự nằm dưới policy có sẵn. Đó chính là mô hình "governance phi tập trung, giám sát và kiểm toán tập trung" mà data mesh mô tả.

C — Amazon S3 làm nơi lưu trữ và Amazon Athena để phân tích. Đây là lớp nền vật lý: S3 giữ dữ liệu của các data product, Athena truy vấn trực tiếp trên đó bằng SQL, đọc schema từ Glue Data Catalog. Cặp này trả lời cho vế analysis của đề bài, và cũng chính là lớp mà quyền của Lake Formation áp lên. Không có S3 thì Lake Formation không có gì để quản trị.

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

B — AWS Data Exchange. Đây là dịch vụ để khách hàng tìm, đăng ký và sử dụng dữ liệu của bên thứ ba trên AWS Cloud. Nó nghe rất gần với "globally share data and control access" nên là distractor mạnh nhất trong bốn phương án sai. Nhưng bối cảnh của nó là thị trường dữ liệu giữa nhà cung cấp và người mua bên ngoài, không phải cơ chế cấp quyền chi tiết giữa các domain nội bộ trên chính data lake của công ty. Nó không gắn được với Glue Data Catalog để phân quyền theo bảng, theo cột.

D — AWS DataSync. DataSync là dịch vụ di chuyển dữ liệu: chuyển dữ liệu giữa on-premises, edge, cloud khác và các dịch vụ lưu trữ AWS. Nó giải quyết bài toán vận chuyển byte, hoàn toàn không có khái niệm governance, catalog hay access control ở mức bảng/cột. Chữ "share data" trong phương án là đánh tráo — DataSync copy dữ liệu chứ không chia sẻ có kiểm soát.

E — AWS Glue DataBrew tích hợp với AWS Glue Studio. Phần mô tả về tích hợp là đúng sự thật: DataBrew là dịch vụ chuẩn bị dữ liệu trực quan (làm sạch, chuẩn hoá, biến đổi), và recipe của nó có thể được điều phối trong job/workflow của AWS Glue Studio. Nhưng đúng sự thật không có nghĩa là đúng câu hỏi. Cả hai đều là công cụ data preparation và ETL orchestration, không phải công cụ chia sẻ dữ liệu hay kiểm soát truy cập. Phương án này còn thừa ở chỗ đề đã nói công ty dùng Glue cho ETL rồi.

📌 Điểm cần nhớ

• Nhắc tới data mesh + governance + access control tập trung trên AWS thì mảnh ghép gần như luôn là Lake Formation, vì nó là lớp phân quyền chi tiết đặt trên S3 và Glue Data Catalog.
• LF-tags (tag-based access control) là lý do Lake Formation hợp với data mesh: policy viết trên tag logic thay vì trên từng tài nguyên, nên số domain và số bảng tăng lên mà số policy không nổ theo.
• Phân biệt ba động từ dễ lẫn: DataSync = di chuyển dữ liệu, Data Exchange = mua/đăng ký dữ liệu bên thứ ba, Lake Formation = quản trị và chia sẻ có kiểm soát dữ liệu của chính mình.
• Câu "chọn hai" thường muốn hai lớp khác nhau chứ không phải hai dịch vụ cùng loại: ở đây là lớp lưu trữ/phân tích (S3 + Athena) và lớp quản trị (Lake Formation). Nếu hai đáp án bạn chọn cùng làm một việc, khả năng cao là sai một cái.

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

Đề mô tả một công ty logistics có nhiều AWS account, mỗi account chạy EC2 instances đã cài CloudWatch Logs agent. Yêu cầu: gom toàn bộ security events về một AWS account trung tâm chuyên để lưu log.

Cụm từ quyết định đáp án là "near-real-time gathering and collating events across multiple AWS accounts" — gần thời gian thực, và xuyên nhiều account. Hai vế này loại phương án theo hai hướng khác nhau:

• near-real-time loại ngay mọi giải pháp chạy theo lô, theo lịch (export mỗi giờ).
• across multiple AWS accounts buộc phải dùng đúng cơ chế mà CloudWatch Logs hỗ trợ để chia sẻ log sang account khác — tức cross-account data sharing bằng CloudWatch Logs destination + subscription filter.

Cụm thứ ba đáng chú ý là "A CloudWatch Logs agent is installed on each of the EC2 instances" — log đã nằm sẵn trong CloudWatch Logs của từng account rồi, nên việc còn lại là đưa nó ra khỏi CloudWatch Logs, chứ không phải cấu hình lại agent.

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

Đáp án đúng là A: dựng Kinesis Data Firehose trong logging account, rồi từ mỗi application account tạo subscription filter trên CloudWatch Logs trỏ tới delivery stream đó, Firehose ghi xuống S3 trong logging account.

Đây đúng là mô hình cross-account subscription mà CloudWatch Logs thiết kế sẵn: bên nhận (logging account) tạo một CloudWatch Logs destination trỏ tới stream của mình và cấp quyền cho các account nguồn; bên gửi chỉ cần tạo subscription filter trỏ vào destination đó. Log event được đẩy đi liên tục ngay khi phát sinh, nên thoả yêu cầu near-real-time, chứ không chờ tới mốc lịch nào.

Chọn Firehose làm đích cũng hợp lý vì Firehose là dịch vụ giao nhận có sẵn tích hợp ghi thẳng vào S3 — không phải viết code tiêu thụ, không phải quản lý shard, và chịu được lưu lượng lớn từ nhiều account gộp lại. Lưu ý một chi tiết vận hành: log đi qua subscription filter được nén gzip và mã hoá Base64, nên khâu xử lý phía sau (đọc từ S3, phân tích) phải biết giải nén.

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

B — CloudWatch Logs agent publish thẳng vào Firehose, rồi Lambda đọc stream đẩy tiếp vào Firehose. Sai ở chỗ căn bản: CloudWatch Logs agent không có khả năng publish dữ liệu vào Kinesis Data Firehose — nó chỉ biết đẩy log lên CloudWatch Logs. (Bản thân agent cũ này cũng chỉ hỗ trợ Linux và đang được thay bằng unified CloudWatch agent, vốn gom được cả log lẫn metric và chạy được cả Windows Server.) Ngoài ra luồng mô tả còn luẩn quẩn: Lambda đọc từ stream rồi lại đẩy vào Firehose, tức là đi qua Firehose hai lần mà không thêm giá trị gì.

C — Forward events từ CloudWatch Logs account này sang CloudWatch Logs account trung tâm, rồi cho Firehose subscribe vào CloudWatch Events. Phương án này nghe rất gần đúng vì nó cũng nhắc tới Firehose và S3, nhưng hỏng ở hai mắt xích. Thứ nhất, không có cơ chế forward trực tiếp CloudWatch Logs sang CloudWatch Logs của account khác; đích hợp lệ của một subscription filter chỉ là Kinesis Data Streams, Kinesis Data Firehose hoặc Lambda. Thứ hai, đề mô tả Firehose stream "subscribe" vào CloudWatch Events — quan hệ này ngược chiều và không tồn tại theo cách đó; Firehose là nơi nhận dữ liệu chứ không tự đi đăng ký nguồn.

D — IAM role ở mỗi account + Lambda assume role, export CloudWatch Logs sang S3 mỗi giờ. Đây là phương án duy nhất không sai về mặt kỹ thuật thuần tuý — nó chạy được — nhưng chạy theo lịch mỗi giờ thì không phải near-real-time, vi phạm thẳng ràng buộc quan trọng nhất của đề. Thêm nữa, dùng Lambda làm xương sống cho một luồng log khối lượng lớn, tốc độ cao từ nhiều account là chọn sai công cụ: đây đúng là bài toán của họ Kinesis. Nếu đề bỏ chữ "near-real-time" và đổi thành gom log định kỳ để lưu trữ, D mới trở thành ứng viên đáng cân nhắc.

📌 Điểm cần nhớ

• Gom log xuyên nhiều AWS account trong near-real-time = CloudWatch Logs destination + subscription filter, đích là Kinesis Data Streams, Kinesis Data Firehose hoặc Lambda. Đây là cơ chế cross-account data sharing chính thống, thấy đề nào có "multiple accounts + centralized logging + near-real-time" thì tìm ngay cụm này trong các phương án.
• Subscription filter không nhận đích là CloudWatch Logs của account khác. Phương án nào nói "forward CloudWatch Logs sang CloudWatch Logs" là loại được ngay mà không cần đọc tiếp.
• Bắt từ khoá thời gian: "near-real-time" / "streaming" loại mọi giải pháp export theo lịch (hourly, daily) dù chúng vẫn chạy được; ngược lại "periodic archive" thì export theo lô lại là lựa chọn rẻ và hợp lý.
• CloudWatch Logs agent chỉ gửi được vào CloudWatch Logs, không gửi thẳng vào Firehose hay Kinesis. Muốn dữ liệu ra khỏi CloudWatch Logs thì phải qua subscription filter (hoặc export task), chứ không phải cấu hình lại agent.
• Dữ liệu đi qua subscription filter bị gzip + Base64, nên khâu tiêu thụ phía sau phải giải nén trước khi phân tích.

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

Một công ty IoT nạp dữ liệu từ thiết bị hiện trường vào Amazon S3 (data lake) theo từng giờ. Mỗi bản ghi có device type, device ID, status, timestamp, source IP… Khối lượng lên tới hàng triệu bản ghi mỗi ngày, và câu hỏi là cách lưu nào cho hiệu năng truy vấn tốt nhất.

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

• "complex analytical queries" — truy vấn phân tích chỉ đọc vài cột trong nhiều cột. Đây là ràng buộc chọn định dạng cột (columnar) thay vì định dạng theo dòng.
• "on a daily basis" — mỗi lần chạy chỉ cần dữ liệu của một ngày. Đây là ràng buộc chọn khoá phân vùng là date, để engine bỏ qua (prune) toàn bộ thư mục của những ngày khác.
• "for each device type" — trong phạm vi một ngày, dữ liệu cần được gom cụm theo device type. Đây là ràng buộc chọn sắp xếp (sort) theo device type.

Chú ý sự phân vai: partition quyết định đọc file nào, sort quyết định đọc nhanh cỡ nào bên trong file đã đọc.

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

Đáp án đúng theo tệp là D — Apache ORC, partitioned by date, sorted by device type.

• ORC là định dạng cột. Cùng với Parquet, đây là hai định dạng columnar mà các dịch vụ phân tích của AWS (Athena, EMR, Redshift Spectrum) tối ưu để đọc nhanh. Truy vấn phân tích chỉ chạm vào một phần cột nên chỉ phần cột đó được đọc từ S3, thay vì đọc nguyên dòng. Định dạng cột cũng nén tốt hơn vì các giá trị cùng cột có kiểu và phân bố giống nhau.
• Partition theo date khớp với nhịp truy vấn. Vì phân tích chạy hằng ngày, phân vùng theo ngày cho phép engine chỉ quét đúng thư mục của ngày đó. Đây vừa là lợi ích hiệu năng vừa là lợi ích chi phí — với Athena, tiền tính theo lượng dữ liệu quét.
• Sort theo device type khớp với chiều phân tích. Trong phạm vi một ngày, các bản ghi cùng device type nằm liền kề nhau, nên khi lọc theo device type engine bỏ qua được nhiều khối dữ liệu (ORC lưu thống kê min/max ở mức stripe và index) và đọc ít hơn hẳn.

Nói gọn: D khớp cả ba ràng buộc trong đề — columnar cho truy vấn phân tích, partition theo chiều lọc chính (ngày), sort theo chiều nhóm phụ (device type).

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

C — Apache Parquet, partitioned by device type and sorted by date. Đây là phương án gần đúng nhất, và nó chỉ hỏng ở đúng một chỗ: đảo ngược vai trò partition và sort. Bản thân Parquet là định dạng cột hoàn toàn hợp lệ, ngang hàng ORC ở use case này — đề không loại C vì định dạng. Vấn đề là phân vùng theo device type khiến truy vấn "phân tích dữ liệu của ngày hôm nay" phải chạm vào mọi phân vùng device type rồi mới lọc ngày bên trong, tức là mất hẳn tác dụng cắt dữ liệu của partition. Ngược lại, phân vùng theo ngày rồi sort theo device type vẫn giữ được cả hai lợi ích. Ngoài ra, số lượng device type thường không nhiều và ít tăng, nên nó là khoá phân vùng thô; còn ngày thì tự nhiên tăng đều theo dòng dữ liệu nạp hằng giờ.

A — compressed .csv, partitioned by date and sorted by device type. Phần partition và sort ở đây thật ra đúng y hệt đáp án D — điều đó cho thấy đề đang cố ý dồn sự khác biệt vào định dạng lưu trữ. CSV là định dạng theo dòng: dù có nén, engine vẫn phải đọc và giải nén cả dòng để lấy ra vài cột cần thiết, không có thống kê min/max theo khối để bỏ qua dữ liệu, và không có mã hoá theo cột. Với hàng triệu bản ghi mỗi ngày, đây là khoản lãng phí I/O lớn nhất trong bốn phương án về mặt định dạng.

B — compressed .csv, partitioned by date and sorted by the status of the device. Hỏng hai lần. Thứ nhất, vẫn là CSV theo dòng, y như A. Thứ hai, sort theo status không phục vụ chiều phân tích nào mà đề nêu — đề nói rõ phân tích "for each device type", không phải theo trạng thái thiết bị. Sắp xếp theo một cột không được lọc/nhóm thì gần như không mang lại lợi ích bỏ qua dữ liệu nào.

📌 Điểm cần nhớ

• Truy vấn phân tích trên data lake ⇒ chọn định dạng cột (Parquet hoặc ORC). Thấy CSV/JSON trong phương án của một câu hỏi về "analytical queries" thì gần như chắc chắn loại được, kể cả khi có chữ "compressed".
• Parquet và ORC ngang nhau ở tầng nguyên lý. Nếu cả hai cùng xuất hiện, đề không phân biệt bằng định dạng — hãy đọc tiếp phần partition/sort để tìm điểm khác biệt thật.
• Partition theo cột dùng để LỌC, sort theo cột dùng để NHÓM/tra cứu bên trong. Cột lọc chính thường là thời gian; đảo hai vai này là lỗi bẫy kinh điển.
• Khoá phân vùng nên bám nhịp truy vấn, không bám cấu trúc nghiệp vụ. Đề nói "daily" thì phân vùng theo ngày; nếu nạp theo giờ và truy vấn theo giờ thì mới xuống tới mức year/month/day/hour.
• Cột không được lọc cũng không được nhóm (như status ở phương án B) thì sắp xếp theo nó là vô ích — luôn đối chiếu khoá sort với đúng câu chữ mô tả nhu cầu phân tích trong đề.

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

Đề mô tả một cơ quan dự báo thời tiết thu thập chỉ số thời tiết từ nhiều thành phố ở Mỹ và gửi lên AWS dưới dạng key-value pairs, tần suất một phút một lần. Câu hỏi yêu cầu chọn hai dịch vụ để xử lý (processing) rồi lưu trữ tin cậy, tính sẵn sàng cao (reliably storing with high availability).

Cụm từ quyết định là "in the form of key-value pairs" — dữ liệu đến ở dạng khoá–giá trị, không phải bảng quan hệ có schema cố định, cũng không phải khối dữ liệu lớn để phân tích. Cụm thứ hai là "Select two" gắn với hai động từ khác nhau: processing và storing. Nghĩa là đáp án không phải hai kho lưu trữ song song, mà là một lớp tính toán + một lớp lưu trữ. Ai chỉ đọc vế "storing" rồi đi so sánh Redshift với DynamoDB với RDS sẽ chọn nhầm.

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

Đáp án theo tệp là B (Amazon DynamoDB) và C (AWS Lambda).

AWS Lambda lo phần processing. Nó chạy code mà không cần cấp phát hay quản trị máy chủ, chỉ tính tiền theo thời gian tính toán thực sự tiêu thụ — không chạy thì không mất phí. Dữ liệu về theo nhịp một phút một lần, tức là từng đợt nhỏ, rời rạc: đúng kiểu công việc chạy ngắn theo sự kiện mà Lambda sinh ra để phục vụ, thay vì giữ một máy chủ bật suốt ngày chỉ để đợi vài chỉ số.

Amazon DynamoDB lo phần storing. Đây là cơ sở dữ liệu key-value và document, cho hiệu năng ở mức mili-giây một chữ số ở mọi quy mô. Nó là dịch vụ được quản lý hoàn toàn, có khả năng chạy đa vùng, bền vững, kèm sẵn bảo mật, sao lưu – khôi phục và bộ nhớ đệm trong bộ nhớ. Là NoSQL, nó hợp nhất với dữ liệu dạng key-value — đúng thứ mà đề nói dữ liệu đang có. Yêu cầu "reliably storing with high availability" cũng được đáp ứng bởi chính đặc tính managed, bền vững, đa vùng đó.

Ghép lại: Lambda nhận và xử lý các cặp khoá–giá trị từ nguồn, rồi ghi xuống DynamoDB. Đó là lý do cả hai phương án cùng đúng.

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

A. Amazon Redshift — Đây là kho dữ liệu (data warehouse) trên đám mây, được quản lý hoàn toàn, ở quy mô petabyte, thiết kế cho việc lưu trữ và phân tích tập dữ liệu lớn. Đây là phương án dễ gây phân vân nhất vì nó cũng "lưu trữ" và nghe rất "dữ liệu". Nhưng nó hỏng ở chỗ: Redshift không phải nơi để thu nhận (capture) dữ liệu key-value đổ về liên tục từ các nguồn kiểu IoT. Nó là đích đến của phân tích, không phải điểm tiếp nhận của luồng ghi nhỏ, tần suất cao.

D. Amazon ElastiCache — Cho phép dựng, chạy và mở rộng các kho dữ liệu in-memory mã nguồn mở phổ biến trên đám mây, phục vụ các trường hợp cần thông lượng cao và độ trễ thấp: caching, session store, gaming, dịch vụ không gian địa lý, phân tích thời gian thực, hàng đợi. Nó cũng lưu theo kiểu khoá–giá trị nên trông rất gần đáp án. Điểm hỏng: ElastiCache đóng vai lớp cache đặt trước một cơ sở dữ liệu quan hệ, không phải kho lưu trữ chính. Đề đòi "reliably storing" — lưu trữ tin cậy, mà một lớp đệm in-memory không phải nơi bạn coi là bản ghi gốc của dữ liệu.

E. Amazon RDS — Giúp dựng, vận hành và mở rộng cơ sở dữ liệu quan hệ trên đám mây, tự động hoá các việc tốn thời gian như cấp phát phần cứng, cài đặt, vá lỗi, sao lưu. Vấn đề nằm ở mô hình dữ liệu: cơ sở dữ liệu quan hệ không phải lựa chọn tốt để lưu dữ liệu dạng key-value. Đề đã nói thẳng định dạng dữ liệu, và đó là ràng buộc loại RDS ra.

📌 Điểm cần nhớ

• Thấy chữ "key-value pairs" trong đề AWS thì nghĩ ngay tới DynamoDB; đó là tín hiệu loại thẳng RDS (quan hệ) và Redshift (data warehouse phân tích).
• Câu "Select two" mà đề có hai động từ (processing + storing) thường muốn một cặp compute + storage, không phải hai kho lưu trữ. Đọc kỹ động từ trước khi so sánh các database với nhau.
• ElastiCache là lớp cache, không phải kho lưu trữ chính. Đề nào nhấn "reliably storing" hoặc "durable" thì ElastiCache bị loại, dù dữ liệu có đúng dạng khoá–giá trị.
• Redshift là đích phân tích, không phải điểm tiếp nhận (ingest) cho luồng ghi nhỏ tần suất cao. Nó xuất hiện trong đáp án là để đánh lừa người chỉ đọc mỗi chữ "storing".

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

Một công ty thương mại điện tử lưu bản sao chi tiết đơn hàng trong bucket S3 tên Orders. Yêu cầu: ghi log mọi thao tác ghi (writes) vào bucket Orders, và đẩy log đó sang một bucket S3 khác tên Audit nằm cùng Region.

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

• "log all writes" — tức là toàn bộ thao tác ghi ở mức object (PutObject, DeleteObject...), trên mọi object trong bucket, không giới hạn theo nhánh đường dẫn nào. Đây chính là định nghĩa của data event loại Write trong AWS CloudTrail.
• "with the LEAST operational effort" — ràng buộc phân biệt bốn phương án. Cả bốn đều "làm được việc" ở mức nào đó, nhưng đề hỏi cái ít công vận hành nhất, nên mọi giải pháp phải tự viết code và tự bảo trì đều bị loại ngay khi có sẵn tích hợp gốc.

Hai cụm này ghép lại chỉ thẳng tới CloudTrail data events cho S3, và câu hỏi thu về một chi tiết cấu hình rất nhỏ: prefix khai như thế nào để bao hết bucket.

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

Đáp án đúng là D: tạo trail trong CloudTrail console, cấu hình nhận data events từ bucket Orders với prefix để trống, chọn loại Write, và đặt bucket Audit làm destination của trail.

Event trong CloudTrail là bản ghi của một hoạt động trong tài khoản AWS. Mặc định, trail chỉ ghi management events chứ không ghi data events — data events phải bật thêm và có tính phí riêng, vì chúng là các thao tác ở tầng data plane, khối lượng thường rất lớn. Với Amazon S3, data event chính là hoạt động API ở mức object: GetObject, PutObject, DeleteObject... đúng thứ mà đề gọi là "writes".

Điểm mấu chốt: khi khai data event cho một bucket S3, prefix dùng để giới hạn phạm vi theo đường dẫn object. Muốn ghi log cho mọi object trong bucket thì phải để prefix trống — không giới hạn gì cả. Kết hợp với việc chỉ chọn loại Write, ta được đúng yêu cầu "log all writes". Đây là tích hợp gốc giữa CloudTrail và S3: chỉ cấu hình, không code, không hạ tầng phải bảo trì — thoả mãn "LEAST operational effort".

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

A. CloudTrail trail nhưng prefix là All-objects — đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Cách tiếp cận (CloudTrail data events, loại Write, đổ vào bucket Audit) hoàn toàn chuẩn; chỉ sai đúng một chi tiết. All-objects không phải một từ khoá đặc biệt — CloudTrail hiểu nó như một prefix theo nghĩa đen. Khi đã khai prefix, trail chỉ ghi log cho những object có key khớp prefix đó. Kết quả: trừ khi trong bucket thật sự có nhánh tên All-objects, log sẽ trống rỗng — mà lại không có lỗi nào báo ra, cấu hình vẫn hợp lệ. Muốn "all objects" thì để trống, không phải viết chữ "all".

C. S3 Event notification → Lambda ghi data event sang bucket Audit — về nguyên tắc có thể tự dựng được đường ống này, nhưng nó thêm hẳn một thành phần phải viết và nuôi: code Lambda, IAM role, xử lý lỗi/retry, theo dõi khi hàm chết. Đề bài đã chốt "LEAST operational effort" nên tự viết lại thứ CloudTrail làm sẵn là đi ngược yêu cầu. Chi tiết "IAM role có full access trên cả hai bucket" còn là cấu hình quyền rộng quá mức cần thiết. Ngoài ra sự kiện New object created chỉ bắt việc tạo object mới, hẹp hơn khái niệm "all writes".

B. S3 Event notification → EventBridge → Lambda copy metadata → rồi log vào CloudTrail — cùng vấn đề như C nhưng còn nhiều tầng hơn: thêm EventBridge, thêm rule, thêm Lambda, tức là thêm chỗ hỏng và thêm việc vận hành. Chuỗi này cũng lòng vòng về mặt logic: nó đi qua Lambda copy metadata rồi mới nói tới CloudTrail, trong khi CloudTrail có thể ghi trực tiếp data events của bucket ngay từ đầu mà không cần một mắt xích nào ở giữa.

📌 Điểm cần nhớ

• CloudTrail data events là công cụ chuẩn để ghi log thao tác mức object trên S3 (GetObject, PutObject, DeleteObject); management events là mặc định và không bao gồm chúng — data events phải bật riêng và có phí thêm.
• Khi khai data event cho S3, prefix trống nghĩa là toàn bộ bucket. Khai một prefix cụ thể là thu hẹp phạm vi — và nếu prefix không khớp gì thì log im lặng rỗng chứ không báo lỗi. Đừng tin những chuỗi nghe như từ khoá kiểu All-objects.
• Cụm "LEAST operational effort" gần như luôn loại các phương án dựng thêm Lambda / EventBridge khi đã tồn tại tích hợp gốc giữa hai dịch vụ. Chỉ cấu hình thắng tự viết code.
• Phân biệt hai lớp khác nhau: S3 Event notification là để kích hoạt xử lý khi có thay đổi, còn CloudTrail là để ghi vết kiểm toán ai đã gọi API nào. Câu hỏi về audit/compliance thì nghĩ tới CloudTrail trước.

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

Đề đặt ra một bài toán tối ưu truy vấn SQL trên Amazon Redshift với ba ràng buộc cụ thể:

1. "expanding the cluster size is not an option" — không được thêm node, nên mọi giải pháp phải nằm trong việc thiết kế bảng, không phải mở rộng hạ tầng.
2. "utilizes the EVEN distribution style for loading data across multiple tables" — hiện trạng là mọi bảng đều dùng EVEN.
3. Cụm từ quyết định đáp án: "some tables containing hundreds of GB of data while others have less than 20 MB" — độ lớn các bảng chênh nhau rất xa. Đây chính là ràng buộc phân biệt bốn phương án: nó nói rằng không thể áp một distribution style duy nhất cho toàn bộ bảng, mà phải chọn theo kích thước từng bảng.

Chính vế "bảng nhỏ vs bảng khổng lồ" biến câu hỏi thành bài kiểm tra hiểu biết về DISTSTYLE ALL — style dành riêng cho bảng nhỏ, ít thay đổi.

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

Đáp án đúng theo tệp là C — dùng ALL distribution cho các bảng nhỏ hiếm khi cập nhật, đồng thời khai báo primary key và foreign key cho mọi bảng.

Với DISTSTYLE ALL, Redshift đặt một bản sao toàn bộ bảng trên mọi node. Trong khi EVEN hoặc KEY chỉ để một phần số dòng trên mỗi node, ALL đảm bảo mọi dòng đều nằm cùng chỗ (collocated) với dữ liệu cần join. Kết quả là các phép join với bảng đó không phải phát tán dữ liệu qua mạng giữa các node — đúng thứ giúp truy vấn nhanh lên mà không cần thêm node nào, khớp với ràng buộc ngân sách.

Cái giá của ALL là dung lượng lưu trữ nhân lên theo số node, và việc load/update/insert chậm hơn hẳn. Vì vậy ALL chỉ hợp lý với bảng nhỏ và ít biến động — chính là nhóm "less than 20 MB" trong đề. Các bảng hàng trăm GB giữ nguyên EVEN.

Phần khai báo primary key và foreign key cũng có lý do thật: Redshift không cưỡng chế các ràng buộc này, nhưng query optimizer đọc chúng để sinh execution plan tốt hơn. Đây là cách tăng hiệu năng không tốn thêm tài nguyên. Lưu ý kèm theo: chỉ khai báo khi ứng dụng của bạn tự đảm bảo tính đúng đắn của dữ liệu, vì Redshift không kiểm tra hộ.

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

A — ALL distribution cho các bảng lớn. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó dùng đúng công cụ nhưng áp vào đúng nhóm bảng sai. Nhân bản một bảng hàng trăm GB ra mọi node làm dung lượng lưu trữ phình lên theo số node — trên một cluster không được phép mở rộng thì đây là hướng đi ngược hoàn toàn — đồng thời khiến việc load và cập nhật chậm đi rất nhiều. ALL chỉ dành cho bảng chậm biến động và có kích thước nhỏ.

B — chuyển toàn bộ bảng sang AUTO. AUTO là lựa chọn dành cho tình huống bạn không có căn cứ rõ ràng để chọn style, hoặc bảng đã denormalize và không tham gia join. Ở đây đề đã mô tả rõ đặc điểm từng nhóm bảng, tức là ta có đủ thông tin để chọn có chủ đích. Giao lại cho AUTO là vứt bỏ hiểu biết mình đang có; đây không phải lựa chọn tối ưu cho use case đã xác định rõ pattern truy cập.

C — đáp án đúng, đã phân tích ở trên.

D — chuyển sang Amazon Redshift Spectrum. Spectrum cho phép truy vấn dữ liệu có cấu trúc và bán cấu trúc nằm trong file trên Amazon S3 mà không cần load vào bảng Redshift. Vấn đề là đề bài không hề nhắc tới S3 — dữ liệu đang nằm trong cluster Redshift. Đây thuần túy là distractor: nó đổi cả kiến trúc lưu trữ để giải một bài toán vốn chỉ cần chỉnh distribution style.

📌 Điểm cần nhớ

• DISTSTYLE ALL = bảng nhỏ + ít cập nhật. Nó nhân bản toàn bộ bảng ra mọi node để join khỏi phải phát tán dữ liệu, đổi lại tốn dung lượng theo số node và ghi chậm. Thấy phương án nào gán ALL cho bảng lớn hoặc bảng biến động nhiều thì loại ngay.
• AUTO là lựa chọn khi thiếu thông tin. Đề mô tả càng rõ kích thước và pattern truy cập của bảng thì AUTO càng ít khả năng là đáp án.
• Primary key và foreign key trong Redshift chỉ mang tính thông tin — không được cưỡng chế, nhưng optimizer dùng chúng để sinh plan tốt hơn. Chỉ khai báo khi ứng dụng tự đảm bảo tính toàn vẹn.
• Redshift Spectrum gắn liền với dữ liệu trên S3. Đề không nhắc tới S3 mà phương án lôi Spectrum vào thì gần như chắc chắn là distractor.
• Khi đề chốt "không được mở rộng cluster", hãy tìm câu trả lời nằm ở thiết kế bảng (distribution, sort key, ràng buộc), không phải ở hạ tầng.

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

Đề mô tả một công ty mạng xã hội lưu ảnh trên Amazon S3, trong đó một số ảnh được truy cập thường xuyên, số khác nằm im rất lâu. Câu hỏi là chọn giải pháp tiết kiệm chi phí NHẤT (MOST cost-effective).

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

• "some ... frequently accessed, others sit idle" — mẫu truy cập là hỗn hợp và không đoán trước được. Đề không nói ảnh nào nóng, ảnh nào nguội, cũng không nói sau bao lâu thì một ảnh chuyển từ nóng sang nguội. Đây chính là ràng buộc phân biệt các phương án: một storage class cố định chỉ đúng cho một trong hai nhóm.
• "MOST cost-effective" — chi phí ở đây không chỉ là giá lưu trữ mỗi GB, mà còn gồm retrieval fee và chi phí xây dựng, vận hành hạ tầng để tự phân loại.

Ghép hai ràng buộc lại: cần thứ tự động phân tầng theo mẫu truy cập thật, không cần người vận hành đoán trước và không phải nuôi thêm máy chủ.

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

Đáp án B — Store the images using the Amazon S3 Intelligent-Tiering storage class.

S3 Intelligent-Tiering được thiết kế đúng cho tình huống mẫu truy cập không biết trước hoặc thay đổi theo thời gian. Nó lưu object trong nhiều access tier: một tier tối ưu cho truy cập thường xuyên và một tier chi phí thấp hơn tối ưu cho truy cập không thường xuyên.

Cơ chế: với một khoản phí giám sát và tự động hoá nhỏ tính theo object mỗi tháng, S3 tự theo dõi mẫu truy cập và chuyển những object không được truy cập trong một số ngày liên tiếp (mốc chuẩn là 30 ngày) xuống tier truy cập không thường xuyên. Nếu một object ở tier đó bị truy cập trở lại, nó tự động được đưa về tier truy cập thường xuyên.

Ba điểm khiến nó thắng ở tiêu chí "MOST cost-effective":

• Ảnh nóng nằm ở tier có chi phí tương đương Standard, ảnh nguội tự tụt xuống tier rẻ hơn — đúng cả hai nhóm mà đề mô tả.
• Không có retrieval fee khi object di chuyển giữa các access tier tự động, nên ảnh nguội bỗng viral trở lại không sinh ra hoá đơn bất ngờ.
• Không có operational overhead: không code, không EC2, không lịch chạy, không ai phải trực.

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

A — Ứng dụng giám sát trên EC2, chạy hằng ngày qua CloudWatch, đẩy object nguội xuống S3 One Zone-IA.

Sai vì hai lớp lý do. Thứ nhất, phải tự viết và tự nuôi một ứng dụng giám sát: chi phí phát triển, chi phí EC2 chạy liên tục, cộng công bảo trì — tất cả để làm lại đúng việc Intelligent-Tiering đã làm sẵn. Thứ hai, One Zone-IA chỉ lưu dữ liệu trong một Availability Zone, nên độ bền trước sự cố mất cả một AZ thấp hơn các class multi-AZ. Ảnh người dùng của mạng xã hội là dữ liệu gốc không tái tạo lại được, đánh đổi độ bền để lấy vài phần trăm giá là quyết định sai bản chất.

C — Ứng dụng giám sát trên EC2, chạy hằng ngày qua CloudWatch, đẩy object nguội xuống S3 Standard-IA.

Đây là phương án gần đúng nhất trong ba cái sai: nó chọn đúng cặp storage class (Standard cho nóng, Standard-IA cho nguội) và đúng hướng phân tầng theo mẫu truy cập. Chỗ hỏng nằm ở cách thực hiện, không phải ở đích đến. Tự xây bộ máy phân loại trên EC2 nghĩa là gánh chi phí phát triển, chi phí instance chạy thường trực và trách nhiệm vận hành — trong khi Intelligent-Tiering cho cùng kết quả với một khoản phí monitoring nhỏ theo object. Với tiêu chí "MOST cost-effective", giải pháp managed thắng giải pháp tự xây tương đương.

D — Lưu toàn bộ ảnh bằng S3 Standard-IA.

Standard-IA dành cho dữ liệu ít khi truy cập nhưng cần lấy ra nhanh khi cần: giá lưu trữ mỗi GB thấp, đổi lại có phí retrieval theo GB và thời gian lưu tối thiểu 30 ngày. Vấn đề là đề nói rõ một phần ảnh được truy cập thường xuyên — nhóm ảnh đó sẽ liên tục phát sinh retrieval fee, và tổng chi phí có thể vọt lên cao hơn cả việc để nguyên ở Standard. Đây là cái bẫy kinh điển: nhìn thấy "giá lưu trữ rẻ hơn" mà bỏ qua vế "trả tiền mỗi lần đọc".

📌 Điểm cần nhớ

• Đề nói mẫu truy cập không biết trước, thay đổi, hoặc hỗn hợp nóng–nguội → nghĩ ngay tới S3 Intelligent-Tiering. Đó là chữ ký nhận dạng của class này.
• Một storage class cố định (Standard-IA, One Zone-IA) chỉ đúng khi bạn đã biết chắc dữ liệu là nguội. Áp lên tập dữ liệu có phần nóng thì retrieval fee ăn hết phần tiết kiệm.
• "Cost-effective" trong đề thi AWS luôn tính cả chi phí vận hành và phát triển, không chỉ hoá đơn hạ tầng. Phương án "viết ứng dụng trên EC2 chạy theo lịch" để làm việc mà một managed feature đã làm sẵn thì gần như luôn là đáp án sai.
• One Zone-IA đánh đổi độ bền lấy giá vì chỉ nằm trong một AZ — chỉ hợp với dữ liệu tái tạo lại được, không hợp với dữ liệu gốc của người dùng.
• Standard-IA có thời gian lưu tối thiểu: object bị xoá hoặc chuyển tier sớm hơn ngưỡng đó vẫn bị tính tiền cho trọn khoảng tối thiểu.