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

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

Một công ty logistics gắn thiết bị IoT lên đội xe để theo dõi vị trí. Dữ liệu vị trí nằm trong một instance Amazon RDS. Cuối mỗi ngày, công ty muốn ghi vị trí cuối cùng đã biết của từng xe sang một bảng Amazon DynamoDB để truy cập nhanh. Hàm AWS Lambda làm việc chuyển dữ liệu đó thì đã viết xong rồi.

Câu hỏi vì thế không hỏi cách xử lý dữ liệu, mà hỏi đúng một việc: lấy gì để kích hoạt Lambda?

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

• "at the end of each day" / "daily transfer" — đây là công việc chạy theo lịch định kỳ, tức là kích hoạt theo thời gian, không phải theo sự kiện dữ liệu.
• "stored in an Amazon RDS instance" — nguồn dữ liệu là RDS, nên mọi cơ chế kích hoạt gắn với một kho dữ liệu khác đều lạc đề ngay từ tiền đề.

Ai bám vào hai cụm này thì loại được ba phương án còn lại mà không cần suy nghĩ nhiều.

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

C — Trigger Lambda bằng Amazon EventBridge với một scheduled rule đặt vào cuối mỗi ngày.

EventBridge cho phép tạo rule chạy theo lịch (biểu thức rate hoặc cron) và đặt Lambda function làm target. Đặt rule chạy vào cuối ngày là đủ để Lambda tự động thực thi mỗi ngày, đọc RDS rồi ghi sang DynamoDB.

Đây đúng là hình mẫu chuẩn cho loại công việc chạy đều đặn theo chu kỳ: cấu hình một lần, sau đó không cần can thiệp thủ công. Nó cũng khớp trực tiếp với yêu cầu "cuối mỗi ngày" — thứ mà một scheduled rule diễn đạt được nguyên văn, còn kích hoạt theo sự kiện thì không.

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

A — Step Functions state machine gọi Lambda để phản hồi CloudTrail logs báo hiệu "data entry completion".

CloudTrail dùng để ghi nhật ký và giám sát hoạt động trên tài khoản AWS (ai gọi API nào, lúc nào), chứ không phải để báo hiệu một tác vụ nghiệp vụ như "dữ liệu trong ngày đã nhập xong". Không có sự kiện CloudTrail nào tương ứng với khái niệm "kết thúc ngày" ở đây. Ngoài ra, thêm Step Functions vào giữa cho một lời gọi Lambda đơn lẻ là phức tạp hóa không cần thiết so với yêu cầu chỉ là chuyển dữ liệu một lần mỗi ngày.

B — S3 event notifications kích hoạt Lambda khi có dữ liệu vị trí mới upload lên S3 bucket.

Sai ngay ở tiền đề: đề nói rõ dữ liệu nằm trong RDS, không nằm trong S3. S3 event notifications chỉ phản ứng với thay đổi bên trong S3 (tạo object, xóa object…), nó không nhìn thấy gì xảy ra trong RDS. Phương án này chỉ hoạt động nếu ta bịa thêm một luồng đưa dữ liệu vào S3 — thứ không hề có trong đề. Và kể cả có, kích hoạt sẽ theo mỗi lần upload, không phải theo cuối ngày.

D — Cấu hình RDS trực tiếp gọi Lambda khi phát hiện dữ liệu cuối ngày được nhập.

Đây là phương án gần đúng nhất về mặt trực giác — "dữ liệu ở RDS thì để RDS tự báo" nghe rất hợp lý — nhưng nó hỏng ở chỗ: RDS không có tính năng gốc kiểu "phát hiện data entry rồi tự gọi Lambda". Việc tích hợp RDS với Lambda cần một dịch vụ trung gian đứng ra kích hoạt. Quan trọng hơn, ngay cả khi có cơ chế đó, nó vẫn phản ứng theo thao tác ghi dữ liệu, trong khi đề đòi một mốc thời gian cố định cuối ngày. Hai thứ này khác nhau: dữ liệu có thể ngừng đến sớm, đến muộn, hoặc không đến ngày nào đó — mà công việc cuối ngày vẫn phải chạy.

📌 Điểm cần nhớ

• "Mỗi ngày / mỗi giờ / định kỳ" ⇒ nghĩ ngay tới scheduled rule của EventBridge. Kích hoạt theo thời gian thì tìm bộ lập lịch, đừng đi tìm sự kiện dữ liệu để suy ra thời gian.
• Kiểm tra tiền đề trước khi đánh giá kỹ thuật. Phương án nào dựa vào một kho dữ liệu hoặc dịch vụ không xuất hiện trong đề (S3, trong khi đề nói RDS) thì loại được ngay, khỏi cần cân nhắc chi tiết.
• CloudTrail là công cụ audit, không phải bus kích hoạt nghiệp vụ. Thấy CloudTrail đứng ở vai trò "phát hiện việc đã xong" thì gần như chắc chắn là bẫy.
• Đơn giản nhất mà đáp ứng đủ yêu cầu là thắng. Kéo thêm Step Functions hay một chuỗi trung gian vào một tác vụ chạy một lần mỗi ngày là dấu hiệu của phương án sai trong đề thi AWS.

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

Đề mô tả một tình huống migration kinh điển: chuyển vài terabyte dữ liệu từ Oracle on-premises sang Amazon Aurora. Có ba ràng buộc được nêu rõ trong đề, và chính chúng quyết định đáp án:

• "minimize downtime" — không được tắt hệ thống nguồn hàng giờ để copy dữ liệu.
• "ensure data consistency" — dữ liệu ở đích phải khớp nguồn, không mất, không lệch.
• Cụm từ quyết định: "After the initial migration, the team also needs to keep the Aurora database synchronized with the on-premises database for a transitional period".

Cụm cuối cùng là mấu chốt. Nó nói rằng bài toán có hai pha: (1) chuyển khối dữ liệu ban đầu, và (2) liên tục đồng bộ thay đổi phát sinh trong lúc hệ thống cũ vẫn đang chạy. Bất kỳ phương án nào chỉ giải quyết được một pha, hoặc chỉ đồng bộ theo lịch thay vì liên tục, đều trượt.

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

Đáp án A — AWS Database Migration Service (AWS DMS).

DMS là dịch vụ được xây dựng đúng cho bài toán này: di chuyển cơ sở dữ liệu với thời gian ngừng hoạt động tối thiểu. Nó hỗ trợ Oracle làm nguồn và Amazon Aurora làm đích, đúng cặp mà đề nêu.

Điểm khiến DMS khớp trọn vẹn hai pha của đề: DMS vừa làm full load (chuyển toàn bộ dữ liệu hiện có), vừa có ongoing replication — đọc thay đổi phát sinh ở nguồn và áp sang đích một cách liên tục. Nhờ vậy database nguồn vẫn phục vụ ứng dụng bình thường trong suốt quá trình migration, và Aurora bám sát nguồn trong "transitional period" mà đề yêu cầu. Đến lúc cutover, chỉ cần một khoảng ngừng rất ngắn để chuyển ứng dụng sang Aurora.

Đây cũng là phương án duy nhất không đòi viết code tùy biến: migration và replication đều là chức năng có sẵn, được cấu hình chứ không phải tự dựng.

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

B — Amazon Kinesis Data Firehose để stream liên tục từ Oracle sang Aurora. Firehose là dịch vụ nhận luồng dữ liệu (streaming ingestion) và giao vào các đích lưu trữ/phân tích của AWS. Nó không phải công cụ migration database: nó không tự đọc được một Oracle database on-premises, không làm được pha full load một cách nhất quán, và không có cơ chế bảo đảm nguồn – đích khớp nhau như một công cụ replication. Nghe "continuous" thì hợp với vế đồng bộ, nhưng hỏng ngay ở vế đầu tiên là chuyển khối dữ liệu ban đầu.

C — AWS Data Pipeline, đặt lịch cập nhật incremental. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Data Pipeline đúng là dịch vụ tự động hoá và lập lịch việc di chuyển dữ liệu, nên thoạt nhìn có vẻ đáp ứng được cả hai pha. Nó hỏng ở hai chỗ:

• Nó là công cụ cho luồng xử lý dữ liệu (data processing workflow), không phải cho migration database phức tạp — không hiểu cơ chế thay đổi ở tầng database như một công cụ replication chuyên dụng.
• Chữ "set up a schedule" tự nó phản lại đề. Đồng bộ theo lịch nghĩa là giữa hai lần chạy luôn có độ trễ và dữ liệu lệch; đề đòi keep synchronized liên tục để downtime tối thiểu. Đó là hai thứ khác nhau.

D — S3 Transfer Acceleration cho pha đầu, rồi Lambda xử lý thay đổi. Hỏng cả hai vế. S3 Transfer Acceleration chỉ tăng tốc việc upload dữ liệu lên S3, nó hoàn toàn không phải công cụ migration database — đích của nó là S3 chứ không phải Aurora, và nó không biết gì về schema hay tính nhất quán của dữ liệu quan hệ. Vế sau dùng Lambda để replication có nghĩa là tự viết toàn bộ logic bắt thay đổi, xử lý thứ tự, xử lý lỗi và retry — công sức phát triển lớn mà độ tin cậy vẫn thua một dịch vụ có sẵn. Đây là phương án ghép hai dịch vụ không liên quan để trông giống một giải pháp hai pha.

📌 Điểm cần nhớ

• Đề nào có đủ bộ ba "minimize downtime" + "migrate database" + "continuous replication / keep synchronized" thì gần như chắc chắn đáp án là AWS DMS. Đây là chữ ký nhận dạng của DMS trong đề thi.
• Phân biệt rõ "scheduled / incremental" với "continuous replication". Đồng bộ theo lịch luôn có cửa sổ lệch dữ liệu, nên không thoả yêu cầu downtime tối thiểu — dùng chính chữ này để loại phương án Data Pipeline.
• Kinesis Data Firehose là ingestion cho dữ liệu dạng luồng, không phải công cụ migration database; đừng chọn nó chỉ vì đề có chữ "continuous".
• S3 Transfer Acceleration chỉ liên quan tới tốc độ đưa dữ liệu vào S3. Nếu đích trong đề là một database chứ không phải S3, phương án chứa nó gần như luôn sai.
• Khi một phương án đòi tự viết code (Lambda) để làm việc mà AWS đã có dịch vụ quản lý sẵn, đó thường là phương án sai trong các câu hỏi ưu tiên hiệu quả và độ tin cậy.

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

Đề mô tả một ETL pipeline chạy trên AWS Lambda, cần kết nối tới database trên Amazon RDS, và hỏi nên dùng dịch vụ nào để lưu trữ và lấy về (store and retrieve) thông tin đăng nhập database một cách an toàn.

Cụm từ quyết định là "manage the database credentials securely" — đề không hỏi "cấp quyền cho Lambda gọi dịch vụ AWS nào", cũng không hỏi "lưu file cấu hình ở đâu", mà hỏi nơi cất giữ chính chuỗi username/password của database. Chi tiết thứ hai đáng chú ý là đối tượng cần bảo vệ là credentials của RDS — đây là loại bí mật gắn liền với một database engine cụ thể, thứ mà AWS có dịch vụ chuyên trách kèm khả năng rotation tự động phối hợp trực tiếp với RDS.

Hai manh mối đó tách được bốn phương án thành: một dịch vụ chuyên cho secret (C), một dịch vụ cấu hình đa dụng có kèm khả năng lưu secret (B), một kho lưu trữ object thuần (A), và một dịch vụ quản lý quyền truy cập chứ không lưu dữ liệu (D).

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

C — AWS Secrets Manager là dịch vụ được thiết kế đúng cho mục đích này: lưu trữ và quản lý những thông tin nhạy cảm như database credentials. Đội data engineering cất cặp username/password của RDS trong Secrets Manager, và Lambda function khi cần kết nối thì gọi lấy secret ra lúc chạy thay vì nhúng cứng trong mã nguồn hay biến môi trường.

Điểm mạnh riêng của Secrets Manager mà lời giải nguồn nhấn mạnh là rotation tự động: nó có sẵn cơ chế xoay vòng credentials, đặc biệt là tích hợp cho database. Nhờ vậy mật khẩu được đổi định kỳ mà không phải sửa code hay redeploy Lambda. Cộng thêm việc credentials được quản lý tập trung, tách hẳn khỏi mã nguồn, đây là lựa chọn phù hợp nhất cho ETL pipeline trong đề.

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

A — Amazon S3. S3 là object storage an toàn và có khả năng mở rộng tốt, nhưng nó không phải nơi dành cho dữ liệu cấu hình nhạy cảm kiểu database credentials. Cất mật khẩu vào một object trong S3 không mang lại các thực hành bảo mật và tính năng chuyên biệt mà Secrets Manager cung cấp — trong đó có credential rotation. Đây là phương án sai rõ nhất trong bốn phương án.

B — AWS Systems Manager Parameter Store. Đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. Parameter Store có lưu được cấu hình theo dạng phân cấp và có kiểu tham số bảo mật, nên về nguyên tắc vẫn dùng để cất credentials theo cách tương tự Secrets Manager được. Nhưng nó không có những tính năng nâng cao của Secrets Manager, cụ thể là rotation tự động của secret. Với một pipeline mà đề nhấn mạnh "manage credentials securely", thiếu vòng đời xoay mật khẩu là điểm trừ quyết định. Khi đề bài đặt Parameter Store cạnh Secrets Manager và đối tượng cần bảo vệ là database credentials, đáp án luôn nghiêng về Secrets Manager.

D — AWS IAM. IAM quản lý quyền truy cập vào dịch vụ và tài nguyên AWS: định nghĩa role, policy, ai được làm gì. Nó không phải cơ chế lưu trữ hay lấy về database credentials. IAM vẫn có vai trò phụ trong kiến trúc này — Lambda cần một execution role được phép đọc secret — nhưng bản thân IAM không cất chuỗi mật khẩu, nên nó không trả lời được câu hỏi "lưu ở đâu".

📌 Điểm cần nhớ

• Đề nhắc tới database credentials + yêu cầu quản lý an toàn → nghĩ ngay tới AWS Secrets Manager; đó là dịch vụ chuyên trách cho secret chứ không phải cho cấu hình chung.
• Phân biệt Secrets Manager và Parameter Store bằng rotation tự động: cả hai lưu được giá trị bảo mật, nhưng chỉ Secrets Manager có sẵn cơ chế xoay vòng credentials, nhất là với database.
• IAM là "ai được phép làm gì", không phải "cất cái gì ở đâu". Trong kiến trúc Lambda + secret, IAM đóng vai trò cấp quyền đọc, không phải nơi lưu credentials.
• S3 là object storage, không phải secret store. Bất kỳ phương án nào đề xuất cất mật khẩu dưới dạng file/object đều là dấu hiệu đáp án sai trong domain bảo mật.
• Nguyên tắc chung của Domain "Data Security and Governance": credentials phải nằm ngoài mã nguồn, được lấy về lúc runtime và quản lý tập trung.

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

Đề mô tả một nhóm data engineer cần điều phối (orchestrate) các luồng ETL phức tạp trải qua nhiều dịch vụ: Amazon EMR, Amazon Redshift và AWS Glue. Câu hỏi là chọn dịch vụ điều phối phù hợp.

Cụm từ quyết định nằm ở phần yêu cầu: "complex ETL workflows", "customizable scheduling", "dependencies management" và "scalable and managed solution". Ghép lại, đề đang mô tả gần như nguyên văn định nghĩa của một data pipeline orchestrator kiểu Apache Airflow: DAG có phụ thuộc giữa các task, lịch chạy tuỳ biến, và bảng theo dõi tình trạng từng lần chạy. Chữ managed loại luôn phương án "tự dựng lấy", còn chữ complex ETL + dependencies là thứ tách MWAA khỏi các dịch vụ điều phối chung chung khác trong danh sách.

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

C — Amazon Managed Workflows for Apache Airflow (MWAA).

MWAA là bản Apache Airflow do AWS vận hành hộ: người dùng chỉ viết DAG bằng Python, còn phần dựng scheduler, worker, web server và mở rộng quy mô thì AWS lo. Đúng ba thứ đề yêu cầu đều là thứ Airflow sinh ra để làm:

• Dependency management — DAG chính là đồ thị phụ thuộc; "chạy Glue job xong mới bung EMR cluster, xong mới COPY vào Redshift" diễn đạt trực tiếp bằng cấu trúc DAG.
• Customizable scheduling — lịch theo cron tuỳ ý, kèm backfill và catch-up cho các lần chạy bị lỡ.
• Monitoring — giao diện Airflow có sẵn cây DAG, log từng task, lịch sử các lần chạy, và cơ chế retry theo từng task.

Quan trọng nữa: Airflow có sẵn bộ operator cho chính những dịch vụ đề nêu (EMR, Redshift, Glue), nên việc nối ba dịch vụ này lại là chuyện cấu hình chứ không phải viết tích hợp từ đầu. Đây là lý do đề cố tình liệt kê đúng ba cái tên đó.

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

A — Amazon Data Pipeline. Đây là dịch vụ di chuyển và biến đổi dữ liệu giữa các dịch vụ compute/storage của AWS, nên nghe qua thì có vẻ đúng chủ đề. Chỗ nó hỏng là mức độ linh hoạt và khả năng mở rộng: định nghĩa pipeline theo khuôn mẫu cố định, khó biểu diễn logic rẽ nhánh phức tạp, và phần theo dõi không chi tiết bằng giao diện Airflow. Đây cũng là dịch vụ thế hệ cũ, không còn là hướng AWS khuyến nghị cho pipeline dữ liệu mới.

B — AWS Step Functions. Đây là phương án gần đúng nhất và cần cân nhắc kỹ. Step Functions thật sự điều phối được nhiều dịch vụ AWS, có state machine biểu diễn được thứ tự và điều kiện, tích hợp trực tiếp với Glue và EMR. Nhưng thế mạnh của nó là điều phối các thành phần ứng dụng và microservice — chuỗi bước theo sự kiện, xử lý lỗi ở mức từng state. Với bài toán data pipeline cần lịch chạy tuỳ biến, backfill dữ liệu quá khứ và cái nhìn theo lần chạy hằng ngày, Airflow mới là công cụ được thiết kế đúng bài. Đề nhấn "complex ETL workflows" chứ không nhấn "application workflow", nên MWAA sát hơn.

D — AWS Lambda + Amazon EventBridge. Cặp này làm được lịch chạy (EventBridge phát sự kiện theo giờ) và tác vụ tự động hoá ngắn (Lambda gọi API khởi động job). Nhưng nó không phải là một orchestrator: không có nơi nào lưu đồ thị phụ thuộc, không có giao diện theo dõi trạng thái toàn pipeline, và mọi logic "chờ bước trước xong mới chạy bước sau" phải tự viết tay. Ngoài ra Lambda có giới hạn thời gian chạy nên không hợp để canh một EMR job kéo dài. Phù hợp cho automation đơn giản, không phù hợp cho ETL nhiều bước.

📌 Điểm cần nhớ

• Thấy đề nói "complex ETL workflows" + "scheduling" + "dependencies" + "managed" → nghĩ ngay tới MWAA (Apache Airflow). Đó là bộ từ khoá đặc trưng của dịch vụ này.
• Ranh giới MWAA và Step Functions: Step Functions cho application/microservice workflow và luồng theo sự kiện; MWAA cho data pipeline có DAG, lịch chạy và backfill. Cả hai đều "điều phối", chỉ khác đối tượng được điều phối.
• Lambda + EventBridge là scheduler + trigger, không phải orchestrator. Thiếu quản lý phụ thuộc và theo dõi tập trung, lại vướng giới hạn thời gian chạy của Lambda.
• Amazon Data Pipeline là dịch vụ đời cũ, chỉ nên chọn khi đề mô tả thao tác di chuyển dữ liệu đơn giản, cố định — không chọn khi đề nhấn tính linh hoạt, mở rộng hay theo dõi chi tiết.

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

Một viện nghiên cứu đang chuyển nền tảng phân tích dữ liệu tại chỗ lên AWS. Họ có hai thứ: các cụm Apache Hadoop (sẽ chạy trên Amazon EMR) và một Apache Hive metastore giữ toàn bộ data catalog. Câu hỏi là: đưa Hive metastore đó lên AWS bằng cách nào.

Cụm từ quyết định nằm ngay trong yêu cầu: "require a serverless, cost-effective solution to migrate and manage their existing data catalog". Hai chữ serverless và manage the data catalog loại bỏ mọi phương án còn phải nuôi một máy chủ hay một cụm để giữ metastore. Từ migrate cũng quan trọng: đề muốn chuyển catalog đang có sang một kho metadata mới, chứ không phải dựng lại nó từ đầu bằng cách quét dữ liệu.

Đây là dạng câu rất hay gặp: cả bốn phương án đều "chạy được" về mặt kỹ thuật, nên phải chấm theo ràng buộc vận hành chứ không phải theo tính khả thi.

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

Đáp án đúng là B — dùng AWS Glue Data Catalog để import Hive metastore hiện có, lấy nó làm kho metadata trung tâm, rồi tích hợp với Amazon EMR.

AWS Glue Data Catalog là một kho metadata serverless, được thiết kế để thay thế trực tiếp Apache Hive metastore. Nó tương thích với Hive metastore về mặt giao diện, nên Amazon EMR (Hive, Spark, Presto) có thể trỏ thẳng vào Glue Data Catalog làm metastore mà không cần đổi cách viết truy vấn.

Điểm khớp với đề bài:

• Serverless: không phải cấp phát, vá lỗi hay theo dõi bất kỳ instance nào chỉ để giữ metadata.
• Cost-effective: không có tài nguyên chạy thường trực chỉ để phục vụ metastore, nên phần chi phí vận hành và chi phí quản trị đều giảm.
• Catalog trung tâm: một kho metadata dùng chung cho nhiều cụm EMR và nhiều dịch vụ phân tích khác trong tài khoản, thay vì mỗi cụm một metastore riêng.
• Migrate: đây đúng là đường đi mà AWS khuyến nghị — nạp metadata từ Hive metastore hiện có vào Glue Data Catalog rồi cho EMR dùng nó.

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

A. Dùng Amazon Athena để dựng lại data catalog từ dữ liệu Hive metastore nằm trên Amazon S3. Đây là phương án hiểu sai vai trò của Athena. Athena là dịch vụ truy vấn tương tác serverless — bản thân nó không phải là kho metadata, và trên thực tế Athena lại dùng chính Glue Data Catalog làm catalog cho mình. Ngoài ra, đề yêu cầu migrate metastore đang có; "dựng lại catalog" nghĩa là vứt bỏ metadata đã tích luỹ rồi tự suy ra lại từ dữ liệu thô — công sức thừa và rất dễ mất thông tin (partition, thuộc tính bảng, quyền đã đặt).

C. Chuyển Hive metastore sang Amazon RDS bằng AWS DMS rồi nối RDS vào các cụm EMR. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. Hive metastore vốn chạy trên một CSDL quan hệ, nên đưa nó sang RDS là việc hoàn toàn khả thi, thậm chí là mô hình nhiều nơi đang dùng thật. Nhưng nó hỏng ở đúng chữ "serverless": RDS là một instance CSDL luôn bật, phải chọn cỡ máy, phải vá, phải sao lưu, phải theo dõi, và bị tính tiền kể cả khi không có cụm EMR nào chạy. Với một yêu cầu nêu thẳng "serverless và tiết kiệm chi phí" thì đây là phương án bị loại vì ràng buộc vận hành, chứ không phải vì nó không chạy được.

D. Dựng cụm EMR có Hive metastore cấu hình sẵn, chuyển metastore lên đó, rồi dùng Glue Data Catalog để đồng bộ catalog. Phương án này có nhắc tới Glue Data Catalog nên trông rất hợp lý, nhưng nó đặt Glue vào sai vai: catalog thật vẫn nằm trên cụm EMR, còn Glue chỉ làm bản sao đồng bộ. Hậu quả là metadata gắn với vòng đời của cụm — cụm bị tắt hay dựng lại thì phải lo giữ metastore, tức là vẫn phải quản lý hạ tầng, trái với "serverless". Thêm nữa, duy trì hai kho metadata rồi đồng bộ giữa chúng là tự tạo thêm một chỗ có thể lệch dữ liệu. Cách đúng là để Glue Data Catalog làm kho metadata chính, không phải bản sao.

📌 Điểm cần nhớ

• AWS Glue Data Catalog là bản thay thế serverless cho Apache Hive metastore, tương thích Hive nên EMR (Hive, Spark, Presto) trỏ thẳng vào được. Thấy đề nêu "Hive metastore + serverless" thì gần như chắc chắn đáp án là Glue Data Catalog.
• Đọc kỹ chữ "serverless" trong đề — nó là con dao loại phương án. Amazon RDS và metastore chạy trên cụm EMR đều "chạy được", nhưng đều là hạ tầng phải nuôi, nên đều rớt trước ràng buộc này.
• Athena là dịch vụ truy vấn, không phải kho catalog. Athena tiêu thụ Glue Data Catalog chứ không thay thế nó. Đừng chọn Athena cho những câu hỏi về quản lý metadata.
• Glue Data Catalog nên là nguồn chân lý, không nên là bản sao đồng bộ. Phương án nào giữ metastore ở nơi khác rồi "đồng bộ sang Glue" là thêm hạ tầng và thêm chỗ lệch dữ liệu, thường là phương án sai được nguỵ trang bằng cách nhắc tên dịch vụ đúng.

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

Một công ty mạng xã hội lưu user activity logs trong một bảng Amazon DynamoDB. Log chỉ có giá trị phân tích trong 30 ngày, sau đó phải bị xoá để tiết kiệm chi phí lưu trữ.

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

• "automatically remove" — phải là cơ chế tự động, do chính dịch vụ lo, không phải một quy trình do mình dựng và trông coi.
• "from the DynamoDB table" — đối tượng bị xoá là item trong DynamoDB, không phải object trong một kho lưu trữ khác.

Ràng buộc thứ nhất loại các phương án đòi tự viết và tự vận hành logic xoá; ràng buộc thứ hai loại thẳng phương án dùng công cụ vòng đời của một dịch vụ khác. Đề còn ám chỉ mục tiêu tiết kiệm chi phí, nên giải pháp thêm chi phí vận hành mới càng đi ngược ý đồ.

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

A. Set up a Time To Live (TTL) attribute on the DynamoDB table là đáp án đúng.

TTL là tính năng có sẵn của DynamoDB dành đúng cho tình huống này: bạn khai một thuộc tính trên bảng để làm cột mốc hết hạn, rồi ghi vào mỗi item một dấu thời gian (thời điểm tạo cộng thêm 30 ngày). Khi mốc đó trôi qua, DynamoDB tự xoá item mà không cần bất kỳ thành phần nào khác.

Ba điểm khiến nó vượt trội trong bối cảnh đề bài:

• Không cần code, không cần lịch chạy — cơ chế do chính DynamoDB đảm nhiệm.
• Việc xoá bằng TTL không tiêu tốn write capacity như thao tác xoá thông thường, nên đúng với mục tiêu tiết kiệm chi phí của đề.
• Log là dữ liệu có hạn dùng rõ ràng theo từng bản ghi — đúng mô hình mà TTL sinh ra để phục vụ.

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

B. Use Amazon DynamoDB Streams to trigger a deletion process for items that are 30 days old. Đây là phương án gây nhầm nhiều nhất vì Streams đúng là tính năng của DynamoDB. Nhưng Streams ghi lại các thay đổi trên item (thêm, sửa, xoá) và phát chúng ra cho consumer xử lý — nó phản ứng theo sự kiện thay đổi, chứ không theo tuổi của dữ liệu. Một item ghi vào hôm nay sẽ sinh sự kiện ngay lúc ghi, chứ không sinh thêm sự kiện nào khi nó tròn 30 ngày. Muốn dùng Streams để xoá theo tuổi thì vẫn phải dựng thêm bộ phận hẹn giờ và logic xoá bên ngoài — phức tạp hơn hẳn TTL mà chẳng được lợi gì.

C. Configure an AWS Lambda function to periodically scan the DynamoDB table and delete items older than 30 days. Phương án này chạy được về mặt kỹ thuật, nhưng sai ở chỗ nó là cách làm thủ công cho một việc đã có tính năng dựng sẵn. Bạn phải viết hàm, duy trì nó, đặt lịch chạy, và trả tiền cho cả lần gọi Lambda lẫn thao tác đọc/ghi phát sinh. Riêng chuyện scan toàn bảng đã là điểm trừ lớn: scan duyệt qua mọi item chứ không nhắm trúng phần cần xoá, nên bảng càng lớn thì càng tốn và càng chậm. Đề nhấn "tiết kiệm chi phí" và "tự động" — phương án này thua ở cả hai.

D. Implement an Amazon S3 Lifecycle policy to remove data from the DynamoDB table after 30 days. Sai hoàn toàn về mặt khái niệm. S3 Lifecycle policy chỉ tác động lên object trong bucket S3; nó không có đường nào chạm tới item trong bảng DynamoDB. Hai dịch vụ khác nhau, hai mô hình dữ liệu khác nhau, và Lifecycle policy không phải công cụ dùng chéo được.

📌 Điểm cần nhớ

• Đề hỏi tự động xoá dữ liệu hết hạn trong DynamoDB → phản xạ đầu tiên là TTL. Đây là tính năng dựng sẵn, không tốn write capacity như thao tác xoá thường.
• DynamoDB Streams phản ứng theo thay đổi, không theo tuổi dữ liệu. Thấy đề nói "sau N ngày" mà phương án đưa Streams ra làm cơ chế kích hoạt thì gần như chắc chắn sai.
• Phương án Lambda quét định kỳ thường là bẫy "chạy được nhưng không tối ưu": khi đề nhắc tới ít chi phí, ít vận hành, tự động, hãy chọn tính năng có sẵn thay vì code tự viết.
• Công cụ vòng đời gắn liền với dịch vụ sinh ra nó. S3 Lifecycle chỉ quản object S3, không đụng được vào bảng DynamoDB — đây là dạng phương án sai ngay từ khái niệm, loại được không cần suy nghĩ lâu.

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

Một công ty bán lẻ thu thập dữ liệu giao dịch theo thời gian thực bằng Amazon Kinesis Data Streams, muốn đưa dữ liệu đó vào Amazon Redshift để phân tích ngay và giữ tương thích với các công cụ BI đang dùng.

Cụm từ quyết định nằm ở câu hỏi cuối: "real-time analytics requirements with the least operational overhead" — hai ràng buộc phải thỏa đồng thời:

• real-time: dữ liệu phải chảy liên tục vào Redshift, không được gom lô rồi nạp theo lịch.
• least operational overhead: không phải viết mã, không phải bảo trì tiến trình do mình quản lý, không phải đặt lịch chạy.

Ràng buộc thứ hai chính là thứ tách các phương án gần giống nhau. Có nhiều cách đưa dữ liệu từ Kinesis Data Streams vào Redshift; câu hỏi không hỏi cách nào chạy được, mà hỏi cách nào ít việc phải tự quản lý nhất. Ai đọc lướt và chỉ bám vào "real-time" sẽ dễ chọn nhầm phương án Lambda, vì Lambda cũng là xử lý liên tục.

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

B — dùng Kinesis Data Firehose để chuyển dữ liệu từ Kinesis Data Streams sang Redshift, nạp tự động bằng lệnh COPY.

Firehose là dịch vụ fully managed cho việc đưa dữ liệu streaming vào các kho dữ liệu và công cụ phân tích. Nó nhận Kinesis Data Streams làm nguồn, tự đệm dữ liệu, có thể biến đổi dữ liệu trên đường đi, rồi tự phát lệnh COPY để nạp vào Redshift — đúng cách nạp dữ liệu hiệu quả mà Redshift khuyến nghị.

Điểm mấu chốt: toàn bộ phần "vận hành" ở đây là cấu hình, không phải lập trình. Không có mã ứng dụng để viết, không có consumer để tự mở rộng quy mô, không có lịch chạy để canh, không có tiến trình chết giữa chừng để đi khôi phục. Dữ liệu vào Redshift theo dòng liên tục nên nhu cầu phân tích thời gian thực được đáp ứng, mà Redshift vẫn là điểm truy vấn quen thuộc cho các công cụ BI sẵn có của công ty. Đó là lý do B thắng cả hai vế của đề bài.

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

A — batch ETL định kỳ rút dữ liệu từ Kinesis Data Streams rồi nạp vào Redshift. Sai ở vế real-time: bản chất của batch là gom dữ liệu rồi nạp theo chu kỳ, nên luôn tồn tại độ trễ giữa lúc dữ liệu phát sinh và lúc nó truy vấn được. Ngoài ra còn sai luôn vế operational overhead: phải tự dựng tiến trình trích xuất, tự đặt lịch và tự theo dõi — nhiều việc hơn hẳn so với việc để Firehose nạp tự động.

C — Kinesis Data Streams + AWS Lambda xử lý và nạp liên tục vào Redshift. Đây là phương án gần đúng nhất và là cái bẫy chính của câu này: nó có chạy được và có tính liên tục, nên thỏa vế real-time. Chỗ hỏng nằm ở vế còn lại — bạn phải tự viết mã hàm Lambda, tự lo logic nạp, tự xử lý lỗi và tự bảo trì đoạn mã đó về sau. So với một luồng Firehose chỉ cần cấu hình, đây rõ ràng là nhiều overhead vận hành hơn. Đề đã nói thẳng "minimizes the need for manual intervention and operational management", nên phương án đòi viết và nuôi mã bị loại.

D — dùng Amazon Redshift Spectrum truy vấn thẳng dữ liệu từ Kinesis Data Streams, không cần lưu trữ. Sai về mặt kỹ thuật ngay từ tiền đề. Redshift Spectrum dùng để truy vấn dữ liệu nằm trong Amazon S3, nó không đọc trực tiếp từ Kinesis Data Streams — nên kịch bản mô tả trong phương án này không tồn tại. Thêm nữa, Spectrum sinh ra để quét khối lượng dữ liệu lớn đang nằm trong kho lưu trữ, chứ không phải để phân tích thời gian thực trên dòng dữ liệu đang chảy.

📌 Điểm cần nhớ

• Khi đề nhấn "least operational overhead", ưu tiên dịch vụ fully managed cấu hình được hơn là giải pháp phải viết mã — Lambda tuy "serverless" nhưng vẫn là mã do bạn viết và bảo trì.
• Kinesis Data Firehose là con đường mặc định để đưa dữ liệu streaming vào đích như Redshift; nó nhận Kinesis Data Streams làm nguồn và nạp vào Redshift bằng lệnh COPY.
• Thấy chữ "batch" hay "periodically" trong một câu hỏi có yêu cầu real-time thì gần như chắc chắn loại được ngay.
• Redshift Spectrum gắn với S3, không phải với luồng streaming. Phương án nào ghép Spectrum với một nguồn không phải S3 là sai ở tiền đề, không cần cân nhắc thêm.

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

Đề mô tả một bảng xếp hạng điểm cao (leaderboard) cho game trực tuyến. Hệ thống nhận bursts of high read traffic — các đợt đọc dồn dập mỗi khi điểm được cập nhật — và backend hiện tại là relational database đang bị latency dưới tải nặng vì quá nhiều truy vấn đọc lặp lại.

Câu hỏi: dùng dịch vụ AWS nào để giảm read latency và quản lý lưu lượng đọc hiệu quả hơn.

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

• "The backend is powered by a relational database" — đây là ràng buộc về hiện trạng. Giải pháp phải cắm được vào kiến trúc relational đang chạy, không được ngầm đòi đổi engine dữ liệu.
• "bursts of high read traffic" + "frequent read requests" — tải đọc lặp lại trên cùng một tập dữ liệu nhỏ (top scores). Đây chính là dạng workload mà in-memory cache sinh ra để phục vụ: đọc lại nhiều lần cùng một thứ.

Ghép hai ràng buộc: cần một lớp cache in-memory đặt trước database quan hệ hiện có.

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

A — Amazon ElastiCache là in-memory data store được quản lý (tương thích Redis / Memcached). Dữ liệu nằm trong RAM nên thời gian phản hồi ở mức dưới mili-giây, nhanh hơn hẳn việc đi qua storage engine và query planner của một relational database.

Với leaderboard, phần dữ liệu nóng rất nhỏ và bị đọc đi đọc lại: chỉ vài chục dòng top score mà hàng nghìn client cùng hỏi. Cache lớp này lại, mọi request trúng cache sẽ không chạm tới database, nên vừa giảm latency cho người chơi vừa gỡ tải đọc khỏi database — đúng hai thứ đề bài yêu cầu.

Quan trọng không kém: ElastiCache đứng cạnh database quan hệ hiện tại như một lớp phía trước, không đòi thay đổi nơi lưu trữ nguồn. Ứng dụng đọc cache trước, miss thì mới xuống database rồi ghi ngược vào cache. Hiện trạng relational giữ nguyên.

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

B — DynamoDB với DAX. Đây là phương án gần đúng nhất và cũng là bẫy chính. DAX đúng là in-memory cache, đúng là giải quyết bài toán đọc nóng. Nhưng DAX chỉ hoạt động với DynamoDB — nó là cache nằm trước DynamoDB, không phải cache đa dụng. Backend trong đề là relational database, nên muốn dùng DAX thì trước hết phải migrate toàn bộ dữ liệu sang DynamoDB: đổi mô hình dữ liệu, viết lại tầng truy cập, xử lý chuyện chuyển đổi. Đó là một dự án tái kiến trúc, trong khi đề chỉ hỏi cách giảm latency đọc. Phương án hỏng ở chỗ nó âm thầm đòi đổi cả engine dữ liệu, chứ không phải hỏng ở kỹ thuật cache.

C — Amazon S3. S3 là object storage: bền, sẵn sàng cao, rẻ. Nhưng nó không được thiết kế cho kiểu đọc độ trễ cực thấp, tần suất cực cao trên từng bản ghi nhỏ như một leaderboard thời gian thực. Mỗi lần đọc là một request qua HTTP tới hệ thống lưu trữ đối tượng, chậm hơn nhiều bậc so với đọc từ RAM. Ngoài ra S3 không có mô hình truy vấn tiện cho việc lấy "top N theo điểm" — muốn cập nhật một điểm số là phải ghi lại cả object. "High availability" trong phương án là mô tả đúng về S3, nhưng nó trả lời sai câu hỏi: đề hỏi về latency và tải đọc.

D — Thêm read replicas. Đây là phương án hợp lý nhất trong ba phương án sai, và trong nhiều bài toán khác nó là câu trả lời đúng. Read replica đúng là phân tán được lưu lượng đọc ra nhiều instance. Vấn đề là nó không đổi bản chất của một lần đọc: mỗi truy vấn vẫn đi qua đầy đủ đường đi của một database quan hệ, latency mỗi request về cơ bản vẫn như cũ — chỉ là ít tranh chấp hơn. Trước các burst đột ngột, thêm replica là mở rộng theo chiều ngang bằng cách nhân bản nguyên cả database, tốn kém và không tức thời, trong khi dữ liệu nóng vẫn chỉ là vài dòng. Một cache in-memory giải đúng bài toán này gọn hơn nhiều.

📌 Điểm cần nhớ

• Đọc lặp lại cùng một tập dữ liệu nhỏ + yêu cầu latency thấp → in-memory cache. Leaderboard, session store, đếm lượt xem đều rơi vào khuôn này. Cache giảm cả latency lẫn tải xuống database; scaling ra thêm replica chỉ giảm tải chứ hầu như không giảm latency mỗi request.
• DAX gắn chặt với DynamoDB, ElastiCache thì không gắn với engine nào. Đề nói backend là relational → DAX loại ngay. Đề nói backend là DynamoDB → DAX thường là đáp án. Đây là cặp phân biệt xuất hiện rất nhiều trong đề thi.
• Chú ý ràng buộc "hiện trạng" trong đề. Phương án nào ngầm bắt migrate sang một dịch vụ dữ liệu khác thường là sai, trừ khi đề nói rõ đang cân nhắc thay kiến trúc.
• S3 tối ưu cho độ bền và dung lượng, không phải cho đọc-ghi từng bản ghi nhỏ ở tần suất cao. Thấy "low-latency" đi kèm S3 trong một phương án thì nên nghi ngờ ngay.

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

Một hãng luật muốn lưu hồ sơ vụ án tối mật trên Amazon S3, với hai yêu cầu đi kèm nhau:

1. "only designated lawyers can view and edit the files" — chỉ đúng nhóm luật sư được chỉ định mới đọc và sửa được tệp.
2. "track which specific users accessed or modified a file" — phải truy ra được cá nhân nào đã truy cập hay chỉnh sửa tệp.

Cụm từ quyết định là "highly confidential" đi cùng "which specific users". Nói cách khác, đề không chỉ hỏi cách chặn truy cập, mà hỏi cách vừa kiểm soát quyền vừa để lại dấu vết theo từng người dùng cho dữ liệu ở mức tối mật. Ba phương án còn lại đều chỉ chạm được một nửa yêu cầu — hoặc chỉ chống xoá/ghi đè, hoặc chỉ chặn quyền mà không kiểm soát ở lớp mã hoá.

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

A — SSE-KMS và giới hạn quyền dùng key cho nhóm luật sư được chỉ định.

Khi tệp được mã hoá bằng SSE-KMS, hãng luật chỉ định đúng KMS key nào dùng để mã hoá, rồi dùng key policy để quy định chính xác ai được phép dùng key đó để mã hoá và giải mã. Đây là lớp kiểm soát nằm ngoài quyền trên object: không có quyền dùng key thì dù chạm được tới object cũng không đọc ra nội dung.

Phần kiểm toán cũng do KMS lo: KMS ghi lại mọi lần sử dụng key vào AWS CloudTrail, nên hãng luật xem lại được người dùng nào đã truy cập hoặc chỉnh sửa tệp. Một phương án đáp ứng trọn cả hai vế của đề — kiểm soát ở mức người dùng và truy vết theo từng người dùng.

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

B — S3 Object Lock chế độ governance + IAM policy. Object Lock ngăn object bị xoá hoặc ghi đè trong một khoảng thời gian ấn định, hoặc vô thời hạn. Nó phục vụ yêu cầu lưu giữ để tuân thủ (compliance retention), tức là bảo vệ tính bất biến của dữ liệu — chứ không quản lý quyền truy cập ở mức người dùng, cũng không quản lý việc dùng key mã hoá. Đề hỏi "ai xem và sửa được, và ai đã xem", Object Lock trả lời câu khác hẳn.

C — Bucket policy theo IAM role + S3 access logging. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Bucket policy đúng là chặn được truy cập, và S3 access logging đúng là sinh ra bản ghi kiểm toán. Nhưng nó hỏng ở chỗ: không có lớp quản lý key mã hoá chi tiết, cũng không có việc theo dõi từng lần sử dụng key như KMS làm. Với dữ liệu "highly confidential", chỉ dựa vào quyền trên object nghĩa là bỏ mất lớp phòng thủ ở tầng mã hoá — hồ sơ vẫn nằm đó ở dạng đọc được với bất kỳ ai lách qua được lớp policy. Chi tiết hơn nữa: policy dựa trên role thì nhiều người có thể cùng đảm nhận một role, làm mờ đi việc quy trách nhiệm tới cá nhân mà đề yêu cầu.

D — S3 Versioning + MFA Delete. Versioning giữ lại các phiên bản cũ, MFA Delete buộc phải có xác thực đa yếu tố khi xoá phiên bản. Cả hai chống xoá nhầm và ghi đè nhầm — không phải chống truy cập trái phép. Đặc biệt lưu ý cách phương án diễn đạt: "requiring multi-factor authentication for file access" là mô tả sai bản chất, MFA Delete tác động lên thao tác xoá chứ không phải lên thao tác đọc tệp. Và nó cũng không ghi lại được ai đã truy cập tệp nào.

📌 Điểm cần nhớ

• Đề hỏi "track which specific users" trên dữ liệu nhạy cảm → nghĩ ngay tới SSE-KMS + CloudTrail: KMS ghi lại từng lần dùng key, cho ra dấu vết ở mức cá nhân.
• Key policy là một lớp kiểm soát riêng, cộng thêm vào IAM/bucket policy. Với dữ liệu tối mật, đáp án ưu tiên phương án có cả hai lớp thay vì chỉ một.
• Phân biệt rạch ròi ba nhóm tính năng S3 hay bị trộn lẫn trong đề thi: Object Lock / Versioning / MFA Delete = bảo vệ tính bất biến và chống xoá; bucket policy / IAM = kiểm soát truy cập; SSE-KMS = kiểm soát ở tầng mã hoá kèm audit theo từng lần dùng key.
• Đọc kỹ phần mô tả trong phương án, không chỉ tên dịch vụ: "MFA cho file access" là dấu hiệu phương án mô tả sai công dụng thật của MFA Delete.

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

Đề mô tả một ứng dụng thương mại điện tử chạy trên Amazon EC2, dùng Amazon RDS làm database backend, và nêu rõ một chi tiết quyết định: "The EC2 instances and RDS instance are in the same VPC". Yêu cầu là chỉ EC2 instances được nói chuyện với RDS trên database port, và "no external database connections are allowed".

Hai cụm từ định đoạt mọi thứ:

• "in the same VPC" — loại ngay mọi phương án nói tới việc nối hai mạng lại với nhau, vì chúng đã nằm chung một mạng rồi.
• "only the EC2 instances ... no external connections" — loại mọi phương án mở đường theo IP công cộng hoặc theo dải IP rộng.

Ngoài ra, câu hỏi ghi rõ "security group rules" (số nhiều, Select TWO), tức là đáp án phải là luật trong security group, và cần đủ cả hai chiều của một kết nối: chiều đi ra từ phía client và chiều đi vào ở phía database.

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

Đáp án đúng theo tệp là D và E — hai luật bù cho nhau, tạo thành một cặp hoàn chỉnh:

D — inbound rule trên security group của RDS, cho phép traffic ở database port từ chính security group của EC2 instances. Đây là cách chuẩn để thể hiện "chỉ những máy này mới được vào". Nguồn của luật không phải một dải IP mà là một security group khác — cái gọi là security group referencing. Nhờ vậy, quyền truy cập gắn với vai trò của instance chứ không gắn với địa chỉ: thêm hay thay EC2 instance, IP đổi, luật vẫn đúng và không phải sửa gì. Đây chính là nguyên tắc least privilege mà giải thích gốc nhấn mạnh — chỉ application server vào được database, không ai khác.

E — outbound rule trên security group của EC2 instances, cho phép traffic tới security group của RDS ở database port. Đây là phía chủ động khởi tạo kết nối: application server phải được phép gửi gói tin ra tới database port thì phiên kết nối mới bắt đầu được. Security group là stateful, nghĩa là traffic trả về của một kết nối đã được cho phép sẽ tự động đi ngược lại mà không cần luật riêng — nhưng điều đó chỉ đúng cho chiều trả lời, không thay cho luật cho phép chiều đi ra ban đầu. Vì outbound của EC2 có thể đã bị siết chặt theo chuẩn bảo mật, khai tường minh luật này là phần còn lại của cặp.

Ghép D và E: EC2 được phép gọi ra đúng database port của RDS, RDS chỉ chấp nhận đúng nguồn là EC2 — không mở gì thừa.

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

A — inbound rule trên RDS security group cho phép 0.0.0.0/0 vào database port "để dễ quản lý". Đây là phương án sai rõ nhất và đi ngược thẳng yêu cầu "no external database connections". Mở database port cho toàn bộ dải địa chỉ biến database thành mục tiêu quét cổng và dò mật khẩu. Lý do "cho dễ quản lý" là cái bẫy kinh điển: tiện lợi vận hành không bao giờ là lý do chính đáng để bỏ least privilege.

C — inbound rule trên RDS security group cho phép traffic từ public IP của các EC2 instances. Đây là phương án gần đúng nhất và cũng là chỗ dễ mất điểm. Nó đúng ở chỗ có siết nguồn lại thay vì mở toang, nhưng hỏng ở hai điểm:

• Public IP của EC2 instance là địa chỉ động — dừng rồi khởi động lại instance là mất IP cũ (trừ khi gán Elastic IP), thay instance khi scale cũng vậy. Luật viết theo IP sẽ âm thầm hết hiệu lực và ứng dụng mất kết nối database.
• Quan trọng hơn: EC2 và RDS đã ở chung một VPC, traffic giữa chúng đi bằng địa chỉ riêng trong mạng. Bắt nó đi vòng qua public IP là mở cửa cho đường đi từ bên ngoài vào — đúng thứ đề bài cấm.

B — dựng VPC peering giữa VPC của EC2 và VPC của RDS. Sai ngay ở tiền đề: VPC peering là cơ chế nối hai VPC khác nhau, trong khi đề đã nói rõ cả hai nằm trong cùng một VPC. Không có gì để peer cả. Ngoài ra, câu hỏi hỏi về security group rules, còn peering là cấu hình ở tầng mạng — kể cả khi hai bên ở hai VPC thật, peering cũng chỉ mở đường đi, chứ tự nó không quyết định ai được vào database port.

📌 Điểm cần nhớ

• Trong cùng một VPC, cách siết truy cập database chuẩn là security group tham chiếu security group khác, không phải liệt kê IP. Quyền gắn với vai trò của instance nên vẫn đúng khi instance được thay hoặc scale.
• Security group là stateful: traffic trả lời của kết nối đã cho phép tự động đi ngược được, nên không cần luật cho chiều trả về — nhưng vẫn cần luật cho chiều khởi tạo kết nối ở phía client.
• Thấy phương án dùng public IP hay 0.0.0.0/0 cho database port thì loại, kể cả khi nó được gói trong lý do "dễ quản lý": database không nên có đường vào từ Internet.
• VPC peering chỉ dành cho hai VPC khác nhau. Đề nào đã nói "same VPC" thì mọi phương án peering đều là mồi nhử.