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

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

Đề mô tả một tình huống di chuyển dữ liệu bằng AWS DMS: nguồn là một Amazon RDS for Oracle DB instance nằm trong một VPC ở Region us-east-1, đích là một VPC khác ở Region us-west-1. Câu hỏi là nên đặt DMS replication instance ở đâu.

Cụm từ quyết định nằm ở đuôi câu hỏi: "for the MOST optimal performance". Cả bốn phương án đều là chỗ đặt hợp lệ về mặt kỹ thuật — DMS chạy được dù replication instance nằm gần nguồn hay gần đích. Nghĩa là đề không hỏi "cách nào chạy được", mà hỏi cách nào tối ưu nhất. Đó là lý do bốn phương án được xếp thành ma trận 2×2: (source vs target) × (cùng Region vs cùng Availability Zone). Muốn chọn đúng phải trả lời hai câu hỏi con: gần nguồn hay gần đích, và chỉ cùng Region là đủ hay phải cùng AZ.

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

Đáp án đúng theo tệp là A — Create the replication instance in the same Availability Zone and VPC as the target DB instance.

Hai vế của phương án này khớp đúng hai câu hỏi con ở trên:

• Đặt ở phía target. Khi di chuyển một Amazon RDS for Oracle database sang Region khác, khuyến nghị của AWS là tạo replication instance trong VPC của AWS Region đích. Replication instance là "server chạy phần mềm sao chép": nó kết nối tới source để rút dữ liệu, kết nối tới target để nạp dữ liệu. Đặt nó cạnh target khiến chặng ghi — chặng thường nặng hơn và nhạy cảm với độ trễ hơn, vì DMS phải tạo bảng, tạo primary key và apply thay đổi lên đích — diễn ra trong nội bộ, còn chặng đi xuyên Region chỉ là chặng đọc.
• Cùng Availability Zone chứ không chỉ cùng Region. Đây là phần "tối ưu thêm" mà giải thích gốc nói rõ: đặt trong VPC của Region đích là đủ để giải pháp chạy, nhưng để tối ưu hơn nữa thì nên đặt replication instance cùng Availability Zone và cùng VPC với target DB instance. Cùng Region mà khác AZ thì lưu lượng vẫn phải đi qua ranh giới giữa các AZ; cùng AZ thì đường đi ngắn nhất có thể.

Chỉ phương án A thoả cả hai vế, nên nó là lựa chọn "MOST optimal".

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

• B — same Region and VPC as the target DB instance. Đây là phương án gần đúng nhất, và cũng là cái bẫy chính. Nó chọn đúng phía (target) và đúng VPC, nhưng dừng lại ở mức Region. Chính giải thích gốc nói rằng cấu hình này "is sufficient to get your solution working" — tức là nó chạy được, chỉ không phải phương án tối ưu nhất. Đề dùng chữ MOST optimal, nên khi có một phương án chặt hơn (cùng AZ) thì B thua. Sai lầm ở đây là dừng ở mức "đủ dùng" khi đề hỏi mức "tốt nhất".

• C — same Availability Zone and VPC as the source DB instance. Phương án này chọn đúng mức chi tiết (cùng AZ) nhưng sai phía: nó đặt replication instance cạnh nguồn ở us-east-1 thay vì cạnh đích ở us-west-1. Đây là bẫy dành cho người đã biết "cùng AZ tốt hơn cùng Region" nhưng chưa nhớ khuyến nghị của AWS là đặt replication instance ở Region đích. Khoảng cách xuyên Region không biến mất — nó chỉ bị dời sang chặng ghi vào target, tức là chặng ta muốn giữ ngắn nhất.

• D — same Region and VPC as the source DB instance. Phương án này sai cả hai vế: vừa đặt sai phía (source thay vì target), vừa chỉ dừng ở mức Region thay vì AZ. Nó là phương án yếu nhất trong bốn cái — cũng là lựa chọn trực giác của người nghĩ "cứ đặt cạnh nơi dữ liệu xuất phát", nhưng trực giác đó ngược với hướng dẫn của AWS cho kịch bản migrate xuyên Region.

📌 Điểm cần nhớ

• Với AWS DMS migrate xuyên Region, replication instance đặt ở phía target — trong VPC của Region đích; cùng AZ với target DB instance là mức tối ưu nhất.
• Đọc kỹ chữ in hoa trong đề. MOST optimal / BEST nghĩa là nhiều phương án đều chạy được, và ta phải chọn phương án chặt nhất — chứ không phải chọn phương án đầu tiên khả thi.
• Khi các phương án khác nhau ở mức độ gần (same Region → same VPC → same Availability Zone), phương án cụ thể hơn thường thắng nếu đề hỏi về performance, vì mỗi cấp ranh giới mạng vượt qua đều thêm độ trễ.
• Nhận diện dạng ma trận 2×2: tách câu hỏi thành các trục độc lập (phía nào × mức nào), trả lời từng trục rồi mới ghép — nhanh hơn và ít bị bẫy hơn đọc lần lượt bốn phương án.

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

Một công ty tài chính muốn có một mô hình xử lý log duy nhất cho mọi loại log (system, application, database…), xử lý theo kiểu serverless, rồi lưu bền vững để phân tích về sau.

Cụm từ quyết định nằm ở câu thứ hai của đề, gần như là bản mô tả nguyên văn của dịch vụ cần chọn:

• "an AWS-managed service" — dịch vụ do AWS quản lý, không phải hạ tầng người dùng tự dựng.
• "automatically scales to match the throughput of the log data" — tự co giãn theo lưu lượng, người dùng không phải khai báo trước sức chứa.
• "requires no ongoing administration" — không có việc vận hành thường xuyên.
• "to deliver the data to persistent storage" — bản thân dịch vụ phải tự giao dữ liệu tới nơi lưu trữ, chứ không dừng lại ở việc nhận dữ liệu.
• Và câu hỏi chốt bằng "with the LEAST overhead" — khi nhiều phương án đều làm được, cái phải chọn là cái ít việc phải làm thêm nhất.

Ràng buộc thứ tư là chỗ tách bạch A với C: yêu cầu không chỉ là nhận luồng log, mà là đưa được nó xuống storage mà không phải viết thêm gì.

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

A – Amazon Kinesis Data Firehose.

Firehose sinh ra đúng để làm việc "nạp dữ liệu streaming vào data lake, data store và công cụ phân tích" một cách tin cậy. Nó nhận luồng log, có thể biến đổi dữ liệu trên đường đi, rồi tự nạp thẳng vào đích lưu trữ như Amazon S3, Amazon Redshift, Amazon Elasticsearch Service hay Splunk — nên phần "durably stored for downstream analytics" của đề được giải quyết bằng cấu hình, không bằng code.

Quan trọng hơn với chữ LEAST overhead: đây là dịch vụ fully managed, tự co giãn khớp với throughput của dữ liệu và không đòi vận hành thường xuyên. Ba vế này khớp từng chữ với ba yêu cầu đề nêu ra, nên A là đáp án.

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

C – Amazon Kinesis Data Streams. Đây là phương án gần đúng nhất và là cái bẫy chính. KDS đúng là dịch vụ streaming thời gian thực, bền vững, quy mô rất lớn — throughput mở rộng bằng cách tăng số shard trong stream, và với on-demand mode thì công suất còn co giãn theo lưu lượng. Nhưng nó hỏng ở hai chỗ so với đề: (1) ở chế độ provisioned, bạn phải tự tính và cấp đủ shard trước, tức là vẫn còn việc vận hành; (2) nghiêm trọng hơn, KDS chỉ giữ dữ liệu trong stream — muốn đưa xuống storage bền vững thì bạn phải tự viết consumer. Đề đòi dịch vụ tự "deliver the data to persistent storage", nên KDS không phải lựa chọn ít overhead nhất.

D – Amazon EMR. EMR là nền tảng big data chạy các công cụ mã nguồn mở như Apache Spark, Hive, HBase, Flink, Hudi, Presto, và nó phân tán xử lý trên một cluster EC2 co giãn được. Chính chỗ "cluster EC2" loại nó ra: có cluster là có hạ tầng bên dưới phải quản lý — chọn instance, chỉnh kích thước cluster, theo dõi. Điều đó mâu thuẫn trực tiếp với cả serverless lẫn no ongoing administration.

B – AWS Lambda. Lambda đúng là serverless, chạy code mà không cần cấp phát hay quản lý server, nên thoạt nhìn nó khớp một từ khoá trong đề. Nhưng Lambda là nơi chạy code, không phải một đường ống nạp dữ liệu: muốn có mô hình xử lý log dùng chung như đề mô tả thì bạn vẫn phải tự viết toàn bộ phần gom log, gộp lô và ghi xuống storage, cùng với việc xử lý retry. Nó không phải giải pháp phân tích log mức production đứng một mình, và lượng việc phải làm thêm rõ ràng lớn hơn A.

📌 Điểm cần nhớ

• Đề mô tả gần như nguyên văn phần giới thiệu của một dịch vụ ("fully managed", "automatically scales to match the throughput", "no ongoing administration") thì hãy đọc đó như một gợi ý trực tiếp, đừng suy luận vòng vo.
• Phân biệt Kinesis Data Streams và Kinesis Data Firehose bằng câu hỏi: đích đến có sẵn hay phải tự viết? Cần tuỳ biến xử lý theo thời gian thực và tự quản consumer → Data Streams. Chỉ cần nạp vào S3/Redshift/Elasticsearch/Splunk với ít công nhất → Firehose.
• Từ khoá LEAST overhead không hỏi "cái nào làm được", mà hỏi "cái nào ít phải viết và vận hành nhất" — nhiều phương án cùng làm được là chuyện bình thường.
• Phương án nào kéo theo một cluster (như EMR với cluster EC2) thì tự động rớt ở mọi câu có chữ serverless hoặc no administration.
• Serverless không đồng nghĩa với "ít việc nhất": Lambda là serverless nhưng vẫn bắt bạn viết và bảo trì toàn bộ logic đường ống.

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

Đề mô tả một ứng dụng chạy trên Amazon EC2, chứa thông tin cá nhân nhạy cảm, và công ty muốn dùng AWS WAF để bảo vệ. Câu hỏi yêu cầu chỉ ra phát biểu/kiến trúc đúng về khả năng của AWS WAF.

Cụm từ quyết định là "hosted on Amazon EC2" kết hợp với "leveraging the capabilities of AWS WAF". Đây không phải câu hỏi thiết kế kiến trúc tối ưu, mà là câu kiểm tra bạn có nhớ chính xác danh sách tài nguyên mà AWS WAF gắn được vào hay không. AWS WAF là dịch vụ gắn vào một điểm tiếp nhận request ở phía trước — tiêu biểu là Amazon CloudFront, Application Load Balancer và Amazon API Gateway — chứ không cài trực tiếp lên instance. Vì EC2 không nằm trong danh sách đó, phương án đúng bắt buộc phải đặt một dịch vụ được WAF hỗ trợ ở trước EC2, và phát biểu kèm theo về WAF phải không sai chỗ nào.

Bốn phương án chỉ khác nhau ở đúng điểm này: A và D là các phát biểu về phạm vi hỗ trợ của WAF, B đưa ra một kiến trúc nghe hợp lý nhưng gài một mệnh đề sai, C mô tả kiến trúc đặt CloudFront trước EC2 rồi gắn WAF lên CloudFront.

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

Đáp án đúng là C: tạo Amazon CloudFront distribution cho ứng dụng chạy trên EC2, rồi triển khai AWS WAF trên CloudFront.

Khi dùng AWS WAF cùng CloudFront, bạn bảo vệ được ứng dụng chạy trên bất kỳ HTTP web server nào — web server trên EC2, hay thậm chí web server bạn tự quản lý ngoài AWS — vì CloudFront đứng làm điểm vào và WAF lọc request tại đó. CloudFront cũng cho phép ép HTTPS cả ở chặng viewer → CloudFront lẫn chặng CloudFront → origin, phù hợp với yêu cầu bảo vệ dữ liệu cá nhân nhạy cảm.

Thêm một ưu điểm được tài liệu AWS nêu rõ: khi WAF chạy trên CloudFront, rule được thực thi tại các Edge Location trên toàn cầu, gần người dùng cuối. Request bị chặn sẽ dừng lại trước khi chạm tới web server của bạn, nên phần bảo mật không phải đánh đổi bằng hiệu năng. Đây chính là kiến trúc mà đề cần: EC2 vẫn là nơi chạy ứng dụng, còn lớp lọc tấn công web nằm ở phía trước.

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

A — "AWS WAF chỉ gắn trực tiếp được vào ALB hoặc API Gateway, rồi ghép một trong hai với EC2". Đây là phương án gần đúng nhất và cũng là bẫy chính. Phần kiến trúc thì hợp lý (đặt ALB hoặc API Gateway trước EC2 là cách làm thật), nhưng chữ "only" làm cả câu sai: nó bỏ sót CloudFront, vốn là một trong những nơi tích hợp WAF phổ biến nhất. Câu hỏi yêu cầu chọn phát biểu đúng, mà một phát biểu đúng một phần về phạm vi hỗ trợ thì vẫn là phát biểu sai.

B — "Dùng ALB cân tải cho EC2, rồi đưa CloudFront ra trước ALB vì AWS WAF không gắn trực tiếp được vào ALB". Kiến trúc mô tả (CloudFront → ALB → EC2) tự nó không có gì sai và đúng là có khả năng mở rộng, nhưng lý do đưa ra thì sai hẳn: AWS WAF gắn trực tiếp được vào Application Load Balancer. Khi chạy trên ALB, rule thực thi trong region và dùng được cho cả internet-facing lẫn internal load balancer. Mệnh đề "WAF cannot be directly configured on ALB" là kiến thức sai, nên phương án bị loại dù phần kiến trúc nghe xuôi tai.

D — "AWS WAF gắn trực tiếp được lên chính instance EC2". Sai rõ ràng nhất. AWS WAF triển khai được trên CloudFront, Application Load Balancer và API Gateway; nó không cấu hình trực tiếp lên một instance EC2. WAF không phải là agent hay phần mềm cài trong máy ảo — nó là lớp lọc gắn vào tài nguyên tiếp nhận request ở phía trước.

📌 Điểm cần nhớ

• AWS WAF gắn vào điểm vào, không gắn vào instance. Ghi nhớ bộ tài nguyên tích hợp tiêu biểu: CloudFront, Application Load Balancer, API Gateway. Thấy phương án nào nói "cài WAF thẳng lên EC2" thì loại ngay.
• Muốn bảo vệ ứng dụng trên EC2 bằng WAF thì phải đặt một dịch vụ được WAF hỗ trợ ở phía trước — CloudFront hoặc ALB — chứ không có đường tắt nào khác.
• Cảnh giác với các từ tuyệt đối như "only", "cannot". Trong dạng câu "chọn phát biểu đúng", một mệnh đề đúng-một-phần vẫn là sai; A và B đều chết vì đúng một chữ chứ không phải vì kiến trúc.
• Khác biệt CloudFront vs ALB khi chạy WAF: trên CloudFront, rule chạy tại Edge Location toàn cầu và chặn request trước khi tới origin; trên ALB, rule chạy trong region và áp được cho cả load balancer nội bộ. Đề nhấn mạnh chặn tấn công từ sớm hoặc người dùng phân tán thì nghiêng về CloudFront.

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

Đề mô tả một hệ thống high-frequency trading ghi log files vào Amazon S3, đồng thời đọc song song gần như tức thời. Nhóm data engineering lo về "data discrepancies" khi hệ thống ghi đè (overwrite) một log file đã tồn tại rồi đọc ngay chính file đó.

Cụm từ quyết định đáp án là: "overwrites an existing log file and then tries to read that specific log file" — tức là kịch bản read-after-write trên một object đã tồn tại (overwrite PUT), đọc theo đúng key chứ không phải LIST hay tìm kiếm. Và câu hỏi không hỏi "nên dùng dịch vụ nào", mà hỏi "which option BEST describes the capabilities of Amazon S3" — đây là câu kiểm tra kiến thức về consistency model của S3, không phải câu thiết kế kiến trúc.

Điểm phân biệt bốn phương án nằm ở mệnh đề "Until the change is fully propagated": ba phương án giả định vẫn còn một khoảng thời gian lan truyền (eventual consistency), chỉ khác nhau ở chỗ trong khoảng đó S3 trả về cái gì. Nhận ra mệnh đề này là giả định sai ngay từ gốc thì câu hỏi tự giải.

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

Đáp án đúng theo tệp là D — "A process replaces an existing object and immediately tries to read it. Amazon S3 always returns the latest version of the object".

Amazon S3 cung cấp strong read-after-write consistency một cách tự động: sau khi một thao tác ghi object mới hoặc ghi đè object đã có thành công, mọi request đọc tiếp theo sẽ nhận ngay phiên bản mới nhất của object. Không có "cửa sổ lan truyền" nào để mà lo.

Điều này áp dụng cho GET, PUT và cả LIST, cũng như các thao tác thay đổi object tags, ACLs hay metadata. Nghĩa là sau khi ghi, bạn liệt kê object trong bucket cũng thấy ngay thay đổi — "what you write is what you will read".

Quan trọng với kịch bản trading trong đề: tính nhất quán này không đánh đổi bằng performance hay availability, không phá vỡ regional isolation của ứng dụng, và không tính thêm phí. Vậy nên nỗi lo "data discrepancies" mà nhóm data engineering nêu ra thực chất không xảy ra — hệ thống đọc song song gần thời gian thực vẫn luôn thấy nội dung log file vừa được ghi đè.

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

Cả ba phương án còn lại đều mở đầu bằng "Until the change is fully propagated" — chúng mô tả mô hình eventual consistency, mâu thuẫn trực tiếp với strong read-after-write consistency mà S3 cung cấp. Chỉ riêng mệnh đề này đã đủ loại cả ba, không cần xét vế sau.

• A — "S3 might return the new data": đây là phương án dễ mắc bẫy nhất vì vế sau nghe có vẻ đúng — cuối cùng thì bạn cũng nhận được dữ liệu mới. Nhưng chữ "might" (có thể) mới là chỗ hỏng: nó nói rằng việc nhận dữ liệu mới chỉ là may rủi trong lúc chờ lan truyền, tức vẫn thừa nhận có cửa sổ không nhất quán. S3 bảo đảm chắc chắn, không phải "might".

• C — "S3 might return the previous data": đây là mô tả kinh điển của eventual consistency, và đúng là kịch bản mà nhóm data engineering trong đề đang sợ. Với hệ thống trading đọc song song, trả về dữ liệu cũ nghĩa là hai reader có thể thấy hai nội dung khác nhau cho cùng một key. Nhưng đây chính là thứ strong consistency đã loại bỏ, nên phương án sai.

• B — "S3 does not return any data": sai cả ở giả định eventual consistency lẫn ở hành vi mô tả. S3 không "giữ im lặng" trong lúc ghi — một object đã tồn tại thì luôn đọc được, việc ghi đè không tạo ra khoảng thời gian object biến mất hay trả về rỗng.

📌 Điểm cần nhớ

• Amazon S3 hiện có strong read-after-write consistency mặc định cho GET, PUT, LIST cũng như thao tác đổi tags/ACLs/metadata — không cần bật, không tốn thêm phí, không đánh đổi performance hay availability.
• Trong đề thi, mọi phương án chứa cụm "until the change is propagated", "eventual consistency", "might return stale/previous data" khi nói về S3 gần như chắc chắn là sai — đó là mô tả hành vi cũ, đã lỗi thời.
• Đọc kỹ trạng từ chỉ mức độ chắc chắn ("might" so với "always"): hai phương án cùng mô tả một kết quả nhưng khác nhau ở mức bảo đảm thì phương án đúng là phương án khớp với cam kết chính thức của dịch vụ.
• Consistency mạnh cho LIST cũng đáng nhớ riêng: sau khi ghi, kết quả liệt kê bucket phản ánh ngay thay đổi — điều này quan trọng cho các pipeline dữ liệu quét S3 để tìm file mới.

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

Đề mô tả một startup xử lý hợp đồng ký số tuyệt mật, đang chuyển lên AWS và cần dữ liệu được mã hoá bằng AES-256 khi lưu trên AWS. Câu hỏi muốn biết nên chọn cơ chế mã hoá nào của Amazon S3.

Cụm từ quyết định nằm ở hai câu cuối phần mô tả:

• "an encryption key that is generated as well as managed internally" — khoá mã hoá phải do chính startup sinh ra và tự quản lý, không phải do AWS sinh.
• "wants to continue using its existing encryption key generation as well as key management mechanism" — họ muốn giữ nguyên quy trình sinh và quản lý khoá đang có.

Đồng thời, họ "would like the data to be encrypted on AWS" — tức là việc mã hoá diễn ra trên phía AWS, không phải trên máy khách.

Ghép hai ràng buộc đó lại thành yêu cầu rất hẹp: khoá thuộc về khách hàng, nhưng thao tác mã hoá/giải mã do S3 làm. Chỉ đúng một phương án trong danh sách thoả cả hai vế cùng lúc.

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

A — SSE-C (Server-Side Encryption with Customer-Provided Keys)

Với SSE-C, khách hàng tự sinh và tự giữ khoá, rồi gửi kèm khoá đó trong mỗi request lên S3. Amazon S3 dùng khoá này để mã hoá object khi ghi xuống đĩa và giải mã khi đọc ra, nhưng không lưu lại khoá. Đây chính là mô hình mà đề mô tả:

• Vế "khoá sinh và quản lý nội bộ" → thoả, vì AWS không tham gia vào việc tạo khoá; startup giữ nguyên cơ chế quản lý khoá cũ của mình.
• Vế "dữ liệu được mã hoá trên AWS" → thoả, vì công đoạn mã hoá/giải mã do S3 thực hiện ở phía server (server-side).

SSE-C dùng thuật toán AES-256, khớp yêu cầu compliance trong đề.

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

B — SSE-S3: Khoá do Amazon S3 tự sinh và tự quản lý hoàn toàn; mỗi object được mã hoá bằng một khoá riêng. Khách hàng không đem khoá của mình vào được, cũng không kiểm soát vòng đời khoá. Điều này đi ngược thẳng ràng buộc "generated as well as managed internally". Ngoài ra, vì khoá nằm hoàn toàn trong tay S3, khách hàng cũng không có khả năng theo dõi việc sử dụng khoá — một điểm yếu với hồ sơ compliance.

C — Client-Side Encryption: Đây là phương án gần đúng nhất và là bẫy chính của câu này. Nó cho phép khách hàng dùng master key của riêng mình, nên vế "khoá quản lý nội bộ" thì thoả. Nhưng nó hỏng ở vế thứ hai: dữ liệu được mã hoá trước khi rời khỏi ứng dụng khách, S3 chỉ nhận vào một khối byte đã mã hoá sẵn. Đề nói rõ startup muốn dữ liệu được mã hoá trên AWS — tức là muốn AWS gánh phần việc mã hoá. Chọn client-side là bắt startup tự viết và tự vận hành thêm lớp mã hoá, đúng thứ họ đang muốn tránh.

D — SSE-KMS: Có vẻ hợp lý vì AWS KMS cho phép dùng customer-managed CMK — khoá do khách hàng tạo ra trong KMS và tự đặt chính sách. Nhưng chỗ hỏng là: khoá đó nằm trong KMS, khách hàng không bao giờ cầm được chất liệu khoá thật, và việc sinh khoá diễn ra bên trong dịch vụ của AWS chứ không phải bằng cơ chế nội bộ sẵn có của startup. Đề yêu cầu giữ nguyên cơ chế sinh và quản lý khoá đang dùng — chuyển sang KMS nghĩa là thay cơ chế đó bằng cơ chế của AWS, nên không đạt.

📌 Điểm cần nhớ

• Phân biệt ba lựa chọn SSE bằng ai giữ khoá: SSE-S3 (S3 giữ hết), SSE-KMS (KMS giữ, khách hàng chỉ điều khiển chính sách), SSE-C (khách hàng giữ, gửi kèm mỗi request).
• Đề nhắc tới "customer-provided key", "key generated and managed by us", "khoá không được nằm trong AWS" mà vẫn muốn AWS mã hoá → gần như luôn là SSE-C.
• Ranh giới giữa SSE-C và client-side encryption là nơi thao tác mã hoá xảy ra, không phải nơi giữ khoá — cả hai đều để khách hàng giữ khoá. Đọc kỹ xem đề muốn AWS làm hay ứng dụng làm.
• "Customer-managed CMK" trong KMS không đồng nghĩa với "khoá do tôi sinh ra và tôi cầm được". Với KMS, chất liệu khoá vẫn ở trong dịch vụ; nếu đề nhấn mạnh việc tự sinh khoá bằng hệ thống có sẵn thì loại KMS.

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

Phòng nhân sự có dữ liệu nhân viên nằm trên Amazon S3, ở định dạng bảng tính Microsoft Excel, với bốn cột id, name, email, phone. Họ muốn gộp bốn cột đó thành một cột duy nhất chứa cấu trúc kiểu key–value (JSON object: tên cột làm khoá, giá trị dòng làm value), và yêu cầu làm việc này với ít công sức viết code nhất (LEAST coding effort).

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

• "Microsoft Excel worksheet format" — đây là ràng buộc loại trừ mạnh nhất. Amazon Athena đọc được CSV, TSV, JSON, ORC, Avro, Parquet và các định dạng log quen thuộc, nhưng không đọc được workbook Excel. Chỉ riêng chi tiết này đã gạch bỏ cả hai phương án Athena, bất kể hàm được nêu đúng hay sai.
• Hình dạng kết quả mong muốn — ví dụ trong đề là một object có khoá "id", "name", "email", "phone". Đó là map (key–value), không phải mảng. Chi tiết này phân biệt hai transformation của DataBrew vốn nghe rất giống nhau.

Cộng thêm "LEAST coding effort" thì công cụ trực quan, thao tác bằng recipe step như AWS Glue DataBrew là hướng đi được nhắm tới.

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

Đáp án đúng theo tệp là D — dùng AWS Glue DataBrew với transformation NEST_TO_MAP.

Trong DataBrew, một recipe step là một hành động biến đổi dữ liệu thô thành dạng sẵn dùng cho data pipeline, còn function là loại recipe step đặc biệt có tham số. Bước NEST_TO_MAP nhận các cột do người dùng chọn và chuyển chúng thành các cặp key–value: khoá là tên cột, value là giá trị của dòng đó. Kết quả nằm gọn trong một cột mới — đúng hình dạng mà phòng nhân sự yêu cầu.

Cấu hình chỉ là khai báo tham số, không phải viết chương trình:

"Operation": "NEST_TO_MAP",
"Parameters": {
    "sourceColumns": "[\"id\",\"name\",\"email\",\"phone\"]",
    "targetColumn": "columnName",
    "removeSourceColumns": "true"
}

Một lưu ý từ chính tài liệu: NEST_TO_MAP không giữ thứ tự các cột đã chọn trong map kết quả. Với yêu cầu ở đây, thứ tự khoá không quan trọng nên điều đó chấp nhận được.

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

A — Athena + json_format. Hàm json_format trả về chuỗi JSON được serialize từ một giá trị JSON đầu vào. Nghe rất hợp lý vì cuối cùng ta muốn có text JSON, nhưng nó hỏng ở tầng dưới: Athena không truy vấn được dữ liệu nằm trong file định dạng Microsoft Excel workbook. Chưa kịp bàn tới hàm nào thì đã không đọc được dữ liệu. Ngoài ra, viết SQL tự ghép JSON cũng nhiều công sức hơn một recipe step trực quan.

C — Athena + json_parse. Sai ở hai tầng. Thứ nhất, giống A: Athena không đọc được Excel workbook. Thứ hai, json_parse làm việc ngược chiều với thứ đề bài cần — nó deserialize một chuỗi JSON đầu vào thành giá trị JSON, tức là dùng khi ta đã có JSON dạng text và muốn bóc ra. Ở đây ta đang đi từ các cột phẳng sang JSON, không phải từ JSON text sang giá trị.

B — DataBrew + NEST_TO_ARRAY. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi: đúng dịch vụ (DataBrew), đúng tinh thần "ít code", đúng ý tưởng gộp nhiều cột vào một cột. Nó hỏng ở hình dạng đầu ra: NEST_TO_ARRAY gộp các cột đã chọn thành một mảng giá trị, giữ nguyên thứ tự cột, và ép các kiểu dữ liệu khác nhau về một kiểu chung bao phủ được tất cả. Kết quả sẽ là danh sách giá trị trần, mất luôn tên cột làm khoá — trong khi đề bài yêu cầu rõ ràng một object có khoá "id", "name", "email", "phone". Mảng không phải JSON object nên không đáp ứng yêu cầu.

📌 Điểm cần nhớ

• Kiểm tra định dạng nguồn trước khi bàn tới hàm. Athena đọc CSV, TSV, JSON, ORC, Avro, Parquet và các log format quen thuộc, nhưng không đọc Microsoft Excel workbook. Đề nhắc "Excel" là tín hiệu loại Athena ngay, còn DataBrew thì hỗ trợ Excel như một nguồn dữ liệu.
• NEST_TO_MAP cho key–value, NEST_TO_ARRAY cho danh sách. Nhìn vào mẫu output trong đề: có tên khoá thì chọn MAP, chỉ có dãy giá trị thì chọn ARRAY. MAP không giữ thứ tự cột; ARRAY giữ thứ tự nhưng ép các cột về một kiểu chung.
• json_format và json_parse ngược chiều nhau. json_format serialize giá trị JSON thành text; json_parse deserialize text thành giá trị JSON. Đọc kỹ chiều biến đổi mà đề cần trước khi chọn.
• "LEAST coding effort" thường nghiêng về công cụ recipe/no-code. DataBrew biến đổi dữ liệu bằng các bước khai báo sẵn thay vì viết SQL hay script — khi đề nhấn mạnh ít code, đó là gợi ý mạnh, nhưng vẫn phải kiểm tra ràng buộc kỹ thuật (định dạng nguồn, hình dạng output) trước khi chốt.

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

Đề mô tả một công ty lưu dữ liệu khách hàng nhạy cảm và mang tính sống còn với hoạt động kinh doanh (business-critical) trên Amazon S3, dữ liệu được sắp xếp tách bạch để giữ độ trễ thấp. Lifecycle policy hiện tại đặt chưa tối ưu nên chi phí bị đội lên. Câu hỏi: giảm chi phí lưu trữ S3 mà tốn ít công sức của đội kỹ thuật nhất.

Có ba cụm từ quyết định, và phải thoả cả ba cùng lúc:

• "keeping the team's involvement to a minimum" — loại mọi giải pháp đòi con người phải phân loại dữ liệu, đoán tần suất truy cập rồi tự viết lại lifecycle rule. Chính việc đặt lifecycle bằng tay đang là nguyên nhân sinh ra vấn đề.
• "business-critical" — dữ liệu không được phép chấp nhận rủi ro về độ bền/khả dụng để đổi lấy giá rẻ.
• "low latency" — dữ liệu phải lấy ra được ngay, không có chuyện chờ khôi phục.

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

C — Amazon S3 Intelligent-Tiering.

Intelligent-Tiering được thiết kế đúng cho tình huống "không biết chắc dữ liệu nào được truy cập thường xuyên". S3 tự theo dõi access pattern của từng object và tự chuyển object sang access tier rẻ hơn khi nó không được chạm tới trong một khoảng thời gian liên tiếp; nếu object nằm ở tier ít truy cập bỗng được đọc lại, nó tự động quay về tier tối ưu cho truy cập thường xuyên. Đội kỹ thuật không phải ngồi phân loại hay chỉnh tay lifecycle rule nữa — đây chính là vế "minimum involvement" của đề.

Hai yêu cầu còn lại cũng khớp: chuyển tier trong Intelligent-Tiering không làm giảm hiệu năng truy cập (vẫn là truy cập tức thời, hợp với "low latency"), và các access tier tự động của nó vẫn giữ mức độ bền cùng khả dụng như dữ liệu quan trọng đòi hỏi — an toàn cho dữ liệu business-critical.

Đổi lại, có một khoản phí monitoring và automation nhỏ tính theo object, nhưng không có phí truy xuất (retrieval fee) khi đọc dữ liệu ở các access tier tự động, và không mất thêm phí mỗi lần object đổi tier. Với khối dữ liệu có pattern truy cập không đoán trước, khoản phí giám sát này rẻ hơn nhiều so với việc để tất cả nằm mãi ở tier đắt.

Lưu ý thêm: storage class đặt được ở mức object, một bucket có thể chứa lẫn lộn Standard, Intelligent-Tiering, Standard-IA và One Zone-IA. Bạn có thể upload thẳng vào Intelligent-Tiering, hoặc dùng lifecycle policy để đưa object từ Standard/Standard-IA sang Intelligent-Tiering.

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

A — S3 One Zone-Infrequent Access. Đây là phương án gần đúng nhất và cũng là bẫy chính: nó thật sự rẻ hơn Standard-IA và vẫn cho truy cập nhanh khi cần. Chỗ hỏng nằm ở độ bền chứ không nằm ở giá: các storage class khác lưu dữ liệu trên tối thiểu ba Availability Zone, còn One Zone-IA chỉ lưu trong một AZ. Mất AZ đó là mất dữ liệu. Đề nói rõ dữ liệu là business-critical, nên đây là mức rủi ro không được phép đánh đổi. Ngoài ra nó cũng không tự thích nghi — vẫn cần người quyết định object nào đưa vào.

B — S3 Glacier Deep Archive. Đúng là lựa chọn rẻ nhất về đơn giá lưu trữ, nhưng nó là archive class: first-byte latency tính bằng giờ. Đề nêu thẳng yêu cầu low latency, nên phương án này bị loại ngay bởi một ràng buộc trong đề chứ không phải bởi chi phí. Nói cách khác, nó tối ưu đúng một chiều (giá) và vi phạm chiều còn lại.

D — Amazon EFS. Sai cả về hướng giải quyết. EFS là file system NFS được quản lý, dùng chung được giữa nhiều máy — khác hẳn EBS vốn không chia sẻ được — nhưng nó đắt hơn lưu dữ liệu trên S3, nên chuyển sang EFS là đi ngược mục tiêu giảm chi phí. Thêm nữa EFS cần một EC2 instance hoặc kết nối AWS Direct Connect để mount, tức là phải dựng thêm hạ tầng và di chuyển dữ liệu — trái hẳn với yêu cầu "ít công sức nhất".

📌 Điểm cần nhớ

• Hễ đề nói access pattern không rõ / không đoán được, hoặc giảm chi phí mà ít thao tác thủ công, thì Intelligent-Tiering gần như luôn là đáp án; các class còn lại đều đòi con người tự quyết dữ liệu nào nằm đâu.
• One Zone-IA đánh đổi độ bền lấy giá. Chỉ chọn khi đề ngụ ý dữ liệu tái tạo lại được hoặc là bản sao phụ. Thấy chữ business-critical, sensitive, không được mất là loại ngay.
• Glacier / Glacier Deep Archive bị loại bởi latency, không bởi giá. Đề nhắc low latency, rapid access, tức thời là các archive class ra khỏi vòng, dù chúng rẻ nhất.
• So sánh phải theo nhiều chiều cùng lúc: chi phí, độ bền/khả dụng (một AZ hay nhiều AZ), độ trễ truy xuất, và công vận hành. Phương án rẻ nhất hiếm khi là đáp án — đáp án là phương án rẻ mà không vi phạm ràng buộc nào đề đã nêu.

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

Đề bài mô tả một công ty bán lẻ muốn kết nối mạng có mã hoá giữa data center tại chỗ (on-premises) và AWS Cloud. Có hai ràng buộc được nêu thẳng trong đề, và cả hai đều cần thiết để loại phương án:

• "get the solution up and running in the fastest possible time" — giải pháp phải dựng được nhanh nhất có thể.
• "it should also support encryption in transit" — phải mã hoá dữ liệu khi truyền.

Cụm từ quyết định là "establish encrypted network connectivity": đề hỏi về một dịch vụ thiết lập kênh kết nối mạng, chứ không phải một dịch vụ chuyển dữ liệu hay quản lý bí mật. Ba trong bốn phương án chỉ cần đọc kỹ động từ này là loại được ngay, vì chúng không phải dịch vụ kết nối mạng. Phương án còn lại là Direct Connect — đúng là dịch vụ kết nối mạng, nhưng nó vấp phải cả hai ràng buộc còn lại: không tự mã hoá, và không dựng nhanh được.

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

A — AWS Site-to-Site VPN là đáp án đúng.

Site-to-Site VPN tạo đường hầm IPsec đi qua Internet công cộng, nối mạng on-premises (hoặc chi nhánh) với Amazon VPC. IPsec là bộ giao thức bảo vệ giao tiếp IP bằng cách xác thực và mã hoá từng gói IP trong luồng dữ liệu — nghĩa là encryption in transit có sẵn ngay trong bản chất của kết nối, không cần thêm lớp nào bên trên.

Về tốc độ triển khai: vì kênh chạy trên đường Internet mà công ty đã có, việc dựng chỉ là cấu hình phía AWS và phía thiết bị customer gateway tại chỗ, không phải kéo cáp hay đặt đường truyền vật lý. Đó chính là lý do nó khớp với yêu cầu "fastest possible time" trong đề.

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

C — AWS Direct Connect (đây là phương án gần đúng nhất, và cũng là bẫy chính của câu này). Direct Connect đúng là dịch vụ thiết lập kết nối mạng: nó tạo một đường truyền mạng chuyên dụng giữa mạng của bạn và một Direct Connect location, và có thể chia thành nhiều virtual interface bằng VLAN chuẩn 802.1q. Nhưng nó hỏng ở hai chỗ so với đề:

• Bản thân Direct Connect không mã hoá lưu lượng in transit. Muốn có mã hoá thì phải dùng thêm tuỳ chọn mã hoá của dịch vụ chạy bên trên nó — tức là bản thân phương án như đề ghi ("dùng Direct Connect để thiết lập kết nối có mã hoá") là sai về mặt mô tả.
• Đây là kết nối vật lý chuyên dụng, nên không dựng được nhanh, đi ngược yêu cầu "fastest possible time".

B — AWS Secrets Manager. Đây là dịch vụ bảo vệ các secret cần để truy cập ứng dụng, dịch vụ và tài nguyên IT: lưu, xoay vòng, quản lý và lấy về thông tin đăng nhập database, API key… theo suốt vòng đời của chúng. Nó hoàn toàn không đụng gì tới tầng mạng, nên không thể dùng để thiết lập kết nối giữa on-premises và AWS.

D — AWS DataSync. DataSync là dịch vụ di chuyển dữ liệu online giữa storage on-premises và AWS: nó tự lo việc lập lịch, giám sát quá trình truyền, kiểm chứng dữ liệu và tối ưu hoá việc dùng băng thông, thay cho các script copy viết tay. Điểm cần phân biệt: DataSync chạy trên một kết nối mạng đã có sẵn — nó là bên sử dụng đường truyền, chứ không phải bên tạo ra đường truyền. Vì vậy nó không đáp ứng yêu cầu "establish network connectivity" của đề.

📌 Điểm cần nhớ

• Đọc kỹ động từ trong đề: "establish network connectivity" chỉ có Site-to-Site VPN và Direct Connect là ứng viên hợp lệ. Dịch vụ chuyển dữ liệu (DataSync) hay quản lý bí mật (Secrets Manager) không nằm ở tầng đó, dù tên nghe có vẻ liên quan tới bảo mật.
• Cặp Site-to-Site VPN vs Direct Connect là một trong những cặp so sánh hay gặp nhất. Phân biệt bằng hai tiêu chí: VPN chạy trên Internet, mã hoá sẵn bằng IPsec, dựng nhanh; Direct Connect là đường chuyên dụng, không tự mã hoá, cần thời gian chuẩn bị.
• Khi đề nhấn "fastest possible time" hoặc "quickest to set up", đó là tín hiệu loại các giải pháp cần hạ tầng vật lý.
• Một phương án có thể sai không phải vì tên dịch vụ sai, mà vì mô tả gán cho dịch vụ đó một khả năng nó không có — như trường hợp Direct Connect ở đây được mô tả là tạo kết nối "encrypted".

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

Đề mô tả một luồng dữ liệu: team đẩy dữ liệu từ Amazon Kinesis Data Firehose xuống Amazon S3. Vấn đề quan sát được là Firehose tạo ra rất nhiều file nhỏ trong bucket S3, trong khi số file kỳ vọng phải thấp hơn nhiều. Câu hỏi yêu cầu chỉ ra nguyên nhân khả dĩ nhất.

Cụm từ quyết định đáp án là "several small files ... as opposed to a much lower expected number of files" — nghĩa là mọi thứ đang chạy bình thường, không ai đổi cấu hình, chỉ có điều file bị chia nhỏ hơn và nhiều hơn so với buffering hints đã đặt. Đây chính là dấu hiệu đặc trưng của việc delivery stream đã scale: Firehose không hỏi ý người dùng khi tự mở rộng năng lực, nên người vận hành thấy hành vi ghi file thay đổi mà không hiểu vì sao.

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

A — Kinesis Data Firehose delivery stream has scaled.

Firehose tự động scale delivery stream tới một mức nhất định để giảm khả năng bị throttling, và việc scale này ảnh hưởng trực tiếp lên buffering hints. Tổng buffer size (SizeInMBs) thay đổi tỉ lệ nghịch với mức scale: capacity tăng gấp đôi thì buffer size còn một nửa, scale gấp bốn thì buffer size còn một phần tư.

Quan trọng hơn, số kênh buffer song song cũng tăng theo. Dữ liệu được delivery đồng thời từ tất cả các buffer này. Ở trạng thái bình thường, Firehose gom dữ liệu vào một buffer và tạo một file khi chạm ngưỡng buffer size. Khi scale gấp đôi, có hai kênh cùng tạo file trong cùng một khoảng thời gian; scale gấp bốn thì có bốn file. Kết quả là đúng hiện tượng đề mô tả: nhiều file, mỗi file nhỏ hơn dự kiến — dù không ai chạm vào cấu hình.

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

B — Data delivery to destination is lagging behind the data being written. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó nghe như một sự cố. Nhưng khi delivery bị tụt lại phía sau lượng dữ liệu ghi vào stream, Firehose tăng buffer size động để đuổi kịp và đảm bảo dữ liệu vẫn về được đích. Hệ quả là object trên S3 có thể lớn hơn buffer size đã khai báo, tức là ít file và file to hơn — ngược hẳn với triệu chứng trong đề.

C — Compression is disabled. Sai cả về chiều tác động. Chính khi bật compression thì Firehose mới ghi ra các record nhỏ hơn kích thước khai trong BufferingHints, vì ngưỡng buffer được tính trên dữ liệu trước khi nén còn file ghi ra là dữ liệu sau khi nén. Vậy nên "tắt compression" không thể là lý do sinh ra file nhỏ; nếu có gì thì nó làm file to hơn.

D — A single delivery stream configured to deliver to multiple S3 buckets. Sai vì tình huống này không tồn tại: một delivery stream chỉ deliver được tới đúng một bucket S3. Muốn ghi vào nhiều bucket thì phải tạo nhiều delivery stream. Ngoài ra, kể cả nếu làm được, việc ghi ra nhiều bucket cũng không giải thích được vì sao file trong một bucket lại nhỏ đi.

📌 Điểm cần nhớ

• Firehose scale ⇒ buffer nhỏ lại và nhiều kênh song song ⇒ nhiều file nhỏ trên S3. Đây là nguyên nhân kinh điển cho "small files problem" khi cấu hình không hề bị đổi.
• Buffering hints là hint, không phải bảo đảm. Firehose có thể ghi file nhỏ hơn (khi scale, khi bật compression) hoặc lớn hơn (khi delivery bị lag và Firehose tăng buffer để đuổi kịp) so với con số khai báo.
• Khi đọc đề dạng "vì sao file nhỏ / vì sao file to", hãy xác định chiều tác động của từng phương án: lag ⇒ file to hơn, compression bật ⇒ file nhỏ hơn, scale ⇒ nhiều file nhỏ hơn.
• Một delivery stream chỉ có một đích S3 — bất kỳ phương án nào giả định một stream ghi vào nhiều bucket đều là phương án bịa ra để gây nhiễu.

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

Đề mô tả một job ETL chạy hằng ngày trên dữ liệu đổ vào Amazon S3, dạng file .csv, mỗi file khoảng 100 MB. Câu hỏi chốt lại bằng: "most cost-effective solution".

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

• "around 100 MB in size" — đây là khối lượng dữ liệu nhỏ. Nó nằm gọn trong bộ nhớ của một tiến trình đơn, không cần chia nhỏ ra nhiều node để xử lý song song.
• "most cost-effective" — đề không hỏi giải pháp mạnh nhất hay dễ dùng nhất, mà hỏi giải pháp rẻ nhất trong số các lựa chọn còn chạy được việc.

Ghép hai ràng buộc lại: bài toán cần một cách chạy script biến đổi dữ liệu, không cần engine phân tán, và tính tiền càng ít càng tốt. Đây chính là chỗ phân biệt giữa AWS Glue Python shell job và các lựa chọn dựa trên Apache Spark.

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

C — Configure an AWS Glue Python shell job. Use the pre-loaded Pandas library to run transformations on the data.

AWS Glue hỗ trợ một kiểu job gọi là Python shell job: chạy script Python thuần, không phân tán, dùng cho những tác vụ nhỏ tới trung bình thường thấy trong một luồng ETL — gửi truy vấn SQL sang Amazon Redshift, Amazon Athena hay Amazon EMR, chạy phân tích khoa học hoặc machine learning.

Điểm mấu chốt về chi phí: Python shell job chạy được với 1 DPU hoặc 0,0625 DPU (tức 1/16 DPU). Chọn mức 1/16 DPU nghĩa là bạn trả tiền cho một phần rất nhỏ tài nguyên so với một job Spark, mà vẫn đủ sức xử lý file 100 MB.

Môi trường Python shell job đã nạp sẵn các thư viện như Boto3, NumPy, SciPy và Pandas. Pandas đọc và biến đổi một file CSV 100 MB hoàn toàn thoải mái trong bộ nhớ, nên không cần cài thêm gì, cũng không cần khởi động Spark runtime.

Một lợi thế nữa được nêu trong tài liệu: so với AWS Lambda vốn bị giới hạn cứng 15 phút thời gian chạy, Glue Python shell job cấu hình được timeout dài hơn nhiều và bộ nhớ lớn hơn — điều thường cần cho công việc data engineering.

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

B — Write an AWS Glue PySpark job. Use Apache Spark to transform the data.

Đây là phương án gần đúng nhất và cũng là cái bẫy chính. PySpark job hoàn toàn làm được việc ETL này về mặt kỹ thuật — không có gì sai về chức năng. Chỗ nó hỏng là ở đúng tiêu chí đề đưa ra: chi phí. Spark là engine phân tán, phải cấp phát và khởi động cluster worker, tiêu tốn số DPU lớn hơn hẳn mức 1/16 DPU của Python shell job. Với 100 MB dữ liệu, toàn bộ sức mạnh phân tán đó không được dùng tới — bạn trả tiền cho năng lực xử lý mà khối dữ liệu này không đòi hỏi. Đề hỏi "most cost-effective", nên "chạy được nhưng đắt hơn" là chạy sai đề.

D — Run the transformations on the data using AWS Glue DataBrew.

AWS Glue DataBrew là công cụ chuẩn bị dữ liệu trực quan, dành cho data analyst và data scientist làm sạch và chuẩn hoá dữ liệu để phục vụ analytics và machine learning. Nó thao tác bằng giao diện, chọn sẵn các bước biến đổi. Theo cách phân loại của tài liệu tham chiếu cho câu này, DataBrew không phải là một giải pháp ETL — nó thuộc nhóm data preparation, không phải nơi để dựng một job ETL chạy theo lịch hằng ngày.

A — Run the transformations on the data using AWS Glue Data Studio.

AWS Glue Studio là giao diện đồ hoạ để tạo, chạy và giám sát các data integration job trong AWS Glue. Bạn kéo thả để dựng luồng biến đổi dữ liệu, rồi luồng đó được chạy trên engine ETL serverless dựa trên Apache Spark của Glue. Hai vấn đề: bản thân Glue Studio là lớp giao diện chứ không phải giải pháp ETL độc lập, và thứ nó sinh ra vẫn là job Spark — nên nếu có tính tiền thì cũng rơi vào đúng nhược điểm chi phí của phương án B.

📌 Điểm cần nhớ

• Thấy đề nêu kích thước dữ liệu nhỏ (vài chục tới vài trăm MB) đi kèm yêu cầu cost-effective, hãy nghĩ tới AWS Glue Python shell job trước, đừng mặc định chọn Spark. Spark chỉ đáng tiền khi dữ liệu thực sự cần xử lý phân tán.
• Glue Python shell job chạy được ở mức 1 DPU hoặc 1/16 DPU, và nạp sẵn Boto3, NumPy, SciPy, Pandas — đây là hai chi tiết hay được hỏi trực tiếp.
• Phân biệt rõ ba cái tên dễ lẫn trong họ Glue: Glue ETL job (PySpark hoặc Python shell) là nơi chạy ETL thật; Glue Studio là giao diện đồ hoạ dựng job chạy trên Spark; Glue DataBrew là công cụ chuẩn bị dữ liệu trực quan cho analyst.
• Khi so Glue Python shell với AWS Lambda, điểm khác biệt cần nhớ là Lambda có giới hạn cứng 15 phút, còn Glue Python shell đặt được timeout dài hơn và bộ nhớ cao hơn cho tác vụ data engineering.