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

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

Một tổ chức nghiên cứu y tế gom nhiều loại dữ liệu nghiên cứu (thử nghiệm lâm sàng, khảo sát bệnh nhân, hồ sơ bệnh án) từ nhiều định dạng và nhiều database khác nhau vào một data lake tập trung trên AWS. Đề hỏi: nên dùng dịch vụ nào để quản lý data lake đó, đảm bảo truy cập được bảo mật và có quản trị (governed) cho nhà nghiên cứu phân tích.

Cụm từ quyết định nằm ở chính câu hỏi: "manage their data lake, ensuring secure and governed access", cộng với "manage this diverse data in a unified manner" và yêu cầu tuân thủ quy định về bảo mật – riêng tư dữ liệu y tế.

Đây là chỗ phân biệt các phương án: đề không hỏi cách truy vấn dữ liệu, không hỏi cách mã hoá, không hỏi cách phát hiện dữ liệu nhạy cảm. Đề hỏi dịch vụ dựng, bảo vệ và quản trị chính data lake — tức là một lớp governance tập trung với phân quyền chi tiết, chứ không phải một mảnh ghép kỹ thuật riêng lẻ.

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

Đáp án đúng theo tệp là C — AWS Lake Formation.

Lake Formation sinh ra đúng để làm việc mà đề mô tả: dựng data lake, bảo vệ nó và quản trị nó ở một chỗ. Nó cung cấp quản lý bảo mật tập trung với fine-grained access control trên các tài nguyên dữ liệu — cấp quyền theo database, theo bảng, theo cột, thay vì chỉ cấp quyền thô ở mức bucket hay prefix trên S3.

Với tổ chức y tế, đây chính là điểm mấu chốt: hồ sơ bệnh án và khảo sát bệnh nhân chứa cột nhạy cảm, nhà nghiên cứu cần phân tích nhưng không được thấy mọi thứ. Lake Formation cho phép định nghĩa quyền ở mức chi tiết đó tại một nơi duy nhất, thay vì rải policy khắp nhiều dịch vụ.

Lake Formation cũng tích hợp với các dịch vụ AWS khác dùng để lưu trữ và phân tích dữ liệu, nên nó là giải pháp trọn gói cho việc quản lý và khai thác data lake — đúng với yêu cầu "unified manner" của đề.

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

A. Redshift Spectrum + AWS KMS — Redshift Spectrum lo việc truy vấn dữ liệu nằm trong data lake, còn KMS lo việc mã hoá. Cả hai đều hữu ích, nhưng chúng chỉ giải quyết hai lát cắt hẹp. Chúng không giải quyết những yêu cầu rộng hơn của việc quản lý data lake: tổ chức dữ liệu, governance, và phân quyền chi tiết. Trả lời A là trả lời câu "làm sao truy vấn và mã hoá", không phải câu đề đang hỏi.

B. S3 Object Lock + IAM — Đây là phương án dễ nhầm nhất vì nó "nghe có vẻ bảo mật". S3 và IAM đúng là nền tảng của lưu trữ và phân quyền trên AWS, và Object Lock cho tính bất biến (immutability) của dữ liệu — nghe hợp với ngành y tế. Nhưng hỏng ở chỗ: immutability không phải là governance, và IAM policy trên S3 cấp quyền theo đường dẫn đối tượng chứ không hiểu cấu trúc bảng/cột của dữ liệu nghiên cứu. Phương án này thiếu hẳn năng lực quản lý và quản trị data lake toàn diện mà Lake Formation cung cấp.

D. AWS Glue + Amazon Macie — Phương án gần đúng thứ hai. Glue làm catalog dữ liệu, Macie phát hiện dữ liệu nhạy cảm phục vụ bảo mật và tuân thủ. Nghe như đã đủ hai vế "quản lý" và "bảo mật". Nhưng ghép hai dịch vụ này lại vẫn không thành một giải pháp hoàn chỉnh để dựng và quản lý data lake với fine-grained access control như Lake Formation. Catalog cho biết dữ liệu có gì và ở đâu; Macie cho biết chỗ nào có dữ liệu nhạy cảm — nhưng không cái nào thực thi quyền truy cập chi tiết lên dữ liệu đó.

📌 Điểm cần nhớ

• Đề hỏi "build, secure, manage a data lake" kèm "governed access" hay "fine-grained access control" → nghĩ tới AWS Lake Formation trước tiên.
• Phân biệt vai trò: Glue = catalog (biết dữ liệu có gì), Macie = phát hiện dữ liệu nhạy cảm, KMS = mã hoá, Redshift Spectrum = truy vấn, Lake Formation = quản trị và thực thi quyền. Biết dữ liệu ở đâu khác với kiểm soát ai được đọc nó.
• IAM trên S3 cấp quyền ở mức đối tượng/prefix, không hiểu bảng và cột. Khi đề nhấn vào phân quyền chi tiết theo cột, IAM thuần là dấu hiệu phương án sai.
• S3 Object Lock giải bài toán bất biến/chống sửa xoá, không phải bài toán quản trị truy cập — đừng để hai chữ "compliance" trong đề kéo mình sang nhầm hướng.

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

Đề mô tả hệ thống xử lý giao dịch chính (OLTP) chạy trên Amazon RDS for PostgreSQL, và yêu cầu chọn HAI biện pháp giảm tải CPU cho instance.

Cụm từ quyết định đáp án nằm ở ngay câu đầu: "The workload is write-heavy" — khối lượng công việc thiên về ghi. Đây chính là ràng buộc phân biệt bốn phương án nghe đều rất "chuẩn AWS". Ba trong năm phương án (ElastiCache, read replica, tăng IOPS) là những kỹ thuật tối ưu quen thuộc cho RDS, nhưng chúng nhắm vào đọc hoặc nhắm vào I/O chứ không nhắm vào CPU của tải ghi.

Cụm từ thứ hai đáng chú ý là "alleviate the CPU load" — đề hỏi đích danh CPU, không hỏi chung chung "cải thiện hiệu năng". Bất kỳ phương án nào không tác động trực tiếp tới lượng công việc CPU phải làm đều bị loại.

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

Đáp án là A và E.

A — Bật Amazon RDS Performance Insights. Đây là tính năng của RDS cho phép nhìn thấy database load được phân rã theo câu SQL, theo wait event và theo user. Nhờ đó data engineer xác định được chính xác truy vấn nào đang ngốn CPU, rồi tối ưu chính truy vấn đó. Cách này giải quyết nguyên nhân gốc thay vì chỉ đắp thêm phần cứng — có khả năng xử lý xong vấn đề mà không cần scale gì cả.

E — Scale up lên instance class lớn hơn, nhiều CPU và memory hơn. Đây là cách trực tiếp nhất cho vấn đề CPU cao: cấp thêm tài nguyên tính toán để instance kham nổi tải ghi. Với tải write-heavy, scale dọc (đổi instance class) là hướng đi hợp lệ, vì tải ghi luôn phải đi qua primary instance — không có cách nào chia bớt nó sang node khác trong kiến trúc RDS thông thường.

Hai phương án này bổ sung cho nhau: A là chẩn đoán và tối ưu, E là tăng năng lực. Đó là cặp hợp lý cho một câu hỏi "chọn hai".

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

B — Amazon ElastiCache để cache truy vấn thường dùng. Đây là phương án gần đúng và dễ chọn nhầm nhất, vì ElastiCache đúng là công cụ giảm tải database. Nhưng nó hỏng ở chỗ: caching chỉ có tác dụng với truy vấn đọc lặp lại. Đề đã nói rõ tải là write-heavy, mà thao tác ghi thì không cache được — mỗi lệnh INSERT/UPDATE đều phải xuống database thật. Chính lời văn của phương án cũng tự tố cáo nó: "decrease the read load", trong khi vấn đề là tải ghi.

C — Tạo read replica để tách thao tác đọc. Cùng một lỗi logic với B, chỉ khác công cụ. Read replica rất hiệu quả trong kịch bản read-heavy, nhưng ở đây phần đọc không phải thủ phạm. Quan trọng hơn: replica không nhận được thao tác ghi — mọi write vẫn đổ hết vào primary, nên CPU của primary gần như không giảm. Thậm chí primary còn phải làm thêm việc gửi thay đổi sang replica.

D — Tăng IOPS cho instance. Phương án này gần đúng ở chỗ nó nhắm vào tải ghi thật. Nhưng nó hỏng ở sai loại tài nguyên: IOPS thuộc về tầng storage, giải quyết nghẽn I/O — biểu hiện là độ trễ đĩa cao, hàng đợi I/O dài. Triệu chứng đề đưa ra là CPU utilization cao, một chỉ số hoàn toàn khác. Tăng IOPS khi nghẽn nằm ở CPU thì chỉ tốn tiền mà đồ thị CPU không nhúc nhích.

(Lưu ý: phần giải thích gốc của đề khi nói về D có một dòng nhắc tới "regularly rebooting the RDS instance" — đó là câu bị lẫn từ phương án khác, không khớp với nội dung D. Lý do loại D đúng vẫn là lý do IOPS ≠ CPU nêu trên.)

📌 Điểm cần nhớ

• Đọc kỹ read-heavy hay write-heavy trước khi chọn. Đây là ràng buộc AWS dùng đi dùng lại để loại ElastiCache và read replica — cả hai chỉ giảm tải đọc. Thấy "write-heavy" thì gạch ngay hai phương án đó.
• Khớp đúng loại tài nguyên bị nghẽn. CPU cao → thêm CPU (đổi instance class) hoặc giảm việc CPU phải làm (tối ưu query). Nghẽn I/O mới là chỗ dùng IOPS/storage type. Đề luôn nêu rõ chỉ số nào đang cao.
• Performance Insights là câu trả lời mặc định cho "tìm truy vấn tốn tài nguyên" trên RDS. Khi đề hỏi chẩn đoán nguyên nhân hiệu năng ở tầng database, đây gần như luôn là một trong các đáp án đúng.
• Tải ghi chỉ scale dọc được trên RDS truyền thống. Mọi write đều đi qua primary, nên không thể chia tải ghi bằng cách thêm replica — chỉ còn cách tăng năng lực của chính primary.

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

Một analyst cần gộp dữ liệu khách hàng nằm rải ở bốn nơi — DynamoDB, RDS, Redshift và S3 — để join lại và phân tích.

Cụm từ quyết định đáp án nằm ở hai chỗ:

• "one-time comprehensive report" / "one-time task" — đây là việc làm một lần, không phải pipeline chạy định kỳ. Mọi giải pháp đòi dựng hạ tầng, xây ETL hay quản lý cluster đều phải trả chi phí thiết lập mà chỉ dùng đúng một lần rồi bỏ.
• "most cost-effective way" — tiêu chí chấm là chi phí, không phải hiệu năng hay khả năng mở rộng.

Cộng thêm một ràng buộc kỹ thuật ngầm: nguồn dữ liệu gồm cả DynamoDB (NoSQL) lẫn RDS (quan hệ), nên công cụ được chọn phải đọc được cả những nguồn không phải S3.

Ghép ba yếu tố lại: cần một cách query dữ liệu tại chỗ, serverless, trả tiền theo lượt query, không di chuyển dữ liệu.

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

Đáp án C — Amazon Athena Federated Query.

Athena Federated Query dùng các data source connector để Athena chạy SQL trực tiếp trên những nguồn nằm ngoài S3: DynamoDB, RDS, Redshift đều nằm trong nhóm nguồn được hỗ trợ. Nhờ vậy analyst viết một câu SQL duy nhất join dữ liệu từ cả bốn nguồn, không phải sao chép hay đồng bộ gì trước.

Vì sao nó khớp với "one-time" và "cost-effective":

• Không di chuyển dữ liệu → không tốn chi phí truyền và không phát sinh bản sao lưu trữ thêm.
• Serverless, trả tiền theo lượt query → không có hạ tầng nào chạy không tải sau khi báo cáo xong.
• Không có bước chuẩn bị → analyst hỏi xong là có kết quả, không phải chờ một job ETL chạy trước.

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

A — Redshift Spectrum. Sai vì lý do năng lực chứ không chỉ vì chi phí. Redshift Spectrum sinh ra để Redshift đọc dữ liệu nằm trong S3 thông qua external table; nó không phải cơ chế truy vấn liên nguồn tới DynamoDB hay RDS. Chọn A thì hai trong bốn nguồn của đề đơn giản là không với tới được — đề đòi join tất cả các nguồn. Ngoài ra Spectrum còn cần một Redshift cluster đứng sau, tức là hạ tầng phải chạy, đắt hơn lựa chọn serverless cho một việc làm một lần.

B — Glue ETL gom về S3 rồi dùng Athena. Đây là phương án gần đúng nhất và về mặt kỹ thuật hoàn toàn khả thi — nó thực sự cho ra kết quả. Nó hỏng ở chỗ thừa một bước cho một việc chỉ làm một lần: phải viết job Glue, chạy job, trả tiền cho thời gian xử lý của Glue, rồi trả thêm tiền lưu bản sao dữ liệu trên S3, sau đó mới query bằng Athena. Toàn bộ công sức xây pipeline đó chỉ được khấu hao đúng một lần. Nếu đề nói báo cáo chạy hằng ngày/hằng tuần thì B mới là lựa chọn hợp lý, vì lúc ấy dữ liệu đã ở dạng tối ưu cho việc đọc lặp lại.

D — EMR cluster với Apache Spark. Đây là phương án nặng tay nhất. Phải provision cluster, cấu hình connector cho từng nguồn, viết code Spark, rồi nhớ tắt cluster. Chi phí cluster tính theo thời gian chạy chứ không theo lượng dữ liệu quét, nên cho một báo cáo duy nhất thì phần lớn tiền bỏ ra là cho việc dựng và quản lý chứ không phải cho công việc thật. EMR phù hợp với xử lý quy mô lớn, lặp lại, có logic phức tạp — không phải một câu join ad-hoc.

📌 Điểm cần nhớ

• "One-time" / "ad-hoc" + "cost-effective" → nghiêng về serverless, pay-per-query. Athena là mặc định cho tín hiệu này; Glue ETL và EMR chỉ hợp lý khi công việc lặp lại đủ nhiều để bù chi phí dựng.
• Athena Federated Query = query nhiều nguồn tại chỗ. Khi đề liệt kê một danh sách nguồn hỗn tạp (NoSQL + quan hệ + data warehouse + object storage) và yêu cầu join chúng mà không di chuyển dữ liệu, đây là dấu hiệu nhận diện.
• Redshift Spectrum ≠ federated query. Spectrum là Redshift đọc external table trên S3. Thấy phương án dùng Spectrum để chạm tới DynamoDB hay RDS thì loại ngay, đó là bẫy hay lặp lại.
• Phân biệt "di chuyển dữ liệu rồi query" với "query tại chỗ". Gom về một chỗ (Glue → S3) tốn chi phí trước nhưng rẻ về sau; query tại chỗ không tốn gì trước nhưng mỗi lượt query đắt hơn. Tần suất sử dụng trong đề là thứ quyết định chọn vế nào.

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

Đề mô tả một doanh nghiệp lớn có nhiều AWS account và rất nhiều dịch vụ AWS đang chạy. Nhu cầu của họ là aggregate, manage, and analyze audit logs trên toàn bộ các account và dịch vụ đó, phục vụ security and compliance auditing, và họ muốn một centralized solution làm đơn giản hoá việc quản lý – phân tích log.

Cụm từ quyết định đáp án là "audit logs" đi kèm "aggregate ... across multiple AWS accounts and services" và "centralized solution". Ba mảnh này ghép lại loại được gần hết danh sách:

• "audit logs" — tức là bản ghi ai đã gọi API nào, lúc nào — chứ không phải bản ghi tài nguyên đang được cấu hình ra sao. Đây là ranh giới tách A khỏi B.
• "centralized" + "multiple accounts" — cần một nơi chứa và truy vấn chung, chứ không phải cơ chế báo sự kiện rời rạc hay code tự viết. Đây là ranh giới tách A khỏi C và D.
• Đề còn nói "analyze", nghĩa là chỉ gom log về một chỗ là chưa đủ — phải truy vấn được trên đống log đã gom.

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

Đáp án đúng theo tệp là A — AWS CloudTrail Lake.

CloudTrail là dịch vụ sinh ra chính loại dữ liệu mà đề gọi tên: audit log của các lời gọi API trong AWS account. CloudTrail Lake là phần mở rộng được thiết kế đúng cho tình huống của đề: gom (aggregate) các sự kiện CloudTrail vào một kho dữ liệu tập trung, giữ chúng trong thời gian dài phục vụ compliance, và truy vấn trực tiếp bằng SQL ngay trên kho đó mà không cần dựng thêm đường ống xử lý.

Quan trọng với đề bài này: CloudTrail Lake làm việc được ở phạm vi nhiều account cùng lúc (organization-level), nên một doanh nghiệp có hàng loạt account không phải đi thu gom log ở từng account rồi tự ghép lại. Đó chính là ba yêu cầu đề nêu — aggregate, manage, analyze — được một dịch vụ managed giải quyết trọn, đúng nghĩa "centralized solution that simplifies log management and analysis".

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

B — AWS Config. Đây là phương án gần đúng nhất, và nó gần đúng vì AWS Config cũng gắn với chữ "auditing": nó ghi lại lịch sử configuration changes của tài nguyên và có tính năng aggregator gom dữ liệu từ nhiều account. Chỗ nó hỏng là loại dữ liệu: Config trả lời câu hỏi "tài nguyên này đang được cấu hình thế nào, và cấu hình đã đổi ra sao theo thời gian", chứ không phải "ai đã gọi API nào". Đề hỏi về audit logs trên các dịch vụ AWS nói chung, không phải riêng trạng thái cấu hình tài nguyên. Chọn B là trả lời đúng chữ "audit" nhưng sai vế "logs".

C — Amazon S3 event notifications. S3 event notifications chỉ là cơ chế phát tín hiệu khi có thay đổi trong một bucket (object được tạo, bị xoá…) rồi đẩy sang đích nhận. Nó không thu thập log từ các dịch vụ AWS khác, không tự gom dữ liệu từ nhiều account, và bản thân nó không có khả năng truy vấn hay phân tích gì cả — nó chỉ báo rằng "có chuyện xảy ra". Đề đòi cả manage lẫn analyze, phương án này không đáp ứng vế nào.

D — AWS Lambda functions. Về lý thuyết bạn có thể viết Lambda đi gom và xử lý log. Nhưng đó là một giải pháp tự xây: phải tự viết logic thu thập cho từng dịch vụ, tự lo cấp quyền cross-account, tự chọn nơi lưu, tự dựng lớp truy vấn, rồi tự bảo trì tất cả. Đề nói rõ họ muốn thứ "simplifies log management" — một khối code tuỳ biến trải trên nhiều account là làm điều ngược lại. Trong đề thi AWS, khi một phương án managed đã phủ đúng yêu cầu, phương án "tự viết Lambda" gần như luôn là phương án sai vì nó thêm gánh nặng vận hành mà không thêm năng lực gì.

📌 Điểm cần nhớ

• CloudTrail = ai gọi API gì (audit log). AWS Config = tài nguyên được cấu hình ra sao (configuration history). Đây là cặp phân biệt xuất hiện đi xuất hiện lại; đọc đề thấy chữ "audit log", "API activity", "who did what" thì nghiêng về CloudTrail, thấy "configuration change", "compliance rule trên tài nguyên" thì nghiêng về Config.
• CloudTrail Lake là vế "analyze" của CloudTrail: gom sự kiện vào một kho tập trung, lưu dài hạn cho compliance, và truy vấn bằng SQL ngay tại chỗ — hợp với đề nào ghép "centralized" + "multi-account" + "query/analyze audit logs".
• S3 event notifications là cơ chế báo sự kiện, không phải công cụ tổng hợp log. Thấy nó xuất hiện trong đề về log aggregation thì gần như chắc chắn là phương án gây nhiễu.
• Phương án "dùng Lambda tự xây" thua phương án managed khi đề nhấn vào simplify, centralized, reduce operational overhead — trừ khi đề yêu cầu một logic tuỳ biến mà không dịch vụ nào có sẵn.

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

Đề mô tả một công ty đa quốc gia dùng Amazon EMR để xử lý dữ liệu và Amazon Athena để truy vấn ad hoc. Yêu cầu gồm hai vế:

1. Cần một kho metadata dùng chung (unified metadata repository) để lưu và truy cập table schema, table properties cho cả EMR lẫn Athena.
2. Cần đưa metadata sẵn có từ một hệ thống Apache Hive cũ vào kho đó.

Cụm từ quyết định nằm ở câu hỏi cuối: "with minimal development effort". Đây là ràng buộc phân biệt các phương án — nhiều lựa chọn trong danh sách về mặt kỹ thuật đều có thể dựng ra một metastore dùng chung, nhưng chỉ một lựa chọn không bắt bạn phải tự dựng hạ tầng, tự cấu hình kết nối hay tự viết lớp trung gian. Cộng thêm cụm "across these services" (EMR và Athena), phương án phải là thứ mà cả hai dịch vụ đều nói chuyện được một cách tự nhiên.

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

B. Leverage the AWS Glue Data Catalog as the centralized metadata repository.

AWS Glue Data Catalog là dịch vụ được quản lý, đóng vai trò kho metadata trung tâm và tương thích với cả Amazon EMR lẫn Amazon Athena. Nó lưu bền vững các định nghĩa bảng, schema và những thuộc tính khác — đúng thứ đề bài mô tả là "table schemas and properties".

Về vế thứ hai, Glue Data Catalog nhập được metadata từ Apache Hive với công sức tối thiểu: nó được thiết kế để tích hợp liền mạch với Hive, nên không phải cấu hình thủ công từng phần hay dựng thêm hạ tầng nào khác. Hai vế yêu cầu của đề được một dịch vụ duy nhất đáp ứng, và đó chính là nghĩa của "minimal development effort".

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

A. AWS Lake Formation để quản lý metadata và quản trị quyền truy cập dữ liệu. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Lake Formation được thiết kế để xây dựng data lake có kiểm soát bảo mật, và bản thân nó dùng chính Glue Data Catalog làm thành phần bên trong. Nghĩa là chọn Lake Formation là chọn một lớp bọc phía trên thứ mà bạn thật sự cần, kéo theo phần thiết lập quản trị quyền truy cập mà đề bài không hề yêu cầu. Đề chỉ hỏi kho metadata dùng chung, không nói gì tới phân quyền — nên xét theo tiêu chí "ít công sức phát triển nhất", dùng thẳng Glue Data Catalog thắng.

C. Dựng một Amazon Aurora PostgreSQL-compatible database làm metadata store riêng. Về nguyên tắc bạn có thể tự vận hành một metastore trên một database quan hệ, nhưng đó là hướng ngược hoàn toàn với ràng buộc của đề: phải tự dựng instance, tự cấu hình, tự bảo trì, tự lo vá lỗi và sẵn sàng cao, rồi còn phải tự nối nó vào EMR và Athena. Glue Data Catalog là dịch vụ được quản lý hoàn toàn nên loại bỏ toàn bộ khối việc đó.

D. Dùng tích hợp của Amazon Athena với Hive metastore sẵn có để nhập metadata trực tiếp. Đây cũng là phương án gần đúng — Athena thật sự có khả năng kết nối tới một Hive metastore đang tồn tại, nên nghe rất hợp với vế "legacy Apache Hive". Nhưng nó hỏng ở hai chỗ: quy trình này phức tạp hơn, không đơn giản bằng dùng Glue Data Catalog vốn đã được thiết kế để tích hợp liền mạch với Hive; và phương án diễn đạt theo hướng lấy Athena làm trung tâm, trong khi đề đòi một kho metadata dùng chung cho cả EMR lẫn Athena, chứ không phải một đường nối riêng cho một dịch vụ.

📌 Điểm cần nhớ

• Thấy đề yêu cầu kho metadata trung tâm dùng chung giữa nhiều dịch vụ phân tích của AWS (EMR, Athena…) thì mặc định nghĩ tới AWS Glue Data Catalog trước tiên.
• Cụm "minimal development effort" / "least operational overhead" gần như luôn loại các phương án đòi tự dựng và tự vận hành hạ tầng (như tự chạy metastore trên Aurora/RDS).
• Lake Formation ≠ Glue Data Catalog. Lake Formation dùng Glue Data Catalog bên trong và bổ sung phần quản trị quyền truy cập; chỉ chọn nó khi đề có nói tới bảo mật, phân quyền hay quản trị data lake.
• Glue Data Catalog tương thích với Hive, nên khi đề nhắc "di chuyển metadata từ Hive cũ", đó là tín hiệu ủng hộ Glue chứ không phải lý do để chọn một đường tích hợp Hive metastore riêng cho từng dịch vụ.

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

Đề mô tả một công ty lưu tài liệu nhạy cảm trong S3 bucket và muốn chỉ một số người dùng nhất định được tải về và giải mã tài liệu đó.

Cụm từ quyết định nằm ở vế cuối: "even if other users have S3 bucket access" — kể cả khi những người khác đã có quyền truy cập bucket. Câu này gạt bỏ mọi giải pháp chỉ dựa vào quyền ở tầng S3 (bucket policy, IAM policy cho s3:GetObject), bởi vì đề đã giả định trước rằng người khác đã qua được cửa đó. Điều đề hỏi là: khi đối tượng đã nằm trong tay họ, còn lớp kiểm soát nào chặn việc giải mã không?

Cụm thứ hai đáng chú ý là "download and decrypt" — hai hành động tách bạch. Đề cố ý phân biệt quyền đọc object với quyền dùng khoá. Phương án nào gộp hai thứ đó làm một là phương án hỏng.

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

B — SSE-KMS kèm key policy xác định quyền dùng khoá.

Với SSE-KMS, khoá mã hoá là một KMS key có policy riêng của nó, độc lập với bucket policy. Khi một người gọi GetObject trên object đã mã hoá bằng SSE-KMS, S3 phải gọi KMS để giải mã data key; lời gọi đó được KMS đánh giá theo key policy (và IAM policy) của người gọi. Không có quyền kms:Decrypt trên đúng khoá đó thì thao tác bị từ chối, dù người đó có toàn quyền trên bucket.

Đây chính là "lớp thứ hai" mà đề đòi hỏi: quyền truy cập S3 và quyền dùng khoá là hai cửa riêng, phải qua cả hai. Key policy cho phép liệt kê chính xác IAM user/role nào được kms:Decrypt, nên chính sách được thực thi chặt chẽ chứ không phụ thuộc thiện chí cấu hình ở tầng bucket.

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

A — SSE-C, quản lý khoá bên ngoài AWS. Đây là phương án gần đúng nhất và dễ mắc bẫy: nó đúng ở chỗ không có khoá thì không đọc được nội dung. Nhưng nó hỏng ở chỗ AWS không thực thi chính sách nào cả. Với SSE-C, người gọi phải tự đính kèm khoá trong mỗi request; việc "ai được có khoá" nằm hoàn toàn ngoài AWS, không kiểm toán được, không thu hồi tập trung được, không diễn đạt được bằng policy. Đề yêu cầu "security controls in place enforce this policy strictly" — tức là hệ thống phải cưỡng chế, chứ không phải trông vào kỷ luật phân phát khoá của con người.

C — IAM policy giới hạn tải về theo role, mã hoá bằng SSE-S3. Hỏng đúng ở cụm từ khoá của đề. IAM policy chặn được hành vi download, nhưng SSE-S3 không cho bạn kiểm soát quyền dùng khoá — khoá do S3 quản lý và việc giải mã diễn ra tự động, trong suốt, với bất kỳ ai đã đọc được object. Nghĩa là toàn bộ trọng lượng bảo vệ dồn hết vào một lớp duy nhất là IAM; đúng cái kịch bản "người khác đã có quyền bucket" mà đề dựng ra để loại phương án này.

D — SSE-S3 kèm bucket policy. Cùng một lỗi với C, chỉ đổi bucket policy thay cho IAM policy — vẫn là kiểm soát ở tầng S3, không có tầng khoá. SSE-S3 bảo vệ dữ liệu lúc nằm yên trên đĩa (chống việc đọc trực tiếp hạ tầng lưu trữ), chứ không phân biệt được người dùng nào trong tài khoản được giải mã. Đọc được object là có nội dung rõ.

📌 Điểm cần nhớ

• SSE-S3 và SSE-KMS khác nhau ở chỗ ai kiểm soát khoá. SSE-S3 mã hoá nhưng không cho bạn viết chính sách trên khoá; SSE-KMS cho phép, và đó là toàn bộ lý do KMS tồn tại trong các câu hỏi kiểu này.
• SSE-KMS tạo ra "quyền kép": phải qua cả quyền S3 lẫn kms:Decrypt trên đúng khoá. Đề nào có cụm "even if they have bucket access", "additional layer of control", hay "restrict who can decrypt" thì gần như chắc chắn đáp án là KMS với key policy.
• SSE-C đẩy trách nhiệm khoá ra ngoài AWS, nên nó không bao giờ là câu trả lời cho yêu cầu "AWS thực thi chính sách"; nó chỉ hợp khi đề nhấn mạnh công ty bắt buộc phải tự giữ khoá ngoài AWS.
• Đọc kỹ động từ trong đề: download và decrypt là hai quyền khác nhau. Phương án nào chỉ giải quyết vế đầu là phương án chưa trả lời hết câu hỏi.

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

Đề mô tả một công ty lưu tài liệu quan trọng trong S3 bucket và muốn theo dõi mọi hoạt động ghi vào bucket đó phục vụ phân tích bảo mật, với yêu cầu mỗi lần dữ liệu được thêm hoặc sửa đều phải được ghi lại vào một S3 bucket khác trong cùng Region.

Cụm từ quyết định là "track all write activities … for security analysis" kết hợp với "every instance of data being added or modified … is recorded". Hai vế này chốt hai điều:

• Cần bản ghi audit ở mức thao tác trên dữ liệu (object-level) — ai gọi, gọi lúc nào, gọi API gì, tham số ra sao — chứ không phải một thông báo sự kiện hay ảnh chụp cấu hình.
• Cần lưu lại (record), tức là log bền vững đổ vào bucket khác, chứ không phải cảnh báo tức thời rồi thôi.

Chính chữ "recorded" loại các phương án chỉ thông báo, và chữ "data being added or modified" loại các phương án chỉ theo dõi cấu hình thay vì dữ liệu.

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

D. Enable AWS CloudTrail with data event logging là đáp án đúng.

CloudTrail là dịch vụ audit API calls của AWS. Mặc định nó ghi management events (thao tác trên chính bucket: tạo bucket, đổi policy…). Muốn nhìn thấy thao tác trên object bên trong bucket — PutObject, DeleteObject, CopyObject… — phải bật thêm data events cho S3, đúng như tên phương án ghi rõ.

Khi bật data event logging, mọi thao tác ghi vào bucket đều sinh ra một bản ghi CloudTrail chứa danh tính người gọi (IAM principal), thời điểm gọi, tham số request và nội dung phản hồi. Đây chính là mức chi tiết mà "phân tích bảo mật" và audit tuân thủ cần. Trail của CloudTrail được cấu hình để đổ log vào một S3 bucket đích do ta chỉ định, nên yêu cầu "ghi vào một bucket riêng trong cùng Region" được thoả tự nhiên bằng chính cấu hình của trail.

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

A. Enable S3 Server Access Logging — đây là phương án gần đúng nhất, và nó thực sự có ghi log request vào một bucket đích. Nhưng bản chất của nó là log truy cập theo kiểu web-server: requester, tên bucket, thời điểm, kiểu request, mã trạng thái. Nó thiên về quan sát mẫu truy cập hơn là audit. So với CloudTrail data events, nó không cung cấp mức chi tiết API call (danh tính IAM đầy đủ, tham số request, response elements) mà phân tích bảo mật cần, nên với đề bài nhấn mạnh "security analysis" thì CloudTrail mới là lựa chọn chuẩn.

B. Configure AWS Config for S3 bucket monitoring — AWS Config theo dõi cấu hình tài nguyên và lịch sử thay đổi cấu hình: bucket policy đổi chưa, public access block bật hay tắt, encryption đặt thế nào. Nó trả lời "cấu hình bucket có bị đổi không", chứ không ghi lại thao tác ghi dữ liệu vào từng object. Đề hỏi về data being added or modified, không hỏi về cấu hình — sai đối tượng theo dõi.

C. Configure S3 Event Notifications — cơ chế này đúng là kích hoạt khi có object được tạo hoặc xoá, nên nghe rất khớp với "added or modified". Chỗ hỏng nằm ở mục đích: nó là kênh thông báo thời gian thực để đẩy sự kiện sang Lambda, SQS, SNS nhằm xử lý tiếp, chứ không phải cơ chế lưu trữ log audit. Bản thân nó không tự sinh ra một kho log chi tiết trong bucket khác, và nội dung sự kiện cũng nghèo hơn nhiều so với bản ghi CloudTrail (không có bức tranh đầy đủ về danh tính người gọi và tham số API). Muốn có log lưu lại thì còn phải tự dựng thêm phần tiêu thụ sự kiện và tự ghi — trong khi đề chỉ hỏi hành động nào nên làm.

📌 Điểm cần nhớ

• CloudTrail = audit API calls. Data events = thao tác ở mức object. Thấy đề hỏi "ai đã ghi/xoá object nào, lúc nào" cho mục đích bảo mật hoặc compliance → nghĩ ngay tới CloudTrail data events, vì management events mặc định không thấy được object-level.
• AWS Config theo dõi cấu hình, không theo dõi dữ liệu. Đề nói "configuration changed" thì chọn Config; đề nói "data added/modified" thì đừng chọn.
• S3 Event Notifications là để kích hoạt xử lý, không phải để lưu log. Từ khoá phân biệt: "notify / trigger / real-time" → Event Notifications; "record / log / audit trail" → CloudTrail.
• S3 Server Access Logging và CloudTrail dễ nhầm nhất. Cả hai đều ghi ra bucket khác, nhưng Server Access Logging thiên về access pattern ở mức request, còn CloudTrail cho chi tiết API call phục vụ audit — đề nhấn "security analysis" hoặc "compliance auditing" thì nghiêng về CloudTrail.

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

Đề mô tả một công ty lưu large volumes of data in Amazon S3 với access patterns that vary unpredictably — mẫu truy cập thay đổi không đoán trước được. Yêu cầu: một storage class rẻ mà automatically adjusts pricing based on data retrieval frequency without manual intervention.

Cụm từ quyết định nằm ở hai chỗ, và phải đọc cả hai cùng lúc:

• "vary unpredictably" — công ty không biết dữ liệu nào sẽ nóng, dữ liệu nào sẽ nguội. Mọi phương án bắt bạn phải chọn sẵn một tier cố định đều trượt ngay từ đây.
• "without manual intervention" — không được dựa vào việc người vận hành ngồi phân loại, cũng không được dựa vào việc tự tay chuyển dữ liệu qua lại giữa các tier khi thói quen truy cập đổi.

Câu hỏi này không hỏi "tier nào rẻ nhất", mà hỏi "tier nào tự đi tìm mức giá đúng khi bạn không biết trước". Chỉ có một storage class trong danh sách được thiết kế đúng cho ý đó.

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

A — S3 Intelligent-Tiering. Đây là storage class được thiết kế riêng cho dữ liệu có access pattern không biết trước hoặc thay đổi theo thời gian. S3 theo dõi tần suất truy cập của từng object và tự chuyển object đó sang access tier hợp lý — object bị bỏ quên lâu ngày rơi xuống tier rẻ hơn, object được đọc lại thì quay lên tier truy cập nhanh. Toàn bộ việc chuyển tier do S3 làm, không cần người vận hành can thiệp và không cần viết lifecycle rule phân loại thủ công.

Điểm khớp thẳng với đề: chi phí lưu trữ tự điều chỉnh theo tần suất truy cập thực tế, đúng cụm "automatically adjusts pricing based on data retrieval frequency", và làm được điều đó without manual intervention. Đây cũng là lý do Intelligent-Tiering luôn là câu trả lời mặc định khi đề bài nói "unknown / changing / unpredictable access patterns".

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

B — S3 One Zone-Infrequent Access. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. One Zone-IA thật sự rẻ hơn Standard cho dữ liệu ít truy cập, nên nếu chỉ đọc chữ "cost-effective" thì nó có vẻ hợp lý. Nó hỏng ở hai chỗ: (1) đây là một tier cố định — bạn tự khẳng định dữ liệu là "infrequently accessed" và ghim nó ở đó; khi access pattern đổi, không có cơ chế nào tự đưa nó về tier khác, tức là vi phạm đúng yêu cầu "automatically adjusts... without manual intervention"; (2) như tên gọi, dữ liệu chỉ nằm trong một Availability Zone, nên độ bền trước sự cố mất cả một AZ thấp hơn các class lưu đa AZ — một đánh đổi mà đề không hề yêu cầu.

C — S3 Glacier. Glacier là lớp dành cho long-term archival, nơi dữ liệu gần như không được đọc tới. Thời gian lấy dữ liệu ra không tức thời như S3 Standard mà phải qua một quá trình retrieval có độ trễ đáng kể tuỳ mức lấy. Đề nói access pattern thay đổi thất thường — nghĩa là hoàn toàn có lúc dữ liệu được đọc nhiều; đẩy nó vào archive là biến một yêu cầu đọc bình thường thành một chu trình chờ. Ngoài ra Glacier cũng là tier cố định, tự nó không phản ứng theo tần suất truy cập.

D — S3 Standard. Standard tối ưu cho dữ liệu truy cập thường xuyên, giá lưu trữ trên mỗi GB cao nhất trong nhóm nhưng không tính phí truy xuất theo kiểu các tier IA. Nếu phần lớn dữ liệu nằm im, công ty đang trả giá của dữ liệu nóng cho dữ liệu nguội — đúng thứ đề đang muốn tránh. Standard cũng chỉ có một mức giá duy nhất, không hề "adjust" theo tần suất truy cập. Cụm "consistent high availability" trong phương án là mồi nhử: đề không đặt vấn đề về availability, mà đặt vấn đề về chi phí biến thiên.

📌 Điểm cần nhớ

• "Unknown / changing / unpredictable access patterns" là chữ ký của S3 Intelligent-Tiering. Thấy cụm này trong đề thì gần như chắc chắn đó là đáp án, kể cả khi các tier IA/Glacier cũng được liệt kê.
• Phân biệt "rẻ" với "tự điều chỉnh". One Zone-IA, Standard-IA và Glacier đều rẻ hơn Standard cho dữ liệu nguội, nhưng chúng là các tier tĩnh — bạn phải tự quyết định và tự chuyển. Chỉ Intelligent-Tiering tự phản ứng theo hành vi truy cập.
• Đọc kỹ cụm "without manual intervention". Nó loại thẳng mọi giải pháp yêu cầu phân loại dữ liệu trước, kể cả khi phương án đó rẻ hơn về mặt đơn giá.
• One Zone trong tên storage class luôn kèm đánh đổi độ bền — dữ liệu nằm trong một AZ duy nhất. Đừng chọn nó khi đề không nói rõ dữ liệu có thể tái tạo được hoặc chấp nhận rủi ro mất một AZ.

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

Đề mô tả một ứng dụng cần relational database nhưng chỉ truy cập ngắt quãng (intermittent access), với lưu lượng lên xuống thất thường không đoán trước được (unpredictable peaks and valleys). Dữ liệu ứng dụng nằm sẵn trên Amazon S3, và yêu cầu là một giải pháp on-demand, tự co giãn theo tải, ít việc vận hành và tiết kiệm chi phí.

Bốn cụm từ trong đề quyết định đáp án, và phải thoả đồng thời:

1. "relational database" — loại thẳng mọi thứ không phải quan hệ.
2. "intermittent access" + "unpredictable peaks and valleys" — cần thứ tự khởi động, tự tắt và tự co giãn theo từng lúc, chứ không phải thứ chạy thường trực với một cấu hình cố định.
3. "minimize operational management and cost" — nghiêng hẳn về mô hình serverless: không trả tiền cho công suất nhàn rỗi, không phải tự chỉnh instance class.
4. "direct integration with Amazon S3" — dữ liệu đã ở S3, cần nạp/xuất thẳng chứ không qua đường vòng.

Câu này là kiểu "chọn đúng hạng dịch vụ", không phải kiểu hỏi chi tiết cấu hình. Chỉ có một phương án vừa là quan hệ, vừa là serverless, vừa nối thẳng được với S3.

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

A — Amazon Aurora Serverless với S3 integration.

Aurora Serverless là bản Aurora tự start up, shut down và scale công suất lên xuống theo nhu cầu ứng dụng, không cần người vận hành chọn sẵn kích cỡ instance. Đúng ba yêu cầu của đề:

• Relational: Aurora là engine quan hệ (tương thích MySQL/PostgreSQL) — không phải làm gì thêm để "giả lập" tính quan hệ.
• Ngắt quãng và thất thường: đây chính là hình thái tải mà Aurora Serverless được thiết kế để phục vụ. Lúc không có ai dùng thì công suất tụt xuống, lúc dồn tải thì tự nâng lên, nên không phải trả tiền cho công suất ngồi không giữa các đợt.
• Tích hợp S3: Aurora hỗ trợ import/export dữ liệu trực tiếp với Amazon S3, khớp đúng chữ "direct integration with Amazon S3" trong đề.

Cộng lại: overhead vận hành thấp nhất trong bốn phương án, và chi phí bám theo mức dùng thật.

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

B — DynamoDB + auto scaling, đẩy dữ liệu từ S3 bằng Lambda. Hỏng ngay ở chữ đầu tiên của yêu cầu: DynamoDB là NoSQL, không cung cấp các đặc tính quan hệ một cách tự nhiên. Muốn có hành vi "relational-like" thì phải dựng thêm một loạt cách làm vòng vo, đúng như phần đuôi của chính phương án đã thừa nhận ("for relational database-like operations"). Nó co giãn tốt thật, nhưng đề không hỏi "cái gì co giãn tốt" mà hỏi "relational database nào co giãn tốt". Thêm Lambda để nhồi dữ liệu vào chỉ làm kiến trúc phức tạp thêm chứ không biến NoSQL thành quan hệ.

C — Amazon RDS với scaling policy. Đây là phương án gần đúng nhất, vì RDS đúng là quan hệ và đúng là có khả năng scale. Chỗ hỏng nằm ở kiểu scale: RDS không tự điều chỉnh compute theo thời gian thực bám sát mức hoạt động như mô hình serverless. Với tải lên xuống thất thường, kết quả là hoặc under-provision lúc cao điểm (chậm, nghẽn), hoặc over-provision lúc rảnh (trả tiền cho tài nguyên không ai dùng). Cả hai đều đi ngược vế "tự động co giãn khớp workload" và "tối thiểu chi phí" của đề. Thêm nữa, đây là lựa chọn tốn công vận hành hơn: phải tự nghĩ ra chính sách scale thay vì để dịch vụ lo.

D — Amazon Redshift với auto pause/resume. Redshift nay có thể tự tạm dừng và chạy lại theo mức hoạt động, nên nhìn qua thì hợp vế "on-demand, tiết kiệm chi phí". Nhưng nó sai mục đích sử dụng: Redshift là data warehouse, tối ưu cho truy vấn phân tích phức tạp trên tập dữ liệu lớn, không phải cơ sở dữ liệu vận hành (operational) phục vụ ứng dụng. Đề nói rõ đây là "a new application requires access to a relational database" — tức là tải giao dịch của ứng dụng, không phải tải phân tích. Chọn D là lấy công cụ phân tích đi làm việc của database ứng dụng.

📌 Điểm cần nhớ

• Gặp cụm "unpredictable" / "intermittent" / "peaks and valleys" đi kèm "relational" và "minimize cost & operational management" → phản xạ đầu tiên là Aurora Serverless. Đây gần như là chữ ký của dịch vụ này trong đề thi.
• Phân biệt rõ RDS scaling và serverless scaling: RDS quan hệ và co giãn được, nhưng không bám tải theo thời gian thực nên vẫn để lại khoảng thừa/thiếu công suất. Tải càng thất thường thì khoảng cách này càng lớn.
• Redshift = analytics/data warehouse, không phải database vận hành cho ứng dụng — dù nó có auto pause/resume. Đọc kỹ tải là transactional hay analytical trước khi chọn.
• Phương án nào tự mô tả mình bằng những chữ như "-like operations" hay cần ghép thêm Lambda/glue code để mô phỏng một tính năng mà đề đòi hỏi trực tiếp, thường là phương án sai: đề đang tìm dịch vụ vốn đã có tính chất đó.

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

Một tổ chức y tế lưu hồ sơ bệnh nhân của nhiều vùng trong một S3 bucket duy nhất, dùng cho phân tích sức khoẻ theo vùng. Yêu cầu: mỗi analyst chỉ được xem hồ sơ bệnh nhân thuộc vùng của mình, để tuân thủ quy định riêng tư địa phương.

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

• "minimum amount of operational effort" — đây là bài toán so sánh công sức vận hành, không phải bài toán "cái nào làm được". Nhiều phương án đều chặn được truy cập; cái thắng là cái tốn ít công duy trì nhất về lâu dài.
• "can only access patient records from their specific region" — kiểm soát ở mức bản ghi/hàng dữ liệu, không phải mức tệp hay mức bucket. Hồ sơ của nhiều vùng đang nằm chung một chỗ, nên thứ cần là fine-grained access control chứ không phải phân quyền theo đường dẫn.

Ghép hai ràng buộc lại: cần một lớp quản trị quyền tập trung, hiểu được dữ liệu ở mức cột/hàng, đặt lên trên chính S3 bucket đang có — mà không phải dời dữ liệu đi đâu.

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

D — AWS Lake Formation, đăng ký S3 bucket làm data lake, dùng fine-grained access control.

Lake Formation sinh ra đúng cho việc này: nó là lớp quản trị quyền cho data lake nằm trên S3. Ta register bucket sẵn có làm vị trí data lake, mô tả dữ liệu bằng Data Catalog, rồi cấp quyền theo cách khai báo — bao gồm cả row-level security, tức là lọc theo giá trị của một cột như region. Analyst vùng nào chỉ nhìn thấy hàng của vùng đó, dù dữ liệu vật lý vẫn nằm chung.

Về "operational effort": dữ liệu không phải di chuyển, không phải sắp xếp lại, không phải nạp vào hệ thống khác. Thêm một vùng mới hay một nhóm analyst mới chỉ là thêm một permission/filter trong Lake Formation, chứ không phải viết lại policy JSON hay dựng thêm hạ tầng. Quyền được quản lý ở một chỗ và áp dụng nhất quán cho các dịch vụ phân tích tích hợp với Lake Formation.

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

A — Rải dữ liệu ra nhiều AWS Region theo vị trí bệnh nhân, rồi dùng IAM policy cấp quyền theo vùng địa lý. Phương án này nhầm lẫn "region của bệnh nhân" với "AWS Region". Nó bắt tổ chức phải di chuyển và tái tổ chức toàn bộ dữ liệu sang nhiều Region, dựng bucket ở từng nơi, rồi duy trì việc định tuyến dữ liệu mới về đúng chỗ — đó là mức công sức vận hành cao nhất trong bốn phương án. Chưa kể việc dời dữ liệu y tế qua biên giới có thể tự nó vi phạm yêu cầu data residency mà đề đang muốn tuân thủ. Phân tích liên vùng cũng khó hơn hẳn khi dữ liệu bị xé lẻ.

B — Tách hồ sơ thành các S3 prefix theo vùng, dùng IAM/bucket policy chặn theo prefix. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Nó có chặn được truy cập, nhưng:

• Phải sắp xếp lại toàn bộ layout dữ liệu theo prefix, và duy trì kỷ luật đó với mọi dữ liệu ghi vào sau này — chỉ một tệp đặt sai prefix là rò rỉ.
• Quyền chỉ ở mức đường dẫn đối tượng, không phải mức bản ghi. Một tệp chứa hồ sơ của nhiều vùng thì cách này bó tay.
• Số vùng và số analyst tăng lên thì bộ policy phình ra, khó đọc, khó kiểm toán — trái hẳn với "minimum operational effort".

C — Nạp dữ liệu vào Amazon Aurora, tạo schema theo vùng, dùng IAM policy cấp quyền theo schema. Phương án này đổi luôn kiến trúc: từ phân tích trên data lake sang cơ sở dữ liệu quan hệ. Phải xây và vận hành pipeline nạp dữ liệu, thiết kế schema cho từng vùng, đồng bộ liên tục với S3, và quản lý một cụm database — công sức vận hành lớn hơn hẳn. Ngoài ra quyền trong Aurora chủ yếu là quyền database, còn IAM chỉ lo phần xác thực kết nối, nên mô hình "IAM policy cấp quyền tới schema" như đề mô tả cũng không phải cách phân quyền tự nhiên ở đây. Cuối cùng, Aurora là database giao dịch, không phải nơi hợp lý để chứa khối dữ liệu phân tích vốn đã nằm sẵn trên S3.

📌 Điểm cần nhớ

• Đề nhắc "minimum operational effort" kèm dữ liệu đã nằm trên S3 → nghiêng về giải pháp phủ lên chỗ dữ liệu đang có, tránh mọi phương án đòi di chuyển, sao chép hoặc nạp lại dữ liệu.
• Cần chặn ở mức hàng/cột (row/column-level) trên data lake → Lake Formation. Cần chặn ở mức tệp/đường dẫn → IAM và bucket policy là đủ. Đọc kỹ đề hỏi mức nào.
• Phương án "tách prefix + IAM policy" luôn trông hợp lý, nhưng nó chỉ phân quyền theo đường dẫn và bắt bạn tự duy trì cách sắp xếp dữ liệu — không mở rộng tốt khi số vùng, số nhóm người dùng tăng.
• Trong đề thi AWS, "region" của người dùng hoặc của bệnh nhân không đồng nghĩa với AWS Region; phương án gợi ý rải dữ liệu ra nhiều AWS Region để giải bài toán phân quyền gần như luôn là bẫy.