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

Đáp án

B — Row-Level Security

Vì sao đúng

RLS của QuickSight gắn một tập quy tắc theo người dùng hoặc theo nhóm vào bộ dữ liệu: mỗi người mở cùng một bảng điều khiển nhưng chỉ thấy những dòng khớp quy tắc của mình. Nhờ vậy một bảng điều khiển phục vụ cả công ty mà dữ liệu tài chính chỉ hiện với người được phép, không phải nhân bản ra nhiều phiên bản.

Vì sao các phương án khác sai

• A. Xác thực đa yếu tố — tăng độ chắc chắn khi đăng nhập, không quyết định ai thấy dữ liệu nào.
• C. Lọc theo IP — kiểm soát nơi truy cập, không kiểm soát nội dung.
• D. Phân quyền theo vai IAM — quản được ai mở được bảng điều khiển, nhưng không lọc tới mức dòng bên trong bộ dữ liệu.

Đáp án

C — Bật mã hoá phía máy chủ bằng AWS KMS, và đặt thời hạn lưu trữ theo yêu cầu

Vì sao đúng

Đề có hai yêu cầu tuân thủ và phương án này trả lời đúng cả hai bằng thiết lập sẵn có của Kinesis: mã hoá phía máy chủ bằng KMS bảo vệ dữ liệu khi nằm trong luồng, không phải sửa mã ứng dụng; thời hạn lưu trữ nâng từ 24 giờ lên tới 365 ngày để giữ dữ liệu đúng khoảng mà quy định đòi hỏi.

Vì sao các phương án khác sai

• A. S3 cộng Macie — Macie phân loại dữ liệu nhạy cảm trên S3; nó không mã hoá luồng Kinesis.
• B. Enhanced fan-out cộng mã hoá phía máy khách — fan-out là chuyện thông lượng; mã hoá phía máy khách làm được nhưng bắt bạn tự quản khoá và sửa mọi producer lẫn consumer.
• D. Firehose xuống S3 kèm versioning — versioning giữ nhiều phiên bản đối tượng, không phải cơ chế giữ dữ liệu trong luồng, và bản thân nó không mã hoá gì.

Đáp án

B và C — Glue Jobs để biến đổi và nạp, Glue Workflows để điều phối và hẹn giờ

Vì sao đúng

Đề mô tả một đường ống ba bước: trích từ S3, đổi sang định dạng cột, nạp vào Redshift.

• C. Glue Jobs làm phần việc thật — đọc dữ liệu thô, đổi sang Parquet, ghi vào Redshift.
• B. Glue Workflows gói các job đó thành một quy trình có thứ tự và chạy theo lịch, đồng thời cho thấy bước nào hỏng để chạy lại từ đúng chỗ.

Vì sao các phương án khác sai

• A. Glue Data Quality — kiểm chất lượng dữ liệu, việc tốt nhưng đề không nêu.
• D. Glue Crawler — cập nhật lược đồ vào catalog; hữu ích nhưng không nằm trong ba bước đề hỏi.
• E. DataBrew để đổi sang định dạng cột — DataBrew là công cụ làm sạch trực quan; việc đổi định dạng ở quy mô này thuộc về ETL job.

Đáp án

B — Dùng DataBrew với phép biến đổi NEST_TO_MAP

Vì sao đúng

Yêu cầu là gộp bốn cột địa chỉ rời (Door_No, Street_Name, City, Zip_Code) thành một cấu trúc có tên trường. NEST_TO_MAP tạo ra kiểu map, tức là cặp khoá–giá trị, nên giữ được tên từng thành phần — sau này vẫn đọc được City là gì. Đó là điều phân biệt nó với các phép gộp khác.

Vì sao các phương án khác sai

• A. NEST_TO_ARRAY — cũng gộp lại nhưng thành mảng theo vị trí, mất hết tên trường; phải nhớ phần tử thứ ba là thành phố.
• C. PIVOT — xoay dòng thành cột, đổi hình dạng bảng chứ không gộp cột trong một dòng.
• D. Viết Lambda bằng Python — làm được, nhưng đề đang trong ngữ cảnh DataBrew và đây là cách phải viết mã cho việc đã có sẵn phép biến đổi.

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

Đề mô tả một microservice chạy trên Amazon ECS, container phục vụ cả nội dung tĩnh lẫn động qua một Application Load Balancer. Khi tải tăng, cluster bị nghẽn về network. Đội đã đo và phát hiện điều quan trọng nhất.

Cụm từ quyết định là: "90% of it is due to distributing static content" — 90% lưu lượng mạng đến từ việc phân phối nội dung tĩnh. Kèm theo đó là yêu cầu ở câu hỏi: improve network usage and decrease costs.

Hai chi tiết này khoá chặt đáp án theo hai chiều:

• Chiều "cái gì": phải xử lý phần static, không phải dynamic. Dynamic chỉ chiếm 10% lưu lượng, có tối ưu cũng không giải quyết được vấn đề.
• Chiều "đưa đi đâu": phải là nơi tự phục vụ nội dung ra Internet, tức là gỡ hẳn lưu lượng khỏi ECS, chứ không phải chỉ đổi chỗ lưu trữ file.

Bốn phương án là tổ hợp 2×2 của (static | dynamic) × (S3 | EFS) — kiểu đề cố tình bắt bạn chọn đúng cả hai chiều.

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

C — Distribute the static content through Amazon S3.

Amazon S3 có thể host static website: bạn bật tính năng website hosting cho bucket, tải nội dung lên, đặt permissions và khai index document; tuỳ nhu cầu còn cấu hình thêm redirect, log truy cập và trang lỗi tuỳ chỉnh.

Điểm mấu chốt: khi static content nằm trên S3, client tải thẳng từ S3. Request cho ảnh, CSS, JS, file tĩnh không còn đi qua Application Load Balancer rồi vào container ECS nữa. Nghĩa là 90% lưu lượng được offload hẳn ra khỏi ECS, giải phóng cluster để chỉ lo phần dynamic — đúng cả hai yêu cầu của đề: giảm network usage và giảm chi phí.

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

A — Distribute the static content through Amazon EFS

Đây là phương án gần đúng nhất, và cũng là bẫy chính. Nó chọn đúng chiều thứ nhất (static), nhưng sai chiều thứ hai. Amazon EFS là một NFS file system để mount vào compute resource — nó không phải endpoint mà trình duyệt của người dùng gọi tới. Kết quả: file tĩnh chuyển từ trong container ra EFS, nhưng ECS task vẫn là nơi đọc file đó rồi trả về cho client. Lưu lượng vẫn đi qua ALB, vẫn đi qua ECS, không giảm chút nào. Nó chỉ đổi chỗ lưu trữ, không đổi đường phân phối — mà đề hỏi về phân phối.

B — Distribute the dynamic content through Amazon EFS

Sai cả hai chiều. Sai về đối tượng: dynamic chỉ là 10% lưu lượng, không phải nguồn cơn vấn đề. Sai về cơ chế: giống lý do ở A, EFS vẫn cần ECS đứng ra phục vụ nội dung. Không giải quyết được gì.

D — Distribute the dynamic content through Amazon S3

Chọn đúng dịch vụ nhưng sai đối tượng, và tệ hơn là về mặt kỹ thuật không làm được. Nội dung động dựa vào xử lý phía server — server-side script kiểu PHP, JSP hay ASP.NET. Amazon S3 không hỗ trợ server-side scripting; nó chỉ trả về đúng object đã lưu. Đưa dynamic content lên S3 nghĩa là mất luôn phần logic sinh nội dung. Kể cả nếu làm được, nó cũng chỉ đụng tới 10% lưu lượng.

📌 Điểm cần nhớ

• Đọc kỹ con số phân bổ trong đề. Khi đề nói rõ "90% là do X", đáp án gần như chắc chắn phải tác động vào X. Phương án nhắm vào phần 10% còn lại là sai bất kể nghe hợp lý đến đâu.
• Phân biệt "nơi lưu trữ" và "nơi phân phối". EFS là file system để compute mount vào — dữ liệu vẫn phải qua compute mới ra được tới client. S3 là object store có thể tự phục vụ trực tiếp cho người dùng cuối. Chỉ loại thứ hai mới offload được lưu lượng khỏi ECS/ALB.
• S3 phục vụ static, không phục vụ dynamic. S3 không chạy server-side script; nội dung cần xử lý phía server phải ở lại trên compute layer như ECS.
• Với đề dạng tổ hợp 2×2, hãy loại theo từng chiều một thay vì so sánh cả bốn phương án cùng lúc: xác định đúng đối tượng (static hay dynamic) trước, rồi mới chọn dịch vụ phù hợp.

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

Đề mô tả một công ty dùng Amazon Redshift làm data warehouse, cluster đang chậm và họ muốn scale cả read lẫn write capacity để đáp ứng nhu cầu người dùng. Câu hỏi cuối cùng rất hẹp: bằng cách nào để bật concurrency scaling cho cluster?

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

• "scale read and write capacity" — đây là ràng buộc phân biệt. Nó loại ngay những cơ chế chỉ tác động tới truy vấn đọc.
• "The cluster runs on RA3 nodes" — câu này không phải thông tin trang trí. Concurrency scaling cho write operations chỉ được hỗ trợ trên node kiểu RA3. Đề đã cố tình nói rõ cluster đang chạy RA3, nghĩa là điều kiện tiên quyết đã thoả — không cần và không nên đổi kiểu node.

Ngoài ra chú ý động từ: đề hỏi "turn on", tức là hỏi đúng cái công tắc, không hỏi "cách nào tăng hiệu năng nói chung".

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

Đáp án đúng theo tệp là A — Enable workload manager (WLM) queue as a concurrency scaling queue. Set the Concurrency Scaling mode value to auto.

Với Concurrency Scaling, Amazon Redshift tự động thêm cluster capacity phụ để xử lý phần tăng đột biến của cả read query lẫn write query. Người dùng vẫn thấy dữ liệu mới nhất, bất kể truy vấn chạy trên main cluster hay trên concurrency-scaling cluster.

Cơ chế điều hướng truy vấn sang concurrency scaling cluster đi qua WLM: bạn bật một WLM queue thành concurrency scaling queue bằng cách đặt giá trị Concurrency Scaling mode = auto. Khi số truy vấn dồn vào queue đó vượt quá mức concurrency đã cấu hình của queue, các truy vấn đủ điều kiện được đẩy sang concurrency scaling cluster; khi có slot trống trở lại thì truy vấn chạy trên main cluster như bình thường. Việc định tuyến truy vấn vào queue này theo đúng cách của WLM: theo user group, theo query group label, hoặc theo WLM query monitoring rules (ví dụ đẩy mọi truy vấn chạy lâu hơn một ngưỡng nào đó sang concurrency scaling queue).

Nói ngắn gọn: WLM queue chính là nơi công tắc concurrency scaling nằm — đúng cái đề đang hỏi.

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

B — Enable Short query acceleration (SQA) SQA là một tính năng thật và cũng liên quan tới WLM, nên nó trông gần đúng. Nhưng SQA làm việc khác hẳn: nó ưu tiên các truy vấn ngắn, cho chúng chạy trong một không gian riêng để không phải xếp hàng sau các truy vấn dài. Đó là sắp xếp lại thứ tự phục vụ trên chính cluster hiện có, không phải thêm capacity. Quan trọng hơn với đề này: SQA không tác động tới write operations, trong khi đề nói rõ phải scale cả write. Chọn B là bỏ mất đúng một nửa yêu cầu của đề.

C — Re-configure the cluster to DC2 nodes and enable WLM queue as a concurrency scaling queue Nửa sau của phương án này chính là đáp án đúng, nên nó là bẫy khó chịu nhất. Chỗ hỏng nằm ở nửa đầu: concurrency scaling cho write operations chỉ được hỗ trợ trên RA3 nodes, không hỗ trợ trên các loại node khác. Cluster trong đề đã chạy RA3 rồi; chuyển sang DC2 là đi giật lùi, tự tay phá bỏ điều kiện cần cho phần write. Đây đúng là lý do đề nhắc tới RA3 ngay từ đầu.

D — Leverage custom parameter groups Parameter group trong Redshift là tập tham số gắn với cluster, áp cho mọi database tạo trong cluster đó — nó điều chỉnh các thiết lập cấp database như query timeout, date style, v.v. Đây là chỗ chỉnh hành vi database, không phải chỗ bật concurrency scaling. Phương án này đúng về mặt "có tồn tại thứ đó trong Redshift" nhưng sai chỗ đặt công tắc.

📌 Điểm cần nhớ

• Concurrency scaling được bật qua WLM queue, bằng cách đặt Concurrency Scaling mode = auto; không bật qua parameter group.
• Đề nhắc loại node (RA3 / DC2) là có ý: concurrency scaling cho write chỉ có trên RA3. Thấy đề nói "scale cả read và write" thì kiểm ngay kiểu node trước khi chọn.
• SQA ≠ concurrency scaling: SQA ưu tiên truy vấn ngắn trên capacity sẵn có và không đụng tới write; concurrency scaling thêm capacity và phục vụ cả read lẫn write.
• Với phương án ghép hai vế (như C), vế đúng không cứu được vế sai — phải đọc hết cả câu, đặc biệt là những vế đề nghị "đổi cấu hình hạ tầng" mà đề không hề yêu cầu.

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

Bối cảnh: công ty đang chuyển database từ Microsoft SQL Server chạy trên EC2 sang Amazon RDS for SQL Server. Trong lúc migration, đội data engineering cần export dữ liệu là kết quả của các phép JOIN nhiều bảng, chạy theo lịch hằng ngày, và ghi ra Apache Parquet trên S3.

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

• "derived from SQL joins across multiple tables" — dữ liệu không nằm gọn trong một bảng. Phải có chỗ nào đó định nghĩa phép join. Cách rẻ nhất về vận hành là tạo một view ngay trong SQL Server, để chính engine của database lo phần join; các nguồn dữ liệu bên ngoài chỉ việc đọc view như đọc một bảng.
• "stored in Apache Parquet format on Amazon S3" — định dạng đích phải là Parquet, và tốt nhất là ghi ra Parquet ngay từ lần ghi đầu tiên, không đi vòng qua định dạng trung gian.
• "most operationally efficient" — đây mới là ràng buộc phân biệt. Cả bốn phương án đều chạy được về mặt kỹ thuật. Câu hỏi không hỏi cái nào khả thi, mà hỏi cái nào ít code phải viết và ít thứ phải bảo trì nhất. Hễ thấy cụm "operationally efficient" trong đề AWS thì tiêu chí chấm là: managed service > code tự viết, một bước > nhiều bước, metadata tự khám phá > metadata khai bằng tay.

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

Đáp án đúng theo tệp là C: tạo view trong SQL Server trên EC2 → dùng AWS Glue crawler đọc view đó → AWS Glue job trích dữ liệu, chuyển sang Parquet và ghi lên S3 → đặt lịch cho Glue job chạy hằng ngày.

Chuỗi này khớp đúng ba ràng buộc ở trên và mỗi mắt xích đều là dịch vụ được quản lý:

• View trong SQL Server giữ toàn bộ logic join nằm ở phía database. Đội data engineering chỉ viết SQL một lần; sau đó view hiện ra như một đối tượng phẳng để đọc.
• Glue crawler kết nối tới view, tự đọc cấu trúc cột và kiểu dữ liệu, rồi tạo bảng tương ứng trong AWS Glue Data Catalog. Bảng trong Data Catalog chính là source table mà Glue job dùng để trích dữ liệu ra khỏi SQL Server. Điểm cốt lõi: schema được khám phá tự động, không ai phải khai tay danh sách cột và kiểu.
• Glue job đọc từ bảng trong Data Catalog, ghi thẳng ra Parquet trên S3 — Glue hỗ trợ sẵn Parquet làm định dạng đích, không cần thư viện tự cài hay code chuyển đổi.
• Lịch chạy hằng ngày là tính năng có sẵn của Glue job scheduler, không phải dịch vụ thứ ba gắn thêm.

Kết quả: một pipeline duy nhất, mỗi thành phần đều là managed service, không có dòng code hạ tầng nào phải nuôi.

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

Phương án B — view + Glue job đọc thẳng từ view, không có crawler. Đây là phương án gần đúng nhất và cũng là cái dễ chọn nhầm nhất, vì nó đúng về mặt kiến trúc: vẫn có view, vẫn Glue job, vẫn Parquet, vẫn chạy hằng ngày. Chỗ hỏng nằm ở phần metadata. Không có crawler thì không có bảng trong Glue Data Catalog, nên bản thân Glue job phải mang theo định nghĩa schema của view. Mỗi lần view đổi — thêm cột, đổi kiểu dữ liệu — là phải sửa job bằng tay. Crawler làm đúng việc đó tự động, nên bỏ crawler đi là kém hiệu quả về vận hành hơn, dù vẫn chạy được. Đề hỏi "most operationally efficient", nên "chạy được" không đủ để thắng.

Phương án D — SQL Server Agent chạy query hằng ngày, xuất .csv lên S3, rồi S3 event kích Lambda chuyển CSV sang Parquet. Hỏng ở chỗ hai bước thay vì một: ghi CSV trước rồi mới viết lại thành Parquet. Mỗi bản ghi bị đọc và ghi hai lần, và bạn phải nuôi thêm ba thứ rời rạc — job của SQL Server Agent, S3 event notification, và code Lambda chuyển đổi. Ba mảnh này không có chỗ nào quan sát chung, hỏng một mắt là phải lần theo cả chuỗi. Ngoài ra CSV trung gian còn đọng lại trên S3 và phải có cơ chế dọn riêng.

Phương án A — Lambda dùng JDBC query database, tự chuyển sang Parquet, EventBridge đặt lịch hằng ngày. Đây là phương án tự viết nhiều nhất. Bạn phải viết và duy trì: code kết nối JDBC, driver SQL Server đóng gói kèm hàm, câu query join, logic chuyển sang Parquet, logic upload S3, cộng với quản lý credential và cấu hình mạng cho Lambda. Toàn bộ khối đó là code của bạn — bạn chịu trách nhiệm sửa lỗi, nâng thư viện, xử lý lỗi kết nối. Glue crawler + Glue job cho ra đúng kết quả ấy mà gần như không phải viết gì. Đây chính là kiểu phương án "làm bằng tay thứ mà managed service đã làm sẵn".

📌 Điểm cần nhớ

• "Most operationally efficient" là tiêu chí chấm, không phải lời trang trí. Khi nhiều phương án đều chạy được, hãy xếp hạng theo lượng code tự viết và số thành phần phải bảo trì: managed service thắng code tự viết, một bước thắng nhiều bước.
• Dữ liệu là kết quả JOIN nhiều bảng → nghĩ tới view trong chính database. Để engine của database lo phép join, còn pipeline bên ngoài chỉ đọc một đối tượng phẳng. Ba trong bốn phương án ở đây đều dùng view, nên riêng nó không phân biệt được — phần phân biệt nằm ở cái đọc view.
• Glue crawler tồn tại để khỏi phải khai schema bằng tay. Crawler nạp metadata vào Glue Data Catalog, Glue job dùng bảng đó làm nguồn. Thấy hai phương án giống hệt nhau mà một cái có crawler, một cái không, thì cái có crawler là cái được chấm.
• Ghi thẳng ra định dạng đích, đừng đi vòng. Đề yêu cầu Parquet mà phương án lại xuất CSV rồi chuyển đổi sau là dấu hiệu loại rõ ràng — thêm một lần đọc/ghi, thêm file trung gian phải dọn, thêm một mắt xích có thể hỏng.

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

Đề mô tả một hãng truyền thông lưu assets có thể tạo lại được (re-creatable) trên Amazon S3. Mẫu truy cập: rất nhiều trong vài ngày đầu, sau một tuần thì giảm mạnh, nhưng vẫn phải lấy ra được ngay lập tức khi cần. Yêu cầu: giảm chi phí lưu trữ càng nhiều càng tốt.

Có hai cụm từ quyết định, và phải dùng cả hai mới loại hết được nhiễu:

1. "re-creatable assets" — dữ liệu mất đi thì tạo lại được. Đây là dấu hiệu kinh điển cho S3 One Zone-IA: bạn không cần trả thêm tiền cho việc nhân bản dữ liệu qua nhiều Availability Zone, vì nếu AZ đó gặp sự cố thì tái tạo lại asset là chuyện chấp nhận được.
2. "the frequency of access falls down drastically after a week" — cụm này trông như gợi ý chuyển tầng sau 7 ngày, và đó chính là cái bẫy. Lifecycle transition từ S3 Standard sang các lớp IA có thời gian lưu trữ tối thiểu là 30 ngày trước khi object đủ điều kiện chuyển tầng. Đề nêu mốc 7 ngày để dụ bạn chọn con số khớp với câu chữ, chứ không khớp với ràng buộc kỹ thuật.

Ngoài ra, cụm "immediately accessible when required" loại bỏ ý nghĩ về các lớp lưu trữ archive — nhưng ở đây cả bốn phương án đều là IA nên nó chỉ xác nhận hướng đi, không phân biệt được phương án nào.

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

B — Lifecycle policy chuyển sang S3 One Zone-IA sau 30 ngày.

• One Zone-IA dành cho dữ liệu ít được truy cập nhưng cần lấy ra nhanh. Khác các lớp S3 khác vốn lưu dữ liệu trên tối thiểu ba AZ, One Zone-IA chỉ lưu trong một AZ duy nhất, nhờ đó rẻ hơn S3 Standard-IA khoảng 20% (theo tài liệu nguồn của câu hỏi).
• Đánh đổi của One Zone-IA là khả năng chịu lỗi thấp hơn khi mất nguyên một AZ. Với dữ liệu re-creatable, đánh đổi này chính là thứ đề bài cho phép — đó là lý do One Zone-IA thắng Standard-IA về mục tiêu "giảm chi phí càng nhiều càng tốt".
• Về hiệu năng, One Zone-IA vẫn giữ độ bền cao, throughput cao và độ trễ thấp như S3 Standard, có phí lưu trữ theo GB thấp kèm phí truy xuất theo GB. Nên yêu cầu "truy cập tức thì" vẫn được đáp ứng.
• Mốc 30 ngày là con số hợp lệ: object phải nằm ở S3 Standard đủ thời gian lưu trữ tối thiểu rồi mới chuyển tầng được bằng lifecycle policy.
• Storage class đặt được ở mức từng object, một bucket chứa lẫn lộn nhiều lớp, và lifecycle policy tự động chuyển tầng mà không phải sửa ứng dụng.

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

A — S3 Standard-IA sau 30 ngày. Đây là phương án gần đúng nhất và là nhiễu mạnh: mốc 30 ngày hợp lệ, Standard-IA cũng cho truy cập tức thì với chi phí lưu trữ thấp. Chỗ nó hỏng là đắt hơn One Zone-IA, vì phải trả tiền cho việc lưu dư thừa qua nhiều AZ. Dữ liệu ở đây tạo lại được nên khoản chi phí dư thừa đó không mua lại giá trị gì, trong khi đề yêu cầu rõ "reducing costs as much as possible". Chọn A là bỏ sót cụm "re-creatable".

C — S3 Standard-IA sau 7 ngày. Sai vì mốc thời gian: chưa đủ thời gian lưu trữ tối thiểu ở S3 Standard thì lifecycle rule không chuyển object sang Standard-IA được. Ngoài ra nó còn mang luôn nhược điểm của A (đắt hơn mức cần thiết). Hai lỗi cùng lúc.

D — S3 One Zone-IA sau 7 ngày. Đây là bẫy tinh vi nhất: chọn đúng lớp lưu trữ (One Zone-IA, rẻ nhất trong nhóm, phù hợp dữ liệu re-creatable) nhưng sai mốc thời gian. Người học đọc thấy "after a week" trong đề rồi khớp thẳng vào "7 days" mà quên ràng buộc tối thiểu 30 ngày của lifecycle transition. Nói cách khác: mô tả nghiệp vụ đúng là truy cập giảm sau một tuần, nhưng điều đó không có nghĩa lifecycle rule chuyển tầng được ngay tại ngày thứ 7.

📌 Điểm cần nhớ

• "Re-creatable" / "reproducible" / "easily reproducible" trong đề → nghĩ ngay tới One Zone-IA. Đó là tín hiệu cho biết bài toán chấp nhận đánh đổi độ sẵn sàng của một AZ để lấy giá rẻ hơn Standard-IA.
• Đừng lấy mốc thời gian trong lời kể nghiệp vụ làm mốc cho lifecycle rule. Lifecycle transition từ S3 Standard sang các lớp IA đòi thời gian lưu trữ tối thiểu; đề thường cố tình nêu một con số nhỏ hơn để tạo phương án nhiễu.
• "Immediately accessible / rapid access when needed" loại các lớp archive và giữ bài toán trong nhóm IA — cần đọc kỹ vì nó phân biệt "ít truy cập" với "lưu trữ dài hạn chấp nhận chờ".
• Khi hai phương án chỉ khác nhau ở một biến, biến đó chính là điểm chấm. Ở đây có hai biến (lớp lưu trữ × mốc thời gian) tạo ra bốn phương án — phải trả lời đúng cả hai câu hỏi phụ mới ra đáp án, chỉ đúng một là rơi vào A hoặc D.

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

Một công ty tài chính lưu dữ liệu nhạy cảm trên Amazon S3. Quy định tuân thủ yêu cầu tệp phải được lưu với server-side encryption, thuật toán phải là AES-256, và công ty không muốn quản lý khoá mã hoá.

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

1. "server-side encryption" — loại thẳng mọi hình thức mã hoá ở phía client.
2. "AES-256" — nêu đích danh thuật toán khối.
3. "does not want to manage the encryption keys" — đây là ràng buộc phân biệt sắc nhất. Nó không chỉ nói "không muốn tự cầm khoá", mà còn hàm ý không muốn gánh việc quản trị khoá: tạo, xoay vòng, phân quyền, theo dõi.

Đề không đòi audit trail, không đòi kiểm soát chính sách khoá, không đòi khoá riêng theo từng phòng ban. Khi đề im lặng về những nhu cầu đó, phương án nào mang thêm gánh nặng quản trị mà đề không xin thì phương án đó thừa.

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

D — Server-side encryption with Amazon S3 managed keys (SSE-S3) thoả đủ ba ràng buộc, không dư không thiếu:

• Đây đúng là server-side encryption: S3 mã hoá khi ghi xuống đĩa và giải mã khi bạn đọc object, hoàn toàn trong suốt với ứng dụng.
• SSE-S3 dùng AES-256 — đúng chuẩn đề nêu tên.
• Mỗi object được mã hoá bằng một khoá riêng, và bản thân khoá đó lại được mã hoá bằng một master key do S3 quản lý và tự xoay vòng định kỳ. Toàn bộ vòng đời khoá nằm ở phía AWS, khách hàng không đụng tay vào — đúng ý "không muốn quản lý khoá".
• SSE-S3 không phát sinh phí phụ trội cho việc mã hoá, và là hành vi mã hoá mặc định của S3.

Nói gọn: đề mô tả chính xác định nghĩa của SSE-S3.

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

A — SSE-C (customer-provided keys). Đúng là server-side encryption thật, nhưng hỏng ngay ở ràng buộc thứ ba: với SSE-C, khách hàng phải tự sinh khoá, tự bảo quản, và gửi kèm khoá trong mỗi request đọc/ghi. AWS chỉ làm phần mã hoá – giải mã, còn khoá thì không lưu giữ. Đây là mức "phải quản lý khoá" nặng nhất trong bốn phương án — trái hẳn yêu cầu.

B — Client Side Encryption. Sai ở hai ràng buộc. Thứ nhất, đề yêu cầu server-side encryption, mà cách này mã hoá dữ liệu ngay tại phía client rồi mới tải bản đã mã hoá lên S3 — sai chỗ mã hoá. Thứ hai, khách hàng phải tự lo cả quy trình mã hoá, cả khoá, lẫn công cụ đi kèm — còn nặng hơn SSE-C về mặt vận hành.

C — SSE-KMS. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, nên cần chỉ rõ nó hỏng ở đâu. SSE-KMS là server-side encryption, và nó có một chế độ mà AWS quản lý khoá thay bạn, tức là về mặt kỹ thuật vẫn chạy được. Nó còn cho thêm audit trail (khoá được dùng lúc nào, bởi ai) và tuỳ chọn tự tạo, tự quản lý khoá. Vấn đề là: đề không hề xin audit trail hay quyền kiểm soát khoá, trong khi dùng KMS key phát sinh phí sử dụng. Chọn C là trả tiền cho năng lực mà bài toán không yêu cầu — nên nó không phải "best fit" cho tình huống này, dù không sai về mặt kỹ thuật.

📌 Điểm cần nhớ

• Bốn lựa chọn mã hoá của S3 phân biệt nhau ở câu hỏi "ai giữ khoá": SSE-S3 → AWS giữ hoàn toàn; SSE-KMS → quản lý qua KMS, có thể AWS hoặc bạn tạo khoá; SSE-C → bạn giữ khoá và gửi kèm mỗi request; Client-Side → bạn lo tất cả, kể cả việc mã hoá.
• Cụm "không muốn quản lý khoá" + không đòi audit → SSE-S3. Nếu đề thêm yêu cầu về audit trail, kiểm soát chính sách khoá, hay khoá riêng theo đơn vị, đáp án sẽ dời sang SSE-KMS.
• AES-256 không đủ để phân biệt phương án. Đây là chuẩn mã hoá chung, nêu ra chủ yếu để xác nhận rằng server-side encryption của S3 đáp ứng được; ràng buộc thật nằm ở phần quản lý khoá.
• Cẩn thận với phương án "mạnh hơn mức cần thiết". Trong các câu chọn kiến trúc, một dịch vụ có nhiều năng lực hơn mà kèm chi phí và độ phức tạp không được đề yêu cầu thường là bẫy, không phải đáp án.

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

Đề mô tả một job phân tích dữ liệu cần join dữ liệu nằm rải ở ba nơi khác nhau: Amazon DynamoDB (NoSQL), Amazon RDS (quan hệ) và Amazon Redshift (kho dữ liệu). Job này đang chạy trên Amazon Athena — đây là chi tiết đầu tiên cần chú ý, vì nó khoá sẵn công cụ truy vấn, chứ không mời bạn đi chọn engine khác.

Cụm từ quyết định đáp án là "MOST cost-effective". Cả bốn phương án đều làm được việc join — Glue Spark join được, EMR join được, copy hết vào S3 rồi query cũng join được. Khi mọi phương án đều đúng về mặt kỹ thuật, đề không hỏi "cái nào chạy được" mà hỏi "cái nào rẻ nhất". Ràng buộc phụ đi kèm là dữ liệu nằm ngoài S3, và Athena vốn là engine đọc S3 — nên câu hỏi thật sự là: có cách nào cho Athena đọc thẳng các nguồn kia mà không phải bê dữ liệu đi đâu không?

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

B — Use Amazon Athena Federated Query to join the data from all data sources.

Athena Federated Query sinh ra đúng cho tình huống này: khi dữ liệu nằm ở nguồn khác ngoài Amazon S3, bạn có thể truy vấn tại chỗ (query in place) thay vì phải trích xuất và nạp trước. Với Federated Query, một câu SQL duy nhất chạy được xuyên qua nguồn quan hệ, phi quan hệ, dạng object và cả nguồn tuỳ biến.

Cơ chế bên dưới là data source connector chạy trên AWS Lambda. Connector là đoạn mã dịch qua lại giữa nguồn đích và Athena — coi như phần mở rộng của query engine. AWS đã dựng sẵn connector cho hàng loạt nguồn, trong đó có Amazon DynamoDB và Amazon RDS cùng các nguồn quan hệ tương thích JDBC như MySQL, PostgreSQL — tức là phủ đúng những gì đề nêu.

Về chi phí: không cụm nào phải dựng, không bản sao dữ liệu nào phải trả tiền lưu trữ, không job ETL nào phải bảo trì. Bạn chỉ trả cho phần truy vấn và phần Lambda chạy connector. Đó là lý do nó thắng ở tiêu chí "cost-effective" — và nó cũng giữ nguyên Athena làm engine đúng như đề đã mô tả.

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

A — AWS Glue job dùng Apache Spark để join. Đây là phương án gần đúng nhất và hoàn toàn khả thi về kỹ thuật: Glue với Spark đọc được các nguồn này và join được. Chỗ nó hỏng là ở tiêu chí của đề. Bạn phải viết và bảo trì một job ETL, và trả tiền cho tài nguyên xử lý của Glue mỗi lần chạy — trong khi Federated Query cho ra cùng kết quả chỉ bằng một câu SQL. Nó cũng đẩy công việc ra khỏi Athena, dù đề đã nói rõ job đang chạy trên Athena.

C — Copy toàn bộ dữ liệu vào một S3 bucket rồi query bằng Athena. Nghe hợp lý vì Athena đọc S3 rất tự nhiên, nhưng nó tạo ra bản sao dữ liệu và kèm theo chi phí lưu trữ S3 không cần thiết. Ngoài ra bạn còn phải dựng và duy trì cơ chế sao chép dữ liệu từ ba nguồn về. Đây chính là thứ mà "query in place" của Federated Query sinh ra để tránh.

D — Dựng EMR cluster để join, cấu hình Spark cho Athena. Yếu nhất trong nhóm. Việc provision và cài đặt một cụm EMR tốn thời gian và không cost-effective cho bài toán này — bạn đang trả tiền cho hạ tầng cụm chỉ để làm một việc join mà một câu SQL giải quyết được. Vế "Configure Spark for Athena" còn là cách diễn đạt lệch: EMR và Athena là hai engine tách biệt, ghép như vậy chỉ làm kiến trúc rối thêm chứ không rẻ đi.

📌 Điểm cần nhớ

• Gặp từ khoá MOST cost-effective thì đừng dừng ở "phương án nào chạy được" — thường cả bốn đều chạy được. Hãy đếm xem phương án nào phải dựng hạ tầng, sao chép dữ liệu, hoặc bảo trì job; mỗi thứ đó là một khoản tiền, và phương án ít nhất thường là đáp án.
• Athena Federated Query = truy vấn dữ liệu ngoài S3 ngay tại chỗ bằng SQL, thông qua data source connector chạy trên Lambda. Có connector dựng sẵn cho DynamoDB, RDS và các nguồn JDBC-compliant.
• Khi đề đã nói rõ job đang chạy trên Athena, phương án đòi đổi sang Glue Spark hay EMR là đang đổi cả kiến trúc — cần lý do mạnh hơn hẳn mới hợp lý, và "join dữ liệu" thì chưa đủ mạnh.
• "Copy hết vào S3 rồi query" là cái bẫy quen thuộc: đúng về kỹ thuật, nhưng đẻ ra bản sao dữ liệu, chi phí lưu trữ và một đường ống đồng bộ phải nuôi. Federated Query tồn tại chính là để không phải làm bước đó.