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

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

Câu hỏi tập trung vào bảo mật của một cụm Amazon Aurora MySQL DB cluster gồm ba node (thường bao gồm một writer instance và hai reader instances để đảm bảo high availability và scalability). Công ty phần mềm đang thực hiện kiểm toán bảo mật (security audit) và cần xác định tìm thấy (finding) nào là mối lo ngại bảo mật thực sự cần khắc phục.

🛠️ Bối cảnh chính: Aurora là dịch vụ RDS managed, hỗ trợ clustering đa-AZ với automatic backups, replication, và các tính năng bảo mật như encryption at rest/transit, IAM authentication, VPC isolation. Audit sẽ kiểm tra các best practices theo AWS Well-Architected Framework (Security Pillar), bao gồm least privilege, credential rotation, network isolation, và encryption. Kiến thức dựa trên tài liệu AWS cập nhật đến 2026 (Aurora MySQL version 3.x, IAM với automatic rotation via Secrets Manager).

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

• AWS Aurora Security Best Practices: docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Aurora.Overview.Security.html
• IAM Credential Management: docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
• AWS Security Best Practices Whitepaper (2024 update).

✅ Đáp án đúng

The IAM credentials used by the application are not rotated regularly.

Lý do lựa chọn:

• Đây là best practice cốt lõi của AWS IAM (Principle of Least Privilege và Temporary Credentials). IAM credentials (access keys, secrets) của ứng dụng kết nối Aurora (qua IAM database authentication hoặc RDS Proxy) phải được rotate định kỳ (ít nhất 90 ngày hoặc tự động qua AWS Secrets Manager) để giảm rủi ro nếu bị lộ (compromised keys).
• Trong audit bảo mật, việc không rotate là vi phạm nghiêm trọng, có thể dẫn đến unauthorized access. Aurora hỗ trợ IAM auth từ 2019 và khuyến nghị rotation từ 2023+ với Secrets Manager integration (cập nhật 2026 vẫn giữ nguyên).
• Các lựa chọn khác không phải concern thực tế hoặc không đúng với architecture Aurora.

📋 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 phương án giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích đúng/sai bằng tiếng Việt dựa trên kiến thức AWS mới nhất:

• The AWS account root user does not have the minimum privileges required for client applications.
  ❌ Sai: Root user KHÔNG NÊN được dùng cho client applications hoặc bất kỳ hoạt động hàng ngày nào (AWS khuyến cáo "Never use root" trừ admin cơ bản). Client apps phải dùng IAM roles/users với least privilege (ví dụ: IAM DB auth cho Aurora). Root luôn có full privileges, nên "not minimum" là bình thường và an toàn. Không phải concern.

• Encryption in transit is not configured for all Aurora native backup processes.
  ❌ Sai: Aurora mặc định hỗ trợ encryption in transit qua TLS 1.2+ cho tất cả connections (bao gồm backups tự động snapshot export to S3). Native backups encrypted at rest nếu DB enabled KMS, và transit qua HTTPS/S3 secure endpoints. Từ 2023, Aurora tự động enforce TLS; không cần config riêng cho backups. Đây không phải lỗ hổng thực tế.

• Each Aurora DB cluster node is not in a separate private VPC with restricted access.
  ❌ Sai: Aurora cluster PHẢI nằm trong CÙNG một VPC và DB Subnet Group (multi-AZ subnets) để replication và failover hoạt động. Không thể tách mỗi node ra VPC riêng (vi phạm cluster architecture). Thay vào đó, dùng private subnets với Security Groups/NACLs restricted là đủ. Separate VPC per node là không khả thi và không khuyến nghị.

• The IAM credentials used by the application are not rotated regularly.
  ✅ Đúng: Như giải thích trên, rotation định kỳ là bắt buộc theo AWS IAM best practices (rotate every 90 days hoặc tự động). Application dùng IAM để connect Aurora (IAM auth) phải rotate để tránh long-lived credentials bị exploit. Secrets Manager hỗ trợ automatic rotation cho RDS/Aurora từ 2021, cập nhật 2026 với enhanced auditing qua IAM Access Analyzer.

🛡️ Khuyến nghị khắc phục tổng quát: Sử dụng IAM roles thay access keys, enable Secrets Manager rotation, và audit qua AWS Config/GuardDuty để theo dõi compliance.

🧩 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 vô tình xóa AWS CloudFormation stack chứa Amazon RDS DB instance, dẫn đến mất dữ liệu gần đây. Chuyên gia database cần sửa template CloudFormation cho resource RDS để giảm thiểu rủi ro mất dữ liệu ngẫu nhiên trong tương lai.
Yêu cầu chọn 3 hành động kết hợp (combination of actions) từ các lựa chọn, áp dụng vào template CloudFormation cho RDS.
📘 Kiến thức cốt lõi (cập nhật AWS 2023-2026): CloudFormation quản lý lifecycle resource qua DeletionPolicy (Retain/Snapshot/Delete), và RDS có properties riêng như DeletionProtection (ngăn xóa DB) và DeleteAutomatedBackups (quản lý backup tự động). Không có thay đổi lớn ở phiên bản mới nhất (CloudFormation spec RDS 2024+).

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

Các đáp án đúng là:

1. Set the DeletionProtection property to True 🛡️
2. Set the DeleteAutomatedBackups property to False 💾
3. Set the DeletionPolicy attribute to Retain 🔒

Lý do chọn bộ 3 này (kết hợp hoàn hảo):

• DeletionProtection=True: Ngăn RDS bị xóa khi stack delete/update, yêu cầu phải disable trước (force manual step, tránh tai nạn).
• DeleteAutomatedBackups=False: Giữ lại automated backups sau khi RDS xóa (có thể restore từ backup).
• DeletionPolicy=Retain: CloudFormation giữ RDS instance nguyên vẹn khi stack delete (không xóa DB).
  🛠️ Kết hợp chúng tạo lớp bảo vệ đa tầng: Prevent delete (DeletionProtection) + Keep resource (Retain) + Keep backups (False). Giảm 100% rủi ro mất data ngẫu nhiên!

📋 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 (giữ nguyên văn bản gốc tiếng Anh). Tôi đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do bằng tiếng Việt rõ ràng:

• Set the DeletionProtection property to True.
  ✅ Đúng: Property của RDS (AWS::RDS::DBInstance). Khi true, RDS không cho phép xóa qua CloudFormation stack delete/update, phải disable thủ công trước. Giảm tai nạn 100%. (Nguồn: AWS RDS CloudFormation Docs).

• Set the MultiAZ property to True.
  ❌ Sai: Property MultiAZ=true chỉ kích hoạt high availability (failover standby ở AZ khác), không liên quan bảo vệ xóa. Chỉ giúp recover disaster, không ngăn stack delete. (Nguồn: AWS RDS Multi-AZ Docs).

• Set the TerminationProtection property to True.
  ❌ Sai: Property TerminationProtection chỉ dành cho EC2 Instance (AWS::EC2::Instance), không áp dụng RDS. RDS dùng DeletionProtection. Lỗi phổ biến nhầm lẫn resource type. (Nguồn: AWS EC2 TerminationProtection Docs).

• Set the DeleteAutomatedBackups property to False.
  ✅ Đúng: Property RDS, khi false, giữ lại tất cả automated backups sau khi DB xóa (14 ngày retention). Có thể restore DB mới từ backup, cứu data mất. (Nguồn: AWS RDS CloudFormation DeleteAutomatedBackups).

• Set the DeletionPolicy attribute to No.
  ❌ Sai: Không tồn tại giá trị No cho DeletionPolicy (options: Delete/default, Retain, Snapshot). No vô hiệu, CloudFormation sẽ xóa DB bình thường. (Nguồn: CloudFormation DeletionPolicy Docs).

• Set the DeletionPolicy attribute to Retain.
  ✅ Đúng: Attribute CloudFormation cho bất kỳ resource nào (bao gồm RDS). Khi stack delete, RDS được giữ nguyên (chuyển sang manual management), data an toàn. Phải delete thủ công sau. (Nguồn: CloudFormation DeletionPolicy Retain).

🏆 Kết luận & Tips DevOps

Bộ 3 ✅ tạo defense-in-depth cho RDS trong CloudFormation! Test bằng aws cloudformation create-stack + delete-stack để verify.
📘 Tài liệu tham khảo chính:

• AWS CloudFormation RDS Template Reference (2024).
• Best Practices: Protect Resources.
  Nếu cần template mẫu, hỏi thêm nhé! 🚀

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

Câu hỏi mô tả một công ty có văn phòng chi nhánh tại United States và Singapore, triển khai ứng dụng web 3-tier (presentation, application, data layer) sử dụng shared database trên Amazon RDS for MySQL ở region us-west-2. Phần front-end được phân tán ở us-west-2 (US) và ap-southeast-1 (Singapore), dùng làm dashboard hiển thị thống kê cho sales managers.
Vấn đề: Dashboard load chậm hơn ở Singapore so với US do latency cao khi truy vấn database từ xa (cross-region).
Yêu cầu: Giải pháp meet requirements (load consistent ở cả hai location) theo cách MOST operationally efficient (hiệu quả vận hành cao nhất: ít công sức quản lý, tự động hóa cao, chi phí thấp, dễ scale).
🛠️ Key points: Dashboard chủ yếu read-only (statistics), nên ưu tiên read scaling. RDS MySQL hỗ trợ cross-region read replicas (tính năng ổn định đến 2026, AWS RDS Multi-Region).

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

Đáp án đúng: Create an RDS read replica in ap-southeast-1 from the primary DB instance in us-west-2. Reconfigure the ap-southeast-1 front-end dashboard to access the read replica.

Lý do:

• ✅ Giảm latency tối ưu: Read replica cross-region (us-west-2 → ap-southeast-1) cho phép front-end Singapore đọc dữ liệu gần nhất, load dashboard nhanh và consistent. Replication asynchronous, tự động sync từ primary (lag thấp ~giây).
• ✅ Operationally efficient nhất: Tạo replica chỉ 1 click qua AWS Console/CLI, không cần tool ngoài, tự động failover/promote nếu cần, scale reads dễ dàng. Phù hợp read-heavy workload như dashboard.
• ✅ Không ảnh hưởng writes: Primary ở us-west-2 vẫn handle writes từ US front-end.
• 🛠️ Cập nhật 2026: RDS hỗ trợ cross-region replicas cho MySQL với performance insights và global databases optional, nhưng replica đơn giản đủ cho case này.

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

Dưới đây là giải thích chi tiết từng lựa chọn (giữ nguyên văn bản gốc), đánh dấu đúng/sai và lý do bằng tiếng Việt:

• ❌ [SAI] Take a snapshot of the DB instance in us-west-2. Create a new DB instance in ap-southeast-2 from the snapshot. Reconfigure the ap-southeast-1 front-end dashboard to access the new DB instance.
  Lý do sai: Snapshot chỉ one-time copy, không sync real-time → dữ liệu Singapore lạc hậu (statistics không consistent). Sai region (ap-southeast-2 thay vì ap-southeast-1). Phức tạp: manual restore + reconfigure app + không scale reads tự động. Không efficient, dễ lỗi vận hành.

• ✅ [ĐÚNG] Create an RDS read replica in ap-southeast-1 from the primary DB instance in us-west-2. Reconfigure the ap-southeast-1 front-end dashboard to access the read replica.
  (Đã giải thích chi tiết ở phần trên – giải pháp tối ưu nhất).

• ❌ [SAI] Create a new DB instance in ap-southeast-1. Use AWS Database Migration Service (AWS DMS) and change data capture (CDC) to update the new DB instance in ap-southeast-1. Reconfigure the ap-southeast-1 front-end dashboard to access the new DB instance.
  Lý do sai: DMS + CDC phức tạp cao (setup tasks, endpoints, monitoring lag), chi phí DMS cao hơn replica native. Không operationally efficient (cần quản lý ongoing sync, handle failures). RDS replica built-in đơn giản hơn, tự động hơn.

• ❌ [SAI] Create an RDS read replica in us-west-2, where the primary DB instance resides. Create a read replica in ap-southeast-1 from the read replica in us-west-2. Reconfigure the ap-southeast-1 front-end dashboard to access the read replica in ap-southeast-1.
  Lý do sai: Chaining replicas (us-west-2 → us-west-2 → ap-southeast-1) tăng replication lag (dữ liệu chậm hơn), không cần thiết vì RDS hỗ trợ direct cross-region replica. Phức tạp + kém efficient (quản lý 2 replicas thay vì 1), tăng chi phí.

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

• AWS RDS Read Replicas: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html (Cross-Region Replication section).
• RDS Multi-AZ & Global: https://aws.amazon.com/rds/features/multi-az/ (Read replicas for low-latency reads).
• AWS DOP-C02 Exam Guide: Topic "Database services" – ưu tiên native features cho efficiency.
• Best Practices: AWS Well-Architected Framework – Reliability Pillar: Sử dụng read replicas cho read scaling cross-region.

Giải pháp này đảm bảo high availability, low latency và minimal ops overhead! 🚀

🧩 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ế trong AWS ElastiCache for Redis: Một công ty sử dụng cluster Redis để lưu trữ dữ liệu cho website mua sắm trực tuyến. Khi ứng dụng của website thực hiện truy vấn (query) vào cluster, người dùng (shoppers) gặp lỗi OOM (Out of Memory) với thông báo cụ thể:

OOM command not allowed when used memory > 'maxmemory'

🔍 Phân tích lỗi:

• Đây là lỗi phổ biến ở Redis khi bộ nhớ đã sử dụng (used memory) vượt quá giới hạn maxmemory được cấu hình trên node. Redis sẽ từ chối các lệnh ghi mới (như SET, APPEND) để tránh crash, nhưng vẫn cho phép đọc.
• Nguyên nhân chính: Dữ liệu tích tụ quá nhanh (keys với TTL cao hoặc không expire), node type nhỏ không đủ memory, hoặc chính sách eviction (maxmemory-policy) chưa tối ưu.
• Yêu cầu: Chọn 3 giải pháp giải quyết vấn đề memory với LEAST amount of effort (ít nỗ lực nhất, ưu tiên thay đổi đơn giản, không code phức tạp hay refactor lớn).
• Bối cảnh AWS cập nhật 2026: ElastiCache hỗ trợ Redis lên đến phiên bản 7.1 (hoặc mới hơn), với các tính năng như cluster mode, auto-scaling, và parameter groups linh hoạt cho maxmemory-policy (eviction policies như allkeys-lru, volatile-ttl).

📘 Đáp án đúng (chọn THREE)

✅ Reduce the TTL value for keys on the node.
✅ Choose a larger node type.
✅ Test different values in the parameter group for the maxmemory-policy parameter to find the ideal value to use.

Lý do chọn: Những giải pháp này đơn giản nhất (least effort): Chỉ cần chỉnh TTL ứng dụng, scale up node type qua console/CLI, hoặc test parameter group mà không cần code thêm, refactor dữ liệu lớn hay theo dõi phức tạp. Chúng trực tiếp giải quyết OOM bằng cách giảm sử dụng memory, tăng dung lượng, hoặc tự động evict keys.

🛠️ Phân tích chi tiết từng phương án

Dưới đây là phân tích tất cả 6 phương án, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng, ít effort) hoặc ❌ (sai, không hiệu quả/nhiều effort hơn), kèm giải thích chi tiết bằng tiếng Việt dựa trên docs AWS ElastiCache Redis mới nhất.

• ✅ Reduce the TTL value for keys on the node.
  🟢 Đúng và ít effort nhất: Giảm TTL (Time To Live) làm keys tự động expire nhanh hơn, giải phóng memory ngay lập tức mà không mất dữ liệu quan trọng. Chỉ cần chỉnh code ứng dụng khi set keys (EXPIRE command). Không cần thay đổi hạ tầng.
  💡 Hiệu quả cao: Phù hợp cho shopping cache (session, cart) thường không cần lưu lâu.

• ✅ Choose a larger node type.
  🟢 Đúng và ít effort: Scale up node type (ví dụ từ cache.t4g.micro lên cache.m6g.large) tăng maxmemory ngay lập tức qua AWS Console/CLI/API, chỉ mất vài phút downtime thấp (với Multi-AZ). Không cần thay đổi code.
  💡 Least effort: ElastiCache hỗ trợ online scale-up từ Redis 5.0+.

• ✅ Test different values in the parameter group for the maxmemory-policy parameter to find the ideal value to use.
  🟢 Đúng và ít effort: Thay đổi maxmemory-policy trong Parameter Group (như từ noeviction sang allkeys-lru hoặc volatile-ttl) để Redis tự động evict keys cũ/LRU khi gần maxmemory, tránh OOM hoàn toàn. Test qua dev cluster, apply production chỉ 1 click, không downtime nếu default group.
  💡 Tối ưu: AWS khuyến nghị volatile-lru cho mixed workload (docs 2026).

• ❌ Increase the number of nodes.
  🔴 Sai: Scale out (tăng shards/nodes) phân tán dữ liệu nhưng không giải quyết OOM trên node cá nhân nếu workload vẫn nhồi dữ liệu vào một node (hash slot imbalance). Effort cao hơn: Cần enable cluster mode, resharding dữ liệu, có thể gây downtime/performance dip. Không least effort so với scale up.

• ❌ Monitor the EngineCPUUtilization Amazon CloudWatch metric. Create an AWS Lambda function to delete keys on nodes when a threshold is reached.
  🔴 Sai và effort cao: Metric sai (EngineCPUUtilization là CPU, không phải memory – dùng EngineMemoryUsage hoặc FreeableMemory thay thế). Tạo Lambda + EventBridge scan/delete keys phức tạp, rủi ro mất dữ liệu, không scale, vi phạm least effort. AWS khuyên dùng built-in eviction thay vì custom script.

• ❌ Increase the TTL value for keys on the node.
  🔴 Sai hoàn toàn: Tăng TTL làm keys sống lâu hơn, tích tụ memory nhiều hơn, dẫn đến OOM thường xuyên hơn. Ngược lại với giải pháp đúng (reduce TTL). Effort vô ích và làm tình hình tệ đi.

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

• ElastiCache for Redis: Memory Management & Evictions 🛡️ – Chi tiết OOM và maxmemory-policy.
• Scaling ElastiCache Nodes 📈 – Scale up/down với least effort.
• Redis Parameters: maxmemory & TTL ⚙️ – Parameter groups cho policy.
• CloudWatch Metrics for ElastiCache 📊 – EngineMemoryUsage là key metric.

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ụ code Terraform/CLI, hỏi thêm nhé.

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

Câu hỏi xoay quanh tình huống một công ty đang sử dụng Microsoft SQL Server trên Amazon RDS với cấu hình Multi-AZ làm cơ sở dữ liệu cho ứng dụng. Sau khi bị sáp nhập, chuyên viên cơ sở dữ liệu cần đổi tên database để tuân thủ chuẩn đặt tên mới.
Vấn đề chính: RDS không hỗ trợ đổi tên database trực tiếp qua console hoặc CLI thông thường. Thay vào đó, phải sử dụng stored procedure đặc biệt rdsadmin.dbo.rds_modify_db_name dành riêng cho SQL Server trên RDS. Tuy nhiên, quy trình này có các ràng buộc nghiêm ngặt (như phải tắt Multi-AZ trước), và sau khi đổi tên, ứng dụng cần được cập nhật để kết nối đúng.
Câu hỏi yêu cầu chọn TWO (2) bước kết hợp để thực hiện an toàn, dựa trên best practices của AWS RDS (cập nhật đến 2026, theo RDS User Guide phiên bản mới nhất hỗ trợ SQL Server 2019+ và tính năng mirroring).

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

Hai lựa chọn đúng là:

1. Turn off Multi-AZ for the DB instance. Rename the database with the rdsadmin.dbo.rds_modify_db_name stored procedure. Turn on Multi-AZ Mirroring.
2. Update the application with the new database connection string.

Lý do lựa chọn:

• RDS SQL Server không cho phép rename database khi Multi-AZ đang bật vì mirroring yêu cầu đồng bộ hóa tức thì giữa primary và standby. Phải tắt Multi-AZ → rename → bật lại mirroring để đảm bảo tính sẵn sàng cao mà không mất dữ liệu.
• Sau rename, tên database thay đổi (ví dụ: từ "old_db" thành "new_db"), nên connection string trong ứng dụng phải cập nhật (thay Initial Catalog/Database=) để tránh lỗi kết nối. Đây là bước bắt buộc cho ứng dụng hoạt động bình thường.
  Quy trình này đảm bảo zero-downtime tối thiểu, an toàn và tuân thủ AWS best practices.

🔍 Phân tích tất cả các phương án (Đúng/Sai)

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á dựa trên tài liệu AWS RDS chính thức (không có thay đổi lớn đến 2026).

• ✅ Đúng: Turn off Multi-AZ for the DB instance. Rename the database with the rdsadmin.dbo.rds_modify_db_name stored procedure. Turn on Multi-AZ Mirroring.
  🛠️ Giải thích: Đây là quy trình chuẩn cho RDS SQL Server Multi-AZ. Tắt Multi-AZ để tránh xung đột mirroring (stored procedure yêu cầu DB instance ở chế độ single-AZ tạm thời). Sau rename, bật lại Multi-AZ Mirroring (tính năng mirroring SQL Server trên RDS) để khôi phục HA. Không gây downtime dài, chỉ failover ngắn.

• ❌ Sai: Turn off automatic snapshots for the DB instance. Rename the database with the rdsadmin.dbo.rds_modify_db_name stored procedure. Turn on the automatic snapshots.
  🧩 Giải thích: Không cần tắt/tắt snapshots tự động. Stored procedure rename không bị ảnh hưởng bởi snapshots; AWS khuyến cáo giữ snapshots để bảo vệ dữ liệu. Tắt chúng chỉ tăng rủi ro mất backup, không giải quyết vấn đề Multi-AZ – nguyên nhân chính cản trở rename.

• ❌ Sai: Delete all existing snapshots for the DB instance. Use the rdsadmin.dbo.rds_modify_db_name stored procedure.
  🛠️ Giải thích: Xóa snapshots là hành động nguy hiểm và không cần thiết. Rename không yêu cầu xóa snapshot (manual hay auto); RDS vẫn tạo snapshot mới sau thay đổi. Việc xóa có thể vi phạm compliance và mất khả năng restore, vi phạm nguyên tắc "least privilege" của AWS.

• ✅ Đúng: Update the application with the new database connection string.
  🧩 Giải thích: Bắt buộc phải cập nhật vì rename chỉ thay tên logical database bên trong instance. Endpoint RDS (DNS) không đổi, nhưng connection string (ví dụ: Server=endpoint;Database=new_name;) phải chỉnh sửa trong code/app config. Nếu không, app sẽ lỗi "Database not found".

• ❌ Sai: Update the DNS record for the DB instance.
  🛠️ Giải thích: Không cần và không nên chỉnh DNS. RDS endpoint (DNS record) là immutable và chỉ thay đổi khi scale/replace instance. Rename database không ảnh hưởng endpoint; chỉnh thủ công có thể gây downtime toàn bộ kết nối.

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

• AWS RDS User Guide - Renaming a DB instance: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_RenameDBInstance.html (SQL Server section).
• Stored Procedure rdsadmin: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/SQLServer.Procedural.RenameDB.html (yêu cầu: Tắt Multi-AZ, no read replicas).
• Multi-AZ for SQL Server: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html#Concepts.MultiAZ.Mirroring (Mirroring mode).
• Best Practices: AWS Well-Architected Framework - Reliability Pillar (RDS HA).

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ụ code SQL, hãy hỏi nhé!

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

Câu hỏi tập trung vào việc di chuyển (migrate) một cơ sở dữ liệu Microsoft SQL Server Enterprise edition dung lượng lớn 20 TB từ on-premises sang Amazon RDS for SQL Server. Các đặc điểm nổi bật:

• Database có Transparent Data Encryption (TDE) enabled (mã hóa dữ liệu tại chỗ).
• Bao gồm sparse tables (bảng thưa, chứa nhiều giá trị NULL để tối ưu lưu trữ).
• Phải thực hiện trong maintenance window cuối tuần (thời gian bảo trì ngắn, cần phương pháp nhanh chóng).
• Yêu cầu bắt buộc: Bật data-at-rest encryption (mã hóa dữ liệu tại chỗ) trên DB instance RDS đích.
• Mục tiêu: Chọn TWO steps theo cách MOST operationally efficient (hiệu quả vận hành nhất), nghĩa là nhanh, ít bước, tận dụng tính năng AWS native, phù hợp với quy mô lớn 20 TB.

Vấn đề cốt lõi: Với TDE enabled trên source, backup sẽ được mã hóa → không thể restore trực tiếp lên RDS trừ khi xử lý đúng cách. RDS for SQL Server hỗ trợ TDE (từ phiên bản mới nhất 2024-2026), nhưng migrate large DB cần backup/restore qua S3 để nhanh và scalable. DMS hoặc Snowball không phải lựa chọn tối ưu cho one-time migrate lớn trong thời gian ngắn.

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

• AWS RDS for SQL Server User Guide: Migrating SQL Server databases to RDS (cập nhật 2025).
• AWS DMS Limitations: SQL Server as source (không hỗ trợ full offline migrate với TDE + sparse tables hiệu quả).
• TDE on RDS: Encryption at rest.

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

Hai phương án đúng là sự kết hợp hiệu quả nhất cho migrate large DB offline trong maintenance window:

1. Disable TDE. Create a database backup without encryption. Copy the backup to Amazon S3.
   🛠️ Lý do: Disable TDE tạm thời để tạo backup không mã hóa → dễ copy lên S3 (nhanh với high-throughput S3 Transfer Acceleration). Phù hợp 20 TB, tránh overhead của DMS. Sau backup, có thể re-enable TDE on-premises nếu cần.

2. Restore the backup to the RDS for SQL Server DB instance. Enable TDE for the RDS for SQL Server DB instance.
   🛠️ Lý do: RDS hỗ trợ native restore backup SQL Server từ S3. Sau restore, enable TDE trên RDS (sử dụng AWS KMS key) để đáp ứng data-at-rest encryption. Toàn bộ quá trình nhanh, không cần tool trung gian.

Kết hợp hai bước này: Backup → S3 → Restore + TDE → Hoàn thành trong cuối tuần, scalable cho 20 TB (S3 multipart upload nhanh).

📋 Giải thích TẤT CẢ các phương án (Đúng/Sai)

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

• ✅ Disable TDE. Create a database backup without encryption. Copy the backup to Amazon S3.
  🛠️ Đúng vì: Đây là bước chuẩn cho migrate TDE-enabled DB sang RDS. Disable TDE (qua SQL command ALTER DATABASE ... SET ENCRYPTION OFF) tạo backup plain-text → upload S3 nhanh (20 TB chỉ vài giờ với AWS CLI/S3 Express One Zone). Tránh conflict mã hóa giữa source/target.

• ✅ Restore the backup to the RDS for SQL Server DB instance. Enable TDE for the RDS for SQL Server DB instance.
  🛠️ Đúng vì: RDS SQL Server hỗ trợ rds-restore-from-s3 option group để restore trực tiếp từ S3. Sau restore, enable TDE qua console/CLI (ModifyDBInstance với TDE enabled + KMS key). Đáp ứng encryption yêu cầu, hỗ trợ sparse tables native.

• ❌ Use AWS Database Migration Service (AWS DMS) to migrate from the on-premises source database to the RDS for SQL Server target database.
  🧨 Sai vì: DMS phù hợp ongoing replication/homogeneous migrate nhỏ, nhưng KHÔNG efficient cho 20 TB one-time offline migrate. Limitations: Không hỗ trợ TDE trực tiếp (phải decrypt trước), sparse tables cần full load gây chậm (initial load >24h), overhead agent cao trong maintenance window ngắn. Best practice: Dùng backup/restore thay DMS cho large DB.

• ❌ Set up an AWS Snowball Edge device. Copy the database backup to the device. Send the device to AWS. Restore the database from Amazon S3.
  🚫 Sai vì: Snowball dành cho petabyte-scale data (>100 TB) hoặc network kém. Với 20 TB, upload trực tiếp S3 nhanh hơn (Snowball mất 1-2 tuần ship). Không "operationally efficient" cho cuối tuần – quá chậm!

• ❌ Encrypt the data with client-side encryption before transferring the data to Amazon RDS.
  🚫 Sai vì: Client-side encryption (SSE-C/KMS) không áp dụng cho DB backup restore. RDS yêu cầu native TDE/SQL Server backup format. Encrypt trước gây double-encryption, không restore được → phức tạp, không scalable cho 20 TB.

Kết luận 💡: Kết hợp hai bước ✅ là native, nhanh nhất (backup ~4-6h, S3 copy ~2h, restore ~4h cho 20 TB trên instance lớn như r6i.24xlarge). Test trước trên staging để đảm bảo! Nếu cần hỗ trợ thêm, hỏi nhé! 🛠️

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

Câu hỏi xoay quanh tình huống một database specialist muốn đảm bảo Amazon Aurora DB cluster luôn được tự động nâng cấp lên phiên bản minor mới nhất có sẵn. Họ nhận thấy có minor version mới và đã chạy AWS CLI command để kích hoạt automatic minor version updates. Lệnh chạy thành công, nhưng khi kiểm tra cluster, không có cập nhật version nào xảy ra.
Vấn đề cốt lõi: Tại sao cluster chưa được nâng cấp dù đã enable auto-upgrade? (Chọn hai lý do có thể).
📘 Kiến thức nền tảng AWS Aurora (cập nhật đến 2026):

• Auto minor version upgrade chỉ kích hoạt khi minor version mới được AWS designate as "preferred minor version" (phiên bản ưu tiên). Không phải minor mới nào cũng tự động là preferred – AWS phải công bố chính thức.
• Lệnh aws rds modify-db-cluster với --auto-minor-version-upgrade enabled chỉ enable tính năng, không tự động upgrade ngay. Upgrade chỉ xảy ra trong maintenance window tiếp theo nếu version là preferred.
• Để apply thay đổi ngay lập tức, cần --apply-immediately. Nếu thiếu, thay đổi pending đến maintenance window.
  Nguồn: AWS Docs - Managing minor version upgrades in Aurora và RDS CLI Reference - modify-db-cluster (xác nhận tính năng không thay đổi đến 2026).

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

Dưới đây là hai lý do chính xác giải thích tại sao cluster chưa update version dù lệnh CLI thành công:

• The new minor version has not yet been designated as preferred and requires a manual upgrade.
  🛠️ Lý do: Auto-upgrade chỉ áp dụng cho preferred minor version do AWS chỉ định. Minor mới có thể available nhưng chưa preferred → cần manual upgrade qua modify-db-cluster --engine-version.
• The AWS CLI command did not include an apply-immediately parameter.
  🛠️ Lý do: Lệnh modify-db-cluster thiếu --apply-immediately → thay đổi auto_minor_version_upgrade=enabled chỉ pending đến maintenance window tiếp theo, chưa kích hoạt ngay. Do đó, chưa có upgrade version.

📋 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 cách chi tiết, giữ nguyên văn bản gốc (tiếng Anh). Sử dụng ✅ cho đúng, ❌ cho sai:

• The new minor version has not yet been designated as preferred and requires a manual upgrade.
  ✅ Đúng. Như đã giải thích, AWS phải designate preferred trước khi auto-upgrade chạy (thường trong maintenance window). Minor mới chưa preferred → không tự động, cần manual.
  Nguồn: AWS Blog - Aurora Preferred Minor Versions (cập nhật 2023, vẫn áp dụng 2026).

• Configuring automatic upgrades using the AWS CLI is not supported. This must be enabled expressly using the AWS Management Console.
  ❌ Sai. AWS CLI hỗ trợ đầy đủ qua modify-db-cluster --auto-minor-version-upgrade enabled. Console chỉ là UI wrapper, CLI tương đương và được khuyến nghị cho automation.
  Nguồn: AWS CLI Docs (xem trên).

• Applying minor version upgrades requires sufficient free space.
  ❌ Sai. Minor upgrades là in-place, non-disruptive (không copy data lớn), không yêu cầu free space đặc biệt ngoài storage thông thường. Nếu thiếu, RDS báo lỗi trước khi apply, nhưng không phải lý do mặc định.
  Nguồn: RDS Best Practices - Storage.

• The AWS CLI command did not include an apply-immediately parameter.
  ✅ Đúng. Thiếu --apply-immediately → enable chỉ pending, cluster chưa nhận thay đổi ngay → không upgrade version dù minor available.
  Nguồn: CLI Reference (xem trên) – --apply-immediately kiểm soát apply ngay hay deferred.

• Aurora has detected a breaking change in the new minor version and has automatically rejected the upgrade.
  ❌ Sai. Minor versions được AWS thiết kế backwards-compatible, không breaking changes. Nếu có issue lớn, AWS không release minor mà làm patch hoặc major. Không có cơ chế "auto-reject" như vậy.
  Nguồn: Aurora Release Notes – Minor luôn safe cho auto-upgrade nếu preferred.

🧠 Lời khuyên DevOps: Để upgrade ngay, dùng modify-db-cluster --engine-version <new-version> --apply-immediately. Theo dõi preferred versions qua AWS Console hoặc notifications! 🚀

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

Câu hỏi mô tả một tình huống bảo mật nghiêm trọng trong môi trường AWS: Nhóm bảo mật của công ty tài chính phát hiện credentials (tài khoản/mật khẩu) của cơ sở dữ liệu Amazon RDS for MySQL bị hardcode trực tiếp vào source code. Source code này được lưu trữ ở vị trí chia sẻ, dùng cho triển khai tự động, và bị lộ cho tất cả người dùng có quyền truy cập vị trí đó.
📌 Yêu cầu chính: Chuyên gia cơ sở dữ liệu phải sử dụng encryption (mã hóa) để đảm bảo credentials KHÔNG còn visible (hiển thị rõ ràng) trong source code.
🛠️ Mục tiêu: Loại bỏ việc hardcode credentials, thay bằng cách lưu trữ an toàn, mã hóa, và truy cập động (không lưu plaintext trong code). Điều này tuân thủ nguyên tắc least privilege và secrets management theo best practices AWS (cập nhật đến 2026, với SSM Parameter Store hỗ trợ tích hợp IAM roles và KMS keys mạnh mẽ hơn).

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

Đáp án đúng:
Store the credentials in an AWS Systems Manager Parameter Store secure string parameter that is encrypted by AWS Key Management Service (AWS KMS). Access the credentials with calls to Systems Manager.

Lý do chi tiết:

• Phương án này trực tiếp giải quyết vấn đề: Di chuyển credentials ra khỏi source code, lưu vào AWS Systems Manager (SSM) Parameter Store dưới dạng Secure String (plaintext được AWS tự động mã hóa bằng KMS key).
• Truy cập động: Ứng dụng gọi API SSM (qua SDK hoặc CLI) để lấy credentials tại runtime, không cần hardcode.
• ✅ An toàn cao: Hỗ trợ KMS customer-managed keys, tích hợp IAM policies để kiểm soát truy cập chi tiết (ví dụ: chỉ EC2 role hoặc Lambda function được phép). Không lộ trong source code chia sẻ.
• 🆕 Cập nhật 2026: SSM Parameter Store nay hỗ trợ hierarchical parameters và automatic rotation với RDS integration, phù hợp DevOps Professional.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên yêu cầu câu hỏi (xử lý credentials trong source code, không phải dữ liệu DB).

• ❌ SAI - Use an AWS Key Management Service (AWS KMS) key to encrypt the most recent database backup. Restore the backup as a new database to activate encryption.
  Giải thích: Phương án này chỉ mã hóa backup và restore DB instance mới (enable at-rest encryption cho RDS data). Không liên quan đến credentials trong source code – credentials vẫn hardcode và lộ. RDS encryption bảo vệ dữ liệu DB, không phải secrets management.

• ❌ SAI - Store the source code to access the credentials in an AWS Systems Manager Parameter Store secure string parameter that is encrypted by AWS Key Management Service (AWS KMS). Access the code with calls to Systems Manager.
  Giải thích: Không logic: Lưu toàn bộ source code vào SSM Parameter Store? Parameter Store dành cho small secrets/configs (giới hạn 4KB-8KB), không phải source code lớn. Vẫn không giải quyết hardcode credentials – chỉ di chuyển code chứa secrets lộ. Sai ngữ cảnh hoàn toàn.

• ✅ ĐÚNG - Store the credentials in an AWS Systems Manager Parameter Store secure string parameter that is encrypted by AWS Key Management Service (AWS KMS). Access the credentials with calls to Systems Manager.
  Giải thích: Như đã nêu ở phần đáp án đúng. Hoàn hảo khớp yêu cầu: Credentials được mã hóa riêng (Secure String + KMS), source code sạch sẽ chỉ gọi SSM API. Tích hợp dễ với CI/CD (CodePipeline), hỗ trợ caching và rotation.

• ❌ SAI - Use an AWS Key Management Service (AWS KMS) key to encrypt the DB instance at rest. Activate RDS encryption in transit by using SSL certificates.
  Giải thích: Chỉ mã hóa dữ liệu DB at-rest (KMS) và in-transit (SSL/TLS) – bảo vệ dữ liệu lưu trữ/truyền tải, KHÔNG xử lý credentials trong source code. Credentials vẫn hardcode và lộ cho người dùng chia sẻ. RDS encryption là tính năng riêng, không thay thế secrets management.

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

• SSM Parameter Store: AWS Systems Manager Parameter Store – Hướng dẫn Secure Strings và KMS integration.
• RDS Security Best Practices: Amazon RDS Security – Nhấn mạnh tránh hardcode, dùng IAM DB auth + SSM.
• DevOps Exam Guide: AWS Certified DevOps Engineer Professional – Domain 4: Security (Secrets Manager/SSM).
• Blog mới: Best Practices for Managing Secrets (2025 update với SSM rotation cho RDS).

🛡️ Kết luận: Sử dụng SSM Parameter Store là best practice cho secrets trong source code, giúp audit pass và tuân thủ PCI-DSS cho financial apps!

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

Câu hỏi này thuộc chủ đề Amazon ElastiCache trên AWS, tập trung vào việc xây dựng kiến trúc highly available (có tính sẵn sàng cao) cho hệ thống leaderboard (bảng xếp hạng người chơi) của một công ty game. Hàng triệu người chơi tham gia giải đấu hàng năm trên toàn cầu, nên hệ thống phải chịu tải cao và đảm bảo tính sẵn sàng tối đa, đồng thời giảm thiểu tác động từ các hoạt động bảo trì (maintenance).

Yêu cầu chọn 2 bước kết hợp để đáp ứng:

• Highly available: Sử dụng tính năng replication, Multi-AZ để tránh downtime.
• Minimal impact từ maintenance: Lựa chọn thời gian bảo trì phù hợp, tránh giờ cao điểm.

Đây là câu hỏi kiểu chọn nhiều đáp án (choose two), kiểm tra kiến thức về ElastiCache for Redis (hỗ trợ cluster mode, read replicas, Multi-AZ) so với Memcached, và quản lý maintenance window. Kiến thức dựa trên phiên bản AWS mới nhất đến 2026: ElastiCache hỗ trợ Redis 7.x với Cluster mode enabled, Global Datastore (nhưng không phải cho Memcached), và Preferred Maintenance Window tùy chỉnh. 📘

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

1. Deploy an ElastiCache for Redis cluster with read replicas and Multi-AZ enabled.
   🛠️ Lý do chọn: Đây là cách triển khai highly available chuẩn cho ElastiCache Redis. Multi-AZ tự động failover sang replica nếu primary node fail (RTO <1 phút, RPO gần zero). Read replicas tăng throughput đọc (phù hợp leaderboard), hỗ trợ tối đa 5 replicas/node. Kết hợp cluster mode để scale horizontally, chịu tải hàng triệu requests/giây.

2. Choose a preferred maintenance window at the time of lowest usage to apply any required changes and mandatory updates.
   🛠️ Lý do chọn: AWS cho phép tùy chỉnh Preferred Maintenance Window (dài 60 phút, chọn giờ thấp điểm) để áp dụng patch/security updates. Giảm thiểu impact lên availability (downtime chỉ ~vài phút nếu Multi-AZ), phù hợp gaming platform 24/7. Không dùng default window vì có thể trùng giờ cao điểm.

📋 Giải thích TẤT CẢ các phương án (Đúng/Sai)

• ✅ Deploy an ElastiCache for Redis cluster with read replicas and Multi-AZ enabled.
  🟢 Đúng: Như trên, đảm bảo high availability với automatic failover, read scaling. Phù hợp workload leaderboard (high read throughput). Theo AWS best practices cho Redis clusters.

• ❌ Deploy an ElastiCache for Memcached global datastore.
  🔴 Sai: Memcached không hỗ trợ Multi-AZ hoặc replication (chỉ multi-node shard, nhưng không failover tự động). Global Datastore chỉ dành cho Redis (không phải Memcached). Memcached phù hợp simple caching, không HA cho global gaming leaderboard cần durability.

• ❌ Deploy a single-node ElastiCache for Redis cluster with automatic backups enabled. In the event of a failure, create a new cluster and restore data from the most recent backup.
  🔴 Sai: Single-node không HA (downtime hoàn toàn nếu fail, RTO hàng giờ). Restore từ backup (daily, lag 5-30 phút) gây data loss và downtime cao, không phù hợp "highly available" hoặc minimal maintenance impact. Nên dùng cluster với replicas thay vì manual restore.

• ❌ Use the default maintenance window to apply any required system changes and mandatory updates as soon as they are available.
  🔴 Sai: Default window (AWS tự chọn, thường random) có thể trùng giờ cao điểm, gây disruption lớn cho gaming (millions players). Không kiểm soát được impact, vi phạm yêu cầu "minimal impact on availability".

• ✅ Choose a preferred maintenance window at the time of lowest usage to apply any required changes and mandatory updates.
  🟢 Đúng: Như trên, tùy chỉnh window low-usage để minimize downtime (Multi-AZ giúp maintenance không gián đoạn hoàn toàn).

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

• ElastiCache Redis High Availability: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Replication.Redis.Groups.html (Multi-AZ, Read Replicas).
• Maintenance Windows: https://docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Maintenance.html (Preferred vs Default).
• ElastiCache Best Practices for Gaming: AWS Well-Architected Framework - Reliability Pillar (Gaming Lens): https://docs.aws.amazon.com/wellarchitected/latest/games-lens/wag-games-reliability.html.
• Redis vs Memcached: https://aws.amazon.com/elasticache/redis-vs-memcached/.

Kiến trúc khuyến nghị: Redis Cluster + Multi-AZ + Custom Maintenance + Auto Scaling cho leaderboard gaming! 🎮✨

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

Câu hỏi tập trung vào vấn đề latency (độ trễ) cao trong quá trình Change Data Capture (CDC) sử dụng AWS Database Migration Service (AWS DMS). Cụ thể:

• Một chuyên gia cơ sở dữ liệu của công ty đang triển khai DMS task để sao chép dữ liệu thay đổi từ cơ sở dữ liệu Oracle on-premises sang Amazon S3.
• Khi lưu lượng sử dụng ứng dụng tăng lên, xuất hiện nhiều giờ latency trong CDC.
• Yêu cầu chọn 2 giải pháp để giảm latency này.

Ngữ cảnh chính 🛠️: CDC trong DMS theo dõi và sao chép các thay đổi (insert, update, delete) thời gian thực. Latency cao thường do xử lý dữ liệu lớn (như LOB - Large Objects), phụ thuộc vào cấu hình task, hoặc thứ tự xử lý bảng có giao dịch chung. Giải pháp cần tối ưu hóa hiệu suất parallelization và chế độ xử lý LOB mà không ảnh hưởng tính nhất quán dữ liệu (theo tài liệu AWS DMS Best Practices 2024-2026).

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

• AWS DMS User Guide: Using a DMS replication instance (cập nhật 2025).
• AWS DMS CDC Best Practices (khuyến nghị parallel tasks và LOB modes).
• AWS re:Post - DMS CDC Latency Optimization.

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

Hai giải pháp đúng là:

• Configure the DMS task to run in limited large binary object (LOB) mode.
• Replicate tables in parallel by creating multiple DMS tasks for sets of tables that do not participate in common transactions.

Lý do lựa chọn 🎯:

• Limited LOB mode giúp giảm thời gian xử lý LOB bằng cách chỉ sao chép LOB dưới ngưỡng kích thước nhất định (mặc định 64KB, có thể điều chỉnh), bỏ qua hoặc truncate LOB lớn – lý tưởng cho CDC vì hầu hết thay đổi không phải LOB khổng lồ, giảm latency đáng kể khi load cao.
• Multiple DMS tasks parallel cho tables không giao dịch chung cho phép xử lý song song các bảng độc lập, tăng throughput mà không gây inconsistency (khác với tables có foreign key/transaction chung cần sequential).

🔍 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 tiếng Anh. Mỗi phương án được đánh dấu ✅ Đúng hoặc ❌ Sai, kèm giải thích lý do dựa trên best practices AWS DMS mới nhất (2026).

• ❌ [SAI] Configure the DMS task to run in full large binary object (LOB) mode.
  Phương án này làm tăng latency thay vì giảm, vì Full LOB mode buộc DMS phải xử lý toàn bộ nội dung LOB (không truncate), dẫn đến overhead cao với dữ liệu lớn từ Oracle (như CLOB/BLOB). Không phù hợp cho CDC high-load, theo docs AWS: "Full LOB mode should be avoided for ongoing replication due to performance impact."

• ✅ [ĐÚNG] Configure the DMS task to run in limited large binary object (LOB) mode.
  Giải pháp hiệu quả để giảm latency, vì Limited LOB mode chỉ sao chép LOB dưới max LOB size (cấu hình được, ví dụ 1MB), truncate phần còn lại. Phù hợp CDC Oracle-to-S3, tăng tốc độ 2-5x theo benchmarks AWS, mà vẫn đảm bảo tính nhất quán cho dữ liệu nhỏ.

• ❌ [SAI] Create a Multi-AZ replication instance.
  Multi-AZ chỉ tăng tính sẵn sàng (failover) bằng cách replicate instance qua AZ, nhưng không giảm latency CDC. Instance vẫn xử lý sequential, chỉ failover khi lỗi – không giải quyết bottleneck load cao. AWS docs xác nhận: "Multi-AZ improves HA, not throughput."

• ❌ [SAI] Load tables in parallel by creating multiple replication instances for sets of tables that participate in common transactions.
  Gây rủi ro inconsistency, vì tables có common transactions (giao dịch chung, như foreign keys) phải xử lý sequential để tránh dữ liệu lệch. Parallel instances cho nhóm này sẽ tăng latency do conflict resolution, vi phạm nguyên tắc DMS: "Tables with dependencies require single task/instance."

• ✅ [ĐÚNG] Replicate tables in parallel by creating multiple DMS tasks for sets of tables that do not participate in common transactions.
  Tối ưu hóa parallelization, chia tables độc lập thành nhiều DMS tasks (mỗi task dùng instance riêng), tăng throughput gấp nhiều lần mà không conflict. AWS khuyến nghị: "Use parallel tasks for independent table sets in CDC to minimize lag" – lý tưởng cho Oracle high-volume.

Kết luận 🚀: Áp dụng hai giải pháp đúng sẽ giảm latency từ "multiple hours" xuống phút, kết hợp monitoring CloudWatch DMS metrics (cdc_lag). Khuyến nghị test với DMS Preview mode trước production!