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

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

Đề mô tả một kiến trúc hai tầng quen thuộc: application server nằm ở public subnet, Amazon RDS MySQL nằm ở private subnet, và một bastion host cũng ở public subnet. Câu hỏi yêu cầu tìm root cause cho lỗi mà người dùng cuối gặp phải.

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

• "could not connect to server: connection timed out" — đây là lỗi ở tầng mạng, tức là gói tin gửi đi mà không có ai trả lời. Nó khác hoàn toàn với lỗi xác thực, vốn sẽ hiện ra dạng "access denied" hoặc "permission denied". Timeout nghĩa là kết nối TCP còn chưa dựng xong, chưa hề tới bước MySQL kiểm tra username/password.
• "the data engineering team can use a bastion host ... and run queries" — bastion host kết nối được vào RDS bình thường. Vậy database còn sống, port MySQL đang lắng nghe, routing giữa public subnet và private subnet trong VPC vẫn thông. Chi tiết này loại trừ hàng loạt nguyên nhân chung chung và ép ta phải tìm thứ chỉ chặn riêng đường từ application server, chứ không chặn đường từ bastion host.

Kết hợp hai điều: có một bộ lọc trên đường mạng cho phép bastion host đi qua nhưng không cho application server đi qua. Đó chính là security group của RDS.

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

D — Security group của database instance thiếu rule cho phép inbound từ application server.

Security group hoạt động theo mô hình stateful và chỉ dùng allow-list cho chiều inbound. Muốn application server nói chuyện được với RDS, security group gắn vào database instance phải có một inbound rule mở port MySQL với source là security group của application server (AWS khuyến nghị trỏ security group làm source thay vì gõ dải IP — instance thay đổi hay scale ra thêm thì rule vẫn đúng).

Nếu rule đó chỉ được tạo cho security group của bastion host mà quên application server, kết quả đúng như hiện tượng trong đề: bastion host query ngon lành, còn application server gửi gói tin đi rồi ngồi chờ tới lúc timeout. Security group âm thầm drop gói tin chứ không gửi lại phản hồi từ chối, nên biểu hiện luôn là timeout chứ không phải "connection refused".

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

A — Sai username/password. Sai thông tin đăng nhập vẫn dựng được kết nối TCP tới MySQL; server nhận, kiểm tra rồi trả về lỗi xác thực kiểu "Access denied for user". Lỗi đến nhanh và có nội dung rõ ràng, không bao giờ là timeout. Đây là distractor đánh vào người đọc lướt đề.

B — Security group của application server thiếu rule inbound từ database instance. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó đúng chữ "security group" nhưng đảo ngược chiều kết nối. Chiều khởi tạo là application server → database, nên bên cần rule inbound là database, không phải application server. Hơn nữa security group là stateful: khi application server chủ động mở kết nối ra ngoài, lưu lượng trả về được cho phép tự động, không cần rule inbound tương ứng. Rule inbound trên application server chỉ dùng cho lưu lượng do bên ngoài chủ động gọi vào (ví dụ từ client application hoặc load balancer).

C — Credential không đủ quyền trên database. Cũng như A, đây là lỗi ở tầng ứng dụng/quyền hạn, xảy ra sau khi đã kết nối và xác thực thành công. Biểu hiện sẽ là lỗi permission trên một câu lệnh cụ thể, không phải kết nối bị treo tới hết thời gian chờ.

📌 Điểm cần nhớ

• Đọc chính xác thông báo lỗi trước khi đoán nguyên nhân. "connection timed out" ⇒ tầng mạng (security group, NACL, route table, subnet). "access denied" / "permission denied" ⇒ tầng xác thực hoặc phân quyền. Đây là ranh giới phân loại nhanh nhất trong các câu troubleshooting.
• Rule inbound luôn đặt ở phía nhận kết nối. Bên nào bị gọi tới thì bên đó cần rule, không phải bên gọi đi. Với kiến trúc application server → RDS thì rule nằm trên security group của RDS.
• Security group là stateful, lưu lượng phản hồi được cho phép tự động; đừng tạo rule đối xứng hai chiều như khi làm việc với network ACL (vốn là stateless).
• Nên trỏ security group làm source thay vì dải IP. AWS khuyến nghị cách này cho mô hình nhiều tầng vì rule không cần sửa khi instance thay đổi hoặc scale.
• Một thành phần kết nối được còn thành phần khác thì không — như bastion host chạy được mà application server thì không — gần như luôn chỉ về sai khác trong cấu hình security group giữa hai nguồn đó, chứ không phải database bị hỏng.

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

Đề mô tả một tình huống rất cụ thể: công ty chạy Athena theo kiểu on-demand trên tập dữ liệu quy mô petabyte để phục vụ các dashboard tuỳ biến. Chi phí Athena tính theo lượng dữ liệu quét, nên khi lượng người mở dashboard tăng đột biến, cùng một truy vấn bị chạy đi chạy lại và tiền tăng theo.

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

• "The data is updated once every day during non-business hours" — dữ liệu chỉ đổi mỗi ngày một lần, ngoài giờ làm việc. Nghĩa là trong suốt cả ngày làm việc, kết quả của một truy vấn hôm nay là không đổi. Đây chính là điều kiện lý tưởng để tái sử dụng kết quả cũ thay vì quét lại dữ liệu.
• "with the LEAST operational overhead" — không chỉ hỏi cách rẻ nhất, mà là cách rẻ hơn và ít công vận hành nhất. Cụm này loại thẳng mọi phương án đòi viết lại dữ liệu hay dựng thêm quy trình theo dõi.

Ghép hai ràng buộc: cần một cơ chế bật lên là dùng được ngay, tận dụng việc dữ liệu tĩnh trong ngày, và cắt đúng nguồn chi phí là các lần quét trùng lặp.

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

B — Use the query result reuse feature of Athena to reduce the query costs.

Query Result Reuse của Athena cho phép khai báo tuổi tối đa của kết quả được phép dùng lại. Nếu cùng một truy vấn đã chạy trong khoảng thời gian đó, Athena trả về kết quả đã có thay vì chạy lại — không quét dữ liệu, nên không phát sinh chi phí quét cho lần chạy đó.

Điểm khớp hoàn hảo với đề:

• Kết quả được dùng chung trong phạm vi workgroup, miễn là người dùng có quyền trên bảng và dữ liệu. Nên lợi ích không dừng ở một người: dashboard mà nhiều người cùng mở sẽ chạy đúng những truy vấn giống nhau, và tất cả cùng ăn theo một lần chạy duy nhất. Đây chính là kịch bản "surge in access requests" mà đề nêu.
• Dữ liệu chỉ cập nhật mỗi ngày một lần, nên đặt tuổi kết quả trong phạm vi một ngày làm việc vẫn cho ra số liệu đúng — không đánh đổi tính chính xác.
• Về vận hành, đây là một tuỳ chọn bật lên cho truy vấn/workgroup, không phải viết lại dữ liệu, không dựng thêm hạ tầng, không thay đổi dashboard. AWS khuyến nghị dùng Query Result Reuse cho mọi truy vấn mà dữ liệu nguồn không đổi thường xuyên — đúng định nghĩa của tình huống này.

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

A — Materialize frequently used queries to improve performance. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì nó cũng mang tinh thần "tính trước rồi dùng lại". Nhưng materialize nhắm vào việc tăng tốc các truy vấn phức tạp — lưu sẵn kết quả của các phép aggregation, join nặng để truy vấn sau đỡ tính lại. Vấn đề trong đề không phải là truy vấn phức tạp chậm, mà là cùng một truy vấn bị chạy lặp lại quá nhiều lần. Ngoài ra, việc tự dựng và duy trì các bảng kết quả tính trước là công việc vận hành thật: phải xây, phải làm mới sau mỗi lần dữ liệu cập nhật, phải sửa dashboard trỏ sang chỗ mới. Nó không cắt được chi phí một cách đáng kể cho use case này, mà lại vi phạm tiêu chí "LEAST operational overhead".

C — Create Athena workgroup for each use case and attach appropriate tags. Monitor costs using CloudWatch alarms. Workgroup là công cụ để tách biệt người dùng, nhóm, ứng dụng hay khối lượng công việc; để đặt giới hạn lượng dữ liệu mỗi truy vấn hoặc cả workgroup được quét; và để theo dõi chi phí. Kết hợp với CloudWatch, bạn xem được metric của truy vấn, đặt ngưỡng và kích hoạt hành động khi vượt ngưỡng. Nhưng hãy đọc kỹ động từ: monitor — theo dõi. Bản thân việc tạo workgroup và gắn tag không làm giảm một đồng nào; nó chỉ cho bạn biết tiền đang chảy đi đâu. Đề yêu cầu optimizing this cost, tức là giảm thật, không phải nhìn thấy rõ hơn.

D — Migrate the data to columnar storage formats like Apache Parquet or ORC. Về nguyên lý thì Parquet và ORC đúng là định dạng cột, được tối ưu cho việc đọc nhanh trong các ứng dụng phân tích trên AWS, và chuyển sang chúng có thể giảm được phần nào chi phí do Athena quét ít byte hơn. Nghĩa là phương án này không sai về mặt kỹ thuật — nó hỏng ở tiêu chí thứ hai. Chuyển đổi định dạng nghĩa là ghi lại toàn bộ dữ liệu hiện có ở quy mô petabyte: dựng job chuyển đổi, chạy nó, kiểm chứng, rồi duy trì cho các lần nạp dữ liệu về sau. Đó là khối lượng vận hành lớn, hoàn toàn trái với "LEAST operational overhead". Thêm nữa, nó vẫn không xử lý gốc rễ vấn đề: cùng một truy vấn vẫn bị chạy lại cho từng lượt xem dashboard, chỉ là mỗi lần quét ít hơn.

📌 Điểm cần nhớ

• Athena tính tiền theo lượng dữ liệu quét. Vì vậy khi đề hỏi giảm chi phí Athena, hãy hỏi ngược lại: phương án này làm giảm số byte quét, hay chỉ làm giảm số lần quét? Query Result Reuse tấn công vào số lần; định dạng cột tấn công vào số byte.
• Tần suất cập nhật dữ liệu trong đề là gợi ý trực tiếp cho Query Result Reuse. Thấy "dữ liệu chỉ đổi mỗi ngày/mỗi giờ một lần" cộng với "nhiều người chạy cùng truy vấn" là gần như chắc chắn đang nói tới tái sử dụng kết quả. Lợi ích lan ra cả workgroup chứ không riêng người chạy đầu tiên.
• "LEAST operational overhead" là tiêu chí loại trừ mạnh nhất. Khi nhiều phương án cùng đúng về kỹ thuật, cái nào đòi viết lại dữ liệu, dựng thêm pipeline hay xây bảng phải tự làm mới sẽ bị loại trước — kể cả khi nó cũng tiết kiệm được tiền.
• Phân biệt "theo dõi chi phí" với "giảm chi phí". Workgroup, tag và CloudWatch alarm cho khả năng quan sát và đặt giới hạn quét, nhưng riêng việc gắn tag rồi đặt cảnh báo không tự nó làm hoá đơn nhỏ đi. Gặp phương án chỉ có động từ monitor, track, alert trong một câu hỏi yêu cầu reduce cost, hãy nghi ngờ ngay.

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

Đề mô tả một data lake trên Amazon S3 dùng cách đặt object key theo kiểu Hive-style partition: s3://bucket/prefix/year=2023/month=01/day=01. Yêu cầu là giữ cho AWS Glue Data Catalog luôn đồng bộ với các partition mới được ghi thêm vào bucket.

Cụm từ quyết định đáp án nằm ở câu hỏi cuối: "while minimizing latency" — giảm thiểu độ trễ. Cả bốn phương án đều có thể đăng ký partition mới vào Data Catalog; chúng chỉ khác nhau ở khoảng cách thời gian giữa lúc dữ liệu rơi xuống S3 và lúc partition xuất hiện trong catalog. Vì vậy câu này không hỏi "cách nào làm được", mà hỏi "cách nào biết về partition mới sớm nhất".

Nguyên tắc để so sánh: mọi cơ chế chạy theo lịch (daily, twice a day) hoặc chạy thủ công đều tạo ra một cửa sổ trễ bằng đúng khoảng cách giữa hai lần chạy. Chỉ cơ chế gắn liền với chính hành động ghi dữ liệu mới cho độ trễ gần như bằng không.

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

C — Update the existing code that writes data to Amazon S3, so that it also invokes the Boto3 AWS Glue create_partition API call.

Đây là cách duy nhất trong danh sách mà việc đăng ký partition xảy ra đồng thời với việc ghi dữ liệu, chứ không chờ tới một lượt quét kế tiếp. Ứng dụng ghi xong prefix year=2023/month=01/day=01 thì gọi luôn create_partition để khai partition đó vào bảng trong Glue Data Catalog. Không có lịch nào phải đợi, nên độ trễ đồng bộ gần như bằng thời gian của một lời gọi API.

Cách này còn hợp lý ở chỗ: chính đoạn code ghi dữ liệu là nơi biết chắc giá trị partition key (year/month/day) mà nó vừa tạo ra — không cần ai đi quét lại S3 để suy ra. Đây cũng là lý do đề nhấn mạnh layout partition rất tường minh ở đầu bài: cấu trúc đã biết trước, nên việc khai báo partition là thao tác xác định chứ không phải việc khám phá.

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

A — Configure an AWS Glue crawler to run on a daily schedule. Đây là phương án gần đúng nhất và là cách làm phổ biến trong thực tế: crawler quét S3, tự nhận ra partition mới rồi cập nhật Data Catalog. Chỗ hỏng nằm ở "on a daily schedule" — partition được ghi ngay sau lượt quét sẽ phải chờ tới lượt quét hôm sau mới xuất hiện trong catalog. Với tiêu chí "minimizing latency", một cửa sổ trễ cỡ một ngày là quá lớn. Bản thân crawler không sai, cái sai là chu kỳ theo lịch.

B — Schedule an AWS Lambda function to run the AWS Glue CreatePartition API twice each day. Phương án này dùng đúng API mà đáp án đúng dùng (CreatePartition), nên nhìn qua rất giống C. Khác biệt duy nhất — và cũng là chỗ hỏng — là "twice each day": nó vẫn là cơ chế theo lịch. Chuyển từ mỗi ngày một lần sang mỗi ngày hai lần chỉ rút ngắn độ trễ chứ không loại bỏ nó. Khi đề đã có sẵn một phương án đồng bộ ngay tại thời điểm ghi, mọi phương án theo lịch đều thua.

D — Manually execute the MSCK REPAIR TABLE command from the AWS Glue console on demand. Lệnh này quét lại toàn bộ layout partition của bảng và thêm những partition còn thiếu vào metastore, nên về mặt chức năng thì làm được việc. Nhưng nó do người chạy tay, tức là độ trễ phụ thuộc vào việc có ai nhớ chạy hay không — đây là lựa chọn tệ nhất về latency trong bốn phương án, và cũng không thể tự động hoá theo yêu cầu "remains updated in sync". Thêm nữa, cách quét lại toàn bộ này càng nặng dần khi số partition tăng lên theo thời gian.

📌 Điểm cần nhớ

• Khi đề hỏi "minimize latency" trong bài toán đồng bộ metadata, hãy loại ngay mọi phương án có từ schedule / daily / twice a day / manually / on demand. Cơ chế theo lịch luôn mang theo một cửa sổ trễ bằng đúng chu kỳ của nó.
• Hai kỹ thuật cập nhật partition vào Glue Data Catalog cần phân biệt: discovery (Glue crawler, MSCK REPAIR TABLE) — đi quét S3 để tìm ra partition; và direct registration (CreatePartition / Boto3 create_partition) — khai báo thẳng partition đã biết. Discovery hợp khi không kiểm soát được quá trình ghi; direct registration nhanh hơn hẳn khi mình sở hữu code ghi dữ liệu.
• Hai phương án dùng cùng một API vẫn có thể một đúng một sai — điều phân biệt là thời điểm gọi: gọi ngay trong luồng ghi (B... không, C) khác hẳn gọi từ một job chạy theo giờ (B).
• Layout key=value trong object key (Hive-style partitioning) là tín hiệu cho biết bảng được phân vùng theo year/month/day; chính đoạn code ghi dữ liệu là nơi biết rõ nhất các giá trị partition key đó, nên nó cũng là nơi đăng ký partition rẻ và nhanh nhất.

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

Đề mô tả một công ty lưu hàng petabyte dữ liệu trong hàng trăm S3 bucket ở lớp S3 Standard, phục vụ nhiều luồng analytics, visualization và reporting. Yêu cầu là tối ưu chi phí lưu trữ.

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

• "data access patterns are unpredictable and variable" — không đoán trước được lúc nào dữ liệu được đọc. Cụm này loại thẳng mọi cách tiếp cận đòi con người (hoặc một quy tắc tĩnh) phải quyết định khi nào chuyển lớp lưu trữ.
• "available in milliseconds when accessed" — dù có object nằm im nhiều tháng, khi cần đọc phải trả về ngay, không có bước khôi phục. Điều này giới hạn phạm vi ở các lớp truy cập tức thì.
• "LEAST operational overhead" — tiêu chí chọn giữa các phương án cùng đạt được mục tiêu: cái nào tự động hoàn toàn thì thắng.

Gộp lại: cần một cơ chế tự động theo dõi truy cập và tự chuyển lớp lưu trữ, mà vẫn giữ độ trễ mili giây.

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

A — Use Amazon S3 Intelligent-Tiering with the default access tier.

S3 Intelligent-Tiering tự lưu object qua nhiều access tier: một tier tối ưu cho truy cập thường xuyên, một tier rẻ hơn cho truy cập thưa, và một tier rất rẻ cho dữ liệu hiếm khi đụng tới. Đổi lấy một khoản phí giám sát và tự động hoá nhỏ tính theo object mỗi tháng, nó theo dõi access pattern và tự di chuyển object: không truy cập trong 30 ngày liên tiếp thì chuyển sang Infrequent Access tier, sau 90 ngày không truy cập thì chuyển tiếp sang Archive Instant Access tier — mà không ảnh hưởng hiệu năng và không cần thao tác vận hành nào.

Đúng cả ba ràng buộc: tự động nên khớp "unpredictable and variable"; Archive Instant Access vẫn cho độ trễ thấp nên khớp "milliseconds"; không ai phải viết hay chỉnh lifecycle rule nên khớp "least operational overhead". Đây chính là lớp lưu trữ AWS khuyến nghị cho dữ liệu có access pattern không biết trước hoặc thay đổi — không phụ thuộc kích thước object hay thời gian lưu — điển hình là data lake và data analytics, đúng bối cảnh trong đề.

Chữ "default access tier" trong phương án chỉ có nghĩa là bật Intelligent-Tiering theo cấu hình mặc định rồi để nó tự chạy — chính là cách dùng đúng.

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

B — S3 Storage Lens advanced metrics để quyết định khi nào chuyển object sang lớp rẻ hơn. Đây là phương án gần đúng nhất vì Storage Lens thật sự phục vụ mục tiêu tối ưu chi phí: nó cho tầm nhìn toàn tổ chức về mức dùng và xu hướng hoạt động của object storage, kèm khuyến nghị hành động, với dashboard tổng hợp qua nhiều tài khoản. Bộ metric chia thành free metrics (phân tích usage theo ảnh chụp hằng ngày, nhóm theo cost optimization, data protection, access management, performance, events) và advanced metrics tính phí thêm (activity như request count, cost optimization sâu hơn như số lifecycle rule, status code chi tiết…). Chỗ hỏng: Storage Lens chỉ quan sát và khuyến nghị, việc chuyển lớp vẫn do người vận hành phân tích rồi ra tay. Đó đúng là thứ mà "LEAST operational overhead" loại bỏ, và với access pattern biến động thì phân tích hôm nay có thể sai vào tháng sau.

C — S3 Transfer Acceleration để có độ trễ mili giây. Đây là distractor bám vào chữ "milliseconds" trong đề. Transfer Acceleration tăng tốc truyền nội dung lên/xuống S3 cho các đường truyền đường dài với object lớn, hữu ích khi người dùng hoặc ứng dụng ở xa bucket. Nó không liên quan gì tới chi phí lưu trữ — mà chi phí lưu trữ mới là yêu cầu chính. Ngoài ra nó còn phát sinh thêm phí, tức là đi ngược mục tiêu.

D — S3 Intelligent-Tiering với Archive Instant Access tier. Sai ở chỗ tinh vi: đúng lớp lưu trữ nhưng sai cách dùng. Archive Instant Access là tier tự động — object tự chuyển vào đó sau 90 ngày liên tiếp không được truy cập, và tier này cho độ trễ thấp, throughput cao. Không có cách nào chọn thẳng tier này bằng tay. Chưa kể nếu ép mọi object vào một tier cố định thì đã vứt bỏ đúng thứ giá trị nhất của Intelligent-Tiering: khả năng tự thích nghi với pattern biến động mà đề đang mô tả.

📌 Điểm cần nhớ

• Thấy "unknown / unpredictable / changing access patterns" đi cùng yêu cầu giảm chi phí lưu trữ S3 → nghĩ ngay tới S3 Intelligent-Tiering; đó là lớp AWS khuyến nghị cho đúng tình huống này.
• "LEAST operational overhead" là tiêu chí loại phương án, không phải chi tiết trang trí: công cụ chỉ đưa ra khuyến nghị (như Storage Lens) luôn thua cơ chế tự thực thi.
• Trong Intelligent-Tiering, các access tier là tự động theo thời gian không truy cập, không phải thứ chọn tay khi ghi object — phương án bảo "dùng tier X" thay vì "bật Intelligent-Tiering" thường là bẫy.
• Transfer Acceleration nói về tốc độ truyền, không nói về chi phí lưu trữ. Đề nhắc "milliseconds" là để loại các lớp archive cần khôi phục, không phải gợi ý tăng tốc mạng.

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

Đề mô tả kiến trúc hai tầng: application server nằm ở public subnet, database RDS (MySQL) nằm ở private subnet. Người dùng cuối báo lỗi ứng dụng, và log ứng dụng ghi rõ thông điệp could not connect to server: connection timed out. Câu hỏi yêu cầu tìm root cause.

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

• "connection timed out" — đây là lỗi ở tầng mạng, tức gói tin gửi đi mà không có gì trả lời. Nếu username/password sai hoặc thiếu quyền, MySQL vẫn bắt tay được rồi mới trả về lỗi kiểu Access denied for user .... Lỗi xác thực đến rất nhanh và có nội dung rõ ràng, không bao giờ biểu hiện thành timeout.
• "bastion host ... run queries from the bastion host" — đội data engineering vẫn truy vấn MySQL bình thường qua bastion host. Điều này chứng minh RDS instance đang sống, listener MySQL đang lắng nghe, route giữa public subnet và private subnet ổn, và tài khoản database dùng được. Cái duy nhất khác nhau giữa bastion host và application server là nguồn gọi tới — tức là rule cho phép trong security group của DB.

Ghép hai manh mối lại: đường mạng tới RDS chỉ mở cho bastion host, chưa mở cho application server.

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

B — Security group của DB instance không có rule cho phép inbound từ application server.

Security group là stateful firewall ở cấp instance, kiểm soát traffic vào/ra của DB instance. Traffic đi từ application server tới RDS là inbound đối với DB instance, nên rule phải nằm ở security group gắn cho DB.

Cách làm chuẩn mà tài liệu RDS mô tả: tạo một security group cho application server (inbound từ phía client của ứng dụng), rồi tạo security group thứ hai cho DB instance với rule chỉ định chính security group của application server làm source, trên cổng MySQL. Nếu bước sau bị thiếu — hoặc chỉ mới thêm bastion host làm source — thì gói tin của application server tới DB bị chặn im lặng: security group drop gói chứ không gửi lại thông báo từ chối, nên phía client ngồi chờ đến hết thời gian và ghi log đúng dòng "connection timed out". Đây khớp chính xác triệu chứng trong đề, đồng thời giải thích được vì sao bastion host (đã nằm trong danh sách source được phép) vẫn kết nối bình thường.

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

A — Credential của ứng dụng không đủ privilege trên database đó. Sai vì loại lỗi không khớp. Thiếu privilege nghĩa là kết nối TCP đã thành công, MySQL đã xác thực xong, và lỗi chỉ xuất hiện khi chạy câu lệnh — dạng thông báo là bị từ chối truy cập đối tượng, không phải hết thời gian chờ. Ngoài ra lỗi này sẽ đến gần như tức thì.

C — Security group của application server không cho phép inbound từ DB instance. Đây là phương án gần đúng nhất, và cũng là bẫy chính: nó nhắc đúng cơ chế (security group) nhưng đặt sai chiều. Security group là stateful — khi application server chủ động mở kết nối tới DB, traffic trả lời từ DB được tự động cho phép quay về, không cần bất kỳ inbound rule nào trên security group của application server. Application server không cần nhận kết nối do DB khởi tạo. Chỗ cần sửa là inbound của DB instance, với source là security group của application server, đúng như phương án B.

D — Credential (username/password) cấu hình cho ứng dụng bị sai. Cùng lý do với A: sai mật khẩu tạo ra lỗi xác thực chứ không phải timeout. Hơn nữa đề đã cho biết database đăng nhập được từ bastion host, nên tài khoản MySQL bản thân nó vẫn hợp lệ. Cả A và D được đặt vào danh sách như distractor để xem thí sinh có đọc kỹ chữ "timed out" hay không.

📌 Điểm cần nhớ

• Đọc đúng loại thông điệp lỗi trước khi chọn: "connection timed out" ⇒ vấn đề đường mạng (security group, network ACL, route, subnet). "Access denied" / lỗi quyền ⇒ vấn đề xác thực hoặc phân quyền trong database. Hai nhóm nguyên nhân này không lẫn sang nhau.
• Security group là stateful: chỉ cần mở inbound ở phía nhận kết nối; traffic trả lời tự động được phép quay ngược. Vì vậy inbound rule luôn thuộc về DB instance, không thuộc về application server.
• Mô hình chuẩn cho RDS là tham chiếu security group làm source, thay vì liệt kê địa chỉ IP: application server có thể thay đổi hoặc co giãn số lượng, nhưng nhóm thì không đổi.
• Chi tiết "cái gì vẫn chạy được" là manh mối mạnh: bastion host kết nối được chứng minh RDS instance và tài khoản đều ổn, thu hẹp nguyên nhân về đúng chỗ khác biệt giữa hai đường truy cập.

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

Một công ty logistics đẩy dữ liệu cảm biến IoT vào các bảng DynamoDB. Yêu cầu: mọi thay đổi trên item của bảng phải được ghi nhận gần thời gian thực để phát hiện hành vi bất thường và phản ứng nhanh.

Có hai cụm từ quyết định trong đề:

• "all changes to the items stored in the DynamoDB tables must be logged in near real-time" — thứ cần bắt là thay đổi ở mức item (dữ liệu), chứ không phải lời gọi API quản trị. Cụm này loại ngay hướng đi bằng CloudTrail/CloudWatch Events.
• "minimal custom development and infrastructure maintenance" — ưu tiên dịch vụ managed ghép sẵn với nhau, không tự viết ứng dụng polling.

Với hai phương án A và B gần như giống hệt nhau, điểm phân biệt nằm ở chỗ Lambda ghi vào KDA trực tiếp hay đi qua KDS rồi mới tới KDA — đó là ràng buộc về nguồn dữ liệu đầu vào hợp lệ của Kinesis Data Analytics.

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

Đáp án đúng là A: DynamoDB Streams → Lambda → Kinesis Data Streams (KDS) → Kinesis Data Analytics (KDA) → SNS.

• DynamoDB Streams là dòng thông tin có thứ tự về các thay đổi của item trong bảng. Bật stream trên bảng thì mỗi lần ứng dụng tạo/sửa/xoá item, DynamoDB ghi một stream record chứa khoá chính của item bị thay đổi. Stream hỗ trợ các kiểu view: KEYS_ONLY, NEW_IMAGE, OLD_IMAGE, NEW_AND_OLD_IMAGES — nên lấy được cả ảnh trước và sau khi sửa, đúng thứ cần cho việc dò bất thường.
• Lambda gắn với stream ARN được AWS gọi ngay khi có record mới: Lambda poll stream giúp bạn, bạn chỉ viết phần xử lý. Đây là cách tiêu chuẩn, ít phải tự vận hành nhất (so với tự chạy ứng dụng dùng KCL + DynamoDB Streams Kinesis Adapter).
• KDA chỉ nhận streaming source là KDS hoặc Kinesis Data Firehose (KDF). Vì vậy Lambda phải ghi record vào một KDS, rồi KDA đọc từ KDS đó để phân tích và phát hiện bất thường, cuối cùng đẩy thông báo qua SNS.

Toàn bộ chuỗi này ghép các dịch vụ managed có sẵn, không phải tự dựng hạ tầng — khớp với yêu cầu "minimal custom development and infrastructure maintenance".

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

B — DynamoDB Streams → Lambda → ghi thẳng vào KDA. Đây là phương án gần đúng nhất, và mọi mắt xích khác đều hợp lý: nguồn dữ liệu đúng (Streams), cách tiêu thụ đúng (Lambda), nơi phân tích đúng (KDA), cách báo động đúng (SNS). Nó hỏng ở đúng một mắt xích: KDA không nhận dữ liệu ghi trực tiếp từ Lambda. Streaming source của một ứng dụng KDA chỉ có thể là KDS hoặc KDF. Lambda vẫn có vai trò tiền xử lý dòng dữ liệu đến từ KDS/KDF, nhưng không thể đóng vai trò nguồn đẩy vào KDA. Thiếu KDS ở giữa là kiến trúc không dựng được.

C — CloudTrail bắt mọi API call cập nhật bảng, rồi dùng CloudTrail event filtering để phân tích. Sai ở hai chỗ. Thứ nhất, CloudTrail ghi lại lời gọi API tới DynamoDB (từ console và từ code), chứ không phải nội dung thay đổi của item; CloudTrail không hỗ trợ API GetRecords của DynamoDB Streams nên không lấy được bản ghi thay đổi thật sự. Thứ hai, "event filtering" của CloudTrail chỉ là cơ chế lọc đơn giản theo vài thuộc tính sự kiện (Read Only, Event Source, Event Time…) — nó không phải công cụ phân tích dòng dữ liệu để phát hiện bất thường.

D — CloudWatch Events bắt sự kiện API call của DynamoDB, Lambda làm target. Sai vì CloudWatch Events không cung cấp loại sự kiện riêng cho DynamoDB — nó phụ thuộc vào CloudTrail để có thông tin về lời gọi API. Mà như đã nói ở phương án C, bản thân CloudTrail không lấy được record thay đổi của DynamoDB Streams. Nên chuỗi này không bao giờ nhìn thấy được "all changes to the items" mà đề yêu cầu, dù phần Lambda + SNS phía sau nghe rất hợp lý.

📌 Điểm cần nhớ

• Phân biệt hai lớp dữ liệu: thay đổi ở mức item thì dùng DynamoDB Streams; lời gọi API mang tính kiểm toán thì mới là CloudTrail. Đề hỏi "changes to items" là gần như chắc chắn hướng về Streams.
• KDA chỉ nhận KDS hoặc KDF làm streaming source. Bất kỳ phương án nào vẽ mũi tên đi thẳng từ Lambda (hay nguồn khác) vào KDA đều sai về mặt kiến trúc — Lambda chỉ đứng ở vai trò tiền xử lý dòng đã vào Kinesis.
• CloudWatch Events với DynamoDB kế thừa giới hạn của CloudTrail: CloudTrail không thấy record của Streams thì CloudWatch Events cũng không thấy.
• Khi đề nhấn "minimal custom development / infrastructure maintenance", ưu tiên chuỗi dịch vụ managed ghép sẵn (Streams → Lambda → Kinesis → SNS) thay vì tự chạy ứng dụng polling bằng KCL.
• Mẹo làm bài: khi hai phương án chỉ khác nhau một mắt xích trung gian, đừng đọc lướt — chính mắt xích đó là điều đề đang kiểm tra.

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

Đề mô tả một ứng dụng y tế xử lý real-time health data của bệnh nhân, đẩy vào một analytics workflow. Khi số người dùng tăng vọt, hệ thống chậm và có lúc không phản hồi vì "it does not have a retry mechanism". Yêu cầu: tìm giải pháp thay thế có khả năng mở rộng và ít công sức triển khai (minimal implementation overhead).

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

1. "real-time" — dữ liệu là luồng liên tục, cần xử lý theo dòng chảy chứ không phải từng thông điệp rời rạc.
2. "retry mechanism" — đây là thứ hệ thống hiện tại thiếu, nên phương án mới bắt buộc phải có sẵn cơ chế đọc lại dữ liệu khi xử lý hỏng.
3. "analytics workflow" + "minimal implementation overhead" — đích đến là phân tích dữ liệu, và phải dùng dịch vụ quản lý sẵn thay vì tự dựng.

Nhiều phương án đều "nhận được dữ liệu vào", nên điểm phân biệt nằm ở chỗ dịch vụ nào sinh ra cho luồng dữ liệu thời gian thực có khả năng đọc lại và cắm thẳng vào analytics.

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

A — Amazon Kinesis Data Streams để ingest, AWS Lambda để xử lý, hoặc Amazon Kinesis Data Analytics để phân tích.

Kinesis Data Streams (KDS) là dịch vụ streaming dữ liệu thời gian thực, có độ bền cao và mở rộng rất lớn, có hỗ trợ cơ chế retry — đúng thứ đề nói đang thiếu. Dữ liệu ghi vào stream được giữ lại trong một khoảng thời gian lưu trữ, nên consumer đọc hỏng thì đọc lại được từ vị trí cũ; đó là điểm khác biệt căn bản so với một cơ chế push bắn đi rồi thôi.

KDS thu nhận dữ liệu liên tục từ rất nhiều nguồn cùng lúc (clickstream, event stream của database, giao dịch tài chính, log IT, dữ liệu định vị…) và dữ liệu sẵn sàng cho phân tích gần như tức thì. Thông lượng điều chỉnh được động theo lượng dữ liệu đầu vào, nên chính vấn đề "người dùng tăng vọt làm hệ thống chậm" được giải quyết bằng cách tăng năng lực của stream chứ không phải viết lại kiến trúc.

Cuối cùng, cùng một stream phục vụ được nhiều ứng dụng phân tích thời gian thực song song, đưa được sang Amazon S3 hoặc AWS Lambda, và cắm thẳng vào Kinesis Data Analytics. Đó là "minimal implementation overhead": toàn bộ đường ống là dịch vụ quản lý, không phải tự xây.

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

B — Amazon SQS ingest, AWS Lambda xử lý. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. SQS là dịch vụ messaging dùng để tách rời (decouple) các thành phần, giảm độ phức tạp của kiến trúc, và nó có cơ chế thử lại. Về lý thuyết SQS vẫn chạy được. Nhưng SQS là hàng đợi thông điệp rời rạc, mỗi thông điệp được một consumer lấy ra rồi xoá đi — nó không phải là mô hình luồng dữ liệu cho phép nhiều ứng dụng analytics cùng đọc lại. Kinesis Data Streams được thiết kế riêng cho dữ liệu streaming thời gian thực, đúng bài toán của đề. Khi câu hỏi đưa ra cả SQS lẫn KDS mà đề nhấn mạnh "real-time" và "analytics workflow", KDS là lựa chọn phù hợp hơn.

C — Amazon API Gateway với giao diện REST sẵn có. API Gateway là lớp cửa ngõ cho API: nhận request, xác thực, định tuyến, kiểm soát tần suất. Nó không dùng để xử lý dữ liệu streaming thời gian thực. Giữ nguyên giao diện REST hiện tại rồi bọc thêm API Gateway cũng không thêm được cơ chế retry cho luồng dữ liệu — vấn đề gốc mà đề nêu vẫn còn nguyên.

D — Amazon SNS ingest, AWS Lambda xử lý. SNS là dịch vụ messaging quản lý hoàn toàn cho giao tiếp application-to-application và application-to-person. Vấn đề: SNS là cơ chế push — nó đẩy thông điệp tới subscriber, không có cơ chế retry đủ mạnh như tình huống này đòi hỏi. Dữ liệu không nằm lại chờ được đọc lại theo cách một stream làm được, nên đúng cái thiếu sót mà đề chỉ ra vẫn chưa được vá.

📌 Điểm cần nhớ

• Thấy "real-time streaming data" kèm "analytics" trong đề thì nghĩ ngay tới Kinesis Data Streams, không phải hàng đợi hay lớp API.
• SQS vs SNS vs KDS: SQS là hàng đợi để decouple, SNS là push/pub-sub (retry yếu, không giữ dữ liệu để đọc lại), KDS là luồng dữ liệu có lưu trữ tạm nên đọc lại được và nhiều consumer đọc song song được.
• API Gateway là cửa ngõ API, không phải công cụ xử lý dữ liệu. Xuất hiện trong phương án của một câu hỏi về streaming thì gần như luôn là mồi nhử.
• Cụm "minimal implementation overhead" đẩy lựa chọn về phía dịch vụ quản lý sẵn, tự co giãn theo tải, thay vì giải pháp phải tự dựng thêm logic.

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

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

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

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

Đây là bẫy kinh điển: nghe thấy "cost-effective" là phản xạ chọn tầng lưu trữ rẻ hơn theo GB. Nhưng giá mỗi GB chỉ là một phần hóa đơn S3. Các tầng "infrequent access" và archive đều có minimum storage duration charge (tính tiền tối thiểu một khoảng thời gian dù bạn xóa sớm hơn) và retrieval fee (tính tiền mỗi lần đọc dữ liệu ra). Vòng đời 24 giờ đâm thẳng vào ràng buộc thứ nhất, còn "heavily referenced" đâm thẳng vào ràng buộc thứ hai.

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

D — S3 Standard.

S3 Standard là tầng dành cho dữ liệu được truy cập thường xuyên: độ bền cao, độ trễ thấp, throughput cao, phù hợp đúng với big data analytics. Điểm mấu chốt về chi phí trong ngữ cảnh này là S3 Standard không có minimum storage duration charge và không có retrieval fee.

Nghĩa là với dữ liệu chỉ tồn tại 24 giờ, bạn trả tiền lưu trữ đúng cho 24 giờ đó rồi thôi; và dù pipeline đọc lại kết quả trung gian bao nhiêu lần, bạn cũng không bị cộng thêm phí lấy dữ liệu ra. Giá mỗi GB của S3 Standard cao hơn các tầng còn lại, nhưng với vòng đời cực ngắn cộng tần suất đọc cực cao, phần "đắt hơn theo GB" đó nhỏ hơn hẳn so với tiền phạt thời gian tối thiểu và phí retrieval mà ba phương án kia bắt bạn trả. Trong bốn lựa chọn có sẵn, S3 Standard là tầng rẻ nhất về tổng chi phí thực tế.

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

A — S3 Glacier Instant Retrieval. Đây là phương án sai rõ nhất trong ba cái. Glacier Instant Retrieval quả thật cho truy cập tức thì với độ trễ mili giây ngang S3 Standard và S3 Standard-IA, nên nếu chỉ nhìn hiệu năng thì nó "chạy được". Nhưng nó là tầng archive, thiết kế cho dữ liệu lưu trữ dài hạn hiếm khi đụng tới (ảnh y tế, kho tư liệu báo chí, nội dung người dùng cũ). Minimum storage duration của nó là 90 ngày: lưu 24 giờ rồi xóa, bạn vẫn bị tính tiền như đã lưu 90 ngày. Cộng thêm phí retrieval cho dữ liệu bị đọc liên tục — hoàn toàn ngược với yêu cầu tiết kiệm.

B — S3 Standard-IA. Đây là phương án "gần đúng" hay bị chọn nhất, vì Standard-IA vẫn giữ độ bền, throughput và độ trễ như S3 Standard, chỉ khác là giá mỗi GB rẻ hơn. Nhưng nó hỏng ở đúng hai chỗ mà đề đã cài sẵn: minimum storage duration 30 ngày (dữ liệu sống 24 giờ, hóa đơn tính 30 ngày) và có phí retrieval theo GB (dữ liệu bị "heavily referenced" nên khoản này phình rất nhanh). Standard-IA đúng cho backup, lưu trữ dài hạn, kho dữ liệu phục vụ disaster recovery — tức là dữ liệu để lâu, ít đụng tới. Kết quả truy vấn trung gian là trường hợp ngược hẳn.

C — S3 One Zone-IA. Rẻ hơn Standard-IA khoảng 20% vì chỉ lưu trong một Availability Zone thay vì tối thiểu ba AZ như các tầng khác. Nhưng nó kế thừa nguyên hai vấn đề của Standard-IA: minimum storage duration 30 ngày và phí retrieval. Giảm giá theo GB không cứu được khi hai khoản kia mới là phần chi phối hóa đơn. Ngoài ra One Zone-IA còn đánh đổi độ bền theo AZ — hợp lý cho dữ liệu tái tạo được, nhưng ở đây nó vẫn thua về đúng tiêu chí đề hỏi là chi phí.

📌 Điểm cần nhớ

• "MOST cost-effective" không đồng nghĩa với "giá mỗi GB thấp nhất". Hóa đơn S3 gồm ba phần: giá lưu trữ, minimum storage duration charge, và retrieval fee. Phải cộng đủ cả ba mới so sánh được.
• Vòng đời dữ liệu là tín hiệu lọc phương án nhanh nhất. Dữ liệu sống ngắn hơn minimum storage duration của một tầng thì tầng đó tự động bị loại: S3 Standard-IA và S3 One Zone-IA tính tối thiểu 30 ngày, S3 Glacier Instant Retrieval tính tối thiểu 90 ngày.
• Đọc lại nhiều lần luôn đẩy về S3 Standard. Từ khóa kiểu "frequently accessed", "heavily referenced" báo hiệu phí retrieval sẽ là khoản lớn, mà S3 Standard là tầng duy nhất trong nhóm này không tính phí đó.
• S3 One Zone-IA khác Standard-IA chỉ ở số AZ và giá GB, không khác ở minimum duration hay retrieval fee. Nếu đã loại Standard-IA vì hai lý do đó thì One Zone-IA cũng bị loại theo, đừng chọn nó chỉ vì thấy "rẻ hơn 20%".

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

Đề mô tả kiến trúc cũ đang bị bó cứng: một EC2 nhận click từ website ghi vào Aurora, một EC2 khác liên tục dò thay đổi trong database rồi chạy SQL để sinh gợi ý sản phẩm. Kiểu "polling database" này vừa gắn chặt các thành phần với nhau, vừa không co giãn nổi khi lưu lượng tăng vọt.

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

• "decouple and scale" — phải tách phần thu dữ liệu khỏi phần xử lý, và phần thu phải tự co giãn.
• "analyzed in real-time" — phân tích ngay trên luồng dữ liệu đang chảy, không phải truy vấn dữ liệu đã nằm yên ở kho.
• "without any data loss even when the company sees huge traffic spikes" — lớp thu nhận phải đệm được dữ liệu và giữ lại được khi tải tăng đột biến, đồng thời kết quả phải được ghi bền vững xuống nơi lưu trữ.

Cả bốn phương án đều "decouple" được ở mức nào đó. Điểm phân biệt thật sự nằm ở thành phần nào làm việc phân tích thời gian thực, vì đó là chỗ ba phương án sai đều gãy.

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

Đáp án D: Kinesis Data Streams thu click từ website → Kinesis Data Analytics truy vấn thời gian thực → kết quả đẩy qua Kinesis Data Firehose để lưu xuống S3.

• Kinesis Data Streams là lớp thu nhận dữ liệu luồng: nó lo hạ tầng, lưu trữ, mạng và cấu hình cần thiết để nhận dữ liệu ở đúng mức thông lượng của bạn, nên không phải tự lo provisioning hay bảo trì. Đây chính là phần thay cho cặp "EC2 ghi vào Aurora" và giải quyết yêu cầu không mất dữ liệu khi tải tăng vọt.
• Kinesis Data Analytics là mắt xích quan trọng nhất của phương án này: nó biến đổi và phân tích dữ liệu luồng đến từ Data Streams ngay trong lúc dữ liệu đang chảy. Dịch vụ tự lo việc chạy ứng dụng streaming liên tục và tự co giãn theo khối lượng cũng như thông lượng dữ liệu đầu vào — không có server phải quản lý, chỉ trả tiền cho tài nguyên ứng dụng streaming tiêu thụ. Đây là thứ thay thế cho EC2 dò database rồi chạy SQL.
• Kinesis Data Firehose là dịch vụ ETL nhận, biến đổi và giao dữ liệu luồng tới data lake, data store và các dịch vụ phân tích. Ở đây nó nhận đầu ra đã phân tích của Data Analytics và đổ xuống S3 một cách tin cậy, không mất dữ liệu.

Thứ tự các mắt xích cũng đúng với ý đồ của đề: thu → phân tích thời gian thực → lưu bền vững.

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

Phương án A — SQS + fleet EC2 trong Auto Scaling group, scale theo số message tồn đọng, phân tích bằng thư viện bên thứ ba. Đây là phương án gần đúng nhất về mặt kiến trúc: SQS cộng EC2 quả thật có decouple được hệ thống, và chính sách scale theo số message chờ cũng là một cách co giãn hợp lệ. Chỗ nó hỏng là mảnh cuối cùng — tự chạy phân tích thời gian thực bằng một thư viện bên thứ ba trên EC2 không phù hợp với tình huống này. Bạn quay lại đúng thứ mà đề muốn bỏ đi: tự quản EC2, tự lo thư viện, tự lo mở rộng phần xử lý. Họ Kinesis mới là lựa chọn hợp hơn vì bao trọn cả ba việc — nạp dữ liệu luồng, phân tích thời gian thực, và giao dữ liệu tin cậy tới đích.

Phương án B — Kinesis Data Streams → QuickSight → Firehose → S3. Hỏng ngay ở mắt xích thứ hai, và hỏng theo hai cách. Thứ nhất, QuickSight không dùng được Kinesis Data Streams làm nguồn — hai dịch vụ đơn giản không nối trực tiếp với nhau như vậy. Thứ hai, QuickSight là công cụ trực quan hoá và báo cáo, không dùng để phân tích dữ liệu streaming thời gian thực ngay từ nguồn. Phần đầu (Data Streams) và phần cuối (Firehose → S3) của phương án này giống hệt đáp án đúng, nên rất dễ chọn nhầm nếu chỉ liếc qua; hãy soi vào đúng ô ở giữa.

Phương án C — Kinesis Data Streams → Firehose → S3, rồi dùng Athena phân tích thời gian thực. Athena là dịch vụ truy vấn tương tác cho phép phân tích dữ liệu đã nằm trong S3 bằng SQL chuẩn; nó serverless, không có hạ tầng phải quản, và chỉ tính tiền theo truy vấn bạn chạy. Nhưng Athena không dùng để phân tích thời gian thực được. Ở đây dữ liệu phải đi trọn đường xuống S3 rồi mới được truy vấn — đó là phân tích trên dữ liệu tĩnh, không phải trên luồng đang chảy, nên không đáp ứng yêu cầu "near-real-time recommendations" của đề.

📌 Điểm cần nhớ

• Trong họ Kinesis, mỗi dịch vụ có một vai riêng: Data Streams thu dữ liệu luồng, Data Analytics phân tích ngay trên luồng, Data Firehose giao dữ liệu tới đích lưu trữ như S3. Đề hỏi "real-time analytics" trên streaming thì thành phần phân tích phải là Data Analytics.
• Athena = truy vấn dữ liệu đã nằm trong S3, không phải công cụ streaming. Thấy Athena đứng ở vị trí "phân tích thời gian thực" là dấu hiệu phương án sai.
• QuickSight = trực quan hoá/BI, không nhận Kinesis Data Streams làm nguồn và không phân tích streaming từ nguồn.
• Khi nhiều phương án chỉ khác nhau đúng một mắt xích giữa, hãy đọc kỹ ô đó thay vì bị phần đầu và phần cuối giống nhau đánh lừa.
• Decouple bằng SQS + EC2 Auto Scaling là hợp lệ về nguyên tắc, nhưng nếu đề nhấn mạnh phân tích streaming thời gian thực thì phương án managed streaming vẫn hợp hơn phương án tự dựng trên EC2.

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

Đề mô tả một cluster Amazon Redshift chứa dữ liệu nhạy cảm. Quy định bắt buộc bật audit log, log phải được mã hoá khi lưu (at rest), giữ ít nhất một năm, và mỗi tháng phải truy vấn được để kiểm toán. Câu hỏi chốt lại: giải pháp nào tiết kiệm chi phí mà vẫn đáp ứng đủ.

Có hai cụm từ quyết định, và phải thoả cả hai:

1. "audit logs of the Redshift cluster" — audit logging của Redshift ghi ra Amazon S3, và ở chức năng này chỉ hỗ trợ SSE-S3 (AES-256). Đây là ràng buộc kỹ thuật loại thẳng mọi phương án đòi SSE-KMS, bất kể phần truy vấn phía sau đúng hay sai.
2. "cost-effective" + "monthly basis" — dữ liệu chỉ đụng tới mỗi tháng một lần. Trả tiền để nạp và giữ nó trong storage của cluster suốt cả năm là lãng phí; truy vấn tại chỗ trên S3 mới hợp.

Hai ràng buộc này ghép lại chỉ còn đúng một phương án: SSE-S3 + Redshift Spectrum.

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

Đáp án A — bật default encryption bằng SSE-S3 (AES-256) trên bucket S3 nhận audit log, rồi dùng Amazon Redshift Spectrum để truy vấn khi kiểm toán hằng tháng.

• Audit logging không bật sẵn trên Redshift; khi bật, Redshift tự tạo và đẩy log lên S3, mỗi lần cập nhật là phần nối tiếp của những gì đã ghi trước đó. Đây là quá trình xuất log sang S3, và loại mã hoá dùng được cho audit log là SSE-S3 (AES-256). Chọn đúng SSE-S3 nghĩa là log được mã hoá at rest bằng đúng cơ chế mà chức năng này chấp nhận.
• Redshift Spectrum cho phép chạy truy vấn SQL thẳng trên dữ liệu nằm trong S3, không cần load, không cần ETL. Truy vấn gửi tới endpoint Redshift, Redshift lập kế hoạch, xác định phần nào là dữ liệu local và phần nào nằm trên S3, tối ưu để đọc càng ít dữ liệu S3 càng tốt, rồi mượn worker Spectrum từ pool tài nguyên dùng chung để đọc và xử lý.
• Kết quả: log nằm nguyên trên S3 — nơi lưu trữ dài hạn rẻ — suốt cả năm, và mỗi tháng chỉ trả chi phí cho phần dữ liệu thực sự bị quét. Đó chính là nghĩa của "cost-effective" trong tình huống truy cập thưa.

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

B — SSE-S3 + COPY dữ liệu vào cluster Redshift mỗi khi cần kiểm toán. Đây là phương án gần đúng nhất: phần mã hoá hoàn toàn hợp lệ, đúng SSE-S3 như yêu cầu của audit logging. Nó hỏng ở vế chi phí. Nạp log vào cluster để phục vụ một đợt kiểm toán mỗi tháng đồng nghĩa chiếm dung lượng lưu trữ của cluster và tốn công sức xử lý cho dữ liệu chỉ dùng vài lần trong năm — trong khi Spectrum cho đúng khả năng truy vấn đó mà không phải chuyển dữ liệu đi đâu cả. Đề đã nói rõ "cost-effective", nên B thua A ở đúng tiêu chí phân biệt.

C — SSE-KMS + Redshift Spectrum. Phần truy vấn giống hệt A và hoàn toàn hợp lý. Nhưng phần mã hoá sai: audit logging của Redshift chỉ dùng được SSE-S3 (AES-256). Chọn SSE-KMS cho bucket nhận audit log là chọn thứ chức năng này không hỗ trợ, nên cấu hình không đáp ứng được yêu cầu đề ra. Đây là cái bẫy quen thuộc — SSE-KMS nghe "bảo mật hơn" (có kiểm soát khoá, có audit trail cho việc dùng khoá), khiến người làm bài mặc định coi nó là lựa chọn an toàn hơn, trong khi câu hỏi thực chất kiểm tra bạn có nhớ giới hạn của chính chức năng audit logging hay không.

D — SSE-KMS + Amazon QuickSight. Sai hai lớp. Thứ nhất, vẫn là SSE-KMS cho audit log — cùng vấn đề với C. Thứ hai, QuickSight là công cụ BI để trực quan hoá và làm dashboard, không phải cơ chế truy vấn SQL trên log lưu ở S3 như tình huống này cần; nhu cầu của đề là kiểm toán log, tức đọc và tra cứu nội dung log, chứ không phải dựng báo cáo hình ảnh.

📌 Điểm cần nhớ

• Redshift audit logging ghi ra S3 và chỉ hỗ trợ SSE-S3 (AES-256). Thấy phương án nào ghép audit log của Redshift với SSE-KMS thì loại ngay, không cần đọc tiếp vế sau.
• Audit logging không bật mặc định — đây là bước cấu hình thủ công, tuỳ chọn; log bắt đầu có từ thời điểm bật trở đi.
• "Truy cập thưa + cost-effective" ⇒ Redshift Spectrum, không phải COPY vào cluster. Spectrum truy vấn trực tiếp dữ liệu trên S3, không cần load hay ETL, nên dữ liệu lạnh cứ nằm ở nơi lưu trữ rẻ.
• Phân biệt vai trò công cụ: Spectrum để chạy SQL trên dữ liệu S3; QuickSight để trực quan hoá. Nhu cầu "query log để audit" thuộc vế thứ nhất.
• Với dạng câu hai vế (mã hoá + truy vấn), hãy lọc theo vế có ràng buộc cứng trước (ở đây là loại mã hoá), rồi mới dùng tiêu chí mềm như chi phí để chọn giữa các phương án còn lại.