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

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

Đề mô tả một dịch vụ streaming dùng Amazon S3 vừa để phát nội dung, vừa làm data lake. Trong data lake có một "staging zone" chứa kết quả truy vấn trung gian (intermediary query results), và câu hỏi là chọn storage class MOST cost-effective cho đúng phần dữ liệu này.

Hai cụm từ trong đề quyết định đáp án, và phải đọc cả hai cùng lúc:

1. "kept only for 24 hours" — dữ liệu chỉ tồn tại một ngày rồi bị xoá.
2. "heavily referenced by other parts of the analytics pipeline" — nó bị đọc lại rất nhiều lần trong quãng thời gian ngắn đó.

Bẫy ở đây là chữ "cost-effective" khiến người làm bài phản xạ chọn class có giá lưu trữ trên GB rẻ nhất. Nhưng giá lưu trữ chỉ là một phần hoá đơn S3: các class "lạnh" còn tính minimum storage duration (trả tiền tối thiểu cho một khoảng thời gian, dù bạn xoá sớm hơn) và retrieval fee (tính tiền mỗi lần lấy dữ liệu ra). Đúng hai khoản đó là thứ dữ liệu "sống 24 giờ, bị đọc liên tục" vi phạm nặng nhất.

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

Đáp án đúng là D — S3 Standard.

S3 Standard dành cho dữ liệu truy cập thường xuyên, độ trễ thấp và throughput cao, phù hợp với big data analytics — đúng mô tả của staging zone trong đề. Điều quyết định là hai đặc điểm về tính phí:

• Không có minimum storage duration charge: giữ 24 giờ thì trả tiền đúng 24 giờ, không bị làm tròn lên một chu kỳ tối thiểu.
• Không có retrieval fee: dữ liệu bị các bước sau của pipeline đọc lại bao nhiêu lần cũng không phát sinh phí lấy dữ liệu theo GB.

Giá lưu trữ trên GB của S3 Standard cao hơn các class IA/Glacier, nhưng với vòng đời 24 giờ thì phần lưu trữ gần như không đáng kể, trong khi phần bị phạt vì lưu tối thiểu và phí đọc lại mới là khoản chi phối. Cộng cả hoá đơn lại, S3 Standard là lựa chọn rẻ nhất trong bốn phương án đã cho.

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

A — S3 Standard-Infrequent Access. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì Standard-IA có cùng độ trễ mili-giây và throughput như S3 Standard, chỉ rẻ hơn ở giá lưu trữ. Nó hỏng ở đúng hai chỗ mà đề nhấn mạnh: minimum storage duration là 30 ngày, nên dữ liệu chỉ giữ 24 giờ vẫn bị tính tiền như lưu đủ 30 ngày; và mỗi lần đọc đều có phí truy xuất theo GB, mà đề nói rõ dữ liệu bị tham chiếu rất nhiều. Standard-IA đúng cho backup, lưu trữ dài hạn, dữ liệu DR — tức là "lưu lâu, ít đọc", ngược hoàn toàn với tình huống này.

C — S3 One Zone-Infrequent Access. Kế thừa toàn bộ nhược điểm của Standard-IA trong ngữ cảnh này: vẫn minimum storage duration 30 ngày, vẫn có phí truy xuất. Điểm khác biệt duy nhất của nó là lưu dữ liệu trong một Availability Zone thay vì tối thiểu ba AZ, đổi độ bền lấy giá lưu trữ thấp hơn Standard-IA. Nhưng cái rẻ hơn đó nằm ở khoản không quan trọng, còn hai khoản gây tốn kém thì vẫn nguyên. Chọn nó là hy sinh khả năng chịu lỗi mà không cứu được chi phí.

B — S3 Glacier Instant Retrieval. Nhãn "Instant Retrieval" khiến nhiều người tưởng nó dùng được cho dữ liệu nóng, và đúng là nó cho truy cập mili-giây như S3 Standard. Nhưng bản chất nó là archive storage: minimum storage duration lên tới 90 ngày — dài nhất trong bốn phương án — nên giữ 24 giờ là đắt nhất theo tỷ lệ, chưa kể phí truy xuất. Nó hợp với dữ liệu lưu trữ dài hạn mà thỉnh thoảng cần lấy ngay: ảnh y tế, tư liệu báo chí, kho nội dung người dùng — không phải kết quả truy vấn tạm sống một ngày.

📌 Điểm cần nhớ

• "Cost-effective" không đồng nghĩa với "giá lưu trữ trên GB thấp nhất." Hoá đơn S3 gồm ba phần: lưu trữ, minimum storage duration, và phí truy xuất. Đọc đề xem phần nào chiếm ưu thế rồi mới chọn.
• Bắt cụm từ về vòng đời dữ liệu trong đề. Dữ liệu sống ngắn hơn minimum storage duration của một class thì class đó tự động bị loại: Standard-IA và One Zone-IA có mức tối thiểu 30 ngày, Glacier Instant Retrieval là 90 ngày, S3 Standard không có.
• Bắt cụm từ về tần suất đọc. "Heavily referenced", "frequently accessed", "read by multiple downstream jobs" là tín hiệu loại mọi class có retrieval fee, kể cả khi class đó vẫn cho truy cập tức thời.
• One Zone-IA chỉ khác Standard-IA ở độ bền, không khác ở cách tính phí thời gian tối thiểu. Nếu Standard-IA đã sai vì lý do vòng đời hoặc phí đọc, thì One Zone-IA cũng sai vì đúng lý do ấy.
• "Instant Retrieval" nói về độ trễ, không nói về mô hình chi phí. Glacier Instant Retrieval vẫn là tầng archive và vẫn ràng buộc lưu trữ tối thiểu rất dài.

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

Đề mô tả một công ty truyền thông thu thập browsing metadata: mỗi lần tải trang sinh ra nhiều event, mỗi event phải lưu riêng lẻ, và mỗi lần tải trang lại phải truy vấn lịch sử duyệt web của người dùng để đưa ra gợi ý. Quy mô trên 1 triệu lượt truy cập mỗi ngày.

Nhưng toàn bộ phần mô tả đó chỉ là bối cảnh. Cụm từ quyết định nằm ở câu cuối và câu hỏi:

"wants to add a caching layer to support high read volumes" — "Which of the following AWS services would you recommend as a caching layer?"

Đây là chỗ phân biệt: đề không hỏi lưu dữ liệu ở đâu, không hỏi phân tích thế nào, không hỏi tìm kiếm ra sao. Nó hỏi dịch vụ nào đóng vai trò cache. Vì vậy mọi phương án là data store, data warehouse hay search engine đều bị loại ngay, dù chúng có thể xuất hiện hợp lý trong kiến trúc tổng thể của bài toán này. Thêm một ràng buộc phụ: (Select two) — phải có đúng hai dịch vụ trong danh sách thực sự là caching layer.

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

A. ElastiCache — đây là dịch vụ cache in-memory được quản lý của AWS. Nó được thiết kế đúng cho vai trò "middle tier" đặt trước một data store như RDS hay DynamoDB, phục vụ các ứng dụng có tốc độ request rất cao và yêu cầu độ trễ thấp. Với kịch bản đọc lịch sử duyệt web ở mỗi lần tải trang, đặt ElastiCache trước tầng lưu trữ giúp phần lớn lượt đọc được phục vụ từ bộ nhớ thay vì đi xuống database.

C. DynamoDB Accelerator (DAX) — là in-memory cache được quản lý toàn phần, có tính sẵn sàng cao, dành riêng cho DynamoDB. DAX đưa độ trễ đọc từ mức mili giây xuống mức micro giây và chịu được lượng request rất lớn. Điểm mạnh so với tự dựng cache: DAX lo giúp phần cache invalidation, nạp dữ liệu và quản lý cluster, nên ứng dụng gần như không phải sửa logic để hưởng lợi.

Cả hai đều là in-memory caching layer, đúng thứ mà đề yêu cầu — nên đây là hai đáp án được chọn.

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

B. Redshift — là data warehouse quy mô petabyte, phục vụ phân tích trên tập dữ liệu lớn với các truy vấn quét nhiều dữ liệu. Nó tối ưu cho analytics, không phải cho việc trả về một bản ghi cụ thể với độ trễ cực thấp ở mỗi lần tải trang. Đây không phải một caching layer.

D. RDS — là relational database được quản lý. Đây chính là nguồn dữ liệu mà người ta thường đặt cache ở phía trước, chứ bản thân nó không đóng vai trò cache. Đúng là RDS cũng có bộ nhớ đệm nội bộ và có thể thêm read replica để san tải đọc, nhưng "read replica" và "caching layer" là hai khái niệm khác nhau: cache là tầng in-memory riêng biệt đặt trước data store, còn read replica vẫn là một bản sao database đầy đủ. Đề hỏi caching layer nên RDS bị loại.

E. Elasticsearch — là search engine dựng trên thư viện Lucene, cung cấp full-text search phân tán trên các tài liệu JSON không cần schema cố định. Đây là phương án dễ gây phân vân nhất vì nó cũng nhanh và cũng phục vụ đọc nhiều — nhưng chức năng của nó là đánh chỉ mục và tìm kiếm, không phải lưu tạm kết quả truy vấn để giảm tải cho data store phía sau. Dùng nó thay cache là dùng sai công cụ: bạn được search engine chứ không được một tầng cache.

📌 Điểm cần nhớ

• Khi đề nói thẳng "caching layer", hãy đọc danh sách phương án theo đúng một tiêu chí: dịch vụ này có phải in-memory cache không? Bối cảnh phía trên (số lượt truy cập, kiểu dữ liệu) thường chỉ để đánh lạc hướng.
• Trong hệ sinh thái AWS, hai cái tên gắn với vai trò cache là ElastiCache (cache chung, đặt trước RDS/DynamoDB hay bất kỳ data store nào) và DAX (cache chuyên biệt, chỉ dành cho DynamoDB).
• Phân biệt rõ ba vai trò dễ bị trộn lẫn: data store (RDS, DynamoDB), data warehouse/analytics (Redshift), search (Elasticsearch). Không cái nào trong ba nhóm này là caching layer, dù cả ba đều "đọc nhanh" theo nghĩa nào đó.
• Chú ý số lượng đáp án phải chọn. (Select two) là ràng buộc cứng — nếu bạn thấy ba dịch vụ đều "hợp lý", nghĩa là bạn đang chấm theo tiêu chí rộng hơn tiêu chí mà đề nêu.

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

Một công ty dịch vụ tài chính vừa chuyển từ hạ tầng on-premises lên AWS Cloud. Đội data engineering cần một giải pháp làm được hai việc cùng lúc:

1. Rà soát cấu hình (resource configurations) của tất cả tài nguyên để bảo đảm chúng tuân thủ compliance guidelines.
2. Xem được lịch sử cấu hình (resource configuration history) trên toàn bộ application stack.

Cụm từ quyết định đáp án là "resource configuration history" — lịch sử cấu hình của tài nguyên, chứ không phải lịch sử hoạt động của tài khoản và cũng không phải số liệu hiệu năng. Đây chính là điểm phân biệt giữa bốn dịch vụ trong danh sách phương án: cả bốn đều là dịch vụ vận hành/quản trị, nhưng chỉ một dịch vụ trả lời được câu hỏi "tài nguyên này trông như thế nào tại thời điểm xyz?".

Cụm thứ hai đáng chú ý là "meet compliance guidelines" — nghĩa là cần đánh giá cấu hình hiện tại so với một bộ quy tắc nội bộ, chứ không chỉ ghi lại thay đổi.

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

Đáp án C — Use AWS Config.

AWS Config là dịch vụ chuyên để assess, audit và evaluate cấu hình của các AWS resource. Nó khớp chính xác với cả hai yêu cầu trong đề:

• Compliance: AWS Config đánh giá cấu hình tài nguyên so với bộ quy tắc mà tổ chức định nghĩa, từ đó xác định mức độ tuân thủ tổng thể — đúng với yêu cầu "meet compliance guidelines".
• Configuration history: AWS Config lưu lại các thay đổi cấu hình và cả mối quan hệ giữa các AWS resource, cho phép đi sâu vào lịch sử cấu hình chi tiết của từng tài nguyên. Nói cách khác, nó trả lời được câu hỏi "What did my AWS resource look like at xyz point in time?" — đúng nghĩa "look into the resource configuration history across the application stack".

Vì cùng một dịch vụ đáp ứng trọn vẹn cả hai vế, C là lựa chọn duy nhất không cần ghép thêm gì.

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

A. Amazon CloudWatch — CloudWatch cung cấp dữ liệu và insight để monitor ứng dụng, phản ứng với thay đổi hiệu năng toàn hệ thống, tối ưu mức sử dụng tài nguyên và có cái nhìn thống nhất về operational health. Nó làm việc với metric, log và alarm, tức là trạng thái vận hành theo thời gian — không phải trạng thái cấu hình. Bạn không thể dùng CloudWatch để lưu giữ lịch sử thay đổi cấu hình tài nguyên. Đây là phương án dễ nhầm vì CloudWatch cũng có yếu tố "theo dõi theo thời gian", nhưng thứ nó theo dõi hoàn toàn khác.

B. AWS Systems Manager — Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì Systems Manager cho phép nhóm tài nguyên (EC2 instance, S3 bucket, RDS instance) theo ứng dụng, xem operational data để giám sát – khắc phục sự cố, và thao tác trên các nhóm tài nguyên đó. Chữ "across the application stack" trong đề nghe rất giống việc gom nhóm theo ứng dụng của Systems Manager. Nhưng nó hỏng ở đúng vế quan trọng: Systems Manager thiên về vận hành và quản trị tài nguyên, chứ không phải nơi lưu giữ lịch sử thay đổi cấu hình của tài nguyên.

D. AWS CloudTrail — Phương án gây nhầm mạnh nhất với C, vì CloudTrail cũng phục vụ governance, compliance, operational auditing và risk auditing. CloudTrail log, giám sát liên tục và lưu giữ account activity liên quan tới các hành động trên hạ tầng AWS — nó trả lời câu hỏi "Ai đã gọi API để sửa tài nguyên này?". Đó là event history của hoạt động tài khoản, tức là ai làm gì, lúc nào. Khác hẳn với thứ đề bài đang hỏi: trạng thái cấu hình của tài nguyên tại một thời điểm. Bạn không thể dùng CloudTrail để duy trì lịch sử cấu hình tài nguyên.

📌 Điểm cần nhớ

• Bộ ba hay bị hỏi so sánh — nhớ theo từ khoá: resource performance monitoring, events, alerts → Amazon CloudWatch; account-specific activity và audit → AWS CloudTrail; resource-specific history, audit và compliance → AWS Config.
• Phân biệt hai câu hỏi rất giống nhau: "Ai đã đổi tài nguyên này?" là CloudTrail; "Tài nguyên này trông thế nào tại thời điểm xyz?" là AWS Config.
• Khi đề nhắc tới configuration history và đánh giá tuân thủ theo bộ quy tắc, hãy nghĩ ngay tới AWS Config — dịch vụ này còn theo dõi cả quan hệ giữa các tài nguyên, nên phù hợp với phạm vi "across the application stack".
• AWS Systems Manager gom nhóm và vận hành tài nguyên theo ứng dụng, nhưng đừng để chữ "application stack" kéo bạn chọn nó khi yêu cầu thật là lưu giữ lịch sử cấu hình.

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

Đề mô tả một workflow AWS Step Functions cho hệ thống ngân hàng, và yêu cầu chọn state phù hợp.

Cụm từ quyết định đáp án là: "process large amounts of data files in parallel" kết hợp với "apply transformations for each file".

Hai ý này phải đọc chung với nhau:

• "for each file" — cùng một logic xử lý được áp dụng lặp lại cho từng phần tử trong một tập dữ liệu. Đây là vòng lặp trên dataset, không phải các nhánh công việc khác nhau.
• "in parallel" — các lần lặp đó chạy đồng thời chứ không tuần tự.

Ràng buộc phân biệt nằm ở chỗ: cùng một bước xử lý, nhiều dữ liệu khác nhau. Đây chính là điểm tách Map khỏi Parallel — cả hai đều chạy song song, nhưng chúng song song hoá hai thứ khác nhau.

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

C — Map state.

Map state dùng để chạy một tập các bước workflow cho từng item trong một dataset. Các iteration của Map chạy song song với nhau, nên xử lý được một khối lượng dữ liệu lớn trong thời gian ngắn — đúng hai yêu cầu mà đề nêu.

Map nhận nhiều kiểu đầu vào khác nhau, trong đó có danh sách object trong Amazon S3 và file CSV, ngoài JSON array. Đây là chi tiết khớp trực tiếp với đề bài "data files": tập file chính là dataset để lặp.

Step Functions cho Map hai chế độ xử lý:

• Inline mode (mặc định): chỉ nhận JSON array làm input, và số iteration đồng thời bị giới hạn ở mức tương đối thấp.
• Distributed mode: dành cho xử lý đồng thời ở quy mô lớn. Mỗi item được xử lý bằng một child workflow execution riêng, có execution history tách khỏi workflow cha, và số child execution chạy song song là cấu hình được.

Với "large amounts of data files", distributed mode chính là chế độ được thiết kế cho tình huống này.

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

B — Parallel state. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Parallel cũng chạy đồng thời, nhưng nó song song hoá các nhánh (branch) khác nhau đã được định nghĩa cứng trong state machine: mỗi branch bắt đầu từ state ghi trong trường StartAt của branch đó, và Parallel chờ tất cả branch kết thúc rồi mới đi tới Next. Chỗ nó hỏng: số nhánh là cố định lúc thiết kế workflow, còn số file cần xử lý thì thay đổi theo dữ liệu chạy thực tế. Parallel hợp khi bạn có nhiều việc khác nhau làm cùng lúc; đề này lại là một việc giống nhau lặp trên nhiều file.

D — Choice state. Choice thêm logic điều kiện vào state machine. Nó chứa một mảng Choice Rules, dùng comparison operator so sánh biến đầu vào với một giá trị cụ thể để quyết định chuyển sang state nào tiếp theo. Nó chỉ rẽ nhánh, hoàn toàn không có khả năng lặp và cũng không tạo ra bất kỳ mức độ đồng thời nào.

A — Concurrent state. State này không tồn tại trong Amazon States Language. Đây là phương án bịa ra để đánh lừa người đọc lướt — chữ "concurrent" nghe rất khớp với "in parallel" trong đề, nên nó dễ được chọn theo phản xạ từ khoá.

📌 Điểm cần nhớ

• "For each item / for each file" → Map. Từ khoá "cho từng phần tử" gần như luôn trỏ về Map state.
• Phân biệt Map với Parallel bằng câu hỏi: song song hoá cái gì? Map = một logic, nhiều dữ liệu (số lần lặp do dữ liệu quyết định). Parallel = nhiều logic khác nhau, số nhánh cố định trong định nghĩa workflow.
• Map có hai mode. Inline là mặc định, chỉ nhận JSON array và mức đồng thời hạn chế; distributed mode dành cho khối lượng lớn, chạy mỗi item như một child workflow execution có history riêng. Đề nhắc "large amounts" là tín hiệu của distributed mode.
• Cảnh giác với phương án nghe khớp từ khoá trong đề. "Concurrent state" không phải là một state có thật; hãy đối chiếu với danh sách state thực của Amazon States Language (Task, Choice, Parallel, Map, Wait, Pass, Succeed, Fail) thay vì chọn theo cảm giác ngôn ngữ.

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

Đề mô tả một công ty đã phình từ startup nhỏ lên hơn 1000 nhân viên, và gần đây cài đặt của Amazon S3 bucket bị thay đổi thường xuyên mà không rõ ai làm. Câu hỏi đặt ra: làm sao tìm ra chuyện gì đang xảy ra?

Cụm từ quyết định nằm ở cuối câu hỏi: "without restricting the rights of the users" — không được siết quyền của người dùng. Kèm theo đó là động từ "figure out what's happening", tức là mục tiêu ở đây là điều tra, truy vết, không phải ngăn chặn.

Hai chi tiết này cùng lúc loại bỏ mọi phương án mang tính phòng thủ (chặn quyền, bắt buộc MFA), vì chúng đều thay đổi quyền hoặc điều kiện truy cập của người dùng. Cái còn lại phải là một cơ chế ghi nhật ký/kiểm toán thụ động, chạy ngầm, không ai bị ảnh hưởng.

Chi tiết thứ hai để phân biệt hai phương án ghi log với nhau: đề nói rõ thứ bị đổi là bucket settings — tức là các thao tác quản trị cấu hình bucket, chứ không phải chuyện ai đọc/ghi object.

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

A. Use AWS CloudTrail to analyze the API calls made to Amazon S3

AWS CloudTrail ghi lại lịch sử API call trong tài khoản AWS, phục vụ governance, compliance và auditing. Nó ghi nhận hành động được thực hiện qua AWS Management Console, AWS SDK, command-line tools và cả từ các dịch vụ AWS khác — kèm theo thông tin ai (user/role) làm, làm gì, lúc nào.

Đúng với tình huống trong đề vì:

• Đổi bucket settings chính là các API call quản trị (kiểu Put... trên cấu hình bucket) — đây đúng là loại sự kiện CloudTrail sinh ra để ghi lại.
• CloudTrail là cơ chế quan sát: bật lên không ai mất quyền gì, đúng với ràng buộc "without restricting the rights of the users", và kẻ đang nghịch cấu hình cũng không nhận ra mình đang bị theo dõi.
• AWS khuyến nghị dùng CloudTrail để ghi log các hành động ở mức bucket và mức object cho tài nguyên S3, vì nó cho nhiều lựa chọn hơn để lưu trữ, phân tích và hành động dựa trên log.

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

B. Implement an IAM policy to forbid users from changing Amazon S3 bucket settings

Sai vì đây chính là thứ đề bài cấm. IAM policy là đối tượng gắn vào identity (user, group, role) hoặc resource để định nghĩa quyền; AWS đánh giá policy mỗi khi một principal gửi request và quyết định cho phép hay từ chối. Cấm người dùng đổi bucket settings đúng là siết quyền — vi phạm trực tiếp "without restricting the rights of the users". Ngoài ra nó còn gây gián đoạn công việc hợp lệ, và người bị chặn sẽ nhận ra ngay, nên cũng không giúp bạn biết được ai đang làm chuyện đó.

C. Use Amazon S3 access logs to analyze user access using Athena

Đây là phương án gần đúng nhất, và nó hỏng ở chỗ tinh tế. S3 server access logging cũng là cơ chế ghi log thụ động, cũng không siết quyền ai, và log đó phân tích bằng Athena được — đến đây vẫn hợp lý. Nhưng server access logging thiên về ghi nhận các request đến bucket (hữu ích để audit truy cập, hiểu tệp khách hàng, đối chiếu hoá đơn S3), trong khi thứ cần truy là hành động thay đổi cấu hình bucket. AWS khuyến nghị rõ dùng CloudTrail cho việc ghi log hành động ở mức bucket và mức object, vì nó cung cấp nhiều lựa chọn hơn để lưu trữ, phân tích và phản ứng theo log. Khi đề đã hỏi "chuyện gì đang xảy ra với bucket settings", CloudTrail là công cụ được chỉ định, còn access log chỉ là lựa chọn thay thế hạng hai.

D. Implement a bucket policy requiring AWS Multi-Factor Authentication (AWS MFA) for all operations

S3 hỗ trợ MFA-protected API access — bắt người dùng chứng minh họ đang giữ thiết bị MFA bằng cách nhập mã hợp lệ, thêm một lớp bảo mật cho môi trường AWS. Nhưng đây lại là biện pháp phòng ngừa, không phải điều tra: nó làm thao tác khó hơn chứ không cho bạn biết ai đã đổi cài đặt. Nó cũng thay đổi điều kiện truy cập của toàn bộ người dùng (vi phạm ràng buộc trong đề) và chắc chắn bị phát hiện ngay lập tức, vì mọi thao tác đều đột ngột đòi mã MFA.

📌 Điểm cần nhớ

• "Ai đã làm gì trong tài khoản AWS?" → CloudTrail. Đây là phản xạ mặc định cho mọi câu hỏi dạng truy vết API call, bất kể dịch vụ nào ở phía sau.
• Phân biệt điều tra và phòng ngừa. Từ khoá kiểu "figure out", "investigate", "who changed" đòi công cụ ghi log; các phương án kiểu IAM policy, bucket policy, MFA là biện pháp chặn — đúng về bảo mật nhưng trả lời sai câu hỏi.
• Ràng buộc phụ trong đề thường là thứ loại phương án nhanh nhất. Ở đây "without restricting the rights of the users" một mình đã gạt được cả B lẫn D trước khi cần suy nghĩ sâu.
• CloudTrail vs. S3 server access logs: cả hai đều ghi log S3, nhưng AWS khuyến nghị CloudTrail cho hành động ở mức bucket và object. Server access logs nghiêng về phân tích pattern truy cập; gặp câu hỏi audit cấu hình thì chọn CloudTrail.

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

Đề mô tả một công ty lưu kết quả của truy vấn Athena CTAS (CREATE TABLE AS SELECT) xuống Amazon S3, và data engineer muốn phân biệt partitioning với bucketing khi ghi dữ liệu theo cách đó. Câu hỏi yêu cầu chọn hai phát biểu mô tả đúng trường hợp nên dùng bucketing và trường hợp nên dùng partitioning.

Cụm từ quyết định nằm ở hai chỗ trong từng phương án, không nằm ở phần mở đầu:

• cardinality (số lượng giá trị phân biệt của cột) — thấp hay cao;
• evenly distributed so với sparsely distributed (dữ liệu trải đều hay thưa thớt).

Mọi phương án đều bắt đầu bằng cùng một mệnh đề mở, khác nhau đúng ở hai tính từ này. Bốn phương án về bucketing và partitioning được ghép chéo có chủ đích, nên phải nắm chắc quy tắc: partition ⇢ low cardinality, số partition có giới hạn; bucket ⇢ high cardinality, giá trị phân bố đều.

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

D — Partitioning hợp khi số partition dự kiến là có giới hạn và cột partition có low cardinality.

Partition trong Athena được hiện thực hoá thành thư mục riêng trên S3: mỗi giá trị phân biệt của cột partition sinh ra một thư mục. Khi chạy CTAS có khai partition, Athena tạo và ghi mỗi partition vào một folder riêng trong cùng vị trí kết quả. Mục đích là để truy vấn chỉ quét đúng phần dữ liệu cần (partition pruning), giảm lượng dữ liệu quét nên nhanh hơn và rẻ hơn. Vì vậy cột partition phải là cột có ít giá trị phân biệt và các bản ghi có đặc điểm giống nhau — kiểu như phòng ban, nguồn dữ liệu, hoặc các mức thời gian year/month/date/hour. Cột có ít giá trị thì tổng số partition mới nằm trong tầm kiểm soát.

B — Bucketing hợp khi bucket theo cột có high cardinality và giá trị phân bố đều.

Bucketing không tạo thư mục theo giá trị mà băm giá trị cột rồi chia dữ liệu vào một số lượng file (bucket) cố định. Muốn các bucket có kích thước xấp xỉ nhau — điều kiện để bucketing phát huy tác dụng — thì cột dùng làm khoá bucket phải có rất nhiều giá trị phân biệt và dữ liệu trải đều trên tập dữ liệu. Ví dụ điển hình mà tài liệu nêu là cột timestamp: số giá trị phân biệt rất lớn, và dữ liệu rải đều. Cột thưa giá trị (sparsely populated) là ứng viên tồi cho bucketing.

Hai kỹ thuật này không loại trừ nhau: cùng một CTAS query có thể vừa partition vừa bucket, và thông thường cột dùng để bucket khác cột dùng để partition.

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

A — Bucketing với cột low cardinality và giá trị phân bố đều. Sai ở vế cardinality. Vế "evenly distributed" thì đúng, nên phương án này rất dễ chọn nhầm. Nhưng cột ít giá trị phân biệt khi băm sẽ chỉ rơi vào một số ít bucket, phần bucket còn lại rỗng hoặc lệch nặng — mất đúng lợi ích mà bucketing hướng tới. Đây là mô tả của cột nên đem đi partition, không phải đem đi bucket.

C — Partitioning với số partition có giới hạn nhưng cột partition có high cardinality. Phương án này tự mâu thuẫn. Vì mỗi giá trị phân biệt của cột partition sinh ra một partition, cột high cardinality tất yếu kéo theo số partition rất lớn, không thể đồng thời "limited". Nhiều partition nhỏ vụn còn làm hại: metadata phình ra và mỗi partition chỉ chứa vài file bé. Vế "number of partitions is limited" đúng nhưng vế cardinality mâu thuẫn với nó, nên cả phát biểu sai.

E — Bucketing với cột high cardinality nhưng giá trị phân bố thưa (sparsely distributed). Vế high cardinality đúng, hỏng ở vế phân bố. Tài liệu nói thẳng rằng cột thưa giá trị không phải ứng viên tốt cho bucketing: dữ liệu không chia được thành nhiều bucket có lượng dữ liệu xấp xỉ nhau, kết quả là bucket lệch kích thước và truy vấn không hưởng lợi đều. Đây là bẫy đổi đúng một từ so với đáp án B.

📌 Điểm cần nhớ

• Partition = thư mục trên S3, một giá trị một folder → chọn cột low cardinality, tổng số partition phải có giới hạn (department, data source, year/month/day/hour).
• Bucket = băm giá trị vào số file cố định → chọn cột high cardinality và phân bố đều để các bucket cân bằng nhau; cột thưa giá trị là ứng viên tồi.
• Trong đề trắc nghiệm, các phương án partitioning/bucketing thường chỉ khác nhau ở cặp từ low/high cardinality và evenly/sparsely distributed — đọc kỹ đúng hai chỗ đó trước khi loại.
• Phương án nào ghép "số partition có giới hạn" với "cột high cardinality" là tự mâu thuẫn, loại được ngay mà không cần nhớ tài liệu.
• Partitioning và bucketing dùng chung được trong cùng một CTAS query, và cột dùng cho hai việc thường khác nhau.

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

Đề mô tả một RDS MySQL DB instance bị spike CPU utilization làm ứng dụng chạy chậm, và đội data engineering đang làm root-cause analysis. Cụm từ quyết định đáp án nằm ở hai chỗ:

• "The standard metrics available in Amazon CloudWatch are not enough" — nghĩa là các metric CloudWatch mặc định của RDS (CPUUtilization, DatabaseConnections, …) đã có nhưng chỉ cho biết CPU cao bao nhiêu, không cho biết cái gì làm CPU cao. Câu hỏi đòi thứ đi sâu hơn mức metric mặc định.
• "provide more details about the underlying processes and queries" — đây là ràng buộc phân biệt. Đề đòi chẩn đoán, ở hai tầng: tầng process/thread của hệ điều hành và tầng query/session của database engine. Đề không đòi giảm tải hay khắc phục.

Bất kỳ phương án nào chỉ làm nhẹ triệu chứng mà không sinh ra dữ liệu chẩn đoán đều trượt, dù nghe có lợi cho hệ thống. Và vì chonNhieuDapAn = true với yêu cầu "Select two", hai đáp án phải bổ sung nhau chứ không trùng lặp.

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

Theo tệp, đáp án đúng là A và B.

A — Enhanced Monitoring. Enhanced Monitoring thu metric ở tầng hệ điều hành mà DB instance đang chạy trên đó, lấy từ một agent trong instance chứ không phải từ hypervisor như CloudWatch metric thường. Nhờ vậy nó cho thấy từng process/thread tiêu thụ CPU ra sao — đúng vế "underlying processes" của đề. Enhanced Monitoring có tần suất lấy mẫu chi tiết hơn metric mặc định và dữ liệu được đẩy vào CloudWatch Logs (khác với CloudWatch metrics thông thường), giữ lại một khoảng thời gian để xem lại sau sự cố.

B — RDS Performance Insights. Đây là vế "queries". Performance Insights lấy metric trung tâm là DB Load — số session đang active trung bình của DB engine, tức connection đã gửi việc và đang chờ engine trả lời. Dashboard cho phép cắt lát tải theo waits, SQL statements, hosts hoặc users, nên nhìn vào là thấy ngay câu SQL nào hoặc loại wait event nào đang đẩy tải lên trong khung giờ có spike.

Hai lựa chọn này ghép lại phủ đúng hai tầng đề hỏi: A trả lời "process nào ăn CPU", B trả lời "query/session nào gây ra tải đó".

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

C — ElastiCache đặt trước RDS. Đây là phương án gần đúng nhất và cũng là bẫy chính. Về mặt kiến trúc nó hợp lý: cache có thể chặn bớt read lặp lại và thật sự kéo CPU của RDS xuống. Nhưng nó hỏng ở chỗ sai mục tiêu: đề đòi insight về nguyên nhân, còn ElastiCache chỉ che triệu chứng — dùng chính chữ của lời giải gốc, nó là band-aid. Sau khi triển khai, bạn vẫn không biết query nào hay process nào đã gây spike, và lần sau tải đổi dạng thì vấn đề quay lại. Ngoài ra đây là thay đổi kiến trúc, không phải bước điều tra root-cause.

D — Amazon CloudWatch Events, xem event data chứa các câu SQL. Sai vì tiền đề của phương án không tồn tại. CloudWatch Events (EventBridge) mang các sự kiện thay đổi trạng thái của tài nguyên — kiểu instance đổi trạng thái, sự kiện vận hành — chứ không bao giờ chứa nội dung câu SQL đang chạy trong DB. Lời giải gốc gọi thẳng đây là made-up option: mô tả nghe trôi chảy nhưng dịch vụ không có khả năng đó.

E — Dùng Amazon Athena phân tích các câu SQL đang chạy trên RDS. Athena là interactive query service để chạy SQL chuẩn trên dữ liệu nằm ở Amazon S3, serverless, hợp cho xử lý log và phân tích ad-hoc. Có federated query nên truy vấn được dữ liệu trong RDS MySQL — chính điểm này khiến phương án nghe hợp lý. Nhưng nó hỏng ở chỗ: federated query cho phép bạn đọc dữ liệu nghiệp vụ trong RDS, chứ không cho bạn thấy hoạt động thực thi của DB engine — tức là các câu SQL đang chạy, session active và wait event. Athena nhìn dữ liệu, không nhìn tải.

📌 Điểm cần nhớ

• Phân biệt quan sát để chẩn đoán với hành động để giảm tải. Đề nói "root-cause analysis", "provide more details" thì mọi phương án kiểu thêm cache, scale up, thêm read replica đều lạc đề dù chúng có ích thật.
• Với RDS, nhớ ba tầng monitoring: CloudWatch metrics (mức instance, nhìn từ ngoài), Enhanced Monitoring (mức OS, process/thread, đẩy vào CloudWatch Logs), Performance Insights (mức DB engine, DB Load cắt theo waits / SQL / hosts / users). Đề nhấn "CloudWatch tiêu chuẩn không đủ" là tín hiệu chọn hai cái sau.
• Đề đòi "process" → Enhanced Monitoring; đề đòi "query", "session", "wait" → Performance Insights. Khi câu hỏi đòi cả hai từ này thì chọn cả hai dịch vụ.
• Cảnh giác với phương án gán cho một dịch vụ khả năng nó không có (CloudWatch Events chứa SQL). Hỏi "dịch vụ này thực sự sinh ra loại dữ liệu đó không?" thường loại được ngay.
• Athena luôn gắn với dữ liệu trên S3 (kèm federated query để đọc nguồn khác); nó không phải công cụ quan sát hoạt động runtime của một database engine.

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

Một data engineer cần đưa dataset vào Amazon S3 data lake. Dataset chứa PII, và yêu cầu gồm hai việc: profile dataset (dò tìm xem PII nằm ở đâu) và mask PII.

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

• "can be independently used" — mỗi phương án được chọn phải tự nó làm trọn cả hai việc, không cần ghép với phương án khác. Đây là lý do phương án nào thiếu một nửa (chỉ phát hiện, hoặc chỉ che) sẽ rớt.
• "with the least amount of operational effort" — ưu tiên khả năng có sẵn (built-in) của dịch vụ, không phải code tự viết. Cụm này là dao mổ để loại các phương án dùng Lambda.

Đề là dạng batch: dataset đã có sẵn, đã được profile thủ công rồi, giờ cần nạp vào data lake. Không có chữ nào nói về dữ liệu chảy liên tục theo thời gian thực.

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

B — Detect PII transform trong AWS Glue Studio + Step Functions

Detect PII là một transform dựng sẵn của AWS Glue Studio. Người dùng chọn loại PII entity muốn tìm (số điện thoại, địa chỉ, số định danh cá nhân…), chọn cách quét, và chọn hành động áp lên entity tìm được. Điểm mấu chốt: transform này vừa detect vừa mask hoặc remove ngay trong cùng một bước — ví dụ thay số định danh bằng chuỗi cố định xxx-xx-xxxx. Vì vậy nó thoả "independently": một transform lo trọn hai yêu cầu. Step Functions chỉ đóng vai orchestrate pipeline nạp dữ liệu vào S3 data lake, không phải nơi làm nghiệp vụ mask.

C — AWS Glue DataBrew: profile job + DataBrew job

DataBrew là công cụ chuẩn bị dữ liệu trực quan, có sẵn nhóm transformation dành riêng cho PII data handling: redaction, replacement, encryption, decryption. Luồng đúng như đề tả: chạy data profile job để DataBrew tự nhận diện và gợi ý các cột có khả năng là PII, sau đó nhắm vào các cột đó trong một DataBrew project, áp transformation, rồi chạy DataBrew job để áp lên toàn bộ dataset và ghi kết quả đã mask vào Amazon S3. Cũng đủ cả hai vế profile + mask, và làm bằng thao tác cấu hình chứ không viết code.

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

A — Detect PII để nhận diện, rồi dùng rule của AWS Glue Data Quality để mask

Đây là phương án gần đúng nhất và cũng là bẫy chính. Nửa đầu hoàn toàn hợp lệ, nhưng nửa sau đặt sai việc cho sai dịch vụ. AWS Glue Data Quality sinh ra để đo và giám sát chất lượng dữ liệu, tự khuyến nghị rule và cảnh báo khi có vấn đề. Các nhóm rule built-in của nó xoay quanh consistency (tương quan giữa các cột), accuracy (số bản ghi, cột rỗng, khớp pattern, kiểu dữ liệu hợp lệ), integrity (trùng lặp) và completeness (thiếu giá trị) — không có rule dựng sẵn nào để mask PII. Muốn mask thì phải tự viết custom rule, tức là thêm công sức vận hành, vi phạm đúng ràng buộc "least operational effort". Trớ trêu là bản thân Detect PII đã mask được rồi, nên phương án này còn thừa một bước.

D — Kinesis Data Streams + Lambda tự mask

Hỏng ở chỗ phải viết custom code trong Lambda để nhận diện và che PII. Đó là công sức vận hành không cần thiết khi Glue Studio và DataBrew đã có sẵn tính năng. Ngoài ra Data Streams là hạ tầng streaming — chọn nó cho một dataset batch cần profile là đưa vào một tầng phải tự quản lý, tự xử lý consumer, rồi vẫn phải tự ghi ra S3.

E — Kinesis Data Firehose + transformation Lambda

Nhẹ nhàng hơn D vì Firehose tự lo phần ghi vào S3, không cần viết consumer. Nhưng phần mask vẫn nằm trong Lambda do bạn tự viết — đúng vào điểm đề muốn tránh. Quan trọng hơn: Firehose không profile dataset, nó chỉ chảy từng bản ghi qua hàm biến đổi. Yêu cầu "profile the dataset" không được đáp ứng bởi bất cứ phần nào của phương án này.

📌 Điểm cần nhớ

• Cụm "least operational effort" trong đề AWS gần như luôn nghiêng về tính năng built-in của dịch vụ, và đẩy lùi mọi phương án có custom Lambda code. Thấy "write a Lambda function to..." bên cạnh một dịch vụ đã làm sẵn việc đó thì cân nhắc loại.
• Detect PII transform (Glue Studio) và PII handling transformations (Glue DataBrew) đều làm được cả detect lẫn mask. Đừng mặc định phải ghép thêm dịch vụ thứ hai để che dữ liệu.
• AWS Glue Data Quality ≠ công cụ bảo vệ dữ liệu. Nó đo chất lượng (đầy đủ, chính xác, nhất quán, không trùng lặp), không phải nơi làm data masking.
• Khi đề dùng chữ "independently", hãy chấm điểm từng phương án như một giải pháp trọn vẹn: thiếu bất kỳ vế nào trong yêu cầu (ở đây là profile và mask) là loại, dù phần còn lại rất đúng.
• Chọn streaming (Kinesis) cho một dataset tĩnh cần khảo sát trước khi nạp là lệch bài toán; batch profiling hợp với công cụ chuẩn bị dữ liệu hơn.

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

Công ty có dữ liệu nằm rải rác ở bốn nơi khác nhau: Amazon Redshift, Amazon S3, một SQL Server database chạy on-premises, và Salesforce (SaaS). Yêu cầu là dựng một dashboard để quản lý nhìn được các chỉ số từ tất cả những hệ thống này.

Cụm từ quyết định đáp án nằm ở câu hỏi cuối: "a simple and easy way to build the dashboard in the least possible time". Đây không phải câu hỏi về kiến trúc tối ưu, về chi phí lâu dài, hay về hiệu năng truy vấn — mà về thời gian dựng nhanh nhất và ít công sức nhất. Cả bốn phương án đều dẫn tới một dashboard chạy được; điểm phân biệt duy nhất là mỗi phương án bắt bạn làm bao nhiêu việc trước khi có dashboard.

Chi tiết thứ hai cần để ý: danh sách nguồn dữ liệu cố tình trộn cả nguồn trong AWS (Redshift, S3), nguồn ngoài AWS (SQL Server on-premises) và nguồn SaaS (Salesforce). Đề đang thử xem bạn có biết Amazon QuickSight kết nối được thẳng tới cả ba loại đó hay không, hay bạn sẽ mặc định rằng "muốn phân tích thì trước hết phải dồn hết dữ liệu về S3".

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

D — Configure Amazon QuickSight to connect to the data sources and generate the visualizations.

Amazon QuickSight là dịch vụ business analytics chạy trên cloud, dựng để người dùng nghiệp vụ tự tạo visualization và phân tích ad-hoc mà không cần đội kỹ thuật đứng sau.

Điểm mấu chốt là bộ connector sẵn có của QuickSight phủ đúng cả bốn nguồn trong đề:

• Nguồn AWS: Amazon Redshift, Amazon S3, và cả Athena, RDS, Aurora
• Database on-premises: SQL Server, MySQL, PostgreSQL
• Ứng dụng SaaS: Salesforce

Nghĩa là với đề bài này, bạn chỉ cần khai báo từng data source trong QuickSight rồi dựng biểu đồ. Không có bước ETL, không có bước migrate, không phải viết truy vấn join thủ công. Đó chính xác là "simple and easy, in the least possible time" mà đề yêu cầu.

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

A — Federated queries của Amazon Athena để join các nguồn, rồi visualize bằng QuickSight.

Đây là phương án gần đúng nhất, và nó chạy được về mặt kỹ thuật: Athena federated query cho phép truy vấn dữ liệu nằm ngoài S3 thông qua các connector, và kết quả hoàn toàn có thể đưa sang QuickSight để vẽ. Chỗ nó hỏng là công sức: bạn phải triển khai và cấu hình connector cho từng nguồn, rồi tự viết các truy vấn join phức tạp xuyên qua nhiều hệ thống khác nhau. Đó là một khối lượng phát triển truy vấn đáng kể — trong khi đề chỉ cần dashboard cho manager xem, không hề đòi hỏi join dữ liệu giữa các nguồn. Phương án này thêm một tầng trung gian mà bài toán không yêu cầu.

B — Dùng AWS Lake Formation migrate dữ liệu về S3, rồi Glue Data Catalog + Athena, có Glue Crawler tự động hoá.

Sai vì đây là phương án nặng nề nhất trong bốn cái. Bạn phải: dựng data lake, di chuyển dữ liệu từ Redshift, SQL Server on-premises và Salesforce về S3, cấu hình Glue Data Catalog, chạy Glue Crawler để tạo schema, rồi mới truy vấn bằng Athena và vẽ. Việc thêm Glue Crawler để "automate the process" nghe có vẻ tiết kiệm công, nhưng nó chỉ tự động hoá phần khám phá schema — toàn bộ khâu di chuyển dữ liệu vẫn còn nguyên đó.

C — Dùng AWS Lake Formation migrate dữ liệu về S3, rồi QuickSight vẽ dashboard.

Nhẹ hơn B vì bỏ được tầng Glue/Athena, nhưng vẫn giữ đúng cái phần tốn kém nhất: bước migrate mọi nguồn dữ liệu vào S3 bằng Lake Formation. Bước này là thừa hoàn toàn, bởi QuickSight vốn đã nối thẳng được tới Redshift, SQL Server on-premises và Salesforce. Nói cách khác, C chính là D cộng thêm một công đoạn không cần thiết — và đề đang hỏi "least possible time", nên bất kỳ công đoạn thừa nào cũng đủ để loại.

📌 Điểm cần nhớ

• Khi đề nhấn "simple", "easy", "least possible time", "least operational overhead", hãy đếm số bước của từng phương án. Phương án nào ít bước nhất mà vẫn đáp ứng yêu cầu thì thắng, kể cả khi phương án khác "chuẩn kiến trúc" hơn.
• Amazon QuickSight không chỉ đọc dữ liệu trong AWS. Nó kết nối trực tiếp tới database on-premises (SQL Server, MySQL, PostgreSQL) và tới ứng dụng SaaS như Salesforce — nên đừng mặc định rằng dữ liệu phải nằm trong S3 mới visualize được.
• Athena federated query dùng khi bạn thực sự cần truy vấn/join dữ liệu xuyên nhiều nguồn khác S3. Nếu đề chỉ cần vẽ dashboard, đó là công cụ thừa cho việc.
• AWS Lake Formation phục vụ việc dựng data lake tập trung. Bất kỳ phương án nào bắt đầu bằng "migrate the data sources into S3" đều là phương án nặng — chỉ chọn khi đề nói rõ họ muốn một data lake, chứ không phải khi đề hỏi cách dựng dashboard nhanh nhất.

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

Đề mô tả một nhu cầu rất cụ thể: kéo dữ liệu customer support từ Zendesk — đề nói thẳng đó là một sản phẩm SaaS — về một Amazon S3 bucket để rồi phân tích bằng Amazon Athena.

Cụm từ quyết định đáp án là "LEAST operational overhead" đặt cạnh "software-as-a-service product". Hai mảnh này phải đọc chung với nhau:

• "SaaS" khoanh vùng bài toán thành ingest dữ liệu từ ứng dụng bên thứ ba, không phải xử lý một luồng sự kiện do chính bạn phát sinh.
• "LEAST operational overhead" loại bỏ mọi phương án mà bạn phải tự viết code gọi API của Zendesk, tự quản cụm, tự lo phân trang, retry, lịch chạy.

Phần "để phân tích bằng Athena" chỉ giải thích vì sao đích đến là S3 — nó không phải ràng buộc phân biệt, vì cả bốn phương án đều có thể xuất ra S3 bằng cách này hay cách khác. Ràng buộc thật nằm ở ai chịu trách nhiệm viết phần kết nối tới Zendesk.

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

D — Amazon AppFlow.

AppFlow là dịch vụ tích hợp fully managed, sinh ra đúng cho việc chuyển dữ liệu an toàn giữa các ứng dụng SaaS (Salesforce, Marketo, Slack, ServiceNow, Zendesk…) và các dịch vụ AWS như Amazon S3 hay Amazon Redshift. Zendesk là connector có sẵn, nên bạn chỉ cấu hình một flow chứ không viết dòng code nào để nói chuyện với API của Zendesk.

Ba điểm khiến nó khớp với "least operational overhead":

• Low-code/no-code: kết nối là thứ được cung cấp sẵn, không phải thứ bạn xây và bảo trì.
• Chạy theo nhiều kiểu: theo lịch, theo sự kiện nghiệp vụ, hoặc chạy tay — không cần dựng scheduler riêng.
• Biến đổi ngay trong flow: masking, ghép trường, validate và lọc bản ghi không đạt tiêu chí được làm luôn trong flow, không cần thêm một bước xử lý phía sau.

Tài liệu AWS về pattern ingest dữ liệu SaaS vào data lake còn nêu đúng ca này làm ví dụ: đẩy case ticket từ Zendesk sang Amazon S3.

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

A — Amazon Kinesis Data Streams. Đây là nơi chứa và phân phối luồng dữ liệu, không phải nơi đi lấy dữ liệu. Kinesis không tự biết gọi API Zendesk; bạn phải viết producer riêng để đọc từ Zendesk rồi PutRecord vào stream, sau đó lại cần một consumer để ghi xuống S3. Chính phần code tự viết đó là operational overhead mà đề yêu cầu tránh.

B — Amazon MSK. Hỏng ở cùng chỗ với A, và còn nặng hơn: Apache Kafka là kho dữ liệu phân tán tối ưu cho ingest và xử lý streaming thời gian thực. Dù MSK gánh hộ phần vận hành cụm Kafka, bạn vẫn phải tự phát triển phần kết nối đọc Zendesk và phần ghi xuống AWS. Thêm nữa, dữ liệu customer support kiểu này thường lấy theo lịch/theo lô, dùng cả một nền tảng streaming cho nó là chọn công cụ nặng hơn nhu cầu.

C — AWS Glue DataBrew. Đây là phương án gần đúng nhất và dễ mắc bẫy vì DataBrew cũng "no-code" — đúng tinh thần "least operational overhead", nên người học hay dừng lại ở đó. Nhưng DataBrew là công cụ chuẩn bị dữ liệu trực quan: làm sạch, chuẩn hoá dữ liệu cho analytics và ML, với hơn 250 phép biến đổi dựng sẵn, không cần viết code. Nó hỏng ở chỗ nguồn: DataBrew làm việc trên dữ liệu đã nằm sẵn trong AWS, nó không đọc được dữ liệu từ một ứng dụng SaaS về. Nó giải bài toán "sau khi có dữ liệu thì làm gì", còn đề đang hỏi "làm sao đưa dữ liệu về".

📌 Điểm cần nhớ

• Thấy SaaS (Zendesk, Salesforce, Slack, ServiceNow, Marketo, Datadog, SAP) + đích là S3/Redshift + least operational overhead → phản xạ đầu tiên là Amazon AppFlow.
• Phân biệt theo hướng di chuyển dữ liệu: AppFlow đi lấy dữ liệu về; Kinesis Data Streams và MSK chỉ nhận dữ liệu bạn đẩy vào. Phương án nào bắt bạn tự viết connector thì tự nó thua tiêu chí "least operational overhead".
• "No-code" chưa đủ để chọn. DataBrew cũng no-code nhưng sai vai trò — nó biến đổi dữ liệu đã có trong AWS, không ingest từ ngoài vào. Luôn hỏi thêm: công cụ này có nói chuyện được với nguồn trong đề không?
• Trong các câu so sánh mức vận hành, hãy xếp hạng: dịch vụ có connector dựng sẵn < dịch vụ managed nhưng phải tự code < nền tảng phải tự vận hành. Cụm từ "LEAST operational overhead" gần như luôn đẩy đáp án về nhóm đầu tiên.