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 marketing thu thập dữ liệu tương tác mạng xã hội mỗi ngày, lưu dưới dạng file .csv trong một S3 bucket. Data engineer cần dữ liệu này được cataloged hằng ngày vào AWS Glue Data Catalog để các dịch vụ analytics của AWS dùng được.

Cụm từ quyết định đáp án là "with the least manual effort" (ít công sức thủ công nhất), đi kèm với "each day". Cả bốn phương án đều dùng chung một công cụ làm việc thật sự: AWS Glue crawler. Không phương án nào thay thế crawler bằng thứ khác — chúng chỉ khác nhau ở cái gì kích hoạt crawler chạy mỗi ngày.

Vì vậy câu này không phải là câu hỏi "dịch vụ nào catalog được S3", mà là câu hỏi "có cần thêm dịch vụ trung gian để hẹn giờ crawler không?". Khi ràng buộc là ít công sức nhất mà mọi phương án đều dùng crawler, phương án nào chồng thêm một lớp dịch vụ chỉ để làm việc mà crawler đã tự làm được thì phương án đó thua.

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

Đáp án đúng là C: gán cho AWS Glue crawler một IAM role có đủ quyền Glue, trỏ nó vào phần dữ liệu social media trong S3 bucket, rồi đặt lịch chạy hằng ngày ngay trên chính crawler.

Hai lý do:

• Glue crawler có sẵn cơ chế lập lịch. Khi tạo crawler, bạn khai luôn schedule chạy theo chu kỳ (hằng ngày). Không cần bất kỳ dịch vụ ngoài nào bấm nút hộ. Đây chính là mấu chốt mà đề nhắm tới.
• Crawler là dịch vụ được quản lý làm đúng việc đề yêu cầu: nó quét S3 path, tự suy ra schema của file .csv, tạo và cập nhật bảng trong Glue Data Catalog khi có dữ liệu mới hoặc dữ liệu thay đổi. Sau đó Athena, Redshift Spectrum, Glue ETL đọc được ngay.

IAM role không phải chi tiết thừa: crawler chạy dưới một role, và role đó phải có quyền Glue cùng quyền đọc S3 bucket — thiếu nó thì crawler không catalog được. Phương án C nêu đủ ba mảnh: quyền, nguồn dữ liệu, lịch chạy. Đó là cấu hình hoàn chỉnh, và cũng là cấu hình ít bộ phận chuyển động nhất.

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

A. EventBridge rule → Step Functions workflow → chạy crawler. Đây là phương án "kiến trúc đẹp" nhưng thừa. Step Functions dùng để điều phối nhiều bước có phụ thuộc lẫn nhau, có rẽ nhánh, có xử lý lỗi giữa các bước. Ở đây chỉ có đúng một bước: chạy crawler. Dựng một state machine cho một bước duy nhất là thêm định nghĩa workflow, thêm IAM role cho Step Functions, thêm EventBridge rule — ba thứ phải tạo và bảo trì để thay thế một ô lịch có sẵn trong Glue. Nó chạy được, chỉ là không phải "least manual effort".

B. Lambda được CloudWatch Events gọi hằng ngày, Lambda gọi crawler. Đây là phương án gần đúng nhất và cũng là bẫy chính. Về mặt kỹ thuật nó hoàn toàn hoạt động: Lambda gọi API StartCrawler. Nhưng nó hỏng ở chỗ bạn phải viết và nuôi code: hàm Lambda, execution role cho nó, xử lý lỗi khi crawler đang chạy dở, và một scheduled rule nữa. Toàn bộ công đó chỉ để tái tạo tính năng hẹn giờ mà crawler đã có sẵn không mất dòng code nào. So với C, nó thêm việc chứ không thêm khả năng.

C là đáp án đúng — xem mục trên.

D. AWS Batch job chạy crawler, CloudWatch Events kích hoạt job hằng ngày. Sai nặng nhất trong bốn phương án, vì sai cả về mục đích dịch vụ lẫn về độ phức tạp. AWS Batch dành cho khối lượng công việc tính toán theo lô (chạy container trong hàng đợi job, phân bổ compute). Crawler không phải một job compute mà bạn nộp vào Batch — nó là dịch vụ được quản lý mà bạn gọi API để khởi động. Muốn dùng Batch bạn phải dựng compute environment, job queue, job definition, đóng gói container chỉ để gọi một API call. Vừa lệch mục đích, vừa là lớp phức tạp dày nhất trong bốn lựa chọn.

📌 Điểm cần nhớ

• AWS Glue crawler tự lập lịch được. Thấy đề hỏi "catalog dữ liệu S3 theo chu kỳ, ít công nhất" thì mặc định là crawler + schedule của chính crawler, không cần trigger từ ngoài.
• Khi mọi phương án cùng dùng một dịch vụ lõi và chỉ khác ở lớp kích hoạt, cụm "least manual effort" / "least operational overhead" luôn chọn phương án ít dịch vụ nhất, tức là dùng tính năng dựng sẵn thay vì viết Lambda hay dựng workflow.
• Lambda + EventBridge là bẫy quen thuộc trong đề AWS: nó luôn "chạy được" nên trông rất hợp lý, nhưng nếu dịch vụ đích đã có tính năng tương đương thì nó chỉ là code phải bảo trì thêm.
• Nhớ đúng mục đích từng dịch vụ điều phối: Step Functions cho quy trình nhiều bước có phụ thuộc; AWS Batch cho khối lượng compute theo lô. Dùng chúng để bấm nút một API call là dấu hiệu của phương án sai.

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

Đề mô tả một workflow AWS Step Functions điều phối quá trình di trú dữ liệu gồm ba việc phụ thuộc lẫn nhau: extract → transform → load. Cụm từ quyết định là "Each task must be completed before the next one begins" — nghĩa là các task phải chạy tuần tự, việc sau chỉ khởi động khi việc trước đã xong. Câu hỏi yêu cầu chọn state nào của Step Functions phù hợp với dòng chảy tuần tự đó, và bốn phương án đều là tên state có thật trong Amazon States Language, nên phải phân biệt bằng đúng vai trò của từng state chứ không đoán theo tên nghe quen.

Điểm cần chú ý: đề không hỏi state nào tạo ra thứ tự — trong Step Functions thứ tự vốn do trường Next giữa các state quy định — mà hỏi state nào thuộc về mô hình workflow tuần tự này. Đó là chỗ khiến câu hỏi khó hơn vẻ ngoài của nó.

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

Theo tệp, đáp án đúng là C — Succeed.

Lập luận của nguồn: bản thân Succeed không tự sắp thứ tự cho các task. Thứ tự tuần tự được thể hiện bằng cấu trúc của state machine, nơi mỗi state chuyển tiếp sang state kế tiếp sau khi hoàn thành. Succeed là state đặt ở cuối chuỗi đó, đánh dấu rằng toàn bộ các bước đã chạy xong theo đúng trình tự và workflow kết thúc thành công.

Nói cách khác, trong bốn phương án thì Succeed là state duy nhất thuộc về một luồng tuần tự thẳng (extract → transform → load → kết thúc). Ba state còn lại đều làm thay đổi hoặc bẻ nhánh dòng chảy: rẽ nhánh theo điều kiện, tách nhánh song song, hoặc chèn độ trễ. Vì vậy nguồn xem Succeed là lựa chọn phù hợp với mô tả trong đề.

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

A — Choice. Choice là state ra quyết định: nó đọc dữ liệu đầu vào, so khớp với các quy tắc, rồi rẽ workflow sang nhánh tương ứng. Nó hữu ích khi cần "nếu dữ liệu hợp lệ thì load, ngược lại thì báo lỗi", nhưng đề bài không nêu điều kiện rẽ nhánh nào. Choice không tạo ra quan hệ "task này xong mới tới task kia" — nó tạo ra sự phân nhánh, tức là ngược với một chuỗi thẳng.

B — Parallel. Đây là phương án gây nhầm nhiều nhất, vì nó là state duy nhất trực tiếp nói về cách nhiều task chạy cùng nhau. Nhưng Parallel chạy nhiều nhánh đồng thời, đúng cái mà đề bài loại trừ. Nếu bọc extract, transform, load vào một Parallel, cả ba khởi động cùng lúc: transform sẽ đọc dữ liệu chưa được extract xong, load sẽ ghi dữ liệu chưa được transform. Parallel chỉ đúng khi các nhánh độc lập với nhau — điều mà câu "Each task must be completed before the next one begins" phủ định thẳng.

D — Wait. Wait tạm dừng workflow trong một khoảng thời gian, hoặc tới một mốc thời gian định trước. Nó cũng khá gần đúng ở chỗ có vẻ "làm chậm lại để chờ việc trước", nhưng cơ chế hoàn toàn khác: Wait chờ theo đồng hồ, không chờ theo kết quả của task trước. Dùng Wait để ép thứ tự là đoán mò thời lượng xử lý — extract chạy lâu hơn dự kiến thì transform vẫn khởi động và làm việc trên dữ liệu thiếu. Đây là chờ mù, không phải phụ thuộc.

📌 Điểm cần nhớ

• Trong Step Functions, thứ tự tuần tự đến từ chuyển tiếp giữa các state (mỗi state trỏ sang state kế tiếp), chứ không đến từ một state đặc biệt nào — hiểu điều này giúp đọc đúng cả những câu hỏi diễn đạt vòng vo.
• Parallel = nhiều nhánh đồng thời, độc lập. Thấy đề nhấn "must complete before", "in order", "dependent tasks" thì đó chính là tín hiệu loại Parallel.
• Choice = rẽ nhánh theo điều kiện dữ liệu; Wait = trễ theo thời gian. Không cái nào diễn đạt được quan hệ phụ thuộc "xong việc A rồi mới tới B".
• Succeed là state kết thúc đánh dấu workflow hoàn tất thành công — cặp đôi của nó là Fail cho trường hợp kết thúc lỗi. Nhớ nhóm state theo vai trò (task, rẽ nhánh, song song, chờ, kết thúc) sẽ loại phương án nhanh hơn nhiều so với nhớ từng tên rời rạc.

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

Một công ty thương mại điện tử muốn nâng cấp bộ máy gợi ý sản phẩm bằng cách đưa dữ liệu nghiên cứu thị trường của bên thứ ba vào hạ tầng phân tích dữ liệu sẵn có. Đề hỏi thẳng: nên dùng dịch vụ AWS nào?

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

• "third-party market research datasets" — nguồn dữ liệu nằm ở nhà cung cấp bên ngoài, không phải dữ liệu công ty đang giữ trong on-premises hay trong tài khoản AWS của mình. Bài toán ở đây là tìm, đăng ký và truy cập một bộ dữ liệu thương mại, chứ không phải chuyện đường ống vận chuyển byte.
• "with minimal operational effort" — chọn dịch vụ được quản lý sẵn cho đúng nhu cầu đó, không dựng thêm mắt xích phải tự vận hành.

Ghép hai ràng buộc lại: câu này hỏi về kênh phân phối dữ liệu bên thứ ba, không hỏi về công cụ truyền dữ liệu. Đó là chỗ phân biệt C với ba phương án còn lại — cả ba đều là công cụ di chuyển dữ liệu, nhưng không cái nào giải quyết việc lấy được dữ liệu từ nhà cung cấp ngay từ đầu.

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

C — Import third-party datasets directly from AWS Data Exchange into the company's data analytics platform.

AWS Data Exchange là nơi tìm, đăng ký (subscribe) và sử dụng dữ liệu của bên thứ ba ngay trong môi trường AWS. Dữ liệu nghiên cứu thị trường đúng là loại dữ liệu được phân phối theo cách này: nhà cung cấp đưa bộ dữ liệu lên, khách hàng đăng ký rồi dùng.

Về mặt vận hành, dịch vụ lo giúp phần rắc rối nhất — quyền truy cập, việc giao dữ liệu tới tài khoản của người đăng ký — nên công ty không phải dựng và trông coi đường ống lấy dữ liệu riêng cho từng nhà cung cấp. Nhờ vậy họ tập trung được vào việc thực sự muốn làm: cải thiện bộ máy gợi ý sản phẩm. Đây chính xác là ý "minimal operational effort" mà đề đòi.

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

A — AWS DataSync để chuyển dữ liệu bên thứ ba vào môi trường AWS. Đây là phương án gần đúng nhất, và cũng là cái bẫy chính. DataSync đúng là dịch vụ được quản lý để chuyển khối lượng dữ liệu lớn, nhưng nó chuyển giữa kho lưu trữ on-premises và các dịch vụ lưu trữ AWS — tức là giữa những nơi bạn đã có quyền truy cập. Nó hỏng ở chỗ: DataSync không phải kênh để tiếp cận dữ liệu bên thứ ba. Trước khi DataSync chạy được, bạn vẫn phải tự xoay xở việc tìm nhà cung cấp, thoả thuận, lấy quyền và đưa dữ liệu về một điểm nào đó — đúng phần công sức vận hành mà đề bảo phải giảm thiểu.

B — Truy cập dữ liệu bên thứ ba từ Amazon S3 bằng Amazon Kinesis Data Streams. Phương án này giả định dữ liệu đã nằm sẵn trong S3, tức là giả định luôn phần khó nhất của đề bài đã xong. Ngoài ra Kinesis Data Streams sinh ra cho dữ liệu streaming thời gian thực, còn dữ liệu nghiên cứu thị trường là bộ dữ liệu giao theo lô. Ghép một dịch vụ streaming vào một bài toán không phải streaming là thêm mắt xích phải vận hành mà chẳng giải quyết được vấn đề gốc: làm sao có dữ liệu.

D — Stream dữ liệu bên thứ ba bằng Kinesis Data Streams lấy từ AWS CodeCommit. Sai ở cả hai vế. CodeCommit là dịch vụ quản lý mã nguồn (source control) — dữ liệu nghiên cứu thị trường của bên thứ ba không được phân phối qua kho mã nguồn. Còn Kinesis Data Streams thì như đã nói, dành cho luồng thời gian thực. Đây là phương án dễ loại nhất: hai dịch vụ đúng tên nhưng ghép vào sai hoàn toàn ngữ cảnh.

📌 Điểm cần nhớ

• Thấy cụm "third-party data" / "external data provider" trong đề, hãy nghĩ ngay tới AWS Data Exchange — đó là dịch vụ chuyên cho việc tìm, đăng ký và dùng dữ liệu của bên ngoài.
• Phân biệt rõ "lấy được dữ liệu" với "vận chuyển dữ liệu". DataSync giỏi việc thứ hai, nhưng chỉ chạy được khi bạn đã có quyền truy cập nguồn. Câu hỏi nào nhấn vào nguồn dữ liệu bên ngoài thì công cụ vận chuyển không phải câu trả lời.
• Kinesis Data Streams gắn với dữ liệu thời gian thực. Đề nói tới bộ dữ liệu (dataset) giao theo lô mà phương án lại đề nghị streaming thì gần như chắc chắn sai.
• Cụm "minimal operational effort" luôn ưu ái phương án dùng đúng dịch vụ được quản lý cho đúng nhu cầu, thay vì phương án ghép nhiều dịch vụ lại để mô phỏng nhu cầu đó.

Đáp án

C — Dùng bucket policy với điều kiện chỉ cho phép yêu cầu đến qua VPC endpoint

Vì sao đúng

Bucket policy là nơi duy nhất trong danh sách áp được điều kiện về nguồn gốc của yêu cầu. Với khoá điều kiện aws:SourceVpce (hoặc aws:SourceVpc), bạn khai rằng chỉ yêu cầu đi qua VPC endpoint chỉ định mới được chấp nhận — mọi yêu cầu khác bị từ chối, kể cả khi người gửi có đủ quyền IAM.

Đây là kiểm soát ở phía tài nguyên, nên nó áp cho mọi đường vào chứ không phụ thuộc vào việc từng người dùng được cấu hình thế nào.

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

• A. Dùng IAM policy cho mọi người dùng — về lý thuyết áp được điều kiện tương tự, nhưng bạn phải nhớ gắn cho từng người, và một tài khoản bị sót là một lỗ hổng. Bucket policy bao trọn.
• B. Dùng NACL — lọc ở tầng mạng trong VPC; nó không kiểm soát được ai gọi tới S3 từ ngoài.
• D. Gắn security group vào bucket — không làm được: S3 là dịch vụ nằm ngoài VPC, security group chỉ gắn được vào giao diện mạng bên trong VPC.

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

Một công ty y tế lưu hồ sơ bệnh nhân dạng JSON trong một S3 bucket ở region US East (N. Virginia). Vì yêu cầu pháp lý, dữ liệu này phải được sao lưu tự động sang một region khác để phục vụ disaster recovery.

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

• "automatically backed up to another AWS region" — đích đến là một region khác, nên mọi cơ chế chỉ hoạt động trong phạm vi một bucket/một region đều bị loại ngay.
• "seamless and require minimal manual intervention" — đây là ràng buộc phân biệt các phương án còn lại với nhau. Cả bốn phương án về mặt lý thuyết đều có thể đưa dữ liệu sang region khác (trừ D, xem bên dưới), nhưng đề không hỏi "cách nào làm được", mà hỏi cách nào ít phải tự dựng và tự vận hành nhất. Khi đề nhấn mạnh "minimal manual intervention", đáp án gần như luôn là tính năng có sẵn (native feature) chứ không phải một pipeline hay đoạn code do mình viết.

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

B — Bật cross-region replication (CRR) trên S3 bucket.

CRR là tính năng dựng sẵn của Amazon S3 làm đúng một việc: tự động nhân bản object từ bucket nguồn sang một bucket đích ở AWS region khác. Bật lên bằng cấu hình replication trên bucket (kèm việc bật versioning và cấp IAM role cho S3), sau đó mọi object ghi vào bucket nguồn được S3 tự sao chép sang bucket đích mà không cần ai can thiệp.

Điều này khớp trọn cả hai ràng buộc của đề: dữ liệu sang được region khác (thoả yêu cầu pháp lý về data redundancy và disaster recovery), và quá trình chạy liền mạch, không cần lịch chạy, không cần code, không cần giám sát job. Đây là giải pháp AWS chỉ định sẵn cho đúng bài toán "backup S3 sang region khác".

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

A — AWS Data Pipeline chạy job hằng ngày copy sang bucket ở region khác. Đây là phương án gần đúng nhất, và nó hỏng ở hai điểm. Thứ nhất, bạn phải tự dựng và tự lên lịch một pipeline job — thêm một hệ thống phải vận hành, giám sát và xử lý khi nó chạy hỏng, tức là ngược lại với "minimal manual intervention". Thứ hai, nó chạy theo lô mỗi ngày, nên giữa hai lần chạy luôn tồn tại một khoảng dữ liệu chưa được sao lưu; với hồ sơ bệnh nhân thì đó là cửa sổ mất dữ liệu mà CRR không có.

C — Lambda function trigger bởi S3 event để copy file mới sang bucket backup. Về mặt kỹ thuật thì chạy được, và còn gần real-time hơn A. Nhưng nó bắt bạn tự viết và tự bảo trì code cho một việc mà S3 đã làm sẵn: phải lo IAM cross-region, lo retry khi copy lỗi, lo file lớn, lo trường hợp event không được xử lý. Nói cách khác, đây là bản tự chế lại CRR — nhiều việc hơn, nhiều chỗ hỏng hơn, trong khi đề đang hỏi giải pháp liền mạch nhất.

D — S3 Lifecycle policy chuyển dữ liệu sang bucket ở region khác sau một khoảng thời gian. Phương án này sai về bản chất chứ không chỉ kém tối ưu: Lifecycle policy không sao chép object sang bucket ở region khác. Nó dùng để quản lý vòng đời object trong chính bucket đó — chuyển sang storage class rẻ hơn, chuyển sang lớp lưu trữ dài hạn, hoặc xoá sau một thời hạn. Ngoài ra "sau một khoảng thời gian" cũng mâu thuẫn với nhu cầu sao lưu liên tục của đề.

📌 Điểm cần nhớ

• Đề hỏi sao lưu S3 sang region khác, tự động → nghĩ ngay tới S3 Cross-Region Replication. Đó là tính năng native đúng cho bài toán này.
• Phân biệt rõ hai họ tính năng của S3: Replication = tạo bản sao ở bucket khác (kể cả khác region); Lifecycle = quản lý vòng đời/storage class trong phạm vi bucket của nó. Đây là cặp gây nhầm quen thuộc trong đề thi.
• Khi đề nhấn mạnh "seamless", "minimal manual intervention", "fully managed", hãy ưu tiên tính năng có sẵn của dịch vụ, thay vì giải pháp tự dựng bằng Lambda hay một pipeline có lịch chạy — dù các phương án đó cũng "làm được".
• Giải pháp chạy theo lịch định kỳ luôn để lại cửa sổ dữ liệu chưa sao lưu. Với yêu cầu về disaster recovery cho dữ liệu nhạy cảm, đó là điểm yếu đủ để loại phương án.

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

Đề mô tả một doanh nghiệp gom nhiều tập dữ liệu khác nhau về một data lake trên Amazon S3, và trong lúc khảo sát ban đầu thì phát hiện có bản ghi trùng lặp. Câu hỏi là: cách nào hiệu quả nhất để đội dữ liệu loại bỏ phần dữ liệu trùng đó.

Cụm từ quyết định là "the most efficient method" — trong bối cảnh đề thi Data Engineer, "efficient" ở đây hiểu theo nghĩa ít công sức vận hành nhất (least operational overhead), chứ không phải chạy nhanh nhất về mặt CPU. Cả bốn phương án đều xoay quanh việc xử lý dữ liệu nằm trên S3, nên thứ phân biệt chúng không phải là "có làm được không" mà là phải tự viết và tự bảo trì bao nhiêu, và dịch vụ được nêu có đúng là dịch vụ dùng để biến đổi dữ liệu hay không.

Cụm thứ hai đáng chú ý là "remove dataset redundancies" — tức là phải thay đổi dữ liệu, chứ không chỉ tìm ra chỗ trùng. Ràng buộc này loại thẳng những phương án chỉ đọc được mà không ghi được.

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

Đáp án đúng theo tệp là D — Use AWS Glue with built-in deduplication transformations to clean the data.

AWS Glue là dịch vụ ETL được quản lý (managed), sinh ra đúng cho việc discover, chuẩn bị và kết hợp dữ liệu phục vụ analytics, machine learning và ứng dụng. Quan trọng nhất với câu này: Glue có sẵn các built-in transform, trong đó có DropDuplicates, làm đúng việc bỏ bản ghi trùng mà không cần viết code riêng.

Ghép hai vế lại đúng với ràng buộc của đề: Glue vừa đọc được dữ liệu trên S3, vừa ghi lại kết quả đã làm sạch — nó là một dịch vụ transform thực thụ. Và vì transform là dựng sẵn chứ không phải code tự viết, đội dữ liệu không phải gánh chi phí phát triển lẫn bảo trì. Đó chính là nghĩa của "most efficient" trong đề.

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

A — Amazon Athena chạy SQL để tìm và xoá bản ghi trùng. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì Athena thật sự viết được câu SQL chỉ ra bản ghi nào bị trùng. Chỗ nó hỏng nằm ở nửa sau của câu: Athena là dịch vụ truy vấn, không phải dịch vụ ETL, và bản thân nó không tự sửa hay xoá dữ liệu gốc trên S3. Muốn dùng Athena để dedup thật thì phải thêm bước ghi kết quả ra chỗ mới rồi ghi đè dữ liệu cũ — tức là thêm bước, thêm phần phải tự dựng và tự quản. Càng nhiều bước thủ công thì càng xa yêu cầu "most efficient".

B — Tạo Amazon S3 Lifecycle policy để tự động dedup. Sai về bản chất chức năng. Lifecycle policy dùng để quản lý vòng đời của object: chuyển object sang storage class khác, hoặc xoá object sau một khoảng thời gian. Nó làm việc ở mức object và mức thời gian, hoàn toàn không có khả năng nhìn vào nội dung bên trong để so sánh bản ghi. Đây không phải là "kém hiệu quả hơn" — nó đơn giản là không làm được việc mà đề hỏi.

C — Viết AWS Lambda với code Python tự loại trùng trước khi đưa vào data lake. Phương án này chạy được về mặt kỹ thuật, nên nó không sai về chức năng như B. Nó hỏng ở đúng tiêu chí mà đề dùng để chấm: viết code dedup riêng nghĩa là phải phát triển nó, kiểm thử nó, rồi bảo trì nó về lâu dài. So với việc gọi một transform đã dựng sẵn trong Glue, đây là mức operational overhead cao hơn hẳn cho cùng một kết quả. Khi đề đã cho sẵn một dịch vụ managed làm đúng việc đó, chọn phương án tự viết code luôn là chọn sai.

📌 Điểm cần nhớ

• Trong đề AWS, "most efficient" / "least operational overhead" gần như luôn nghiêng về dịch vụ managed có sẵn tính năng, và luôn loại phương án "viết code tuỳ biến" khi hai bên cho cùng kết quả.
• Phân biệt rõ vai trò: Athena = truy vấn (đọc), Glue = ETL (đọc + biến đổi + ghi). Đề yêu cầu thay đổi dữ liệu thì Athena một mình không đủ.
• S3 Lifecycle policy chỉ hiểu object và thời gian, không hiểu nội dung bản ghi. Nó dùng để chuyển storage class hoặc xoá theo hạn, không bao giờ là câu trả lời cho việc làm sạch dữ liệu.
• Khi đề nói tới việc làm sạch dữ liệu cho data lake trên S3, hãy nhớ Glue có sẵn các built-in transform như DropDuplicates — biết tên transform giúp loại nhanh các phương án phải tự dựng.

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

Đề mô tả một công ty dịch vụ tài chính chạy ứng dụng trên Amazon EC2 trong một VPC, và cần gọi tới các bảng Amazon DynamoDB. Yêu cầu nghiệp vụ được nêu rất rõ ràng ở một cụm từ: "all traffic to their DynamoDB tables remains within the AWS network and does not traverse the public internet" — toàn bộ lưu lượng phải nằm trong mạng AWS và không được đi qua Internet công cộng.

Cụm từ quyết định thứ hai là "connect its EC2 instances to DynamoDB": hai đầu của kết nối đều nằm trong AWS. Không có mạng on-premises nào trong đề, không có data center nào cần nối vào. Đây chính là ràng buộc gạt bỏ ba phương án còn lại, vì cả ba đều là công cụ để nối AWS với một mạng bên ngoài, hoặc để đi ra Internet — chứ không phải để giữ lưu lượng ở lại bên trong.

DynamoDB là một dịch vụ AWS có endpoint công khai; mặc định, EC2 gọi tới nó qua địa chỉ dịch vụ công khai. Câu hỏi đang hỏi: dùng cái gì để chuyển đường đi đó vào mạng riêng của AWS.

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

A — Implement AWS PrivateLink to privately connect the VPC to DynamoDB.

AWS PrivateLink là cơ chế cung cấp kết nối riêng tư giữa VPC và các dịch vụ AWS ngay trên hạ tầng mạng của AWS. Khi dùng PrivateLink (VPC endpoint) cho DynamoDB, lời gọi từ EC2 instance trong VPC đi thẳng tới DynamoDB qua mạng AWS mà không ra Internet công cộng — đúng nguyên văn yêu cầu tuân thủ mà đề nêu.

Đây cũng là mô hình duy nhất trong bốn phương án khiến lưu lượng ở lại bên trong: instance không cần địa chỉ IP công khai, không cần internet gateway, và không cần thiết bị NAT nào để gọi DynamoDB. Tài liệu tham chiếu của đề chính là trang VPC endpoints cho DynamoDB.

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

B — Establish a VPN connection between the VPC and DynamoDB. VPN dùng để tạo đường hầm mã hoá giữa VPC và một mạng khác, điển hình là mạng on-premises, và đường hầm đó thường chạy trên chính Internet. DynamoDB là một dịch vụ AWS được quản lý, không phải một mạng có thể làm đầu kia của VPN — không có gateway phía DynamoDB để bạn thiết lập kết nối tới. Phương án này sai cả về đối tượng lẫn về đường đi.

C — Use AWS Direct Connect to link the VPC to DynamoDB. Đây là phương án dễ nhầm nhất, vì Direct Connect đúng là đường truyền riêng không đi qua Internet. Nhưng vai trò của nó là nối môi trường on-premises với AWS bằng đường vật lý chuyên dụng. Trong đề, ứng dụng đã chạy trên EC2 bên trong VPC rồi — không có mạng bên ngoài nào cần kéo vào. Dựng Direct Connect ở đây là giải quyết một bài toán không tồn tại, tốn kém và vẫn không giải quyết chuyện lưu lượng EC2 → DynamoDB đi đường nào.

D — Configure a NAT Gateway in the VPC for secure communication with DynamoDB. NAT Gateway cho phép instance ở private subnet đi ra Internet (hoặc tới endpoint công khai của dịch vụ AWS) mà không lộ IP vào. Điểm hỏng nằm ở chữ "đi ra": lưu lượng vẫn rời VPC qua internet gateway và tới endpoint công khai của DynamoDB. NAT Gateway che giấu instance, chứ không giữ traffic trong mạng AWS — nó vi phạm thẳng yêu cầu "does not traverse the public internet". Chọn D là nhầm giữa ẩn nguồn gọi và thay đổi đường đi.

📌 Điểm cần nhớ

• Khi đề nói "traffic phải ở trong mạng AWS, không qua public internet" mà cả hai đầu đều nằm trong AWS, câu trả lời gần như luôn là VPC endpoint / PrivateLink, không phải VPN hay Direct Connect.
• Phân biệt theo hai đầu của kết nối: Direct Connect và VPN nối on-premises ↔ AWS; PrivateLink nối VPC ↔ dịch vụ AWS. Đề không nhắc data center thì loại ngay hai cái đầu.
• NAT Gateway không phải giải pháp riêng tư. Nó chỉ cho phép ra Internet từ private subnet; traffic vẫn ra Internet. Đây là cái bẫy được lặp lại rất nhiều trong domain bảo mật.
• Có VPC endpoint thì instance ở private subnet gọi được DynamoDB mà không cần internet gateway hay NAT — nhận ra điều này giúp loại phương án D nhanh mà không phải đọc kỹ.

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

Đề mô tả một công ty fintech xây hệ thống phát hiện gian lận theo thời gian thực: dữ liệu giao dịch đổ về liên tục với khối lượng lớn, và hệ thống phải thu nhận, xử lý, phân tích ngay khi giao dịch xảy ra để cảnh báo tức thì.

Cụm từ quyết định đáp án nằm ở chính câu hỏi cuối: "capturing and processing this high-volume, real-time transaction data", cộng với "process and analyze large streams of transaction data as they occur" và "detect and alert ... instantly".

Ba tín hiệu này ghép lại cho ra một yêu cầu rất cụ thể: cần một streaming service — thứ nhận dữ liệu liên tục theo dòng, cho phép nhiều consumer đọc và phân tích gần như tức thì. Đây không phải bài toán xếp hàng công việc (queue), không phải bài toán lưu trữ rồi phản ứng theo sự kiện, và cũng không phải bài toán bắt thay đổi trên một bảng dữ liệu.

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

A — Amazon Kinesis Data Streams.

Kinesis Data Streams được thiết kế đúng cho tình huống này: nó là dịch vụ real-time data streaming, thu nhận và lưu tạm dòng dữ liệu liên tục từ rất nhiều nguồn phát cùng lúc với thông lượng rất lớn, rồi cho ứng dụng tiêu thụ đọc và xử lý gần như ngay lập tức.

Hai đặc điểm khớp thẳng vào yêu cầu của đề:

• Nạp dữ liệu liên tục, thông lượng cao: đúng với "large streams ... high-volume" mà hệ thống giao dịch fintech tạo ra.
• Phân tích và phản ứng ngay trên dòng dữ liệu: đúng với "detect and alert ... instantly" — dữ liệu vừa vào stream là ứng dụng phát hiện gian lận đã đọc và chấm điểm được, không cần chờ gom lô hay chờ ghi xuống nơi lưu trữ.

Nói ngắn gọn: đề hỏi capture + process real-time stream, và đó chính là mô tả nhiệm vụ của Kinesis Data Streams.

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

B — Amazon SQS. Đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. SQS là message queue: nó nhận thông điệp, giữ lại, giao cho consumer xử lý rồi thông điệp bị xoá khỏi hàng chờ. Nó rất tốt cho việc tách rời (decouple) và mở rộng các microservice hay ứng dụng serverless — nhưng đó là mô hình messaging, không phải mô hình streaming analytics. Điểm khác biệt cốt lõi: queue hướng tới "mỗi việc được xử lý một lần rồi biến mất", còn phát hiện gian lận cần đọc dòng dữ liệu theo thứ tự, có thể nhiều ứng dụng cùng phân tích một dòng, và đọc lại được. SQS không được tối ưu cho việc phân tích thời gian thực trên dòng dữ liệu như Kinesis Data Streams.

C — DynamoDB + DynamoDB Streams. Nghe cũng có vẻ hợp lý vì tên nó có chữ "Streams", nhưng bản chất khác hẳn. DynamoDB Streams bắt thay đổi item trong một bảng DynamoDB — nó là cơ chế change data capture gắn liền với bảng, dùng khi trọng tâm là "phản ứng với việc dữ liệu trong bảng vừa bị đổi". Ở đây trọng tâm là thu nhận thẳng một dòng giao dịch khối lượng lớn từ ngoài vào để phân tích, chứ không phải theo dõi biến động của một bảng. Dùng cách này bạn còn phải ghi mọi giao dịch vào DynamoDB trước rồi mới xử lý được — thêm một chặng không cần thiết, và DynamoDB Streams không được thiết kế cho khối lượng streaming lớn kiểu này.

D — Amazon S3 event notifications. S3 trước hết là dịch vụ lưu trữ đối tượng. Event notification chỉ phát tín hiệu khi có sự kiện như đối tượng được tạo — nghĩa là dữ liệu phải được gom thành file và ghi lên S3 xong thì mới có gì để kích hoạt. Cách làm này về bản chất là xử lý theo lô (mỗi object là một lô), nên không đạt được độ trễ thấp mà việc phát hiện gian lận tức thì đòi hỏi.

📌 Điểm cần nhớ

• Gặp cụm "real-time" + "streaming data" + "high volume" trong đề, hãy nghĩ ngay tới Kinesis Data Streams — đó là dịch vụ chuyên trách thu nhận và xử lý dòng dữ liệu thời gian thực.
• Phân biệt queue và stream: SQS là hàng chờ công việc, thông điệp được xử lý rồi rời hàng; stream là dòng dữ liệu có thứ tự, nhiều consumer cùng đọc được và đọc lại được. Đề nói "analyze streams" là dấu hiệu chọn stream, không phải queue.
• DynamoDB Streams ≠ streaming ingestion: nó là change data capture cho một bảng DynamoDB, chỉ hợp khi yêu cầu là phản ứng với thay đổi trong bảng đó.
• S3 event notification là mô hình theo lô/theo sự kiện lưu trữ, không phải nền tảng xử lý thời gian thực — cứ thấy đề nhấn mạnh độ trễ tức thì thì loại phương án dựa trên "ghi file lên S3 rồi kích hoạt".

Đáp án

C — Public Subnet

Vì sao đúng

Một subnet được coi là public khi bảng định tuyến của nó có đường mặc định 0.0.0.0/0 trỏ tới Internet Gateway. Đó là điều kiện bắt buộc để máy chủ web nhận được kết nối từ Internet. Máy chủ còn cần một địa chỉ IP công khai (Elastic IP hoặc IP tự cấp) thì người ngoài mới gọi tới được.

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

• A. Isolated Subnet — không có đường ra Internet theo cả hai chiều, hợp cho CSDL nội bộ.
• B. VPN-only Subnet — chỉ tới được qua Virtual Private Gateway, tức là từ mạng nội bộ của doanh nghiệp, không phải từ Internet công cộng.
• D. Private Subnet — ra Internet được qua NAT Gateway nhưng chỉ một chiều; kết nối từ ngoài vào bị chặn, nên máy chủ web sẽ không ai truy cập được.

Nhớ nhanh

Public = có đường tới Internet Gateway. Private = ra được, vào không được.

Đáp án

B — Nhiều node, có cả primary shard và replica shard

Vì sao đúng

Trong OpenSearch, primary shard chia nhỏ dữ liệu để phân tán qua nhiều node — đó là phần trả lời cho yêu cầu "rải tài liệu qua nhiều node". Replica shard là bản sao của primary đặt trên node khác, và điểm mấu chốt: replica phục vụ được truy vấn đọc. Nhờ vậy tải đọc được chia đều và cụm vẫn đọc được khi mất một node — đúng hai yêu cầu "nhanh" và "không hỏng".

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

• A. Một node với replica — OpenSearch không đặt replica cùng node với primary của nó, nên trên cụm một node thì replica luôn ở trạng thái unassigned, cụm báo vàng.
• C. Cold storage cho truy vấn đọc — cold storage dành cho dữ liệu ít đụng tới, phải gắn lại trước khi truy vấn được; ngược hẳn với yêu cầu đọc nhanh.
• D. Chỉ primary shard — mất một node là mất luôn phần dữ liệu nằm trên đó.

Nhớ nhanh

Primary chia dữ liệu, replica vừa đỡ tải đọc vừa chống mất node.