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

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

Đề mô tả một nhóm vận hành hạ tầng AWS muốn dùng AWS Step Functions làm bộ điều phối cho một quy trình gồm ba việc tách bạch:

1. Kiểm tra sức khoẻ EC2 instances theo chu kỳ (check the health of their EC2 instances periodically)
2. Kích hoạt quá trình khắc phục khi phát hiện instance không khoẻ (trigger a remediation process)
3. Ghi log trạng thái và các hành động đã thực hiện (log the status and any actions taken)

Cụm từ quyết định là "health of their EC2 instances" — đây là sức khoẻ vận hành của từng instance cụ thể (status check, CPU, khả năng phản hồi), chứ không phải tình trạng tuân thủ cấu hình, không phải lỗ hổng bảo mật, và cũng không phải sự cố ở phía dịch vụ AWS. Cụm thứ hai là "remediation tasks" — công việc sửa chữa tuỳ biến, chạy ngắn, do Step Functions gọi ra. Cụm thứ ba là "log the status and actions" — dữ liệu log dạng ghi rồi để đó, không cần truy vấn quan hệ.

Ba chữ khoá này chia đúng ba vai: monitoring – remediation – logging. Phương án nào sai lệch ở dù chỉ một vai cũng bị loại.

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

Đáp án đúng theo tệp là D — Step Functions + Amazon CloudWatch (health checks) + AWS Lambda (remediation) + Amazon S3 (logging).

• Amazon CloudWatch là dịch vụ giám sát sức khoẻ và hiệu năng tài nguyên AWS, trong đó có EC2 instances. Nó thu metric và cho phép đặt alarm dựa trên các metric đó — đúng thứ cần để trả lời câu hỏi "instance này có khoẻ không".
• AWS Lambda là nơi đặt logic khắc phục. Step Functions gọi Lambda như một bước trong state machine, nên toàn bộ workflow "kiểm tra → rẽ nhánh → sửa" nằm gọn trong một luồng có trạng thái, có retry, có xử lý lỗi.
• Amazon S3 nhận log kết quả kiểm tra và log các hành động đã thực hiện. Đây là kho lưu trữ đối tượng, phù hợp với dữ liệu ghi-một-lần-đọc-nhiều như log.

Bộ ba này phủ trọn ba vai đề bài nêu, với Step Functions đứng giữa làm bộ điều phối — đúng vai trò dịch vụ này sinh ra để làm.

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

A — AWS Config + Step Functions + Amazon RDS (logging). AWS Config nghiêng về theo dõi cấu hình và tuân thủ: nó ghi lại tài nguyên được cấu hình ra sao, có lệch chuẩn không, thay đổi lúc nào. Đó là câu hỏi "instance này có được cấu hình đúng chuẩn không", khác hẳn "instance này có đang khoẻ không". Config vẫn tích hợp được với Step Functions, nhưng không phải công cụ tối ưu cho tình huống giám sát sức khoẻ ở đây. Thêm nữa, dùng Amazon RDS — một CSDL quan hệ — chỉ để chứa mấy dòng log đơn giản là quá nặng so với nhu cầu.

B — AWS Health + Amazon ECS (remediation) + Amazon DynamoDB (logging). AWS Health cung cấp cảnh báo và hướng dẫn xử lý về tình trạng của chính dịch vụ AWS — sự kiện phía nhà cung cấp ảnh hưởng tới tài khoản của bạn. Nó không được thiết kế để kiểm tra sức khoẻ từng tài nguyên riêng lẻ như một EC2 instance cụ thể, nên hỏng ngay ở vai giám sát. Vai remediation cũng lệch: Amazon ECS là dịch vụ chạy container, không phải lựa chọn thông thường để thực thi tác vụ khắc phục sự cố sức khoẻ EC2. Riêng DynamoDB làm nơi ghi log thì không phải điểm hỏng chính, nhưng hai vai kia sai đã đủ loại phương án này.

C — Amazon Inspector + EC2 Auto Scaling (remediation) + AWS CloudTrail (logging). Phương án này lệch cả ba vai. Amazon Inspector làm đánh giá bảo mật — quét lỗ hổng, quét vấn đề an ninh — chứ không giám sát sức khoẻ vận hành nói chung của EC2. EC2 Auto Scaling dùng để co giãn số lượng instance theo tải; nó không phải cơ chế khắc phục sự cố sức khoẻ theo nghĩa đề bài (nó thay thế instance theo chính sách scaling, chứ không phải chạy quy trình sửa chữa mà nhóm tự định nghĩa). AWS CloudTrail ghi nhật ký hoạt động API trong tài khoản phục vụ kiểm toán — nó không phải nơi để bạn chủ động ghi kết quả health check và hành động khắc phục của mình. Đây là phương án nghe "kỹ thuật" nhất nhưng thực ra sai xa nhất.

📌 Điểm cần nhớ

• Phân biệt bốn dịch vụ hay bị lẫn theo đúng câu hỏi mà chúng trả lời: CloudWatch — "tài nguyên có đang khoẻ/chạy tốt không"; AWS Config — "cấu hình có đúng chuẩn không"; Amazon Inspector — "có lỗ hổng bảo mật không"; AWS Health — "phía dịch vụ AWS có sự cố gì không".
• Cũng đừng lẫn hai loại log: CloudTrail ghi hoạt động API để kiểm toán, còn log do ứng dụng/workflow của bạn chủ động sinh ra thì đổ vào kho lưu trữ như S3.
• Trong các câu về Step Functions, hãy đọc đề như một sơ đồ ba vai: ai phát hiện – ai sửa – ai ghi lại. Step Functions chỉ điều phối, không tự làm việc nào trong ba vai đó.
• Với tác vụ khắc phục ngắn, tuỳ biến, được workflow gọi ra, AWS Lambda là lựa chọn mặc định; EC2 Auto Scaling là công cụ co giãn theo tải chứ không phải công cụ remediation tuỳ biến.

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

Đề mô tả một bảng Redshift tên FinancialRecords bị update và delete liên tục, dùng interleaved sort key theo loại giao dịch. Doanh nghiệp lo hai chuyện cùng lúc: dung lượng đĩa phình ra và truy vấn ngày càng chậm, và muốn giữ cho sort key còn hiệu lực. Câu hỏi là dùng lệnh Redshift nào.

Cụm từ quyết định đáp án là "maintain the sort key's effectiveness" đi kèm "interleaved sort key". Nếu đề chỉ nói tới việc thu hồi dung lượng đĩa thì nhiều lệnh cùng làm được; nhưng khi đề đòi vừa thu hồi không gian vừa sắp xếp lại dữ liệu theo sort key, chỉ còn đúng một lệnh làm cả hai. Lý do là trong Redshift, DELETE và UPDATE không xoá vật lý — dòng cũ chỉ bị đánh dấu là đã xoá, vẫn chiếm chỗ. Đồng thời dữ liệu mới ghi vào vùng chưa được sắp xếp, khiến interleaved sort key — vốn nhạy cảm với việc phân bố dữ liệu thay đổi — mất dần tác dụng lọc theo vùng.

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

A. VACUUM FULL FinancialRecords là thao tác VACUUM đầy đủ: nó vừa thu hồi không gian của những dòng đã bị đánh dấu xoá, vừa sắp xếp lại (re-sort) dữ liệu trong bảng theo sort key đã định nghĩa.

Ánh xạ thẳng vào hai yêu cầu của đề:

• "growing disk space usage" → phần reclaim space nén lại các block, trả chỗ trống về.
• "diminishing query performance" + "maintain the sort key's effectiveness" → phần re-sort đưa dữ liệu về đúng thứ tự sort key, khôi phục khả năng bỏ qua block không liên quan khi quét.

Với interleaved sort key, việc sắp xếp lại đặc biệt quan trọng vì kiểu sort key này suy giảm rõ rệt khi bảng thay đổi nhiều. VACUUM FULL là lựa chọn bao trùm cả hai vấn đề nên nó là đáp án đúng.

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

B. VACUUM DELETE ONLY FinancialRecords — đây là phương án gần đúng nhất và cũng là bẫy chính. Nó có giải quyết vế dung lượng đĩa: thu hồi không gian từ các dòng đã xoá. Nhưng đúng như tên gọi, nó chỉ làm phần delete, không sắp xếp lại dữ liệu theo sort key. Vế thứ hai của đề — hiệu năng truy vấn tụt và sort key mất hiệu lực — hoàn toàn không được xử lý. Chọn B nghĩa là đọc sót một nửa yêu cầu.

C. ALTER TABLE FinancialRecords APPEND FROM STAGING_TABLE — lệnh này dùng để chuyển nhanh dữ liệu từ bảng này sang bảng khác, ví dụ từ bảng staging sang bảng production, bằng cách dời block thay vì copy từng dòng. Nó là thao tác nạp dữ liệu, không phải thao tác bảo trì: không thu hồi không gian của các dòng đã xoá trong bảng đích, cũng không sắp xếp lại bảng theo sort key. Ngoài ra đề cũng không hề nói tới bảng staging nào — nó chỉ mô tả một bảng đang bị update/delete tại chỗ.

D. ANALYZE FinancialRecords — lệnh này cập nhật số liệu thống kê (statistics) cho query planner, giúp planner chọn kế hoạch thực thi tốt hơn. Đây cũng là việc nên làm định kỳ và nghe rất "liên quan tới hiệu năng", nhưng nó không đụng gì tới dữ liệu vật lý: không giải phóng đĩa, không sắp xếp lại dòng. Vấn đề đề nêu là dữ liệu nằm sai chỗ và chiếm chỗ thừa, không phải planner thiếu thông tin.

📌 Điểm cần nhớ

• Trong Redshift, DELETE/UPDATE chỉ đánh dấu logic; không gian và thứ tự sort key chỉ được xử lý khi chạy VACUUM.
• Phân biệt các biến thể VACUUM: FULL = thu hồi không gian và re-sort; DELETE ONLY = chỉ thu hồi không gian. Đề hỏi cả hai vế thì phải chọn FULL.
• ANALYZE phục vụ query planner (statistics), VACUUM phục vụ bố cục dữ liệu vật lý — hai việc khác nhau, đừng lẫn dù cả hai đều gắn nhãn "tối ưu hiệu năng".
• ALTER TABLE ... APPEND là công cụ nạp/di chuyển dữ liệu giữa các bảng, không phải công cụ bảo trì bảng.
• Bảng dùng interleaved sort key suy giảm hiệu quả rõ hơn khi có nhiều thay đổi dữ liệu — hễ đề nhắc tới interleaved sort key kèm "update/delete thường xuyên", hãy nghĩ ngay tới việc re-sort.

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

Đề mô tả một đội data engineering có hai nhu cầu nối tiếp nhau: di chuyển khối dữ liệu lớn từ file server on-premises lên AWS để phục vụ phân tích, và sau đó tiếp tục đồng bộ những thay đổi tăng dần (incremental) giữa file server đó và Amazon S3.

Cụm từ quyết định nằm ở câu hỏi cuối: "with the ability to schedule periodic syncs" và "ensure data is kept current". Đây không phải bài toán "làm sao đẩy file lên S3" — cả bốn phương án đều đưa được dữ liệu lên S3 theo cách nào đó. Ràng buộc thật sự là cơ chế đồng bộ có lịch chạy định kỳ và xử lý được phần chênh lệch, tức là dịch vụ phải tự biết so sánh nguồn với đích và chỉ chuyển phần khác nhau. Thêm cụm "large datasets" và "migrating" cho biết đây là bài toán truyền dữ liệu một chiều có điều phối, chứ không phải cung cấp một giao diện file cho ứng dụng dùng hằng ngày.

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

B — AWS DataSync là dịch vụ được thiết kế đúng cho việc chuyển khối lượng dữ liệu lớn giữa hệ thống lưu trữ on-premises và các dịch vụ lưu trữ của AWS như Amazon S3.

Điểm khớp với đề nằm ở ba chỗ:

• DataSync cho phép tạo task có lịch chạy (một lần hoặc lặp lại định kỳ), đúng với yêu cầu "schedule periodic syncs".
• Nó xử lý thay đổi tăng dần: sau lần chuyển đầu tiên, các lần sau chỉ đồng bộ phần dữ liệu đã đổi, giữ hai bên khớp nhau mà không phải chép lại toàn bộ.
• Cùng một dịch vụ phục vụ được cả hai giai đoạn đề nêu — migration ban đầu và replication liên tục sau đó — nên đội không phải ghép hai công cụ khác nhau.

Yếu tố lịch chạy tự động chính là thứ giúp dữ liệu luôn cập nhật sau đợt migration mà gần như không cần can thiệp thủ công.

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

A — AWS Transfer Family. Đây là phương án gần đúng nhất vì nó thật sự chuyển được file vào và ra khỏi Amazon S3. Nhưng bản chất của Transfer Family là cung cấp endpoint theo giao thức truyền file (SFTP, FTPS, FTP) để bên ngoài đẩy/kéo file một cách an toàn. Nó không mang sẵn khái niệm "so sánh nguồn với đích rồi đồng bộ phần chênh lệch theo lịch" — muốn có hành vi đó, đội phải tự viết script và tự đặt lịch ở phía on-premises. So với DataSync, nó thiếu đúng phần tự động hoá đồng bộ mà đề yêu cầu.

C — AWS Storage Gateway (file gateway). File gateway cho phép ứng dụng on-premises đọc/ghi object trong S3 qua giao diện file system, có cache tại chỗ. Đây là mô hình "lưu trữ tại chỗ được S3 chống lưng" — hợp khi ứng dụng cần dùng S3 như một ổ đĩa thường trực. Nó giải bài toán truy cập, không phải bài toán migration khối lớn + đồng bộ theo lịch. Đề không nói ứng dụng on-premises cần đọc dữ liệu qua giao diện file, mà nói cần chuyển dữ liệu lên để phân tích và giữ hai bên cập nhật — vậy nên đây là công cụ lệch mục đích.

D — Amazon S3 Transfer Acceleration. Đây chỉ là một tính năng tăng tốc độ cho việc upload/download S3 qua đường biên của CloudFront, hữu ích khi khoảng cách địa lý tới bucket xa. Nó hoàn toàn không có phần điều phối: không lịch chạy, không phát hiện thay đổi, không đồng bộ. Chọn D là trả lời sai vế của câu hỏi — đề hỏi cách điều phối việc chuyển dữ liệu, còn Transfer Acceleration chỉ nói về hiệu năng của một lần chuyển đã được ai đó khởi động.

📌 Điểm cần nhớ

• Thấy từ khoá "schedule", "periodic sync", "incremental", "keep data current" trong bài toán on-premises → S3, gần như luôn là DataSync.
• Phân biệt theo mục đích chứ không theo có chuyển được file hay không: Transfer Family = endpoint giao thức SFTP/FTPS/FTP cho đối tác đẩy file; Storage Gateway file gateway = giao diện file system cho ứng dụng tại chỗ dùng S3; DataSync = di chuyển và đồng bộ dữ liệu có điều phối.
• S3 Transfer Acceleration là tính năng hiệu năng, không phải dịch vụ điều phối — nếu đề hỏi "làm thế nào để tự động/định kỳ" thì nó bị loại ngay, dù đề có nhắc tới tốc độ.
• Khi một dịch vụ giải được cả hai giai đoạn đề nêu (migration ban đầu và đồng bộ về sau), đó thường là dấu hiệu của đáp án đúng, so với phương án phải ghép thêm script bên ngoài mới đủ.

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

Đề mô tả một startup làm ứng dụng web có workload không đoán trước được và traffic bùng lên từng đợt (sporadic bursts). Yêu cầu đặt ra gồm ba vế, và cả ba đều là ràng buộc lọc phương án:

1. "requires a relational database" — đây là cụm từ quyết định đầu tiên. Nó loại thẳng mọi thứ không phải cơ sở dữ liệu quan hệ, bất kể khả năng co giãn tốt đến đâu.
2. "with automatic scaling capabilities" — tự động, tức là không cần người vận hành bấm nút hay dựng thêm instance. Cụm này loại các phương án chỉ cho phép mở rộng bằng thao tác thủ công.
3. "while optimizing costs" — với traffic thất thường, tối ưu chi phí nghĩa là lúc vắng khách thì phải trả ít đi, chứ không phải trả tiền cho công suất dự phòng ngồi không.

Chỉ một phương án thoả cả ba: vừa quan hệ, vừa tự co giãn compute, vừa tính tiền theo mức công suất thực dùng.

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

D — Amazon Aurora Serverless.

Aurora Serverless là cấu hình on-demand, auto-scaling của Amazon Aurora — mà Aurora bản thân nó là relational database tương thích MySQL (và PostgreSQL), nên vế "relational" thoả ngay.

Điểm mấu chốt là nó tự điều chỉnh compute và memory theo nhu cầu thực tế của ứng dụng, không cần ai can thiệp. Đúng loại workload mà đề mô tả: không đoán trước được lúc nào tải lên, lúc nào tải xuống.

Về chi phí: Aurora Serverless tính tiền theo công suất database thực sự sử dụng, theo đơn vị thời gian rất nhỏ (per second). Với traffic bùng phát rồi lặng đi, mô hình này rẻ hơn hẳn việc nuôi một instance cỡ lớn suốt ngày đêm chỉ để chịu được đỉnh. Đó chính là ý "optimizing costs" trong đề.

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

A — Amazon RDS for MySQL + Read Replicas. Đây là phương án gần đúng nhất, vì RDS for MySQL đúng là relational database. Chỗ nó hỏng nằm ở chữ "automatic": Read Replica chỉ thêm năng lực đọc, và việc thêm/bớt replica cũng như đổi kích cỡ instance là thao tác bạn phải chủ động làm. Nó không tự co giãn compute theo traffic. Ngoài ra Read Replica không giúp gì cho tải ghi, và replica dựng lên là chạy liên tục — trả tiền cả những lúc không có ai truy cập, đi ngược vế tối ưu chi phí.

B — Amazon Redshift + elastic resize. Redshift là data warehouse, phục vụ phân tích và truy vấn tổng hợp trên khối dữ liệu lớn, không phải cơ sở dữ liệu vận hành (operational/OLTP) đứng sau một ứng dụng web. Elastic resize đúng là đổi được quy mô cluster, nhưng đó là một thao tác được kích hoạt, không phải phản ứng tự động liên tục theo từng đợt burst. Sai cả về loại workload lẫn về tính chất "automatic".

C — Amazon DynamoDB on-demand capacity mode. Phương án này thoả rất tốt hai vế sau — on-demand mode đúng là tự co giãn theo tải và chỉ tính tiền theo request thực tế, hợp với traffic thất thường. Nhưng nó chết ở vế đầu tiên: DynamoDB là NoSQL (key-value/document), không phải relational database. Đề nói rõ "requires a relational database", nên dù cơ chế scaling có đẹp đến mấy thì cũng không đáp ứng đúng yêu cầu. Đây là kiểu bẫy điển hình: phương án hấp dẫn ở phần được nhấn mạnh nhiều nhất, nhưng vi phạm một ràng buộc ghi gọn trong một câu.

📌 Điểm cần nhớ

• Đọc kỹ vế "relational" hay "NoSQL" trong đề trước khi cân nhắc khả năng scaling. Một ràng buộc về mô hình dữ liệu loại phương án dứt khoát hơn mọi ưu điểm về vận hành — DynamoDB bị loại ở đây chỉ vì lý do đó.
• Phân biệt "scalable" với "automatically scaling". RDS Read Replica và Redshift elastic resize đều mở rộng được, nhưng cần thao tác chủ động. Khi đề dùng chữ unpredictable + automatic, câu trả lời gần như luôn là một tuỳ chọn serverless/on-demand.
• Ghép "unpredictable workload" + "relational" + "optimize cost" → Aurora Serverless. Đây là bộ ba từ khoá gần như cố định trong đề thi AWS.
• Redshift là kho dữ liệu phân tích, không phải database vận hành cho web app. Thấy Redshift xuất hiện trong câu hỏi về backend của ứng dụng giao dịch/web thì phần lớn là phương án gây nhiễu.

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

Một nhóm data engineering muốn chạy câu lệnh SQL trên cụm Amazon Redshift từ nhiều ứng dụng khác nhau (from various applications), và quan trọng nhất: không phải quản lý kết nối tới cơ sở dữ liệu (without managing database connections).

Cụm từ quyết định là "without managing database connections", đi kèm với "from various applications". Đây không phải câu hỏi "làm sao chạy được SQL trên Redshift" — cách nào trong bốn phương án rồi cũng chạy được SQL. Đề đang lọc theo cách truy cập: phải là truy cập theo chương trình (programmatic), gọi được từ nhiều môi trường ứng dụng, và không cần mở/giữ/đóng kết nối JDBC–ODBC, không cần connection pool, không cần nhét thông tin đăng nhập vào từng ứng dụng.

Chỉ cần bám vào hai ràng buộc đó, ba phương án còn lại rụng ngay: một cái là công cụ dành cho người ngồi bấm, một cái vẫn phải tự quản kết nối, một cái mô tả sai cơ chế kích hoạt.

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

C — Use the Amazon Redshift Data API to run and manage SQL queries.

Amazon Redshift Data API cho phép truy cập Redshift một cách an toàn từ bất kỳ ứng dụng nào mà không cần quản lý kết nối cơ sở dữ liệu. Ứng dụng gửi câu lệnh SQL qua lời gọi API (qua AWS SDK/CLI), thay vì thiết lập một phiên JDBC/ODBC tới cụm.

Vì đây là API HTTP có ký xác thực, nó khớp trọn ba yêu cầu của đề:

• Không quản lý kết nối: không connection pool, không giữ session sống, không lo kết nối rớt giữa chừng.
• Gọi từ nhiều ứng dụng khác nhau: bất kỳ môi trường nào dùng được AWS SDK đều gọi được — rất hợp với các ứng dụng serverless, nơi vòng đời tiến trình quá ngắn để nuôi một pool kết nối.
• "submit and manage these queries" — Data API chạy SQL bất đồng bộ: nộp câu lệnh xong nhận về một mã định danh, sau đó tra trạng thái và lấy kết quả. Đúng nghĩa "submit and manage", và rất hợp với khối lượng SQL kiểu batch.

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

B — Use the Amazon Redshift Query Editor for direct SQL execution. Đây là phương án gần đúng nhất và cũng là bẫy chính. Query Editor đúng là chạy được SQL trực tiếp trên cụm Redshift mà người dùng không phải tự dựng kết nối. Nhưng nó là công cụ web-based, dùng thủ công qua AWS Console — dành cho con người ngồi gõ và xem kết quả. Nó không phải là kênh truy cập theo chương trình để tích hợp vào ứng dụng. Đề nói rõ "from various applications", mà ứng dụng thì không đăng nhập Console để bấm nút. Hỏng ở chỗ ai là người gọi, không phải ở chỗ có chạy được SQL hay không.

D — Implement AWS Lambda with Redshift as a trigger for query execution. Phương án này sai ngay ở mô tả cơ chế: Redshift không trực tiếp kích hoạt (trigger) hàm Lambda. Vế "with Redshift as a trigger" mô tả một luồng không tồn tại như vậy. Lambda hoàn toàn có thể làm việc với Redshift, nhưng đó là chiều ngược lại — Lambda gọi tới Redshift. Và nếu đi theo hướng Lambda tự kết nối, ta lại phải thiết lập và quản lý kết nối tới cơ sở dữ liệu, thêm cấu hình, đúng thứ mà nhóm muốn tránh. Sai cả về cơ chế lẫn về yêu cầu.

A — Deploy Amazon EC2 instances to host applications that connect to Redshift. Phương án nặng nề nhất và đi ngược hẳn đề bài. Dùng EC2 nghĩa là tự quản hạ tầng máy chủ: vận hành instance, vận hành ứng dụng, và vẫn tự quản kết nối cơ sở dữ liệu tới Redshift. Nó mâu thuẫn trực tiếp với ràng buộc "without managing database connections", đồng thời không cho được tính co giãn và mức độ được quản lý sẵn mà Redshift Data API mang lại.

📌 Điểm cần nhớ

• Thấy cụm "without managing database connections" kèm "from applications" trong đề Redshift, hãy nghĩ ngay tới Redshift Data API — đó gần như là chữ ký nhận dạng của dịch vụ này.
• Phân biệt rạch ròi công cụ cho người và kênh cho ứng dụng: Query Editor là giao diện web thủ công trong Console; Data API là đường tích hợp theo chương trình. Cả hai đều "chạy SQL trên Redshift", nhưng đề bài chọn theo người gọi là ai.
• Data API chạy SQL bất đồng bộ: nộp lệnh → nhận mã định danh → tra trạng thái → lấy kết quả. Đề nào nhấn mạnh SQL kiểu batch, hoặc ứng dụng serverless có vòng đời ngắn, thì đây là lựa chọn tự nhiên.
• Cảnh giác với phương án mô tả sai chiều kích hoạt, kiểu "Redshift as a trigger for Lambda". Một phương án có thể sai vì cơ chế nó mô tả không tồn tại, chứ không cần sai vì lựa chọn kém tối ưu.
• Phương án dựng EC2 để né một bài toán kết nối/tích hợp gần như luôn sai trong đề thi: nó thêm việc quản hạ tầng đúng vào chỗ đề bài đang muốn bớt việc.

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

Đề mô tả một công ty phân tích thị trường chứng khoán lưu dữ liệu lịch sử trong Amazon Redshift, và cần một dashboard application truy vấn dữ liệu đó theo kiểu real-time, tương tác.

Cụm từ quyết định đáp án nằm ở câu hỏi cuối: "integrate query capabilities into the application with minimal operational complexity". Hai vế này phải đọc cùng nhau:

• "into the application" — thứ cần là cách để mã ứng dụng tự chạy truy vấn, không phải một công cụ cho người dùng cuối ngồi bấm.
• "minimal operational complexity" — trong bốn phương án đều có cách lấy được dữ liệu Redshift ra, nên đề không hỏi "cái nào chạy được" mà hỏi "cái nào ít phải vận hành nhất". Đây chính là ràng buộc phân biệt A với C: cả hai đều là truy vấn từ ứng dụng, chỉ khác nhau ở khối lượng hạ tầng phải tự lo.

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

C — Amazon Redshift Data API. Data API cho phép ứng dụng gửi câu lệnh SQL tới Redshift qua lời gọi API HTTP, chạy bất đồng bộ rồi lấy kết quả về bằng một lời gọi khác. Điểm mấu chốt: ứng dụng không phải mở và giữ kết nối cơ sở dữ liệu. Với một dashboard web mà số người dùng và số truy vấn biến động mạnh, việc quản lý kết nối (mở, giữ, đóng, xử lý kết nối chết) chính là phần tốn công nhất — Data API gánh hộ phần đó, kể cả việc co giãn theo lượng truy vấn. Xác thực cũng đi theo IAM thay vì phải nhúng và luân chuyển thông tin đăng nhập cơ sở dữ liệu trong ứng dụng.

Nói gọn: cùng là truy vấn thẳng vào Redshift từ code, nhưng Data API bỏ đi toàn bộ tầng quản lý kết nối — đúng nghĩa "minimal operational complexity".

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

A — Cấu hình ODBC cho ứng dụng. Đây là phương án gần đúng nhất và cũng là cái dễ chọn nhầm: nó đúng về mặt chức năng, ứng dụng hoàn toàn truy vấn được Redshift qua ODBC. Chỗ hỏng nằm đúng ở ràng buộc của đề. Đi đường ODBC thì ứng dụng phải tự lo connection pooling, tự lo co giãn khi lượng người dùng tăng, tự lo tính sẵn sàng khi kết nối đứt, và tự quản lý driver cùng thông tin đăng nhập. Với ứng dụng web, chừng đó là một khối vận hành đáng kể so với việc chỉ gọi API. A thua C ở mức độ vận hành, không thua ở khả năng.

B — Athena với Redshift federated query. Federated query của Athena sinh ra để truy vấn xuyên nhiều nguồn dữ liệu, kiểu ad-hoc, khi dữ liệu nằm rải rác. Ở đây dữ liệu đã nằm trọn trong Redshift, nên đi vòng qua Athena là thêm một tầng trung gian mà chẳng giải quyết vấn đề gì: phải dựng và duy trì connector, thêm cấu hình, và đường đi dài hơn nên không hợp với yêu cầu real-time, tương tác. Vừa phức tạp hơn vừa không đúng mục đích thiết kế.

D — QuickSight với SPICE. QuickSight là công cụ business intelligence cho người dùng cuối — nó dựng dashboard của riêng nó, chứ không phải một lớp truy vấn để custom application nhúng vào. Đề nói rõ ứng dụng phải tự truy vấn, mà QuickSight không đóng vai đó. Ngoài ra SPICE là bộ nhớ đệm dữ liệu đã nạp sẵn, tức là ngược lại với ý "direct querying" mà chính phương án ghi — dữ liệu trả về là bản đã nạp vào SPICE, không phải truy vấn thẳng vào Redshift.

📌 Điểm cần nhớ

• Thấy "minimal operational complexity" trong đề thì đừng dừng ở "phương án nào chạy được" — nhiều phương án cùng chạy được, phải so tiếp xem cái nào bắt mình tự dựng và tự nuôi ít hạ tầng nhất.
• Redshift Data API là câu trả lời mặc định cho mẫu đề "ứng dụng cần truy vấn Redshift": không cần quản lý kết nối, gọi bằng HTTP, xác thực qua IAM, hợp với ứng dụng web có tải biến động.
• Phân biệt công cụ cho ứng dụng với công cụ cho người dùng cuối: QuickSight thuộc nhóm sau, nên hễ đề nói "integrate into the application" là loại được ngay.
• Federated query chỉ đáng dùng khi dữ liệu thật sự nằm ở nhiều nguồn khác nhau. Dữ liệu đã nằm gọn một chỗ mà vẫn đi qua federated query là tự thêm tầng trung gian.

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

Đề mô tả một game online nhiều người chơi thời gian thực, cần kho dữ liệu in-memory để quản lý session và bảng xếp hạng người chơi (leaderboard). Câu hỏi là chọn một dịch vụ AWS đáp ứng được yêu cầu.

Cụm từ quyết định nằm gọn trong một câu: "microsecond latency for read and write operations" và "high availability and durability". Ba ràng buộc này phải thoả đồng thời:

• microsecond — không phải millisecond. Đây là mức chỉ đạt được bằng kho dữ liệu in-memory, loại bỏ ngay mọi thứ dựa trên đĩa.
• cho cả read và write — nhiều dịch vụ tăng tốc chỉ nhanh ở chiều đọc, vì chúng là lớp cache đặt trước một CSDL bền vững.
• durability — dữ liệu phải sống sót, chứ không chỉ là bản sao tạm của dữ liệu nằm nơi khác.

Chính vế "write cũng phải microsecond" cộng với "durability" là thứ tách bốn phương án ra. Một cache thuần thì nhanh nhưng không bền; một CSDL bền thì bền nhưng không nhanh tới mức đó; một cache đặt trước CSDL thì nhanh ở đọc, còn ghi vẫn phải xuống lớp bền phía dưới.

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

D — Amazon MemoryDB for Redis.

MemoryDB là CSDL in-memory tương thích Redis, được quản lý hoàn toàn, và điểm khác biệt của nó so với một cache thông thường là: nó là CSDL chính (primary database), không phải lớp cache đứng trước CSDL khác. Dữ liệu nằm trong bộ nhớ nên đọc đạt mức microsecond, đồng thời mọi thao tác ghi được ghi bền vào một transaction log phân tán nhiều Availability Zone trước khi xác nhận — nhờ vậy nó vừa có durability vừa có high availability mà không cần một kho dữ liệu thứ hai phía sau.

Đúng hai bài toán đề nêu: session management (đọc/ghi liên tục trạng thái người chơi) và leaderboard (Redis có sorted set, cấu trúc sinh ra để xếp hạng). Đây cũng chính là lập luận trong phần giải thích gốc: MemoryDB được thiết kế cho ứng dụng cần microsecond latency kèm cả tính sẵn sàng lẫn tính bền của dữ liệu.

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

A — ElastiCache for Memcached. Đây là phương án gần đúng nhất về tốc độ: Memcached là in-memory, latency rất thấp, và dùng cho session management là hoàn toàn hợp lệ. Nó hỏng ở vế durability và high availability: Memcached không có cơ chế bền hoá dữ liệu và không có replication — mất một node là mất phần dữ liệu trên node đó, người chơi mất session, leaderboard mất điểm. Memcached cũng không có kiểu dữ liệu sorted set, nên leaderboard phải tự dựng bằng tay. Nó là cache, mà đề đang cần một data store.

B — DynamoDB với DAX. Cũng gần đúng, và là bẫy chính của câu này. DAX là cache in-memory đặt trước DynamoDB, cho đọc ở mức microsecond — nhưng chỉ đọc. Thao tác ghi vẫn phải đi xuống DynamoDB, tức là mức millisecond một chữ số, không đạt yêu cầu "microsecond cho cả read và write" mà đề nêu rõ. Ràng buộc chiều ghi là thứ loại phương án này.

C — Amazon RDS với instance hiệu năng cao. Sai rõ nhất. RDS là CSDL quan hệ dựa trên đĩa; instance mạnh hơn chỉ đẩy latency xuống mức millisecond chứ không thể chạm tới microsecond, vì rào cản nằm ở kiến trúc lưu trữ chứ không ở kích cỡ máy. Đề còn nói thẳng cần "in-memory data store" — RDS không phải loại đó. Nó hợp với workload giao dịch quan hệ, không hợp với đọc/ghi tốc độ cao của session và leaderboard.

📌 Điểm cần nhớ

• Thấy "microsecond" trong đề là loại ngay mọi CSDL dựa trên đĩa; chỉ in-memory mới vào tới ngưỡng đó.
• Đọc kỹ latency áp cho chiều nào. "Microsecond read" và "microsecond read and write" dẫn tới hai đáp án khác nhau: DAX chỉ tăng tốc đọc, còn ghi vẫn theo tốc độ của DynamoDB phía sau.
• Phân biệt cache với primary in-memory database: ElastiCache (Memcached) là cache, dữ liệu có thể mất; MemoryDB for Redis là CSDL chính, có bền hoá và sẵn sàng cao. Đề nhắc "durability" là đang trỏ về vế thứ hai.
• Leaderboard là tín hiệu quen thuộc của Redis — sorted set là cấu trúc dựng sẵn cho xếp hạng, thứ Memcached không có.

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

Đề mô tả một công ty truyền thông tải video lên một Amazon S3 bucket, và muốn tự động transcode ngay sau khi upload, rồi ghi kết quả sang một S3 bucket khác. Câu hỏi yêu cầu chọn tổ hợp dịch vụ AWS để tự động hoá việc đó.

Cụm từ quyết định là "immediately after upload" — tức là cơ chế kích hoạt phải bám thẳng vào sự kiện tạo object trong S3, không phải quét định kỳ, không phải lịch chạy theo chu kỳ, không phải chính sách quản lý vòng đời lưu trữ. Cụm thứ hai đáng chú ý là "automated process ... saved to a different S3 bucket": cần một thành phần tính toán thực sự thực thi logic transcode và ghi output, chứ không chỉ có phần "phát hiện file mới".

Ghép hai ràng buộc này lại, phương án đúng phải trả lời được cả cái gì phát hiện file mới lẫn cái gì chạy công việc chuyển mã.

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

Đáp án đúng là B — Configure S3 Event Notifications to trigger an AWS Lambda function for video transcoding, and save the output to a different S3 bucket.

S3 Event Notifications là cơ chế gắn liền với chính S3: khi có object mới được tạo (s3:ObjectCreated:*), S3 phát ra thông báo và gọi thẳng đích đã cấu hình. Đây là con đường ngắn nhất giữa "file vừa lên" và "bắt đầu xử lý", nên nó khớp trực tiếp với yêu cầu immediately after upload.

AWS Lambda ở đây đóng vai trò phần tính toán: nó là một trong những đích được S3 Event Notifications hỗ trợ gọi trực tiếp, nhận thông tin bucket và key của object vừa upload, chạy logic transcode (bằng mã tự viết hoặc bằng cách gọi dịch vụ chuyển mã của AWS), rồi ghi kết quả sang bucket đích. Toàn bộ chuỗi là event-driven, không cần server nào chạy chờ, không có bước polling ở giữa.

Nói ngắn gọn: B là tổ hợp trigger đúng nguồn sự kiện + compute đúng chỗ, và đó là kiến trúc chuẩn mà AWS đưa ra cho bài toán "xử lý object ngay khi nó xuất hiện trong S3".

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

A — Amazon CloudWatch Events monitor S3 bucket, trigger Amazon Elastic Transcoder. Đây là phương án gần đúng nhất, vì CloudWatch Events (nay là EventBridge) thực sự có thể nhận sự kiện thay đổi trong môi trường AWS. Nhưng nó là lớp giám sát chung cho nhiều nguồn, không phải cơ chế thông báo gắn thẳng vào bucket; với bài toán "xử lý ngay khi upload", S3 Event Notifications là con đường trực tiếp và hiệu quả hơn. Ngoài ra, phương án chỉ nêu "trigger Elastic Transcoder jobs" mà bỏ ngỏ phần điều phối — vẫn thiếu mắt xích thực thi và ghi output như B mô tả rõ ràng.

C — AWS Data Pipeline phát hiện file mới rồi khởi tạo Elastic Transcoder jobs. Về lý thuyết có thể dựng được luồng này: Data Pipeline là dịch vụ xử lý và di chuyển dữ liệu giữa các dịch vụ compute và storage của AWS. Vấn đề là nó nặng nề và gián tiếp — hướng thiết kế của nó là các workflow dữ liệu có điều phối, chứ không phải phản ứng tức thì với từng object vừa được tạo. So với B, đây là giải pháp phức tạp hơn mà không đem lại tính "ngay lập tức" tốt hơn.

D — S3 Lifecycle policies chuyển video sang Elastic Transcoder để xử lý. Sai về bản chất chức năng. Lifecycle policies chỉ quản lý storage class và vòng đời của object (chuyển tầng lưu trữ, hết hạn, xoá) — chúng không phải là cơ chế kích hoạt xử lý, không tích hợp trực tiếp với Elastic Transcoder, và không phản ứng theo sự kiện upload. Đây là phương án dùng sai công cụ hoàn toàn, không phải chuyện "kém tối ưu".

📌 Điểm cần nhớ

• "Ngay sau khi upload lên S3" gần như luôn dẫn tới S3 Event Notifications, thường ghép với Lambda — đây là mẫu kiến trúc event-driven kinh điển cần nhận ra ngay khi đọc đề.
• S3 Lifecycle policies chỉ quản vòng đời lưu trữ, không phải cơ chế trigger xử lý. Thấy phương án dùng Lifecycle để "khởi động một job" thì loại được ngay mà không cần cân nhắc thêm.
• CloudWatch Events/EventBridge không sai về nguyên tắc, nhưng thua về độ trực tiếp khi nguồn sự kiện chính là S3. Trong câu hỏi so sánh, hãy chọn cơ chế gắn liền với chính dịch vụ phát sinh sự kiện.
• Một phương án tốt phải trả lời cả hai vế: ai phát hiện sự kiện và ai chạy công việc. Phương án chỉ nêu phần trigger mà bỏ lửng phần thực thi và ghi output thường là bẫy.
• AWS Data Pipeline thiên về workflow dữ liệu có điều phối, không phải phản ứng tức thời từng object — khi đề nhấn mạnh tính tức thì, nó là lựa chọn quá nặng.

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

Đề mô tả một công ty có nhiều nguồn dữ liệu, lưu ở nhiều định dạng khác nhau trên Amazon S3, và muốn các data analyst dễ dàng tìm ra (discover) và truy cập những tập dữ liệu đó để phân tích.

Cụm từ quyết định đáp án nằm ngay ở câu hỏi cuối: "automate the creation of a data catalog". Hai chữ này khoá chặt phạm vi lựa chọn:

• "data catalog" — thứ cần tạo ra là metadata (bảng, schema, kiểu cột, partition) mô tả dữ liệu nằm ở đâu trên S3, chứ không phải bản sao dữ liệu, cũng không phải kết quả truy vấn.
• "automate" — công ty không muốn ai đó ngồi khai báo schema bằng tay. Bất kỳ phương án nào có chữ manually trong chính nội dung của nó đều tự loại mình.

Thêm chi tiết "different formats" củng cố hướng đi: cần một công cụ tự suy ra schema (schema inference) cho nhiều định dạng khác nhau, thay vì viết logic đọc từng định dạng.

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

Đáp án đúng theo tệp là C — dùng AWS Glue Crawler quét dữ liệu trên S3 và tự động điền vào AWS Glue Data Catalog.

Đây đúng là công việc mà Glue Crawler sinh ra để làm: nó quét (crawl) dữ liệu trong Amazon S3 và các data store khác, tự suy ra schema, rồi tạo các bảng metadata trong AWS Glue Data Catalog.

Ba điểm khớp trọn vẹn với đề:

1. Tự động — crawler chạy theo lịch hoặc theo yêu cầu, không cần người khai báo bảng.
2. Nhiều định dạng — crawler xử lý được nhiều định dạng dữ liệu khác nhau, đúng tình huống "multiple data sources stored in different formats".
3. Bám theo thay đổi — khi cấu trúc dữ liệu đổi, crawler cập nhật lại catalog, giảm can thiệp thủ công.

Kết quả là AWS Glue Data Catalog trở thành nơi tra cứu chung: analyst mở ra là thấy có những tập dữ liệu nào, gồm cột gì, nằm ở đâu — tức là đạt đúng mục tiêu "easily discoverable for analysis".

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

A — Dùng Amazon Athena để truy vấn thủ công các tập dữ liệu S3 rồi tự dựng data catalog. Đây là phương án gần đúng nhất và dễ mắc bẫy, vì Athena thật sự có mặt trong thế giới "phân tích dữ liệu trên S3". Nhưng Athena là query service — nó dùng SQL để đọc dữ liệu trên S3, chứ không phải công cụ tạo và duy trì catalog một cách tự động. Athena là bên tiêu thụ catalog, không phải bên sinh ra catalog. Phương án còn ghi rõ chữ manually, đi ngược yêu cầu "automate" trong đề.

B — Cấu hình Amazon RDS để tạo và duy trì một catalog dạng cơ sở dữ liệu quan hệ cho dữ liệu S3. RDS là dịch vụ relational database, không có bất kỳ khả năng cataloging tự động nào. Chọn phương án này nghĩa là bạn phải tự viết toàn bộ phần quét S3, tự suy schema, tự chèn bản ghi metadata vào bảng — công việc mà Glue Crawler làm sẵn. Kết quả là một catalog thủ công, tốn công duy trì và lệch khỏi dữ liệu thật ngay khi cấu trúc thay đổi.

D — Dùng AWS Lambda quét các S3 bucket rồi cập nhật thủ công một bảng Amazon DynamoDB làm data catalog. Về mặt kỹ thuật, Lambda có thể quét bucket — nên phương án nghe có vẻ khả thi. Chỗ hỏng nằm ở nửa sau: cập nhật DynamoDB thủ công để làm catalog là cách làm tốn thời gian và không hiệu quả. Nó thiếu hẳn phần phát hiện schema tự động và các tính năng cataloging mà Glue Crawler cung cấp. Đây là tự xây lại một dịch vụ đã có sẵn, bằng code phải tự bảo trì.

📌 Điểm cần nhớ

• Thấy đề nói "tự động tạo data catalog cho dữ liệu trên S3" → phản xạ đầu tiên là AWS Glue Crawler + AWS Glue Data Catalog.
• Phân biệt vai trò: Glue Crawler/Data Catalog sinh ra metadata, còn Athena là bên tiêu thụ metadata đó để chạy SQL. Đề hỏi tạo catalog thì chọn Glue, hỏi truy vấn thì mới tới Athena.
• Trong đề trắc nghiệm, chữ "manually" nằm ngay trong nội dung một phương án gần như luôn là dấu hiệu loại, khi câu hỏi yêu cầu "automate" hoặc "efficient".
• Phương án kiểu Lambda + DynamoDB tự xây hoặc RDS tự quản lý metadata là mô-típ "tự dựng lại dịch vụ managed đã có": chạy được nhưng thua về công sức vận hành, nên hầu như không phải đáp án đúng.

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

Đề mô tả một viện nghiên cứu cần chuyển một tập dữ liệu lớn đang nằm trên hệ thống NAS (Network Attached Storage) tại data center on-premises lên AWS để làm analytics.

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

• "stored on a Network Attached Storage (NAS) system" — nguồn dữ liệu là NAS, tức là chia sẻ tệp qua NFS/SMB. Đây là loại nguồn mà câu hỏi muốn bạn nhận ra ngay.
• "transferred securely and efficiently" — cần một dịch vụ truyền dữ liệu thật sự, có mã hoá và tối ưu đường truyền, chứ không phải chỉ có đường mạng.
• "with minimal downtime to ongoing research activities" — hoạt động nghiên cứu vẫn đang chạy, nên phương án nào làm gián đoạn việc truy cập dữ liệu hoặc bắt phải chờ đợi thao tác vật lý sẽ bị loại.

Ràng buộc phân biệt mạnh nhất là "minimal downtime" + nguồn NAS: đề muốn một cách chuyển online, tự động hoá, không đụng vào nếp làm việc hiện tại.

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

Đáp án đúng là A — Use AWS DataSync to automate the transfer of data from the NAS system to AWS.

AWS DataSync là dịch vụ truyền dữ liệu online, sinh ra đúng cho việc di chuyển dữ liệu giữa hệ thống lưu trữ on-premises và các dịch vụ lưu trữ của AWS. Nó đọc được trực tiếp các NAS chia sẻ qua NFS/SMB và ghi sang đích như Amazon S3 hay Amazon EFS.

Ba điểm khớp với từng ràng buộc trong đề:

• NAS: DataSync kết nối thẳng vào file share của NAS, không cần viết script đồng bộ thủ công.
• Securely and efficiently: dữ liệu được mã hoá khi truyền, và dịch vụ tự lo phần tăng tốc, xác thực tính toàn vẹn, thử lại khi lỗi.
• Minimal downtime: đây là chuyển dữ liệu online chạy nền, việc truyền có thể lập lịch và tự động hoá, nên nhóm nghiên cứu vẫn tiếp tục dùng NAS trong lúc dữ liệu được sao lên AWS.

DataSync còn chạy được cả trên Internet lẫn trên AWS Direct Connect — nghĩa là nó là lớp truyền dữ liệu, còn Direct Connect chỉ là lớp đường truyền bên dưới.

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

B — AWS Snowball để vận chuyển dữ liệu bằng thiết bị vật lý. Snowball là giải pháp chuyển dữ liệu vật lý, hợp lý khi khối lượng dữ liệu quá lớn hoặc đường truyền quá yếu để chuyển qua mạng trong thời gian chấp nhận được. Nhưng ở đây nó vướng đúng ràng buộc của đề: phải đặt thiết bị, chờ giao hàng, sao chép dữ liệu ra thiết bị rồi gửi trả — quy trình đó gây gián đoạn nhiều hơn cho hoạt động nghiên cứu đang chạy so với một lần chuyển online. Đề không hề nói băng thông là vấn đề, nên không có lý do gì để nhảy sang phương án vật lý.

C — AWS Direct Connect. Đây là phương án gần đúng và dễ bị chọn nhầm nhất. Direct Connect cung cấp một kết nối mạng riêng, ổn định giữa on-premises và AWS — nhưng bản thân nó không truyền dữ liệu. Nó chỉ là ống dẫn; bạn vẫn cần một công cụ ở trên để đọc từ NAS và ghi vào S3/EFS. Ngoài ra Direct Connect hợp với nhu cầu truyền dữ liệu thường xuyên, liên tục, còn đề này là một cuộc migration. Chọn C là chọn hạ tầng thay vì chọn dịch vụ làm việc.

D — AWS Storage Gateway đồng bộ dữ liệu NAS sang Amazon S3. Cũng gần đúng vì Storage Gateway đúng là đưa được dữ liệu lên AWS. Chỗ nó hỏng: Storage Gateway được thiết kế cho các tình huống tích hợp lâu dài với môi trường on-premises — cho ứng dụng tại chỗ truy cập kho lưu trữ trên AWS, phục vụ backup và lưu trữ dài hạn. Nó là một lớp lưu trữ lai chạy thường trực, không phải công cụ migration một lần cho một tập dữ liệu lớn. Dùng nó ở đây là dựng một thành phần phải vận hành mãi về sau chỉ để giải quyết một việc chuyển dữ liệu.

📌 Điểm cần nhớ

• Nguồn là NAS/file share + cần chuyển lên AWS qua mạng → nghĩ tới DataSync trước tiên. Đây là mẫu câu hỏi lặp lại rất nhiều trong đề Data Engineer.
• Phân biệt "đường truyền" và "dịch vụ truyền dữ liệu". Direct Connect là đường truyền; DataSync là dịch vụ chuyển dữ liệu và chạy được trên Direct Connect. Câu hỏi hỏi "service for the migration" thì đáp án phải là thứ thật sự di chuyển dữ liệu.
• Snowball dành cho tình huống mạng không kham nổi — chỉ chọn khi đề nêu rõ băng thông thấp, dữ liệu ở mức rất lớn, hoặc địa điểm không có kết nối tốt. Đề nhấn "minimal downtime" mà không than phiền về băng thông thì Snowball là bẫy.
• Storage Gateway là giải pháp lưu trữ lai chạy thường trực (ứng dụng on-premises dùng kho AWS, backup, archive), không phải công cụ migration một lần. Thấy chữ "migration" thì cân nhắc DataSync; thấy "ứng dụng tại chỗ vẫn cần truy cập dữ liệu trên AWS lâu dài" thì mới tới Storage Gateway.