Ngân hàng đề — AWS Certified Database Specialty

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

Câu hỏi tập trung vào tình huống một quản trị viên cơ sở dữ liệu (database administrator) cần lưu trữ một snapshot tự động (automated database snapshot) từ Amazon RDS cho Microsoft SQL Server DB instance lâu hơn giới hạn số ngày tối đa mà AWS cho phép.

• Automated snapshots trong RDS được tạo tự động theo lịch backup, nhưng retention period (thời gian lưu trữ) của chúng bị giới hạn tối đa 35 ngày (theo tài liệu AWS mới nhất đến 2026, không thay đổi).
• Yêu cầu là tìm giải pháp hiệu quả nhất về mặt vận hành (MOST operationally efficient) để giữ snapshot này lâu dài, mà không làm gián đoạn hoạt động RDS và tận dụng tối đa tính năng native của AWS.
• Mục tiêu chính: Tránh mất dữ liệu snapshot tự động sau 35 ngày, đồng thời ưu tiên phương pháp đơn giản, chi phí thấp và tích hợp cao.

🛠️ Bối cảnh kỹ thuật: RDS hỗ trợ snapshot cho SQL Server, nhưng automated snapshots chỉ tồn tại tạm thời. Giải pháp phải xử lý trực tiếp snapshot hiện có mà không cần export hay recreate backup từ đầu.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Create a manual copy of the snapshot.

Lý do chi tiết:

• Khi tạo manual copy từ automated snapshot, AWS sẽ chuyển snapshot thành manual snapshot, có thể lưu trữ vô thời hạn (indefinitely) hoặc lên đến 100 năm tùy theo thiết lập tài khoản (cập nhật AWS 2026).
• Phương pháp này hiệu quả vận hành nhất vì:
  • Chỉ cần một lệnh AWS CLI/API đơn giản (ví dụ: aws rds copy-db-snapshot), không cần export dữ liệu lớn.
  • Giữ nguyên định dạng snapshot RDS native, dễ dàng restore thành DB instance mới bất kỳ lúc nào.
  • Chi phí thấp (chỉ tính phí lưu trữ), không yêu cầu thay đổi cấu hình DB hoặc can thiệp SQL Server.
• Đây là best practice được AWS khuyến nghị cho việc lưu trữ dài hạn snapshot RDS.

📋 Giải thích tất cả các phương án (đúng và sai)

• ✅ Create a manual copy of the snapshot.
  Đúng 🥇: Như giải thích trên, đây là cách chuẩn và hiệu quả nhất. Manual snapshot kế thừa toàn bộ dữ liệu từ automated snapshot, không mất thời gian xử lý dữ liệu, và có thể chia sẻ cross-region/account nếu cần. Hoàn hảo cho SQL Server RDS!

• ❌ Export the contents of the snapshot to an Amazon S3 bucket.
  Sai 🚫: RDS không hỗ trợ export trực tiếp nội dung snapshot ra S3 cho SQL Server (chỉ hỗ trợ cho MySQL/PostgreSQL với native backup export từ DB instance, không phải snapshot). Việc này yêu cầu restore snapshot thành DB tạm thời rồi export, tốn kém tài nguyên, thời gian và không "operationally efficient". (Cập nhật 2026: Tính năng export snapshot S3 vẫn hạn chế cho SQL Server.)

• ❌ Change the retention period of the snapshot to 45 days.
  Sai 🔒: Retention period cho automated snapshots chỉ tối đa 35 ngày, không thể tăng lên 45 ngày (giới hạn cứng của AWS RDS). Thay đổi chỉ áp dụng cho tương lai snapshots, không cứu được snapshot hiện tại sắp hết hạn. Vi phạm quy tắc RDS!

• ❌ Create a native SQL Server backup. Save the backup to an Amazon S3 bucket.
  Sai ⚠️: Native backup SQL Server yêu cầu chạy lệnh từ DB instance đang live (qua SQL Server Management Studio hoặc AWS DMS), không áp dụng trực tiếp cho snapshot đã tồn tại. Phải restore snapshot trước rồi backup lại – quy trình phức tạp, tốn CPU/DB resources, và không phải từ snapshot gốc. Không hiệu quả cho mục tiêu!

📘 Tài liệu tham khảo (AWS cập nhật mới nhất 2026)

• RDS User Guide - Working with DB Snapshots: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html – Chi tiết về automated vs manual snapshots và retention limits.
• RDS Snapshots Best Practices: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithSnapshots.html – Hướng dẫn copy snapshot cho lưu trữ dài hạn.
• AWS CLI Reference: copy-db-snapshot command – docs.aws.amazon.com/cli/latest/reference/rds/copy-db-snapshot.html.
• Exam Topic DOP-C02: Phần RDS Backup & Restore trong AWS Certified DevOps Engineer Professional.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần ví dụ code CLI, hãy hỏi thêm nhé!

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

Câu hỏi tập trung vào việc xuất dữ liệu từ snapshot của Amazon Aurora MySQL DB instance sang Amazon S3 data lake để bộ phận marketing sử dụng dữ liệu gửi email khuyến mãi. Yêu cầu là chọn kết hợp 3 bước thực hiện việc export từ snapshot với ít operational overhead nhất (tức là đơn giản, tự động hóa cao, không cần can thiệp thủ công nhiều).

• Bối cảnh: Aurora MySQL hỗ trợ tính năng export snapshot data to S3 (từ năm 2019, cập nhật liên tục đến 2026), cho phép xuất toàn bộ dữ liệu từ tất cả các bảng dưới dạng Parquet files (nén, columnar format phù hợp data lake). Quá trình này serverless, không làm gián đoạn DB chính, và hỗ trợ encryption qua KMS.
• Yêu cầu chính: Sử dụng snapshot hiện có hoặc tạo mới, cấp quyền IAM đúng cách cho DB instance, và export với encryption vào S3 (không phải Glacier).
• Mục tiêu overhead thấp: Ưu tiên snapshot gốc (không copy), IAM role (không user), S3 chuẩn (không Glacier).

✅ Đáp án đúng (chọn 3 phương án)

Các đáp án đúng là A, D, E (dựa trên đánh dấu gốc và quy trình AWS chuẩn):

1. Use an existing automated snapshot or manual snapshot, or create a manual snapshot of the DB instance.
2. Create a symmetric AWS Key Management Service (AWS KMS) key for server-side encryption. Export the snapshot to Amazon S3.
3. Identify the S3 bucket for export. Provide access to the S3 bucket by using an IAM role. Attach an IAM policy with s3:PutObject, s3:GetQpject, s3:ListBucket, s3:DeleteObject*, and s3:GetBucketLocation permissions to the IAM role. Attach the IAM role to the DB instance.**

Lý do lựa chọn 🛠️:

• Kết hợp này đơn giản nhất, overhead thấp vì: (1) Dùng snapshot sẵn có (automated/manual) để tránh tạo copy thừa; (2) IAM role gắn trực tiếp vào DB instance (best practice, an toàn hơn IAM user); (3) Export với KMS symmetric key vào S3 chuẩn (hỗ trợ SSE-KMS, dữ liệu ngay lập tức dùng được cho data lake). Toàn bộ quy trình qua AWS Console/CLI/API, tự động, không cần script custom hay EC2 trung gian. Thời gian export phụ thuộc kích thước DB (ví dụ: 100GB ~ vài giờ).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng phương án một (giữ nguyên văn bản gốc tiếng Anh). Tôi đánh dấu ✅ cho đúng, ❌ cho sai, kèm lý do chi tiết dựa trên docs AWS mới nhất (2026).

• ✅ Use an existing automated snapshot or manual snapshot, or create a manual snapshot of the DB instance.
  🟢 Đúng: Bước đầu tiên bắt buộc. Aurora hỗ trợ export trực tiếp từ snapshot gốc (automated backup tự động hàng ngày hoặc manual). Overhead thấp vì không cần copy snapshot (tiết kiệm thời gian/storage). Nếu chưa có, tạo manual snapshot nhanh (retention 0-35 ngày).

• ❌ Identify the S3 bucket for export. Provide access to the S3 bucket by using an IAM user. Attach an IAM policy with s3:PutObject, s3:GetObject, s3:ListBucket, s3:DeleteObject*, and s3:DeleteObject*, and s3:GetBucketLocation permissions to the IAM user. Attach the IAM role to the DB instance.**
  🔴 Sai: Không dùng IAM user cho export snapshot – RDS/Aurora chỉ chấp nhận IAM role gắn vào DB instance (option group hoặc cluster). IAM user không tương thích, gây lỗi "Invalid role". Policy permissions đúng nhưng attach role sai (user không attach role được). Overhead cao hơn vì phải quản lý user credentials thủ công.

• ❌ Create a copy of an existing automated snapshot or manual snapshot of the DB instance.
  🔴 Sai: Không cần thiết! Export trực tiếp từ snapshot gốc (không copy), giảm overhead (copy tốn thời gian/storage ~ kích thước DB). AWS khuyến cáo tránh copy trừ khi cần cross-region hoặc modify.

• ✅ Create a symmetric AWS Key Management Service (AWS KMS) key for server-side encryption. Export the snapshot to Amazon S3.
  🟢 Đúng: KMS symmetric key (SSE-KMS) bắt buộc cho encryption khi export (mặc định unencrypted snapshot không export được). Export vào S3 chuẩn (không Glacier), dữ liệu dạng Parquet sẵn dùng cho Athena/Glue data lake. Overhead thấp, AWS quản lý process.

• ✅ Identify the S3 bucket for export. Provide access to the S3 bucket by using an IAM role. Attach an IAM policy with s3:PutObject, s3:GetQpject, s3:ListBucket, s3:DeleteObject*, and s3:GetBucketLocation permissions to the IAM role. Attach the IAM role to the DB instance.**
  🟢 Đúng: IAM role là best practice (trust policy cho RDS service principal). Policy permissions chuẩn (lưu ý lỗi đánh máy "GetQpject*" = GetObject*). Attach role vào DB cluster/option group → RDS tự dùng role export. Bucket phải same region, versioning enabled khuyến khích.

• ❌ Create a symmetric AWS Key Management Service (AWS KMS) key for server-side encryption. Export the snapshot to Amazon S3 Glacier Flexible Retrieval.
  🔴 Sai: Export không hỗ trợ S3 Glacier (chỉ S3 Standard/Intelligent-Tiering). Glacier dành archival, retrieval chậm (phút đến giờ), không phù hợp data lake cần truy vấn nhanh (Athena/S3 Select). Overhead cao vì phải restore sau, vi phạm "least overhead".

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• Chính thức: Exporting DB snapshot data from Amazon Aurora to Amazon S3 – Chi tiết IAM role/policy, KMS, snapshot requirements.
• IAM Policy Sample: RDS S3 Export Role (tương tự Aurora MySQL).
• Exam Tips (DOP-C02): AWS re:Post & A Cloud Guru – Nhấn IAM role over user, no copy snapshot.
• Cập nhật mới: Aurora Serverless v2 (2024-2026) hỗ trợ export nhanh hơn, Parquet v2 format.

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! 🚀 Nếu cần ví dụ CLI, comment nhé.

🧩 Giải thích nội dung câu hỏi

Câu hỏi xoay quanh tình huống một công ty tài chính lớn đang sử dụng AWS Database Migration Service (AWS DMS) để di chuyển cơ sở dữ liệu từ on-premises lên AWS Cloud. Trong quá trình migrate một database cụ thể, replication instance của DMS rơi vào trạng thái storage-full (hết dung lượng lưu trữ). Quản trị viên database cần khắc phục sự cố bằng cách chọn hai phương án phù hợp nhất.

🛠️ Nguyên nhân phổ biến của storage-full trong DMS:

• Replication instance sử dụng storage (EBS volume) để lưu cache dữ liệu thay đổi (Change Data Capture - CDC), temporary files, và logs lỗi.
• Storage bị đầy do lượng dữ liệu lớn, LOB (Large Objects), hoặc logs tích tụ.
• DMS không hỗ trợ giảm storage, chỉ có thể tăng storage hoặc nâng cấp instance class (với kiến thức cập nhật đến 2026, DMS hỗ trợ instance lên đến t3/r5/r6g series với storage tối đa 16 TiB tùy loại).

Mục tiêu: Chọn 2 options giúp tăng storage ngay lập tức mà không làm gián đoạn migration quá nhiều. (Lưu ý: Task đang chạy có thể cần pause/stop để modify một số settings).

✅ Đáp án đúng (Chọn TWO)

Hai phương án đúng là:

1. Change the size of the replication instance to a larger supported instance type.
2. Use the modify-replication-instance API to increase the amount of storage allocated to the replication instance.

Lý do lựa chọn:

• Cả hai đều trực tiếp tăng dung lượng storage của replication instance, giải quyết gốc rễ vấn đề storage-full.
• Theo docs AWS DMS (2026), replication instance có thể modify storage độc lập (tăng từ 50 GiB lên 16 TiB tùy instance class), hoặc nâng cấp instance type (ví dụ từ t3.medium lên t3.large, tự động tăng storage allocated).
• Không cần recreate instance, migration có thể resume nhanh chóng sau modify (downtime ngắn ~5-10 phút).
• Đây là best practice từ AWS Troubleshooting Guide cho DMS storage issues.

📋 Phân tích chi tiết TẤT CẢ các phương án

Dưới đây là giải thích từng lựa chọn một, với nội dung gốc giữ nguyên tiếng Anh, đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt rõ ràng:

• ✅ Change the size of the replication instance to a larger supported instance type.
  🟢 Đúng: Nâng cấp instance type lớn hơn (qua Console/CLI/API) sẽ tăng allocated storage tự động (ví dụ: t3.micro=50 GiB → t3.xlarge=1 TiB+). DMS hỗ trợ multi-AZ upgrade mà không mất dữ liệu cache. Giải quyết storage-full hiệu quả, phù hợp production.

• ❌ Use the AWS Management Console to modify the replication task settings to the limited large binary object (LOB) mode and set the value to 16.
  🔴 Sai: Limited LOB mode (MaxLobSize=16 KB) chỉ giới hạn xử lý LOB lớn để tránh full memory/buffer, không tăng storage instance. Phải stop task để modify, và chỉ giúp ngăn ngừa full trong tương lai, không fix storage-full hiện tại (cache CDC vẫn đầy). Không phải giải pháp chính cho storage instance.

• ❌ Use the AWS CLI to modify the replication task settings with ‘{“Logging”: {“DeleteTaskLogs”: true}}’.
  🔴 Sai: DMS task settings không có parameter "DeleteTaskLogs". Logging DMS chủ yếu đẩy vào CloudWatch Logs, không tự động xóa logs trên instance storage. Modify task logging yêu cầu stop task, và không giải quyết cache CDC (nguyên nhân chính storage-full). Command này lỗi syntax theo DMS API 2026.

• ❌ Use the AWS CLI to modify the replication task settings with ‘{“Logging”: {“CloudWatchLogGroup”: null}}’.
  🔴 Sai: Setting "CloudWatchLogGroup": null chỉ disable CloudWatch logging cho task mới, không ảnh hưởng storage instance (logs local vẫn tồn tại). Phải stop task để apply, và storage-full do EBS volume cache, không phải CW. Không fix gốc rễ, chỉ giảm logs tương lai.

• ✅ Use the modify-replication-instance API to increase the amount of storage allocated to the replication instance.
  🟢 Đúng: API ModifyReplicationInstance cho phép tăng storage trực tiếp (AllocatedStorage parameter, ví dụ +100 GiB) mà không thay đổi instance class. Hỗ trợ online modify (instance available ngay), lý tưởng cho production. AWS khuyến nghị cho storage-full (tăng dần 100 GiB/lần, max 16 TiB).

📘 Tài liệu tham khảo (AWS Docs cập nhật 2026)

• AWS DMS User Guide - Replication Instance Storage: docs.aws.amazon.com/dms/latest/userguide/CHAP_Storage.html – Chi tiết modify storage và instance sizing.
• Troubleshooting DMS Storage Full: docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.html#CHAP_Troubleshooting.ReplicationInstanceStorage – Best practices tăng storage.
• API Reference - ModifyReplicationInstance: docs.aws.amazon.com/dms/latest/APIReference/API_ModifyReplicationInstance.html – Xác nhận parameter AllocatedStorage.
• DMS Limits (2026): Instance storage up to 16 TiB on r6g.16xlarge (AWS Service Quotas).

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! 🚀 Nếu cần thêm ví dụ CLI/API, hãy hỏi nhé!

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

Câu hỏi tập trung vào việc triển khai disaster recovery (DR) đa vùng (multi-Region) cho ứng dụng trên AWS, cụ thể là Amazon DynamoDB.

• Bối cảnh: Công ty có website tĩnh trên Amazon S3 và Amazon CloudFront. Ứng dụng kết nối với bảng DynamoDB ở vùng us-east-1, bảng này mới tạo và đã được nạp lượng dữ liệu lớn từ công ty.
• Yêu cầu chính:
  • Replicate database real-time sang vùng us-west-2.
  • Bao gồm tất cả dữ liệu hiện có (existing data) và dữ liệu mới thêm sau này (future data).
  • Thực hiện tự động (automated), không cần can thiệp thủ công liên tục.
• Vai trò: Database specialist cần chọn giải pháp phù hợp sử dụng Global Tables của DynamoDB để đạt multi-Region replication với độ trễ thấp và tính sẵn sàng cao.

Lưu ý kỹ thuật (cập nhật AWS 2026): DynamoDB Global Tables hỗ trợ replication liên tục qua các vùng. Với bảng existing (có dữ liệu lớn), cần kích hoạt DynamoDB Streams với chế độ NEW_AND_OLD_IMAGES trước khi tạo replica để backfill (sao chép dữ liệu cũ tự động). Nếu không, chỉ replicate thay đổi mới, đòi hỏi copy thủ công dữ liệu cũ (không automated). Điều này đảm bảo zero data loss và point-in-time consistency.

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Enable DynamoDB streams. Configure streams for new and old images. Create a global table replica in us-west-2. Monitor the progress of the replication until the status changes to Active.

Lý do:

• 🛠️ Enable DynamoDB Streams với NEW_AND_OLD_IMAGES: Cho phép AWS đọc cả dữ liệu cũ (old images) và mới (new images) từ stream để backfill tự động toàn bộ dữ liệu hiện có khi tạo replica.
• 🧩 Create global table replica: Kích hoạt replication real-time cho dữ liệu tương lai qua multi-master setup.
• 📊 Monitor đến status Active: Đảm bảo replication hoàn tất (thường mất vài giờ với dữ liệu lớn), sau đó table ở us-west-2 đồng bộ 100%.
• ✅ Đầy đủ automated: Không cần export/import thủ công, phù hợp bảng mới tạo với dữ liệu lớn, hỗ trợ DR multi-Region.

📋 Giải thích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên docs AWS mới nhất.

• Enable DynamoDB streams. Configure streams for new and old images. Create a global table replica in us-west-2. Monitor the progress of the replication until the status changes to Active.
  ✅ Đúng (như đã giải thích ở trên). Đây là quy trình chuẩn cho existing tables với dữ liệu lớn: Streams backfill dữ liệu cũ + replication real-time cho dữ liệu mới, hoàn toàn automated.

• Create global table replica in us-west-2. Monitor the progress of the replication until the status changes to Active.
  ❌ Sai. Nếu không enable Streams trước, Global Table chỉ replicate thay đổi mới (ongoing changes) sau khi tạo replica. Dữ liệu hiện có không được backfill tự động, dẫn đến data loss ở replica (us-west-2 thiếu dữ liệu cũ). Không đáp ứng "include all existing table data".

• Enable DynamoDB streams. Configure streams for new and old images. Create a global table replica in us-west-2. Copy all existing data from us-east-1 to us-west-2 by using an export and batch import.
  ❌ Sai. Phần enable Streams + create replica đã đúng (backfill tự động), nhưng thêm export và batch import thủ công là thừa và phức tạp. Streams đã xử lý backfill, export/import (qua S3/DynamoDB Export) sẽ gây duplicate data, conflict, và không automated.

• Create a global table replica in us-west-2. Copy all existing data from us-east-1 to us-west-2 by using an export and batch import.
  ❌ Sai. Tạo replica chỉ replicate dữ liệu mới, nên cần copy thủ công dữ liệu cũ → không automated (phải export to S3 rồi batch-write-import, tốn thời gian với dữ liệu lớn). Dễ gây inconsistency nếu có writes trong lúc copy, không real-time.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• AWS DynamoDB Global Tables Developer Guide: Global Tables - Backfilling Existing Data – Xác nhận cần Streams (NEW_AND_OLD_IMAGES) cho backfill.
• DynamoDB Streams: Using Streams for Backfill.
• Exam Topic DOP-C02: Multi-Region DynamoDB replication cho DR (AWS Certified DevOps Engineer - Professional).
• Best Practices: AWS Well-Architected Framework - Reliability Pillar: Global Tables cho active-active DR.

Giải pháp này đảm bảo RPO=0 (no data loss) và RTO thấp cho DR! 🚀

🧩 Giải thích nội dung câu hỏi

Câu hỏi mô tả một tình huống thực tế: Một công ty đã triển khai ứng dụng ba tầng (three-tier application) bằng AWS CloudFormation kèm theo Amazon RDS DB instance. Trong quá trình kiểm tra, quản trị viên cơ sở dữ liệu (DBA) vô tình xóa CloudFormation stack, dẫn đến việc tất cả các tài nguyên (bao gồm RDS DB instance) bị xóa và mất dữ liệu quan trọng.
Yêu cầu chính: Ngăn chặn việc xóa nhầm DB instance trong tương lai. Cần chọn TWO giải pháp phù hợp.
🛠️ Bối cảnh kỹ thuật: Khi xóa CloudFormation stack, tất cả tài nguyên trong stack sẽ bị xóa theo mặc định (DeletionPolicy mặc định là Delete). Để bảo vệ, cần sử dụng các cơ chế như DeletionPolicy trên resource cụ thể hoặc TerminationProtection trên stack/resource để tránh xóa ngẫu nhiên.

✅ Đáp án đúng (Chọn TWO)

Dựa trên kiến thức AWS CloudFormation và RDS cập nhật đến năm 2026 (phiên bản mới nhất DOP-C02 và CloudFormation features):

1. Set the deletion policy of the RDS resource to Retain.
   🟢 Lý do: Thiết lập DeletionPolicy: Retain trực tiếp trên resource RDS DBInstance trong template CloudFormation sẽ giữ nguyên DB instance khi stack bị xóa, ngăn mất dữ liệu. Đây là cách bảo vệ resource-level hiệu quả nhất cho RDS.

2. Enable termination protection for the stack.
   🟢 Lý do: TerminationProtection trên CloudFormation stack (feature được hỗ trợ đầy đủ từ 2023+) ngăn chặn việc xóa stack hoàn toàn. Phải disable protection trước khi delete, tránh xóa nhầm toàn bộ stack và các resource bên trong.

📝 Phân tích chi tiết tất cả các phương án

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm giải thích rõ ràng dựa trên docs AWS mới nhất:

• Set the deletion policy of the stack to Retain.
  ❌ SAI: CloudFormation không hỗ trợ DeletionPolicy trực tiếp trên stack (stack-level). DeletionPolicy chỉ áp dụng cho individual resources trong template (như RDS DBInstance). Set trên stack sẽ không có hiệu lực và không bảo vệ DB instance.

• Set the deletion policy of the RDS resource to Retain.
  ✅ ĐÚNG: DeletionPolicy: Retain trên resource RDS DBInstance (property hợp lệ trong AWS::RDS::DBInstance) sẽ giữ nguyên DB instance ngay cả khi stack bị xóa. DB không bị terminate, dữ liệu được bảo toàn. Đây là giải pháp chuẩn cho RDS.

• Set the deletion policy of the stack to Snapshot.
  ❌ SAI: Tương tự phương án đầu, DeletionPolicy không tồn tại trên stack-level. Hơn nữa, Snapshot chỉ áp dụng cho một số resource hỗ trợ (như EBS, RDS), không phải cho toàn stack. Không ngăn chặn xóa DB.

• Enable termination protection for the RDS resource.
  ❌ SAI: RDS DBInstance sử dụng property DeletionProtection (boolean, true để bảo vệ), không gọi là "termination protection". "Termination protection" thường ám chỉ disableApiTermination cho EC2 Instance. Set sai tên sẽ không hoạt động, và ngay cả DeletionProtection cũng không retain DB mà chỉ fail delete request.

• Enable termination protection for the stack.
  ✅ ĐÚNG: TerminationProtection (property trên stack, enable qua AWS Console/CLI/API) khóa stack khỏi deletion. Phải explicit disable trước khi xóa, ngăn DBA xóa nhầm toàn bộ stack và DB instance. Feature này ổn định từ 2023+.

📘 Tài liệu tham khảo (AWS Docs cập nhật 2026)

• CloudFormation DeletionPolicy: AWS CloudFormation User Guide - DeletionPolicy – Chi tiết Retain/Snapshot per resource.
• RDS DBInstance Properties: AWS::RDS::DBInstance – DeletionPolicy và DeletionProtection.
• Stack Termination Protection: Protecting a stack from deletion – Feature chính thức từ 2023.
• Exam Context: DOP-C02 Sample Questions (AWS Certified DevOps Engineer - Professional).

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần template YAML mẫu, hãy hỏi thêm nhé!

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

Câu hỏi xoay quanh một công ty tại Mỹ (us-west-2) muốn mở rộng hoạt động sang châu Á. Dữ liệu sản xuất (production data) được lưu trữ trong bảng Amazon DynamoDB tại region us-west-2. Nhóm phát triển tại ap-northeast-1 (Tokyo) cần một bản sao dữ liệu này để thực hiện User Acceptance Testing (UAT) và các bài kiểm tra hiệu suất (performance feasibility tests). Quan trọng: Các bài test KHÔNG yêu cầu dữ liệu cập nhật real-time, nghĩa là chỉ cần một snapshot dữ liệu tại một thời điểm nhất định là đủ.
Mục tiêu: Tìm giải pháp cost-effective nhất (tiết kiệm chi phí nhất) để sao chép dữ liệu từ us-west-2 sang ap-northeast-1.
🔍 Yếu tố then chốt: Ưu tiên chi phí thấp, không cần replication liên tục (vì chỉ test một lần), tận dụng tính năng native của DynamoDB để tránh data transfer lớn và ongoing costs.

✅ Đáp án đúng: Use point-in-time recovery to restore the DynamoDB table from us-west-2 to ap-northeast-1.

Lý do lựa chọn:

• Point-in-Time Recovery (PITR) của DynamoDB cho phép khôi phục bảng đến bất kỳ thời điểm nào trong vòng 35 ngày gần nhất (mặc định PITR enabled với chi phí lưu trữ backup thấp ~0.20 USD/GB/tháng).
• Từ năm 2023 (cập nhật mới nhất đến 2026), AWS hỗ trợ cross-region restore trực tiếp từ PITR backup của us-west-2 sang ap-northeast-1, tạo bảng mới mà KHÔNG tốn data transfer outbound lớn (chỉ tính phí backup storage và restore).
• Cost-effective nhất vì: Không cần export/import thủ công, không replication real-time (tiết kiệm Lambda/Streams), phù hợp cho test không real-time. Thời gian nhanh, tự động hóa cao.
  🛡️ Ưu điểm: Backup PITR luôn sẵn sàng nếu enabled (On-Demand tables tự động), chi phí chỉ phát sinh khi restore (~0.10 USD/GB restored + storage mới).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai kèm lý do cụ thể:

• ❌ [SAI] Create a new DynamoDB table in ap-northeast-1. Create an AWS Glue job to perform a data export from the DynamoDB table in us-west-2. Import the same data into the DynamoDB table in ap-northeast-1.
  Giải thích sai: Phương án này dùng AWS Glue để export dữ liệu từ DynamoDB (qua S3) rồi import sang bảng mới. Tốn kém vì: (1) Data transfer cross-region outbound từ us-west-2 (~0.09 USD/GB), (2) Glue job tính phí theo DPU-time (Data Processing Units), (3) Thời gian dài cho dataset lớn, cần ETL thủ công. Không cost-effective cho test một lần, phức tạp hơn PITR native.

• ❌ [SAI] Enable DynamoDB Streams on the DynamoDB table in us-west-2. Create a new DynamoDB table in ap-northeast-1. Create an AWS Lambda function to poll the DynamoDB table stream in us-west-2 and to deliver batch records from the stream to the new DynamoDB table in ap-northeast-1.
  Giải thích sai: Sử dụng DynamoDB Streams + Lambda để replicate dữ liệu theo batch. Sai vì: (1) Streams tính phí đọc (~0.02 USD/100.000 units), Lambda invocation/execution time, (2) Phù hợp real-time replication nhưng thừa thãi (không cần real-time), (3) Cross-region polling tốn data transfer liên tục và latency cao. Chi phí ongoing cao hơn PITR snapshot.

• ✅ [ĐÚNG] Use point-in-time recovery to restore the DynamoDB table from us-west-2 to ap-northeast-1.
  Giải thích đúng: Như đã nêu ở trên. Đây là giải pháp native, nhanh chóng, chi phí thấp nhất cho cross-region copy không real-time. PITR restore tạo bảng mới độc lập tại ap-northeast-1 với dữ liệu chính xác tại thời điểm chọn, hỗ trợ cả On-Demand và Provisioned capacity.

• ❌ [SAI] Enable DynamoDB Streams on the DynamoDB table in us-west-2. Add ap-northeast-1 to the DynamoDB global tables setting in us-west-2.
  Giải thích sai: Global Tables (v2) dùng Streams để multi-region replication multi-master real-time. Sai vì: (1) Chi phí cao (replication lag <1s, nhưng tính phí Streams + write units ở cả hai region), (2) Không phù hợp test một lần (ongoing sync), (3) Tốn RCU/WCU gấp đôi. Chỉ dùng cho production high-availability, không cost-effective cho UAT.

📘 Tài liệu tham khảo (cập nhật AWS 2024-2026)

• DynamoDB PITR Cross-Region Restore: AWS Blog - Amazon DynamoDB PITR now supports restoring to a new table in a different AWS Region (ra mắt Nov 2023, áp dụng đến 2026).
• DynamoDB Pricing: DynamoDB Pricing Page – PITR ~0.20 USD/GB/tháng storage, restore phí thấp.
• DynamoDB Developer Guide: Point-in-time recovery: How it works và Global Tables.
• Exam Tip (DOP-C02): Ưu tiên native features như PITR cho cost-optimization cross-region copy (Well-Architected Framework: Cost Optimization pillar).

🛠️ Khuyến nghị thực tế: Enable PITR trước cho production tables. Test bằng AWS CLI: aws dynamodb restore-table-from-point-in-time --source-table-arn ... --target-table-name ... --destination-region ap-northeast-1. Chi phí ước tính: Với 100GB data, PITR restore ~20-30 USD (storage + restore), rẻ hơn alternatives!

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

Câu hỏi mô tả một công ty sử dụng nhiều AWS accounts trong AWS Organizations để tách biệt các đội ngũ phát triển làm việc trên các ứng dụng khác nhau. Mỗi account chứa nhiều ứng dụng chạy trong default VPC với interface endpoints. Các ứng dụng này cần truy cập cùng một dữ liệu từ Amazon Aurora PostgreSQL DB cluster nằm trong một AWS account cụ thể.

Yêu cầu chính: Tìm giải pháp MOST operationally efficient (hiệu quả vận hành nhất), nghĩa là:

• Hỗ trợ truy cập dữ liệu real-time (không phải backup).
• Tối ưu cho multi-account/multi-VPC trong Organizations.
• Sử dụng private connectivity (vì dùng interface endpoints, tránh public internet).
• Giảm thiểu quản lý phức tạp như peering nhiều VPC hoặc restore dữ liệu.

Bối cảnh AWS cập nhật 2026: Aurora PostgreSQL hỗ trợ cross-account access qua networking private (VPC sharing, peering, Transit Gateway). AWS RAM (Resource Access Manager) cho phép chia sẻ subnets hiệu quả trong Organizations. RDS Proxy giúp connection pooling, IAM auth, và truy cập an toàn cross-network.

📘 Tài liệu tham khảo:

• AWS RAM Subnet Sharing: docs.aws.amazon.com/ram/latest/userguide/shareable.html#subnet (hỗ trợ chia sẻ private subnets cross-account cho private access).
• RDS Proxy: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html (tích hợp với VPC sharing cho multi-account).
• AWS Organizations Best Practices: docs.aws.amazon.com/organizations/latest/userguide/orgs_best-practices_vpc-sharing.html.

✅ Đáp án đúng: Phương án đầu tiên

Use AWS Resource Access Manager (AWS RAM) to share the subnet that contains the database. Create an Amazon RDS Proxy endpoint for the other applications to access.

Lý do lựa chọn:

• 🛠️ AWS RAM cho phép chia sẻ subnet (chứa DB subnets của Aurora) cross-account trong Organizations một lần duy nhất, giúp các VPC khác attach ENIs vào shared subnet như cùng VPC → private connectivity tự động, không cần peering riêng lẻ.
• RDS Proxy triển khai trong shared subnet/VPC, cung cấp endpoint chung cho tất cả apps truy cập DB với connection pooling, IAM auth, multiplexing → giảm tải DB, an toàn, scalable.
• MOST operationally efficient: Quản lý tập trung (share 1 resource), hỗ trợ multiple accounts/VPCs, tránh N-to-1 peering connections. Phù hợp default VPC + interface endpoints (Proxy hỗ trợ VPC endpoints).

📋 Giải thích tất cả các phương án

• ✅ Use AWS Resource Access Manager (AWS RAM) to share the subnet that contains the database. Create an Amazon RDS Proxy endpoint for the other applications to access.
  Đúng vì: Như giải thích trên, kết hợp RAM subnet sharing (private VPC sharing hiệu quả nhất cho multi-account) + RDS Proxy (endpoint an toàn, pooling cho Aurora). Giảm chi phí quản lý peering, hỗ trợ real-time access. ✅ Hiệu quả vận hành cao nhất theo best practices AWS 2026.

• ❌ Use VPC peering to connect the VPCs of the other AWS accounts to the subnet that contains the database.
  Sai vì: VPC peering chỉ kết nối VPCs, không share subnet trực tiếp. Với multiple accounts/VPCs, cần nhiều peering connections (N-to-1), phức tạp quản lý (limit 125 peerings/VPC), không scalable, tăng operational overhead. Không efficient cho Organizations lớn.

• ❌ Create an Amazon S3 bucket that stores database backups. Configure replication to S3 buckets in the other accounts. Restore the backups in the other AWS accounts.
  Sai vì: Chỉ cung cấp backups (không real-time access dữ liệu đang chạy). Restore tạo DB riêng → dữ liệu không sync live, duplicate chi phí, không meet "access the same underlying data". Không dùng cho apps cần query real-time.

• ❌ Create an interface VPC endpoint for the Amazon RDS API. Attach an endpoint policy that grants the other AWS accounts access to the database.
  Sai vì: RDS API endpoint (com.amazonaws.region.rds) chỉ cho control plane (management APIs như DescribeDB), không phải data plane (query DB). Cross-account endpoint policy không grant data access; cần RDS Data Service endpoint (rds-data) nhưng vẫn yêu cầu networking (peering/sharing). Không giải quyết private data access.

Kết luận 🏆: Giải pháp RAM + RDS Proxy là tối ưu nhất cho multi-account private access đến Aurora, giảm thiểu config và scale dễ dàng!

🧩 Giải thích nội dung câu hỏi

Câu hỏi xoay quanh một ứng dụng game online được host trên AWS, sử dụng Amazon DynamoDB làm cơ sở dữ liệu chính. Bảng DynamoDB có một item duy nhất cho mỗi user đã đăng ký, với partition key (PK) là user ID (không đề cập sort key, nên bảng là kiểu partition key only).

Mỗi ngày, một report generator tính tổng (sum totals) của hai attributes well-known (cố định, dễ nhận biết) cho tất cả items chứa "dimension attribute" (các item có attribute dimension tồn tại/không null – đây là filter quan trọng).

Vấn đề: Khi số lượng user tăng, thời gian generate report kéo dài do hiện tại đang sử dụng full scan table (đọc toàn bộ bảng, bao gồm tất cả attributes, dẫn đến tiêu tốn nhiều Read Capacity Units - RCUs và thời gian cao).

Mục tiêu: Chọn TWO steps kết hợp để tối ưu thời gian report nhất, dựa trên kiến thức DynamoDB mới nhất (2024-2026): Sử dụng secondary indexes để sparse index (chỉ index items có dimension), project chỉ attributes cần (giảm dữ liệu đọc), tránh full scan table lớn. (📘 Tài liệu: DynamoDB Developer Guide - Secondary Indexes).

✅ Đáp án đúng và lý do lựa chọn

Hai đáp án đúng (chọn TWO):

• Create a global secondary index (GSI) that uses the user ID as the partition key and the dimension attribute as the sort key. Use the GSI to project the two attributes that the report generator uses to compute the sum totals.
• Modify the report generator to query the index instead of the table.

Lý do chọn (🛠️ Phân tích kỹ):
GSI cho phép tạo index bất kỳ lúc nào trên bảng partition-key-only, với PK = user ID (giống table), SK = dimension → Index sparse tự nhiên (chỉ chứa items có dimension attribute, item thiếu dimension không vào index). Project chỉ 2 attributes cần sum → Dữ liệu đọc rất nhỏ (không đọc toàn bộ attributes như table gốc).

Kết hợp query index thay vì table: Thay vì scan table lớn chậm, report giờ Query GSI với condition trên SK (dimension existence/range), tận dụng key schema để đọc nhanh cross-partition hiệu quả hơn (tránh đọc dữ liệu thừa). Thời gian giảm đáng kể khi user tăng, vì chỉ đọc items liên quan + projection tối ưu. (GSI hỗ trợ strongly consistent reads nếu cần chính xác sum).

Kết quả: Report nhanh hơn hàng chục lần, tiết kiệm RCUs/WCUs. (📘 Nguồn: GSI Sparse & Projection, cập nhật 2024).

📋 Giải thích tất cả các phương án

Dưới đây là phân tích từng lựa chọn một, giữ nguyên văn bản gốc tiếng Anh. Sử dụng ✅ đúng / ❌ sai dựa trên câu hỏi.

• ✅ Create a global secondary index (GSI) that uses the user ID as the partition key and the dimension attribute as the sort key. Use the GSI to project the two attributes that the report generator uses to compute the sum totals.
  🛠️ Đúng vì: GSI tạo được trên bảng partition-only, sparse trên dimension (chỉ index items có dimension), project chỉ 2 attrs → scan/query GSI nhỏ gọn, nhanh. Tối ưu cho filter "contain dimension attribute". (Hỗ trợ on-demand/burst capacity mới 2024).

• ❌ Create a local secondary index (LSI) that uses the user ID as the partition key and the dimension attribute as the sort key. Use the LSI to project the two attributes that the report generator uses to compute the sum totals.
  🛠️ Sai vì: LSI bắt buộc table phải có sort key (composite PK), nhưng table chỉ PK user ID → không tạo được LSI. LSI còn giới hạn 10/index/table, share RCUs với table. Không linh hoạt như GSI. (📘 Nguồn: [LSI Requirements](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/LSI chapter.html)).

• ✅ Modify the report generator to query the index instead of the table.
  🛠️ Đúng vì: Sau khi có GSI optimized (sparse + project), Query GSI với key condition (PK user ID + SK dimension exists/range) nhanh hơn scan table gốc rất nhiều. Query tận dụng index schema, consistent reads, hỗ trợ aggregation client-side hiệu quả. Giảm thời gian proportional với user growth.

• ❌ Modify the report generator to scan the index instead of the table.
  🛠️ Sai vì: Scan vẫn đọc toàn bộ index (dù sparse/project nhỏ hơn table), không tận dụng key schema → kém tối ưu hơn Query (Query filter early, ít RCUs hơn). Với user lớn, scan GSI vẫn chậm nếu không condition chặt.

• ❌ Modify the report generator to call the BatchGetItem operation.
  🛠️ Sai vì: BatchGetItem yêu cầu biết trước exact keys (user IDs của items có dimension) → report generator không có list keys sẵn (và list sẽ lớn theo user growth). Không phù hợp aggregate/filter động, giới hạn 100 items/request.

💡 Lưu ý cuối: Kết hợp GSI + Query là best practice cho read-heavy aggregate trên DynamoDB (có thể kết hợp PartiQL cho sum server-side nếu cần, nhưng client-side đủ). Nếu report real-time, cân nhắc DynamoDB Accelerator (DAX) hoặc Athena. (📘 Nguồn cập nhật 2026: DynamoDB Best Practices).

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

Câu hỏi xoay quanh một hệ thống hiện tại sử dụng single-instance Amazon DocumentDB (with MongoDB compatibility) cluster, nghĩa là chỉ có một instance chính (primary) xử lý cả read và write. Read requests chiếm 75% tổng queries, còn write requests dự kiến tăng 50% sau global release. Chuyên gia database cần thiết kế giải pháp cải thiện hiệu suất tổng thể (đặc biệt scale read và chịu tải write tăng) mà không tạo thêm overhead cho ứng dụng (không cần sửa code app để route traffic thủ công).

Mục tiêu chính:

• Scale read traffic (75%) bằng replicas.
• Xử lý write tăng mà primary không overload.
• Không overhead app: Giải pháp phải tự động, tận dụng driver MongoDB/DocumentDB (như read preference).
• DocumentDB (phiên bản mới nhất 2026): Hỗ trợ up to 15 read replicas/cluster, storage shared tự động giữa primary/replicas, multi-AZ deployment. Replicas chỉ scale read, write luôn qua primary.

✅ Đáp án đúng: Add one read replica instance. Set the read preference to secondary preferred.

Lý do lựa chọn:

• ✅ Thêm 1 read replica: Scale read traffic (75%) ngay lập tức, giảm tải primary → cải thiện performance tổng thể. Write tăng 50% vẫn xử lý tốt trên primary vì read đã offload.
• ✅ Set read preference to secondary preferred: Trong MongoDB driver (DocumentDB compatible), config này ưu tiên đọc từ secondary (replica) nếu available, fallback về primary nếu replica busy/unavailable. Không cần sửa app code → driver tự handle routing, zero overhead cho app.
• ✅ Phù hợp yêu cầu: Giải pháp đơn giản, nhanh deploy, tận dụng tính năng native DocumentDB/MongoDB. Hiệu suất cao vì replicas share storage (low replication lag ~milliseconds).
• 🛠️ Cách triển khai: Sử dụng AWS Console/CLI tạo replica (aws docdb create-db-cluster-parameter-group + connection string với readPreference=secondaryPreferred).

📋 Giải thích tất cả các phương án (đúng/sai)

• ❌ Recreate the cluster with a shared cluster volume. Add two instances to serve both read requests and write requests.
  Sai vì: DocumentDB đã có shared storage volume mặc định (không cần recreate/activate). Thêm 2 instances không scale write (write chỉ primary), chỉ scale read nhưng tốn kém downtime recreate cluster và không tối ưu (write tăng vẫn overload primary). Không giải quyết write +50%.

• ❌ Add one read replica instance. Activate a shared cluster volume. Route all read queries to the read replica instance.
  Sai vì: Shared volume đã active mặc định, không cần activate. Route all read queries yêu cầu sửa app code/driver để chỉ định endpoint replica → tạo overhead lớn (app phải manage failover, lag). Vi phạm yêu cầu "no additional application overhead". Nếu replica down, read fail hoàn toàn.

• ✅ Add one read replica instance. Set the read preference to secondary preferred.
  Đúng vì: Như giải thích trên. Driver tự động route read ưu tiên replica, fallback primary → resilient, zero app change, scale hiệu quả read/write tăng.

• ❌ Add one read replica instance. Update the application to route all read queries to the read replica instance.
  Sai vì: Thêm replica tốt, nhưng update app để route → overhead cao (sửa code, manage connection pools, endpoint replica cụ thể). Không resilient (replica fail → app crash read), vi phạm yêu cầu chính.

📘 Tài liệu tham khảo (AWS cập nhật 2026)

• Amazon DocumentDB User Guide: Read replicas & scaling – Xác nhận shared storage, up to 15 replicas.
• MongoDB Read Preference: secondaryPreferred – Tích hợp DocumentDB drivers.
• AWS Best Practices: DocumentDB performance tuning – Khuyến nghị readPreference cho zero-code-change scaling.
• CLI Example: aws docdb create-db-instance --db-instance-identifier my-replica --db-cluster-identifier my-cluster.

🛠️ Lời khuyên DevOps: Test với CloudWatch metrics (CPUUtilization, ReadIOPS), enable Performance Insights để monitor post-deploy!

🧩 Giải thích nội dung câu hỏi

Câu hỏi tập trung vào quy trình kích hoạt xác thực IAM (IAM authentication) trên một Amazon Aurora PostgreSQL DB cluster đã tồn tại. Một database specialist đã hoàn thành các bước ban đầu:

• Sửa đổi cài đặt DB cluster (ví dụ: kích hoạt tham số rds_iam=1 trong parameter group để enable IAM auth).
• Tạo IAM credentials và database credentials.
• Phân phối credentials cho người dùng phù hợp.

Bước tiếp theo cần làm là thiết lập (establish) credentials để người dùng có thể đăng nhập (log in) vào DB cluster. Đây là quy trình chuẩn của AWS cho IAM database authentication trên RDS/Aurora PostgreSQL (cập nhật đến năm 2026, hỗ trợ IAM auth với token tạm thời 15 phút, không thay đổi cơ bản từ các phiên bản trước). Mục tiêu là tạo password tạm thời an toàn từ IAM credentials, thay vì dùng password tĩnh.

📘 Tài liệu tham khảo:

• AWS RDS IAM Database Authentication
• Aurora PostgreSQL IAM Auth (xác nhận generate token là bước chính).

✅ Đáp án đúng và lý do lựa chọn

Đáp án đúng: Run the generate-db-auth-token command with the user names to generate a temporary password for the users.

Lý do:

• Sau khi enable IAM auth và cấp IAM roles/permissions (như rds-db:connect), người dùng phải sử dụng lệnh AWS CLI aws rds generate-db-auth-token để tạo token tạm thời (password) dựa trên IAM credentials của họ.
• Token này có hiệu lực 15 phút 🕐, được generate cho từng username cụ thể (ví dụ: --username myuser), và dùng làm password khi connect qua psql hoặc JDBC/ODBC.
• Đây là bước next chính xác để "establish credentials" cho login, đảm bảo an toàn cao (không lưu password lâu dài). Quy trình này không thay đổi trong các update AWS đến 2026.

🛠️ Phân tích tất cả các phương án

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng:

• Add the users' IAM credentials to the Aurora cluster parameter group.
  ❌ Sai: Parameter group chỉ dùng để cấu hình DB engine (như enable rds_iam=1), không lưu trữ hoặc thêm IAM credentials của users. Việc thêm credentials vào đây sẽ không hợp lệ, gây lỗi bảo mật và không hỗ trợ quy trình IAM auth. AWS không cho phép thao tác này.

• Run the generate-db-auth-token command with the user names to generate a temporary password for the users.
  ✅ Đúng: Như đã giải thích ở trên, đây là lệnh chuẩn aws rds generate-db-auth-token --hostname <endpoint> --port 5432 --region <region> --username <user>. Token tạo ra chính là password tạm thời để login, hoàn hảo khớp với bước "establish credentials".

• Add the users' IAM credentials to the default credential profile, Use the AWS Management Console to access the DB cluster.
  ❌ Sai: AWS Management Console không hỗ trợ truy cập trực tiếp DB cluster qua IAM (chỉ dùng cho quản lý RDS, không phải query database). Thêm credentials vào profile (~/.aws/credentials) chỉ dùng cho AWS CLI/API, không "access DB cluster" trực tiếp.

• Use an AWS Security Token Service (AWS STS) token by sending the IAM access key and secret key as headers to the DB cluster API endpoint.
  ❌ Sai: IAM auth cho RDS/Aurora KHÔNG dùng STS token hoặc gửi access/secret key qua headers. Thay vào đó, dùng generate-db-auth-token để tạo token từ IAM. Gửi key trực tiếp sẽ lộ thông tin nhạy cảm và bị AWS chặn (không phải API endpoint chuẩn cho DB connect).

Tóm tắt nhanh 📝: Chỉ phương án generate token mới đúng quy trình AWS IAM DB auth. Các phương án sai lẫn lộn khái niệm parameter, console, hoặc STS không liên quan! Nếu implement, test bằng AWS CLI để verify. 🚀