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

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

Công ty đang chuyển phần static content của website logistics từ EC2 sang S3, rồi phân phối qua CloudFront. Trước khi chuyển, quyền truy cập bị giới hạn bằng security group gắn trên EC2, chỉ mở cho một tập IP range của các nhà cung cấp. Sau khi chuyển, yêu cầu là: vẫn chỉ những dải IP đó mới xem được nội dung — chọn hai phương án kết hợp.

Cụm từ quyết định nằm ở hai chỗ. Thứ nhất, "access to the static content should only be allowed from the aforementioned IP addresses" — cần một cơ chế lọc theo IP, nhưng phải là cơ chế gắn được vào CloudFront, vì CloudFront chạy trên mạng edge location toàn cầu chứ không nằm trong một VPC hay subnet nào. Thứ hai, ẩn hơn nhưng quan trọng không kém: nếu chỉ lọc IP ở CloudFront mà bucket S3 vẫn cho truy cập trực tiếp, người ta bỏ qua CloudFront và gọi thẳng URL của bucket là vô hiệu hoá toàn bộ lớp lọc. Vì thế đề hỏi hai phương án chứ không phải một: một để lọc IP tại edge, một để bịt đường vòng vào S3.

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

B — Origin access control (OAC) + bucket policy chỉ cho OAC đọc object. OAC khiến CloudFront gửi request đã ký (authenticated request) tới origin S3, còn bucket policy được viết để chỉ chấp nhận đúng những request đó. Kết quả: bucket không còn public, và người dùng chỉ có thể lấy nội dung qua đúng distribution đã chỉ định — không vào thẳng bucket được, cũng không mượn một CloudFront distribution khác được. Đây chính là mảnh bịt đường vòng nói ở trên. AWS khuyến nghị dùng OAC vì nó hỗ trợ bucket ở mọi Region (kể cả các opt-in Region ra sau tháng 12/2022), hỗ trợ SSE-KMS, và hỗ trợ cả request động (POST, PUT…).

E — AWS WAF ACL với IP match condition, associate với CloudFront distribution. AWS WAF giám sát request HTTP/HTTPS tới các resource được bảo vệ, và CloudFront distribution nằm trong danh sách resource type mà WAF gắn được (cùng với API Gateway REST API, Application Load Balancer, AppSync GraphQL API, Cognito user pool). Với IP match condition, ta liệt kê đúng các dải IP đang có trong security group của EC2; request từ IP ngoài danh sách bị trả về HTTP 403 hoặc custom response. Đây là cách chuyển nguyên luật lọc IP cũ sang kiến trúc mới mà không cần security group.

Hai phương án bù nhau: E quyết định ai được gọi CloudFront, B đảm bảo CloudFront là lối vào duy nhất.

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

A — NACL gắn vào CloudFront distribution. Sai ở chỗ gắn. NACL là cơ chế của VPC, chỉ associate được với subnet. CloudFront phân phối nội dung qua mạng edge location toàn cầu, không nằm trong subnet nào của bạn, nên không có chỗ để gắn NACL. Ý tưởng lọc IP thì đúng hướng, nhưng công cụ đặt nhầm tầng mạng.

C — WAF ACL với IP match condition, nhưng associate với bucket policy của S3. Đây là phương án gần đúng nhất và dễ bẫy nhất: nội dung luật (IP match condition lấy từ security group) hoàn toàn giống phương án E đúng. Chỗ hỏng nằm đúng một chữ — đối tượng được gắn. Không thể associate một AWS WAF ACL với bucket policy của S3; S3 không phải resource type mà WAF bảo vệ, và bucket policy là tài liệu IAM chứ không phải nơi để "cắm" web ACL vào. Khi hai phương án chỉ khác nhau ở vế associate, hãy đọc kỹ vế đó.

D — Security group mới gắn vào CloudFront distribution. Cùng lỗi bản chất với A. Security group là virtual firewall cho EC2 instance, kiểm soát inbound/outbound của instance trong VPC. CloudFront không phải instance và không nằm trong VPC, nên không gắn security group vào distribution được. Đúng là luật IP cần được mang sang, nhưng phải mang sang WAF, không phải mang sang một security group khác.

📌 Điểm cần nhớ

• Security group và NACL là cơ chế trong VPC (instance / subnet). Với các dịch vụ edge như CloudFront, công cụ lọc IP theo tầng ứng dụng là AWS WAF với IP match condition.
• AWS WAF gắn được vào CloudFront distribution, API Gateway REST API, Application Load Balancer, AppSync GraphQL API, Cognito user pool — không gắn vào S3 bucket policy.
• Khi CloudFront đứng trước S3, lọc ở edge thôi là chưa đủ: phải dùng OAC + bucket policy chỉ cho OAC đọc để chặn đường truy cập thẳng vào bucket. Thiếu bước này thì mọi luật ở CloudFront đều bỏ qua được.
• Với câu "Select two", hãy đọc theo hướng hai mảnh bù nhau (kiểm soát ai vào + bịt lối đi vòng), và ở các phương án gần giống nhau thì điểm phân biệt thường nằm ở resource được associate, không nằm ở nội dung luật.

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

Một doanh nghiệp chuyển một bảng lõi hàng tỷ dòng sang Amazon Redshift. Trong bảng đó có một số cột chứa dữ liệu nhạy cảm, chỉ đội tài chính (finance team) được xem. Sau khi dữ liệu lên Redshift, nhiều đội khác nhau sẽ cùng chạy truy vấn trên chính bảng này.

Cụm từ quyết định nằm ở chỗ: phạm vi cần kiểm soát là cột, chứ không phải bảng, và tất cả các đội đều phải làm việc trên cùng một bảng. Hai chi tiết đi kèm siết thêm lựa chọn:

• "billions of rows" — mọi giải pháp đòi nhân bản dữ liệu ra nơi thứ hai đều trả giá bằng dung lượng lưu trữ và công đồng bộ, ở quy mô này là rất đắt.
• "only be accessed by the finance team" — quyền phải được thu hẹp cho các đội khác, chứ không phải mở rộng cho đội tài chính.

Nói cách khác, đề đang hỏi thẳng: Redshift có cơ chế phân quyền ở mức cột hay không, và bạn có dùng đúng cơ chế đó thay vì đi vòng bằng bảng phụ hay view hay không.

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

Đáp án đúng là D: cấp cho finance group quyền đọc bảng, rồi dùng lệnh GRANT của SQL để cấp quyền chỉ-đọc trên tập con các cột không nhạy cảm cho những người dùng còn lại.

Amazon Redshift hỗ trợ column-level access control — quyền được gắn trực tiếp lên từng cột của bảng hoặc view, thông qua chính GRANT/REVOKE mà bạn vẫn dùng cho quyền mức bảng. Cú pháp có dạng:

GRANT { { SELECT | UPDATE } ( column_name [, ...] ) [, ...] | ALL [ PRIVILEGES ] ( column_name [,...] ) }
    ON { [ TABLE ] table_name [, ...] }
    TO { username | GROUP group_name | PUBLIC } [, ...]

Cách này khớp chính xác yêu cầu của đề:

• Một bản dữ liệu duy nhất. Bảng hàng tỷ dòng không bị nhân đôi, không có bài toán đồng bộ giữa hai bản.
• Kiểm soát đúng đơn vị mà đề nói tới — cột, không phải bảng.
• Cấp theo group. Đội tài chính là một group được GRANT quyền đọc cả bảng; các đội khác chỉ nhận SELECT trên danh sách cột an toàn. Người mới vào chỉ cần thêm vào group tương ứng.
• Đây cũng là hướng AWS khuyến nghị cho việc kiểm soát truy cập các cột nhạy cảm bên trong một bảng.

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

A — Tạo bảng thứ hai chỉ chứa các cột không nhạy cảm, cấp quyền đọc bảng đó cho những người còn lại. Về mặt bảo mật thì phương án này có đạt mục tiêu: các đội khác không nhìn thấy cột nhạy cảm. Nhưng nó hỏng ở chỗ hiệu quả. Với bảng hàng tỷ dòng, bạn đang nhân bản gần như toàn bộ khối dữ liệu chỉ để giấu vài cột — tốn dung lượng lưu trữ, và sinh thêm nghĩa vụ giữ hai bảng đồng bộ mỗi khi bảng gốc thay đổi. Khi Redshift đã cho phân quyền thẳng trên cột của bảng gốc thì việc sao chép này là thừa.

B — Cấp cho mọi người quyền đọc các cột không nhạy cảm, rồi đưa đội tài chính vào group administrator. Nửa đầu đúng hướng, nhưng nửa sau là lỗi nghiêm trọng về nguyên tắc least privilege. Đội tài chính chỉ cần đọc một số cột; đưa họ vào group quản trị là trao kèm quyền quản trị toàn hệ thống — tạo/xoá bảng, đụng vào dữ liệu của mọi đội khác. Bạn dùng một quyền rất rộng để đạt một nhu cầu rất hẹp, và mở ra rủi ro lớn hơn chính vấn đề đang muốn giải.

C — Tạo một view chỉ gồm các cột không nhạy cảm, cấp quyền đọc view đó cho những người còn lại. Đây là phương án gần đúng nhất, và trước khi Redshift có column-level access control thì nó chính là cách làm phổ biến. View không nhân bản dữ liệu nên tránh được điểm yếu của A. Chỗ nó hỏng: đây là giải pháp đi vòng khi cơ chế đúng đã tồn tại. AWS khuyến nghị dùng column-level access control thay cho view để quản lý truy cập các cột nhạy cảm trong một bảng. Quản lý bằng view còn kéo theo chi phí vận hành — mỗi lần bảng đổi cấu trúc lại phải rà và sửa view, và quyền nằm rải ở hai đối tượng (bảng và view) thay vì tập trung một chỗ. Trong bài thi, khi một phương án dùng đúng tính năng gốc còn phương án kia lách bằng object phụ, phương án đầu thắng.

📌 Điểm cần nhớ

• Redshift phân quyền được tới mức cột bằng chính GRANT/REVOKE, không chỉ mức bảng. Đề nào nói "một số cột nhạy cảm trong cùng một bảng" thì nghĩ ngay tới column-level access control.
• AWS khuyến nghị column-level access control thay cho view khi mục tiêu là che cột nhạy cảm — view không sai về kết quả, nhưng là cách làm cũ và tốn công bảo trì hơn.
• Nhân bản dữ liệu để phân quyền là dấu hiệu của phương án sai, nhất là khi đề nhấn mạnh quy mô bảng ("billions of rows"). Chi phí lưu trữ và nghĩa vụ đồng bộ là hai điểm trừ luôn có.
• Đừng bao giờ giải bài toán quyền bằng cách nâng ai đó lên administrator. Nếu một phương án mở rộng quyền thay vì thu hẹp, gần như chắc chắn nó sai — cứ bám nguyên tắc least privilege.
• Cấp quyền theo group, không theo từng user. Đề nói "finance team" là gợi ý dùng group; việc thêm/bớt người sau này không phải sửa lại quyền.

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

Một công ty phân tích dữ liệu thu thập dữ liệu thời gian thực tại data center on-premises của họ, rồi mỗi ngày nén toàn bộ feed thành một file duy nhất khoảng 2 GB và đẩy lên Amazon S3 để backup. Câu hỏi: cách nào nhanh nhất để upload file nén hằng ngày đó lên Amazon S3?

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

• "on-premises data center" — dữ liệu đi từ mạng của khách hàng ra Internet tới S3, tức là truyền khoảng cách xa qua đường công cộng. Đây chính là bài toán mà Amazon S3 Transfer Acceleration sinh ra để giải.
• "a single file… around 2 gigabytes" — một đối tượng lớn, vượt xa ngưỡng mà AWS khuyến nghị chuyển sang multipart upload thay vì upload một lần.
• "the fastest way" — không hỏi cách rẻ nhất, cũng không hỏi cách đơn giản nhất. Khi đề hỏi nhanh nhất, phương án kết hợp được nhiều kỹ thuật tăng tốc sẽ thắng phương án chỉ dùng một kỹ thuật.

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

C — Upload the compressed file using multipart upload with Amazon S3 Transfer Acceleration (Amazon S3TA)

Phương án này gộp hai cơ chế tăng tốc, mỗi cái xử lý một nút thắt khác nhau:

• Multipart upload chia object thành nhiều phần liên tiếp, upload song song và theo thứ tự bất kỳ. Với đường truyền băng thông rộng ổn định, upload nhiều phần cùng lúc giúp tận dụng tối đa băng thông sẵn có thay vì bị giới hạn bởi một luồng TCP duy nhất. Thêm nữa, phần nào lỗi thì chỉ cần truyền lại đúng phần đó, không phải upload lại từ đầu — điểm này rất có giá trị với file 2 GB đi qua đường mạng không hoàn hảo. Upload xong hết các phần, S3 ghép lại thành object.
• Amazon S3 Transfer Acceleration tận dụng mạng lưới edge location phân tán toàn cầu của Amazon CloudFront. Dữ liệu từ client đi tới edge location gần nhất, rồi từ đó đi tiếp về bucket S3 qua đường mạng backbone đã được tối ưu của AWS thay vì lang thang trên Internet công cộng. Chặng đường xa — đúng tình huống on-premises trong đề — chính là nơi cơ chế này phát huy tác dụng.

Hai kỹ thuật này không loại trừ nhau: bạn hoàn toàn có thể bật Transfer Acceleration trên bucket rồi thực hiện multipart upload qua endpoint tăng tốc. Vì đề hỏi nhanh nhất, kết hợp cả hai là câu trả lời.

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

A — Upload the compressed file using multipart upload

Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Multipart upload thật sự có làm quá trình nhanh hơn: song song hoá luồng, chống lỗi mạng tốt hơn. Chỗ nó hỏng không nằm ở kỹ thuật mà nằm ở mức độ: multipart tối ưu việc dùng hết băng thông sẵn có, nhưng không làm gì được với chất lượng đường truyền từ on-premises ra tới region của bucket. Bổ sung S3 Transfer Acceleration vào đúng chỗ đó sẽ cải thiện thêm nữa. Khi đề hỏi "fastest", một phương án tốt vẫn thua phương án tốt hơn.

B — Upload the compressed file in a single operation

Sai vì kích thước file. Hướng dẫn của AWS là khi object đạt cỡ khoảng trăm megabyte trở lên thì nên cân nhắc multipart upload thay cho upload một lần — file ở đây là 2 GB, vượt xa ngưỡng đó. Upload một thao tác đơn nghĩa là một luồng duy nhất, không tận dụng được throughput song song, và nếu đứt giữa chừng thì mất trắng cả 2 GB, phải làm lại từ đầu. Đây là phương án chậm nhất trong bốn phương án.

D — FTP file vào một Amazon EC2 instance cùng region với bucket, rồi chuyển từ EC2 sang Amazon S3

Về mặt kỹ thuật thì làm được, nhưng đây là đường vòng và là distractor. Vấn đề: chặng chậm nhất — từ on-premises ra AWS — vẫn còn nguyên, bạn chỉ đổi đích đến của nó từ S3 sang EC2 chứ không rút ngắn được gì. Sau đó lại thêm một chặng ghi từ EC2 lên S3 nữa. Tức là dữ liệu bị chạm hai lần thay vì một lần. Chưa kể phải dựng và duy trì EC2 instance, cấu hình FTP server, viết script tự động hoá cho quy trình chạy hằng ngày, và trả thêm tiền cho instance cùng dung lượng lưu trữ tạm. Nhiều công sức hơn hẳn mà không nhanh hơn.

📌 Điểm cần nhớ

• Multipart upload giải bài toán object lớn: song song hoá để tận dụng băng thông, và cho phép truyền lại từng phần khi lỗi thay vì làm lại cả file. Object cỡ trăm MB trở lên là nên dùng.
• Amazon S3 Transfer Acceleration giải bài toán khoảng cách xa: đi qua edge location của CloudFront rồi vào backbone AWS. Tín hiệu nhận biết trong đề là những cụm như "on-premises", "long distance", hoặc client ở khác châu lục với bucket.
• Hai cơ chế này bổ sung cho nhau, không thay thế nhau. Khi đề hỏi "fastest" mà danh sách có cả "multipart" lẫn "multipart + S3TA", phương án kết hợp là đáp án — phương án đơn lẻ chỉ là bẫy gần đúng.
• Cảnh giác với phương án chèn thêm một chặng trung gian (EC2, FTP server…) để "tăng tốc": nếu chặng nghẽn thật sự vẫn còn nguyên, thêm bước chỉ làm dữ liệu phải đi qua nhiều điểm hơn và thêm việc vận hành.

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

Đề mô tả một bucket Amazon S3 nhận đủ mọi định dạng dữ liệu, nhưng chỉ tệp .csv mới cần được chuyển sang Apache Parquet cho các ứng dụng phía sau. Câu hỏi là chọn cách nối S3 với hàm Lambda làm việc chuyển đổi đó.

Có hai cụm từ quyết định trong đề, và cả bốn phương án đều xoay quanh đúng hai cụm ấy:

1. "only the .csv files are uploaded" — chữ uploaded (được tải lên / được tạo ra) giới hạn phạm vi sự kiện: ta chỉ quan tâm sự kiện tạo object, chứ không phải mọi loại sự kiện của S3. Đây là chỗ phân biệt s3:ObjectCreated:* với s3:*.
2. "LEAST operational overhead" — cụm này luôn là ràng buộc phá thế hoà giữa hai phương án cùng chạy được. Nó phân biệt "S3 gọi thẳng Lambda" với "S3 → EventBridge → Lambda".

Cả bốn phương án đều dùng chung một suffix filter .csv, nên bộ lọc suffix không phải điểm phân biệt — đừng mất thời gian ở đó. Bài toán rút gọn thành ma trận 2×2: kiểu sự kiện (s3:* hay s3:ObjectCreated:*) × đích đến (Lambda ARN trực tiếp hay qua EventBridge).

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

Phương án B: s3:ObjectCreated:* + suffix filter .csv + đặt ARN của Lambda làm destination.

• s3:ObjectCreated:* gom đúng nhóm sự kiện tạo object: s3:ObjectCreated:Put, s3:ObjectCreated:Post, s3:ObjectCreated:Copy và s3:ObjectCreated:CompleteMultipartUpload. Dùng dấu * ở đây có ý nghĩa: object có thể sinh ra bằng PUT, POST, COPY hoặc multipart upload, và ta muốn bắt hết các đường đó mà không phải khai báo riêng từng loại. CompleteMultipartUpload cũng phủ luôn các object tạo bằng UploadPartCopy — quan trọng vì tệp dữ liệu lớn thường lên bằng multipart.
• Suffix filter .csv lọc ngay tại tầng S3 notification, nên Lambda không bị gọi cho những định dạng khác trong cùng bucket. Lọc ở nguồn rẻ hơn là gọi Lambda rồi để code tự kiểm tra đuôi tệp.
• Đặt thẳng Lambda function ARN làm destination của S3 event notification là đường ngắn nhất: một cấu hình duy nhất trên bucket, không thêm dịch vụ trung gian nào phải dựng, phân quyền và giám sát. Đó chính là "LEAST operational overhead".

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

A — s3:* + EventBridge: sai cả hai vế. Vế kiểu sự kiện, s3:* phát thông báo cho mọi loại sự kiện S3 chứ không riêng lúc object được tạo, nên Lambda bị đánh thức bởi những sự kiện không liên quan đến yêu cầu. Vế đích đến, nó lại thêm EventBridge vào giữa mà không có lý do nghiệp vụ nào. Đây là phương án tệ nhất trong bốn.

C — s3:ObjectCreated:* + EventBridge: đây là phương án gần đúng nhất, và cũng là cái đáng phân tích kỹ. Kiểu sự kiện của nó hoàn toàn chính xác; nó chỉ hỏng ở đích đến. Chuỗi S3 → EventBridge → Lambda là đường vòng: bạn phải bật gửi sự kiện tới EventBridge cho bucket, viết thêm một EventBridge rule với pattern khớp, cấp quyền cho rule gọi Lambda, rồi khi gỡ lỗi phải lần qua hai tầng thay vì một. Thêm một điểm đáng nhớ về hành vi: với EventBridge, việc bật/tắt là ở mức bucket — bật lên thì mọi sự kiện của bucket đều được gửi sang EventBridge, việc thu hẹp phạm vi chuyển sang nằm ở event pattern của rule chứ không nằm ở cấu hình notification nữa. Tất cả những thứ đó là operational overhead tăng thêm mà không đổi lấy được năng lực gì đề bài cần. EventBridge chỉ đáng dùng khi bạn cần fan-out tới nhiều đích, lọc theo nội dung phức tạp, archive/replay sự kiện, hay gửi chéo tài khoản — đề này không đòi hỏi gì trong số đó.

D — s3:* + Lambda ARN trực tiếp: đích đến đúng, nhưng kiểu sự kiện sai. s3:* đăng ký toàn bộ họ sự kiện của S3, nghĩa là Lambda sẽ được gọi cho những chuyện chẳng liên quan gì đến việc "có tệp .csv mới được tải lên". Suffix filter .csv không cứu được điều này, vì nó lọc theo tên khoá object, không lọc theo loại sự kiện — một sự kiện thuộc loại khác nhưng trỏ vào một object tên .csv vẫn lọt qua bộ lọc. Kết quả là hàm chuyển đổi bị kích hoạt thừa, tốn tiền và có nguy cơ xử lý lặp.

📌 Điểm cần nhớ

• Chọn kiểu sự kiện hẹp nhất phủ đủ nhu cầu. "Tệp được tải lên" ⇒ s3:ObjectCreated:*, không phải s3:*. Dấu * trong ObjectCreated:* là để phủ hết PUT/POST/COPY/CompleteMultipartUpload — hợp lý; còn s3:* là phủ hết mọi họ sự kiện — thừa.
• Prefix/suffix filter lọc theo tên khoá object, không lọc theo loại sự kiện. Hai bộ lọc này độc lập nhau; có filter .csv rồi vẫn phải chọn đúng event type.
• "LEAST operational overhead" ⇒ ưu tiên tích hợp trực tiếp. S3 event notification gọi thẳng Lambda ARN thắng chuỗi S3 → EventBridge → Lambda khi bài toán chỉ có một đích và một điều kiện lọc đơn giản.
• Biết khi nào EventBridge mới xứng công sức: cần nhiều consumer cho cùng một sự kiện, lọc theo nội dung phức tạp, gửi chéo tài khoản/region, hoặc archive & replay. Không có nhu cầu nào trong số đó thì nó chỉ là một mắt xích phải vận hành thêm.

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

Đề mô tả một database SQL Server chạy trên RDS chứa dữ liệu giao dịch lịch sử, và cần tự động hoá hai việc: định kỳ tìm dữ liệu cũ hơn 3 tháng, rồi xuất ra S3 để lưu trữ dài hạn với chi phí thấp.

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

• "Select two" — câu này cần hai mảnh ghép, không phải một giải pháp trọn gói. Đọc kỹ sẽ thấy đề nêu đúng hai vế: (1) tự động export từ SQL Server sang S3, và (2) lifecycle management trong S3. Mỗi vế lấy một phương án.
• "least operational overhead" — ưu tiên dịch vụ được quản lý sẵn, hạn chế phần mình phải tự viết và tự bảo trì.
• "long-term, cost-effective storage" — dữ liệu lịch sử đưa vào kho lưu trữ lâu dài, gần như không truy cập lại. Đây là cụm từ tách bạch hai phương án lifecycle nhìn rất giống nhau (B và C).

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

D — dùng AWS DMS chạy task định kỳ để chuyển dữ liệu cũ hơn 3 tháng từ RDS sang S3. DMS là dịch vụ được quản lý dùng để di chuyển và sao chép dữ liệu, hỗ trợ SQL Server làm nguồn và S3 làm đích. Điểm quan trọng: database nguồn vẫn hoạt động bình thường trong lúc migrate, nên tác vụ archive không làm gián đoạn ứng dụng đang chạy trên RDS. Task DMS được cấu hình một lần rồi chạy định kỳ (ví dụ hằng tuần), không cần viết và duy trì mã tự chế — đúng tinh thần "least operational overhead".

B — cấu hình S3 lifecycle rules để chuyển dữ liệu đã archive sang S3 Glacier Deep Archive. Đây là vế lifecycle management mà đề hỏi. Glacier Deep Archive là storage class dành riêng cho lưu trữ dài hạn, dữ liệu gần như không đọc lại — đúng với dữ liệu giao dịch cũ hơn 3 tháng. Lifecycle rule là cấu hình khai báo trên chính bucket, S3 tự thực thi, không cần bất kỳ tiến trình nào của bạn canh chừng.

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

A — Lambda function xuất dữ liệu cũ từ RDS sang S3, trigger bằng Amazon CloudWatch RDS Events. Đây là phương án gãy ở cơ chế trigger, chứ không phải ở ý tưởng. RDS event là sự kiện phản ánh thay đổi trong môi trường RDS: DB instance, DB parameter group, DB security group, DB snapshot, RDS Proxy, Blue/green deployment. RDS events không phát sinh theo thay đổi dữ liệu, nên không có sự kiện nào tương ứng với "có dữ liệu vừa đủ 3 tháng tuổi". Trigger sai nguồn thì cả luồng không bao giờ chạy đúng lúc cần. Chưa kể phần Lambda tự viết vẫn là mã phải tự bảo trì, nặng hơn một task DMS khai báo sẵn.

C — lifecycle rule chuyển sang S3 Intelligent-Tiering. Phương án gần đúng nhất, và cũng là chỗ dễ mất điểm. Intelligent-Tiering thực sự tối ưu chi phí và thực sự không tốn công vận hành — nó tự động dịch chuyển dữ liệu sang access tier hợp lý khi mẫu truy cập thay đổi. Nhưng công dụng đó dành cho dữ liệu có mẫu truy cập không biết trước hoặc thay đổi thất thường. Ở đây mẫu truy cập đã biết rõ ngay từ đầu: dữ liệu cũ hơn 3 tháng, archive để giữ lâu dài. Với bài toán long-term archival, Intelligent-Tiering không phải lựa chọn phù hợp — trả tiền cho khả năng tự dò mẫu truy cập trong khi mình đã biết câu trả lời.

E — Step Functions dựng workflow gọi DataSync để sync file database sang S3. Sai ở hai điểm. Thứ nhất, nó phức tạp không cần thiết: thêm một lớp orchestration cho việc mà một task DMS làm trọn. Thứ hai, bản thân Step Functions cũng cần một trigger — dựng workflow xong vẫn còn nguyên câu hỏi "ai gọi nó chạy định kỳ", tức là chưa giải quyết xong phần tự động hoá mà lại tăng số thành phần phải vận hành.

📌 Điểm cần nhớ

• Câu "Select two" mô tả hai yêu cầu tách bạch trong đề (ở đây: export + lifecycle) thì gần như chắc chắn mỗi yêu cầu lấy một đáp án — đừng tìm hai phương án cùng giải quyết một vế.
• Phân biệt Glacier Deep Archive với S3 Intelligent-Tiering theo mẫu truy cập: mẫu đã biết và là archive lâu dài → Deep Archive; mẫu không đoán trước được hoặc thay đổi → Intelligent-Tiering.
• RDS events là sự kiện hạ tầng, không phải sự kiện dữ liệu. Bất kỳ phương án nào dùng RDS event để phản ứng với nội dung bảng đều sai về nguyên tắc.
• Với "least operational overhead", ưu tiên dịch vụ quản lý cấu hình sẵn (DMS, S3 lifecycle rule) hơn mã tự viết (Lambda) hay chuỗi orchestration nhiều tầng (Step Functions + DataSync). Cũng nên hỏi thêm: phương án đó đã tự chạy được chưa, hay vẫn còn thiếu một trigger?

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

Đề cho một bảng MySQL tên user, cột name chứa họ tên người dùng. Yêu cầu: viết truy vấn trả về mọi bản ghi có giá trị cột name bắt đầu bằng John hoặc Doe, và việc so khớp phải không phân biệt chữ hoa chữ thường.

Chi tiết về "vài người bị lưu ngược thành lastname firstname" chỉ là bối cảnh giải thích vì sao phải tìm cả John lẫn Doe ở đầu chuỗi — nó không thêm ràng buộc kỹ thuật nào.

Hai cụm từ quyết định đáp án nằm ngay trong câu hỏi:

• "starting with" → phải neo mẫu vào đầu chuỗi, tức ký tự ^.
• "on a case-insensitive basis" → phải dùng toán tử regex không phân biệt hoa thường, tức ~* chứ không phải ~.

Bốn phương án chính là bốn tổ hợp của hai lựa chọn nhị phân đó: ~ hay ~*, và ^ hay $. Chỉ cần đọc đúng hai cụm từ trên là loại được ba phương án còn lại mà không cần chạy thử.

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

Đáp án đúng theo tệp là D:

SELECT * FROM user WHERE name ~ * '^(John|Doe)'

Ghép đủ cả hai yêu cầu của đề:

• Toán tử ~ là toán tử so khớp biểu thức chính quy (regular expression) trong SQL. Biến thể ~* thực hiện đúng phép so khớp đó nhưng bỏ qua phân biệt hoa thường, nên john, JOHN, John đều khớp — đáp ứng vế "case-insensitive".
• Trong biểu thức chính quy, ^ neo mẫu vào đầu chuỗi, nên ^(John|Doe) chỉ khớp những giá trị mở đầu bằng John hoặc Doe — đáp ứng vế "starting with".
• Nhóm ngoặc ( ... ) cùng dấu | diễn đạt phép chọn một trong hai nhánh, và vì ^ đứng ngoài nhóm nên nó áp cho cả hai nhánh — đúng ý "bắt đầu bằng John hoặc Doe".

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

A. WHERE name ~ '^(John|Doe)' — Đây là phương án gần đúng nhất, và chỉ hỏng đúng một chỗ. Mẫu ^(John|Doe) hoàn toàn chính xác về vị trí: nó neo vào đầu chuỗi như đề yêu cầu. Nhưng toán tử là ~ chứ không phải ~*, nghĩa là so khớp phân biệt hoa thường. Bản ghi lưu là JOHN SMITH hay john smith sẽ bị bỏ sót, trong khi đề nói rõ phải tìm trên cơ sở case-insensitive. Đây là kiểu bẫy điển hình: phương án làm đúng phần khó (regex) rồi trượt ở đúng một ký tự *.

C. WHERE name ~ '$(John|Doe)' — Sai cả hai vế. Ký tự $ neo mẫu vào cuối chuỗi, ngược hẳn với "starting with" mà đề đòi. Ngoài ra toán tử vẫn là ~ nên cũng phân biệt hoa thường. Đây là phương án tệ nhất trong bốn phương án.

B. WHERE name ~ * '$(John|Doe)' — Đã sửa được vế hoa thường (dùng ~* là đúng), nhưng vẫn dùng $ thay vì ^. $ neo vào cuối chuỗi, tức là ý đồ của mẫu này trở thành "kết thúc bằng John hoặc Doe", trong khi đề hỏi "bắt đầu bằng". Với dữ liệu của đề, hai điều kiện này cho ra tập kết quả khác hẳn nhau: một người tên John Doe sẽ khớp mẫu ^, còn Doe John mới là thứ khớp mẫu $. Nhớ rằng đề cố tình nói có người bị lưu ngược thứ tự — dùng nhầm $ là bắt đúng nhóm bản ghi ngược lại với ý định.

📌 Điểm cần nhớ

• Trong SQL, ~ là toán tử so khớp regex; thêm dấu * thành ~* để so khớp không phân biệt hoa thường. Đề bài có chữ "case-insensitive" là tín hiệu trực tiếp bắt phải dùng ~*.
• ^ neo vào đầu chuỗi, $ neo vào cuối chuỗi. Ánh xạ thẳng: "starts with / begins with" → ^, "ends with" → $. Đây là cặp hay bị hoán đổi nhất trong các câu hỏi regex.
• Khi bốn phương án chỉ khác nhau ở vài ký tự, hãy tách chúng thành các trục lựa chọn độc lập (ở đây: toán tử ~ vs ~*, và mỏ neo ^ vs $), rồi loại theo từng trục. Cách này nhanh và ít sai hơn đọc tuần tự từng phương án.
• Chi tiết kể chuyện trong đề (dữ liệu legacy lưu ngược lastname firstname) thường chỉ để giải thích lý do nghiệp vụ, không phải ràng buộc kỹ thuật — ràng buộc thật nằm ở những cụm từ mô tả hành vi truy vấn cần đạt được.

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

Đề mô tả một kỹ sư dữ liệu chạy phân tích nặng nhưng chỉ một lần mỗi tháng trên Amazon Redshift. Mỗi lần lại tự tay dựng một provisioned cluster mới, chạy xong thì sao lưu dữ liệu sang S3 rồi xoá cluster đi. Câu hỏi yêu cầu tìm giải pháp "minimizes the need for manual infrastructure management" và "with the lowest operational overhead".

Hai cụm từ đó chính là ràng buộc quyết định. Đề không hỏi cách tiết kiệm chi phí, cũng không hỏi cách tự động hoá quy trình sẵn có — nó hỏi cách bỏ hẳn việc quản lý hạ tầng. Thêm một chi tiết quan trọng nữa: khối lượng công việc có tính gián đoạn, không liên tục (mỗi tháng một lần, giữa các lần thì không có gì chạy). Ai bám vào hai điểm này — bỏ quản lý hạ tầng và workload chỉ chạy từng đợt — sẽ loại được ba phương án còn lại rất nhanh.

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

D — Use Amazon Redshift Serverless.

Amazon Redshift Serverless tự cấp phát năng lực data warehouse và tự co giãn tài nguyên bên dưới theo nhu cầu, nên người dùng không phải set up, tune hay quản lý provisioned cluster nữa. Đây đúng là thứ mà đề đang tìm: bỏ toàn bộ vòng lặp "dựng cluster → chạy → sao lưu → xoá cluster" mà kỹ sư đang làm bằng tay mỗi tháng.

Những điểm khớp trực tiếp với tình huống trong đề:

• Vẫn dùng được đầy đủ khả năng SQL của Amazon Redshift, hiệu năng cao và tích hợp data lake — truy vấn xuyên qua data warehouse, data lake và nguồn dữ liệu vận hành.
• Tự động co giãn thông minh, giữ hiệu năng ổn định cho cả những workload nặng và biến động thất thường — đúng đặc tính "resource-intensive, mỗi tháng một lần" của đề.
• Chỉ trả tiền khi data warehouse thực sự được dùng, nên khoảng thời gian giữa hai lần phân tích không phát sinh chi phí compute — thay thế được động cơ ban đầu khiến kỹ sư phải xoá cluster đi.
• Tổ chức tài nguyên và dữ liệu bằng workgroup và namespace, có cơ chế kiểm soát chi phí ở mức chi tiết.
• Truy cập được cả Amazon Redshift managed storage lẫn dữ liệu trong S3 data lake.

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

A — Use zero-ETL integrations. Zero-ETL integration là giải pháp fully managed giúp đưa dữ liệu transactional/operational sang Amazon Redshift gần thời gian thực, tự động hoá việc sao chép dữ liệu từ nguồn sang cluster hoặc sang Redshift Serverless namespace mà không phải nuôi pipeline ETL. Nghe rất "managed", nhưng nó giải quyết bài toán đưa dữ liệu vào, còn đề đang hỏi về năng lực compute để chạy phân tích. Dữ liệu trong đề đã nằm sẵn ở S3 rồi; chuyện replicate dữ liệu không phải vấn đề ở đây. Sai chủ đề, không phải sai kỹ thuật.

B — EventBridge Scheduler + Step Functions state machine. Đây là phương án gần đúng nhất, và cũng là cái bẫy chính. Nó có tự động hoá được: đúng lịch thì state machine chạy, dựng cluster, chạy phân tích, chép dữ liệu về S3, rồi decommission cluster. Nhưng nó chỉ tự động hoá đúng cái quy trình thủ công đang có thay vì loại bỏ nó. Hạ tầng vẫn còn nguyên đó để quản lý — vẫn là provisioned cluster, vẫn phải cấu hình node type, vẫn phải xử lý lỗi khi provision hỏng — và giờ có thêm hai dịch vụ nữa (EventBridge Scheduler, Step Functions) cùng một state machine phải viết và bảo trì. Giải pháp phức tạp không cần thiết, dính quá nhiều dịch vụ, nên operational overhead cao hơn chứ không thấp hơn.

C — Purchase Redshift reserved node offerings. Reserved node dành cho trường hợp bạn định để cluster chạy liên tục trong thời gian dài: nó tiết kiệm đáng kể so với giá on-demand, nhưng đổi lại phải đặt trước compute node và cam kết trả tiền cho các node đó trong một hoặc ba năm. Tình huống trong đề thì ngược hẳn — cluster bị decommission sau mỗi lần dùng hằng tháng, nên cam kết dài hạn là vô nghĩa. Quan trọng hơn: reserved node là một mô hình định giá, nó không hề làm giảm công sức provisioning hay bảo trì hạ tầng — chính là điều phương án này tự nhận là làm được.

📌 Điểm cần nhớ

• "Lowest operational overhead" + workload chạy từng đợt, không liên tục → hướng tới lựa chọn serverless. Amazon Redshift Serverless tự cấp phát và tự co giãn, chỉ tính tiền khi data warehouse được dùng.
• Tự động hoá một quy trình thủ công không đồng nghĩa với giảm operational overhead. Kịch bản EventBridge Scheduler + Step Functions dựng rồi xoá provisioned cluster vẫn để lại nguyên hạ tầng phải quản lý, cộng thêm state machine phải bảo trì.
• Phân biệt rõ mô hình định giá với mô hình vận hành: reserved node chỉ giảm chi phí cho cluster chạy dài hạn, không giảm việc quản lý; và nó xung đột với tình huống cluster bị xoá sau mỗi lần dùng.
• Đọc kỹ xem đề hỏi về compute chạy phân tích hay về đường đưa dữ liệu vào kho. Zero-ETL integration thuộc vế thứ hai — dữ liệu đã sẵn sàng thì nó không giải quyết được gì.

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

Đề mô tả một kiến trúc ba tầng rất quen thuộc: client → Application Load Balancer (ALB) → EC2 instances trong Auto Scaling Group → RDS PostgreSQL. Câu hỏi yêu cầu chọn ba security group rule để luồng đi được trọn vẹn.

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

• "provides HTTPS termination" — ALB là nơi kết thúc TLS. Nghĩa là phía trước ALB nhận HTTPS (port 443), còn phía sau ALB đi tới EC2 thì đã là HTTP thường (port 80). Cụm này loại được ngay các phương án đặt sai port cho ALB.
• "PostgreSQL database managed by Amazon RDS" — PostgreSQL nghe port 5432, không phải 80.
• "How should you configure the security groups" — hỏi về inbound rule ở từng tầng. Security group mặc định cho phép toàn bộ outbound và stateful, nên chỉ cần mở chiều đi vào ở phía nhận kết nối; không cần rule chiều ngược lại cho gói trả về.

Điểm phân biệt cốt lõi: mỗi rule phải nằm ở security group của bên nhận kết nối, với nguồn là security group của bên khởi tạo kết nối, trên đúng port của giao thức tầng đó.

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

Ba đáp án B, C, E dựng lại đúng ba chặng của luồng request:

• B — SG của ALB: inbound từ anywhere trên port 443. ALB là thành phần duy nhất hướng ra Internet, và client gọi vào bằng HTTPS. Vì người dùng đến từ mọi nơi nên nguồn phải là 0.0.0.0/0, còn port là 443 đúng như cụm "HTTPS termination" trong đề.
• C — SG của EC2: inbound từ SG của ALB trên port 80. Sau khi ALB đã giải mã TLS, nó chuyển tiếp request tới target group bằng HTTP thường trên port 80. Nguồn được khai bằng security group của ALB chứ không phải dải IP — vì trong Auto Scaling Group, IP của instance thay đổi liên tục và ALB cũng đổi node theo thời gian, tham chiếu SG là cách duy nhất không phải sửa rule mỗi lần scale.
• E — SG của RDS: inbound từ SG của EC2 trên port 5432. Chặng cuối là ứng dụng trên EC2 mở kết nối tới PostgreSQL. Bên nhận là RDS, bên khởi tạo là EC2, port là 5432. Rule này cũng khiến database chỉ chấp nhận kết nối từ đúng tầng ứng dụng, không mở ra ngoài.

Ghép lại: 443 vào ALB → 80 vào EC2 → 5432 vào RDS. Mỗi tầng chỉ mở đúng cho tầng đứng ngay trước nó.

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

• A — SG của EC2 inbound từ SG của RDS trên port 5432: ngược chiều. EC2 mới là bên khởi tạo kết nối tới database, RDS không bao giờ chủ động gọi vào EC2. Rule này còn sai cả port: 5432 là port EC2 đi ra, không phải port EC2 lắng nghe. Đây là phương án gài bẫy tinh vi nhất vì nó dùng đúng số port PostgreSQL, chỉ đặt nhầm chỗ. Nhớ rằng security group là stateful — gói trả lời từ RDS về EC2 đã tự động được cho qua, không cần khai thêm gì.
• D — SG của ALB inbound từ anywhere trên port 80: sai port ở đúng tầng có nói tới HTTPS. Đề ghi rõ ALB làm HTTPS termination, tức client gọi vào bằng 443. Phương án này rất gần đúng ở chỗ nó đặt đúng SG (ALB) và đúng nguồn (anywhere), nhưng chọn nhầm giao thức. Nếu bài toán có thêm yêu cầu redirect HTTP → HTTPS thì port 80 mới có lý do tồn tại, còn đề này không nhắc gì tới việc đó.
• F — SG của RDS inbound từ SG của EC2 trên port 80: đúng hướng, sai port. Chiều kết nối EC2 → RDS là chính xác, nhưng RDS PostgreSQL lắng nghe ở 5432 chứ không phải 80. Mở port 80 trên security group của RDS thì database vẫn không nhận được kết nối nào, ứng dụng sẽ timeout khi truy vấn. Đây là phiên bản hỏng của E.

📌 Điểm cần nhớ

• Rule luôn đặt ở security group của bên nhận kết nối, nguồn là security group của bên gọi tới. Đảo chiều là sai, dù port có đúng.
• Security group stateful: chỉ khai inbound cho chiều khởi tạo, gói trả về tự động được phép — đừng thêm rule cho chiều ngược lại.
• Tham chiếu security group làm nguồn thay vì dải IP là bắt buộc khi đứng sau Auto Scaling Group, vì IP instance thay đổi theo mỗi lần scale.
• Ba port cần thuộc lòng cho dạng bài này: HTTP 80, HTTPS 443, PostgreSQL 5432. Khi đề nói load balancer làm TLS/HTTPS termination, mặc định là 443 ở phía trước và 80 ở phía sau.

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

Tình huống: một AWS Glue job chạy mỗi Chủ Nhật, copy dữ liệu từ vài thư mục trong S3 bucket sang Redshift. Job bookmarks đã được bật, thế nhưng job vẫn xử lý lại đúng những dữ liệu đã xử lý ở lần chạy trước.

Cụm từ quyết định là "job bookmarks have been enabled ... However, the ETL job is reprocessing data". Nó khoá chặt phạm vi câu trả lời: bookmark đã bật rồi, nên nguyên nhân không thể là "bookmark không hỗ trợ nguồn này" hay "bạn quên bật". Câu hỏi đang hỏi: bookmark đã bật nhưng vì sao nó không có tác dụng? Đi kèm là "(Select two)" — phải chỉ ra hai điều kiện làm cơ chế bookmark mất hiệu lực.

Bookmark của AWS Glue hoạt động bằng cách ghi lại trạng thái (timestamp, đường dẫn/khoá đã đọc) sau mỗi lần chạy thành công, để lần sau chỉ đọc phần dữ liệu mới. Vậy nên phải soi vào hai chỗ: trạng thái có được ghi lại không, và có gì làm việc ghi trạng thái bị nhiễu không.

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

D — Có nhiều lần chạy đồng thời (concurrent runs) mà max concurrency không đặt về 1. Bookmark là một trạng thái dùng chung của job. Khi nhiều lần chạy của cùng một job diễn ra song song, chúng cùng đọc và cùng ghi lên trạng thái đó, nên bookmark không còn phản ánh chính xác "đã xử lý tới đâu". Kết quả là dữ liệu bị đọc lại. Cách xử lý theo tài liệu là đặt số lần chạy đồng thời tối đa của job về 1.

E — Thiếu job.commit(). Đây là câu lệnh chốt sổ của một lần chạy. Khi script kết thúc bằng job.commit(), Glue mới ghi lại timestamp và đường dẫn của lần chạy đó; lần sau chạy trên cùng path, Glue chỉ xử lý các file mới. Không có job.commit() mà vẫn bật bookmark thì không có gì được ghi lại — job xử lý lại toàn bộ file cũ cùng với file mới, tạo dữ liệu trùng lặp ở đích (ở đây là Redshift). Đúng khớp với triệu chứng trong đề.

Hai đáp án này bổ trợ nhau: E là "không ghi trạng thái", D là "ghi trạng thái nhưng bị tranh chấp".

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

A — "Glue lưu metadata bookmark trong một S3 bucket cấu hình lúc tạo job; xoá bucket gây reprocess". Sai ở tiền đề. Glue gắn bookmark vào chính job, chứ không lưu vào một S3 bucket do người dùng khai báo. Xoá job thì bookmark mất theo job; còn bucket S3 khai lúc tạo job là nơi chứa script và thư mục tạm, không phải kho bookmark. Phương án này nghe hợp lý vì mọi thứ trong bài đều xoay quanh S3, nhưng nó gán sai nơi lưu trạng thái.

B — "Bạn đã thêm transformation context vào DynamicFrame, khiến job crash". Đây là phương án gần đúng nhất và cũng lật ngược sự thật. transformation_ctx đúng là tham số tuỳ chọn của GlueContext, nhưng nó là thứ định danh để bookmark theo dõi từng DynamicFrame — không có nó thì bookmark mới không hoạt động. Thêm vào là việc nên làm, không phải nguyên nhân lỗi. Ngoài ra đề mô tả job chạy xong và ghi dữ liệu trùng, chứ không hề crash — triệu chứng cũng không khớp.

C — "Job bookmarks không hoạt động với nguồn Amazon S3". Sai thẳng về mặt sự thật: bookmark hỗ trợ nguồn S3. Phương án này còn tự mâu thuẫn với đề, vì đề nói bookmark đã được bật trên đúng job đọc từ S3 — nếu S3 không được hỗ trợ thì tình huống trong đề không tồn tại.

📌 Điểm cần nhớ

• Bookmark chỉ được ghi khi lần chạy kết thúc bằng job.commit(). Bật bookmark mà thiếu dòng này là bật cho có — triệu chứng kinh điển là dữ liệu trùng lặp ở đích.
• transformation_ctx là điều kiện cần để bookmark theo dõi được từng nguồn dữ liệu. Gặp phương án nào nói thêm nó gây lỗi thì đó là bẫy đảo chiều.
• Bookmark là trạng thái chung của job, không chịu được chạy song song. Khi bài nhắc tới concurrency và bookmark trong cùng một câu, hướng xử lý là giới hạn số lần chạy đồng thời về 1.
• Bookmark thuộc về job, không nằm trong bucket của người dùng. Xoá job là mất bookmark; xoá bucket dữ liệu là chuyện khác.
• Với câu "(Select two)" kiểu chẩn đoán, hãy tách nguyên nhân theo tầng: trạng thái có được ghi không và trạng thái có bị tranh chấp không — hai đáp án thường rơi vào hai tầng khác nhau chứ không trùng ý.

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

Một công ty dùng Redshift làm data warehouse để phân tích dữ liệu từ Amazon S3. Sau 30 ngày, dữ liệu gần như không còn được truy vấn nữa — nó đã nguội (cold data). Câu hỏi yêu cầu chọn hai phương án vừa cắt được chi phí tối đa cho Redshift, vừa giữ nguyên hai điều kiện.

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

• "preserve the SQL querying capability" — vẫn phải truy vấn bằng SQL được sau khi chuyển dữ liệu đi.
• "have the query execution start immediately" — truy vấn phải chạy được ngay, không có bước khôi phục dữ liệu (restore) trước.
• "save the maximum amount of cost on Redshift" — tiết kiệm phải rơi vào Redshift, tức phải đưa dữ liệu nguội ra khỏi Redshift chứ không phải sắp xếp lại bên trong nó.

Cụm "start immediately" chính là ràng buộc tách bạch hai storage class của S3 trong danh sách phương án, còn "save cost on Redshift" là cái loại các phương án vẫn giữ dữ liệu trong cluster.

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

B – Move the data to S3 Standard-IA after 30 days. S3 Standard-IA dành đúng cho dữ liệu ít được truy cập nhưng khi cần thì phải lấy được nhanh. Nó giữ độ bền, thông lượng và độ trễ thấp tương đương S3 Standard, đổi lại giá lưu trữ mỗi GB rẻ hơn và có thêm phí truy xuất mỗi GB. Vì độ trễ truy cập không đổi, dữ liệu nằm ở Standard-IA vẫn đọc được ngay lập tức — thoả điều kiện "start immediately". Lưu ý Standard-IA có thời hạn lưu tối thiểu tính phí là 30 ngày, khớp đúng với mốc 30 ngày trong đề. Dữ liệu ra khỏi Redshift nên chi phí Redshift giảm thật.

E – Analyze the cold data with Athena. Athena là dịch vụ truy vấn tương tác cho phép phân tích dữ liệu trực tiếp trong S3 bằng SQL chuẩn, nên khả năng truy vấn SQL được giữ nguyên sau khi chuyển dữ liệu. Athena serverless: không phải dựng hay quản lý hạ tầng, chỉ trả tiền theo truy vấn đã chạy. Với dữ liệu hiếm khi được hỏi tới, mô hình trả theo lượt dùng này rẻ hơn hẳn so với việc nuôi node Redshift chạy 24/7 chỉ để chứa dữ liệu nguội.

Hai phương án ghép lại thành một cặp trọn vẹn: B lo chỗ lưu rẻ mà vẫn nhanh, E lo cách truy vấn bằng SQL trên chỗ lưu đó.

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

A – Create a smaller Redshift Cluster with the cold data. Đây là phương án gần đúng nhất vì cluster nhỏ thì rẻ hơn cluster lớn, và SQL vẫn dùng được ngay. Nhưng nó hỏng ở chỗ dữ liệu vẫn nằm trong Redshift: chi phí lưu trữ Redshift không hề giảm đi, mà còn tăng dần theo thời gian khi dữ liệu nguội tiếp tục dồn vào cluster. Đề yêu cầu "maximum amount of cost" — chuyển hẳn sang S3 + Athena tiết kiệm hơn nhiều so với việc chỉ đổi sang một cluster nhỏ hơn nhưng vẫn phải chạy liên tục.

C – Move the data to S3 Glacier Deep Archive after 30 days. Đúng là rẻ nhất trong các storage class, và đây là bẫy dành cho ai chỉ đọc mỗi chữ "maximum cost saving". Nhưng Glacier Deep Archive là lớp lưu trữ để archive và backup dài hạn: muốn đọc dữ liệu phải qua bước khôi phục trước, không truy vấn được ngay. Điều đó phá thẳng ràng buộc "query execution start immediately" trong đề.

D – Migrate the Redshift cluster's underlying storage class to Standard-IA. Phương án này sai ngay ở tiền đề kỹ thuật. Một cluster Redshift gồm leader node và các compute node; leader node nhận truy vấn, phân tích, lập kế hoạch thực thi rồi điều phối các compute node chạy song song và gộp kết quả trả về. Storage bên trong Redshift không có các "tier" storage class kiểu S3 để mà chuyển sang Standard-IA. Không tồn tại thao tác này, nên phương án bị loại.

📌 Điểm cần nhớ

• Cụm "query immediately" hay "no retrieval delay" trong đề loại ngay mọi lớp archive (Glacier, Glacier Deep Archive); còn S3 Standard-IA đọc nhanh như Standard, chỉ khác ở giá lưu trữ thấp hơn kèm phí truy xuất.
• Muốn giữ SQL trên dữ liệu nằm trong S3 mà không nuôi hạ tầng, câu trả lời trong bối cảnh này là Athena — serverless, trả tiền theo truy vấn, hợp với dữ liệu nguội hiếm khi hỏi tới.
• Đề bảo tiết kiệm chi phí cho Redshift thì phải đưa dữ liệu ra khỏi Redshift; sắp xếp lại bên trong cluster (thu nhỏ cluster) không đụng tới gốc chi phí.
• Redshift không có khái niệm storage class phân tầng như S3 — phương án nào nói "đổi storage class của Redshift" là sai về mặt kỹ thuật, không cần cân nhắc chi phí.
• Câu "(Select two)" kiểu này thường ghép một quyết định về nơi lưu với một quyết định về công cụ truy vấn; chọn hai phương án cùng loại là dấu hiệu đọc thiếu vế của đề.