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

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

Một công ty dịch vụ tài chính lưu transaction logs khối lượng lớn trên Amazon S3, hiện ở định dạng .csv, và truy vấn bằng Amazon Athena. Mục tiêu: giảm chi phí truy vấn và tăng hiệu năng.

Cụm từ quyết định đáp án nằm ở câu: "mostly queried for specific columns using Amazon Athena" — tức là mỗi truy vấn chỉ cần vài cột trong số rất nhiều cột. Kèm theo đó là ràng buộc thứ hai: *"store these logs in S3" — đề đã chốt sẵn nơi lưu là S3, nên mọi phương án chuyển dữ liệu sang một kho khác đều đi ngược yêu cầu.

Hai chi tiết này gộp lại chỉ ra rất rõ hướng giải: giữ dữ liệu trên S3 nhưng đổi định dạng tệp sang dạng cột (columnar). Athena tính tiền theo lượng dữ liệu quét được từ S3, mà .csv là định dạng theo hàng — muốn đọc một cột thì vẫn phải quét toàn bộ hàng. Định dạng cột cho phép Athena chỉ đọc đúng những cột được nêu trong SELECT, nên vừa nhanh hơn vừa rẻ hơn.

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

C. Convert .csv files to Apache Parquet format using AWS Glue and store in S3 for efficient columnar querying.

Apache Parquet là định dạng lưu trữ theo cột, thiết kế cho khối lượng công việc phân tích. Khi dữ liệu ở dạng Parquet, Athena chỉ cần đọc các cột mà truy vấn yêu cầu thay vì quét cả bản ghi — đây chính là điều đề bài mô tả ("mostly queried for specific columns"). Kết quả trực tiếp là giảm lượng dữ liệu quét → giảm chi phí Athena, đồng thời truy vấn chạy nhanh hơn. Parquet cũng nén tốt hơn .csv, nên dung lượng lưu trữ trên S3 giảm theo.

AWS Glue là phần còn lại của phương án: nó tự động hoá và chạy được ở quy mô lớn việc chuyển đổi .csv → Parquet, rồi ghi kết quả trở lại S3. Nhờ vậy dữ liệu vẫn nằm đúng chỗ Athena được thiết kế để đọc, không phải dựng thêm hệ thống nào khác.

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

A. Replicate .csv logs to Amazon DynamoDB for querying with Amazon Athena. DynamoDB là cơ sở dữ liệu NoSQL, không phải nơi Athena đọc dữ liệu một cách tự nhiên. Athena được xây dựng để truy vấn dữ liệu nằm trên S3. Nhân bản log sang DynamoDB chỉ thêm một hệ thống phải vận hành và trả tiền, trong khi không hề giải quyết vấn đề gốc là định dạng .csv theo hàng. Đây cũng không phải mô hình phù hợp cho phân tích log quy mô lớn.

B. Store .csv logs in Amazon RDS and query with Athena using a JDBC connection. Đây là phương án nghe hợp lý nhất trong nhóm sai, vì "JDBC" gợi ra cảm giác kết nối được. Nhưng nó hỏng ở hai chỗ: Athena không truy vấn thẳng dữ liệu trong RDS qua JDBC theo cách mô tả ở đây — Athena hướng tới dữ liệu trên S3; và RDS là cơ sở dữ liệu quan hệ giao dịch, không phải kho lưu trữ để Athena quét. Ngoài ra, nạp khối lượng transaction logs rất lớn vào RDS đi ngược lại yêu cầu "store these logs in S3" của đề, đồng thời đắt hơn nhiều so với để dữ liệu nằm yên trên S3.

D. Use AWS Glue to transform .csv logs into XML format for optimized Amazon Athena querying. Phương án này dùng đúng công cụ (AWS Glue) và đúng nơi lưu (S3), nên rất dễ nhầm — nhưng nó chọn sai định dạng đích. XML không phải định dạng cột: dữ liệu vẫn được tổ chức theo bản ghi, nên Athena vẫn phải quét toàn bộ để lấy vài cột. Tệ hơn, XML mang nặng thẻ mở/thẻ đóng lặp lại, làm tệp phình to hơn cả .csv — lượng dữ liệu quét tăng, chi phí Athena tăng theo, và tốc độ phân tích cú pháp cũng chậm hơn. Nói cách khác, phương án này làm mọi thứ tệ đi chứ không tối ưu.

📌 Điểm cần nhớ

• Athena tính chi phí theo lượng dữ liệu quét từ S3, nên mọi câu hỏi "giảm chi phí Athena" đều xoay quanh việc quét ít byte hơn: đổi sang định dạng cột, nén, và phân vùng dữ liệu.
• Thấy cụm "chỉ truy vấn một số cột" (specific columns) trong đề là tín hiệu gần như chắc chắn cho Apache Parquet (hoặc ORC) — định dạng cột chỉ đọc đúng cột cần.
• Athena đọc dữ liệu trên S3. Phương án nào chuyển dữ liệu sang DynamoDB, RDS hay kho khác rồi bảo Athena truy vấn đều đáng nghi ngay từ đầu.
• Đúng công cụ chưa đủ — phải đúng định dạng đích. AWS Glue dùng để chuyển đổi định dạng ở quy mô lớn, nhưng Glue ra XML thì vẫn sai; giá trị nằm ở Parquet, không nằm ở Glue.

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

Đề mô tả một công ty marketing số cần phân tích clickstream theo thời gian thực. Dữ liệu chảy vào Amazon Kinesis Data Streams, phải được làm giàu (enrich) bằng cách tra chéo với một customer database nằm sau một external API, rồi mới ghi xuống Amazon S3.

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

• "in real-time" — loại bỏ mọi kiến trúc thiên về batch. Câu hỏi không nói "mỗi giờ một lần", nó nói ngay lập tức, theo từng bản ghi chảy tới.
• "cross-referencing with a customer database hosted on an external API" — việc làm giàu ở đây là gọi HTTP ra ngoài cho từng bản ghi, chứ không phải join với một bảng nằm trong data lake. Đây là kiểu xử lý theo sự kiện, nhẹ, ngắn.
• "efficiently" — trong ngôn ngữ đề thi AWS, từ này gần như luôn nghiêng về serverless, tức là ít chi phí vận hành, tự co giãn, không phải tự quản hạ tầng.

Gộp lại: cần thứ gì đó được Kinesis Data Streams kích hoạt trực tiếp, chạy được logic gọi API tuỳ ý, và tự co giãn theo lưu lượng stream.

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

Đáp án đúng theo tệp là A — dùng AWS Lambda xử lý và làm giàu dữ liệu từ Kinesis Data Streams, rồi lưu vào Amazon S3.

AWS Lambda tích hợp sẵn với Kinesis Data Streams thông qua event source mapping: dịch vụ Lambda tự đọc các shard của stream, gom bản ghi thành lô rồi gọi hàm của bạn với lô đó. Không cần viết consumer, không cần quản lý checkpoint hay số worker.

Bên trong hàm, bạn viết code tuỳ ý — kể cả gọi HTTP tới external API chứa customer database để tra chéo và bổ sung thuộc tính vào từng bản ghi clickstream. Đây chính là điểm hợp với yêu cầu enrich của đề: logic làm giàu là một lời gọi ra ngoài cho mỗi sự kiện, đúng khuôn hình xử lý theo sự kiện của Lambda.

Sau khi làm giàu xong, hàm ghi thẳng kết quả xuống Amazon S3 để phân tích về sau. Toàn bộ đường ống là serverless: mức song song bám theo số shard của stream, không có instance nào phải khởi tạo trước hay để nhàn rỗi lúc lưu lượng thấp. Đó là nghĩa của chữ "efficiently" trong đề.

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

B — Amazon EMR consume stream, transform, ghi S3. EMR là nền tảng big data mạnh, và về mặt kỹ thuật nó có thể đọc Kinesis. Nhưng EMR sinh ra để xử lý khối lượng lớn theo lô: bạn phải dựng cluster, chọn cỡ node, quản lý framework xử lý bên trên. Với bài toán "mỗi bản ghi gọi một API rồi ghi ra" thì đây là bộ máy nặng nề và tốn tài nguyên hơn hẳn mức cần thiết, lại thêm gánh nặng vận hành cluster. Đây là phương án "làm được nhưng không hiệu quả", nên trượt ở chữ efficiently.

C — AWS Glue trích từ Kinesis, enrich, load vào S3. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Glue là dịch vụ ETL, và bản chất mô hình vận hành của nó hướng tới xử lý theo lô: crawl, catalog, chạy job biến đổi trên tập dữ liệu. Với yêu cầu làm giàu theo thời gian thực bằng lời gọi API bên ngoài cho từng sự kiện, Glue không phải lựa chọn tối ưu — nó không phải khuôn hình xử lý theo sự kiện, và logic gọi API ngoài cho từng bản ghi nằm ngoài thế mạnh ETL của nó. Đề chọn Lambda vì Lambda là consumer sự kiện tự nhiên của Kinesis, còn Glue là công cụ ETL đặt sai chỗ.

D — EC2 pull dữ liệu từ Kinesis, enrich, upload S3. Cũng làm được về mặt kỹ thuật, nhưng bạn phải tự viết consumer, tự cấu hình auto scaling theo tải của stream, tự vá hệ điều hành, tự lo giám sát và độ sẵn sàng. Toàn bộ phần "hạ tầng" mà Lambda cho không thì ở đây bạn phải tự dựng và tự trả tiền kể cả lúc stream vắng. Đây là đáp án thua rõ nhất về mặt operational overhead.

📌 Điểm cần nhớ

• Kinesis Data Streams + AWS Lambda là cặp mặc định cho xử lý stream theo thời gian thực với logic tuỳ ý. Lambda là consumer tích hợp sẵn của stream — thấy đề nói "real-time" và "per-record processing" thì nghĩ tới cặp này trước.
• Làm giàu bằng cách gọi external API cho từng bản ghi là dấu hiệu của xử lý theo sự kiện (Lambda), không phải xử lý theo lô (Glue, EMR).
• Phân biệt batch với streaming: Glue và EMR đều mạnh về khối lượng lớn theo lô; đưa chúng vào bài toán thời gian thực đơn giản thì vừa phức tạp vừa nặng.
• "Efficiently", "without managing infrastructure", "least operational overhead" là những cụm từ đẩy đáp án về hướng serverless và loại thẳng EC2 tự quản.

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

Đề mô tả một công ty bán lẻ mỗi ngày nhận một file .xls khoảng 2 GB chứa dữ liệu khách hàng và đẩy lên Amazon S3. Việc cần làm gồm hai bước: ghép cột first name với last name, rồi đếm số khách hàng duy nhất trong file.

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

• .xls — định dạng bảng tính của Excel, không phải CSV, JSON hay Parquet. Đây là chi tiết loại bỏ phần lớn phương án, vì hầu hết dịch vụ truy vấn dữ liệu trên S3 chỉ hiểu các định dạng text/columnar chuẩn.
• "with minimal operational effort" — tiêu chí chấm điểm không phải là "làm được hay không", mà là "làm được với ít công vận hành nhất". Nhiều phương án về lý thuyết đều ra được con số đúng; cái nào bắt người kỹ sư viết code, chuyển đổi định dạng, hay quản lý runtime thì đều thua.

Ghép hai ràng buộc lại: cần một công cụ đọc thẳng được .xls trên S3 và có sẵn phép ghép cột + đếm giá trị duy nhất mà không phải viết code.

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

Đáp án đúng là C — AWS Glue DataBrew.

DataBrew là công cụ chuẩn bị dữ liệu dạng trực quan (visual data preparation): người dùng trỏ nó vào dataset, chọn các phép biến đổi từ danh sách có sẵn, và DataBrew ghi lại chuỗi phép đó thành một recipe rồi chạy thành job. Không phải viết code, không phải cấp phát hay quản lý server nào.

Nó khớp trọn vẹn hai yêu cầu của đề:

• Đọc dữ liệu trực tiếp từ S3 — DataBrew nhận dataset nằm sẵn trên S3, kể cả định dạng bảng tính Excel, nên không cần bước chuyển đổi định dạng trung gian.
• Có sẵn cả hai phép cần dùng — ghép hai cột thành một là một transform có sẵn trong recipe, và COUNT_DISTINCT là hàm có sẵn để đếm số giá trị duy nhất trên cột vừa ghép.

Vì toàn bộ pipeline nằm gọn trong một job serverless được cấu hình bằng giao diện, đây là phương án có operational effort thấp nhất — đúng cụm từ đề nhấn mạnh.

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

A — Amazon Athena, convert sang CSV rồi chạy SQL. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì Athena thật sự chạy SQL trên dữ liệu S3 và câu SQL cần viết rất tầm thường (COUNT(DISTINCT ...) trên biểu thức ghép chuỗi). Chỗ hỏng nằm ở ngay trong chính lời phương án: "after converting the file to CSV format". Athena không đọc được .xls một cách tự nhiên, nên phải dựng thêm một bước chuyển đổi định dạng chạy hằng ngày trước khi truy vấn. Chính bước phụ đó làm nó thua tiêu chí minimal operational effort — phương án tự thú nhận nó cần thêm việc.

B — AWS Lambda với S3 trigger. Phương án này hỏng ở hai chỗ độc lập nhau. Thứ nhất, Lambda bị ràng buộc về kích thước và thời gian chạy, nên xử lý một file khoảng 2 GB trong một lần gọi hàm là không phù hợp — sẽ phải chia nhỏ, stream, hoặc dựng cơ chế phức tạp hơn. Thứ hai, và quan trọng hơn với đề này: Lambda không biết đọc .xls, kỹ sư phải tự viết code kèm thư viện phân tích Excel, tự viết logic ghép tên và tự gom tập giá trị duy nhất. Viết code tùy biến là dấu hiệu ngược hẳn với "minimal operational effort".

D — Amazon S3 Select. Nghe hấp dẫn vì nó chạy truy vấn ngay tại chỗ trên object trong S3, không cần dịch vụ nào khác. Nhưng S3 Select được thiết kế để lấy ra một tập con dữ liệu từ một object, chứ không phải chạy phép tổng hợp phức tạp trên toàn file; nó có giới hạn về quy mô và mức độ phức tạp của truy vấn, nên gộp cả ghép cột lẫn đếm distinct toàn bộ trong một lần là vượt quá tầm nó. Và một lần nữa, nó cũng không hỗ trợ .xls, nên vẫn dính bước chuyển đổi định dạng giống Athena.

📌 Điểm cần nhớ

• Định dạng file là bộ lọc đầu tiên. Thấy .xls (hoặc .xlsx) trong đề thì Athena và S3 Select gần như tự loại, vì cả hai đều cần định dạng text/columnar chuẩn — chọn chúng đồng nghĩa với việc thêm một bước convert vào quy trình.
• "Minimal operational effort" là tiêu chí chấm, không phải câu văn trang trí. Khi nhiều phương án đều ra được kết quả đúng, cái ít code nhất và ít thành phần phải quản lý nhất là cái thắng. Phương án nào chứa sẵn cụm "after converting…" hay đòi viết custom code thì tự đánh tụt điểm mình.
• AWS Glue DataBrew là đáp án kinh điển cho "chuẩn bị/làm sạch dữ liệu, không viết code". Ghép cột, tách cột, chuẩn hóa, khử trùng lặp, COUNT_DISTINCT đều là transform dựng sẵn trong recipe.
• Cẩn thận với Lambda cho file lớn. Lambda hợp với xử lý sự kiện nhẹ và ngắn; file cỡ gigabyte cộng thêm logic phân tích định dạng phức tạp là dấu hiệu đề đang muốn bạn chọn dịch vụ khác.

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

Đội phân tích chạy các truy vấn Athena phức tạp trên dữ liệu nằm trong S3, dùng AWS Glue Data Catalog làm kho metadata. Vấn đề đã được đề nêu rất cụ thể: truy vấn chậm và nguyên nhân được quy cho số lượng partition trên S3 quá lớn. Mục tiêu là tăng hiệu năng truy vấn và giảm thời gian Athena dành cho khâu lập kế hoạch truy vấn (query planning).

Cụm từ quyết định là "reduce the time Athena takes in query planning" đi kèm "excessive number of S3 partitions". Đây không phải câu hỏi chung chung về "làm sao cho Athena nhanh hơn" — nó chỉ đích danh giai đoạn lập kế hoạch, tức là giai đoạn Athena phải hỏi Glue Data Catalog để liệt kê partition trước khi đọc dữ liệu. Càng nhiều partition, bước lấy metadata này càng lâu. Thêm nữa, đề yêu cầu chọn HAI biện pháp, nên đáp án gồm một biện pháp xử lý đúng nút thắt metadata, cộng một biện pháp giảm khối lượng dữ liệu phải quét.

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

B — Dùng partition projection của Athena. Đây là biện pháp nhắm thẳng vào query planning. Với partition projection, Athena suy ra các giá trị partition từ cấu hình khai báo trên bảng theo mẫu truy vấn thường dùng, thay vì phải đi đọc metadata partition thật trong Glue Data Catalog. Nói cách khác, partition được "chiếu" vào kết quả truy vấn như thể chúng có sẵn ở đó, mà không cần thao tác trên metadata thật. Nhờ vậy Athena tốn ít thời gian đọc metadata partition hơn — đúng chính xác điều đề bài đòi.

D — Chuyển dữ liệu trong S3 sang định dạng Apache Parquet. Parquet là định dạng cột. Khi chuyển sang Parquet, Athena giảm được số byte phải đọc, và điều này ảnh hưởng rõ rệt tới hiệu năng truy vấn, đặc biệt với những truy vấn không cần quét toàn bộ bảng mà chỉ đụng tới một phần cột. Đây là vế "enhance query performance" trong yêu cầu của đề.

Hai đáp án ghép lại phủ đúng hai vế của mục tiêu: B lo khâu lập kế hoạch, D lo khâu quét dữ liệu.

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

A — Gộp các object S3 nhỏ thành object lớn hơn bằng Glue transformation job. Đây là phương án gần đúng nhất và dễ chọn nhầm. Glue job đúng là gộp và định hình lại được object trong S3, và trên thực tế "small files problem" cũng là một nguyên nhân làm Athena chậm. Nhưng nó hỏng ở chỗ: chỉ gộp file mà không đụng gì tới chiến lược partition thì chưa chắc giải quyết được nút thắt ở khâu query planning mà đề mô tả. Số partition vẫn nguyên như cũ, Athena vẫn phải liệt kê từng ấy partition trong Glue Data Catalog. Đề đã chỉ đích danh thủ phạm là số lượng partition, chứ không phải số lượng file trong mỗi partition.

C — Dùng câu lệnh DML của Athena để tổ chức lại dữ liệu thành ít partition hơn, có ý nghĩa hơn. Nghe rất hợp lý vì "ít partition hơn" đúng là hướng đi. Nhưng Athena hỗ trợ DML để thao tác dữ liệu chứ bản thân nó không tự tổ chức lại dữ liệu thành ít partition hơn theo cách cần thiết để gỡ nút thắt hiệu năng mà đề mô tả. Đây là phương án mô tả một kết quả mong muốn mà không mô tả một cơ chế thực sự đạt được kết quả đó.

E — Dùng AWS Glue Elastic Views để tự động quản lý partition. Sai về bản chất dịch vụ. Glue Elastic Views là dịch vụ kết hợp và sao chép dữ liệu giữa nhiều kho dữ liệu khác nhau, không liên quan trực tiếp tới hiệu năng truy vấn Athena hay việc quản lý partition. Đây là kiểu mồi nhử ghép tên một dịch vụ có thật với một chức năng nó không làm.

📌 Điểm cần nhớ

• Khi đề nói tới "query planning time" và "quá nhiều partition", hãy nghĩ ngay tới partition projection — nó tránh hẳn việc đọc metadata partition trong Glue Data Catalog.
• Khi đề nói tới hiệu năng truy vấn và lượng dữ liệu quét, hãy nghĩ tới định dạng cột như Apache Parquet — giảm số byte Athena phải đọc.
• Phân biệt hai vấn đề hay bị gộp làm một: nhiều file nhỏ (chữa bằng gộp file) khác với nhiều partition (chữa bằng partition projection hoặc thiết kế lại partition). Đề chỉ thủ phạm nào thì chữa đúng thủ phạm đó.
• Cẩn thận với các phương án chỉ nêu kết quả mong muốn ("tổ chức lại thành ít partition hơn") mà không nêu cơ chế khả thi, và với các phương án gán sai chức năng cho một dịch vụ có thật (Glue Elastic Views là để kết hợp/sao chép dữ liệu giữa các kho, không phải để quản lý partition cho Athena).

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

Đề mô tả một nhóm phân tích dựng cụm Amazon EMR loại provisioned để chạy Apache Spark trên tập dữ liệu lớn, và yêu cầu chọn hai khuyến nghị cấu hình.

Cụm từ quyết định là "cost-effectively without compromising on performance or reliability" — tiết kiệm chi phí nhưng không được đánh đổi hiệu năng lẫn độ tin cậy. Đây chính là ràng buộc lọc ra đáp án: mọi lựa chọn nào mua rẻ bằng cách chấp nhận rủi ro gián đoạn, hoặc bằng cách ràng buộc cam kết dài hạn vào một hình dạng cụm cố định, đều bị loại. Thứ còn lại phải là những thay đổi giảm chi phí ngay ở tầng nền tảng — nơi lưu dữ liệu và loại vi xử lý — vì hai thứ này rẻ hơn mà không làm cụm kém ổn định đi chút nào.

Hai chữ "provisioned" cũng quan trọng: cụm do người dùng tự khai báo node, nên câu hỏi đang xoay quanh chọn hạ tầng cho node và chọn nơi đặt dữ liệu.

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

C — Dùng Graviton instances cho core node và task node. Graviton là dòng vi xử lý kiến trúc Arm của AWS, cho tỷ lệ price-performance tốt hơn so với instance x86 tương đương. Với khối lượng công việc big data chạy dài và ngốn tài nguyên như Spark trên EMR, đổi sang Graviton là cách hạ chi phí mà không giảm hiệu năng — đúng tinh thần "cost-effective without compromising performance".

E — Dùng Amazon S3 làm data lake cho EMR. S3 cho độ bền rất cao với chi phí lưu trữ thấp hơn HDFS chạy trên node EMR. Quan trọng hơn, S3 tách rời storage khỏi compute: dữ liệu không nằm trong ổ của cụm nữa, nên khi không dùng có thể tắt hẳn cụm EMR mà không mất gì. Nếu để dữ liệu trong HDFS thì cụm phải sống liên tục chỉ để giữ dữ liệu, và tiền trả cho phần compute nằm không đó là tiền lãng phí.

Hai đáp án này bổ trợ nhau: E hạ chi phí ở tầng lưu trữ và vòng đời cụm, C hạ chi phí ở tầng tính toán.

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

A — EMR Managed Scaling để tự co giãn cụm theo tải. Đây là phương án gần đúng nhất và bản thân nó là thực hành tốt trong nhiều tình huống. Nhưng nó chỉ điều chỉnh số lượng node, không đụng tới hai nguồn chi phí mà đề đang nhắm: dữ liệu vẫn nằm trong HDFS đòi cụm chạy liên tục, và node vẫn là loại đắt hơn. Scaling giỏi tới đâu cũng không cứu được một cụm buộc phải bật 24/7 để giữ dữ liệu.

B — Spot Instances cho task node. Cũng rất gần đúng: Spot đúng là rẻ và task node đúng là chỗ hợp lý nhất để đặt Spot vì chúng không giữ dữ liệu HDFS. Chỗ hỏng nằm ở vế "without compromising reliability" của đề: instance Spot có thể bị AWS thu hồi khi nhu cầu dung lượng tăng, làm job Spark chạy dài bị gián đoạn hoặc phải tính lại phần việc đã mất. Đề yêu cầu tiết kiệm mà không đánh đổi độ tin cậy, nên Spot bị loại ở đây.

D — Reserved Instances cho core node. Reserved giảm giá nhờ cam kết dài hạn, nhưng cam kết đó gắn với instance x86, mà x86 không phải lựa chọn tối ưu về price-performance khi đã có Graviton — nhất là với khối lượng công việc chạy dài, nặng tài nguyên như phân tích dữ liệu lớn. Nói cách khác, D khoá bạn vào loại hạ tầng mà C vừa chứng minh là kém kinh tế hơn.

📌 Điểm cần nhớ

• Với EMR, tách storage khỏi compute bằng S3 là bước tiết kiệm lớn nhất: nó cho phép tắt cụm khi không dùng, thứ mà HDFS-trên-node không cho phép.
• Graviton là câu trả lời mặc định khi đề nhắc tới "price-performance" — rẻ hơn mà không giảm hiệu năng, nên hợp với đề đòi tiết kiệm và giữ hiệu năng.
• Đọc kỹ vế "without compromising reliability": nó là dấu hiệu loại Spot Instances, dù Spot vốn là lựa chọn hợp lý cho task node trong các đề chỉ hỏi thuần chi phí.
• Phân biệt vai trò node EMR: master và core giữ trạng thái/HDFS nên cần ổn định; task node thì không — nhưng đó chỉ là điều kiện cần, chưa đủ để chọn Spot khi đề cấm đánh đổi độ tin cậy.

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

Đề mô tả một phòng nghiên cứu đại học lưu hai loại dữ liệu khác nhau trên Amazon S3, và hỏi kết hợp storage class nào tiết kiệm chi phí nhất. Đây là dạng câu "ghép cặp": phải chọn đúng cả hai vế, sai một vế là sai cả phương án.

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

• Với "Project Alpha": "when needed, the data must be immediately available" — dữ liệu ít được truy cập sau 30 ngày, nhưng khi cần thì phải có ngay lập tức. Cụm này loại bỏ mọi lớp lưu trữ có thời gian khôi phục, và cũng ngầm đòi mức độ sẵn sàng cùng khả năng chịu lỗi ở mức tiêu chuẩn.
• Với "Project Beta": "archival" và "retrieval time being less critical" — chỉ lấy ra khi có kiểm toán, và thời gian khôi phục không quan trọng. Đây là lời mời gọi thẳng tới lớp lưu trữ archive rẻ nhất, chấp nhận chờ hàng giờ.

Nói cách khác, đề đã tự viết sẵn hai tiêu chí ngược nhau: một bên ưu tiên độ sẵn sàng tức thì, một bên ưu tiên giá rẻ tối đa.

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

Đáp án đúng là B — S3 Standard cho "Project Alpha" và S3 Glacier Deep Archive cho "Project Beta".

• S3 Standard cho Project Alpha: lớp này cho độ sẵn sàng cao và truy cập tức thì, không có bước khôi phục, không có ràng buộc thời gian lưu tối thiểu gây phiền. Kể cả khi dữ liệu trở nên ít được truy cập sau 30 ngày, yêu cầu "phải có ngay lập tức" vẫn được đáp ứng trọn vẹn.
• S3 Glacier Deep Archive cho Project Beta: đây là lớp lưu trữ có chi phí lưu trữ thấp nhất trong họ S3, thiết kế đúng cho dữ liệu archive gần như không bao giờ đọc tới. Đổi lại, khôi phục mất nhiều giờ — mà đề đã nói rõ retrieval time being less critical, nên nhược điểm đó không phải nhược điểm trong bối cảnh này.

Cặp này khớp chính xác hai ràng buộc của đề: tức thì ở vế cần tức thì, rẻ nhất ở vế được phép chờ.

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

A. S3 Intelligent-Tiering cho Alpha + S3 Standard-Infrequent Access cho Beta — đây là phương án gần đúng nhất, và nó hỏng ở vế Beta. Vế Alpha thực ra rất hợp lý: Intelligent-Tiering tự chuyển tầng khi mẫu truy cập đổi (nhiều trong 30 ngày đầu, ít về sau) mà vẫn giữ truy cập tức thì. Nhưng S3 Standard-IA dành cho dữ liệu ít truy cập nhưng vẫn cần lấy ngay, và giá lưu trữ của nó cao hơn hẳn Glacier Deep Archive. Với dữ liệu archive chỉ đụng tới khi kiểm toán và không cần lấy nhanh, trả thêm tiền để mua tốc độ mình không dùng là đi ngược yêu cầu "most cost-effectively".

C. S3 Standard cho cả hai — vế Alpha đúng, vế Beta sai hoàn toàn về mục tiêu chi phí. Đề hỏi phương án tiết kiệm nhất, mà để dữ liệu archive nằm ở lớp đắt nhất là bỏ qua toàn bộ khoảng tiết kiệm có thể có. "Simplicity and consistent access" nghe hợp lý nhưng không phải tiêu chí mà đề đưa ra.

D. S3 One Zone-IA cho Alpha + S3 Glacier cho Beta — sai ở cả hai vế, mỗi vế một kiểu:

• One Zone-IA chỉ lưu dữ liệu trong một Availability Zone, nên mức độ bền vững trước sự cố toàn AZ và mức sẵn sàng đều thấp hơn S3 Standard. Với dữ liệu nghiên cứu phải "immediately available" khi cần, chấp nhận rủi ro mất cả AZ là đánh đổi không được đề cho phép.
• Glacier (lớp archive có khôi phục nhanh hơn) dùng được cho Beta, nhưng vì đề nói rõ thời gian khôi phục không quan trọng, Glacier Deep Archive rẻ hơn và mới là lựa chọn tối ưu chi phí. Vế này không sai về kỹ thuật, chỉ là không tối ưu — nhưng cộng với lỗi ở vế Alpha thì phương án bị loại chắc chắn.

📌 Điểm cần nhớ

• Trong câu hỏi ghép cặp storage class, phải kiểm tra cả hai vế; một vế đúng không cứu được phương án. Cách làm nhanh: loại theo vế dễ phán đoán trước, rồi mới so vế còn lại.
• Cụm "must be immediately available" loại mọi lớp archive; cụm "retrieval time is not critical" / "archival" / "audit only" là tín hiệu chọn Glacier Deep Archive — lớp rẻ nhất, chậm nhất.
• S3 Standard-IA và One Zone-IA dành cho dữ liệu ít truy cập nhưng vẫn cần lấy ngay, không phải dữ liệu archive. Dùng chúng cho archive là trả tiền cho tốc độ không dùng đến.
• One Zone-IA chỉ nằm trong một AZ: chỉ chọn khi đề nói dữ liệu có thể tái tạo được hoặc chấp nhận rủi ro mất AZ; nếu đề nhấn mạnh availability hay resilience thì loại ngay.

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

Đề mô tả một ứng dụng di động lưu user-generated content và hỏi chọn giải pháp database nào phù hợp nhất. Có bốn cụm từ trong đề đóng vai trò ràng buộc, và cả bốn đều chỉ về cùng một hướng:

• "flexible data model" và "varies greatly in size and structure" — dữ liệu không có hình dạng cố định, nên schema cứng của relational database là gánh nặng chứ không phải trợ giúp.
• "unpredictable traffic" và "automatically scale to accommodate peak loads" — không dự đoán được tải, nên phải là dịch vụ tự co giãn theo lưu lượng thực tế.
• "Cost-efficiency" — loại bỏ những phương án bắt trả tiền cho hạ tầng thường trực hoặc trả bằng công sức vận hành.
• "performance are primary concerns" — cần độ trễ ổn định ở quy mô lớn.

Cụm quyết định mạnh nhất là "flexible data model … varies greatly in size and structure". Chỉ riêng nó đã tách nhóm NoSQL (B, C) khỏi nhóm relational (A, D); phần còn lại của đề — managed, cost-efficiency — dùng để tách C khỏi B.

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

C — Amazon DynamoDB. DynamoDB là NoSQL database dạng managed service, khớp cả bốn ràng buộc cùng lúc:

• Flexible schema: mỗi item chỉ bắt buộc có key, các attribute còn lại tự do khác nhau giữa các item. Đúng với nội dung người dùng đăng lên mỗi bản ghi một kiểu.
• Seamless scalability: dịch vụ tự điều chỉnh theo lượng traffic và dung lượng dữ liệu đổ vào, không phải người vận hành ngồi canh peak load.
• Cost-efficiency: không có server để trả tiền chờ sẵn, không có đội vận hành database.
• Performance: truy cập theo key giữ độ trễ ổn định khi dữ liệu và lưu lượng phình ra — đúng kiểu truy cập của một mobile app đọc/ghi nội dung theo người dùng.

Đây cũng là lập luận trong phần giải thích gốc: DynamoDB xử lý tốt dữ liệu phi cấu trúc khối lượng lớn, và tự thích ứng với lưu lượng khó đoán.

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

A — Amazon Aurora. Đây là phương án gần đúng nhất trong nhóm relational, vì Aurora thật sự có khả năng auto scaling và hiệu năng cao hơn relational database thông thường. Nhưng nó vẫn là relational, vẫn dựa trên schema cố định — mỗi lần cấu trúc nội dung người dùng thay đổi là một lần phải sửa schema. Đề nhấn "flexible data model" ngay câu đầu, nên ưu thế về scaling của Aurora không cứu được điểm hỏng này: nó không quản lý dữ liệu phi cấu trúc hiệu quả bằng DynamoDB.

B — Self-managed NoSQL trên Amazon EC2. Phương án này đúng phần NoSQL (có schema linh hoạt) nhưng hỏng ở phần self-managed. "Full control" nghe như ưu điểm, thực chất là công việc: tự lo scaling, patching, backup, giám sát. Với traffic không đoán trước, tự scale nghĩa là hoặc chạy dư instance cho lúc cao điểm (đắt), hoặc phản ứng chậm khi tải tăng (mất performance) — trái thẳng với hai tiêu chí "cost-efficiency and performance" mà đề nêu là ưu tiên chính. Đây là bẫy kinh điển: đúng loại database, sai mô hình vận hành.

D — Amazon RDS. Sai ở cả hai ràng buộc lớn. RDS là relational, hợp với dữ liệu có cấu trúc rõ ràng cần ACID transactions và complex queries — nhưng đề không hề đòi hỏi hai thứ đó. Phương án tự tô điểm bằng lợi ích mà đề không cần, đồng thời không đáp ứng nhu cầu thật sự về schema linh hoạt. Về scaling, RDS cũng không co giãn dễ dàng theo tải bất thường bằng DynamoDB, nên phần "cost-efficiency" cũng không đạt.

📌 Điểm cần nhớ

• "Flexible schema" / "varies in structure" / "unstructured" trong đề là tín hiệu chọn NoSQL — cụ thể là DynamoDB. Ngược lại, thấy "complex joins", "ACID transactions", "reporting queries" thì mới nghĩ tới Aurora/RDS.
• Đừng để "auto scaling" của Aurora đánh lừa. Aurora scale được nhưng không bỏ được schema cố định; khi đề nhấn cả hai thứ, ràng buộc về schema mới là thứ phân định.
• "Self-managed trên EC2" gần như luôn sai khi đề nêu cost-efficiency hoặc giảm operational overhead, kể cả khi đúng loại database. AWS ra đề theo hướng ưu tiên managed service.
• Đọc kỹ phần đuôi của mỗi phương án. Nhiều phương án sai vì lý do biện minh (ACID, complex queries, full control) là lợi ích mà đề không hề yêu cầu — nêu ưu điểm lạc đề chính là dấu hiệu nhận biết distractor.

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

Đề mô tả một tổ chức đang xây data lake trên AWS và cần granular access control — cụ thể là cấp quyền tới từng dòng (row-level) và từng cột (column-level) trong tập dữ liệu.

Cụm từ quyết định đáp án nằm ở câu cuối phần mô tả: các nhóm sẽ truy vấn dữ liệu bằng "a combination of Amazon Athena, Amazon Redshift Spectrum, and Apache Hive on Amazon EMR". Đây là ràng buộc phân biệt bốn phương án gần giống nhau: cơ chế phân quyền phải là một nơi khai báo duy nhất, áp dụng được cho cả ba engine truy vấn, chứ không phải giải pháp gắn chặt vào một engine.

Ràng buộc thứ hai, yếu hơn nhưng vẫn quan trọng: đây là data lake, nghĩa là dữ liệu nằm trên Amazon S3, không phải nằm trong kho dữ liệu của một engine cụ thể. Và cụm "manage data permissions efficiently" hướng tới phương án ít công vận hành nhất.

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

Đáp án A — AWS Lake Formation.

Lake Formation là dịch vụ chuyên để dựng và quản trị data lake trên S3. Nó cho phép khai báo fine-grained access policies ở mức bảng, cột và dòng, gắn với người dùng/vai trò IAM, và quản lý tập trung trên metadata của AWS Glue Data Catalog.

Điểm mấu chốt khớp thẳng với đề: Lake Formation tích hợp sẵn với Amazon Athena, Amazon Redshift Spectrum và Apache Hive trên Amazon EMR. Khai báo chính sách một lần ở Lake Formation, cả ba engine đều tôn trọng chính sách đó khi truy vấn — không phải cấu hình lại cho từng engine. Đó chính là "manage data permissions efficiently" mà đề yêu cầu, với operational overhead thấp nhất trong bốn phương án.

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

B — Redshift security groups và views.

Đây là phương án gần đúng ở chỗ views trong Redshift đúng là kỹ thuật cổ điển để giới hạn dòng và cột. Nhưng nó hỏng ở phạm vi: quyền và view chỉ tồn tại trong môi trường Redshift. Athena và Apache Hive trên EMR đọc thẳng dữ liệu trên S3, chúng không đi qua lớp view của Redshift nên không chịu ràng buộc nào. Ngoài ra, "security groups" trong Redshift là kiểm soát truy cập mạng tới cluster, không phải phân quyền dòng/cột — đề đang hỏi cái sau. Phương án này cũng ngầm biến Redshift thành nơi lưu dữ liệu chính của data lake, trong khi vai trò đó thuộc về S3.

C — Apache Ranger trên Amazon EMR.

Ranger thật sự làm được fine-grained access control, nên đây là phương án gây phân vân nhất. Nó hỏng ở hai điểm. Thứ nhất, Ranger là công cụ của hệ sinh thái Hadoop, phạm vi tự nhiên của nó là các engine chạy trên EMR — nó không phủ được Athena, và phương án còn chuyển hướng sang truy vấn bằng Redshift chứ không phải bộ ba engine đề nêu. Thứ hai, Ranger đòi tự cài đặt, tự vận hành, tự đồng bộ chính sách: phải dựng và duy trì server Ranger, cấu hình plugin, xử lý tích hợp danh tính. So với Lake Formation là dịch vụ managed tích hợp sẵn, đây là công vận hành cao hơn hẳn — trái với chữ "efficiently".

D — S3 bucket policies và IAM roles.

Đây là lớp phân quyền nền tảng của S3, nhưng nó làm việc ở mức đối tượng và tiền tố (prefix): cho phép hay từ chối truy cập cả một file, một thư mục. Nó không hiểu cấu trúc bên trong file dữ liệu, nên không có khái niệm dòng hay cột — đúng thứ mà đề yêu cầu. Muốn mô phỏng row/column-level bằng cách này thì phải tách dữ liệu ra nhiều prefix theo từng nhóm quyền và nhân bản dữ liệu, vừa cồng kềnh vừa dễ sai. Nó cũng không cung cấp cơ chế thống nhất cho ba engine truy vấn ở tầng bảng.

📌 Điểm cần nhớ

• Thấy đồng thời "data lake trên S3" + "row-level / column-level" + nhiều engine truy vấn (Athena, Redshift Spectrum, EMR/Hive) thì đáp án gần như chắc chắn là AWS Lake Formation — đó là chữ ký nhận dạng của dịch vụ này.
• Phân biệt tầng phân quyền: IAM và S3 bucket policy kiểm soát ở mức object/prefix; Lake Formation kiểm soát ở mức bảng, cột, dòng trên metadata của Glue Data Catalog. Câu hỏi nhắc tới dòng/cột là đã loại IAM/S3 policy.
• Apache Ranger là đáp án mồi kinh điển khi đề có EMR: nó làm được về mặt kỹ thuật nhưng là giải pháp tự vận hành, phạm vi thiên về Hadoop. Đề nào nhấn "least operational overhead" hoặc "efficiently" thì chọn dịch vụ managed của AWS.
• Giải pháp phân quyền gắn với một engine (view trong Redshift) không áp được cho các engine khác đọc thẳng S3. Khi đề liệt kê nhiều công cụ truy vấn, hãy hỏi: chính sách này có được cả ba tôn trọng không?

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

Một công ty thương mại điện tử chuyển dữ liệu catalog sản phẩm từ relational database on-premises lên AWS. Dữ liệu vừa có dạng structured vừa semi-structured, và schema thay đổi thường xuyên. Yêu cầu: chạy SQL trực tiếp trên dữ liệu đang nằm trong Amazon S3, theo mô hình serverless, không dựng hạ tầng database phức tạp.

Ba cụm từ trong đề quyết định đáp án, và phải thoả cả ba cùng lúc:

• "query this data directly in Amazon S3" — dữ liệu ở nguyên S3, không nạp vào database khác.
• "serverless solution" / "without setting up complex database infrastructure" — không có cluster, không có instance để quản lý.
• "new updates and schemas introduced regularly" — cần một nơi quản lý schema tách rời khỏi dữ liệu, tức là một data catalog.

Các phương án đều động tới SQL và S3 ở mức nào đó, nên chính ràng buộc serverless cộng với query tại chỗ trên S3 mới là thứ tách chúng ra.

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

Đáp án đúng là D — Amazon Athena kết hợp AWS Glue Data Catalog.

Athena là dịch vụ truy vấn tương tác serverless, chạy SQL thẳng trên dữ liệu lưu ở S3. Công ty không phải cấp phát, vá hay chỉnh kích thước bất kỳ compute resource nào — cứ có nhu cầu thì chạy query, đúng tinh thần "không dựng hạ tầng database".

Phần schema do AWS Glue Data Catalog đảm nhiệm. Đây là kho metadata định nghĩa bảng, cột và kiểu dữ liệu cho dữ liệu nằm trên S3. Vì schema được mô tả trong catalog chứ không "khoá cứng" vào file dữ liệu, catalog sản phẩm có thêm trường mới hay đổi cấu trúc thì chỉ cần cập nhật định nghĩa bảng, dữ liệu cũ trên S3 vẫn nguyên vị trí. Đó chính là cách xử lý phù hợp với dữ liệu structured lẫn semi-structured mà đề mô tả.

Ghép lại: query tại chỗ trên S3 ✔, serverless ✔, chịu được schema thay đổi ✔ — D thoả đủ ba ràng buộc.

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

A — AWS Lambda xử lý và query dữ liệu trong S3, dùng DynamoDB để quản lý schema. Lambda đúng là serverless, nhưng nó không cho bạn một SQL engine — bạn phải tự viết toàn bộ phần đọc file, phân tích định dạng và diễn giải truy vấn. Đề đòi "phân tích dữ liệu bằng SQL query" chứ không đòi viết một công cụ query. Việc dùng DynamoDB làm nơi giữ schema cũng là cách dùng lệch mục đích: DynamoDB là NoSQL database phục vụ truy cập theo khoá, không phải metadata catalog cho dữ liệu trên S3 — vai trò đó là của Glue Data Catalog. Phương án này đổi một dịch vụ có sẵn lấy một khối lượng lớn code tự viết và vận hành.

B — Migrate dữ liệu sang Amazon RDS rồi dùng Athena query trực tiếp trên RDS. Sai ở ngay tiền đề kỹ thuật: Athena được thiết kế để query dữ liệu trên S3, không phải để query thẳng vào RDS database. Ngoài ra phương án này vi phạm luôn hai ràng buộc khác của đề: nó di chuyển dữ liệu ra khỏi S3 thay vì query tại chỗ, và RDS là managed database có instance phải quản lý — trái với yêu cầu serverless, không dựng hạ tầng database. Đây là phương án nghe quen tai vì có nhắc tên Athena, nhưng ghép Athena với sai nguồn dữ liệu.

C — Amazon Redshift Spectrum query dữ liệu trong S3, Glue Data Catalog quản lý schema. Đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. Redshift Spectrum thật sự query được dữ liệu nằm trên S3, và cũng thật sự tích hợp với AWS Glue Data Catalog — hai vế đó không sai. Chỗ chết là: Spectrum hoạt động thông qua Amazon Redshift, tức là phải có một Redshift cluster để chạy truy vấn. Có cluster nghĩa là có hạ tầng phải cấu hình và vận hành, mâu thuẫn trực tiếp với chữ "serverless" trong đề. Nếu đề bỏ ràng buộc serverless đi, C sẽ là lựa chọn hợp lệ — chính chi tiết đó là cụm từ phân biệt.

📌 Điểm cần nhớ

• Athena = SQL serverless trên dữ liệu ở S3. Thấy đề ghép "SQL + data in S3 + serverless + không muốn quản lý hạ tầng" thì Athena là mặc định nên nghĩ tới trước.
• Athena query S3, không query RDS. Bất kỳ phương án nào bảo dùng Athena để truy vấn thẳng vào một relational database đều sai ở tiền đề, dù tên dịch vụ nghe đúng.
• Glue Data Catalog là nơi giữ schema cho dữ liệu trên S3, giúp chịu được schema thay đổi. Đừng nhầm vai trò này sang DynamoDB hay bất kỳ database nào khác.
• Redshift Spectrum cũng đọc S3 nhưng cần cluster. Đây là cặp gây nhiễu kinh điển: khi đề nhấn mạnh serverless thì chọn Athena; khi đề nhấn mạnh join dữ liệu S3 với dữ liệu đang có sẵn trong data warehouse thì mới nghiêng về Spectrum.
• Mẹo đọc đề chung: khi nhiều phương án cùng "đúng về mặt kỹ thuật", hãy quay lại tìm ràng buộc vận hành (serverless, không di chuyển dữ liệu, không quản lý hạ tầng) — nó thường là thứ loại bớt phương án.

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

Đề mô tả một công ty làm mobile app cho phép người dùng upload và retrieve ảnh, ảnh lưu trên Amazon S3. Câu hỏi chốt lại: nên tích hợp S3 vào ứng dụng di động theo cách nào.

Cụm từ quyết định là "mobile application" đi kèm "integrate the S3 service into their application". Đây không phải câu hỏi về hiệu năng hay chi phí lưu trữ, mà về kiến trúc tích hợp giữa client không đáng tin cậy và một dịch vụ lưu trữ. Một mobile app là mã chạy trên máy người dùng — mọi thứ nhúng trong đó (credentials, cấu hình bucket) đều có thể bị bóc ra. Vì vậy câu hỏi thực chất là: đặt gì ở giữa app và S3 để kiểm soát truy cập, xác thực request và co giãn theo tải.

Cụm phụ thứ hai cũng quan trọng: "uploading and retrieving photos" — đây là các thao tác đơn lẻ, ngắn, theo từng request, không phải một quy trình nhiều bước có trạng thái. Chi tiết này chính là thứ loại phương án D.

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

C — AWS Lambda được trigger bởi Amazon API Gateway để xử lý upload/retrieve với S3.

API Gateway đóng vai trò "cửa trước" (front door) cho toàn bộ API mà mobile app gọi tới. Nó cho phép công ty:

• Kiểm soát truy cập vào các thao tác S3 thay vì để client nói chuyện thẳng với bucket
• Quản lý traffic và authorize request trước khi bất cứ thứ gì chạm tới dữ liệu
• Quản lý phiên bản API, nên app cũ trên máy người dùng vẫn dùng được trong khi backend tiến hoá

Phía sau, Lambda xử lý logic upload và retrieve, giao tiếp với S3. Kiến trúc serverless này tự động co giãn theo số lượng request — đúng thứ một mobile app cần khi tải thay đổi thất thường — và tiết kiệm chi phí vì chỉ trả cho lượt gọi thực tế, không phải cho hạ tầng chờ sẵn.

Nói ngắn gọn: C là phương án duy nhất vừa có lớp kiểm soát ở giữa, vừa không bắt công ty tự vận hành server.

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

A — Gọi thẳng Amazon S3 API trong mã ứng dụng.

Đây là phương án gần đúng nhất và về mặt kỹ thuật là làm được — SDK của AWS có bản cho mobile. Nhưng nó không phải best practice cho mobile application. Chỗ hỏng: cách này phơi dịch vụ S3 trực tiếp ra client, dẫn tới rủi ro bảo mật và ít quyền kiểm soát hơn đối với traffic cũng như các thao tác được phép. Client là môi trường không kiểm soát được; đặt ranh giới tin cậy ngay tại S3 nghĩa là không còn chỗ nào để chèn logic kiểm tra, giới hạn hay ghi nhận. Đề nhấn "mobile app" chính là để loại phương án này.

B — Dùng EC2 instances làm trung gian cho các thao tác S3.

Phương án này giải đúng vấn đề của A: nó có đặt một lớp trung gian giữa app và S3. Nhưng nó hỏng ở cách hiện thực: EC2 mang lại độ phức tạp và chi phí không cần thiết. Công ty phải duy trì và scale các instance, tức là tốn nhiều tài nguyên vận hành hơn hẳn so với hướng serverless mà Lambda + API Gateway cung cấp. Cùng một kết quả kiến trúc, nhưng phải trả giá bằng việc quản lý máy chủ — nên nó thua C chứ không phải sai về ý tưởng.

D — Dùng AWS Step Functions để quản lý workflow upload/retrieve ảnh từ S3.

Step Functions dùng để điều phối nhiều dịch vụ AWS thành các serverless workflow. Nó không phải công cụ cho các tương tác trực tiếp kiểu upload/tải một tệp. Với tình huống trong đề, Step Functions thêm phức tạp mà không mang lại lợi ích đáng kể nào so với API Gateway + Lambda. Ngoài ra, bản thân Step Functions không phải điểm tiếp nhận request từ mobile app — vẫn cần một lớp API phía trước, nên nó không thay thế được C mà chỉ chồng thêm lên.

📌 Điểm cần nhớ

• Mobile app = client không đáng tin cậy. Hễ đề nói "mobile application" gọi tới một dịch vụ dữ liệu, hãy tìm phương án có lớp trung gian kiểm soát truy cập, đừng chọn phương án gọi thẳng SDK/API của dịch vụ.
• API Gateway + Lambda là mẫu chuẩn cho backend serverless của mobile app: API Gateway lo authorize, quản lý traffic và phiên bản API; Lambda lo logic và nói chuyện với S3.
• Cùng đúng về kiến trúc thì chọn phương án ít vận hành hơn. EC2 và Lambda đều làm trung gian được, nhưng EC2 bắt bạn tự duy trì và scale — thi cử gần như luôn nghiêng về hướng serverless khi tải biến động.
• Step Functions dành cho điều phối nhiều bước, không dành cho thao tác đơn lẻ. Thấy "upload/retrieve một tệp" mà phương án đưa ra Step Functions thì đó là dấu hiệu over-engineering.