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 truyền thông số xử lý lượng lớn file ảnh và video mỗi ngày, tất cả đã nằm trong một Amazon S3 bucket. Việc cần làm là trích xuất metadata của file (kích thước, kiểu file, ngày tạo), lưu lại và truy xuất nhanh để phân tích.

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

• "automatically handle new files as they are uploaded" — phải có cơ chế phản ứng theo sự kiện ngay khi file được tải lên, chứ không phải chạy theo lịch hay quét lại toàn bucket.
• "quick retrieval" — nơi lưu metadata phải là kho tra cứu độ trễ thấp theo khoá, không phải kho phân tích quét cả bảng.
• "scalable to handle increasing data volumes" — cả tầng xử lý lẫn tầng lưu trữ phải giãn theo lượng file mà không cần chỉnh tay.

Đây là metadata của file — dữ liệu nhỏ, rất nhiều bản ghi, tra theo khoá — chứ không phải nội dung file. Nhận ra điểm này là loại được các phương án dựng cả một đường ống phân tích nặng nề.

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

A. S3 Event Notifications → AWS Lambda → Amazon DynamoDB.

• S3 Event Notifications trả lời trực tiếp yêu cầu "tự động xử lý file mới": mỗi lần có object được tạo trong bucket, S3 phát sự kiện và gọi thẳng Lambda. Không cần lịch chạy, không cần quét lại, không có độ trễ giữa các đợt.
• AWS Lambda là compute serverless: nó giãn theo số sự kiện đến, nên lượng file tăng lên thì số lần chạy tăng theo mà người vận hành không phải cấp thêm hạ tầng. Trích xuất metadata là việc ngắn, nhẹ — đúng khuôn của Lambda.
• DynamoDB cho truy cập độ trễ thấp theo khoá, đúng nghĩa "quick retrieval and analysis" mà đề nêu, và mở rộng được theo lượng bản ghi.

Cả ba mảnh ghép lại thành một giải pháp đầu-cuối gần như không phải quản trị gì, đúng ba ràng buộc trong đề.

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

B. Athena query metadata trực tiếp trên S3 → kết quả lưu vào ElastiCache. Athena là công cụ truy vấn dữ liệu trong S3, không phải công cụ trích xuất và quản lý metadata của file. Nó cũng không tự kích hoạt khi có file mới — phải có ai đó chạy truy vấn. Còn việc đổ kết quả truy vấn vào ElastiCache không phải cách làm thông thường để quản lý metadata và không cho một đường truy xuất hiệu quả, ổn định.

C. AWS Glue chạy ETL job trên file mới → lưu vào Amazon RDS. Đây là phương án gần đúng nhất: Glue thực sự làm được ETL và trích xuất metadata. Chỗ hỏng nằm ở tầng lưu trữ — Amazon RDS là CSDL quan hệ, không phải lựa chọn hiệu quả cho khối lượng và tốc độ dữ liệu điển hình của file media. Đây là kho metadata ghi rất nhiều, tra theo khoá, tăng không giới hạn — đúng thế mạnh của DynamoDB và đúng điểm yếu của một instance RDS phải quản lý dung lượng và mở rộng. So với A, nó cũng nặng nề hơn cho một việc chỉ là đọc thuộc tính file.

D. Kinesis Data Firehose thu metadata → nạp vào Amazon Redshift. Firehose sinh ra cho dữ liệu streaming, không hợp với bài toán trích xuất metadata dựa trên file như ở đây — nguồn phát ở đề là sự kiện S3 chứ không phải một luồng bản ghi liên tục. Redshift lại là data warehouse, dùng nó để lưu và tra vài thuộc tính đơn giản của file là phức tạp và tốn kém quá mức so với nhu cầu.

📌 Điểm cần nhớ

• Thấy "tự động xử lý khi có file mới trong S3" thì nghĩ ngay tới S3 Event Notifications + Lambda — đó là mẫu event-driven chuẩn, không cần lịch chạy hay quét lại bucket.
• Chọn kho lưu theo kiểu truy cập: tra cứu độ trễ thấp theo khoá → DynamoDB; phân tích tổng hợp trên khối lượng lớn → Redshift; quan hệ, giao dịch → RDS. Đề nói "quick retrieval" là đang chỉ về vế đầu.
• Firehose dành cho streaming, không phải cho xử lý theo file. Nguồn dữ liệu là object trong S3 thì Firehose gần như luôn là phương án lạc đề.
• Athena là công cụ truy vấn, không phải công cụ trích xuất và quản lý metadata, và nó không tự chạy khi có dữ liệu mới.
• Một câu có thể có phương án đúng ở phần xử lý nhưng sai ở phần lưu trữ (như C) — luôn soi cả hai vế của mỗi phương án trước khi chọn.

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

Một công ty có dữ liệu nằm rải rác ở bốn nơi: file JSON và .csv trên Amazon S3, cơ sở dữ liệu Amazon RDS for SQL Server, bảng Amazon DynamoDB ở chế độ provisioned capacity, và một Amazon Redshift cluster. Yêu cầu là để các data scientist chạy truy vấn kiểu SQL trên toàn bộ những nguồn này.

Cụm từ quyết định đáp án là "simplest solution ... with the least operational overhead" — đơn giản nhất, ít việc vận hành nhất. Cả bốn phương án đều dựa trên AWS Glue Data Catalog để gom metadata, nên Glue không phải là chỗ phân biệt. Điểm khác nhau nằm ở hai chỗ:

1. Dùng engine truy vấn nào: Athena (serverless) hay Redshift Spectrum (gắn với cluster).
2. Có phải biến đổi dữ liệu trước hay không (chuyển sang .csv, chuyển sang Parquet).

Một cụm nữa cần để ý: dữ liệu có cả JSON, tức là dữ liệu bán cấu trúc/lồng nhau — đây là lý do các phương án nhắc tới PartiQL.

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

C — dùng AWS Glue để catalog các nguồn dữ liệu, rồi truy vấn bằng Amazon Athena: SQL chuẩn cho dữ liệu có cấu trúc và PartiQL cho JSON.

• AWS Glue crawler/catalog gom được metadata từ nhiều nguồn (S3, RDS, DynamoDB, Redshift) về một Data Catalog dùng chung, nên data scientist chỉ cần biết một nơi để tra bảng thay vì học bốn hệ thống.
• Amazon Athena là dịch vụ serverless: không có cluster nào để dựng, để tuning hay để trả tiền lúc rảnh. Nó đọc thẳng Glue Data Catalog và chạy SQL chuẩn trên dữ liệu ở định dạng vốn có — .csv không cần đổi gì cả.
• Với dữ liệu JSON, Athena hỗ trợ PartiQL, một ngôn ngữ truy vấn tương thích SQL được mở rộng để làm việc với dữ liệu bán cấu trúc và lồng nhau. Nhờ đó JSON được truy vấn tại chỗ, không cần bước ETL nào.

Cộng lại: không ETL, không cluster, một catalog, một engine — đúng nghĩa "ít operational overhead nhất" mà đề đòi.

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

A — Glue catalog + Redshift Spectrum, SQL chuẩn cho dữ liệu có cấu trúc và PartiQL cho JSON. Đây là phương án gần đúng nhất, vì phần catalog và phần xử lý JSON giống hệt C; nó chỉ đổi engine. Chỗ hỏng nằm đúng ở chỗ đổi đó: Redshift Spectrum không chạy độc lập được, nó phải có một Redshift cluster làm điểm vào. Công ty đúng là đang có cluster, nhưng vậy nghĩa là mọi truy vấn ad-hoc của data scientist phải đi qua tài nguyên của cluster đó — thêm phần phải quản lý, phải cấp phát, phải cạnh tranh tài nguyên với công việc sẵn có. Athena bỏ hẳn lớp này mà vẫn làm được đúng việc, nên với tiêu chí "least operational overhead" thì A thua.

B — Lake Formation dựng data lake, dùng Lake Formation job đổi hết sang Apache Parquet, rồi truy vấn bằng Athena hoặc Redshift Spectrum. Parquet là định dạng cột, thực tế rất tốt cho hiệu năng và chi phí quét — nhưng đề không hỏi về hiệu năng, đề hỏi cái đơn giản nhất. Chuyển đổi toàn bộ dữ liệu sang Parquet là thêm một pipeline phải viết, phải chạy định kỳ, phải theo dõi khi hỏng, chưa kể phải dựng và phân quyền một data lake qua Lake Formation. Tất cả những thứ đó là operational overhead cộng thêm, trong khi Athena vốn đã đọc được .csv và JSON nguyên trạng.

D — Glue catalog + Glue job đổi JSON sang .csv, rồi truy vấn hết bằng Athena. Engine ở đây đúng (Athena), nhưng bước biến đổi là thừa: Athena đọc JSON được ngay qua PartiQL, chẳng có lý do gì phải hạ nó xuống .csv. Tệ hơn, .csv là định dạng phẳng, còn JSON thường lồng nhau — ép sang .csv là làm mất cấu trúc lồng, hoặc phải viết thêm logic làm phẳng phức tạp. Vậy là vừa thêm Glue job phải nuôi, vừa có nguy cơ mất thông tin, đổi lại chẳng được gì.

📌 Điểm cần nhớ

• Gặp cụm "least operational overhead" hay "simplest solution": ưu tiên serverless và query-in-place. Mọi phương án có bước chuyển đổi/copy dữ liệu trước khi truy vấn (sang .csv, sang Parquet) đều tự động nặng hơn.
• Athena vs Redshift Spectrum: cùng đọc Glue Data Catalog, nhưng Athena serverless còn Spectrum cần một Redshift cluster đứng sau. Truy vấn ad-hoc, không ràng buộc sẵn với cluster → chọn Athena.
• AWS Glue Data Catalog là lớp metadata dùng chung cho nhiều nguồn (S3, RDS, DynamoDB, Redshift) — khi câu hỏi nói "truy vấn xuyên nhiều nguồn", catalog thường là mảnh ghép chung của mọi phương án, nên đừng dùng nó để phân biệt; hãy nhìn engine và bước ETL.
• JSON không bắt buộc phải phẳng hoá. Athena hỗ trợ PartiQL cho dữ liệu bán cấu trúc/lồng nhau; phương án nào đề xuất đổi JSON sang định dạng phẳng chỉ để truy vấn được thì 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 công ty truyền thông lưu ảnh độ phân giải cao trên Amazon S3. Mẫu truy cập rất rõ: ảnh được đọc nhiều trong tháng đầu sau khi tải lên, sau đó hiếm khi được truy cập.

Cụm từ quyết định đáp án là: "Immediate access is required on demand, even after the initial month" — tức là dù ít đọc, khi cần thì phải lấy được ngay lập tức, không chấp nhận thời gian chờ khôi phục. Cụm thứ hai bổ trợ là "lower their S3 storage costs while maintaining quick access" và chữ COST effective viết hoa: câu hỏi không hỏi phương án nào chạy được, mà hỏi phương án nào rẻ nhất trong số các phương án vẫn giữ được độ trễ thấp.

Hai ràng buộc này kẹp lại thành một khe rất hẹp: bỏ được nhóm archive (vì mất tính tức thời), và bỏ được phương án giữ nguyên S3 Standard (vì không giảm chi phí).

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

B — Store the images in S3 Standard-IA after the first month.

S3 Standard-IA (Infrequent Access) được thiết kế đúng cho dạng dữ liệu ít được đọc nhưng khi đọc thì phải nhanh. Giá lưu trữ mỗi GB thấp hơn S3 Standard, trong khi hiệu năng truy xuất vẫn giữ nguyên đặc tính độ trễ thấp và throughput cao như S3 Standard — không có bước restore, không có hàng chờ khôi phục, object gọi GET là ra ngay.

Ghép với đề bài: tháng đầu ảnh được đọc nhiều thì để ở S3 Standard, sau tháng đầu chuyển sang Standard-IA. Vế "immediate access on demand" được thoả vì Standard-IA truy cập tức thời; vế "lower storage costs" được thoả vì đơn giá lưu trữ rẻ hơn. Đây chính là cặp yêu cầu mà Standard-IA sinh ra để phục vụ.

Lưu ý về cách tính tiền của lớp này: Standard-IA rẻ ở phần lưu trữ nhưng tính thêm phí truy xuất theo lượng dữ liệu đọc ra. Vì vậy nó chỉ có lợi khi dữ liệu thật sự ít được đọc — đúng như đề mô tả "rarely accessed thereafter".

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

A — Use S3 Outposts for on-premises access to the images. Sai ở hai tầng. Thứ nhất, S3 Outposts không phải là một storage class để chuyển dữ liệu sang như Standard-IA hay Glacier; nó là hạ tầng AWS đặt tại trung tâm dữ liệu của khách hàng. Thứ hai, mục đích của nó là đáp ứng yêu cầu dữ liệu phải nằm tại chỗ (độ trễ tới ứng dụng on-premises, hoặc ràng buộc lưu trú dữ liệu) — hoàn toàn không phải bài toán tối ưu chi phí cho dữ liệu ít đọc. Đề không hề nhắc tới ứng dụng on-premises nào.

C — Move the images to S3 Glacier immediately after the first month. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Nó bám rất sát vế "rarely accessed thereafter" và đúng là rẻ hơn Standard-IA về lưu trữ. Chỗ nó hỏng nằm ở đúng ràng buộc phân biệt đã chỉ ra: S3 Glacier là lớp lưu trữ dài hạn dạng archive, dữ liệu phải qua bước khôi phục và thời gian chờ tính bằng phút tới hàng giờ tuỳ hạng truy xuất. Đề đã nói thẳng "Immediate access is required on demand", nên mô hình archive-rồi-restore vi phạm yêu cầu. Rẻ hơn nhưng không đáp ứng được yêu cầu thì không phải "most cost effective" — nó là phương án sai.

D — Keep the images in S3 Standard for high availability access. Phương án này thoả yêu cầu truy cập nhanh, nhưng bỏ qua hoàn toàn vế còn lại của câu hỏi. Đề yêu cầu giảm chi phí lưu trữ; giữ nguyên S3 Standard nghĩa là không giảm gì cả. Với dữ liệu hiếm khi đọc sau tháng đầu, trả giá lưu trữ của lớp dành cho dữ liệu nóng là lãng phí. Đây là dạng phương án "không làm gì" — an toàn về mặt kỹ thuật nhưng trượt tiêu chí tối ưu chi phí mà đề nêu rõ.

📌 Điểm cần nhớ

• Với câu hỏi chọn S3 storage class, hãy tách đề thành hai trục độc lập: tần suất truy cập (quyết định lớp nào rẻ) và độ trễ chấp nhận được khi truy cập (quyết định lớp nào hợp lệ). Trục độ trễ luôn được xét trước — nó loại phương án, còn trục chi phí chỉ dùng để chọn trong số đã hợp lệ.
• Cụm "immediate access", "on demand", "milliseconds" trong đề là tín hiệu loại toàn bộ nhóm Glacier/archive, bất kể chúng rẻ tới đâu. Ngược lại, "retrieval in hours is acceptable", "archive", "compliance retention" mới là tín hiệu cho nhóm archive.
• S3 Standard-IA = ít đọc + vẫn cần lấy ngay; rẻ ở lưu trữ nhưng tính phí truy xuất, nên nó chỉ thắng khi đề khẳng định dữ liệu thật sự hiếm được đọc. Nếu đề nói dữ liệu được đọc thường xuyên, Standard-IA có thể đắt hơn Standard.
• S3 Outposts không phải storage class — nó chỉ xuất hiện đúng khi đề nói tới ứng dụng on-premises hoặc yêu cầu dữ liệu phải nằm tại chỗ. Thấy nó trong câu hỏi thuần về tối ưu chi phí lưu trữ thì gần như chắc chắn là phương án nhiễu.
• Phương án "giữ nguyên hiện trạng" (ở đây là S3 Standard) chỉ đúng khi đề không yêu cầu cải thiện gì. Đề đã viết hoa COST thì phương án không giảm được chi phí tự động bị loại.

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

Đề mô tả một hệ thống nhận nhiều loại event khác nhau do nhiều ứng dụng trong tổ chức sinh ra, và cần định tuyến (route) từng event tới đúng AWS service để xử lý và phân tích, với yêu cầu scalable và xử lý được lượng event lớn.

Cụm từ quyết định đáp án là: "route these events to specific AWS services ... based on the type of event". Đây không phải bài toán xử lý dòng dữ liệu, cũng không phải bài toán điều phối các bước trong một quy trình — mà là bài toán router theo nội dung/loại event: nhìn vào event, so khớp với một luật, rồi đẩy sang target tương ứng.

Thêm một cụm nữa cũng đáng chú ý: "scalable and able to handle many events efficiently". Cụm này loại bỏ những phương án đòi bạn tự viết logic phân loại bằng tay, vì việc đó vừa phải tự bảo trì vừa phải tự lo phần mở rộng.

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

Đáp án đúng theo tệp là B — Amazon EventBridge.

EventBridge là một serverless event bus: các ứng dụng, các AWS service và cả dịch vụ bên ngoài đẩy event vào bus, còn EventBridge dùng rules so khớp theo nội dung event (event pattern) để quyết định event nào đi tới target nào. Đây đúng là mô hình mà đề mô tả — nhiều nguồn phát sinh nhiều loại event, mỗi loại đi về một service xử lý riêng.

Điểm mạnh khớp với đề:

• Định tuyến theo nội dung là chức năng dựng sẵn, khai báo bằng rule chứ không phải viết code phân loại.
• Hỗ trợ nhiều target AWS khác nhau cho cùng một bus, nên "gửi tới các service phù hợp" chỉ là chuyện thêm rule.
• Serverless, không phải quản lý hạ tầng hay tự lo việc mở rộng khi lượng event tăng — đúng yêu cầu "scalable ... handle many events efficiently".

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

A — AWS Step Functions để orchestrate việc routing. Step Functions là dịch vụ điều phối workflow: định nghĩa các bước, thứ tự, rẽ nhánh, retry, xử lý lỗi giữa các microservice. Nó giải quyết câu hỏi "chạy những bước nào, theo trình tự nào", chứ không phải "event này thuộc loại gì thì gửi đi đâu". Dùng nó làm router nghĩa là bạn vẫn phải có thứ gì đó nhận event và khởi động state machine, rồi dựng nhánh Choice cho từng loại event — sai vai trò của công cụ. Step Functions rất hợp làm target phía sau một router, không hợp làm chính cái router.

C — AWS Lambda tự parse và dispatch event. Đây là phương án gần đúng nhất về mặt kết quả: Lambda hoàn toàn có thể đọc event rồi gọi service tương ứng. Chỗ hỏng nằm ở chữ "manually": toàn bộ logic phân loại trở thành code bạn tự viết, tự test, tự sửa mỗi lần thêm một loại event mới — trong khi EventBridge cho phép khai báo bằng rule. Ngoài ra bạn phải tự dựng phần tiếp nhận event và tự lo việc mở rộng cho lượng event lớn, tức là làm lại bằng tay đúng thứ một dịch vụ chuyên dụng đã có sẵn. Bài thi ưu tiên giải pháp quản trị sẵn hơn giải pháp tự code khi hai bên cùng ra một kết quả.

D — Amazon Kinesis Data Streams để lọc và route. Kinesis Data Streams mạnh ở streaming dữ liệu thời gian thực với thông lượng cao: ghi record vào shard, consumer đọc theo thứ tự trong shard, giữ lại dữ liệu để xử lý lại. Nhưng nó không có cơ chế định tuyến theo pattern của event — bản thân stream không biết "event loại X thì gửi tới service Y". Muốn có hành vi đó bạn phải viết consumer tự đọc, tự phân loại, tự dispatch, tức là quay lại đúng vấn đề của phương án C. Kinesis hợp với bài toán ingest và xử lý luồng bản ghi liên tục, không hợp với bài toán fan-out theo loại event.

📌 Điểm cần nhớ

• Thấy đề nói "route events based on type/content" kèm nhiều target khác nhau → nghĩ ngay tới Amazon EventBridge và cơ chế rules + event pattern.
• Phân biệt vai trò: EventBridge = router theo nội dung event; Step Functions = điều phối các bước trong workflow; Kinesis Data Streams = ingest và xử lý luồng dữ liệu thông lượng cao.
• Khi một phương án là "dùng Lambda tự parse và dispatch", hãy hỏi: có dịch vụ quản trị sẵn nào làm đúng việc này bằng cấu hình không? Nếu có, phương án tự code thường là bẫy vì tốn công phát triển và bảo trì.
• Cụm "scalable / handle many events / minimal effort" trong đề thường là tín hiệu chọn giải pháp serverless, khai báo bằng rule thay vì giải pháp phải tự viết logic hoặc tự quản lý hạ tầng.

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

Một agency marketing thu thập dữ liệu tương tác khách hàng từ nhiều nền tảng SaaS, cần gom hết về một bucket Amazon S3 trước khi phân tích bằng Amazon Redshift. Câu hỏi là chọn dịch vụ nào để chuyển dữ liệu từ SaaS về S3.

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

• "sourced from multiple SaaS platforms" — nguồn dữ liệu là ứng dụng SaaS bên thứ ba (kiểu Salesforce, Zendesk, Google Analytics), chứ không phải máy chủ file, không phải sự kiện nội bộ trong AWS, cũng không phải bộ dữ liệu thương mại bán sẵn.
• "most straightforward and maintenance-light" / "minimal operational effort" — loại ngay mọi phương án đòi viết mã tích hợp riêng hoặc dựng hạ tầng để vận hành.

Ghép hai ràng buộc lại: cần một dịch vụ tích hợp có sẵn connector tới các SaaS phổ biến, cấu hình không cần viết mã. Phần Redshift chỉ là bối cảnh phía sau — đề đã nói rõ dữ liệu phải nằm ở S3 trước khi phân tích, nên đích đến cần giải quyết là S3.

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

C — Amazon AppFlow là dịch vụ tích hợp fully managed, sinh ra đúng cho việc chuyển dữ liệu an toàn giữa các ứng dụng SaaS và các dịch vụ AWS như S3, theo kiểu no-code.

Nó khớp từng chữ trong đề:

• Có sẵn connector cho các nền tảng SaaS phổ biến, nên không phải tự viết mã gọi API của từng nền tảng, không phải tự lo phân trang, retry hay xác thực.
• Cấu hình một flow rồi hẹn lịch chạy theo chu kỳ mong muốn (hoặc chạy theo sự kiện), dữ liệu tự đổ vào S3.
• Fully managed: không có server, không có cụm nào để vá lỗi hay mở rộng — đúng nghĩa "maintenance-light".

Dữ liệu đã nằm trong S3 rồi thì agency phân tích tiếp bằng Redshift như dự định.

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

A — Amazon EventBridge. Đây là gần đúng nhất và cũng là bẫy chính. EventBridge có khái niệm partner event source nên nghe như "nối được với SaaS". Nhưng bản chất nó là event bus: nhận sự kiện rời rạc rồi định tuyến tới target, dùng để điều phối luồng xử lý. Nó không phải công cụ kéo dữ liệu (bulk/scheduled data transfer) từ SaaS đổ thẳng vào S3. Muốn dùng nó cho bài toán này phải tự ghép thêm target xử lý và mã trung gian — tức là thêm việc phải bảo trì, đi ngược ràng buộc "minimal operational effort".

B — AWS Data Exchange. Sai vì nhầm loại dữ liệu. Data Exchange dùng để tìm kiếm, đăng ký (subscribe) và sử dụng dữ liệu của bên thứ ba được phát hành trên marketplace. Nó phục vụ trường hợp bạn muốn mua/lấy một bộ dữ liệu do nhà cung cấp khác công bố. Ở đây dữ liệu là của chính agency, nằm trong các tài khoản SaaS mà họ đang dùng — Data Exchange không có cơ chế nào để rút dữ liệu riêng đó ra.

D — AWS Transfer Family. Sai vì nhầm giao thức. Transfer Family cung cấp endpoint managed cho SFTP, FTPS, FTP (và AS2) để đẩy/lấy file vào S3. Nó giả định phía đối tác chủ động đẩy file qua các giao thức đó. Các nền tảng SaaS thường phơi dữ liệu qua REST API, không tự bắn file qua SFTP — nên muốn dùng phương án này vẫn phải có ai đó xuất dữ liệu ra file rồi tự upload, tức là còn nguyên phần việc mà đề muốn loại bỏ.

📌 Điểm cần nhớ

• Thấy "SaaS application" + "no-code" / "least operational overhead" trong đề bài AWS về ingestion → nghĩ tới Amazon AppFlow trước tiên; đó là chữ ký nhận dạng của dịch vụ này.
• Phân biệt ba dịch vụ hay bị trộn lẫn theo loại nguồn: AppFlow = dữ liệu của bạn trong ứng dụng SaaS; Data Exchange = dữ liệu bên thứ ba phát hành trên marketplace; Transfer Family = file đi qua SFTP/FTPS/FTP.
• EventBridge là bus định tuyến sự kiện, không phải đường ống chuyển dữ liệu theo lô. Nó hợp để kích hoạt một luồng, không hợp để tải dữ liệu.
• Cụm "minimal operational effort" gần như luôn ưu tiên dịch vụ fully managed có connector sẵn hơn là phương án ghép nhiều mảnh, kể cả khi phương án ghép về mặt kỹ thuật vẫn chạy được.

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

Đề mô tả một công ty logistics có dữ liệu vận đơn ở nhiều định dạng khác nhau nằm trong Amazon S3, và cần làm sạch, biến đổi, hợp nhất chúng thành dạng có cấu trúc để phân tích và báo cáo.

Cụm từ quyết định nằm ở câu cuối phần mô tả: "The process should be automated and scalable" — quy trình phải tự động và co giãn được khi khối lượng dữ liệu tăng lên. Cộng thêm việc đề hỏi thẳng "What AWS service should the team use to efficiently perform ETL operations", ta có hai ràng buộc đồng thời:

1. Đây là bài toán ETL đúng nghĩa — trích xuất, biến đổi, nạp — chứ không phải bài toán truy vấn hay báo cáo.
2. Đội ngũ không muốn tự vận hành hạ tầng: "automated and scalable" ám chỉ hướng managed/serverless, để việc mở rộng theo dữ liệu là chuyện của dịch vụ chứ không phải của người vận hành.

Cả bốn phương án đều có thể đụng tới dữ liệu trong S3. Chỗ phân biệt là: cái nào là dịch vụ ETL chuyên dụng và không bắt quản lý hạ tầng.

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

C — AWS Glue. Glue là dịch vụ data integration serverless, được thiết kế đúng cho việc khám phá, chuẩn bị và kết hợp dữ liệu phục vụ phân tích. Nó khớp cả hai ràng buộc của đề:

• Đúng bài toán: Glue làm ETL là nhiệm vụ chính chứ không phải công dụng phụ. Nó lập catalog dữ liệu (rất hợp với tình huống "various formats" — cần biết dữ liệu có schema gì trước khi biến đổi), làm sạch, làm giàu, rồi chuyển dữ liệu giữa các kho một cách tin cậy.
• Đúng mô hình vận hành: vì serverless, công ty mở rộng quy mô ETL mà không phải quản lý hạ tầng nào — không cluster, không sizing, không patching. Đó chính là nghĩa của "automated and scalable" trong đề.

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

A — Amazon Redshift Spectrum. Sai vì nhầm loại công cụ. Spectrum cho phép truy vấn dữ liệu nằm trong S3 từ Redshift mà không cần nạp vào kho trước — nó là công cụ truy vấn/phân tích, không phải công cụ ETL. Nó mạnh ở việc chạy truy vấn phức tạp trên tập dữ liệu lớn, nhưng phần "transform và load" — làm sạch, chuẩn hoá nhiều định dạng, ghi kết quả ra dạng có cấu trúc — không phải việc của nó. Đề nói rõ cần consolidate thành structured format, tức là phải có bước ghi ra, chứ không chỉ đọc tại chỗ.

B — Amazon EMR chạy custom ETL script. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất: EMR thật sự chạy được ETL, và với script tuỳ biến thì làm được mọi thứ Glue làm. Chỗ nó hỏng là mô hình vận hành: EMR đòi bạn quản lý cluster — chọn kích cỡ, cấu hình, theo dõi, mở rộng. So với bản chất serverless và managed của Glue, EMR tốn công vận hành hơn hẳn, nên không phải lựa chọn thẳng thớm nhất cho một đội chỉ muốn quy trình "automated and scalable". Khi đề không nêu yêu cầu đặc thù buộc phải dùng framework riêng hay tinh chỉnh cluster, EMR luôn thua Glue ở tiêu chí vận hành.

D — AWS Lambda kích hoạt ETL khi có file upload. Cũng gần đúng ở chỗ nó cho ta phần "tự động" — trigger theo sự kiện upload lên S3 nghe rất hợp lý. Nhưng nó hỏng ở quy mô: Lambda hợp với các tác vụ xử lý nhỏ, hướng sự kiện, còn đề nói "large datasets" và dữ liệu sẽ tăng dần. Với phép biến đổi phức tạp trên tập dữ liệu lớn, Lambda không thực tế do giới hạn về thời gian chạy và tài nguyên mỗi lần gọi. Tự động ≠ đủ sức tải; đề đòi cả hai.

📌 Điểm cần nhớ

• Đề hỏi ETL trên S3 + serverless/ít vận hành thì mặc định nghĩ tới AWS Glue — nó là dịch vụ data integration chuyên dụng, gồm cả catalog cho dữ liệu nhiều định dạng.
• Phân biệt công cụ truy vấn với công cụ ETL: Redshift Spectrum (và các dịch vụ query-in-place) dùng để đọc và phân tích dữ liệu tại chỗ, không phải để biến đổi và nạp.
• EMR vs Glue gần như luôn được quyết bởi từ khoá vận hành: đề nhắc "managed", "serverless", "no infrastructure to manage", "giảm operational overhead" → Glue. Đề nhắc framework cụ thể hoặc nhu cầu kiểm soát/tinh chỉnh cluster → EMR.
• Lambda là bẫy quy mô: nó thắng ở các tác vụ ngắn, nhẹ, hướng sự kiện; hễ đề nói "large datasets", "increasing data volumes" hay biến đổi phức tạp thì loại Lambda dù phần trigger nghe rất khớp.

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

Đề mô tả một đội data engineering trên Amazon Redshift có nhiều complex query chạy trên các tập dữ liệu lớn đã join, và hỏi nên dùng tính năng nào để tăng hiệu năng truy vấn.

Cụm từ quyết định đáp án nằm ở vế cuối câu hỏi: "especially for frequently executed queries that join multiple tables" — truy vấn chạy đi chạy lại nhiều lần và join nhiều bảng. Thêm một tín hiệu nữa được gài sẵn trong phần mô tả: đội đã "considering the use of materialized views".

Hai chi tiết đó gộp lại chỉ đúng một hướng: kết quả của phép join đắt tiền là lặp lại và đoán trước được, nên thay vì tính lại mỗi lần chạy, hãy tính trước một lần và lưu lại. Đây chính là định nghĩa của materialized view. Các phương án còn lại đều nói về việc sắp xếp, ưu tiên, hoặc dời chỗ chạy truy vấn — không phương án nào loại bỏ được công việc join lặp lại.

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

D — Use Redshift's Query Optimizer with materialized views to precompute and store the results of complex joins.

Materialized view trong Redshift lưu sẵn kết quả đã tính của một truy vấn, bao gồm cả các phép join và tổng hợp tốn kém. Chi phí join lớn được trả một lần lúc dựng (và lúc refresh), thay vì trả lại từ đầu ở mỗi lần truy vấn.

Điểm mạnh thứ hai nằm ở phía Query Optimizer: khi một truy vấn tới có thể được phục vụ từ materialized view đã có, optimizer có khả năng dùng lại view đó để trả kết quả nhanh hơn — người dùng không nhất thiết phải viết lại truy vấn để trỏ thẳng vào view.

Đúng như đề nhấn mạnh, cách này phát huy tác dụng nhất với mẫu truy vấn lặp lại và đoán trước được — tức là tình huống được mô tả trong đề.

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

A — Automatic workload management (WLM). WLM là công cụ quản lý tài nguyên: chia bộ nhớ, phân luồng, và ưu tiên các loại truy vấn khác nhau. Đây là phương án gần đúng vì WLM thật sự ảnh hưởng tới hiệu năng cảm nhận được — nhưng nó hỏng ở chỗ: WLM không thay đổi execution plan và không làm phép join nào rẻ đi. Một truy vấn join nặng được cấp nhiều bộ nhớ hơn vẫn phải thực hiện đúng khối lượng join đó, ở mọi lần chạy.

B — Short query acceleration (SQA). SQA được thiết kế để truy vấn ngắn, tính chất tương tác không bị kẹt sau truy vấn dài. Đề bài lại nói về complex query trên large joined datasets — tức là chính nhóm truy vấn dài mà SQA không nhắm tới. Phương án này còn tự mâu thuẫn: nó nói "prioritize execution of the complex join queries", trong khi SQA vốn ưu tiên theo hướng ngược lại. Và giống A, bản chất SQA là xếp thứ tự chạy, không phải tối ưu bản thân truy vấn.

C — Redshift Spectrum với external tables. Spectrum dùng để truy vấn dữ liệu nằm trên S3 mà không nạp vào Redshift. Nó giải quyết một bài toán khác: mở rộng phạm vi dữ liệu truy vấn được, chứ không phải tăng tốc join giữa các bảng đã nằm sẵn trong Redshift. Áp vào tình huống của đề, việc đẩy dữ liệu ra ngoài rồi join qua external table nhiều khả năng làm chậm đi chứ không nhanh lên, vì thêm một lớp đọc dữ liệu ngoài. Đề không hề nói dữ liệu nằm trên S3 hay kho dữ liệu quá lớn để chứa — nên tiền đề của phương án này không tồn tại trong đề.

📌 Điểm cần nhớ

• Thấy cụm "frequently executed" + "joins multiple tables" + kết quả lặp lại trong đề Redshift → nghĩ ngay tới materialized view: trả chi phí tính toán một lần, dùng lại nhiều lần.
• Phân biệt rõ hai nhóm tính năng: WLM và SQA quản lý cách chạy (bộ nhớ, hàng đợi, thứ tự ưu tiên), còn materialized view thay đổi khối lượng việc phải làm. Đề hỏi "tối ưu truy vấn" thì nhóm sau mới trúng.
• SQA nhắm vào truy vấn ngắn, không phải truy vấn phân tích dài. Phương án nào ghép SQA với "complex join query" là dấu hiệu sai ngay từ mô tả.
• Redshift Spectrum trả lời câu hỏi "dữ liệu ở đâu", không trả lời "truy vấn có nhanh không". Chỉ chọn Spectrum khi đề nêu rõ dữ liệu nằm trên S3 hoặc không muốn nạp vào cluster.

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

Đề mô tả một công ty game mobile dùng Amazon DynamoDB để lưu dữ liệu phiên chơi (player session data). Dữ liệu này hết giá trị sau 24 giờ và cần được xoá tự động để tiết kiệm dung lượng lưu trữ và chi phí.

Cụm từ quyết định đáp án nằm ở câu hỏi cuối: "automatically remove outdated ... data after 24 hours" — tức là cần một cơ chế tự động xoá item dựa trên mốc thời gian, không cần ai bấm nút, không cần viết job dọn dẹp. Hai chữ khoá phải tách bạch:

• automatically → loại mọi phương án cần lệnh ghi/xoá do ứng dụng chủ động phát ra;
• after 24 hours → loại mọi phương án chỉ liên quan tới throughput hoặc tới việc phản ứng với thay đổi dữ liệu.

Đề không hỏi cách tối ưu chi phí đọc/ghi, cũng không hỏi cách xử lý sự kiện sau khi dữ liệu thay đổi. Đọc lướt rất dễ bị hai phương án đó dẫn đi lạc.

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

Đáp án đúng là B — DynamoDB TTL (Time To Live).

TTL là tính năng cho phép bạn chỉ định một thuộc tính trong item chứa mốc thời gian hết hạn (dạng epoch timestamp). Khi mốc đó trôi qua, DynamoDB tự đánh dấu item là đã hết hạn và xoá nó khỏi bảng trong nền, không cần ứng dụng can thiệp.

Áp vào tình huống của đề: mỗi lần ghi một session, ứng dụng gắn thêm thuộc tính TTL bằng "thời điểm tạo + 24 giờ". Từ đó DynamoDB tự dọn dẹp — đúng nghĩa "automatically remove after 24 hours" mà đề yêu cầu.

Điểm khiến TTL phù hợp với vế "save storage space and reduce costs": việc xoá do TTL chạy ở tiến trình nền và không tiêu tốn write throughput của bảng. Nếu tự viết cơ chế dọn dẹp, mỗi lần xoá là một thao tác ghi có tính phí; TTL bỏ được toàn bộ chi phí đó, đồng thời giảm dung lượng lưu trữ vì item hết hạn biến mất thật sự.

Lưu ý về nguyên lý (đề không hỏi nhưng nên biết): TTL đảm bảo item sẽ bị xoá sau khi hết hạn, nhưng thời điểm xoá thực tế là "trong nền", không tức thời tại đúng giây thứ 86.400. Với dữ liệu session game, độ trễ này không thành vấn đề.

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

A — DynamoDB Auto Scaling. Đây là tính năng điều chỉnh read/write capacity của bảng theo tải thực tế, giúp bảng không bị throttle lúc cao điểm và không trả tiền thừa lúc thấp điểm. Nó đúng nửa vế "reduce costs" của đề nên trông hấp dẫn — nhưng đó là chi phí throughput, không phải chi phí lưu trữ, và Auto Scaling không xoá bất kỳ item nào. Dữ liệu 24 giờ trước vẫn nằm nguyên trong bảng, càng ngày càng phình ra.

C — DynamoDB Conditional Writes. Đây là cơ chế cho phép một thao tác ghi (kể cả DeleteItem) chỉ được thực hiện nếu điều kiện bạn nêu là đúng, ví dụ chỉ xoá khi thuộc tính thời gian nhỏ hơn một giá trị nào đó. Đây là phương án gần đúng nhất trong ba phương án sai, vì nó có liên quan tới việc xoá và có liên quan tới điều kiện thời gian. Chỗ nó hỏng: conditional write không tự khởi động. Phải có ai đó — ứng dụng hoặc một tiến trình quét bảng — chủ động phát ra lệnh xoá thì điều kiện mới được kiểm tra. Nó là "bộ lọc an toàn cho lệnh ghi", không phải "bộ hẹn giờ tự xoá". Ngoài ra mỗi lần xoá như vậy vẫn tốn write capacity, đi ngược vế tiết kiệm chi phí.

D — DynamoDB Streams. Streams ghi lại các thay đổi trên item (thêm/sửa/xoá) theo thứ tự, gần thời gian thực, để hệ thống khác tiêu thụ — thường là kích hoạt AWS Lambda hoặc nhân bản dữ liệu. Đây là cơ chế phản ứng sau khi dữ liệu đã đổi, chứ tự nó không tạo ra thay đổi nào. Nó không hề biết item nào "cũ" hay "quá 24 giờ", và không xoá gì cả. Streams thường xuất hiện cùng TTL (bắt sự kiện item bị TTL xoá để lưu trữ nơi khác), nhưng vai trò dọn dẹp vẫn thuộc về TTL — Streams chỉ là bên nghe.

📌 Điểm cần nhớ

• Trong DynamoDB, chỉ có TTL là cơ chế xoá item tự động theo mốc thời gian. Thấy đề nói "expire", "after N hours/days", "automatically delete old records" thì gần như chắc chắn đáp án là TTL.
• Phân biệt hai loại "tiết kiệm chi phí": Auto Scaling tiết kiệm chi phí throughput (read/write capacity), TTL tiết kiệm chi phí storage. Đề nói "storage space" là loại được Auto Scaling ngay.
• Phân biệt chủ động với bị động: Conditional Writes cần ứng dụng phát lệnh mới chạy; Streams chỉ ghi nhận thay đổi do người khác gây ra. Không cái nào tự sinh ra hành động xoá theo thời gian.
• TTL xoá ở tiến trình nền và không tiêu tốn write capacity, nên nó rẻ hơn hẳn việc tự viết job quét bảng rồi xoá từng item. Đổi lại, thời điểm xoá là "sau khi hết hạn" chứ không chính xác tuyệt đối tới từng giây.

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

Một studio ảnh lưu file ảnh độ phân giải cao trong Amazon S3 và đang gặp cảnh ghi đè nhầm lên file quan trọng. Họ cần giải pháp vừa chống ghi đè và xoá nhầm, vừa giữ cho phiên bản mới nhất luôn truy cập được ngay.

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

• "prevent the overwriting and accidental deletion" — vấn đề là khôi phục lại được nội dung cũ khi có ai đó ghi đè hoặc xoá, chứ không phải khoá cứng dữ liệu.
• "ensuring that the latest version of a file is readily accessible" — bản mới nhất vẫn phải nằm ở tầng truy cập tức thì, không được đẩy đi đâu, và ghi đè vẫn phải được phép diễn ra bình thường.
• Thêm một ràng buộc về hình thức: "which single feature" — chỉ chọn đúng một tính năng, không ghép nhiều thứ lại.

Hai vế này chống nhau nếu chọn sai: giải pháp nào chặn hẳn thao tác ghi thì vi phạm nhu cầu làm việc thường ngày của studio; giải pháp nào chỉ tối ưu chi phí lưu trữ thì không đụng gì tới chuyện mất dữ liệu.

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

B — Activate S3 Versioning to maintain multiple versions of each file.

S3 Versioning giữ nhiều phiên bản của cùng một object trong cùng bucket. Khi bật:

• Ghi đè một key không xoá nội dung cũ mà tạo thêm một version mới; version cũ vẫn còn nguyên và lấy lại được bằng version ID.
• Xoá một object không huỷ dữ liệu mà đặt một delete marker lên trên; gỡ marker đó là object trở lại.
• Yêu cầu GET thông thường (không kèm version ID) luôn trả về version mới nhất, nên "bản mới nhất truy cập ngay" được thoả mãn mà không cần thao tác gì thêm.

Đúng như phần giải thích của đề: đây là tính năng duy nhất trong danh sách vừa chống mất dữ liệu do ghi đè/xoá, vừa giữ bản hiện hành sẵn sàng — và nó là một tính năng đơn lẻ, khớp với "single feature".

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

A — S3 Object Lock in compliance mode (WORM). Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Object Lock thật sự chống ghi đè và xoá, nhưng ở compliance mode thì trong thời hạn giữ, không ai gỡ được — kể cả tài khoản root. Đó là mức bất biến dành cho yêu cầu tuân thủ pháp lý, chặt hơn nhiều so với nhu cầu "lỡ tay ghi đè thì lấy lại được" của một studio ảnh. Chọn nhầm mode này là tự khoá tay mình. Ngoài ra Object Lock chỉ hoạt động trên bucket đã bật Versioning — nên nó không phải là một tính năng độc lập thay thế được Versioning, mà là lớp xây thêm lên trên.

C — S3 Lifecycle policies archive older versions sang S3 Glacier. Sai theo hai hướng. Thứ nhất, Lifecycle là công cụ quản lý vòng đời và chi phí, nó không hề ngăn thao tác ghi đè hay xoá xảy ra. Thứ hai, chính cụm từ "older versions" trong phương án đã tự tố cáo: muốn có "phiên bản cũ" để mà archive thì Versioning phải được bật trước rồi. Nó là bước đi sau, không phải lời giải cho vấn đề. Tệ hơn, đẩy dữ liệu sang lớp lưu trữ archive còn làm việc truy xuất chậm đi thay vì nhanh lên.

D — S3 Intelligent-Tiering. Đây là tính năng tối ưu chi phí: tự động chuyển object giữa các tầng truy cập theo tần suất được dùng. Nó không tạo bản sao, không giữ lịch sử, không can thiệp vào thao tác PUT hay DELETE. Bật lên thì studio vẫn mất file y như cũ, chỉ khác là hoá đơn lưu trữ có thể rẻ hơn. Hoàn toàn lệch chủ đề của câu hỏi.

📌 Điểm cần nhớ

• Đề nhắc "accidental overwrite / accidental deletion" kèm nhu cầu khôi phục → mặc định nghĩ tới S3 Versioning. Đây là phản xạ nên có.
• Phân biệt ba nhóm tính năng S3 để khỏi lẫn: bảo vệ dữ liệu (Versioning, Object Lock, MFA Delete), tối ưu chi phí (Lifecycle, Intelligent-Tiering, các storage class), hiệu năng/phân phối. Đề hỏi nhóm nào thì loại thẳng hai nhóm còn lại.
• Object Lock cần Versioning làm nền. Khi đề yêu cầu một tính năng và có cả hai trong danh sách, Versioning là lựa chọn nền tảng; chỉ chọn Object Lock khi đề nói rõ về compliance, regulatory, WORM, immutable, retention period.
• Cẩn thận với compliance mode: không thể rút ngắn hay gỡ bỏ trong thời hạn giữ. Nếu đề mô tả nhu cầu vận hành thông thường (vẫn phải sửa, vẫn phải cập nhật file), mức bảo vệ này là quá tay và thành đáp án sai.
• Cụm "latest version readily accessible" loại ngay mọi phương án đẩy dữ liệu sang tầng archive.

Đáp án

A và B — thiếu quyền IAM cho QuickSight, và chính sách khoá KMS không có QuickSight

Vì sao đúng

Chuỗi truy cập ở đây đi qua nhiều tầng, và QuickSight phải được cấp quyền riêng ở từng tầng:

QuickSight → Athena → S3 → (dữ liệu được mã hoá bằng KMS)

• A. Quyền IAM — QuickSight dùng vai riêng của nó, không mượn quyền của người đang đăng nhập. Vai đó phải được phép gọi Athena và đọc S3.
• B. Chính sách khoá KMS — nếu dữ liệu được mã hoá bằng khoá do khách hàng quản lý thì QuickSight phải nằm trong danh sách principal được phép giải mã. Đây là tầng hay bị quên nhất, vì nó nằm ngoài IAM thông thường.

Vì sao các phương án khác sai

• C. Bucket bật chặn truy cập công khai — thiết lập này chặn truy cập ẩn danh; nó không ảnh hưởng tới dịch vụ đã được cấp quyền qua IAM.
• D. Cấu hình VPC hạn chế — chỉ liên quan khi QuickSight kết nối vào tài nguyên trong VPC; S3 và Athena là dịch vụ công cộng.
• E. Hết dung lượng SPICE — sẽ báo lỗi về dung lượng, không phải lỗi về quyền.