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

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

Đề mô tả một đội đang xây dựng ứng dụng Java cần kết nối tới Amazon Aurora MySQL, và hỏi nên dùng giao thức/API kết nối cơ sở dữ liệu nào để vừa tương thích vừa cho hiệu năng tốt.

Cụm từ quyết định đáp án là "Java-based application" đi kèm "database connection protocol". Hai vế này khoá chặt phạm vi lựa chọn:

• "database connection" loại thẳng mọi thứ không phải giao thức kết nối CSDL — dù nghe có vẻ "chuẩn công nghiệp" đến đâu.
• "Java-based" dùng để phân biệt giữa những lựa chọn đều kết nối được CSDL, nhưng chỉ một cái là chuẩn dành riêng cho hệ sinh thái Java.

Đây là dạng câu hỏi mà bốn phương án cố tình xếp cạnh nhau bốn từ viết tắt bốn chữ nghe giống nhau (ODBC / SOAP / JDBC / AMQP). Cách xử lý là phân loại từng cái theo mục đích tồn tại của nó, chứ không phải theo cảm giác quen tai.

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

C — Java Database Connectivity (JDBC) là đáp án đúng.

JDBC là API chuẩn của Java định nghĩa cách một ứng dụng client truy cập cơ sở dữ liệu quan hệ: mở connection, gửi câu SQL, nhận và duyệt result set, quản lý transaction. Nó là lớp kết nối CSDL bản địa của nền tảng Java, nên khớp trực tiếp với cả hai ràng buộc trong đề.

Về phía Aurora MySQL: Aurora MySQL tương thích với giao thức wire của MySQL, nên MySQL JDBC driver (hoặc AWS JDBC Driver for MySQL) cắm vào endpoint của cluster là chạy được, không cần lớp trung gian nào. Ứng dụng Java nói chuyện với database qua JDBC là con đường ngắn nhất — ít lớp chuyển đổi hơn thì độ trễ và chi phí xử lý cũng thấp hơn, đúng với yêu cầu "optimal performance" trong đề.

Ngoài ra, gần như toàn bộ hệ sinh thái truy cập dữ liệu của Java (connection pool, ORM, framework) đều xây trên JDBC, nên chọn JDBC còn là chọn thứ tương thích rộng nhất với phần còn lại của ứng dụng.

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

A — Open Database Connectivity (ODBC). Đây là phương án gần đúng nhất, và cũng là cái bẫy chính của câu hỏi. ODBC thật sự là một API chuẩn để truy cập hệ quản trị CSDL, và ODBC driver cho MySQL/Aurora MySQL có tồn tại — nên không thể gạt nó đi bằng câu "không kết nối được database". Chỗ nó hỏng là ở vế "Java-based": ODBC là chuẩn có tính đa mục đích, sinh ra trong thế giới C/C++ và các ngôn ngữ gọi được thư viện native. Với một ứng dụng Java, dùng ODBC nghĩa là phải bắc thêm một lớp cầu nối sang thư viện native thay vì gọi thẳng API của nền tảng — thêm lớp, thêm phụ thuộc, thêm điểm hỏng, và kém tối ưu hơn JDBC. Đề đã nêu rõ tiêu chí "compatibility and optimal performance", nên ODBC thua ở đúng hai tiêu chí đó.

B — Simple Object Access Protocol (SOAP). SOAP là giao thức trao đổi thông tin có cấu trúc (dựa trên XML) dùng cho web service — tức là để hai ứng dụng nói chuyện với nhau qua mạng theo kiểu gọi dịch vụ. Nó hoàn toàn không phải giao thức kết nối cơ sở dữ liệu và không có khái niệm connection, SQL statement hay result set. Không có cách nào để một ứng dụng Java dùng SOAP kết nối trực tiếp vào Aurora MySQL.

D — Advanced Message Queuing Protocol (AMQP). AMQP là giao thức tầng ứng dụng mở dành cho message-oriented middleware — hàng đợi thông điệp, publish/subscribe, giao tiếp bất đồng bộ giữa các thành phần. Nó giải quyết một bài toán khác hẳn: chuyển thông điệp giữa producer và consumer, chứ không phải truy vấn dữ liệu trong một cơ sở dữ liệu quan hệ. Đưa AMQP vào đây là nhầm lẫn giữa "kết nối tới database" và "trao đổi thông điệp giữa các service".

📌 Điểm cần nhớ

• JDBC = chuẩn kết nối CSDL của Java; ODBC = chuẩn kết nối CSDL đa mục đích, gốc từ C/C++. Đề nêu ngôn ngữ là Java thì chọn JDBC; đây gần như luôn là điểm phân biệt giữa hai phương án này.
• Aurora MySQL tương thích wire protocol của MySQL, nên driver MySQL tiêu chuẩn dùng được với endpoint của Aurora cluster — không cần giao thức đặc thù nào khác.
• Phân loại từ viết tắt theo mục đích tồn tại, đừng theo độ quen tai. SOAP thuộc nhóm web service, AMQP thuộc nhóm message queue — cả hai đều không nằm trong nhóm database connectivity, nên bị loại ngay ở bước đọc đề.
• Khi đề vừa nêu ngôn ngữ lập trình vừa nêu tiêu chí hiệu năng, hãy ưu tiên lựa chọn bản địa của ngôn ngữ đó: ít lớp trung gian hơn thường đồng nghĩa với tương thích tốt hơn và độ trễ thấp hơn.

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

Đề mô tả một AWS Glue job đọc dữ liệu từ S3 bucket, chạy trong VPC. Có ba dữ kiện được cài sẵn để thu hẹp phạm vi:

1. "the IAM role and AWS Glue connections are correctly configured" — đề đã tuyên bố thẳng rằng IAM role và Glue connection không phải nguyên nhân. Đây là cách ra đề kinh điển: loại trừ trước một phương án nghe rất hợp lý.
2. "suggesting an issue with the S3 VPC endpoint configuration" — đây là cụm từ quyết định. Lỗi không nói "access denied vì thiếu quyền IAM", cũng không nói "endpoint không tồn tại trong subnet", mà nói vấn đề nằm ở cấu hình của chính VPC endpoint.
3. Câu hỏi yêu cầu một hành động khắc phục, tức là phải chọn thứ nằm bên trong cấu hình endpoint.

Ghép lại: thứ duy nhất được gọi là "configuration" của một S3 gateway VPC endpoint mà có thể chặn traffic, trong khi IAM đã đúng và endpoint đã tồn tại, chính là endpoint policy.

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

D — Kiểm tra endpoint policy gắn trên S3 VPC endpoint có cho phép traffic của AWS Glue hay không.

VPC endpoint policy là một resource policy riêng biệt, gắn trực tiếp lên endpoint, dùng để kiểm soát chi tiết ai được đi qua endpoint đó và tới bucket/action nào. Nó hoạt động độc lập với IAM role: quyền truy cập S3 thực tế là giao của IAM policy, bucket policy và endpoint policy. Do đó một IAM role có đầy đủ s3:GetObject vẫn có thể bị chặn nếu endpoint policy quá hẹp — chỉ liệt kê vài bucket ARN cụ thể, hoặc dùng điều kiện principal/source không bao gồm luồng truy cập của Glue job.

Đây đúng là kiểu lỗi khớp với mô tả "issue with the S3 VPC endpoint configuration": đường mạng thông, endpoint có mặt, IAM đủ quyền, nhưng policy trên endpoint từ chối request. Cách sửa là mở rộng endpoint policy để cho phép các action S3 cần thiết trên đúng bucket mà Glue job đang đọc.

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

A — Sửa security group của VPC endpoint để cho phép outbound tới S3. Đây là phương án gần đúng nhất về mặt "cũng là cấu hình mạng", nhưng nó nhầm loại endpoint. S3 truy cập từ VPC theo kiểu cổ điển dùng gateway endpoint, và gateway endpoint không có security group — nó hoạt động bằng cách chèn route vào route table, không phải bằng ENI trong subnet. Không có "security group của endpoint" để sửa theo cách đề mô tả. Ngoài ra, cách diễn đạt "outbound tới S3 service" cũng đặt sai chỗ: nếu có chuyện security group thì nó phải nằm ở phía tài nguyên gọi đi, không phải ở gateway endpoint.

B — Đảm bảo S3 VPC endpoint được gắn đúng với subnet mà Glue job dùng. Về nguyên tắc thì việc endpoint phải phủ đúng đường đi của Glue job là điều kiện cần — nếu route table của subnet không có prefix list trỏ vào gateway endpoint thì traffic đi lối khác và hỏng. Nhưng phương án này hỏng ở chỗ không khớp với thông điệp lỗi: đề nói lỗi chỉ vào cấu hình endpoint, tức endpoint đã tồn tại và đã nằm đúng đường đi rồi. Nếu endpoint hoàn toàn không được liên kết, triệu chứng thường là timeout khi kết nối chứ không phải một thông báo trỏ vào cấu hình endpoint. Đây là phương án đúng về kỹ thuật nhưng sai về tình huống mà đề đưa ra.

C — Sửa IAM role của Glue job để thêm quyền S3. Bị loại thẳng bởi chính câu đề: "the IAM role ... correctly configured". Khi đề đã chốt một dữ kiện, thí sinh không được phép nghi ngờ nó. Về bản chất, đây cũng là một lớp kiểm soát khác — IAM là quyền của principal, còn endpoint policy là quyền gắn trên tài nguyên mạng. Sửa IAM không đụng gì tới lỗi phát ra từ endpoint.

📌 Điểm cần nhớ

• Truy cập S3 qua VPC endpoint phải vượt qua nhiều lớp cùng lúc: IAM policy của principal, bucket policy, và endpoint policy. Chỉ cần một lớp từ chối là hỏng — nên "IAM đã đúng" không đồng nghĩa với "được phép".
• Gateway endpoint (S3, DynamoDB) không có security group và không có ENI; nó điều khiển bằng route table và endpoint policy. Phương án nào nói tới security group của gateway endpoint thì gần như chắc chắn sai.
• Đọc kỹ những gì đề đã tuyên bố là đúng. Câu chữ kiểu "IAM role được cấu hình đúng" là công cụ loại trừ do người ra đề đặt sẵn, không phải chi tiết thừa.
• Phân biệt "endpoint không tồn tại/không nằm trên đường đi" với "endpoint có nhưng policy chặn". Triệu chứng khác nhau: cái trước thường là mất kết nối/timeout, cái sau là bị từ chối truy cập dù đường mạng thông.

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

Đề mô tả một công ty làm ứng dụng di động cần nơi lưu user profiles và app settings, rồi hỏi dịch vụ AWS nào phù hợp nhất để lưu và đọc dữ liệu hồ sơ người dùng.

Bốn cụm từ trong đề quyết định đáp án, và phải đọc chúng cùng lúc chứ không tách rời:

• "key-value pairs" — cấu trúc dữ liệu là cặp khoá – giá trị, không phải bảng quan hệ nhiều mối nối.
• "fast, millisecond response times for read and write" — độ trễ mili giây cho cả đọc lẫn ghi, chứ không chỉ đọc.
• "regardless of traffic spikes" — phải giữ được độ trễ đó khi lưu lượng tăng vọt, tức là cần khả năng co giãn mà không phải đổi cỡ máy chủ bằng tay.
• "fully managed to minimize maintenance overhead" — loại bỏ mọi phương án đòi người vận hành tự lo cụm, tự vá, tự sizing.

Ràng buộc phân biệt mạnh nhất ở đây là "key-value" đi kèm "ghi mili giây khi có traffic spike". Chỉ cần một trong bốn tiêu chí trên là vài phương án còn sống sót; ghép đủ bốn thì chỉ còn một dịch vụ.

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

A — Amazon DynamoDB. DynamoDB là dịch vụ NoSQL fully managed với mô hình dữ liệu key-value (và document), tức là khớp trực tiếp với "user profiles và app settings" — mỗi user một item, tra bằng partition key.

Đặc tính nó cung cấp đúng những gì đề đòi:

• Độ trễ ở mức mili giây một chữ số cho cả GetItem lẫn PutItem, và giữ được mức đó khi kích thước bảng lớn dần, vì truy cập theo khoá không phụ thuộc số lượng item trong bảng.
• Co giãn theo lưu lượng: on-demand capacity mode hấp thụ traffic spike mà người vận hành không phải làm gì; provisioned mode thì có auto scaling.
• Fully managed thật sự — không có instance để vá, không có storage để mở rộng bằng tay, không có replica để tự dựng.

Ba yếu tố đó cộng lại chính là ba câu trong phần giải thích gốc: mô hình key-value, hiệu năng nhanh và dự đoán được ở tốc độ request cao, và chi phí bảo trì tối thiểu.

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

B — Amazon RDS với provisioned IOPS. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì provisioned IOPS đúng là để tăng hiệu năng I/O. Chỗ hỏng nằm ở sự lệch mô hình: RDS là cơ sở dữ liệu quan hệ, sinh ra cho workload giao dịch có schema và join, còn dữ liệu ở đây chỉ là cặp key-value. Dùng RDS cho nó là trả tiền cho một engine quan hệ mà không dùng đến thứ gì làm nên giá trị của nó. Nặng hơn, RDS co giãn theo hướng đổi cỡ instance — gặp traffic spike thì phải scale up hoặc thêm read replica, thao tác này không tức thời và không tự động theo cách on-demand của DynamoDB. Nó cũng chỉ "managed" chứ không "serverless": vẫn còn instance class, storage, patch window để cân nhắc.

C — Amazon S3 kèm S3 Select. S3 là object storage, đơn vị làm việc là cả object chứ không phải một trường trong hồ sơ. Muốn sửa một app setting thì phải đọc object về, sửa, rồi ghi đè toàn bộ — không có ghi tại chỗ. Độ trễ mỗi request của S3 ở tầng khác hẳn so với một key-value store phục vụ ứng dụng di động, nên yêu cầu "millisecond cho cả read và write" không đạt. S3 Select chỉ giúp lọc bớt dữ liệu trả về từ trong một object (giảm băng thông), nó không biến S3 thành cơ sở dữ liệu truy cập theo khoá và cũng không giúp gì cho phía ghi.

D — Amazon ElastiCache. Phương án này thoả tiêu chí "nhanh" tốt nhất — dữ liệu nằm trong bộ nhớ nên rất nhanh — nên rất dễ chọn nếu chỉ đọc lướt chữ "millisecond". Nhưng ElastiCache về bản chất là caching layer đặt trước một datastore khác, không phải nơi lưu trữ chính (system of record). Dùng nó làm kho duy nhất cho user profiles nghĩa là chấp nhận rủi ro mất dữ liệu và thiếu độ bền cùng khả năng truy vấn mà một database cung cấp. Đề đang hỏi "database solution" để lưu hồ sơ, không hỏi lớp tăng tốc — đó là chỗ phương án này lệch.

📌 Điểm cần nhớ

• Đề nêu "key-value" + "millisecond" + "fully managed" + chịu được traffic spike thì đó gần như là chữ ký của DynamoDB; nhận ra tổ hợp này là trả lời được trong vài giây.
• RDS xuất hiện là để dụ người đọc thấy chữ "high performance". Hỏi lại: dữ liệu có quan hệ và có join không? Nếu không, engine quan hệ là chọn sai công cụ, dù có tăng IOPS bao nhiêu.
• Phân biệt "kho lưu trữ chính" với "lớp cache". ElastiCache nhanh nhưng nằm trước một database; đề hỏi "database solution" thì cache không thay thế được.
• S3 Select không biến S3 thành key-value store. Nó chỉ lọc dữ liệu trong một object; ghi vẫn là ghi đè cả object, nên mọi kịch bản cập nhật từng trường đều loại S3 ra.
• Khi nhiều phương án cùng "nhanh", hãy chọn theo tiêu chí bị bỏ sót: khả năng ghi, độ bền, hay mức managed — đó thường là chỗ ba phương án sai cùng gãy.

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

Một công ty sản xuất video lưu các file video dung lượng lớn trên Amazon S3, ở storage class S3 Standard. Sau giai đoạn dựng ban đầu, các file này ít được truy cập, nhưng vẫn cần sẵn sàng dùng lại về sau. Câu hỏi yêu cầu chọn S3 Lifecycle policy tối ưu chi phí lưu trữ.

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

• "infrequently accessed" — dữ liệu nguội, nên không đáng nằm mãi ở S3 Standard.
• "need to be readily available" / "remain accessible with minimal retrieval time when needed" — đây mới là ràng buộc phân biệt. Minimal retrieval time loại thẳng mọi tier archive: các lớp S3 Glacier và Glacier Deep Archive yêu cầu thao tác restore trước khi đọc được object, tức là có độ trễ lấy dữ liệu chứ không đọc tức thì như các lớp truy cập trực tiếp.

Vậy bài toán rút gọn thành: chọn lớp lưu trữ rẻ hơn Standard nhưng vẫn truy cập tức thì, và không đẩy dữ liệu xuống archive.

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

Đáp án đúng theo tệp là C — chuyển sang S3 Standard-Infrequent Access (S3 Standard-IA) sau 90 ngày, và giữ nguyên ở lớp đó về sau.

S3 Standard-IA được thiết kế đúng cho mô hình "lưu lâu, đọc thưa, nhưng khi đọc thì phải có ngay": giá lưu trữ mỗi GB thấp hơn S3 Standard, đổi lại có phí truy xuất theo dung lượng — hợp lý khi tần suất đọc thấp như tình huống này. Quan trọng nhất, Standard-IA là lớp truy cập tức thì, object đọc được thẳng bằng GetObject, không cần restore, nên thỏa mãn yêu cầu minimal retrieval time.

Việc giữ nguyên ở Standard-IA mãi về sau cũng là phần cố ý của đáp án: đề không hề nói dữ liệu sẽ hết giá trị hay chuyển sang chế độ lưu trữ dài hạn: nó nói các file "need to be readily available for future use", không giới hạn thời điểm. Mọi transition tiếp theo xuống archive sẽ phá vỡ chính yêu cầu đó. Standard-IA lưu dữ liệu ở nhiều Availability Zone, nên vẫn giữ độ bền và khả năng chịu lỗi tương đương Standard — phù hợp với tài sản gốc là các file video sản xuất, thứ không dựng lại được nếu mất.

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

A — Intelligent-Tiering sau 30 ngày, rồi Glacier sau 1 năm. Đây là phương án gần đúng nhất và đáng cân nhắc: S3 Intelligent-Tiering tự động dịch chuyển object giữa các access tier theo mẫu truy cập thực tế, rất hợp với dữ liệu có tần suất đọc khó đoán. Chỗ hỏng nằm ở vế sau: chuyển sang S3 Glacier sau 1 năm biến dữ liệu thành archive, phải restore mới đọc được. Đề đã nói rõ file phải sẵn sàng dùng lại với thời gian lấy tối thiểu, nên bước transition này mâu thuẫn trực tiếp với yêu cầu. Một chính sách đúng ở nửa đầu mà sai ở nửa sau thì vẫn là chính sách sai.

B — One Zone-IA sau 60 ngày, rồi Glacier Deep Archive sau 6 tháng. Hỏng ở cả hai bước. S3 One Zone-IA chỉ lưu dữ liệu trong một Availability Zone — rẻ hơn Standard-IA nhưng đánh đổi bằng khả năng phục hồi và tính sẵn sàng thấp hơn; nó chỉ hợp với dữ liệu tái tạo được, không hợp với video gốc của công ty sản xuất. Bước thứ hai còn tệ hơn: Glacier Deep Archive là lớp lạnh nhất, thời gian lấy dữ liệu dài nhất trong nhóm, mà lại áp dụng chỉ sau 6 tháng — trái hẳn yêu cầu truy cập nhanh.

D — Glacier sau 30 ngày, rồi Glacier Deep Archive sau 1 năm. Đây là phương án rẻ nhất về chi phí lưu trữ và cũng là phương án sai rõ nhất về mặt yêu cầu. Cả hai chặng đều là archive: dữ liệu phải qua bước restore mới đọc được, và thời gian chờ ở Deep Archive còn dài hơn nữa. Chính sách này phục vụ nhu cầu lưu trữ dài hạn để tuân thủ/backup, không phục vụ nhu cầu "sẵn sàng dùng lại bất cứ lúc nào" mà đề nêu. Chuyển sau đúng 30 ngày còn quá sớm so với mô tả "sau giai đoạn dựng ban đầu".

📌 Điểm cần nhớ

• Trong mọi câu hỏi về S3 Lifecycle, hãy tách đề thành hai tín hiệu: tần suất truy cập (quyết định có rời Standard hay không) và thời gian lấy dữ liệu chấp nhận được (quyết định được phép xuống tới đâu). Tín hiệu thứ hai thường là thứ loại bớt phương án.
• Cụm "readily available", "immediate access", "minimal retrieval time", "millisecond access" là dấu hiệu loại toàn bộ S3 Glacier và S3 Glacier Deep Archive — các lớp này cần restore trước khi đọc.
• Đọc toàn bộ chuỗi transition, không dừng ở bước đầu. Một chính sách bắt đầu đúng (Intelligent-Tiering, Standard-IA) vẫn sai nếu bước sau đẩy dữ liệu xuống archive trong khi đề đòi truy cập nhanh.
• Chỉ chọn S3 One Zone-IA khi đề nói rõ dữ liệu tái tạo lại được hoặc chấp nhận độ bền/sẵn sàng thấp hơn; dữ liệu gốc không sao chép được thì dùng S3 Standard-IA để giữ phân bố trên nhiều Availability Zone.
• "Giữ nguyên ở một lớp, không transition tiếp" là một đáp án hợp lệ — đề không nhắc tới nhu cầu lưu trữ dài hạn thì đừng tự thêm bước archive vào.

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

Một tập đoàn đa quốc gia muốn gom (aggregate), phân tích (analyze) và trực quan hoá (visualize) log đến từ nhiều dịch vụ AWS và cả tài nguyên on-premises, phục vụ mục đích business intelligence — báo cáo và ra quyết định.

Cụm từ quyết định đáp án nằm ở cuối đề: "building interactive visualizations for reporting and decision-making". Đây là một câu hỏi ghép bộ ba: đề yêu cầu đúng ba vai trò — gom log, truy vấn phân tích, và vẽ báo cáo tương tác — nên phương án đúng phải có cả ba dịch vụ đều đúng vai. Chỉ cần một mắt xích được gán sai chức năng (ví dụ lấy một dịch vụ lưu trữ hay một dịch vụ compute để làm "visualization") thì cả phương án hỏng, dù hai mắt xích còn lại hợp lý.

Thêm một ràng buộc phụ đáng chú ý: "logs from various AWS services and on-premises resources" — dịch vụ gom log phải nhận được log từ cả hai phía, không chỉ từ bên trong AWS.

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

Đáp án đúng là B: CloudWatch → Athena → QuickSight.

• Amazon CloudWatch đóng vai điểm gom log: các dịch vụ AWS gửi log vào CloudWatch Logs một cách tự nhiên, còn máy chủ on-premises gửi được thông qua CloudWatch agent. Đúng với yêu cầu "gom log từ cả AWS lẫn on-premises".
• Amazon Athena đóng vai phân tích: truy vấn dữ liệu log bằng SQL, chạy serverless nên không phải dựng và vận hành hạ tầng để soi khối lượng log lớn. Đây chính là lý do Athena hợp hơn các lựa chọn cần cụm máy hoặc cần nạp dữ liệu vào một database trước.
• Amazon QuickSight đóng vai trực quan hoá: đây là dịch vụ BI của AWS, dựng dashboard và biểu đồ tương tác. QuickSight kết nối trực tiếp Athena làm nguồn dữ liệu, nên kết quả truy vấn ra thẳng báo cáo mà không cần lớp trung gian tự viết.

Ba mảnh ghép khớp đúng ba vế của đề, và mảnh cuối — QuickSight — là dịch vụ duy nhất trong toàn bộ danh sách phương án thực sự làm nhiệm vụ visualization.

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

A — CloudTrail / EMR / S3. Hỏng ở cả hai đầu. CloudTrail ghi lại hoạt động trên tài khoản AWS phục vụ mục đích audit, chứ không phải công cụ gom log chung cho BI — nó không nhận log ứng dụng hay log của máy on-premises. EMR thì phân tích được dữ liệu lớn, nhưng là một cụm big data nặng nề hơn mức bài toán soi log này cần. Nặng nhất là S3: đó là dịch vụ lưu trữ, hoàn toàn không có khả năng visualization nào. Vế thứ ba sai trắng.

C — Kinesis Data Firehose / RDS / EC2. Đây là phương án gần đúng nhất ở vế đầu: Firehose thật sự có nhận và chuyển tiếp dữ liệu, nhưng nó là đường ống nạp dữ liệu streaming thời gian thực chứ không phải nơi gom và giữ log để phân tích trong ngữ cảnh này. Vế hai, RDS là cơ sở dữ liệu quan hệ cho workload giao dịch — không phải lựa chọn tối ưu để phân tích khối log lớn, và còn phải nạp dữ liệu vào trước mới truy vấn được. Vế ba sai rõ như phương án A: EC2 chỉ cung cấp năng lực tính toán, muốn có dashboard thì phải tự cài và tự vận hành phần mềm BI — đề không hỏi cách tự dựng.

D — Glue / Redshift / Lambda. AWS Glue là dịch vụ ETL, dùng để biến đổi và lập catalog dữ liệu, không phải nơi gom log. Redshift là data warehouse mạnh và phân tích được thật, nhưng phức tạp và tốn tài nguyên hơn mức cần thiết cho việc phân tích log ở đây — Athena serverless phù hợp hơn. Và Lambda là compute serverless chạy code theo sự kiện, không phải dịch vụ trực quan hoá. Lại đúng cái bẫy quen thuộc: vế visualization bị gán cho một dịch vụ không hề làm việc đó.

📌 Điểm cần nhớ

• Khi đề yêu cầu interactive visualization / BI dashboard trên AWS, câu trả lời gần như luôn là QuickSight. Phương án nào đặt S3, EC2 hay Lambda vào vị trí "visualization" thì loại được ngay mà không cần đọc hai vế còn lại.
• Câu hỏi dạng ghép bộ ba dịch vụ: chấm theo nguyên tắc "một mắt xích sai là cả phương án sai". Chiến thuật nhanh nhất là soi vế dễ phán nhất (thường là visualization) để gạch bớt, rồi mới cân nhắc phần còn lại.
• Bộ ba kinh điển cho phân tích log trên AWS: CloudWatch gom → Athena truy vấn SQL serverless → QuickSight vẽ. Athena được chọn thay vì Redshift/EMR khi đề nhấn vào sự đơn giản, không quản lý hạ tầng.
• Phân biệt vai trò để không lẫn: CloudTrail = audit hoạt động tài khoản, Glue = ETL và catalog, Firehose = đường ống nạp dữ liệu streaming, Redshift/EMR = phân tích nặng có hạ tầng. Chúng đều là dịch vụ dữ liệu hợp lệ, nhưng bị đặt sai vai trong câu này.

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

Đề mô tả một tổ chức tài chính lớn cần chuyển vài terabyte dữ liệu tài chính quan trọng từ data center on-premises lên AWS để phân tích và lưu trữ dài hạn. Yêu cầu đặt ra ba điều kiện: secure, consistent, và minimal impact on the institution's existing network bandwidth.

Cụm từ quyết định đáp án ở đây là "consistent" đi kèm "minimal impact on existing network bandwidth". Hai chữ này loại bỏ mọi phương án đi qua public internet: bất cứ thứ gì chạy trên đường internet sẵn có đều ăn vào chính băng thông mà tổ chức đang dùng cho công việc hằng ngày, và chất lượng đường truyền phụ thuộc vào các chặng mạng công cộng nên không "consistent" được. Câu hỏi hỏi "Which AWS service" — tức là chọn một dịch vụ kết nối, không phải thiết kế kiến trúc.

Lưu ý thêm: đề nói dữ liệu dùng cho analysis and long-term storage, hàm ý đây không phải một cú chuyển một lần rồi thôi mà là đường dẫn dữ liệu cần dùng lâu dài.

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

Đáp án đúng là B — Implement AWS Direct Connect for a dedicated network connection to AWS.

Direct Connect dựng một đường kết nối mạng riêng (dedicated) giữa data center on-premises và AWS, không đi qua public internet. Điều này đáp ứng cả ba ràng buộc trong đề cùng lúc:

• Secure: lưu lượng chạy trên đường truyền riêng thay vì băng qua internet công cộng, giảm hẳn bề mặt phơi ra bên ngoài — rất hợp với dữ liệu tài chính nhạy cảm.
• Consistent: vì không dùng chung hạ tầng internet công cộng nên trải nghiệm mạng ổn định và dự đoán được hơn nhiều — đúng nghĩa "consistent network experience" mà đề đòi.
• Minimal impact on existing bandwidth: đường Direct Connect là dung lượng riêng, tách khỏi đường internet mà tổ chức đang dùng, nên việc đẩy vài terabyte không bóp nghẹt hoạt động thường ngày. Đồng thời nó tăng throughput và thường giảm chi phí truyền dữ liệu ra ngoài.

Với khối lượng vài terabyte cần chuyển đều đặn và tiếp tục phục vụ phân tích về sau, đây là lựa chọn phù hợp nhất trong danh sách.

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

A — Amazon S3 Transfer Acceleration. Đây là phương án nghe hợp lý nhất trong ba cái sai, vì nó đúng là làm việc upload nhanh hơn và an toàn hơn khi client ở xa bucket S3, nhờ đi vào edge location của CloudFront rồi chạy tiếp trên đường trục AWS. Nhưng nó vẫn khởi đầu bằng public internet: chặng từ data center ra tới edge location vẫn ăn vào chính băng thông internet hiện có của tổ chức. Nó tăng tốc chứ không cấp băng thông riêng và không mang lại độ ổn định như một dedicated connection. Đúng phần "nhanh", trượt cả phần "consistent" lẫn phần "minimal impact on existing bandwidth".

C — VPN connection over the internet. Phương án này giải quyết được vế secure — đường hầm VPN mã hoá dữ liệu trên đường đi. Nhưng nó hỏng đúng ở hai vế còn lại: VPN chạy trên chính đường internet công cộng của tổ chức, nên vừa tiêu thụ băng thông đang có, vừa chịu mọi biến động độ trễ và thông lượng của internet. Với vài terabyte, đây không phải cách hiệu quả về băng thông. Đừng nhầm "được mã hoá" với "có đường riêng" — hai chuyện khác nhau.

D — AWS Snowball. Đây cũng là một lựa chọn thật sự dành cho di chuyển dữ liệu lớn, và nó thậm chí không đụng gì tới băng thông mạng. Nhưng nó dựa vào vận chuyển thiết bị vật lý: đóng gói, gửi đi, chờ AWS nhận và nạp lên. Cách làm đó là một đợt chuyển rời rạc, không phải một kênh truyền liên tục và ổn định như đề mô tả — mà đề còn nói rõ dữ liệu dùng cho phân tích và lưu trữ dài hạn. Theo cách chấm của câu này, Snowball không phù hợp với yêu cầu về quá trình truyền dữ liệu liên tục, nhất quán.

📌 Điểm cần nhớ

• Từ khoá "dedicated", "consistent" và "không ảnh hưởng băng thông internet hiện có" trong đề gần như luôn trỏ về AWS Direct Connect.
• Mã hoá ≠ băng thông riêng. VPN bảo mật dữ liệu nhưng vẫn chạy trên public internet, nên không giải được bài toán băng thông và độ ổn định.
• S3 Transfer Acceleration tối ưu tốc độ, không cấp dung lượng riêng — nó vẫn xuất phát từ đường internet của bạn.
• Snowball hợp với đợt chuyển một lần, offline; khi đề nhấn vào tính liên tục và nhất quán của luồng dữ liệu thì đường mạng riêng mới là câu trả lời.

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

Đề mô tả một data engineer cần lên lịch chạy AWS Glue ETL job hằng ngày, và đặt ra đúng hai điều kiện:

• "the exact timing of job execution is not critical" / "without a specific requirement on job completion times" — job xong lúc nào cũng được.
• "minimize the operational costs" — mục tiêu chính là giảm chi phí chạy job.

Cụm quyết định là "timing is not critical". Đây chính là điều kiện đánh đổi mà AWS Glue đòi hỏi khi cho bạn dùng giá rẻ hơn: bạn chấp nhận job có thể khởi động chậm hoặc chạy lâu hơn, đổi lại được chạy trên phần dung lượng dư (spare/spot capacity) của AWS. Đề cố tình nhấn mạnh điều kiện này hai lần — đó là dấu hiệu rằng đáp án phải là một tính năng trực tiếp làm rẻ tài nguyên tính toán, chứ không phải một mẹo lập lịch hay một tính năng tối ưu khác của Glue.

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

A — Choose the 'FLEX' execution class.

AWS Glue cho phép chọn execution class cho job. Ngoài lớp tiêu chuẩn, có lớp FLEX được thiết kế đúng cho các workload không nhạy cảm về thời gian: job chạy trên dung lượng dư thừa (spot capacity) của AWS, nhờ đó chi phí thấp hơn so với chạy trên tài nguyên on-demand.

Cái giá phải trả là job có thể bắt đầu trễ, hoặc thời gian chạy dao động, vì tài nguyên có thể bị thu hồi và cấp lại. Với ETL hằng ngày mà đề nói rõ "exact timing is not critical", đánh đổi này hoàn toàn chấp nhận được — và đó là lý do FLEX khớp chính xác với ràng buộc trong đề. Đây là thiết lập duy nhất trong danh sách thực sự thay đổi giá của tài nguyên tính toán.

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

B — Apply a 'Job Delay' to schedule execution during non-peak hours.

Phương án này gần đúng về mặt trực giác: "chạy giờ thấp điểm cho rẻ" nghe hợp lý với người quen mô hình tính tiền theo giờ cao điểm. Nhưng nó hỏng ở hai chỗ. Thứ nhất, AWS Glue không có thuộc tính job nào tên "Job Delay" — đây là tên bịa. Thứ hai, và quan trọng hơn về mặt nguyên lý: giá tài nguyên Glue không phụ thuộc vào việc bạn chạy lúc mấy giờ, nên dời job sang đêm cũng không làm hoá đơn giảm. Nó chỉ là mẹo lập lịch, không phải cơ chế giảm giá do dịch vụ cung cấp.

C — Enable job bookmarking để xử lý dữ liệu tăng dần.

Đây là phương án gây nhiễu mạnh nhất, vì job bookmarking là tính năng có thật và đúng là giúp tiết kiệm. Bookmark lưu lại trạng thái dữ liệu đã xử lý ở lần chạy trước, nên lần chạy sau chỉ đụng tới dữ liệu mới hoặc dữ liệu thay đổi — job làm ít việc hơn, chạy ngắn hơn.

Nhưng nó hỏng ở chỗ không khớp với ràng buộc mà đề nêu ra. Bookmarking giảm khối lượng dữ liệu phải xử lý, chứ không làm rẻ đơn giá tài nguyên tính toán. Và đặc biệt: bookmarking chẳng liên quan gì tới việc "thời điểm hoàn thành job không quan trọng" — bạn bật nó dù job có gấp hay không. Cụm từ then chốt trong đề bị bỏ phí hoàn toàn nếu chọn C. Đề đang hỏi cấu hình nào khai thác được sự linh hoạt về thời gian, và bookmarking không phải câu trả lời đó.

D — Set 'Job Timeout' dài hơn.

Job timeout là ngưỡng an toàn: quá thời gian đó, Glue chấm dứt job. Vai trò của nó là chặn job treo chạy vô tận và đốt tiền, tức là nó liên quan tới chi phí theo hướng ngược lại. Đặt timeout dài hơn không hề làm tài nguyên rẻ đi — nó chỉ cho phép job chạy lâu hơn trước khi bị cắt, và nếu có tác dụng gì lên hoá đơn thì là làm tăng chứ không giảm. Đây không phải một cơ chế tối ưu chi phí.

📌 Điểm cần nhớ

• "Timing is not critical" + "minimize cost" trong đề AWS Glue là tín hiệu gần như chắc chắn trỏ tới FLEX execution class. Cặp từ khoá này gắn liền với nhau: FLEX đổi tính chắc chắn về thời gian lấy chi phí thấp hơn nhờ dùng spare capacity.
• Phân biệt "giảm lượng việc" với "giảm đơn giá tài nguyên". Job bookmarking thuộc nhóm đầu (xử lý ít dữ liệu hơn), FLEX thuộc nhóm sau (chạy cùng khối lượng việc trên tài nguyên rẻ hơn). Đề hỏi nhóm nào thì phải bám vào ràng buộc mà đề nêu.
• Job Timeout là cơ chế phòng vệ, không phải cơ chế tối ưu chi phí. Kéo dài timeout không bao giờ là câu trả lời cho câu hỏi "làm sao rẻ hơn".
• Cảnh giác với tên thuộc tính nghe hợp lý nhưng không tồn tại. "Job Delay" là dạng mồi nhử phổ biến: mô tả một hành vi nghe có lý (chạy giờ thấp điểm) rồi gán cho nó một cái tên giả trong danh sách thuộc tính của dịch vụ. Với Glue, hãy nhớ các thuộc tính job có thật như execution class, job bookmark, timeout, worker type.

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

Đề bài cần chạy một dãy Athena query nối tiếp nhau, theo lịch hằng ngày, với ba ràng buộc chồng lên nhau:

1. "typically take more than 15 minutes each" — đây là cụm từ then chốt. Con số 15 phút không phải ngẫu nhiên: nó chính là trần thời gian chạy tối đa của một lần gọi AWS Lambda. Đề cố tình nêu ra để loại bỏ mọi phương án dựa vào một Lambda invocation vừa khởi động vừa chờ query xong.
2. "each query is initiated only after the preceding one completes" — cần trạng thái và tuần tự, tức phải có nơi nào đó theo dõi query trước đã xong hay chưa (poll get_query_execution) rồi mới bắn query kế tiếp.
3. "minimize costs" / "most cost-effective" — loại những cách phải trả tiền cho hạ tầng chạy thường trực hoặc cụm được cấp phát sẵn, dù về mặt kỹ thuật chúng làm được việc.

Chú ý thêm: Athena start_query_execution là lời gọi bất đồng bộ — nó trả về ngay một QueryExecutionId, query vẫn chạy tiếp ở phía Athena. Nên bản thân việc khởi động query không tốn 15 phút; cái tốn thời gian là chờ. Ai đặt phần chờ đó ở đâu chính là điều phân biệt các phương án.

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

Theo tệp, đáp án đúng là C và D.

C — AWS Step Functions + Lambda + vòng poll. Step Functions giữ state machine ở ngoài Lambda: một Lambda ngắn chỉ gọi start_query_execution rồi trả về, sau đó state machine dùng Wait + kiểm tra trạng thái để chờ, và chỉ chuyển sang query kế tiếp khi query trước đã SUCCEEDED. Việc chờ nằm ở tầng workflow chứ không nằm trong Lambda, nên trần 15 phút không còn là vấn đề — Lambda chỉ sống vài giây mỗi lần. Về chi phí, Step Functions tính theo state transition chứ không tính theo thời gian workflow ngồi chờ, nên một workflow chờ hàng giờ vẫn rẻ. Kèm theo là error handling, retry và quản lý trạng thái sẵn có, không phải tự viết.

D — AWS Glue Python shell job có vòng chờ. Đây là job serverless chạy một script Python: gọi start_query_execution, rồi lặp get_query_execution cho tới khi query xong, rồi bắn query tiếp theo. Glue Python shell không bị giới hạn 15 phút như Lambda nên chịu được query dài, và nó tính tiền theo thời lượng job thực tế với lượng tài nguyên rất nhỏ (Python shell job dùng phần DPU rất khiêm tốn), không cần cấp phát cluster hay máy chủ. Toàn bộ logic tuần tự nằm gọn trong một script, lên lịch hằng ngày được bằng chính trigger của Glue.

Điểm chung của C và D: serverless, không có gì chạy thường trực, và chỗ chờ đợi được đặt ở nơi không bị giới hạn 15 phút.

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

A — EventBridge → Lambda gọi start_query_execution. Đây là phương án gần đúng nhất và là cái bẫy chính. EventBridge lên lịch hằng ngày thì hoàn toàn ổn, và Lambda gọi được Athena. Nhưng phương án không có cơ chế nào nối các query lại với nhau: muốn "query sau chỉ chạy khi query trước xong" thì Lambda phải ngồi chờ trong chính lần invocation đó — và nó hết thời gian trước khi query xong, vì query thường dài hơn 15 phút. Kết quả: hoặc Lambda timeout, hoặc các query bị bắn ra song song không đúng thứ tự. Hỏng ở chỗ thiếu tầng theo dõi trạng thái, không phải ở chỗ chọn sai dịch vụ lên lịch.

B — Amazon MWAA với một DAG. Về mặt kỹ thuật thì đúng: Airflow có operator cho Athena, quản lý dependency và trạng thái rất tốt, và đây là công cụ orchestration đúng nghề. Nhưng MWAA là môi trường được cấp phát và chạy thường trực — bạn trả tiền cho environment kể cả lúc nó không làm gì, trong khi công việc ở đây chỉ là vài query mỗi ngày. So với "minimize costs" thì nó thua rõ C và D. Đây là kiểu phương án "đúng nhưng quá nặng": phù hợp khi bạn đã có pipeline lớn cần Airflow, không phù hợp khi chỉ nối vài query.

E — AWS Batch với job dependencies. Batch có dependsOn nên đúng là diễn đạt được thứ tự thực thi. Nhưng Batch sinh ra cho workload tính toán theo lô — nó cấp phát compute environment, chạy container để làm việc nặng. Ở đây phần việc nặng nằm hoàn toàn bên trong Athena; container của Batch chỉ ngồi gọi API rồi chờ, tức là bạn trả tiền compute cho một tiến trình chẳng tính toán gì. Vừa phức tạp hơn (phải dựng compute environment, job queue, job definition, image container) vừa không rẻ hơn C hay D.

📌 Điểm cần nhớ

• Con số "hơn 15 phút" trong đề gần như luôn là tín hiệu loại Lambda khỏi vai trò "chờ cho xong". Lambda vẫn dùng được, nhưng chỉ để khởi động việc, còn phần chờ phải đẩy sang Step Functions hoặc một runtime không bị giới hạn đó.
• start_query_execution là bất đồng bộ. Bất kỳ thiết kế nào cần thứ tự đều buộc phải có bước poll get_query_execution; phương án nào không nhắc tới việc kiểm tra trạng thái thì gần như chắc chắn không đảm bảo được tuần tự.
• Step Functions tính tiền theo bước chuyển trạng thái, không theo thời gian chờ — nên nó là lựa chọn mặc định cho orchestration serverless có chờ đợi dài.
• "Cost-effective" thường là tiêu chí loại bỏ MWAA và AWS Batch, chứ không phải loại vì chúng làm không được. Cả hai đều dựa trên hạ tầng được cấp phát; khi công việc chỉ là điều phối vài lời gọi API mỗi ngày, chúng luôn đắt và rối hơn Step Functions hay Glue Python shell.

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

Một data engineer đang duy trì các custom Python script dùng chung cho nhiều AWS Lambda function. Vấn đề hiện tại: mỗi lần sửa script là phải thủ công cập nhật lại tất cả các Lambda function — mất thời gian và dễ sai sót.

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

• "used by many AWS Lambda functions" — đây là bài toán chia sẻ code dùng chung giữa nhiều function, chứ không phải bài toán quản lý phiên bản của một function.
• "minimal manual effort" — cần một cơ chế để sửa một chỗ rồi mọi function cùng dùng, thay vì đóng gói lại từng deployment package.

Ghép hai ràng buộc đó lại, câu hỏi thực chất là: AWS Lambda có cơ chế gì để đóng gói code dùng chung và gắn vào nhiều function? Ai nhận ra vế "code dùng chung, nhiều function" thì loại được ngay các phương án nói về alias hay về nơi cất tệp.

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

D. Package the custom Python scripts into Lambda layers. Apply the Lambda layers to the Lambda functions.

Lambda layers được thiết kế đúng cho mục đích này: đóng gói thư viện, runtime dependency hoặc script dùng chung, rồi gắn (attach) vào nhiều Lambda function khác nhau. Code trong layer được Lambda giải nén vào môi trường thực thi của function và import trực tiếp như code thường — không phải tải về lúc chạy.

Khi cần sửa script, data engineer chỉ tạo một version mới của layer, sau đó các function tham chiếu tới version layer đã cập nhật. Việc quản lý tập trung tại một artifact duy nhất, không còn phải mở từng function ra sửa code, nên vừa giảm công sức thủ công vừa đảm bảo mọi function chạy cùng một bản script — đúng cả hai yêu cầu "streamlined" và "minimal manual effort" của đề.

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

A. Store a pointer to the custom Python scripts in the execution context object in a shared Amazon S3 bucket. Đây là phương án gần đúng nhất về mặt "một nơi lưu trữ chung", nhưng hỏng ở chỗ thời điểm và cách nạp code. Để script trên S3 rồi trỏ tới nó nghĩa là function phải tải script về lúc runtime, thêm độ trễ và thêm code xử lý tải/ghi tệp/ xử lý lỗi trong từng function. Execution context cũng không phải là nơi để "trỏ" tới script — nó là môi trường thực thi được Lambda tái sử dụng giữa các lần gọi, không phải cơ chế phân phối code. Ngoài ra cách diễn đạt của phương án còn lẫn lộn: pointer thì nằm trong execution context hay nằm trong S3 bucket?

B. Assign the same alias to each Lambda function. Call each Lambda function by specifying the function's alias. Alias trong Lambda là con trỏ tới một version của chính function đó, phục vụ việc chuyển traffic khi triển khai (ví dụ trỏ alias prod sang version mới). Nó hoàn toàn không có khả năng chia sẻ code giữa các function. Đặt cùng tên alias cho nhiều function chỉ khiến chúng trùng nhãn chứ không làm chúng dùng chung một bản Python script — vấn đề gốc của đề bài không hề được giải quyết.

C. Store a pointer to the custom Python scripts in environment variables in a shared Amazon S3 bucket. Dùng environment variable để lưu đường dẫn S3 nghe có vẻ gọn hơn A, nhưng dính đúng khiếm khuyết cốt lõi: script vẫn phải được tải về lúc runtime, mỗi function vẫn phải tự viết logic tải và nạp. Environment variable chỉ mang cấu hình, không mang code. Và việc sửa script trên S3 không tự động lan tới các function một cách có kiểm soát theo version như layer — không có cơ chế nào để biết function nào đang chạy bản script nào.

📌 Điểm cần nhớ

• Đề bài nhắc tới code/thư viện dùng chung cho nhiều Lambda function → phản xạ đầu tiên là Lambda layers. Đó là cơ chế AWS xây riêng cho tình huống này.
• Phân biệt rõ ba khái niệm hay bị trộn trong đề thi: layer = chia sẻ code/dependency giữa các function; version = ảnh chụp bất biến của một function; alias = con trỏ có tên trỏ tới một version, dùng để chuyển traffic khi deploy.
• Environment variable dùng để truyền cấu hình, không dùng để phân phối code. Thấy phương án nào lấy env var làm nơi trỏ tới mã nguồn thì gần như chắc là bẫy.
• Phương án bắt Lambda tải tệp từ S3 lúc runtime luôn thua phương án đóng gói sẵn khi đề nhấn mạnh giảm công sức vận hành: nó thêm độ trễ, thêm code xử lý lỗi trong từng function, và không có cơ chế phiên bản rõ ràng.

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

Bài toán: dữ liệu bán hàng lịch sử nằm ở Amazon S3 dạng Parquet, cập nhật hằng tháng; dữ liệu giao dịch đang chạy nằm trong cluster Amazon Redshift. Team muốn truy vấn cả hai cùng lúc.

Cụm từ quyết định đáp án là "without importing the S3 data into Redshift" — nhắc lại lần nữa ở câu hỏi cuối là "without data loading or transformation". Đây là ràng buộc loại thẳng mọi phương án mang tính di chuyển/nạp dữ liệu.

Cụm thứ hai cũng quan trọng không kém: "real-time transactional data in their Amazon Redshift cluster". Điểm neo của bài là Redshift — dữ liệu nóng đã ở đó rồi, và cluster đó chính là nơi người dùng ngồi truy vấn. Nên lời giải đúng phải là thứ mở rộng tầm với của Redshift ra S3, chứ không phải kéo Redshift về một engine khác.

Ghép hai ràng buộc: cần một cơ chế cho phép Redshift đọc trực tiếp file trên S3 tại chỗ, dùng SQL quen thuộc, join thẳng với bảng nội bộ.

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

C — Amazon Redshift Spectrum.

Redshift Spectrum cho phép chạy SQL trực tiếp trên dữ liệu đặt ở Amazon S3, không cần load, không cần ETL. Team khai báo external schema và external table trỏ tới thư mục Parquet trên S3, sau đó truy vấn nó từ chính cluster Redshift như một bảng bình thường.

Vì bảng external và bảng nội bộ cùng nằm trong một phiên Redshift, có thể viết một câu SQL duy nhất JOIN dữ liệu lịch sử trên S3 với dữ liệu giao dịch trong cluster — đúng cái "query both datasets simultaneously" mà đề yêu cầu. Dữ liệu lịch sử vẫn nằm nguyên trên S3, mỗi tháng nguồn cập nhật thì truy vấn tự thấy nội dung mới, không phải làm lại bước nạp.

Định dạng Parquet cũng hợp: đây là định dạng cột, Spectrum đọc được và chỉ quét những cột cần dùng thay vì đọc toàn bộ file.

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

A — AWS Glue Data Catalog. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì Spectrum thật sự dùng Data Catalog làm nơi lưu metadata cho external table. Nhưng Data Catalog chỉ là kho metadata trung tâm — nó mô tả dữ liệu ở đâu, schema ra sao, phục vụ ETL và data discovery. Bản thân nó không phải là engine truy vấn, không tự chạy được câu SQL nào, và không "combine" dữ liệu S3 với Redshift. Chọn A là nhầm phần catalog với phần thực thi truy vấn.

B — Amazon Athena Federated Query. Cũng gần đúng: Athena Federated Query đúng là cho phép một câu truy vấn chạm tới nhiều nguồn dữ liệu khác nhau. Chỗ hỏng là hướng của giải pháp. Nó lấy Athena làm trung tâm và với tay sang Redshift, trong khi đề nêu rõ dữ liệu real-time đang nằm trong cluster Redshift và đó mới là nơi làm việc. Cách này không cho sự tích hợp liền mạch với Redshift mà tình huống cần; nó thêm một engine và một lớp connector nữa vào giữa, thay vì mở rộng chính cluster sẵn có.

D — AWS Data Pipeline. Sai rõ nhất. Từ khoá consolidate đã tự mâu thuẫn với ràng buộc "without data loading or transformation" trong đề. Data Pipeline là dịch vụ xử lý và di chuyển dữ liệu giữa các dịch vụ compute và storage của AWS — nó không phải công cụ truy vấn. Dùng nó nghĩa là dựng đúng cái pipeline nạp dữ liệu mà đề bảo không được làm.

📌 Điểm cần nhớ

• Thấy cụm "without loading", "without ETL", "query in place" đi kèm dữ liệu trên S3 và một cluster Redshift sẵn có → nghĩ ngay tới Redshift Spectrum.
• Phân biệt vai trò: Glue Data Catalog = metadata, Redshift Spectrum / Athena = engine truy vấn, Data Pipeline = di chuyển dữ liệu. Catalog không tự truy vấn được gì.
• Khi hai phương án đều "truy vấn nhiều nguồn" (Spectrum vs Athena Federated Query), hãy xem đề đặt người dùng ngồi ở đâu. Dữ liệu nóng đã ở Redshift → mở rộng Redshift ra S3. Nếu điểm xuất phát là Athena và nguồn nằm rải rác nhiều nơi thì mới tới lượt Federated Query.
• Phương án nào chứa động từ kiểu consolidate, import, copy, move thì gần như chắc chắn sai khi đề đã cấm nạp dữ liệu — đọc động từ trong phương án cũng là một cách loại nhanh.