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

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

Một công ty dịch vụ tài chính chuyển hạ tầng lên AWS và cần áp dụng các cơ chế bảo vệ dữ liệu trên Amazon S3 để đáp ứng yêu cầu tuân thủ. Nhưng phần thân đề chỉ là bối cảnh — câu hỏi thật nằm ở dòng cuối.

Cụm từ quyết định là "identify the INCORRECT option". Đây là câu hỏi đảo chiều: bốn phương án đều mô tả một khả năng bảo vệ dữ liệu của S3, và ta phải tìm phương án mô tả sai, tức là điều S3 không làm được. Ba phương án còn lại đúng và vì thế bị loại.

Ràng buộc thứ hai nằm trong chính nội dung các phương án: chúng phân biệt nhau ở đối tượng được bảo vệ (dữ liệu ở trạng thái nghỉ, dữ liệu trên đường truyền, hay object metadata) và ở nơi thực hiện mã hoá (phía server hay phía client). Chỉ có một phương án nói về metadata — đó chính là chỗ khác biệt cần chú ý.

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

Đáp án đúng theo tệp là B — "Amazon S3 can encrypt object metadata by using Server-Side Encryption", và nó đúng theo nghĩa "đây là phát biểu SAI cần chỉ ra".

Một object trong S3 gồm nhiều thành phần: Key (tên object), Version ID, Value (nội dung thật sự của object), Metadata (tập các cặp name–value mô tả object), Subresources và Access Control Information.

Server-Side Encryption của S3 tác động lên phần Value — tức nội dung object khi được ghi xuống đĩa. Phần metadata đi kèm object không được mã hoá khi lưu trên S3. Chính vì vậy AWS khuyến nghị không đặt thông tin nhạy cảm vào metadata của object trên S3. Với một công ty dịch vụ tài chính có ràng buộc tuân thủ, đây là chi tiết rất đáng nhớ: gắn số tài khoản hay thông tin định danh vào metadata là để lộ dữ liệu, dù object đã bật SSE.

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

Ở đây "sai" nghĩa là phát biểu đúng về S3, nên không phải thứ đề bài đang tìm.

A — "Amazon S3 can protect data at rest using Server-Side Encryption": đây là phát biểu hoàn toàn đúng. S3 cung cấp Server-Side Encryption theo ba hướng quản lý khoá khác nhau: SSE-S3 (khoá do chính Amazon S3 quản lý), SSE-KMS (khoá quản lý trong AWS Key Management Service) và SSE-C (khoá do khách hàng cung cấp kèm request). Phương án này chỉ mô tả lại đúng năng lực có sẵn của dịch vụ.

C — "Amazon S3 can encrypt data in transit using HTTPS (TLS)": cũng đúng. Truy cập S3 qua HTTPS (TLS) bảo vệ dữ liệu trên đường truyền, giúp ngăn kẻ tấn công nghe lén hoặc can thiệp vào lưu lượng mạng theo kiểu person-in-the-middle. Đây là biện pháp bảo vệ data in transit, khác trục với hai phương án nói về data at rest — nhưng vẫn là một cơ chế S3 hỗ trợ thật, nên không phải đáp án.

D — "Amazon S3 can protect data at rest using Client-Side Encryption": phương án dễ nhầm nhất, vì nó rất gần A và nhiều người quen nghĩ "mã hoá là việc của S3". Thực tế nó vẫn đúng: bạn hoàn toàn có thể mã hoá dữ liệu ngay phía client rồi mới tải bản đã mã hoá lên S3. Điểm khác biệt là ai chịu trách nhiệm — với Client-Side Encryption, client tự lo quy trình mã hoá, tự quản lý khoá và các công cụ liên quan. Khác về mô hình trách nhiệm, nhưng vẫn là một cách bảo vệ data at rest hợp lệ, nên phương án này không sai.

📌 Điểm cần nhớ

• Đọc kỹ chữ INCORRECT / NOT / EXCEPT trong đề. Câu hỏi đảo chiều biến ba phát biểu đúng thành phương án phải loại, và đáp án là phát biểu sai duy nhất — bỏ qua chữ này là chọn ngược hoàn toàn.
• Server-Side Encryption của S3 bảo vệ nội dung object, không bảo vệ object metadata. Không đặt thông tin nhạy cảm vào metadata; muốn giấu thì đưa nó vào chính nội dung object.
• Nhớ đủ ba trục bảo vệ dữ liệu trên S3: at rest bằng Server-Side Encryption (SSE-S3, SSE-KMS, SSE-C), at rest bằng Client-Side Encryption, và in transit bằng HTTPS (TLS).
• Phân biệt Server-Side với Client-Side Encryption theo ranh giới trách nhiệm: SSE thì S3 lo việc mã hoá, còn CSE thì client tự mã hoá và tự giữ khoá trước khi upload.

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

Một công ty game mobile cần đường ống nhận điểm số từ ứng dụng, xử lý ở backend rồi hiển thị lên bảng xếp hạng. Đề đưa ra bốn ràng buộc, và phải thoả cả bốn thì phương án mới đúng:

1. "handle major traffic spikes" — chịu được cú tăng đột biến về lượng dữ liệu vào.
2. "process the mobile game updates in the order of receipt" — xử lý đúng thứ tự nhận được.
3. "store the processed updates in a highly available database" — lưu vào cơ sở dữ liệu có tính sẵn sàng cao.
4. "minimize the management overhead" — tối thiểu hoá công sức vận hành.

Hai cụm quyết định là "in the order of receipt" và "minimize the management overhead". Cụm thứ nhất loại bỏ dịch vụ không đảm bảo thứ tự; cụm thứ hai loại bỏ mọi kiến trúc còn dính EC2 — bởi vì đề đã nói thẳng là muốn ít việc quản trị nhất, mà EC2 thì bạn vẫn phải tự lo hệ điều hành khách, cài đặt phần mềm, bản vá bảo mật và cấu hình Auto Scaling.

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

Phương án D — Kinesis Data Streams → Lambda → DynamoDB.

• Kinesis Data Streams (KDS) sinh ra để nhận dữ liệu thời gian thực ở quy mô lớn: nó thu được lượng dữ liệu rất lớn mỗi giây từ hàng trăm nghìn nguồn, dữ liệu sẵn sàng để đọc chỉ sau vài mili-giây. Quan trọng hơn với câu này: KDS giữ thứ tự bản ghi và cho phép nhiều ứng dụng Kinesis đọc lại (replay) đúng theo thứ tự đó. Đây chính là thứ đáp ứng "in the order of receipt".
• Lambda tích hợp sẵn (native integration) với Kinesis Data Streams. Khi dùng tích hợp này, những phần phức tạp như polling, checkpointing và xử lý lỗi đều được trừu tượng hoá đi — bạn không phải tự viết consumer, không phải tự quản máy chủ chạy consumer.
• DynamoDB là cơ sở dữ liệu được quản lý hoàn toàn, đáp ứng yêu cầu "highly available database" mà không cần bạn vận hành máy chủ nào.

Cả ba mắt xích đều là dịch vụ được quản lý, nên phương án này là phương án duy nhất thoả đồng thời cả ràng buộc thứ tự lẫn ràng buộc "ít việc vận hành nhất".

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

A. SNS topic → Lambda → SQL database trên EC2. Hỏng ở hai chỗ. Thứ nhất, khâu lưu trữ chạy SQL database trên Amazon EC2: bạn phải tự quản hệ điều hành khách, tự cài phần mềm, tự vá bảo mật, tự lo tính sẵn sàng cao — trái hẳn với "minimize the management overhead". Thứ hai, mô hình publish/subscribe của SNS là fan-out thông báo, không phải hàng đợi giữ thứ tự bản ghi cho một luồng xử lý tuần tự như KDS.

B. SQS queue → fleet EC2 (Auto Scaling) → RDS MySQL. Đây là phương án trông "hợp lý" nhất trong ba phương án sai, vì SQS lẫn RDS đều là dịch vụ được quản lý. Nhưng khâu ở giữa là một fleet EC2 với Auto Scaling — bạn vẫn phải chăm hệ điều hành, ảnh máy, phiên bản phần mềm và bản vá cho từng instance. Việc gắn Auto Scaling vào chỉ giúp co giãn theo tải, không làm biến mất công việc vận hành máy chủ. Riêng khoản đó đã đủ để loại nó theo tiêu chí của đề.

C. Kinesis Data Streams → fleet EC2 (Auto Scaling) → DynamoDB. Phương án này chọn đúng dịch vụ ingest (KDS, có giữ thứ tự) và đúng cơ sở dữ liệu (DynamoDB). Nó chỉ sai đúng một mắt xích ở giữa: thay vì để Lambda tích hợp sẵn với KDS lo polling và checkpointing, nó bắt bạn dựng một fleet EC2 làm consumer. Kết quả là bạn gánh thêm toàn bộ chi phí vận hành EC2 mà chẳng đổi lại được gì so với D. Đây là kiểu "bẫy" điển hình: so sánh C với D thì thấy ngay cụm từ trong đề nào đang phân định — chính là "minimize the management overhead".

📌 Điểm cần nhớ

• "In the order of receipt" là tín hiệu chỉ thẳng tới Kinesis Data Streams — KDS đảm bảo thứ tự bản ghi và cho phép đọc lại đúng thứ tự đó bằng nhiều ứng dụng Kinesis.
• "Minimize management overhead" gần như luôn loại mọi phương án có EC2, kể cả khi đã kèm Auto Scaling. Auto Scaling giải bài toán co giãn, không giải bài toán vận hành hệ điều hành và bản vá.
• Lambda + Kinesis Data Streams là cặp tích hợp sẵn: polling, checkpointing, xử lý lỗi đều được lo hộ. Thấy phương án tự dựng consumer trên EC2 để đọc KDS thì nên nghi ngay là phương án "gần đúng" cố tình đặt ra.
• Khi hai phương án chỉ khác nhau một mắt xích, hãy đối chiếu đúng mắt xích đó với ràng buộc trong đề thay vì đọc lại cả kiến trúc — như cặp C và D ở đây, chênh nhau đúng ở khâu xử lý.

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

Đề mô tả một AWS Glue job đọc dữ liệu từ Amazon S3. Người kỹ sư đã cấu hình đủ hai thứ thường bị nghi ngờ trước tiên: AWS Glue connection và IAM role đi kèm. Job vẫn hỏng, và cụm từ quyết định nằm ở chỗ mô tả lỗi:

"it fails with an error pointing to the Amazon S3 VPC gateway endpoint that has been configured for accessing the data in Amazon S3"

Hai chi tiết trong cụm này thu hẹp toàn bộ không gian đáp án:

• Lỗi trỏ thẳng vào VPC gateway endpoint — nghĩa là vấn đề nằm ở đường mạng đi qua endpoint đó, không phải ở quyền hạn. Nếu là chuyện quyền, thông báo lỗi sẽ là Access Denied trên bucket/object chứ không nhắc tới endpoint.
• Đó là gateway endpoint, không phải interface endpoint. Hai loại endpoint này hoạt động khác hẳn nhau, và câu hỏi cố tình nêu rõ loại để loại một phương án gài bẫy.

Câu hỏi thuộc Domain 4 (Data Security and Governance) nhưng thực chất đang kiểm tra hiểu biết về cách gateway endpoint định tuyến lưu lượng.

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

C — Verify that the route table of the VPC has inbound and outbound routes for the Amazon S3 VPC gateway endpoint.

Gateway VPC endpoint hoạt động bằng cơ chế định tuyến. Khi tạo gateway endpoint, bạn chỉ định những route table nào của subnet trong VPC sẽ dùng endpoint đó. AWS tự thêm vào mỗi route table một route có đích là prefix list ID của dịch vụ (pl-xxxxxxxx) và target là endpoint ID (vpce-xxxxxxxxxxxxxxxxx). Bạn không xoá hay sửa trực tiếp được route này, nhưng bạn đổi được tập route table mà endpoint sử dụng.

Hệ quả: nếu subnet mà AWS Glue job chạy trong đó gắn với một route table không nằm trong danh sách route table của endpoint, thì lưu lượng đi S3 không có đường nào để đi qua endpoint — và lỗi sinh ra chính là lỗi trỏ vào S3 VPC gateway endpoint, đúng như đề mô tả. Vì vậy việc cần làm khi troubleshoot là kiểm tra lại route table của VPC xem đã có route cho gateway endpoint hay chưa.

Cũng cần nhớ nền tảng đằng sau: VPC endpoint cho S3 cho phép AWS Glue dùng private IP để truy cập S3, không lộ ra public internet. Glue không cần public IP, không cần internet gateway, NAT device hay virtual private gateway. Lưu lượng giữa VPC và dịch vụ AWS không rời khỏi mạng của Amazon, và việc kiểm soát truy cập được làm bằng endpoint policy.

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

A — Configure an Internet Gateway in the VPC ... via the public endpoint. Đây là đi ngược lại đúng kiến trúc mà đề đã dựng sẵn. Giải pháp đúng là dùng VPC endpoint cho S3 để Glue truy cập bằng private IP, không phơi ra internet. Thêm internet gateway để đi vòng qua public endpoint không phải là "troubleshoot" — nó là thay kiến trúc private bằng kiến trúc public, làm mất chính lợi ích bảo mật mà gateway endpoint mang lại. Ngoài ra nó không hề chạm tới nguyên nhân lỗi đang được báo.

B — Configure private DNS options for the VPC gateway endpoint. Đây là phương án gài bẫy sát nhất, vì "private DNS" nghe rất hợp với chuyện truy cập private. Chỗ nó hỏng: private DNS là tuỳ chọn của interface VPC endpoint, không áp dụng cho gateway endpoint. Với S3, bạn dùng private DNS khi triển khai interface endpoint để tên miền S3 chuẩn phân giải về IP riêng của endpoint. Gateway endpoint không làm việc theo cách đó — nó làm việc bằng route table và prefix list. Cấu hình này đơn giản là không tồn tại cho loại endpoint mà đề đang nói tới, nên không sửa được lỗi.

D — Attach a bucket policy ... explicitly grant access permissions to the IAM role. Bucket policy thiếu quyền cho IAM role của Glue job là một sự cố có thật, nhưng nó sinh ra loại lỗi khác: lỗi từ chối quyền truy cập vào bucket/object, không phải lỗi trỏ vào Amazon S3 VPC gateway endpoint. Đề đã nói rõ IAM role đã được cấu hình cùng connection, và triệu chứng được mô tả là triệu chứng mạng. Sửa policy trong trường hợp này là chữa nhầm bệnh — job vẫn hỏng vì gói tin còn chưa tới được S3 để mà bị từ chối quyền.

📌 Điểm cần nhớ

• Gateway endpoint = route table + prefix list; interface endpoint = ENI + private DNS + security group. Đề nêu loại endpoint nào thì chỉ những cách khắc phục thuộc loại đó mới hợp lệ — "private DNS" xuất hiện cùng chữ gateway gần như luôn là bẫy.
• Đọc kỹ thông báo lỗi trong đề để phân biệt lỗi mạng với lỗi quyền. Lỗi trỏ vào endpoint → soi định tuyến/endpoint policy. Lỗi Access Denied → soi IAM role và bucket policy. Đề thường cố tình nói sẵn "IAM role đã cấu hình" để bạn loại nhánh quyền.
• VPC endpoint cho S3 giúp AWS Glue truy cập S3 bằng private IP, không cần public IP, internet gateway, NAT device hay virtual private gateway; lưu lượng không rời mạng AWS.
• Route của gateway endpoint do AWS tự thêm và không sửa/xoá trực tiếp được, nhưng bạn đổi được danh sách route table mà endpoint áp dụng — nên "subnet của job dùng route table không có route đó" là nguyên nhân kinh điển.

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

Đề mô tả một đường ống dữ liệu hoàn chỉnh: transaction được ghi vào Amazon Kinesis Data Streams bằng Kinesis Producer Library (KPL), stream bật Auto Scaling, còn Kinesis Client Library (KCL) đọc ra để nạp vào kho dữ liệu. Vấn đề gặp phải là duplicate records, và câu hỏi yêu cầu chỉ ra nguyên nhân khả dĩ nhất.

Cụm từ quyết định nằm ở hai chỗ. Thứ nhất là "duplicate records" — bản ghi bị nhân đôi, tức là cùng một dữ liệu tồn tại hai lần trong stream, chứ không phải bản ghi bị mất, bị chậm hay bị gộp lại. Thứ hai là "most likely reason" — người ta hỏi cơ chế sinh ra bản sao, không hỏi triệu chứng đi kèm.

Trong Kinesis Data Streams, bản ghi trùng đến từ đúng hai nguồn: producer retries và consumer retries. Cả bốn phương án đều nhắc tới thành phần có thật của Kinesis, nên phải đối chiếu từng cái xem nó có thực sự tạo ra hai bản ghi giống nhau trong stream hay không.

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

Đáp án đúng theo tệp là D — producer gặp network-related timeout, buộc phải ghi trùng vào Kinesis Data Streams.

Kịch bản kinh điển: producer gọi PutRecord, request đã tới Kinesis và đã được ghi thành công, nhưng acknowledgment không quay về được vì timeout mạng. Từ phía producer, kết quả là không xác định — nó không có cách nào biết bản ghi đã vào stream hay chưa.

Với dữ liệu giao dịch mà mọi bản ghi đều quan trọng, producer được viết theo hướng an toàn là retry với đúng dữ liệu đó. Nếu cả hai lần PutRecord đều commit thành công, stream sẽ chứa hai record cho cùng một transaction. Đây chính là producer retry — một trong hai nguyên nhân chính thức gây trùng bản ghi trong Kinesis.

Cách xử lý cho ứng dụng cần đảm bảo chặt chẽ là nhúng một primary key vào trong record để khử trùng ở bước xử lý phía sau. Cũng cần lưu ý: số bản ghi trùng do producer retry thường ít hơn so với số bản ghi trùng do consumer retry.

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

A — KPL gộp các record nhỏ thành record lớn tới 1 MB, đôi khi sinh ra bản ghi trùng. Vế đầu đúng: KPL thật sự có tính năng aggregation, gom nhiều user record nhỏ vào một Kinesis record lớn để tận dụng throughput của stream tốt hơn. Nhưng vế sau bịa ra hệ quả. Aggregation chỉ là cách đóng gói — KCL sẽ tự tách (de-aggregate) ra đúng các record ban đầu. Nó không nhân bản dữ liệu, nên không liên quan gì tới vấn đề duplicate. Đây là phương án gài bẫy vì nó mô tả đúng một cơ chế có thật của KPL.

B — PutRecords.Bytes vượt write capacity gây throttling, record fail rồi KPL ghi lại. Phương án này gần đúng nhất và cần nói rõ nó hỏng ở đâu. PutRecords.Bytes là metric stream-level mà Kinesis Data Streams gửi sang CloudWatch mỗi phút, cho biết số byte đã đưa vào stream qua thao tác PutRecords trong khoảng thời gian đó. Nó là chỉ số quan sát, không phải cơ chế gây trùng — metric vượt ngưỡng không tự nó sinh ra bản sao. Điểm mấu chốt: khi record bị throttle, producer nhận về phản hồi lỗi rõ ràng, biết chắc bản ghi chưa vào stream, nên ghi lại là ghi bù chứ không phải ghi trùng. Trùng chỉ xảy ra khi kết quả không xác định — đúng tình huống timeout ở phương án D.

C — GetRecord fail không nhận được acknowledgment thì KPL ghi lại dữ liệu. Phương án này lẫn lộn hai phía của đường ống. GetRecord là lời gọi đọc, thuộc về phía consumer; còn KPL là thư viện ghi, thuộc phía producer. KPL không bao giờ gọi GetRecord, và một lời gọi đọc thất bại thì không thể khiến dữ liệu được ghi thêm lần nữa. Lời gọi thực sự gây trùng khi thiếu acknowledgment là PutRecord. Đổi đúng một tên method là biến câu đúng thành câu sai — đây là kiểu bẫy rất hay gặp.

📌 Điểm cần nhớ

• Trong Kinesis Data Streams, bản ghi trùng chỉ đến từ hai nguồn: producer retries và consumer retries. Gặp câu hỏi về duplicate, hãy quy về một trong hai nguồn này trước khi xét thứ khác.
• Trùng sinh ra từ sự không chắc chắn, không phải từ lỗi rõ ràng. Timeout mạng khiến producer không biết PutRecord đã thành công hay chưa → retry → hai bản ghi. Ngược lại, throttling trả về lỗi tường minh nên producer biết chắc phải ghi lại.
• Phân biệt PutRecord (ghi, phía producer/KPL) với GetRecord (đọc, phía consumer/KCL). Phương án gán nhầm method cho sai phía là sai bất kể phần còn lại nghe hợp lý thế nào.
• KPL aggregation gom record nhỏ thành record lớn tới 1 MB là để tối ưu throughput; KCL de-aggregate lại nguyên vẹn. Đây là chuyện đóng gói, không phải chuyện nhân bản.
• Muốn đảm bảo chặt chẽ, nhúng primary key vào record rồi khử trùng ở tầng xử lý phía sau — Kinesis Data Streams không tự khử trùng giúp bạn.

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

Đề mô tả một pipeline đã chạy sẵn: VPC flow logs → Kinesis Data Streams → Kinesis Data Firehose (delivery stream). Sau đó đội kỹ thuật cấu hình thêm Kinesis Agent trên một nhóm thiết bị mạng khác, đẩy dữ liệu thẳng vào cùng delivery stream đó, và dữ liệu không tới nơi.

Cụm từ quyết định đáp án nằm ở hai chỗ ghép lại:

• "Kinesis Data Streams which further acts as the source of a delivery stream for Kinesis Firehose" — delivery stream này đã có source là một Kinesis data stream.
• "to send the VPC flow logs data ... to the same Firehose delivery stream" — Agent ghi trực tiếp vào chính delivery stream đó, chứ không ghi vào data stream ở đầu nguồn.

Đề hỏi MOST plausible root cause — nguyên nhân gốc hợp lý nhất, tức là phải tìm ràng buộc kiến trúc, không phải đoán mò lỗi vận hành.

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

Đáp án B — Kinesis Agent không ghi được vào một Firehose delivery stream đã đặt source là Kinesis Data Streams.

Một Firehose delivery stream có đúng một kiểu nguồn dữ liệu. Khi bạn chọn kiểu nguồn là "Kinesis data stream", Firehose tự đọc bản ghi từ data stream đó, và các thao tác ghi trực tiếp PutRecord / PutRecordBatch lên delivery stream bị vô hiệu hoá. Kinesis Agent hoạt động bằng đúng hai API này, nên khi nó nhắm vào delivery stream đã bị khoá đường ghi trực tiếp, dữ liệu không vào được.

Cách làm đúng theo kiến trúc này: cho Agent ghi vào Kinesis data stream ở đầu nguồn bằng PutRecord/PutRecords, rồi để Firehose tiếp tục kéo từ đó như cũ. Đây là ràng buộc thiết kế của dịch vụ, không phải sự cố tạm thời — nên nó là "root cause" đúng nghĩa.

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

A — "Dữ liệu Agent gửi bị mất do lỗi cấu hình". Đây là phương án gây nhiễu kiểu chung chung: "lỗi cấu hình" không nêu được cấu hình nào sai, nên nó không phải là root cause mà chỉ là mô tả lại triệu chứng. Trong đề đã có đủ dữ kiện để chỉ đích danh nguyên nhân kiến trúc, vì vậy một câu trả lời mơ hồ luôn thua câu trả lời cụ thể. Đề nhấn mạnh MOST plausible root cause chính là để loại kiểu đáp án này.

C — "Kinesis Agent chỉ ghi được vào Kinesis Data Streams, không ghi được vào Kinesis Firehose". Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nó chạm đúng vào Agent. Nhưng nó phát biểu quá rộng: Kinesis Agent là ứng dụng Java chạy độc lập, hỗ trợ gửi dữ liệu tới cả Kinesis Data Streams lẫn Kinesis Data Firehose. Nếu delivery stream được tạo với kiểu nguồn "Direct PUT", Agent ghi vào bình thường. Chỗ hỏng của C là bỏ mất điều kiện then chốt: vấn đề không nằm ở "Agent không nói chuyện được với Firehose", mà ở "delivery stream này đã bị chiếm nguồn bởi một data stream". Nhận ra khác biệt giữa không bao giờ được và không được trong cấu hình cụ thể này là điểm phân định B và C.

D — "Delivery stream đã chạm giới hạn, cần scale thủ công". Sai ở hai lớp. Thứ nhất, Firehose là dịch vụ fully managed, tự co giãn theo throughput của dữ liệu, không có khái niệm scale tay như shard của Data Streams — nên vế "needs to be scaled manually" tự nó đã sai với bản chất dịch vụ. Thứ hai, nếu thật sự đụng trần throughput thì triệu chứng sẽ là bị throttle, dữ liệu chậm hoặc rớt một phần, chứ không phải toàn bộ dòng dữ liệu từ Agent không tới nơi trong khi luồng cũ vẫn chạy êm. Triệu chứng "tất cả hoặc không gì cả" chỉ về phía một ràng buộc cứng, không phải giới hạn dung lượng.

📌 Điểm cần nhớ

• Một Firehose delivery stream chỉ có một kiểu nguồn: hoặc Direct PUT (nhận PutRecord/PutRecordBatch từ Kinesis Agent, SDK, CloudWatch Logs...), hoặc Kinesis Data Streams. Chọn kiểu thứ hai là đường ghi trực tiếp bị đóng.
• Kinesis Agent ghi được vào cả Data Streams và Firehose — đừng nhớ nhầm thành "chỉ một trong hai". Nó hỏng ở đây là vì cấu hình nguồn của delivery stream, không phải vì bản thân Agent.
• Trong kiến trúc Data Streams → Firehose, muốn bơm thêm nguồn dữ liệu mới thì bơm vào đầu nguồn (data stream), đừng bơm vào giữa đường ống.
• Firehose tự co giãn, Data Streams mới là chỗ có khái niệm shard/capacity cần chú ý. Gặp phương án nói "scale Firehose thủ công" thì gần như chắc chắn là distractor.
• Với câu hỏi "MOST plausible root cause", hãy ưu tiên phương án nêu được cơ chế cụ thể khớp với dữ kiện trong đề, và loại các phương án chỉ nói chung chung như "lỗi cấu hình".

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

Một công ty y tế đang chạy Oracle và PostgreSQL trên Amazon RDS, mỗi dòng dữ liệu có 2.000 điểm dữ liệu, hàng triệu dòng. Vấn đề: đội data engineer chạy truy vấn ad-hoc để làm báo cáo, và mỗi lần chạy thì hiệu năng của chính CSDL nghiệp vụ bị ảnh hưởng. Họ muốn nhân bản dữ liệu đó sang Amazon Redshift để tách tải báo cáo ra khỏi CSDL gốc.

Cụm từ quyết định nằm ở câu hỏi cuối: "MOST resource-efficient solution that requires the LEAST amount of development time" — ít công sức phát triển nhất, ít tài nguyên phải tự quản nhất. Cụm thứ hai đáng chú ý là "replicate this data with high availability" và "streaming data to Amazon Redshift": đây là nhân bản liên tục từ CSDL quan hệ sang kho dữ liệu, không phải một job ETL chạy theo lô.

Cả bốn phương án về mặt kỹ thuật đều làm được việc đưa dữ liệu vào Redshift. Ràng buộc "ít code nhất" mới là thứ loại ba phương án còn lại.

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

C — AWS Database Migration Service (AWS DMS).

DMS sinh ra đúng cho bài toán này: chuyển và nhân bản liên tục (continuous data replication) dữ liệu từ CSDL nguồn sang đích, trong khi CSDL nguồn vẫn hoạt động bình thường, gần như không có downtime cho ứng dụng đang dùng nó. Oracle và PostgreSQL đều là nguồn được DMS hỗ trợ, còn Amazon Redshift là một target được hỗ trợ sẵn.

Điểm mấu chốt là không phải viết code: người vận hành khai nguồn, khai đích, tạo replication instance và task — phần đọc thay đổi từ CSDL rồi ghi vào Redshift do dịch vụ tự lo. Đúng nghĩa "least development time".

Cơ chế bên trong cũng đáng nhớ: khi target là Redshift, DMS đưa dữ liệu qua một bucket Amazon S3 trước, rồi từ S3 nạp vào đúng bảng trong Redshift. DMS tự tạo bucket đó, và nó đặt bucket cùng Region với Redshift. Kèm theo là ràng buộc triển khai: cluster Redshift, replication instance và bucket phải cùng một AWS account và cùng một Region.

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

A — Amazon EMR. EMR là nền tảng big data chạy Hadoop/Spark/Hive/Presto trên một cluster EC2 co giãn được. Nó xử lý được khối lượng rất lớn, nhưng ở đây hỏng ở hai chỗ cùng lúc: bạn phải dựng và duy trì cluster (quản trị hạ tầng — trái với "most resource-efficient"), và phải tự viết job nhân bản dữ liệu từ RDS vào Redshift (trái với "least development time"). Đây là phương án tốn công nhất trong bốn cái.

B — Amazon Kinesis Data Streams. KDS là dịch vụ streaming thời gian thực rất mạnh, hợp với clickstream, log, giao dịch tài chính, database event stream. Nghe có vẻ khớp vì đề có chữ "streaming". Nhưng KDS chỉ là đường ống — nó không tự biết cách đọc thay đổi từ Oracle/PostgreSQL, cũng không tự ghi vào Redshift. Bạn vẫn phải viết producer để bắt thay đổi ở nguồn và viết consumer để xử lý stream rồi ghi vào Redshift (qua S3). Đây là phương án gần đúng nhất về mặt mô hình dữ liệu, nhưng hỏng ở đúng tiêu chí mà đề nhấn: khối lượng code phải tự viết.

D — AWS Glue. Glue là dịch vụ ETL managed, không phải quản hạ tầng nên phần "resource-efficient" thì ổn. Chỗ hỏng là Glue job hướng tới xử lý ETL theo lô (batch), còn đề cần nhân bản liên tục có tính sẵn sàng cao. Và để chép dữ liệu CSDL vào Redshift bằng Glue thì vẫn phải viết script migration riêng — nhiều công phát triển hơn hẳn so với việc chỉ khai một task DMS.

📌 Điểm cần nhớ

• Thấy đề ghép "replicate / continuous replication" + CSDL quan hệ (Oracle, PostgreSQL, MySQL…) + "least development time" thì nghĩ ngay tới AWS DMS. Đó là dịch vụ duy nhất trong nhóm này làm việc đó mà không cần viết code.
• DMS giữ nguồn hoạt động trong suốt quá trình — đây là lý do nó hợp với hệ đang chạy production, khác hẳn cách dump-rồi-nạp.
• Với target là Redshift, DMS đi vòng qua S3 rồi mới nạp vào bảng; và Redshift, replication instance, bucket phải cùng account, cùng Region. Câu hỏi về kiến trúc hay xoáy vào ràng buộc Region này.
• Phân biệt vai trò để khỏi bị đánh lừa bởi từ khoá: Glue = ETL managed thiên về batch, vẫn phải viết script; EMR = cluster big data tự quản, tốn cả hạ tầng lẫn code; Kinesis Data Streams = đường ống streaming thô, phải tự viết cả hai đầu. Chữ "streaming" trong đề không tự động có nghĩa là Kinesis.

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

Đề mô tả một hệ thống serverless: Amazon API Gateway ở phía trước, AWS Lambda xử lý nghiệp vụ, và toàn bộ hợp đồng được lưu trong Amazon DynamoDB. Yêu cầu là tự động chúc mừng developer khi họ đạt cột mốc, ví dụ hợp đồng có trả tiền đầu tiên.

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

• "All the contracts are stored in Amazon DynamoDB" — sự kiện cần phản ứng chính là một thay đổi dữ liệu trong bảng DynamoDB. Nguồn phát sinh sự kiện đã được đề chỉ định sẵn, không phải thứ ta được tự chọn.
• "LEAST delay" — cần cơ chế đẩy sự kiện đi ngay khi ghi dữ liệu, không qua vòng hỏi–đáp trung gian và không thêm bước ứng dụng phải tự phát tin.

Ghép hai ràng buộc lại: cần một cơ chế gắn trực tiếp vào bảng DynamoDB, tự phát sinh sự kiện mỗi khi item thay đổi, và kích hoạt Lambda ngay lập tức.

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

B — Amazon DynamoDB Streams + AWS Lambda.

DynamoDB Streams là dòng thông tin có thứ tự về mọi thay đổi của item trong bảng. Khi bật stream trên bảng, mỗi lần ứng dụng tạo, cập nhật hoặc xoá item, DynamoDB tự ghi một stream record chứa khoá chính và nội dung thay đổi của item đó.

Điểm mấu chốt: stream do chính DynamoDB sinh ra, không phải do code ứng dụng phát tin. Lambda có thể đăng ký đọc stream này và được kích hoạt để phản ứng với thay đổi — trong đó có cột mốc hợp đồng đầu tiên của developer. Không có bước trung gian nào phải tự viết, và sự kiện đi thẳng từ nơi dữ liệu được ghi tới nơi xử lý, nên độ trễ là thấp nhất trong các phương án.

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

A — Amazon DynamoDB DAX + Amazon API Gateway. DAX là lớp cache in-memory được quản lý hoàn toàn cho DynamoDB, giúp tăng tốc thao tác đọc — từ mức mili giây xuống micro giây. API Gateway là dịch vụ triển khai và vận hành API ở quy mô lớn. Cả hai đều nằm trên đường đọc và phục vụ request, không có thành phần nào phát sinh sự kiện khi dữ liệu thay đổi. Ghép chúng lại vẫn không có gì kích hoạt thông báo — phương án này lạc hoàn toàn khỏi bài toán event-driven.

C — Amazon EventBridge events + AWS Lambda. Đây là phương án nghe hợp lý nhất, vì EventBridge đúng là bus sự kiện và Lambda đúng là target hợp lệ của nó. Chỗ hỏng nằm ở đầu vào: không dùng được DynamoDB làm target của một EventBridge event, tức là không có đường nối chuẩn để chính bảng DynamoDB đẩy thay đổi item vào EventBridge trong khuôn khổ câu hỏi này. Sự kiện phải xuất phát từ thay đổi dữ liệu, mà đó lại đúng là thứ EventBridge không nhận được ở đây.

D — Amazon SQS + AWS Lambda. Về mặt kiến trúc thì chạy được: SQS là hàng đợi tin nhắn được quản lý, dùng để tách rời và mở rộng các thành phần; Lambda tiêu thụ tin từ hàng đợi rất tự nhiên. Nhưng nó hỏng ở chỗ phải viết thêm logic để ứng dụng chủ động gửi message vào SQS mỗi khi ghi hợp đồng. Nghĩa là thêm một bước do code tự lo, thêm điểm có thể quên hoặc lỗi (ghi DynamoDB xong mà gửi SQS hỏng thì mất thông báo), và thêm một chặng trên đường đi của sự kiện. Dữ liệu vốn đã nằm sẵn trong DynamoDB, nên Streams là lựa chọn tốt hơn hẳn — đây là phương án gần đúng nhưng thua ở tiêu chí "LEAST delay" và ở việc phải tự dựng phần phát tin.

📌 Điểm cần nhớ

• Khi đề nói "phản ứng với thay đổi dữ liệu trong DynamoDB" với độ trễ thấp nhất, phản xạ đầu tiên là DynamoDB Streams + Lambda: stream do chính bảng sinh ra, không cần ứng dụng phát tin thủ công.
• Phân biệt rõ vai trò: DAX là cache cho đường đọc, không phải cơ chế sự kiện; API Gateway là cửa vào của API, không sinh sự kiện từ dữ liệu.
• SQS đòi producer chủ động gửi message. Nếu nguồn sự kiện đã là một dịch vụ có sẵn cơ chế đẩy thay đổi (như DynamoDB Streams), chọn SQS nghĩa là tự thêm một chặng và một điểm hỏng.
• Với EventBridge, luôn kiểm lại dịch vụ nào được làm nguồn và dịch vụ nào được làm target — nhiều phương án bẫy ghép EventBridge với một nguồn mà nó không nhận được sự kiện.

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

Đề mô tả một luồng dữ liệu rất cụ thể: một dịch vụ bên thứ ba export dữ liệu ra Amazon S3 bucket, và sau mỗi lần export thì phần dữ liệu tăng dần (incremental data) trong bucket đó cần được chuyển sang Amazon Redshift, để rồi lọc theo những key nhất định.

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

• "needs to be transferred to Amazon Redshift" — dữ liệu phải nằm trong Redshift, tức là được nạp vào bảng của Redshift, chứ không phải chỉ được truy vấn từ xa.
• "incremental data ... after each export" — đây là một pipeline ETL lặp lại, chạy theo từng mẻ dữ liệu mới, chứ không phải một lần copy duy nhất hay một thao tác đơn giản kiểu sao chép file.

Ghép hai ràng buộc đó lại, thứ cần tìm là một dịch vụ tích hợp/ETL có quản lý (managed), chạy được lặp đi lặp lại, ghi kết quả vào Redshift. Ba phương án còn lại đều trượt ở đúng một trong hai ràng buộc này.

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

Đáp án theo tệp là C — Load data from Amazon S3 to Amazon Redshift using AWS Glue.

AWS Glue là dịch vụ tích hợp dữ liệu serverless: nó kết nối tới rất nhiều nguồn dữ liệu khác nhau và quản lý metadata tập trung trong Data Catalog. Với Glue, bạn tạo, chạy và giám sát các pipeline extract – transform – load (ETL) để nạp dữ liệu vào nơi đích. Dữ liệu đã được catalog hoá thì tra cứu được ngay bằng Amazon Athena, Amazon EMR và Amazon Redshift Spectrum.

Áp vào đề bài: Glue job đọc phần dữ liệu mới trong S3 bucket sau mỗi lần export, xử lý rồi ghi vào bảng Redshift — đúng nghĩa "transferred to Amazon Redshift". Đây cũng chính là mẫu kiến trúc mà AWS mô tả trong tài liệu prescriptive guidance: build an ETL service pipeline to load data incrementally from Amazon S3 to Amazon Redshift using AWS Glue. Trong bốn phương án được cho, Glue là lựa chọn duy nhất vừa là dịch vụ tích hợp dữ liệu có quản lý, vừa thực sự nạp được dữ liệu vào Redshift.

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

A. S3 Event notifications kích hoạt AWS Lambda để copy dữ liệu sang Redshift — đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì cơ chế "có file mới → chạy ngay" nghe rất hợp với chữ "after each export". Chỗ nó hỏng là Lambda có giới hạn thời gian thực thi tối đa 15 phút. Một mẻ dữ liệu incremental có thể lớn và thời gian nạp không đoán trước được, nên dùng Lambda làm nơi chạy tác vụ load là chọn sai công cụ: job vượt giới hạn sẽ bị cắt ngang. Glue thì không bị ràng buộc kiểu này.

B. Dùng Amazon S3 Replication để copy dữ liệu từ bucket sang Redshift — sai ngay ở mức khái niệm. S3 Replication là tính năng sao chép object giữa các S3 bucket với nhau; nó không có khái niệm "đích là một data warehouse". Redshift không phải bucket, nên không có cách nào cấu hình replication trỏ tới đó.

D. Dùng Amazon Redshift Spectrum để copy dữ liệu từ S3 bucket sang Redshift — phương án này mô tả sai chính bản chất của Spectrum. Spectrum cho phép bạn truy vấn dữ liệu có cấu trúc và bán cấu trúc nằm trong file trên S3 mà KHÔNG cần nạp vào bảng Redshift. Nói cách khác, nó đọc tại chỗ chứ không di chuyển dữ liệu. Đề bài yêu cầu chuyển dữ liệu incremental vào Redshift, nên Spectrum không đáp ứng — nó giải quyết bài toán ngược lại: tránh phải load.

📌 Điểm cần nhớ

• Đọc kỹ động từ trong đề: "load/transfer into Redshift" khác hẳn "query data in S3". Vế đầu dẫn tới Glue (hoặc cơ chế nạp thật sự); vế sau dẫn tới Redshift Spectrum. Đây là cặp đánh lừa xuất hiện rất thường xuyên.
• Amazon S3 Replication chỉ đi từ bucket sang bucket. Bất kỳ phương án nào dùng Replication để đưa dữ liệu vào Redshift, RDS, DynamoDB… đều loại được ngay mà không cần cân nhắc thêm.
• AWS Lambda không hợp cho tác vụ load dữ liệu kéo dài vì trần thời gian thực thi 15 phút. Khi đề nói tới khối lượng dữ liệu không xác định hoặc tăng dần theo thời gian, hãy nghi ngờ mọi phương án đặt phần việc nặng vào Lambda.
• Với các câu hỏi "S3 → Redshift theo mẻ, lặp lại, có biến đổi dữ liệu", AWS Glue là lựa chọn mặc định trong đề thi Data Engineer: serverless, có Data Catalog, và tạo/chạy/giám sát ETL pipeline được ngay trong dịch vụ.

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

Đề mô tả một data engineer đang mô hình hoá dữ liệu cho một DynamoDB production database và đang tạo secondary indexes để phục vụ những access pattern của ứng dụng. Câu hỏi yêu cầu chọn ba phát biểu đúng cần cân nhắc.

Cụm từ quyết định là "creating secondary indexes" kết hợp với "(Select three)": đây không phải câu tình huống kiến trúc mà là câu kiểm tra kiến thức nền về Global Secondary Index (GSI) và Local Secondary Index (LSI). Mỗi phương án là một phát biểu độc lập, đúng hay sai được quyết định bởi định nghĩa của DynamoDB chứ không bởi ngữ cảnh trong đề. Vì vậy cách làm là soi từng câu vào ba trục phân biệt kinh điển: key schema (GSI có primary key khác hẳn bảng gốc, LSI dùng chung partition key nhưng đổi sort key), tính nhất quán khi đọc (GSI chỉ eventually consistent, LSI hỗ trợ cả strongly consistent), và throughput / quota.

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

Theo trường dapAnDung, ba phương án đúng là A, B, D.

• A — Ứng dụng cần truy vấn theo nhiều thuộc tính khác nhau thì dùng GSI. Đúng theo tài liệu AWS: khi ứng dụng phải chạy nhiều kiểu query với nhiều attribute làm điều kiện, bạn tạo một hoặc nhiều global secondary index rồi phát Query lên chính các index đó. Đây là lý do tồn tại của GSI — nó gỡ bỏ ràng buộc "chỉ query được theo primary key của bảng gốc".
• B — GSI chứa một tập thuộc tính chọn lọc từ base table, tổ chức theo một primary key khác với primary key của bảng. Đây đúng là định nghĩa của GSI. Index key không cần chứa bất kỳ key attribute nào của bảng gốc, và cũng không cần cùng key schema với bảng. Chính điều này khiến GSI tăng tốc được các query trên non-key attribute.
• D — Nếu writes bị throttle trên GSI thì bảng chính cũng bị throttle, dù Write Capacity Units của bảng chính vẫn ổn. Để một lệnh ghi vào bảng thành công, throughput được cấp cho bảng và tất cả GSI của nó đều phải đủ write capacity. Thiếu ở bất kỳ GSI nào thì chính lệnh ghi vào bảng chính bị throttle. Đây là bẫy vận hành hay gặp: nhìn metric của bảng thấy bình thường nhưng ứng dụng vẫn báo lỗi ghi, nguyên nhân nằm ở một GSI bị cấp phát thiếu.

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

• C — "Global secondary indexes support both data models - eventually consistent or strongly consistent reads". Sai. GSI chỉ hỗ trợ eventually consistent reads. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì phát biểu này đúng nếu đổi GSI thành LSI: LSI dùng chung partition key với bảng gốc nên đọc được strongly consistent, còn GSI được duy trì bất đồng bộ trên phân vùng khác nên không thể bảo đảm strong consistency. Nếu access pattern của bạn bắt buộc đọc nhất quán tuyệt đối, GSI không đáp ứng được.
• E — "you can create up to twenty Local Secondary Indexes per table". Sai vì gán nhầm con số cho loại index. Con số hai mươi là quota mặc định của global secondary index mỗi bảng; local secondary index có giới hạn thấp hơn nhiều (5). Phương án này lấy đúng một con số có thật nhưng gắn vào sai loại index — dạng bẫy rất phổ biến.
• F — "A Local Secondary Index maintains an alternate primary key for a given partition key value". Sai ở đúng một chữ. LSI duy trì một alternate sort key, không phải alternate primary key. Dữ liệu trong LSI được tổ chức theo cùng partition key với base table, chỉ khác sort key. Nếu LSI đổi được cả primary key thì nó đã thành GSI — và khi đó phương án B sẽ không còn là điểm phân biệt giữa hai loại index nữa.

📌 Điểm cần nhớ

• GSI = primary key hoàn toàn mới (partition key và sort key đều có thể khác bảng gốc); LSI = giữ nguyên partition key, chỉ đổi sort key. Đây là ranh giới phân biệt trung tâm, và hầu hết bẫy trong đề chỉ là đảo hai định nghĩa này cho nhau.
• Chỉ LSI mới đọc strongly consistent được; GSI luôn eventually consistent. Thấy cụm "strongly consistent" đứng cạnh "global secondary index" thì gần như chắc chắn là phương án sai.
• Write capacity của GSI ảnh hưởng ngược lên bảng chính. Ghi vào bảng chỉ thành công khi bảng và mọi GSI đều đủ capacity — nên khi gỡ lỗi throttling, phải xem cả các index chứ không chỉ metric của bảng.
• Với câu hỏi về quota, hãy nhớ rằng giới hạn số lượng GSI cao hơn giới hạn số lượng LSI trên cùng một bảng; đề thường tráo con số của loại này sang loại kia.

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

Đề mô tả một công ty bán lẻ đa quốc gia dùng nhiều AWS account tách biệt cho từng đơn vị kinh doanh. Team finance đang giữ một encrypted snapshot của Amazon RDS instance, và điểm mấu chốt nằm ở cụm từ: snapshot đó được mã hoá bằng "the default AWS KMS key". Yêu cầu là chia sẻ snapshot này sang account khác (team Audit).

Cụm từ quyết định đáp án chính là "default AWS KMS key" cộng với "another AWS account". Bốn phương án chỉ khác nhau ở đúng hai biến:

1. Thêm target account vào default KMS key hay vào customer-managed key?
2. Copy snapshot bằng default KMS key hay bằng customer-managed key?

Ai nắm được ràng buộc "snapshot mã hoá bằng default KMS key thì không share cross-account được" sẽ loại ngay ba phương án chỉ bằng một nhát.

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

Đáp án đúng theo tệp là D: Add the target account to a customer-managed key. Copy the snapshot using the customer-managed key, and then share the snapshot with the target account. Copy the shared DB snapshot from the target account.

Lý do: không thể share một snapshot được mã hoá bằng default AWS KMS key. Default (AWS-managed) key không cho phép sửa key policy, mà chia sẻ cross-account lại bắt buộc phải cấp quyền dùng key cho account đích ngay trong key policy. Không sửa được policy nghĩa là account Audit không bao giờ giải mã được snapshot — nên phải chuyển sang customer-managed key (CMK), loại key mà chủ sở hữu toàn quyền chỉnh key policy.

Quy trình đúng vì thế gồm ba bước, và cả ba bước đều phải nhất quán quanh cùng một customer-managed key:

1. Thêm target account vào customer-managed key — cấp quyền sử dụng key đó cho account Audit qua key policy.
2. Copy snapshot bằng chính customer-managed key đó — thao tác copy là cách "re-encrypt" snapshot từ default key sang CMK, tạo ra bản snapshot mới mà account đích có quyền giải mã. Sau đó share bản copy này với target account.
3. Từ account đích, copy tiếp shared snapshot về account mình — bước này để account Audit sở hữu một bản snapshot của riêng họ và từ đó restore ra DB instance.

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

A — Add target account vào default KMS key, copy bằng default KMS key: sai ở cả hai vế. Không thêm được account khác vào default AWS KMS key vì key policy của nó do AWS quản lý, không cho chỉnh sửa. Và vì snapshot vẫn nằm dưới default key nên nó vẫn thuộc loại không share cross-account được. Đây là phương án sai hoàn toàn, không có bước nào cứu được.

B — Add target account vào customer-managed key, nhưng copy bằng default KMS key: đây là phương án gần đúng và dễ mắc bẫy nhất. Bước đầu đúng: cấp quyền cho target account trên CMK là việc phải làm. Nhưng bước copy lại vẫn dùng default key, nên snapshot bản copy vẫn được mã hoá bằng default key — đúng cái loại không share được. Quyền đã cấp trên CMK trở nên vô nghĩa vì snapshot chẳng liên quan gì tới CMK đó. Hỏng ở chỗ hai bước không trỏ về cùng một key.

C — Add target account vào default KMS key, copy bằng customer-managed key: ngược lại với B, cũng gần đúng ở một nửa. Bước copy sang CMK là đúng hướng, nhưng bước cấp quyền lại nhắm vào default key — thao tác này không thực hiện được, và kể cả có thì cũng cấp nhầm chỗ. Kết quả: snapshot nằm dưới CMK nhưng account Audit không hề có quyền dùng CMK đó, nên khi copy shared snapshot về sẽ thất bại vì không giải mã được. Vẫn là lỗi lệch key giữa hai bước.

📌 Điểm cần nhớ

• Snapshot RDS mã hoá bằng default AWS KMS key không share cross-account được. Thấy đề có "default KMS key" + "another AWS account" là gần như chắc chắn đáp án phải có bước chuyển sang customer-managed key.
• Chỉ customer-managed key mới sửa được key policy. AWS-managed / default key do AWS kiểm soát policy, nên mọi kịch bản cần cấp quyền cho account khác đều buộc phải dùng CMK.
• Copy snapshot là cơ chế đổi key mã hoá. Muốn chuyển một snapshot từ default key sang CMK thì copy nó và chỉ định CMK làm key đích, chứ không có thao tác "đổi key tại chỗ".
• Cấp quyền và copy phải cùng trỏ về một key. Với dạng câu bốn phương án hoán vị hai biến như thế này, hãy kiểm tra tính nhất quán giữa các bước — phương án nào để hai bước dùng hai key khác nhau thì sai, dù từng bước nghe đều hợp lý.
• Bước cuối "copy shared snapshot từ account đích" không phải thừa: account nhận cần có bản snapshot của riêng mình mới restore ra DB instance được.