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

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

Đề mô tả một static, single-page application được người dùng truy cập qua custom domain name, và liệt kê bốn ràng buộc: low-latency, serverless, in-transit data encryption, cost-effective. Câu hỏi chốt lại bằng cụm "the simplest possible solution".

Hai cụm từ quyết định đáp án là "static" và "serverless" — và cụm "simplest possible" dùng để loại nốt những phương án tuy hợp lệ về mặt kỹ thuật nhưng thừa thãi.

• static: không có mã chạy phía máy chủ. Nội dung chỉ là HTML/CSS/JS/ảnh, tức là chỉ cần một nơi lưu trữ đối tượng và một nơi phân phối, không cần compute layer nào cả.
• serverless: loại thẳng mọi phương án dựa trên Amazon EC2.
• in-transit encryption + custom domain: đây chính là lý do phải có CloudFront chứ không chỉ mỗi Amazon S3. Website endpoint của Amazon S3 không phục vụ HTTPS; muốn có HTTPS trên tên miền riêng thì phải đặt CloudFront ở phía trước.

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

Đáp án C — Use Amazon S3 to host the static website and Amazon CloudFront to distribute the content for low latency access.

Cặp Amazon S3 + Amazon CloudFront đáp ứng đủ bốn ràng buộc mà không thêm bất kỳ thành phần nào thừa:

• Serverless: cả hai đều là dịch vụ managed, không có instance nào để vá, để chỉnh kích cỡ hay để trả tiền lúc rảnh.
• Static hosting: bật tính năng static website hosting trên bucket Amazon S3, tải nội dung lên, khai báo index document (và error document nếu cần) — thế là xong phần lưu trữ.
• Low latency: CloudFront cache nội dung tại các edge location trải khắp thế giới. Yêu cầu của khách được điều hướng tới bản sao ở edge gần nhất thay vì đi tới tận Region gốc, nên thời gian tải giảm rõ rệt. Nội dung được giữ ở edge theo khoảng thời gian bạn cấu hình; hết hạn thì CloudFront hỏi lại origin xem có bản mới không.
• In-transit encryption + custom domain: đây là mắt xích quan trọng. Website endpoint của Amazon S3 không hỗ trợ HTTPS. Muốn phục vụ static website qua HTTPS thì cách chính tắc là dùng CloudFront đứng trước bucket. CloudFront cũng là nơi gắn tên miền tuỳ chỉnh.
• Cost-effective: trả tiền theo dung lượng lưu trữ và lưu lượng phục vụ, không phải trả cho compute chạy suốt ngày đêm.

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

A — Amazon EC2 với instance store volume. Sai ngay ở ràng buộc rõ ràng nhất: đề yêu cầu serverless, mà Amazon EC2 thì không phải serverless — bạn vẫn quản lý instance, vẫn vá hệ điều hành, vẫn trả tiền theo thời gian instance chạy. Ngoài ra instance store là ổ đĩa cục bộ gắn liền vòng đời instance, dùng nó làm nơi chứa nội dung website là chọn sai kiểu lưu trữ cho dữ liệu cần bền vững. Instance store nhanh thật, nhưng "nhanh ở phía ổ đĩa" không giải quyết được độ trễ mạng tới người dùng ở xa — thứ mà edge cache mới giải quyết được.

B — Amazon S3 lưu dữ liệu tĩnh + AWS Fargate hosting ứng dụng. Đây là phương án dễ nhầm nhất vì nó đúng về serverless: AWS Fargate là compute engine serverless cho container. Chỗ hỏng nằm ở chữ static. Một single-page application tĩnh không cần tầng compute nào để render hay xử lý request — thêm Fargate là dựng ra một tầng container chỉ để trả về file, tức là thừa cả về độ phức tạp lẫn chi phí (container chạy liên tục thì tính tiền liên tục, khác hẳn mô hình trả theo request/lưu lượng). Nó cũng không tự mang lại low latency toàn cầu: task Fargate chạy trong một Region, không có edge cache. So với tiêu chí "simplest possible solution", phương án này thua rõ.

D — Amazon ECS launch type Fargate + Elastic Load Balancing. Cùng lỗi với B nhưng nặng hơn một bậc, vì thêm hẳn Elastic Load Balancing. Load balancer sinh ra để phân tán request tới một đội compute — ở đây chẳng có logic ứng dụng nào để phân tán cả. Phương án này cũng vẫn là kiến trúc trong một Region: ELB không phải CDN, nó không cache nội dung tại edge, nên chính mục tiêu low-latency toàn cầu vẫn chưa được giải quyết. Tổng lại: phức tạp nhất, tốn nhất, mà vẫn không đáp ứng tiêu chí trung tâm của đề.

📌 Điểm cần nhớ

• Thấy "static website" trong đề thì mặc định nghĩ tới Amazon S3 + Amazon CloudFront trước; mọi phương án cắm thêm tầng compute (EC2, ECS, Fargate) đều đang giải một bài toán mà đề không đặt ra.
• Website endpoint của Amazon S3 không phục vụ HTTPS. Vì vậy hễ đề nhắc in-transit encryption hoặc custom domain có HTTPS cho static site thì CloudFront không còn là tuỳ chọn "cho nhanh hơn" mà là thành phần bắt buộc.
• Serverless ≠ tự động là đáp án đúng. AWS Fargate serverless nhưng vẫn có thể bị loại vì thừa. Khi đề nói "simplest possible" hay "least operational overhead", hãy đếm số thành phần: phương án ít mảnh ghép nhất mà vẫn đủ tiêu chí sẽ thắng.
• Phân biệt CDN với load balancer: CloudFront cache tại edge location gần người dùng nên giảm độ trễ theo khoảng cách địa lý; Elastic Load Balancing chỉ phân phối request trong phạm vi hạ tầng của bạn và không thay thế được vai trò đó.

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

Đề mô tả một công ty dùng Amazon Athena để phân tích ad-hoc dữ liệu khách hàng trong data lake trên Amazon S3. Data engineer muốn hiểu hai thứ cùng lúc:

1. "the detailed breakdown for each of the SQL query's run plan" — chi tiết kế hoạch thực thi của câu truy vấn;
2. "and the computational cost of each operation" — chi phí tính toán của từng phép toán trong truy vấn.

Cụm từ quyết định chính là vế thứ hai: "the computational cost of each operation". Đây là ràng buộc phân biệt hai phương án nhìn rất giống nhau (EXPLAIN và EXPLAIN ANALYZE). Nếu đề chỉ hỏi kế hoạch thực thi thì EXPLAIN đã đủ; nhưng khi đề đòi thêm số liệu chi phí thực tế của từng bước, chỉ còn một câu lệnh đáp ứng được. Cũng cần chú ý: đề hỏi "Athena statements" — tức là câu lệnh SQL chạy ngay trong Athena, không phải một dịch vụ hay công cụ bên ngoài.

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

A. EXPLAIN ANALYZE

EXPLAIN ANALYZE là câu lệnh thực sự chạy truy vấn rồi trả về cả hai thứ đề yêu cầu: kế hoạch thực thi phân tán (distributed execution plan) của câu lệnh SQL và chi phí tính toán của từng phép toán trong truy vấn đó. Kết quả xuất ra được ở dạng text hoặc JSON.

Điểm đắt giá với Athena: đầu ra của EXPLAIN ANALYZE kèm theo số lượng dữ liệu đã quét (scanned data count) cho từng bước. Vì Athena tính tiền theo lượng dữ liệu quét, con số này giúp quản trị viên nhìn ra chỗ nào trong truy vấn đang ngốn dữ liệu, từ đó tối ưu và kiểm soát chi phí — đúng với ý "computational cost of each operation" trong đề.

Nói gọn: EXPLAIN = kế hoạch, EXPLAIN ANALYZE = kế hoạch cộng số đo thực tế của từng operation.

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

C. EXPLAIN — đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. EXPLAIN chỉ đưa ra chi tiết kế hoạch thực thi (run plan) của truy vấn. Bạn có thể đọc kế hoạch đó để giảm độ phức tạp truy vấn và cải thiện thời gian chạy, và cũng có thể dùng EXPLAIN để kiểm tra cú pháp SQL trước khi chạy thật, tránh lỗi giữa chừng. Nhưng nó dừng ở mức mô tả kế hoạch — không kèm chi phí tính toán của từng phép toán, vì nó không thực sự thực thi truy vấn để đo. Đề yêu cầu cả hai vế nên EXPLAIN chỉ đáp ứng được một nửa, và đáp ứng một nửa thì sai.

B. PREPARE — câu lệnh này tạo một câu lệnh SQL có tên (statement_name) để chạy vào lúc khác; câu lệnh có thể chứa tham số biểu diễn bằng dấu hỏi chấm. Đây là cơ chế truy vấn tham số hoá / dùng lại truy vấn, hoàn toàn không liên quan tới việc xem kế hoạch thực thi hay đo chi phí. Nó thuộc nhóm "chuẩn bị để chạy sau", không phải nhóm chẩn đoán hiệu năng.

D. OPTIMIZE — nghe rất hợp với chữ "tối ưu" nhưng làm việc khác hẳn: nó tối ưu các dòng trong bảng Apache Iceberg bằng cách ghi lại (rewrite) các data file thành bố cục tối ưu hơn, dựa trên kích thước file và số lượng delete file đi kèm. Đây là thao tác bảo trì dữ liệu vật lý ở tầng lưu trữ, hoàn toàn không trả về thông tin chẩn đoán nào về câu truy vấn. Chọn nó là nhầm giữa "tối ưu dữ liệu" và "phân tích truy vấn".

📌 Điểm cần nhớ

• EXPLAIN vs EXPLAIN ANALYZE trong Athena: EXPLAIN chỉ cho kế hoạch thực thi (và kiểm tra cú pháp trước khi chạy); EXPLAIN ANALYZE chạy thật rồi cho kế hoạch kèm chi phí/số liệu của từng operation. Thấy đề nhắc tới "cost", "runtime statistics", "data scanned per operation" → chọn EXPLAIN ANALYZE.
• Với Athena, lượng dữ liệu quét chính là chi phí. Bất kỳ câu hỏi nào nói về kiểm soát chi phí truy vấn ad-hoc trên S3 đều xoay quanh việc giảm dữ liệu phải quét, và EXPLAIN ANALYZE là công cụ đo con số đó ở mức từng bước.
• PREPARE thuộc nhóm chuẩn bị/tham số hoá truy vấn, không phải nhóm chẩn đoán — đừng để chữ "statement" trong đề kéo sang nó.
• OPTIMIZE là bảo trì bảng Iceberg (rewrite data file theo kích thước và số delete file), tác động lên dữ liệu chứ không phân tích truy vấn. Cẩn thận với các phương án mà tên gọi trùng nghĩa đời thường ("optimize") nhưng phạm vi kỹ thuật lại khác.

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

Đề mô tả một chuỗi cửa hàng chăm sóc thú cưng, toàn bộ dữ liệu nằm trong một Amazon S3 bucket và được truy vấn bằng Amazon Athena. Dữ liệu ở mức hàng chục terabyte, và yêu cầu là giảm chi phí chạy các truy vấn này.

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

1. "uses Amazon Athena" — Athena tính tiền theo lượng dữ liệu quét từ S3 cho mỗi truy vấn. Muốn giảm chi phí thì phải giảm số byte bị quét, chứ không phải đổi công cụ.
2. "analyze customer preferences to launch new products for the different types of pets" — đây là cụm từ phân biệt các phương án partition với nhau. Nó cho biết cột lọc chính trong các truy vấn là loại thú cưng (pet type).

Partition trong Athena chỉ có tác dụng khi khoá partition trùng với cột hay xuất hiện trong mệnh đề WHERE. Vì vậy câu hỏi thực chất là: "truy vấn của họ lọc theo cột nào?" — và đề đã nói thẳng: theo types of pets.

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

D — Partition the data by pet type.

Khi dữ liệu trên S3 được partition, Athena chỉ đọc những prefix tương ứng với giá trị partition mà truy vấn yêu cầu, thay vì quét toàn bộ dataset. Với khối lượng hàng chục terabyte, phần dữ liệu bị loại bỏ nhờ partition pruning là rất lớn — vừa nhanh hơn vừa rẻ hơn, vì Athena tính tiền theo dữ liệu quét.

Bạn có thể partition theo bất kỳ khoá nào. Thực tế phổ biến là partition theo thời gian (year/month/day/hour) tạo thành sơ đồ nhiều tầng, hoặc theo nguồn dữ liệu kết hợp với ngày. Nhưng khoá tốt nhất luôn là khoá mà truy vấn thực tế lọc theo. Ở đây, phần lớn truy vấn phục vụ việc phân tích sản phẩm mới theo từng loại thú cưng, nên câu lệnh sẽ có dạng lọc theo pet type; partition theo chính cột đó khiến Athena chỉ quét đúng phần dữ liệu của loại thú cưng đang xét.

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

A — Partition the data by store region. Đây là một khoá partition hợp lệ về mặt kỹ thuật, và trong một bài toán khác (so sánh doanh thu giữa các vùng) nó sẽ là lựa chọn đúng. Nhưng ở đây truy vấn không lọc theo region — nó lọc theo loại thú cưng. Partition theo region mà truy vấn không có điều kiện region trong WHERE thì Athena vẫn phải quét mọi partition, tức là toàn bộ dataset, và chi phí không giảm. Đó chính là chỗ nó hỏng: partition sai khoá gần như không đem lại lợi ích nào.

C — Partition the data by customer. Sai vì cùng lý do với A, và còn tệ hơn ở một điểm nữa: customer là cột có cardinality rất cao. Partition theo nó sẽ sinh ra một số lượng partition khổng lồ, mỗi partition chứa rất ít dữ liệu — dẫn tới vô số file nhỏ trên S3 và chi phí quản lý metadata lớn, trong khi các truy vấn phân tích theo loại thú cưng vẫn phải chạm vào tất cả. Nó vừa không giúp giảm dữ liệu quét, vừa làm bố cục dữ liệu xấu đi.

B — Migrate the data to Redshift tables for a more cost-efficient analysis. Đây là phương án gần đúng nhất về mặt "nghe hợp lý", vì Redshift đúng là engine phân tích mạnh. Nhưng nó hỏng ở đúng mục tiêu đề đặt ra: giảm chi phí. Chuyển hàng chục terabyte sang Redshift nghĩa là phải duy trì một cluster có dung lượng lưu trữ và tính toán riêng, tốn kém hơn so với việc để nguyên dữ liệu trên S3 và truy vấn bằng Athena. Ngoài ra, đây là thay đổi kiến trúc lớn (di chuyển dữ liệu, dựng schema, đổi cách kết nối) trong khi vấn đề có thể xử lý bằng một thay đổi về cách sắp xếp dữ liệu. Đề chỉ xin giảm chi phí truy vấn, không xin đổi nền tảng.

📌 Điểm cần nhớ

• Athena tính tiền theo lượng dữ liệu quét từ S3. Mọi câu hỏi "giảm chi phí Athena" đều quy về: làm sao quét ít byte hơn — partition, chọn định dạng cột như Parquet/ORC, nén dữ liệu.
• Partition chỉ có giá trị khi khoá partition trùng với cột trong mệnh đề WHERE. Partition sai khoá thì Athena vẫn quét toàn bộ; đó là lý do A và C bị loại dù đều là partition.
• Đọc đề để tìm cột lọc chính. Khi nhiều phương án cùng là "partition by X", cụm từ mô tả mục tiêu phân tích (ở đây là different types of pets) chính là chỗ chỉ ra X đúng.
• Tránh chọn khoá partition có cardinality quá cao (customer id, user id): sinh quá nhiều partition nhỏ, gây vấn đề file nhỏ và metadata thay vì tiết kiệm.
• Đổi engine không phải cách rẻ nhất để giảm chi phí truy vấn. Khi dữ liệu đã nằm trên S3 và câu hỏi chỉ nói về chi phí, tối ưu bố cục dữ liệu thường thắng phương án di chuyển sang một hệ thống có cluster riêng.

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

Bối cảnh: nhiều khách hàng doanh nghiệp dùng mobile app để đẩy dữ liệu vào Amazon Kinesis Data Streams, và phía producer đang nhận ProvisionedThroughputExceededException. Khi phân tích, kỹ sư phát hiện "messages are being sent one by one at a high rate" — bản ghi được gửi từng cái một với tần suất rất cao.

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

• "sent one by one at a high rate" — đây là chẩn đoán nguyên nhân, không phải triệu chứng chung chung. Vấn đề nằm ở cách producer gọi API (mỗi bản ghi một lời gọi PutRecord), chứ không phải ở việc stream thiếu năng lực xử lý dữ liệu.
• "while keeping costs at a minimum" — ràng buộc chi phí. Cụm này tồn tại để loại chính xác một phương án: cái nào giải quyết được vấn đề nhưng bằng cách mua thêm năng lực.

Kinesis Data Streams giới hạn throughput trên mỗi shard theo hai chiều: theo dung lượng dữ liệu, và theo số lượng lời gọi/bản ghi ghi vào mỗi giây. Gửi từng bản ghi một sẽ chạm trần ở chiều thứ hai (số request) trong khi dung lượng thực tế còn thừa rất nhiều — shard chưa hề bị dùng hết mà exception đã nổ. Nhận ra điều đó là chìa khoá của câu này.

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

A — Use batch messages.

Khi một producer cần đẩy nhiều bản ghi mỗi giây, gọi PutRecord trong vòng lặp là cách làm không đủ: mỗi bản ghi tiêu một suất trong hạn mức request của shard, cộng thêm toàn bộ chi phí cố định của một lời gọi HTTP riêng lẻ. Gom nhiều bản ghi lại rồi gửi theo lô (PutRecords, hoặc để Kinesis Producer Library tự gom và gửi song song) làm giảm mạnh số lời gọi trên cùng một lượng dữ liệu — nhiều bản ghi giờ nằm gọn trong một request.

Đây là sửa đúng chỗ hỏng mà đề đã chỉ ra: đề nói bản ghi đi từng cái một, batching biến nó thành đi theo cụm. Và nó thoả ràng buộc chi phí — không thêm shard, không thêm hạ tầng, chỉ đổi cách producer gọi API. Kết quả là dùng shard hiện có một cách tối ưu hơn thay vì mua thêm shard.

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

B — Use Exponential Backoff. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Backoff là thực hành đúng khi gặp throttling: gặp lỗi thì chờ rồi thử lại với khoảng chờ tăng dần, giúp hệ thống không tự dồn ép mình thêm. Nhưng nó chỉ xử lý hậu quả, không đụng tới nguyên nhân — số lời gọi mỗi giây vẫn y nguyên. Ngay khi nhịp gửi tăng trở lại, ProvisionedThroughputExceededException xuất hiện lại. Ngoài ra, việc thử lại còn kéo theo độ trễ và nguy cơ tồn đọng dữ liệu ở phía producer. Backoff nên có, nhưng không phải câu trả lời cho "làm gì để hết lỗi này".

C — Increase the number of shards. Thêm shard đúng là nâng trần throughput và có thể làm lỗi biến mất trong ngắn hạn. Nhưng shard là đơn vị tính tiền của Kinesis Data Streams: thêm shard là thêm chi phí liên tục, va thẳng vào ràng buộc "keeping costs at a minimum" trong đề. Tệ hơn về mặt kỹ thuật: nút thắt ở đây là số request, không phải dung lượng dữ liệu, nên bạn đang trả tiền cho năng lực mà pattern gửi từng bản ghi vẫn lãng phí. Sửa producer trước, mở rộng shard chỉ khi lượng dữ liệu thật sự vượt năng lực.

D — Decrease the Stream retention duration. Sai hoàn toàn về mặt cơ chế. Retention là khoảng thời gian dữ liệu được giữ lại trong stream cho consumer đọc, hoàn toàn tách biệt với giới hạn ghi vào. Giảm retention không làm tăng thêm một request nào cho phía producer, nên exception vẫn nguyên. Đổi lại còn gây hại: consumer chậm hoặc gặp sự cố sẽ mất luôn dữ liệu chưa kịp đọc. Đây là phương án vừa không giải quyết vấn đề vừa tạo rủi ro mới.

📌 Điểm cần nhớ

• ProvisionedThroughputExceededException trên Kinesis Data Streams nghĩa là đã vượt hạn mức của shard, và hạn mức đó tính theo cả dung lượng dữ liệu lẫn số bản ghi/lời gọi ghi mỗi giây. Đề nhắc "gửi từng cái một" là tín hiệu chiều thứ hai đang bị chạm, không phải chiều dung lượng.
• Batching (PutRecords / Kinesis Producer Library) là câu trả lời mặc định cho producer gọi API quá dày. Nó sửa nguyên nhân và không tốn thêm tiền hạ tầng.
• Cụm "keeping costs at a minimum" trong đề gần như luôn để loại phương án "thêm shard / thêm capacity". Có ràng buộc chi phí thì ưu tiên tối ưu cách dùng tài nguyên hiện có trước khi mở rộng.
• Phân biệt rõ giảm nhẹ triệu chứng (exponential backoff) với sửa nguyên nhân (batching). Đề hỏi "cái gì giúp khắc phục exception" thì chọn cái sửa gốc; backoff là lớp bảo vệ bổ sung, không phải giải pháp.
• Stream retention duration không liên quan gì đến giới hạn ghi. Nó chỉ chi phối thời gian consumer còn đọc được dữ liệu — đụng vào nó khi bị throttle là đi nhầm hướng và có thể mất dữ liệu.

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

Đề mô tả một truy vấn Amazon Athena chạy chậm, trong đó có phép join giữa hai bảng theo điều kiện bằng (equality condition). Cụm từ quyết định nằm ở phần mô tả dữ liệu: "one of the tables is large with millions of rows of data and the other table is small" — hai bảng lệch nhau rất nhiều về kích thước, cộng với "join ... using the equality condition".

Hai chi tiết đó gộp lại chỉ đúng một hướng: đây là bài toán thứ tự bảng trong phép join, không phải bài toán cấu hình hay phiên bản engine. Khi đề đã nói rõ join là equality join và hai bảng lệch cỡ, câu hỏi thực chất là: bảng nhỏ nên nằm bên nào?

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

B — Specify the larger table on the left side of the join and the smaller table on the right side.

Với dạng join phổ biến nhất là equality join, Athena thực hiện distributed hash join: nó xây một lookup table (bảng băm) từ bảng nằm bên PHẢI rồi phân phối bảng băm đó tới các worker node. Sau đó Athena stream bảng bên TRÁI qua, mỗi dòng đọc tới đâu thì tra vào lookup table để tìm dòng khớp tới đó.

Điểm mấu chốt: lookup table được giữ trong bộ nhớ của worker. Bảng bên phải càng nhỏ thì bảng băm càng nhỏ, tốn ít bộ nhớ hơn và join chạy nhanh hơn. Vì vậy quy tắc là: bảng lớn ở bên trái (được stream), bảng nhỏ ở bên phải (được băm).

Đây đúng là khuyến nghị tối ưu join của Athena — đặt bảng lớn bên trái, bảng nhỏ bên phải.

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

A — Specify the smaller table on the left side of the join and the larger table on the right side. Đây là phương án gần đúng nhất, và cũng là bẫy chính: nó nhận ra đúng vấn đề (thứ tự bảng) nhưng đảo ngược đúng chiều cần thiết. Đặt bảng lớn hàng triệu dòng ở bên phải nghĩa là Athena sẽ cố dựng lookup table từ chính bảng khổng lồ đó và giữ nó trong bộ nhớ của các worker node — tiêu tốn bộ nhớ lớn, join chậm đi, và trong trường hợp xấu có thể gây áp lực bộ nhớ. Nói cách khác, A không phải "kém tối ưu hơn một chút" mà là làm đúng ngược lại điều cần làm.

C — Update the Athena workgroup settings ... most stable version of Athena engine. Workgroup là công cụ để tách người dùng, nhóm, ứng dụng hay workload ra khỏi nhau: đặt giới hạn lượng dữ liệu mỗi truy vấn hoặc cả workgroup được quét, theo dõi chi phí, gắn IAM policy ở mức tài nguyên để kiểm soát quyền truy cập, xem metric trong Amazon CloudWatch và bắn cảnh báo qua Amazon SNS khi vượt ngưỡng. Không có mục nào trong danh sách đó chạm tới cách Athena sắp xếp phép join. Đề bài đã chỉ rõ nguyên nhân chậm nằm ở cấu trúc truy vấn, nên chọn "phiên bản ổn định" chỉ là một thao tác cấu hình không liên quan.

D — Update the Athena workgroup settings ... latest version of Athena engine. Athena có phát hành engine version mới theo thời gian để cải thiện hiệu năng, bổ sung tính năng và sửa lỗi; bạn có thể để Athena tự quyết định thời điểm nâng cấp hoặc chỉ định engine version thủ công theo từng workgroup. Nhưng đây vẫn không phải điều đề đang hỏi: vấn đề trong tình huống này là thứ tự bảng trong một equality join giữa hai bảng lệch cỡ, chuyện mà đổi engine version không sửa được. C và D được đặt vào chỉ để làm nhiễu — chúng nghe rất "hành động kỹ thuật" và lại là một cặp đối xứng (stable ↔ latest), khiến thí sinh dễ mất thời gian so sánh hai cái vô nghĩa với nhau thay vì nhìn lại phép join.

📌 Điểm cần nhớ

• Trong Athena, equality join = distributed hash join: bảng bên phải được dựng thành lookup table giữ trong bộ nhớ, bảng bên trái được stream qua. Nhớ đúng chiều này là trả lời được cả họ câu hỏi về thứ tự join.
• Quy tắc rút gọn để thuộc: bảng lớn bên trái, bảng nhỏ bên phải — vì thứ nằm trong RAM là bảng bên phải, càng nhỏ càng tốt.
• Khi đề bài mô tả hai bảng lệch cỡ rõ rệt, đó là tín hiệu hướng tới tối ưu ở tầng cách viết truy vấn, không phải tầng cấu hình dịch vụ.
• Workgroup trong Athena giải quyết chuyện tách workload, giới hạn dữ liệu quét, kiểm soát chi phí và phân quyền — không phải công cụ tăng tốc một truy vấn viết chưa tối ưu. Gặp phương án "đổi engine version / đổi workgroup settings" cho một câu về hiệu năng truy vấn, hãy nghi ngờ đó là distractor.

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

Đội data engineering đã đưa clickstream data vào raw zone của data lake trên Amazon S3, và giờ muốn chạy các SQL-based data sanity check trên chính vùng dữ liệu thô đó.

Cụm từ quyết định đáp án nằm ở câu hỏi cuối: giải pháp phải cost-effective and easy to maintain. Thêm một chi tiết nữa cũng quan trọng: dữ liệu đã nằm sẵn trên S3. Ghép hai điều kiện này lại thì câu hỏi thực chất là: "chạy SQL ngay tại chỗ, hay bốc dữ liệu đi nơi khác rồi mới chạy SQL?"

Ba phương án A, B, C đều bắt đầu bằng chữ "Load the incremental raw zone data into..." — nghĩa là mỗi phương án đều thêm một bước sao chép dữ liệu định kỳ hằng giờ, cộng thêm một hệ thống phải nuôi. Phương án D không load gì cả. Đây chính là chỗ phân biệt: sanity check là việc kiểm tra nhẹ, không đáng để dựng cả một đường ống ETL và một cluster chỉ để phục vụ nó.

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

D — Use Amazon Athena to run SQL based analytics against Amazon S3 data.

Athena là interactive query service cho phép chạy standard SQL trực tiếp trên dữ liệu đang nằm ở Amazon S3, không cần di chuyển hay nạp dữ liệu vào đâu khác. Đúng ngay hình dạng bài toán: dữ liệu đã ở S3, việc cần làm là chạy SQL lên nó.

Athena là dịch vụ serverless — không có cluster, không có instance, không có node nào để cấp phát, vá lỗi hay chỉnh kích thước. Về chi phí, mô hình của Athena là trả tiền theo truy vấn đã chạy, nên với công việc sanity check chạy rời rạc thì không phải nuôi hạ tầng nằm không giữa các lần chạy. Hai điểm đó khớp thẳng vào hai yêu cầu cost-effective và easy to maintain của đề.

Ngoài ra Athena vốn được dùng đúng cho các việc kiểu này: xử lý log, phân tích ad-hoc và chạy truy vấn tương tác — mà kiểm tra tính đúng đắn của clickstream data mới nạp về chính là một dạng phân tích ad-hoc.

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

A — Load vào Amazon Redshift hằng giờ rồi chạy SQL. Redshift là data warehouse quản lý hoàn toàn, dựng cho việc lưu trữ và phân tích tập dữ liệu rất lớn. Nó chạy được SQL sanity check, nên đây là phương án gần đúng nhất về mặt kỹ thuật — nhưng nó hỏng ở phần vận hành: đội phát triển phải theo dõi và chỉnh kích thước cluster Redshift, đồng thời phải bỏ công sức đáng kể để dựng quy trình nạp dữ liệu định kỳ. Đó đúng là hai thứ mà đề nói phải tránh. Dùng một data warehouse cho việc kiểm tra tính hợp lệ của raw zone cũng là dùng quá tay so với nhu cầu.

B — Load vào Amazon RDS hằng giờ rồi chạy SQL. Nạp dữ liệu tăng dần vào RDS đồng nghĩa với việc phải tự viết job migration — qua AWS Lambda function hoặc một tiến trình chạy trên Amazon EC2. Đó là code phải viết, phải chạy và phải bảo trì mãi về sau, đi ngược yêu cầu "ít công sức phát triển và bảo trì nhất". Chưa kể RDS là cơ sở dữ liệu giao dịch, không phải nơi tự nhiên để soi khối lượng lớn clickstream data thô.

C — Load vào cluster Spark trên Amazon EMR hằng giờ rồi dùng SparkSQL. EMR là nền tảng big data mạnh, chạy các công cụ mã nguồn mở như Apache Spark, Hive, HBase, Flink, Hudi, Presto, phân tán dữ liệu và tính toán trên một cụm EC2 co giãn được. SparkSQL hoàn toàn viết được các phép kiểm tra cần thiết, nên phương án này cũng "chạy được". Nhưng dùng EMR nghĩa là phải quản lý hạ tầng bên dưới — cụm máy, kích thước cụm, vòng đời cụm. Với một việc chỉ đơn giản là chạy vài câu SQL kiểm tra, đó là gánh nặng vận hành không cần thiết, nên bị loại theo đúng tiêu chí của đề.

📌 Điểm cần nhớ

• Đề nói dữ liệu đã ở S3 + hỏi SQL + nhấn cost-effective / easy to maintain → gần như luôn là Athena. Truy vấn tại chỗ, khỏi di chuyển dữ liệu.
• Cảnh giác với mọi phương án mở đầu bằng "Load the data into...": mỗi lần load là thêm một đường ống phải viết và một hệ thống phải nuôi. Khi tiêu chí là công sức bảo trì thấp nhất, đó thường là dấu hiệu của đáp án sai chứ không phải đáp án đúng.
• "Chạy được" khác "phù hợp nhất". Redshift, RDS và EMR đều chạy được SQL; chúng bị loại vì chi phí vận hành, không phải vì bất khả thi. Đề dạng "recommend ... such that" luôn chọn theo ràng buộc phụ, không chọn theo tính khả thi.
• Phân biệt vai trò: Athena cho truy vấn ad-hoc/tương tác trên S3, Redshift cho data warehouse quy mô lớn, EMR cho xử lý big data bằng framework mã nguồn mở, RDS cho cơ sở dữ liệu giao dịch. Sanity check trên raw zone rơi vào nhóm ad-hoc.

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

Đề mô tả một công ty đang thiết kế lại một real-time data processor và nêu rõ mong muốn: "build custom applications that process and analyze the streaming data for its specialized needs".

Cụm từ quyết định nằm gọn ở đó: "custom applications" + "process and analyze". Nó không nói "đưa dữ liệu vào S3", cũng không nói "gửi thông báo" hay "xếp hàng công việc" — nó nói người dùng sẽ tự viết ứng dụng tiêu thụ dòng dữ liệu và tự xử lý theo nhu cầu riêng. Kèm theo đó là yêu cầu decouple producers và consumers cho một luồng streaming liên tục.

Ràng buộc này loại bỏ mọi lựa chọn không cho phép ứng dụng tự viết đọc trực tiếp dòng dữ liệu, và loại bỏ luôn những dịch vụ vốn dành cho messaging/notification chứ không phải streaming.

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

B — Amazon Kinesis Data Streams.

Kinesis Data Streams được thiết kế đúng cho việc đưa dữ liệu ra khỏi producer thật nhanh rồi xử lý liên tục: biến đổi dữ liệu trước khi ghi vào data store, tính metrics và phân tích thời gian thực, hoặc dựng ra các luồng dữ liệu phức tạp hơn để xử lý tiếp.

Nó thu nhận liên tục lượng dữ liệu rất lớn mỗi giây từ rất nhiều nguồn — website clickstream, database event stream, giao dịch tài chính, social media feed, IT log, dữ liệu định vị. Điểm mấu chốt khớp với đề: consumer là ứng dụng do bạn tự viết, đọc trực tiếp từ stream và xử lý theo logic riêng. Đó chính là "custom applications ... for its specialized needs".

Đồng thời stream đứng giữa nên producer và consumer không phụ thuộc nhau — đúng phần "decouple" mà đề yêu cầu.

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

A — Amazon SQS. SQS là hosted queue: an toàn, bền, sẵn sàng cao, dùng để tích hợp và tách rời các thành phần phần mềm phân tán. Nhưng nó là hàng đợi thông điệp, không phải nền tảng streaming để nhiều ứng dụng phân tích cùng đọc và xử lý một dòng dữ liệu liên tục. SQS không dùng được để decouple producer–consumer cho real-time data processor như tình huống trong đề. Đây là phương án dễ nhầm nhất vì chữ "decouple" — nhưng đề còn đòi process and analyze streaming data, phần đó SQS không đáp ứng.

C — Amazon SNS. SNS là dịch vụ pub/sub messaging được quản lý hoàn toàn, dùng để tách rời microservice, hệ thống phân tán và ứng dụng serverless. Nó đẩy thông báo tới subscriber chứ không phải nơi ứng dụng tự viết đọc và phân tích một luồng dữ liệu streaming. Với use case trong đề, SNS không dùng được để decouple producer và consumer của real-time data processor.

D — Amazon Kinesis Data Firehose. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó thuộc cùng họ Kinesis, cũng làm việc với streaming data, cũng cho near real-time analytics. Chỗ nó hỏng là vai trò: Firehose là cách đơn giản nhất để nạp streaming data vào data store và công cụ phân tích — capture, transform rồi load vào Amazon S3, Amazon Redshift, Amazon Elasticsearch Service, Splunk. Nó là delivery stream, không phải nơi để ứng dụng tự viết đọc ra và xử lý. Firehose không dùng được để process và analyze streaming data trong custom application như đề yêu cầu.

📌 Điểm cần nhớ

• Thấy "custom applications" đọc và xử lý streaming data → nghĩ ngay tới Kinesis Data Streams. Thấy "load/deliver vào S3, Redshift, OpenSearch, Splunk" → nghĩ tới Kinesis Data Firehose. Cùng họ Kinesis nhưng khác vai trò hoàn toàn.
• Chữ "decouple" một mình không đủ để chọn SQS hay SNS. Phải đọc tiếp: nếu đề đòi process and analyze một dòng dữ liệu liên tục thì đó là bài toán streaming, không phải bài toán queue hay pub/sub.
• SQS = hàng đợi (tích hợp, tách rời thành phần), SNS = pub/sub đẩy thông báo. Cả hai là messaging, không phải nền tảng streaming analytics.
• Firehose thiên về near real-time và nạp dữ liệu đi nơi khác; Data Streams thiên về xử lý liên tục ngay trên luồng với logic do bạn viết. Đề nhấn "real-time" + "custom" là dấu hiệu chọn Data Streams.

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

Đề mô tả một Amazon Redshift provisioned cluster gồm bốn node ra3, đang dùng key distribution. Triệu chứng: một node chạy CPU trên 90% gần như liên tục, ba node còn lại chỉ khoảng 10%. Đây là mô tả kinh điển của distribution skew — dữ liệu bị dồn về một node slice thay vì trải đều.

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

• "the cluster uses key distribution" — tức là dòng dữ liệu được phân bổ theo giá trị của một cột duy nhất (distribution key). Nguyên nhân lệch tải nằm ngay ở cột đó, chứ không nằm ở sort key hay ở kích thước cluster.
• "if provisioning additional nodes is not an option" — cấm mọi phương án làm phình dung lượng hoặc đòi thêm node. Cụm này chính là thứ loại phương án ALL distribution.

Nói cách khác: đề hỏi thay đổi cấu hình nào chữa được skew mà không đụng tới số node.

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

A — The distribution key should be changed to the table column that has the largest dimension.

Trong key distribution, leader node băm giá trị của distribution key và đặt các dòng có cùng giá trị lên cùng một slice. Hệ quả trực tiếp: nếu cột được chọn làm distribution key có ít giá trị phân biệt (low cardinality) hoặc có vài giá trị chiếm tỷ trọng áp đảo, thì phần lớn dòng rơi vào một số ít slice — đúng hình ảnh một node 90% CPU còn ba node ngồi không.

Chọn distribution key là cột có dimension lớn nhất, tức cột có nhiều giá trị phân biệt và phân bố đều hơn, làm cho dữ liệu trải đều ra các slice, kéo theo khối lượng tính toán cũng trải đều. Đây là cách chữa skew đúng tầng vấn đề: sửa chính tiêu chí phân bổ dữ liệu.

Thêm một lợi ích mà giải thích nguồn nhấn mạnh: khi hai bảng cùng được phân bổ theo cột dùng để JOIN, các dòng khớp nhau được collocated trên cùng slice, nên Redshift không phải chuyển dữ liệu qua lại giữa các node lúc join. Vừa cân tải, vừa giảm data movement — và không cần thêm node nào.

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

B — Change the distribution style to ALL for the cluster. Đây là phương án gần đúng nhất và cũng là bẫy chính. ALL distribution đúng là loại bỏ skew theo nghĩa mỗi node đều có bản sao đầy đủ của bảng, nên mọi join đều collocated. Nhưng nó nhân dung lượng lưu trữ lên theo số node, khiến việc load, update và insert chậm đi đáng kể. ALL chỉ hợp với bảng nhỏ, ít thay đổi (bảng tra cứu, dimension chậm biến động), chứ không phải áp cho cả cluster. Và vì nó ngốn thêm dung lượng, nó dẫn tới đúng cái mà đề đã cấm: phải cấp thêm node.

C — Update the sort key to equal distribution key. Sort key quyết định thứ tự lưu dòng trên đĩa trong mỗi slice, không quyết định dòng đó nằm ở slice nào. Đặt sort key trùng distribution key không di chuyển một dòng dữ liệu nào sang node khác, nên phân bố vẫn lệch y nguyên. Phương án này nhắm sai tầng: nó tối ưu việc quét dữ liệu, không tối ưu việc chia dữ liệu.

D — Configure the sort key to be the column most used in JOIN of tables. Phương án này trộn lẫn hai quy tắc. Cột hay dùng trong JOIN đúng là cột nên cân nhắc, nhưng nó thuộc về DISTKEY, không thuộc về SORTKEY. Quy tắc chung: đặt DISTKEY theo cột hay dùng trong JOIN, đặt SORTKEY theo cột hay dùng trong mệnh đề WHERE. Gán cột join cho sort key giúp query planner chút ít về thứ tự đọc, nhưng vẫn không đổi cách dòng được rải ra các slice — skew vẫn còn nguyên.

📌 Điểm cần nhớ

• Triệu chứng lệch tải CPU giữa các node trong Redshift = distribution skew. Chỗ cần sửa là distribution key hoặc distribution style, không phải sort key.
• Phân biệt hai khái niệm cho chắc: DISTKEY quyết định dòng nằm ở node/slice nào; SORTKEY quyết định dòng được lưu theo thứ tự nào bên trong slice. Câu hỏi về cân tải luôn thuộc về vế đầu.
• Quy tắc chọn key: DISTKEY ưu tiên cột hay dùng trong JOIN và có cardinality cao, phân bố đều; SORTKEY ưu tiên cột hay xuất hiện trong WHERE.
• ALL distribution có cái giá là dung lượng. Nó nhân bản cả bảng lên mọi node và làm chậm ghi, nên chỉ dùng cho bảng nhỏ, ít cập nhật. Hễ đề ràng buộc "không thêm node" hoặc "không tăng chi phí lưu trữ" thì ALL gần như chắc chắn là bẫy.

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

Đề mô tả một hãng tin: phóng viên upload và download các tệp video ~500 MB lên/xuống một Amazon S3 bucket. Khi mở thêm văn phòng ở các vị trí xa, độ trễ tăng lên cho cả hai chiều. Câu hỏi yêu cầu chọn hai giải pháp cải thiện hiệu năng.

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

1. "upload/download ... to/from" — giải pháp phải tăng tốc cả chiều ghi lẫn chiều đọc, không chỉ chiều đọc.
2. "wants to continue using a serverless storage solution such as Amazon S3" — mọi phương án kéo Amazon EC2, Amazon EBS vào đều bị loại ngay từ ràng buộc này, bất kể nó có nhanh hay không.
3. "remote locations" / "poor latency" — vấn đề nằm ở khoảng cách địa lý tới bucket, tức là đường truyền qua Internet công cộng, chứ không phải bucket chậm.

Ba ràng buộc này gộp lại chỉ còn đúng hai kỹ thuật trong danh sách: một CDN đặt trước S3, và tính năng tăng tốc truyền của chính S3.

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

A — Amazon CloudFront với origin là Amazon S3 bucket. CloudFront là CDN có mạng lưới edge location toàn cầu. Người dùng ở văn phòng xa kết nối tới edge gần mình thay vì đi thẳng tới region chứa bucket; phần đường còn lại đi trên mạng backbone của AWS thay vì Internet công cộng. Với chiều download, nội dung còn được cache tại edge nên các lượt lấy lại cùng tệp video phục vụ ngay tại chỗ. Điểm nhiều người bỏ sót — và cũng là lý do phương án này hợp lệ ở đây: CloudFront hỗ trợ cả các phương thức ghi (POST/PUT), nên upload cũng được đẩy qua edge và hưởng cùng đường truyền tối ưu. Đúng yêu cầu "speed up uploads as well as downloads", và bucket vẫn là S3 nên vẫn serverless.

B — Amazon S3 Transfer Acceleration (Amazon S3TA). Đây là tính năng bật ngay trên bucket, tận dụng chính hệ thống edge location của CloudFront: dữ liệu vào edge gần nhất rồi đi tiếp tới S3 qua đường mạng đã được tối ưu của AWS. S3TA sinh ra đúng cho tình huống trong đề — object lớn, truyền đường dài, và có tác dụng cho cả hai chiều. Bật xong chỉ cần đổi endpoint khi gọi, không thêm hạ tầng nào phải quản lý, nên vẫn giữ nguyên tính serverless mà hãng tin yêu cầu.

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

C — Amazon EC2 ở mỗi region kèm job hằng ngày copy dữ liệu S3 xuống Amazon EBS. Hỏng ở hai chỗ. Thứ nhất, nó vi phạm thẳng ràng buộc "serverless": giờ phải vận hành EC2 instance và EBS volume ở từng văn phòng. Thứ hai, job chạy hằng ngày nghĩa là dữ liệu ở xa luôn cũ, mà phóng viên làm việc theo tin tức trong ngày. Và nó chỉ giải quyết chiều đọc — phóng viên vẫn phải upload video 500 MB về bucket trung tâm với đúng độ trễ cũ.

D — Tạo bucket S3 riêng ở mỗi region có văn phòng. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất: nó có giữ được tính serverless và có rút ngắn khoảng cách. Chỗ hỏng là nó phá vỡ kho lưu trữ tập trung: mỗi văn phòng giữ một bản riêng, không còn một nguồn sự thật duy nhất cho kho media, và bài toán đồng bộ giữa các bucket phát sinh thêm thay vì được giải. Đề chỉ than phiền về hiệu năng, không hề yêu cầu tách kho dữ liệu — chọn D là đổi kiến trúc lưu trữ để chữa một vấn đề mạng.

E — Chuyển dữ liệu sang Amazon EFS ở một US region, truy cập từ Amazon EC2 ở region khác qua inter-region VPC peering. Sai ở cả hai mặt. Về ràng buộc: phải dựng EC2 để mount EFS, hết serverless, và đề nói rõ hãng tin muốn tiếp tục dùng S3. Về hiệu năng: dữ liệu vẫn nằm ở một US region, truy cập từ region khác vẫn phải đi hết quãng đường địa lý đó — chỉ là đi qua VPC peering thay vì gọi S3 API. Đường xa không hề ngắn lại, mà còn cộng thêm một tầng hạ tầng phải quản lý.

📌 Điểm cần nhớ

• Đề bài nhắc "serverless" là một bộ lọc cứng: gạch ngay mọi phương án có EC2, EBS, hay bất cứ thứ gì phải tự vận hành, trước khi cân nhắc hiệu năng.
• Phân biệt "tăng tốc download" với "tăng tốc cả upload lẫn download". Cả CloudFront lẫn S3 Transfer Acceleration đều xử lý được chiều ghi — đừng loại CloudFront chỉ vì quen nghĩ CDN chỉ để phân phối nội dung ra.
• Latency do khoảng cách địa lý thì cách chữa đúng là đưa điểm tiếp nhận về gần người dùng (edge location) rồi đi tiếp trên backbone AWS, chứ không phải nhân bản dữ liệu ra nhiều nơi.
• Nhân bản kho dữ liệu (nhiều bucket, copy xuống EBS) đổi một vấn đề mạng lấy một vấn đề đồng bộ và dữ liệu cũ — thường là dấu hiệu của phương án sai trong đề thi khi bài toán gốc chỉ nói về hiệu năng truyền tải.

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

Nhóm nghiên cứu computer vision chạy một thuật toán I/O bound trên Amazon EC2. Đề yêu cầu chọn kiểu lưu trữ cho MOST performant as well as cost-optimal — vừa nhanh nhất vừa rẻ nhất.

Cụm từ quyết định nằm ở giữa câu: "temporary storage space before uploading the results back into Amazon S3". Đây là chỗ phân biệt bốn phương án gần giống nhau, vì cả bốn đều cho ra IOPS ở mức nào đó.

Hãy đọc kỹ ba tín hiệu ghép lại:

1. "high-performance IOPS" — cần random I/O cao, tức là ưu tiên SSD chứ không phải HDD.
2. "temporary storage space" — dữ liệu chỉ sống trong lúc xử lý, không cần bền vững (persistent).
3. "before uploading the results back into Amazon S3" — kết quả cuối cùng nằm ở S3, nên mất dữ liệu tạm khi instance dừng cũng không sao, chạy lại được.

Khi đề đã nói rõ dữ liệu là scratch/tạm và kết quả được đẩy sang S3, thì mọi lựa chọn lưu trữ bền vững đều là trả tiền cho một tính chất mà bài toán không cần — đó chính là chỗ tiêu chí "cost-optimal" cắt bớt các phương án.

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

C — Instance Store.

Instance Store là block storage tạm thời nằm trên đĩa gắn vật lý ngay vào máy chủ host đang chạy instance. Vì không phải đi qua mạng để tới một volume ở nơi khác như EBS, nó cho độ trễ rất thấp và random I/O rất cao — nhiều họ instance dùng SSD NVMe cho phần lưu trữ này. Đúng bài toán "I/O bound, cần IOPS cao".

Về chi phí, đây là điểm mấu chốt: dung lượng Instance Store đã nằm trong giá của chính instance, không tính tiền riêng. Trong khi đó mỗi volume EBS là một khoản phí cộng thêm vào giá EC2. Vậy nên Instance Store thắng cả hai tiêu chí mà đề nêu.

Nhược điểm của Instance Store — dữ liệu biến mất khi instance dừng hoặc bị terminate — ở đây không phải nhược điểm, vì đề đã nói dữ liệu chỉ là không gian làm việc tạm và kết quả cuối được đưa lên S3. Đúng với mô tả kinh điển: buffer, cache, scratch data, hoặc dữ liệu đã được nhân bản trên cả một fleet.

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

A — EBS Provisioned IOPS SSD (io1). Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. io1 sinh ra cho workload I/O-intensive, cho phép khai báo mức IOPS cố định và giữ được sự ổn định đó — nên tiêu chí "performant" nó đáp ứng được. Nó hỏng ở vế cost-optimal: io1 là loại volume EBS đắt nhất trong danh sách, tính tiền cả theo dung lượng lẫn theo số IOPS đã provision, và đó là chi phí cộng thêm ngoài giá EC2. Trả giá cao nhất để mua tính bền vững mà đề nói thẳng là không cần.

B — EBS Throughput Optimized HDD (st1). Sai cả hai vế. st1 là HDD, được thiết kế cho workload thiên về throughput tuần tự (big data, data warehouse, log processing), không phải cho IOPS ngẫu nhiên cao — nên nó đã trượt ngay ở yêu cầu "high-performance IOPS". Ngoài ra st1 vẫn là storage bền vững tính phí riêng ngoài chi phí instance.

D — EBS General Purpose SSD (gp2). Là SSD nên đúng hướng hơn st1, độ trễ ở mức mili-giây một chữ số và có cơ chế burst. Nhưng gp2 có hai điểm hỏng: hiệu năng nền của nó tỉ lệ theo dung lượng volume và dựa trên mô hình tích luỹ credit để burst — muốn IOPS cao bền bỉ thì phải mua volume thật lớn, đẩy chi phí lên. Và như ba phương án EBS còn lại, nó vẫn là chi phí cộng thêm cho tính bền vững không cần thiết. Đây là lựa chọn "cân bằng", mà đề lại hỏi cực trị ở cả hai đầu.

📌 Điểm cần nhớ

• Đề nói "temporary", "scratch", "cache", hoặc "kết quả sẽ được đẩy lên S3" → đó là tín hiệu mạnh chọn Instance Store. Ngược lại, nếu đề nhấn "must persist", "survive instance stop/termination" thì Instance Store bị loại ngay.
• Instance Store nằm trong giá instance; mọi volume EBS là phí cộng thêm. Khi đề hỏi "most performant và cost-optimal" cho dữ liệu tạm, đó gần như luôn là Instance Store.
• Phân biệt trục hiệu năng: IOPS ngẫu nhiên cao → SSD (io1/gp2 hoặc Instance Store NVMe); throughput tuần tự lớn, chi phí thấp → HDD (st1). Đề nói "IOPS" mà chọn st1 là sai ngay từ bản chất loại đĩa.
• gp2 và io1 khác nhau ở cách đảm bảo hiệu năng: gp2 gắn hiệu năng nền với dung lượng volume kèm cơ chế burst, io1 cho khai báo IOPS trực tiếp và giữ ổn định — đổi lại đắt hơn.