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

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

Đề mô tả một công ty bán lẻ dùng data lake trên Amazon S3, phân tích bằng Amazon Redshift và Amazon QuickSight. Điểm mấu chốt nằm ở sự thay đổi: nhóm vừa chuyển sang nightly refresh nạp hàng terabyte thay đổi của ngày hôm trước vào Redshift. Câu hỏi yêu cầu tìm nguyên nhân KHẢ DĨ NHẤT khiến dashboard chậm đi.

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

• "had good performance earlier" — dashboard vốn chạy tốt, chỉ chậm sau khi đổi quy trình. Bất kỳ nguyên nhân nào tồn tại sẵn từ trước đều bị loại.
• "nightly refresh utilizing terabytes of the previous day's changes" — nạp "changes" nghĩa là hàng loạt thao tác UPDATE/DELETE/INSERT, chứ không phải nạp bảng mới hoàn toàn. Trong Redshift, UPDATE và DELETE chỉ đánh dấu hàng cũ là đã xoá, để lại vùng trống và làm bảng mất thứ tự sort key.
• "degraded performance during business hours as well" — chậm cả trong giờ làm việc, tức là ngoài cửa sổ chạy refresh ban đêm. Nguyên nhân phải là thứ để lại hậu quả kéo dài, không phải thứ chỉ tranh chấp tài nguyên trong lúc nó chạy.

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

Đáp án đúng theo tệp là C — các đợt refresh hằng đêm khiến bảng dashboard cần được VACUUM, mà Redshift không tự chạy được vì tải người dùng vẫn đang diễn ra.

Redshift kế thừa thiết kế từ PostgreSQL: nó không tự động thu hồi không gian trống. Mỗi lần DELETE hoặc UPDATE, hàng cũ vẫn nằm lại trên đĩa dưới dạng hàng đã đánh dấu xoá, và hàng mới được ghi vào vùng chưa sắp xếp. Lệnh VACUUM làm hai việc: thu hồi vùng trống và sắp xếp lại hàng theo sort key. Bảng gọn và có thứ tự thì Redshift mới bỏ qua được các block không liên quan khi quét — đây chính là nguồn hiệu năng của dashboard trước kia.

Nạp hàng terabyte thay đổi mỗi đêm tạo ra lượng hàng chết và hàng chưa sắp xếp khổng lồ. Redshift có cơ chế automatic vacuum, nhưng theo tài liệu, nó tạm dừng khi cluster đang chịu tải cao. Cluster này chịu tải nặng suốt đêm (refresh) rồi lại tải nặng ban ngày (dashboard), nên automatic vacuum gần như không có cửa sổ nào để hoàn tất. Kết quả là bảng ngày càng phình và mất thứ tự — hiệu năng suy giảm dai dẳng, kể cả trong giờ làm việc, đúng với hiện tượng đề mô tả. Việc CloudWatch không báo gì cũng hợp lý: đây không phải sự cố về CPU hay dung lượng vượt ngưỡng, mà là vấn đề tổ chức dữ liệu bên trong bảng.

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

A. Redshift cluster bị undersize so với truy vấn của dashboard — Đây là distractor dựa vào phản xạ "chậm thì thêm node". Nếu cluster thiếu tài nguyên cho chính các truy vấn dashboard đó, thì nó đã thiếu từ trước khi đổi sang nightly refresh, vì bản thân dashboard và truy vấn của chúng không thay đổi. Đề nói rõ trước đây chúng chạy tốt, nên kích thước cluster không phải biến số đã đổi.

B. Dashboard chạy các câu SQL kém hiệu quả — Sai vì cùng một lý do, nhưng đáng nói kỹ hơn vì nó gần đúng: SQL kém hiệu quả thật sự là nguyên nhân phổ biến khiến Redshift chậm. Vấn đề là ở đây các câu truy vấn dashboard vẫn y nguyên như trước; thứ thay đổi là quy trình nạp dữ liệu. Một nguyên nhân không đổi thì không giải thích được một triệu chứng mới xuất hiện.

D. Refresh hằng đêm khiến truy vấn bị treo trong giờ làm việc — Đây là phương án gần đúng nhất và cũng là bẫy chính. Nó đúng ở chỗ nightly refresh là thủ phạm, nhưng sai ở cơ chế và sai ở khung thời gian. Refresh chạy bằng các bước ETL với truy vấn dài như COPY; những thao tác đó có thể chiếm tài nguyên và làm truy vấn khác chờ trong lúc chúng đang chạy, tức là ban đêm. Khi refresh kết thúc, sự tranh chấp đó cũng kết thúc — nó không thể tự nó gây treo vào giờ hành chính. Đề đã chốt "during business hours as well", nên nguyên nhân phải là di chứng để lại trên bảng, không phải tranh chấp tức thời. Phân biệt được "tranh chấp trong lúc chạy" với "hậu quả sau khi chạy" chính là chỗ câu này muốn kiểm tra.

📌 Điểm cần nhớ

• Khi đề nhấn "trước đây chạy tốt, giờ chậm", hãy tìm thứ vừa thay đổi. Mọi phương án mô tả điều kiện đã tồn tại từ trước (cluster undersize, SQL kém) đều bị loại ngay, bất kể nghe hợp lý đến đâu.
• Redshift không tự thu hồi không gian sau UPDATE/DELETE. Nạp khối lượng lớn thay đổi mà không VACUUM sẽ để lại hàng chết và hàng chưa sắp xếp, làm truy vấn phải quét nhiều block hơn.
• Automatic vacuum có thể bị tạm dừng khi cluster đang tải cao. Cluster bận cả đêm lẫn ngày thì đừng trông chờ nó tự dọn — phải chủ động lên lịch bảo trì.
• Phân biệt hai kiểu triệu chứng: tranh chấp tài nguyên chỉ đau trong khung giờ job chạy; vấn đề tổ chức dữ liệu thì đau kéo dài sau đó. Khung giờ mà đề nêu ra thường là manh mối loại trừ mạnh nhất.
• CloudWatch im lặng không có nghĩa là cluster khoẻ — các metric hạ tầng không phản ánh mức phân mảnh hay tình trạng sắp xếp bên trong bảng.

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

Đề bài mô tả một công ty cần chuyển khoảng 20 petabyte dữ liệu lưu trữ (archived digital media assets) lên AWS Cloud, và nhấn mạnh hai ràng buộc:

• "in the shortest possible time" — thời gian là tiêu chí tối ưu, không phải chi phí hay tính linh hoạt.
• "the company's archives are located at a remote location" — kho lưu trữ nằm ở một địa điểm xa, tức là đường truyền Internet tại đó không thể coi là nhanh hay đáng tin cậy.

Cụm từ quyết định đáp án là "20 petabytes" đi cùng "a remote location" (một địa điểm duy nhất, ở xa). Quy mô petabyte hai chữ số loại ngay mọi phương án truyền qua đường mạng, còn chi tiết "một địa điểm ở xa" loại nốt phương án vận chuyển vật lý dạng nhiều thiết bị nhỏ. Đây chính là ranh giới AWS dùng để phân biệt hai dịch vụ chuyển dữ liệu ngoại tuyến: dữ liệu rất lớn tập trung tại một nơi thì dùng Snowmobile, còn dữ liệu nhỏ hơn hoặc phân tán nhiều nơi thì dùng Snowball.

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

B — AWS Snowmobile. Snowmobile là dịch vụ chuyển dữ liệu ở quy mô exabyte: một container vận chuyển dài 45 foot được kéo bằng đầu xe tải, có thể chở tới 100PB dữ liệu mỗi Snowmobile. Nó được sinh ra đúng cho các tình huống như thư viện video, kho ảnh, hoặc di dời trọn một trung tâm dữ liệu.

Với 20PB, việc chuyển qua Internet là bất khả thi trong khung "thời gian ngắn nhất" — riêng thời gian truyền tải đã tính bằng nhiều tháng hoặc nhiều năm tuỳ băng thông. Chở dữ liệu bằng phương tiện vật lý và nạp trực tiếp vào hạ tầng AWS là con đường nhanh nhất, đồng thời an toàn và tiết kiệm hơn.

AWS khuyến nghị dùng Snowmobile cho các tập dữ liệu từ 10PB trở lên nằm tại một địa điểm duy nhất. Đề bài khớp cả hai vế: 20PB (vượt ngưỡng 10PB) và một "remote location" duy nhất. Đây chính là kịch bản mẫu của Snowmobile.

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

A — AWS Snowball. Đây là phương án gần đúng nhất, và nó sai không phải về nguyên lý mà về quy mô. Snowball cũng là chuyển dữ liệu ngoại tuyến bằng thiết bị vật lý, cũng nhanh hơn Internet, nhưng mỗi thiết bị chỉ chứa được một phần rất nhỏ so với 20PB. Muốn chuyển 20PB bằng Snowball thì phải điều phối một số lượng thiết bị rất lớn, cùng chừng ấy vòng đặt hàng — nhận thiết bị — sao chép — gửi trả, khiến tổng thời gian kéo dài hẳn ra, đi ngược yêu cầu "shortest possible time". Theo hướng dẫn của AWS, Snowball là lựa chọn cho tập dữ liệu dưới 10PB hoặc nằm phân tán ở nhiều địa điểm; ở đây dữ liệu vừa vượt ngưỡng vừa tập trung một chỗ, nên Snowmobile mới đúng.

C — AWS DataSync. DataSync là dịch vụ di chuyển dữ liệu trực tuyến, chạy trên đường mạng giữa on-premises (hoặc edge, hoặc cloud khác) và các dịch vụ lưu trữ AWS. Nó tự động hoá và tăng tốc việc sao chép, nhưng tốc độ trần vẫn bị chặn bởi băng thông đường truyền sẵn có. Với 20PB xuất phát từ một địa điểm xa nơi đường truyền không tối ưu, DataSync làm cả thời gian lẫn chi phí truyền tải phình lên — sai đúng vào ràng buộc mà đề nhấn mạnh.

D — AWS Storage Gateway. Storage Gateway là giải pháp lai (hybrid): nó để ứng dụng tại chỗ tiếp tục truy cập lưu trữ theo giao thức quen thuộc trong khi dữ liệu được đẩy dần lên AWS qua mạng. Bản chất của nó là duy trì một cầu nối lâu dài giữa on-premises và cloud, chứ không phải công cụ di dời một lần khối dữ liệu khổng lồ. Và vì vẫn phụ thuộc hoàn toàn vào đường truyền Internet, nó vấp đúng rào cản như DataSync khi phải xử lý 20PB từ một địa điểm xa.

📌 Điểm cần nhớ

• Khi đề nêu khối lượng ở mức petabyte kèm yêu cầu thời gian ngắn nhất, hãy loại ngay các dịch vụ truyền qua mạng (DataSync, Storage Gateway) và chỉ cân nhắc nhóm chuyển dữ liệu ngoại tuyến.
• Ranh giới giữa Snowball và Snowmobile là quy mô và mức độ tập trung: dữ liệu rất lớn ở một địa điểm → Snowmobile; dữ liệu nhỏ hơn hoặc phân tán nhiều địa điểm → Snowball. AWS lấy mốc 10PB làm đường phân chia.
• Chi tiết địa lý trong đề ("remote location", "internet speed may not be optimal") hầu như luôn là tín hiệu cố ý để loại bỏ các phương án phụ thuộc băng thông — đừng bỏ qua nó như văn cảnh trang trí.
• Phân biệt mục đích của dịch vụ, không chỉ khả năng: Storage Gateway sinh ra cho kiến trúc hybrid dùng lâu dài, còn Snowball/Snowmobile là công cụ di dời một lần.

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

Đề mô tả một công ty triển khai provisioned Amazon EMR cluster chạy Apache Spark cho phân tích big data, và yêu cầu chọn hai tổ hợp tài nguyên tiết kiệm nhất.

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

• "highly reliable configuration" — cấu hình phải đáng tin cậy, tức là không được chấp nhận mất dữ liệu. Cụm này một mình loại thẳng phương án dùng spot instance cho core node.
• "cost-effective, long-duration workloads" — workload chạy dài ngày, nên nơi lưu dữ liệu phải bền vững sau khi cluster tắt, chứ không phải kiểu lưu tạm theo vòng đời của instance.
• "while preserving existing performance levels" — không được đánh đổi hiệu năng để lấy giá rẻ. Cụm này là lý do lựa chọn nghiêng về Graviton: rẻ hơn mà vẫn giữ được mức price-performance, thay vì phải cắt giảm cấu hình.

Câu hỏi thực chất tách làm hai vế độc lập: chọn tầng lưu trữ (EMRFS/S3 hay HDFS) và chọn loại instance (Graviton, x86 hay Spot).

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

A — Dùng EMRFS làm nơi lưu trữ bền vững, đọc/ghi thẳng vào Amazon S3. EMRFS tách rời storage khỏi compute. Hệ quả trực tiếp về chi phí: bạn không còn phải provision core node chỉ để chứa dữ liệu, và không phải trả tiền cho phần nhân bản dữ liệu (replication) mà HDFS bắt buộc phải có. Về độ tin cậy, dữ liệu nằm trên S3 nên vẫn còn nguyên sau khi tắt cluster, và nhiều cluster khác cũng đọc được cùng tập dữ liệu đó. Với kiểu workload đọc dataset một lượt mỗi lần chạy, đây đúng là lựa chọn vừa rẻ vừa tin cậy cho long-duration workload trên EMR.

E — Dùng Graviton instance cho core node và task node. AWS Graviton là dòng processor thiết kế để cho price-performance tốt nhất cho workload chạy trên Amazon EC2. So với instance x86 tương đương, Graviton rẻ hơn đáng kể mà vẫn giữ được mức hiệu năng — đúng với ràng buộc "preserving existing performance levels" trong đề. Đây là cách hạ chi phí không kèm rủi ro mất dữ liệu, khác hẳn với hướng dùng spot.

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

B — Provision spot instance cho core node. Đây là phương án gần đúng nhất và cũng là bẫy chính. Spot Instances tận dụng capacity EC2 đang rảnh nên giá giảm rất mạnh so với On-Demand — xét riêng tiêu chí "tiết kiệm" thì nó rất hấp dẫn. Chỗ hỏng nằm ở vai trò của core node: core node vừa xử lý dữ liệu vừa lưu dữ liệu HDFS. Spot instance có thể bị thu hồi bất cứ lúc nào, mà một core instance bị terminate thì có nguy cơ mất dữ liệu. Spot chỉ nên dùng cho core node khi bạn chấp nhận được mất một phần dữ liệu HDFS — trong khi đề nói thẳng là cần "highly reliable". Vậy nên nó bị loại vì độ tin cậy, không phải vì giá.

C — Dùng HDFS làm nơi lưu trữ bền vững. Sai ngay ở chữ "persistent". HDFS là file system phân tán cho Hadoop, có ưu điểm là data awareness giữa các node trong cluster, nhưng nó ephemeral: dung lượng bị thu hồi khi instance bị terminate. Dữ liệu không sống qua vòng đời cluster nên không thể coi là kho lưu trữ bền vững. Thêm nữa, HDFS bắt bạn trả tiền cho việc nhân bản dữ liệu, và buộc phải duy trì core node chỉ để giữ dữ liệu — đắt hơn EMRFS đúng ở khoản đó. Với long-duration workload thì HDFS không phải lựa chọn phù hợp.

D — Provision instance x86 cho core node và task node. Không sai về kỹ thuật, cluster chạy được bình thường. Nhưng đề hỏi tổ hợp tiết kiệm nhất, mà instance x86 đắt hơn instance Graviton tương đương. Khi hai phương án cùng đáp ứng yêu cầu vận hành và độ tin cậy, phương án có giá cao hơn tự động bị loại. D và E loại trừ nhau, và E thắng.

📌 Điểm cần nhớ

• Đọc kỹ chữ "persistent" và "long-duration" trong đề EMR: chúng gần như luôn trỏ về EMRFS + S3 chứ không phải HDFS. HDFS là lưu trữ tạm gắn với vòng đời cluster.
• Tách storage khỏi compute là đòn bẩy chi phí lớn nhất trên EMR: bỏ được core node "chỉ để chứa dữ liệu", bỏ được chi phí replication, và dữ liệu vẫn còn sau khi tắt cluster.
• Spot instance phân biệt theo loại node: task node không giữ dữ liệu nên dùng spot khá an toàn; core node giữ dữ liệu HDFS nên đặt spot ở đó là đánh đổi trực tiếp với độ tin cậy. Đề nào nhắc "reliable" thì gạch phương án spot cho core node.
• Graviton là cách giảm giá "miễn phí" so với x86 tương đương — không đụng đến độ tin cậy, không đụng đến kiến trúc. Khi đề vừa đòi rẻ vừa đòi giữ nguyên hiệu năng, Graviton thường là mảnh ghép thứ hai của đáp án.

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

Đề mô tả một đội data engineering đang nhúng cứng (hardcode) chuỗi kết nối RDS ngay trong từng web server, và sau khi trượt kỳ security audit, họ muốn đổi cách làm.

Cụm từ quyết định đáp án nằm ở vế cuối: "store the database secrets securely and automatically rotate the database credentials". Hai yêu cầu phải thoả đồng thời:

1. Cất giữ bí mật an toàn, không nằm trong mã nguồn/cấu hình của web server.
2. Tự động xoay vòng (rotate) credential của database — không phải người vận hành đổi tay, mà dịch vụ tự làm.

Chỉ riêng vế "lưu trữ an toàn" thì nhiều phương án trong danh sách đáp ứng được ở mức nào đó; chính vế automatic rotation mới là ràng buộc lọc ra một đáp án duy nhất. Ngoài ra, chi tiết "RDS database" cũng đáng chú ý: nó gợi tới dịch vụ có tích hợp rotation sẵn cho RDS chứ không đòi bạn tự viết logic đổi mật khẩu.

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

B — Secrets Manager.

AWS Secrets Manager sinh ra đúng cho bài toán này: lưu trữ, quản lý, truy xuất và xoay vòng các loại bí mật như database credential, API key trong suốt vòng đời của chúng. Ứng dụng lấy bí mật bằng lời gọi API tới Secrets Manager tại thời điểm chạy, nên không còn chuỗi kết nối dạng plain text nằm trong web server — đúng thứ mà kỳ audit đã bắt lỗi.

Điểm mấu chốt khớp với đề: Secrets Manager có rotation dựng sẵn, tích hợp với Amazon RDS (cũng như Amazon Redshift và Amazon DocumentDB). Nghĩa là việc đổi mật khẩu database theo chu kỳ và cập nhật lại giá trị bí mật diễn ra tự động, ứng dụng chỉ việc đọc phiên bản hiện hành thay vì phải deploy lại. Cả hai yêu cầu của đề — cất giữ an toàn và tự động rotate — đều được một dịch vụ duy nhất giải quyết.

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

A — KMS. AWS Key Management Service dùng để tạo và quản lý khoá mã hoá (cryptographic key) cùng quyền sử dụng chúng trên các dịch vụ AWS và trong ứng dụng của bạn. KMS quản lý khoá, không phải nơi để cất chuỗi kết nối database, và nó không xoay vòng credential của database. Đây là phương án gây nhầm vì chữ "key" và vì KMS thực sự nằm trong bức tranh bảo mật — nhưng vai trò của nó là mã hoá dữ liệu, còn Secrets Manager mới là nơi giữ và luân chuyển bí mật.

C — AWS Config. Đây là dịch vụ audit và ghi nhận tình trạng tuân thủ của tài nguyên AWS. Nó liên quan tới từ khoá "security audit" trong đề nên rất dễ chọn nhầm, nhưng hãy đọc kỹ: audit chỉ là bối cảnh dẫn tới yêu cầu, còn yêu cầu là lưu và rotate credential. AWS Config có thể cho bạn biết cấu hình nào lệch chuẩn, nhưng không lưu trữ bí mật và không rotate credential — chọn nó là giải quyết triệu chứng chứ không giải quyết bài toán.

D — SSM Parameter Store. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. AWS Systems Manager Parameter Store cung cấp kho lưu trữ an toàn, phân cấp cho dữ liệu cấu hình và bí mật; bạn hoàn toàn có thể cất password, database string, license code ở đây và gỡ chúng khỏi web server. Nghĩa là nó thoả vế thứ nhất của đề. Chỗ nó hỏng là vế thứ hai: Parameter Store không tự động xoay vòng credential của database. Vì đề yêu cầu cả hai, phương án thoả một nửa vẫn là sai.

📌 Điểm cần nhớ

• Thấy cụm "automatically rotate credentials" đi kèm RDS/Redshift/DocumentDB → nghĩ ngay Secrets Manager. Đây là dấu hiệu phân biệt mạnh nhất giữa Secrets Manager và Parameter Store trong đề thi.
• Secrets Manager vs SSM Parameter Store: cả hai đều lưu bí mật an toàn; khác biệt kinh điển là rotation dựng sẵn. Nếu đề chỉ nói "lưu cấu hình/bí mật an toàn" mà không nhắc rotation, Parameter Store thường là lựa chọn hợp lý hơn.
• KMS quản lý khoá mã hoá, không phải kho bí mật. Nó là thành phần mã hoá phía dưới, không thay thế được dịch vụ quản lý secret.
• AWS Config = audit và compliance, không phải remediation cho secret. Từ khoá "failed a security audit" trong đề là bối cảnh, đừng để nó kéo bạn chọn dịch vụ audit.
• Với câu có hai yêu cầu nối bằng "and", hãy chấm điểm từng phương án theo cả hai vế; phương án thoả một vế luôn được đặt vào để bẫy người đọc lướt.

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

Đề mô tả một ứng dụng có hai đặc điểm rất cụ thể:

1. "perform a lot of overwrites and deletes on data" — khối lượng ghi đè và xoá dữ liệu lớn, tức là workload nặng về UPDATE/DELETE chứ không chỉ ghi thêm rồi đọc lại.
2. "require the latest information to be available anytime data is read via queries on database tables" — mỗi lần đọc bằng query trên bảng dữ liệu phải thấy ngay dữ liệu mới nhất.

Cụm quyết định là "queries on database tables" ghép với "the latest information ... anytime data is read". Vế đầu loại ngay những dịch vụ không phải cơ sở dữ liệu quan hệ có bảng và câu truy vấn; vế sau đòi hỏi tính nhất quán mạnh và giao dịch ACID — ghi đè, xoá xong là lần đọc kế tiếp phải thấy đúng trạng thái mới, không có bản cũ, không có độ trễ đồng bộ.

Nói cách khác, đề đang hỏi: dịch vụ nào cho CRUD trên bảng + giao dịch ACID. Chỉ cần bám hai chữ đó là bốn phương án tách bạch ngay.

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

C — Amazon Relational Database Service (Amazon RDS) là dịch vụ cơ sở dữ liệu quan hệ được quản lý, đúng loại công nghệ mà đề mô tả: dữ liệu nằm trong bảng, truy vấn bằng SQL, và mọi thao tác tạo – đọc – cập nhật – xoá được thực hiện trong khuôn khổ giao dịch ACID:

• Atomicity: giao dịch hoặc thành công trọn vẹn, hoặc bị huỷ hoàn toàn — không để lại trạng thái nửa vời sau một loạt overwrite/delete.
• Consistency: dữ liệu ghi vào phải tuân thủ mọi ràng buộc, cascade, trigger đã định nghĩa.
• Isolation: các giao dịch chạy đồng thời không giẫm lên nhau, đây là nền tảng của kiểm soát tương tranh khi có nhiều lượt ghi đè cùng lúc.
• Durability: giao dịch đã hoàn tất thì thay đổi là vĩnh viễn.

Chính bốn tính chất này bảo đảm điều đề yêu cầu: đọc lúc nào cũng ra bản mới nhất, không mập mờ, không kẹt khoá bản ghi. Ngoài ra RDS còn lo giúp việc cấp phát phần cứng, cài đặt, vá lỗi và sao lưu, nên đáp ứng được cả yêu cầu vận hành lẫn yêu cầu nhất quán.

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

A — Amazon S3: đây là dịch vụ lưu trữ đối tượng, không phải công nghệ database và không hỗ trợ truy vấn trên "database tables" theo cách mặc định. Phương án này gần đúng ở một điểm dễ gây nhầm: S3 có strong read-after-write consistency — ghi mới hoặc ghi đè một object xong thì lần đọc kế tiếp nhận ngay phiên bản mới nhất, và list operations cũng nhất quán mạnh. Nhưng nhất quán mạnh trên object không thay thế được giao dịch trên bảng: không có SQL, không có ràng buộc, không có giao dịch nhiều thao tác. Đề đã ghim chữ "queries on database tables", nên S3 rớt ngay ở đúng chỗ đó.

B — Amazon ElastiCache: kho dữ liệu in-memory, dùng để tăng tốc đọc với độ trễ thấp và thông lượng cao — hợp cho caching, session store, gaming, geospatial, real-time analytics, queuing. Đây là phương án "gần đúng" thứ hai vì nó có thể dùng được, nhưng vai trò tự nhiên của nó là lớp cache đặt trước một database để cải thiện đọc, chứ không phải nguồn dữ liệu chính (system of record) cho workload nặng ghi đè và xoá. Chọn ElastiCache làm nơi lưu chính thì mất đúng thứ đề đòi: cơ chế giao dịch trên bảng.

D — Amazon Neptune: graph database được quản lý, tối ưu cho dữ liệu liên kết dày đặc — lưu hàng tỷ quan hệ và duyệt đồ thị với độ trễ mili-giây. Nó cũng có read replica, point-in-time recovery, sao lưu liên tục sang S3, mã hoá khi truyền và khi lưu. Vấn đề không nằm ở chất lượng dịch vụ mà ở mô hình dữ liệu: đề nói về bảng và truy vấn trên bảng, không hề nhắc tới quan hệ đồ thị hay việc duyệt các mối nối. Dùng graph database cho một use case CRUD quan hệ thuần tuý là chọn sai công cụ.

📌 Điểm cần nhớ

• Thấy đề nhấn "database tables" + truy vấn + dữ liệu mới nhất sau nhiều update/delete → nghĩ ngay tới cơ sở dữ liệu quan hệ và giao dịch ACID, tức Amazon RDS.
• Amazon S3 nhất quán mạnh nhưng không phải database: strong read-after-write chỉ áp cho object, không cho bạn giao dịch, ràng buộc hay SQL trên bảng.
• Amazon ElastiCache là lớp tăng tốc đọc, không phải nơi lưu chính. Câu nào mô tả nguồn dữ liệu chuẩn (system of record) thì ElastiCache là bẫy.
• Chọn database theo mô hình dữ liệu trước, theo tính năng sau: Amazon Neptune chỉ thắng khi đề nói tới dữ liệu liên kết dày và việc duyệt quan hệ; đề nói tới bảng thì nó không có cửa.

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

Đề mô tả một tác vụ ad-hoc: đọc các object định dạng Apache Parquet nằm trong một Amazon S3 bucket, và chỉ cần truy vấn đúng một cột dữ liệu. Câu hỏi kết lại bằng: "How would you build a solution that involves the LEAST operational overhead?"

Có ba cụm từ quyết định, và cả ba đều kéo về cùng một hướng:

• "ad-hoc task" — làm một lần, không phải đường ống chạy định kỳ. Mọi hạ tầng dựng sẵn (crawler, data catalog, ETL job) đều là chi phí bỏ ra cho thứ chỉ dùng một lần.
• "only one column" — đây là lọc theo cột trong phạm vi một object, không phải một truy vấn phân tích trên cả tập dữ liệu lớn nhiều file.
• "LEAST operational overhead" — tiêu chí chấm không phải "chạy được", mà là "ít việc phải dựng và phải nuôi nhất". Cả bốn phương án đều lấy được cột đó; chỉ khác nhau ở lượng thứ phải cấu hình trước.

Cụm "LEAST operational overhead" chính là ràng buộc phân biệt, vì nếu bỏ nó đi thì phương án Athena cũng hoàn toàn hợp lệ.

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

Đáp án theo tệp là B — Use Amazon S3 Select to filter the required column from the contents of the Amazon S3 object.

Amazon S3 Select cho phép dùng câu lệnh SQL để lọc nội dung ngay bên trong một object S3 và chỉ lấy về đúng phần dữ liệu cần. Nhờ lọc ngay tại tầng S3, lượng dữ liệu S3 phải truyền đi giảm xuống, kéo theo giảm cả chi phí lẫn độ trễ khi lấy dữ liệu.

S3 Select khớp với đề ở mọi mặt:

• Nó làm việc trực tiếp với object định dạng Apache Parquet (ngoài ra còn CSV và JSON), đúng định dạng đề nêu.
• Nó hỗ trợ lệnh SELECT, với các mệnh đề SELECT list, FROM, WHERE, LIMIT — quá đủ để lấy ra một cột.
• Đặc điểm "chỉ truy vấn được một object mỗi lần" vốn là giới hạn của S3 Select, nhưng ở đây lại đúng với nhu cầu ad-hoc trên object trong bucket.

Quan trọng nhất: không cần dựng gì cả — không crawler, không schema trong catalog, không job, không hàm tự viết. Đó là định nghĩa của "least operational overhead".

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

A — Glue crawler tạo schema + Glue ETL job đọc cột bằng Spark dataframe. Sai vì hai lớp overhead chồng lên nhau: phải chạy crawler để sinh schema, rồi phải viết mã Apache Spark tùy biến cho một việc chỉ là lấy một cột. Viết và nuôi mã tùy biến là overhead không cần thiết cho một tác vụ ad-hoc.

C — Lambda nạp dữ liệu vào pandas DataFrame rồi SELECT trên DataFrame. Sai vì cũng phải phát triển mã tùy biến bằng pandas, kèm theo cả một Lambda function phải cấu hình và duy trì. Toàn bộ phần lọc cột ở đây là thứ S3 Select làm sẵn.

D — Glue crawler tạo schema + Athena SQL select cột. Đây là phương án gần đúng nhất, và nó chạy được thật — Athena hoàn toàn truy vấn được cột cần. Chỗ hỏng nằm đúng ở tiêu chí chấm: nó buộc phải cấu hình AWS Glue crawler trên các object S3 để tạo schema trước thì Athena mới có bảng mà truy vấn. Với một tác vụ ad-hoc lấy một cột, bước dựng schema đó là overhead thừa so với S3 Select vốn đọc thẳng object mà không cần schema nào. Nói cách khác, D thua B không phải vì sai kỹ thuật, mà vì thua ở tiêu chí "ít overhead nhất".

📌 Điểm cần nhớ

• Khi đề nói "ad-hoc" + "một object" + "least operational overhead", hãy nghĩ tới S3 Select trước: nó lọc ngay trong object, không cần schema, không cần hạ tầng dựng sẵn.
• S3 Select đọc được CSV, JSON và Apache Parquet, chỉ hỗ trợ lệnh SELECT với FROM, WHERE, LIMIT, và mỗi lần chỉ một object. Đề nào cần quét nhiều file hoặc join thì S3 Select hết cửa — lúc đó Athena mới là câu trả lời.
• "Chạy được" không đồng nghĩa với "đúng" trong dạng câu hỏi này. Cả A, C, D đều lấy được cột; tiêu chí phân loại là số bước phải cấu hình và lượng mã phải tự viết.
• Bất cứ phương án nào bắt viết mã tùy biến (Spark trong Glue ETL, pandas trong Lambda) đều tự động tụt hạng khi đề hỏi về operational overhead — dịch vụ có sẵn luôn thắng mã tự viết ở tiêu chí này.

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

Đề mô tả một hệ thống IoT (baby monitor, security camera, entertainment system) đẩy dữ liệu vào Kinesis Data Streams (KDS). Cụm từ quyết định nằm ở hai chỗ:

• "Multiple consumer applications are using the incoming data streams" — có nhiều ứng dụng tiêu thụ cùng lúc trên cùng một stream.
• "performance lag in the data delivery speed between producers and consumers" — vấn đề là độ trễ / thông lượng đọc, không phải producer ghi vào không nổi.

Ghép hai cụm này lại là ra bản chất: mặc định, băng thông đọc của một shard trong KDS được chia sẻ chung cho tất cả consumer đăng ký trên stream đó. Càng nhiều ứng dụng cùng đọc, mỗi ứng dụng càng phải giành phần nhỏ hơn của cùng một đường ống, và độ trễ giao dữ liệu tăng lên. Vậy câu hỏi thực chất là: làm sao cho mỗi consumer có đường đọc riêng thay vì chia nhau một đường?

Chú ý thêm một tín hiệu phụ: ba phương án đầu đều bắt đầu bằng "Swap out Kinesis Data Streams" — tức thay hẳn dịch vụ. Đề không hề nói KDS sai lựa chọn, chỉ nói nó chậm trong tình huống nhiều consumer. Thay cả kiến trúc để chữa một vấn đề thông lượng đọc là phản ứng quá tay.

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

D — Use Enhanced Fan-Out feature of Kinesis Data Streams.

Enhanced Fan-Out được sinh ra đúng cho tình huống này. Ở chế độ đọc mặc định (GetRecords), thông lượng đọc trên mỗi shard là một hạn mức dùng chung cho mọi consumer. Với Enhanced Fan-Out, developer đăng ký từng consumer làm stream consumer riêng, và mỗi consumer nhận đường đọc riêng trên mỗi shard, độc lập với các consumer khác. Thêm consumer mới không còn ăn vào phần của consumer cũ.

Ngoài ra, Enhanced Fan-Out dùng cơ chế đẩy (push) qua HTTP/2 với SubscribeToShard thay vì để consumer liên tục hỏi vòng (polling), nên độ trễ giao bản ghi giảm đáng kể — đúng cái mà đề gọi là "performance lag in data delivery speed". Và thông lượng riêng này tự co giãn theo số shard của stream, không phải cấu hình lại tay khi stream lớn lên.

Quan trọng nhất: đây là một tính năng bật thêm trên chính KDS, giữ nguyên producer, giữ nguyên mô hình nhiều consumer đọc song song cùng một dữ liệu. Không phải viết lại kiến trúc.

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

A — Thay KDS bằng Kinesis Data Firehose. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì Firehose cùng họ Kinesis và được quảng bá là "tự co giãn theo thông lượng dữ liệu". Nhưng Firehose là dịch vụ giao dữ liệu tới đích lưu trữ/phân tích (S3, Redshift, OpenSearch/Elasticsearch, Splunk...), có thể gom lô, nén, biến đổi, mã hoá trước khi ghi. Nó không cho ứng dụng tự đăng ký đọc trực tiếp từ stream — không có khái niệm consumer đọc song song như KDS. Đề bài lại nói rõ có multiple consumer applications đang tiêu thụ luồng dữ liệu, nên chuyển sang Firehose là phá mất chính năng lực đang cần, chứ không phải tăng tốc nó.

B — Thay KDS bằng SQS Standard queue. SQS Standard cho thông lượng rất cao, nhưng mô hình của nó là hàng đợi: một thông điệp được một consumer nhận và xử lý rồi xoá khỏi hàng đợi. Đây là mô hình chia việc, không phải mô hình phát tán cùng một dữ liệu cho nhiều ứng dụng độc lập. Nhiều consumer cắm vào một queue nghĩa là chúng chia nhau các thông điệp, mỗi ứng dụng chỉ thấy một phần dữ liệu IoT — sai hoàn toàn yêu cầu. Thêm nữa, SQS Standard chỉ đảm bảo thứ tự ở mức nỗ lực tốt nhất và giao ít nhất một lần (có thể trùng), điều mà dữ liệu cảm biến theo thời gian thường không chấp nhận được.

C — Thay KDS bằng SQS FIFO queue. FIFO chữa được hai điểm yếu vừa nêu của Standard: bảo đảm đúng thứ tự và xử lý đúng một lần. Nhưng nó không chữa được vấn đề gốc, vì vẫn là mô hình hàng đợi — vẫn không có chuyện nhiều ứng dụng cùng đọc trọn vẹn cùng một luồng. Tệ hơn nữa cho tình huống này: đổi lấy bảo đảm thứ tự, FIFO có trần thông lượng thấp hơn hẳn Standard. Đề đang than chậm mà lại chọn phương án có thông lượng thấp hơn — đi ngược mục tiêu.

Điểm chung của cả B và C: chúng nhìn nhầm bài toán thành "hàng đợi thông điệp", trong khi đề là bài toán streaming nhiều consumer cùng đọc lại một luồng.

📌 Điểm cần nhớ

• Thấy "multiple consumers" + "read throughput / lag" trên Kinesis Data Streams → phản xạ đầu tiên là Enhanced Fan-Out. Đó là câu trả lời chuẩn cho cảnh nhiều ứng dụng giành nhau băng thông đọc của cùng một shard.
• Phân biệt bản chất: KDS = nhiều consumer độc lập cùng đọc lại một luồng, dữ liệu giữ lại theo thời gian. SQS = hàng đợi chia việc, thông điệp xử lý xong là biến mất. Firehose = ống giao dữ liệu vào đích lưu trữ, không phục vụ consumer tự đọc.
• SQS FIFO đổi thông lượng lấy thứ tự. Bài nào than chậm mà phương án là FIFO thì gần như chắc chắn sai.
• Khi đề chỉ nêu một vấn đề hiệu năng, hãy ưu tiên phương án bật tính năng sẵn có của dịch vụ đang dùng thay vì phương án thay hẳn dịch vụ ("swap out ..."). Thay dịch vụ thường kéo theo mất một năng lực mà đề đang cần.

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

Đề mô tả một bảng Amazon DynamoDB liên tục bị provisioned throughput exception vì lưu lượng ghi dồn thành các đợt cao điểm đột biến. Nhóm phát triển muốn tách rời (decouple) tầng ứng dụng khỏi tầng cơ sở dữ liệu, và giao cho một worker process riêng đảm nhiệm việc ghi dữ liệu xuống DynamoDB.

Có ba cụm từ trong đề quyết định đáp án, và phải đọc đủ cả ba:

• "spikes in the writes" — vấn đề nằm ở đường ghi, không phải đường đọc. Cụm này một mình đã loại được mọi giải pháp thuộc về caching đọc.
• "decouple ... and dedicate a worker process" — đây chính là mô tả kinh điển của mô hình queue + consumer: producer đẩy message vào hàng đợi rồi trả lời client ngay, worker rút message ra theo nhịp mà DynamoDB chịu được. Dịch vụ được chọn phải giữ lại (persist) message cho tới khi worker xử lý xong.
• "scale infinitely ... in the most cost-effective way" — ràng buộc phân biệt cuối cùng. Nhiều phương án còn lại vẫn "chạy được" ở mức nào đó, nên tiêu chí rẻ nhất cho tải dạng đột biến mới là thứ chốt hạ.

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

Đáp án đúng theo tệp là C — Amazon Simple Queue Service (Amazon SQS).

SQS là dịch vụ message queue được quản lý hoàn toàn, sinh ra đúng để decouple microservice, hệ phân tán và ứng dụng serverless. Đặt SQS làm lớp trung gian giữa ứng dụng và DynamoDB thì:

• Ứng dụng chỉ việc đẩy message vào queue — thao tác này không bị ràng buộc bởi throughput đã cấp phát của bảng DynamoDB, nên đỉnh ghi được hấp thụ vào queue thay vì đập thẳng vào bảng.
• Worker process chuyên trách đọc message ra và ghi xuống DynamoDB theo tốc độ mà bảng chịu được. Đây chính là kỹ thuật buffering/throttling làm phẳng đường ghi, khiến provisioned throughput exception biến mất.
• Queue lưu giữ message cho tới khi có consumer xử lý, nên dữ liệu trong lúc cao điểm không bị mất.
• SQS có hai loại queue: standard queue (throughput tối đa, thứ tự best-effort, giao ít nhất một lần) và FIFO queue (xử lý đúng một lần, đúng thứ tự gửi). Cả hai đều đáp ứng nhu cầu decouple ở đây.
• Về chi phí, SQS tính theo lượng request thực tế nên với tải thất thường, lúc cao lúc thấp thì nó là lựa chọn kinh tế nhất trong danh sách.

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

A — Amazon Kinesis Data Streams. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. KDS thật sự là dịch vụ streaming thời gian thực, bền bỉ, và throughput mở rộng được bằng cách tăng số shard, nên về mặt kỹ thuật nó vẫn có thể làm lớp đệm cho ghi. Nhưng KDS được thiết kế cho dòng dữ liệu thời gian thực đều đặn, liên tục, còn ở đây tải là các đợt đột biến rời rạc. Mô hình shard buộc phải cấp phát năng lực cho đỉnh, tức là ngoài lúc cao điểm vẫn phải trả tiền cho phần dư — nên nó không tiết kiệm bằng SQS đối với dạng tải spiky này. Đề đã nêu rõ "most cost-effective way", nên KDS thua ở đúng tiêu chí đó chứ không phải ở khả năng.

B — Amazon DynamoDB DAX. DAX là bộ nhớ đệm in-memory được quản lý cho DynamoDB, giúp giảm độ trễ đọc từ mili giây xuống micro giây, tự lo việc vô hiệu hoá cache và quản lý cụm. Vấn đề: DAX phục vụ đọc, không giải quyết gì cho đường ghi. Đề bài nói thẳng exception đến từ writes, nên DAX sai ngay từ bản chất — và nó cũng không decouple ứng dụng khỏi database, cũng chẳng tạo ra chỗ cho worker process.

D — Amazon Simple Notification Service (Amazon SNS). SNS đúng là dịch vụ pub/sub được quản lý, sẵn sàng cao, và cũng thường được dùng để decouple — nên nghe qua rất hợp lý. Chỗ hỏng nằm ở mô hình phân phối: SNS đẩy message tới subscriber và không giữ lại dữ liệu nếu không giao được. Trong tình huống cao điểm, đó chính là lúc worker chưa kịp nhận — và message sẽ mất. Muốn hấp thụ đỉnh tải thì phải có nơi chứa message chờ xử lý, tức là một queue, chứ không phải một kênh phát tin.

📌 Điểm cần nhớ

• Đọc kỹ hướng của tải: write bottleneck thì mọi phương án caching đọc như DAX bị loại ngay, dù chúng có tên gắn liền với chính DynamoDB.
• Cặp từ khoá "decouple" + "worker process" gần như luôn trỏ tới mô hình queue: producer đẩy vào, consumer rút ra theo nhịp của hệ thống phía sau.
• Phân biệt SQS và SNS bằng câu hỏi "message có được giữ lại chờ xử lý không?". SQS giữ (pull, có buffer); SNS đẩy đi và không lưu nếu không giao được (push, fan-out).
• Phân biệt SQS và Kinesis Data Streams bằng dạng tải và chi phí: tải đột biến, không đều → SQS trả theo request là kinh tế hơn; dòng dữ liệu liên tục, cần replay hoặc nhiều consumer đọc lại cùng dữ liệu → mới đáng dùng Kinesis. Khi đề nhấn "most cost-effective", đó thường là chỗ Kinesis bị loại dù về mặt kỹ thuật nó làm được.

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

Đề mô tả một REST API chạy trong Auto Scaling group sau Application Load Balancer, dữ liệu người dùng nằm trong DynamoDB, còn nội dung tĩnh như ảnh thì phục vụ từ S3. Câu hỏi yêu cầu chọn giải pháp MOST efficient để cải thiện hiệu năng ứng dụng.

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

• "90% of the read requests are for commonly accessed data across all users" — tải chủ yếu là đọc và lặp lại cùng một dữ liệu cho mọi người dùng. Đây chính là điều kiện lý tưởng để đặt một lớp cache phía trước, vì tỉ lệ cache hit sẽ rất cao.
• "stores the user data in DynamoDB and any static content, such as images, is served via S3" — có hai nguồn dữ liệu khác nhau, nên đáp án phải ghép đúng cơ chế cache cho từng nguồn. Mọi phương án đều đưa ra một cặp; việc còn lại chỉ là kiểm tra từng vế có hợp lệ với nguồn tương ứng hay không.

Nói cách khác, đây là câu ghép cặp: cache cho DynamoDB là gì, và cache cho S3 là gì.

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

Đáp án đúng theo tệp là A — Enable Amazon DynamoDB Accelerator (DAX) for DynamoDB and Amazon CloudFront for S3.

• DAX cho DynamoDB: DAX là in-memory cache được quản lý hoàn toàn, thiết kế riêng cho DynamoDB, đưa độ trễ đọc từ mức mili-giây xuống mức micro-giây ngay cả ở quy mô rất lớn. Điểm mạnh khiến nó là lựa chọn "hiệu quả nhất": DAX tương thích API với DynamoDB, chỉ cần dựng cluster và trỏ các lời gọi hiện có qua DAX client SDK, không phải sửa logic ứng dụng. DAX cache đọc của DynamoDB một cách "native".
• CloudFront cho S3: CloudFront là CDN, phục vụ nội dung tĩnh từ Edge Location gần người dùng. Khi có bản sao trong cache, CloudFront trả về ngay với độ trễ thấp; chưa có thì lấy từ origin là bucket S3 rồi cache lại. Đây đúng là cách chuẩn để tăng tốc phần ảnh và nội dung tĩnh, đồng thời giảm lưu lượng đi thẳng ra từ S3.

Cặp này khớp hoàn hảo với dữ kiện "90% đọc, dữ liệu dùng chung cho mọi người dùng": cả hai lớp cache đều phát huy tối đa khi cùng một nội dung được nhiều người yêu cầu lặp lại.

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

B — ElastiCache cho cả DynamoDB và S3: sai ở cả hai vế. ElastiCache là in-memory data store rất nhanh, nhưng nó không dùng được để phục vụ nội dung tĩnh từ S3 — nó không phải CDN và không đứng trước bucket. Vế DynamoDB cũng không tối ưu, xem giải thích ở phương án D.

C — DAX cho DynamoDB và ElastiCache cho S3: đây là phương án gần đúng nhất, vế DynamoDB đã chọn đúng DAX. Nó hỏng ở vế thứ hai: ElastiCache không phải cơ chế phục vụ nội dung tĩnh từ S3, trong khi CloudFront mới là dịch vụ sinh ra cho việc đó. Sai một nửa vẫn là sai — bài thi ghép cặp đòi cả hai vế cùng đúng.

D — ElastiCache cho DynamoDB và CloudFront cho S3: cũng gần đúng, vế S3 chọn CloudFront là chuẩn. Hỏng ở vế DynamoDB: tuy về mặt kỹ thuật vẫn tích hợp ElastiCache với DynamoDB được, cách làm đó phức tạp hơn hẳn — phải tự viết logic đọc cache, ghi cache, xử lý invalidation trong code ứng dụng. DAX làm sẵn tất cả những việc đó và tương thích API, nên với tiêu chí MOST efficient trong đề, D thua A.

📌 Điểm cần nhớ

• Cụm "MOST efficient" trong các câu ghép cặp thường không dùng để loại phương án bất khả thi, mà để loại phương án làm được nhưng tốn công hơn — như ElastiCache so với DAX cho DynamoDB.
• Ghép đúng cache với đúng nguồn: DynamoDB → DAX (cache đọc native, tương thích API, không sửa code); S3 và nội dung tĩnh → CloudFront (CDN, cache tại Edge Location).
• ElastiCache không phải CDN: bất kỳ phương án nào đặt ElastiCache trước S3 để phục vụ ảnh/nội dung tĩnh đều loại được ngay, không cần đọc tiếp vế còn lại.
• Dữ kiện kiểu "phần lớn là read, dữ liệu dùng chung cho mọi user" là tín hiệu kinh điển cho giải pháp caching; hãy đọc kỹ con số đó thay vì lướt qua như văn cảnh trang trí.

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

Đề mô tả một pipeline: Step Functions điều phối các job EMR — job đầu kéo dữ liệu từ nhiều nguồn về S3, job sau đẩy dữ liệu sang Redshift. State machine và EMR cluster (nằm trong một VPC) đều được dựng tay, và hiện state machine không chạy được các job EMR.

Cụm từ quyết định đáp án là "determine the root cause" — tìm nguyên nhân gốc, tức là chẩn đoán. Nó không hỏi "làm sao xử lý lỗi cho êm" hay "làm sao báo cho người trực". Mọi phương án nói về việc phản ứng với lỗi (Fail state, Catch, Retry) đều lệch mục tiêu ngay từ động từ của câu hỏi.

Cụm thứ hai là "manually configured" và "within a VPC": dựng tay thì hai thứ hay sót nhất chính là IAM permissions của state machine và cấu hình mạng (security group, đường ra tới nguồn dữ liệu). Đó chính là hai hướng điều tra mà đáp án nhắm tới. Cuối cùng, (Select two) cùng với việc có hai phương án B và C chỉ khác nhau ở câu cuối báo hiệu rõ: một cặp là bẫy phân biệt bằng đúng tên công cụ S3.

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

A — VPC Flow Logs + security group của EMR cluster. VPC Flow Logs ghi lại thông tin về lưu lượng IP đi vào và ra khỏi các network interface trong VPC; bật cho VPC hoặc subnet là mọi interface bên trong đều được theo dõi, và bản ghi có thể đẩy sang CloudWatch Logs, S3 hoặc Data Firehose. Đọc flow log cho biết traffic từ EMR cluster có thực sự tới được các data provider hay không — nếu bị chặn, bản ghi sẽ phản ánh điều đó. Ghép thêm việc kiểm tra security group của EMR cluster có mở đúng cổng tới máy chủ nguồn hay không, ta có một bước chẩn đoán mạng hoàn chỉnh: dữ liệu quan sát được (flow log) cộng với cấu hình cho phép (security group).

B — IAM permissions + Access Analyzer for Amazon S3. Step Functions cần được cấp quyền IAM mới truy cập được tài nguyên AWS. Với tình huống này, state machine phải có quyền tạo và chạy job EMR, đồng thời có quyền làm việc với các S3 bucket mà job EMR dùng. Vì cluster và state machine đều dựng tay, thiếu quyền là nguyên nhân gốc rất có khả năng. Access Analyzer for Amazon S3 đúng là công cụ dùng để soát lại access settings của bucket, nên nó khớp với việc xác minh quyền truy cập.

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

C — IAM permissions + S3 Analytics storage class analysis. Đây là phương án gần đúng nhất, và phần đầu của nó giống hệt B: kiểm tra quyền IAM cho EMR và S3 — phần đó không sai. Nó hỏng ở đúng một chỗ: công cụ chọn sai. S3 Analytics storage class analysis quan sát mẫu truy cập dữ liệu để giúp quyết định khi nào nên chuyển dữ liệu ít được dùng từ STANDARD sang STANDARD_IA — nó là công cụ tối ưu chi phí lưu trữ, không nói gì về access settings hay quyền truy cập bucket. Bài học rút ra: khi hai phương án chỉ khác nhau mệnh đề cuối, mệnh đề cuối chính là điểm chấm.

D — Fail state + Catch block gửi SNS cho người xử lý. Fail state ("Type": "Fail") dừng execution và đánh dấu là thất bại, trừ khi được Catch bắt lại. Thêm nó vào chỉ khiến state machine chuyển sang trạng thái lỗi khi job EMR hỏng, rồi bắn thông báo cho một người. Đó là xử lý lỗi và cảnh báo — nó không chỉ ra nguyên nhân gốc. Người nhận SNS vẫn phải đi làm đúng việc mà A và B mô tả. Lệch với "determine the root cause".

E — Fail state + Retry block, tăng khoảng cách giữa các lần thử. Cùng lỗi khái niệm như D, nhưng còn xa hơn: thử lại chậm hơn chỉ có ý nghĩa với lỗi thoáng qua (throttling, tài nguyên tạm chưa sẵn sàng). Nếu nguyên nhân là thiếu quyền IAM hoặc security group chặn cổng, thử lại bao nhiêu lần với khoảng cách bao lâu cũng vẫn hỏng y như vậy — và vẫn không cho biết vì sao hỏng.

📌 Điểm cần nhớ

• Đọc kỹ động từ của câu hỏi: determine the root cause (chẩn đoán) khác hẳn handle the failure (xử lý). Fail state, Catch, Retry, SNS đều thuộc nhóm xử lý — chúng bị loại ngay dù nội dung kỹ thuật hoàn toàn đúng.
• Với pipeline dựng tay có Step Functions gọi dịch vụ khác, hai nghi phạm mặc định là IAM permissions của state machine và cấu hình mạng của VPC (security group, đường tới nguồn). Câu hỏi kiểu này thường muốn đúng cặp đó.
• VPC Flow Logs là công cụ quan sát traffic IP trong VPC — dùng để xác nhận gói tin có đi tới đích không; nó bổ sung cho việc soát security group chứ không thay thế.
• Phân biệt hai tính năng S3 dễ lẫn tên: Access Analyzer for S3 soát quyền truy cập bucket; S3 Analytics storage class analysis soát mẫu truy cập để chuyển storage class, phục vụ tối ưu chi phí.
• Khi hai phương án chép gần như nguyên văn nhau, hãy so từng chữ và tập trung vào phần khác biệt — đó chính là chỗ đề đặt bẫy.