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

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

📖 Tóm tắt câu hỏi:
Các lập trình viên (developers) đã yêu cầu một cụm Amazon Redshift mới để tải dữ liệu marketing từ bên thứ ba (third-party) lưu trữ trên Amazon S3. Cụm Redshift đã sẵn sàng và credentials người dùng đã được cung cấp. Tuy nhiên, các lệnh COPY (dùng để tải dữ liệu từ S3 vào Redshift) thất bại với lỗi:
Amazon Invalid operation: S3ServiceException:Access Denied,Status 403,Error AccessDenied.

🛠️ Nguyên nhân lỗi: Lỗi 403 Access Denied xảy ra vì cụm Redshift không có quyền truy cập (permission) vào bucket S3 chứa dữ liệu. Redshift cần quyền đọc (read) từ S3 để thực hiện COPY, nhưng hiện tại chưa được cấu hình IAM role phù hợp.

Mục tiêu: Tìm giải pháp MOST secure (an toàn nhất) để khắc phục nhanh chóng, vì developers cần load data gấp. Giải pháp phải tuân thủ best practice AWS: Sử dụng IAM Role cho Redshift cluster thay vì hardcode access keys (vì keys dễ leak và kém an toàn).

🆕 Kiến thức cập nhật (AWS 2026): Theo tài liệu AWS mới nhất (Redshift IAM integration và COPY command), cách chuẩn là attach IAM Role vào cluster với policy read-only S3 (s3:GetObject, s3:ListBucket), và Redshift sẽ assume role này khi chạy COPY. Không khuyến khích dùng access keys trong COPY vì vi phạm nguyên tắc least privilege và zero-trust.

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

Đáp án đúng:
Create a new IAM role with read-only access to the Amazon S3 bucket and include the assume role action. Modify the Amazon Redshift cluster to add the IAM role.

Lý do chi tiết:
🛡️ Giải pháp này an toàn nhất (MOST secure) vì:

• Tạo IAM Role với policy read-only (GetObject, ListBucket) chỉ cho bucket S3 cụ thể → Áp dụng least privilege.
• Trust policy cho phép Redshift assume role (sts:AssumeRole).
• Attach role trực tiếp vào Redshift cluster qua console/CLI/API → Redshift tự động assume role khi chạy COPY mà không cần credentials thủ công.
• Developers chỉ cần chạy COPY với CREDENTIALS 'aws_iam_role=arn:aws:iam::account:role/RoleName' → Không lộ keys, tuân thủ AWS best practice.
• Fix nhanh: Chỉ mất vài phút để tạo role và modify cluster (hỗ trợ online modification từ Redshift RA3 nodes).

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

• ❌ Phương án SAI:
  Create a new IAM role with the same user name as the Amazon Redshift developer user ID. Provide the IAM role with read-only access to Amazon S3 with the assume role action.
  Giải thích sai: Phương án này không khả thi vì Redshift không hỗ trợ IAM role dựa trên "user name" của database user (như dev user ID). Redshift sử dụng cluster-level IAM role để assume, không phải per-user role. Việc match username chỉ làm phức tạp và không giải quyết lỗi Access Denied từ S3. Không phải best practice.

• ✅ Phương án ĐÚNG:
  Create a new IAM role with read-only access to the Amazon S3 bucket and include the assume role action. Modify the Amazon Redshift cluster to add the IAM role.
  Giải thích đúng: Như đã phân tích ở trên. Đây là cách chuẩn AWS cho COPY từ S3, đảm bảo security cao, scalable và không cần thay đổi COPY command nhiều.

• ❌ Phương án SAI:
  Create a new IAM role with read-only access to the Amazon S3 bucket with the assume role action. Add this role to the developer IAM user ID used for the copy job that ended with an error message.
  Giải thích sai: Lỗi logic – COPY job chạy từ Redshift cluster, không phải từ IAM user của developer. Attach role vào user ID không giúp Redshift truy cập S3. Developer user chỉ dùng để connect database, không liên quan đến S3 permissions trong COPY.

• ❌ Phương án SAI:
  Create a new IAM user with access keys and a new role with read-only access to the Amazon S3 bucket. Add this role to the Amazon Redshift cluster. Change the copy job to use the access keys created.
  Giải thích sai: Kém an toàn nhất vì tạo access keys và hardcode vào COPY command (dạng CREDENTIALS 'aws_access_key_id=...;aws_secret_access_key=...') → Dễ leak keys, vi phạm AWS security (keys có thể rotate thủ công nhưng vẫn rủi ro cao). Dù attach role vào cluster, việc dùng keys là thừa và không secure.

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

• AWS Redshift Docs: Using IAM roles for COPY: docs.aws.amazon.com/redshift/latest/mgmt/copy-usage_iam.html ✅ (Hướng dẫn chi tiết IAM role cho COPY).
• IAM Roles for Amazon Redshift: docs.aws.amazon.com/redshift/latest/mgmt/iam-identity-based-roles.html 🛡️ (Trust policy và attach cluster).
• Best Practices: Avoid access keys: AWS Well-Architected Framework (Security Pillar) – Khuyến nghị zero standing keys.
• Exam Tip (DOP-C02): Câu hỏi kiểu này thường test IAM integration cho managed services như Redshift/ECS.

💡 Lời khuyên thực tế: Sau khi attach role, chạy ALTER CLUSTER ... ADD IAM ROLES và test COPY ngay. Nếu multi-AZ cluster, role sẽ sync tự động! 🚀

🧩 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 thiết kế chiến lược disaster recovery (DR) cho một ứng dụng cao khả dụng sử dụng Amazon DynamoDB làm kho dữ liệu. Chuyên viên cơ sở dữ liệu tại một công ty tài chính đa quốc gia cần đề xuất giải pháp hiệu quả về mặt vận hành (operationally efficient), đáp ứng các yêu cầu nghiêm ngặt:

• RTO (Recovery Time Objective): 1 phút → Thời gian khôi phục hệ thống phải dưới 1 phút.
• RPO (Recovery Point Objective): 2 phút → Mất dữ liệu tối đa chỉ 2 phút.

📘 Bối cảnh AWS cập nhật đến 2026: DynamoDB hỗ trợ các tính năng DR tiên tiến như Global Tables (tự động replicate đa vùng), Point-in-Time Recovery (PITR - khôi phục điểm thời gian trong 35 ngày), và các công cụ backup khác. Giải pháp phải đảm bảo tính sẵn sàng cao, tự động hóa cao để phù hợp với ứng dụng đang phát triển (in development).

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

Đáp án đúng: Use a DynamoDB global table replica in another Region. Enable point-in-time recovery for both tables.

🛠️ Lý do chi tiết:

• DynamoDB Global Tables cung cấp replication đa vùng (multi-Region) tự động, đồng bộ dữ liệu gần như real-time (latency thấp, thường dưới giây), giúp đạt RPO < 2 phút nhờ dữ liệu được replicate liên tục.
• Point-in-Time Recovery (PITR) cho phép khôi phục bảng đến bất kỳ điểm thời gian nào trong 35 ngày qua với độ chính xác giây, đảm bảo mất dữ liệu tối đa 2 phút.
• Failover tự động sang replica ở Region khác chỉ mất vài giây đến 1 phút, đáp ứng RTO 1 phút.
• Operationally efficient: Quản lý tự động qua AWS console/CLI, không cần code tùy chỉnh, phù hợp cho môi trường production lớn.
  📘 Tài liệu tham khảo: AWS DynamoDB Global Tables Documentation và Point-in-Time Recovery (PITR) (cập nhật 2024-2026, hỗ trợ multi-Region PITR).

📋 Phân tí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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên khả năng đáp ứng RTO 1 phút, RPO 2 phút, và hiệu quả vận hành.

• [SAI] Create a DynamoDB stream that is processed by an AWS Lambda function that copies the data to a DynamoDB table in another Region.
  ❌ Sai vì: DynamoDB Streams + Lambda chỉ replicate dữ liệu bất đồng bộ (asynchronous), có độ trễ cao (có thể vài giây đến phút tùy workload), không đảm bảo RPO 2 phút (có thể mất dữ liệu nếu Lambda fail hoặc backlog). Failover thủ công, RTO vượt quá 1 phút. Không efficient vì cần code/maintain Lambda, xử lý lỗi phức tạp, không tự động như Global Tables.

• [ĐÚNG] Use a DynamoDB global table replica in another Region. Enable point-in-time recovery for both tables.
  ✅ Đúng vì: Như đã giải thích ở phần đáp án đúng. Giải pháp tự động, managed hoàn toàn, replication real-time + PITR đảm bảo RTO/RPO nghiêm ngặt, và scalable cho workload tài chính lớn. Đây là best practice AWS cho multi-Region DR.

• [SAI] Use a DynamoDB Accelerator table in another Region. Enable point-in-time recovery for the table.
  ❌ Sai vì: DynamoDB Accelerator (DAX) là lớp cache in-memory để tăng tốc đọc (không phải DR hoặc replication). DAX không lưu trữ dữ liệu bền vững, chỉ cache tạm thời, nên không replicate dữ liệu chính và không hỗ trợ PITR cho DR cross-Region. RTO/RPO không được đáp ứng vì mất dữ liệu cache khi failover.

• [SAI] Create an AWS Backup plan and assign the DynamoDB table as a resource.
  ❌ Sai vì: AWS Backup hỗ trợ DynamoDB nhưng chỉ backup theo lịch (hourly/daily), độ phân giải PITR chỉ 5 phút (không đạt RPO 2 phút chính xác). Restore mất thời gian dài (hàng giờ), vượt RTO 1 phút. Không efficient cho DR real-time, chỉ phù hợp backup dài hạn chứ không phải continuous replication.

🧩 Kết luận: Giải pháp Global Tables + PITR là lựa chọn tối ưu nhất theo AWS Well-Architected Framework (Reliability Pillar), đảm bảo tính sẵn sàng 99.999% cho ứng dụng tài chính. Nếu triển khai, khuyến nghị test failover định kỳ qua AWS Fault Injection Simulator! 📘

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

Câu hỏi tập trung vào việc di chuyển một cơ sở dữ liệu MySQL dung lượng 4 TB từ môi trường on-premises (tại chỗ) sang Amazon RDS for MySQL với thời gian downtime (thời gian gián đoạn) thấp nhất có thể.

• Bối cảnh: Đây là startup nhỏ, dữ liệu lớn (4 TB), nên cần phương pháp hiệu quả, đáng tin cậy, tránh mất dữ liệu hoặc gián đoạn lâu. AWS khuyến nghị các chiến lược migration như snapshot (mysqldump), replication (sao chép dữ liệu liên tục), hoặc DMS (Database Migration Service) để giảm thiểu downtime.
• Mục tiêu chính: Không chỉ copy dữ liệu ban đầu mà còn xử lý dữ liệu thay đổi liên tục (ongoing changes) trong quá trình migration, chỉ cutover (chuyển hướng ứng dụng) khi dữ liệu đồng bộ hoàn toàn.
• Kiến thức cập nhật (2026): Theo AWS Well-Architected Framework và RDS best practices mới nhất, replication bản địa của MySQL (MySQL native replication) kết hợp snapshot ban đầu là cách tối ưu cho homogeneous migration (cùng engine MySQL), hỗ trợ multi-AZ, read replicas, và zero-ETL trong RDS (nếu áp dụng nâng cao).

✅ Đáp án đúng: Phương án D

Deploy a new RDS for MySQL DB instance and configure it for access from the on-premises data center. Use the mysqldump utility to create an initial snapshot from the on-premises MySQL server, and copy it to an Amazon S3 bucket. Import the snapshot into the DB instance using the MySQL utilities running on an Amazon EC2 instance. Establish replication into the new DB instance using MySQL replication. Stop application access to the on-premises MySQL server and let the remaining transactions replicate over. Point the application to the DB instance.

Lý do lựa chọn:

• 🛠️ Giảm downtime tối đa: Snapshot ban đầu (mysqldump → S3 → import qua EC2) xử lý bulk data (4 TB). Sau đó, thiết lập MySQL replication để đồng bộ dữ liệu thay đổi real-time, chỉ downtime vài giây/phút khi stop app và cutover.
• ✅ Hiệu quả cao: Trực tiếp từ on-prem → RDS (không qua EC2 trung gian lâu dài), tận dụng native replication của RDS MySQL (hỗ trợ binlog-based replication).
• 🧩 Phù hợp quy mô lớn: Với 4 TB, replication lag thấp (<1 phút), an toàn hơn dump full (có thể mất hàng giờ).
• Không rủi ro: Dữ liệu không bị mất nhờ replication verify (slave status).

📋 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 phương án. Tôi giữ nguyên nội dung văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với lý do đúng/sai. Các phương án sai đều thiếu cơ chế đồng bộ dữ liệu thay đổi, dẫn đến downtime lớn (phải dump full lại hoặc mất data).

• Phương án A (❌ SAI):
  Deploy a new RDS for MySQL DB instance and configure it for access from the on-premises data center. Use the mysqldump utility to create an initial snapshot from the on-premises MySQL server, and copy it to an Amazon S3 bucket. Import the snapshot into the DB instance utilizing the MySQL utilities running on an Amazon EC2 instance. Immediately point the application to the DB instance.
  Giải thích: Chỉ snapshot ban đầu và cutover ngay lập tức → downtime cao (hàng giờ cho 4 TB + dữ liệu thay đổi bị mất). Không có replication để đồng bộ ongoing transactions, vi phạm yêu cầu "LEAST downtime".

• Phương án B (❌ SAI):
  Deploy a new Amazon EC2 instance, install the MySQL software on the EC2 instance, and configure networking for access from the on-premises data center. Use the mysqldump utility to create a snapshot of the on-premises MySQL server. Copy the snapshot into the EC2 instance and restore it into the EC2 MySQL instance. Use AWS DMS to migrate data into a new RDS for MySQL DB instance. Point the application to the DB instance.
  Giải thích: Sử dụng EC2 làm staging (dump → restore → DMS → RDS) → phức tạp, chi phí cao, downtime lớn (DMS full load + CDC nhưng với 4 TB cần thời gian dài). DMS phù hợp heterogeneous nhưng ở đây homogeneous nên replication native tốt hơn, không cần EC2 trung gian.

• Phương án C (❌ SAI):
  Deploy a new Amazon EC2 instance, install the MySQL software on the EC2 instance, and configure networking for access from the on-premises data center. Use the mysqldump utility to create a snapshot of the on-premises MySQL server. Copy the snapshot into an Amazon S3 bucket and import the snapshot into a new RDS for MySQL DB instance using the MySQL utilities running on an EC2 instance. Point the application to the DB instance.
  Giải thích: Tương tự A nhưng thêm EC2 không cần thiết → vẫn cutover ngay sau snapshot, mất dữ liệu thay đổi, downtime cao. EC2 chỉ dùng utilities (mysql command) nhưng không giải quyết ongoing sync.

• Phương án D (✅ ĐÚNG):
  Deploy a new RDS for MySQL DB instance and configure it for access from the on-premises data center. Use the mysqldump utility to create an initial snapshot from the on-premises MySQL server, and copy it to an Amazon S3 bucket. Import the snapshot into the DB instance using the MySQL utilities running on an Amazon EC2 instance. Establish replication into the new DB instance using MySQL replication. Stop application access to the on-premises MySQL server and let the remaining transactions replicate over. Point the application to the DB instance.
  Giải thích chi tiết: Kết hợp snapshot bulk + replication real-time → downtime chỉ lúc cutover ngắn. RDS hỗ trợ read replica từ on-prem master, binlog position sync chính xác. Tối ưu chi phí, scalable cho 4 TB.

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

• AWS RDS MySQL Migration Guide: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Procedural.Importing.html (mysqldump + replication).
• MySQL Replication to RDS: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MySQL.Replication.html.
• Database Migration Best Practices: https://aws.amazon.com/blogs/database/best-practices-for-migrating-mysql-to-amazon-rds/ (khuyến nghị replication cho low-downtime).
• AWS DMS vs Native Replication: DMS docs nhấn mạnh native tốt hơn cho MySQL homogeneous.

🛡️ Lời khuyên DevOps: Test replication lag trước production bằng SHOW SLAVE STATUS, dùng VPC peering/VPN cho connectivity an toàn!

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

Câu hỏi mô tả một công ty phát triển phần mềm đang sử dụng Amazon Aurora MySQL DB clusters cho các trường hợp sử dụng như development (phát triển) và reporting (báo cáo). Những workload này có nhu cầu không dự đoán được và biến động, dẫn đến spike latency (tăng đột ngột độ trễ) tạm thời. Người dùng chạy ad-hoc queries (truy vấn ngẫu hứng) rải rác suốt tuần. Chi phí là ưu tiên hàng đầu, và giải pháp cần không yêu cầu rework lớn (thay đổi đáng kể).

Mục tiêu: Tìm giải pháp tối ưu chi phí, xử lý workload không đều, scale linh hoạt, và dễ triển khai trên Aurora MySQL (hỗ trợ phiên bản mới nhất Aurora Serverless v2 đến 2026).

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

Đáp án đúng: Create new Aurora Serverless DB clusters for development and reporting, then migrate to these new DB clusters.

Lý do 🛠️:

• Aurora Serverless v2 (cập nhật mới nhất 2024-2026) tự động scale theo nhu cầu thực tế (từ 0.5 ACU đến 256 ACU), xử lý spike latency mà không cần quản lý instance thủ công.
• Pay-per-use: Chỉ tính phí khi có workload (pause khi idle), tiết kiệm chi phí lớn cho dev/reporting ad-hoc (giảm ~80% so với provisioned clusters).
• Không rework lớn: Tạo cluster mới và migrate dữ liệu đơn giản qua snapshot/export-import, phù hợp Aurora MySQL.
• Hoàn hảo cho workload unpredictable và sporadic, tránh over-provisioning.

📋 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 giá đúng/sai với lý do cụ thể dựa trên best practices AWS DevOps.

• ✅ Create new Aurora Serverless DB clusters for development and reporting, then migrate to these new DB clusters.
  🟢 Đúng vì lý do đã nêu ở trên: Scale tự động, chi phí thấp, dễ migrate (sử dụng AWS Database Migration Service - DMS nếu cần). Phù hợp Aurora MySQL Serverless v2 (hỗ trợ read replicas, global databases đến 2026).

• ❌ Upgrade one of the DB clusters to a larger size, and consolidate development and reporting activities on this larger DB cluster.
  🔴 Sai vì: Tăng kích thước instance (provisioned) dẫn đến chi phí cao hơn liên tục (over-provisioning cho spike hiếm), không giải quyết latency spike hiệu quả (vẫn cần manual scaling). Không tối ưu cho ad-hoc workload, vi phạm yêu cầu "cost primary concern".

• ❌ Use existing DB clusters and stop/start the databases on a routine basis using scheduling tools.
  🔴 Sai vì: Stop/start tiết kiệm chi phí storage nhưng không linh hoạt cho ad-hoc queries (người dùng phải chờ khởi động ~5-15 phút). Không xử lý spike realtime, yêu cầu scripting phức tạp (Lambda + EventBridge), và có downtime – không phù hợp "unpredictable demands" hay "no significant rework".

• ❌ Change the DB clusters to the burstable instance family.
  🔴 Sai vì: Burstable instances (t3/t4g) chỉ phù hợp low-baseline CPU với burst ngắn (credit-based), không xử lý sustained spikes của reporting queries. Aurora không hỗ trợ burstable trực tiếp cho clusters (chủ yếu provisioned hoặc Serverless), dẫn đến latency cao hơn và chi phí không tối ưu cho workload biến động mạnh.

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

• Aurora Serverless v2: docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless-v2.html – Scale theo demand, pause idle.
• Aurora Pricing: aws.amazon.com/rds/aurora/pricing – So sánh Serverless vs Provisioned.
• Best Practices DevOps: AWS Well-Architected Framework – Reliability & Cost Optimization pillars (whitepaper 2024).
• Exam Guide DOP-C02: AWS Certified DevOps Engineer Professional (bao gồm Serverless DB cho variable workloads).

Giải pháp này đảm bảo high availability, cost-efficiency theo tiêu chuẩn DevOps Engineer! 🚀

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

Câu hỏi mô tả một chuyên gia cơ sở dữ liệu (database specialist) đang xây dựng hệ thống sử dụng dataset tĩnh (static vendor dataset) chứa thông tin mã bưu điện (postal codes) và lãnh thổ liên quan, kích thước dưới 1 GB. Dataset này được load vào cache của ứng dụng ngay lúc khởi động (startup). Yêu cầu chính là lưu trữ dữ liệu với chi phí thấp nhất (lowest cost) và thời gian khởi động ứng dụng thấp (low application startup time).

🛠️ Phân tích yêu cầu chính:

• Dữ liệu tĩnh: Không thay đổi thường xuyên, chỉ đọc một lần lúc startup.
• Kích thước nhỏ (<1 GB): Không cần cơ sở dữ liệu phức tạp.
• Ưu tiên chi phí thấp: Tránh các dịch vụ tính phí compute/read liên tục.
• Startup nhanh: Truy cập dữ liệu phải nhanh chóng, dễ load vào cache.

📘 Kiến thức AWS cập nhật đến 2026: Theo tài liệu AWS mới nhất (AWS Well-Architected Framework - Storage Lens và Pricing pages, cập nhật 2025), S3 là lựa chọn tối ưu cho object storage tĩnh với chi phí thấp (~0.023 USD/GB/tháng), latency thấp cho GET requests, hỗ trợ Intelligent-Tiering để tối ưu chi phí. Các dịch vụ DB như RDS/Aurora/DynamoDB có chi phí cao hơn do compute và IOPS.

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

Đáp án đúng: Use Amazon S3 and load the data from flat files.

Lý do:

• Chi phí thấp nhất: S3 Standard storage chỉ ~0.023 USD/GB/tháng cho dữ liệu <1 GB, không tốn compute. Flat files (CSV/JSON) dễ load nhanh vào cache qua AWS SDK (boto3), hỗ trợ multipart download cho tốc độ cao.
• Startup time thấp: Latency GET object ~10-100ms, kết hợp CloudFront CDN hoặc S3 Transfer Acceleration để load toàn bộ file <1 GB chỉ trong vài giây.
• Phù hợp dữ liệu tĩnh: Không cần query phức tạp, chỉ đọc một lần.
• Nguồn tham khảo: AWS S3 Pricing (2025) và Best Practices for Loading Data into Amazon S3.

📋 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 bằng tiếng Anh. Mỗi phương án được đánh giá dựa trên chi phí, startup time và phù hợp dữ liệu tĩnh.

• ❌ Phương án SAI: Use an Amazon RDS DB instance. Shut down the instance once the data has been read.
  Lý do sai: RDS yêu cầu instance luôn chạy (hoặc pause với Multi-AZ), chi phí instance (~0.1-0.5 USD/giờ) + storage (~0.115 USD/GB/tháng) cao hơn S3 nhiều lần. Shutdown chỉ dừng compute nhưng storage vẫn tính phí, startup DB instance mất 1-5 phút để load dữ liệu, làm chậm application startup. Không hiệu quả cho dữ liệu tĩnh nhỏ.
  Nguồn: Amazon RDS Pricing (2025).

• ❌ Phương án SAI: Use Amazon Aurora Serverless. Allow the service to spin resources up and down, as needed.
  Lý do sai: Aurora Serverless v2 (cập nhật 2024) vẫn tính phí ACU (Aurora Capacity Units) ngay cả khi pause (~0.06 USD/ACU/giờ), cộng storage và I/O. Spin up/down mất 5-30 giây, chậm startup. Phù hợp workload biến động, không phải dữ liệu tĩnh load một lần. Chi phí cao hơn S3 gấp 10-50 lần.
  Nguồn: Amazon Aurora Serverless v2 Documentation (2025).

• ❌ Phương án SAI: Use Amazon DynamoDB in on-demand capacity mode.
  Lý do sai: DynamoDB on-demand tính phí theo read/write units (~0.25 USD/million reads), ngay cả dữ liệu tĩnh cũng tốn phí scan toàn bộ table lúc startup (chi phí ~1-5 USD cho 1 GB). Latency query cao hơn S3 GET, startup chậm do cần index/scan. Không tối ưu cho dataset nhỏ tĩnh, chi phí storage ~0.25 USD/GB/tháng cao gấp 10 lần S3.
  Nguồn: Amazon DynamoDB Pricing (2025).

• ✅ Phương án ĐÚNG: Use Amazon S3 and load the data from flat files.
  Lý do đúng (tóm tắt lại): Chi phí thấp nhất, truy cập nhanh nhất cho flat files tĩnh. Load qua SDK đơn giản, hỗ trợ compression (gzip) để giảm kích thước <1 GB xuống còn vài trăm MB, startup chỉ vài giây. Hoàn hảo cho cache preload.
  Nguồn: AWS S3 Best Practices (2025).

🛠️ Kết luận: S3 là giải pháp "Well-Architected" nhất cho dữ liệu tĩnh nhỏ, cân bằng cost/performance. Nếu cần query, có thể kết hợp Athena nhưng không cần thiết ở đây! 🚀

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

Câu hỏi tập trung vào vấn đề hiệu suất của bảng Amazon DynamoDB do hot partitions (phân vùng nóng) gây ra bởi partition key không tối ưu. Chuyên gia cơ sở dữ liệu đã xác định nguyên nhân và tạo partition key mới. Nhiệm vụ là áp dụng partition key mới cho tất cả dữ liệu hiện có (existing data) và dữ liệu mới (new data) một cách hiệu quả.

🔍 Chi tiết vấn đề:

• Hot partitions: Xảy ra khi nhiều truy vấn tập trung vào một partition key value cụ thể, dẫn đến throttling và latency cao.
• DynamoDB không hỗ trợ thay đổi trực tiếp partition key của bảng hiện tại (đây là hạn chế thiết kế từ các phiên bản AWS mới nhất đến 2026).
• Giải pháp yêu cầu tạo bảng mới với partition key cải thiện (để phân bố đều hơn), di chuyển toàn bộ dữ liệu cũ sang bảng mới, và chuyển hướng ứng dụng sang bảng mới cho dữ liệu mới.
• Mục tiêu: Không gián đoạn dịch vụ, giữ nguyên dữ liệu, và tối ưu hóa hiệu suất.

📘 Kiến thức cập nhật AWS (2026): Theo tài liệu AWS DynamoDB Developer Guide (phiên bản mới nhất), cách chuẩn để thay đổi partition key là export dữ liệu ra S3 rồi import vào bảng mới bằng công cụ như Amazon EMR (sử dụng Hive/Spark).

✅ Đáp án đúng

Use Amazon EMR to export the data from the current DynamoDB table to Amazon S3. Then use Amazon EMR again to import the data from Amazon S3 into a new DynamoDB table with the new partition key.

Lý do chọn đáp án này:

• ✅ EMR hỗ trợ export DynamoDB sang S3 qua Hive (hdfs-dynamodb.jar) hoặc Spark connector, sau đó import vào bảng mới với schema tùy chỉnh (bao gồm partition key mới).
• Quy trình: Tạo bảng DynamoDB mới → Export full data → Transform key nếu cần → Import với key mapping mới → Cập nhật ứng dụng switchover.
• Hiệu quả cao cho dữ liệu lớn, hỗ trợ parallel processing, không downtime nếu dùng Global Tables hoặc blue-green deployment.
• Đây là best practice từ AWS Well-Architected Framework cho DynamoDB migration.

🛠️ 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, với nội dung gốc giữ nguyên bằng tiếng Anh:

• ✅ [ĐÚNG] Use Amazon EMR to export the data from the current DynamoDB table to Amazon S3. Then use Amazon EMR again to import the data from Amazon S3 into a new DynamoDB table with the new partition key.
  Như đã giải thích ở trên: EMR là công cụ chính thức, linh hoạt cho export/import với key transformation. Hỗ trợ dữ liệu lớn, scalable, và không thay đổi schema gốc trực tiếp (tránh hot partitions).

• ❌ [SAI] Use AWS DMS to copy the data from the current DynamoDB table to Amazon S3. Then import the DynamoDB table to create a new DynamoDB table with the new partition key.
  DMS (Database Migration Service) không hỗ trợ export trực tiếp DynamoDB sang S3 dưới dạng migration full schema change. DMS chủ yếu dùng cho CDC (Change Data Capture) từ DynamoDB source sang target (như RDS/Kinesis), nhưng không transform partition key và không export raw data sang S3 dễ dàng. Import từ S3 cần công cụ khác, dẫn đến phức tạp và không hiệu quả.

• ❌ [SAI] Use the AWS CLI to update the DynamoDB table and modify the partition key.
  Không thể modify partition key qua AWS CLI (hoặc bất kỳ API nào). DynamoDB immutable schema cho primary key – chỉ tạo bảng mới được. Lệnh update-table chỉ hỗ trợ thay đổi billing mode, attributes phụ, indexes, không chạm primary key (xác nhận từ AWS CLI v2.15+ năm 2026).

• ❌ [SAI] Use the AWS CLI to back up the DynamoDB table. Then use the restore-table-from-backup command and restore the table with a new partition key.
  Point-in-Time Recovery (PITR) hoặc On-Demand Backup tạo bảng giống hệt (restore giữ nguyên schema, bao gồm partition key). Không hỗ trợ modify key khi restore – bảng mới sẽ inherit schema cũ, vẫn gây hot partitions (AWS Docs: Backup/Restore DynamoDB không cho phép schema edit).

📚 Tài liệu tham khảo

• AWS DynamoDB Developer Guide: "Exporting DynamoDB data to Amazon S3" và "Changing the primary key" → docs.aws.amazon.com/amazondynamodb/latest/developerguide/ (cập nhật 2024-2026).
• Amazon EMR DynamoDB Connector: Hive/Spark integration → aws.amazon.com/blogs/big-data/.
• AWS Well-Architected DynamoDB Lens: Best practices cho hot partitions → aws.amazon.com/architecture/well-architected/.
• Sample EMR Steps: hadoop jar emr-dynamodb-hive.jar ... cho export/import.

🛡️ Lời khuyên DevOps: Sau migration, monitor bằng CloudWatch Contributor Insights để xác nhận no hot partitions, và dùng DynamoDB Streams cho dual-write transition nếu cần zero-downtime.

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

Câu hỏi xoay quanh một tình huống bảo mật trong AWS: Một công ty đang trải qua cuộc kiểm toán bảo mật (security audit). Nhóm kiểm toán phát hiện mật khẩu master user (mật khẩu người dùng chính) được lưu trữ dưới dạng văn bản rõ ràng (cleartext) trong các template AWS CloudFormation dùng để triển khai Amazon RDS for MySQL DB instances. Điều này bị đánh giá là rủi ro bảo mật cao đối với đội ngũ quản lý cơ sở dữ liệu (database team).

📌 Vấn đề cốt lõi: Việc hardcode (cố định) mật khẩu rõ ràng trong CloudFormation template vi phạm nguyên tắc bảo mật "least privilege" và "secrets management" của AWS, dễ bị lộ thông qua truy cập template (ví dụ: Git repo, CI/CD pipeline). Database specialist cần giải pháp mitigate rủi ro này mà không làm gián đoạn triển khai và tuân thủ best practices AWS (cập nhật đến 2026, với hỗ trợ đầy đủ cho CloudFormation v6+ và Secrets Manager ARN references).

🛠️ Mục tiêu: Thay thế cleartext password bằng cơ chế quản lý bí mật an toàn, tự động hóa trong IaC (Infrastructure as Code).

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

Đáp án đúng: Use an AWS Secrets Manager resource to generate a random password and reference the secret in the CloudFormation template.

Lý do chi tiết:

• AWS khuyến nghị chính thức sử dụng AWS Secrets Manager để tạo mật khẩu ngẫu nhiên (random password) và tham chiếu (reference) secret ARN trong CloudFormation template cho RDS.
• Trong template, dùng resource AWS::SecretsManager::Secret để generate password, sau đó reference qua Fn::GetSecretValue hoặc NoEcho: true cho DBInstance.MasterUserPassword.
• Lợi ích: Mật khẩu được mã hóa tự động (KMS), rotate định kỳ, audit logs đầy đủ, và RDS tự động retrieve secret khi tạo DB instance (hỗ trợ từ RDS v13+ và CFN intrinsic functions). Không lộ cleartext, tuân thủ CIS AWS Foundations Benchmark.
• ✅ Hoàn hảo cho MySQL RDS: Hỗ trợ full từ năm 2018, cập nhật 2026 với AI-powered rotation.

📋 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 tính khả thi, bảo mật và best practices AWS (2026).

• Change all the databases to use AWS IAM for authentication and remove all the cleartext passwords in CloudFormation templates.
  ❌ Sai vì: IAM Database Authentication chỉ hỗ trợ MySQL 5.6.34+ / 8.0+ với điều kiện cụ thể (như SSL), nhưng KHÔNG thay thế hoàn toàn master user password – RDS vẫn yêu cầu master password khi tạo instance (bắt buộc field trong CFN). Migrate tất cả DB sang IAM đòi hỏi thay đổi app code (generate IAM tokens), không khả thi ngay lập tức cho audit nhanh. Không mitigate cleartext ngay, có thể fail deployment.

• Use an AWS Secrets Manager resource to generate a random password and reference the secret in the CloudFormation template.
  ✅ Đúng vì: Như đã giải thích ở trên. Đây là giải pháp chuẩn AWS, tích hợp native với RDS CFN (resource AWS::RDS::DBInstance + MasterUserPassword: !Ref Secret). Tạo random password an toàn (min 8 ký tự), reference qua !Sub '{{resolve:secretsmanager:SecretId}}' hoặc Fn::Sub. Zero cleartext, auto-rotate, chi phí thấp (~$0.40/secret/tháng).

• Remove the passwords from the CloudFormation templates so Amazon RDS prompts for the password when the database is being created.
  ❌ Sai vì: CloudFormation KHÔNG hỗ trợ interactive prompts như AWS Console. Field MasterUserPassword là bắt buộc (required) cho RDS CFN template – nếu remove, stack creation sẽ fail với lỗi validation. RDS chỉ prompt trong Console wizard, không áp dụng cho IaC/automation.

• Remove the passwords from the CloudFormation template and store them in a separate file. Replace the passwords by running CloudFormation using a sed command.
  ❌ Sai vì: Vẫn hardcode password ở file riêng (dễ leak qua Git/secrets scanning), sed command là hack thủ công, KHÔNG idempotent (không lặp lại được), vi phạm IaC principles. Không audit trail, không encryption tự động, dễ lỗi CI/CD. AWS chống lại custom scripts thay vì managed services như Secrets Manager.

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

• AWS CloudFormation User Guide: Secrets Manager Integration 🛠️
• Amazon RDS CloudFormation: Managing Secrets ✅
• AWS Best Practices: Secrets Management
• CIS AWS Benchmarks v3.0.0: RDS Secrets (Control 2.2.5)

🧠 Kết luận: Sử dụng Secrets Manager là cách tối ưu, scalable cho DevOps IaC bảo mật! Nếu deploy, test với cfn-lint để validate.

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

Câu hỏi xoay quanh tình huống thực tế trong Amazon DocumentDB (một dịch vụ cơ sở dữ liệu NoSQL tương thích MongoDB do AWS cung cấp).

• Bối cảnh: Một chuyên viên cơ sở dữ liệu (database specialist) đã tắt TLS (Transport Layer Security) trên cluster DocumentDB để thực hiện các bài kiểm tra hiệu suất (benchmarking tests). TLS là lớp bảo mật bắt buộc mặc định trong DocumentDB để mã hóa kết nối.
• Sự cố: Vài ngày sau, một thực tập sinh (trainee) vô tình xóa nhiều bảng (tables). Chuyên viên đã khôi phục (restore) cluster từ snapshot có sẵn.
• Vấn đề hiện tại: Sau 1 giờ khôi phục, chuyên viên vẫn không thể kết nối đến endpoint của cluster mới. Lý do cốt lõi là cluster mới sau restore sử dụng default parameter group, nơi TLS được bật trở lại (enforced), trong khi client kết nối có lẽ đang cấu hình không hỗ trợ TLS (dựa trên setup benchmarking trước đó).

Mục tiêu: Xác định hành động nhanh chóng và chính xác để kết nối được với cluster mới. 🛠️
(Lưu ý: Theo tài liệu AWS cập nhật 2024-2026, khi restore DocumentDB từ snapshot, cluster mới không kế thừa custom parameter group của cluster gốc mà sử dụng default parameter group. Parameter tls_disabled mặc định là 0, buộc TLS bật.)

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

Đáp án đúng: Change the restored cluster's parameter group to the original cluster's custom parameter group.

Lý do chi tiết:

• Cluster gốc đã sử dụng custom parameter group để đặt tls_disabled = 1, tắt TLS cho benchmarking.
• Khi restore, cluster mới tự động dùng default parameter group (tls_disabled = 0), nên TLS enforced → client không connect được nếu không dùng TLS.
• Thay parameter group của cluster mới thành custom group của cluster gốc sẽ áp dụng lại cấu hình tắt TLS ngay lập tức, cho phép kết nối.
  Thời gian áp dụng: Parameter group thay đổi propagate trong vài phút (không cần reboot cluster).
  ✅ Hoàn hảo cho tình huống khẩn cấp sau restore!
  (Nguồn: AWS DocumentDB Developer Guide - Parameter Groups: https://docs.aws.amazon.com/documentdb/latest/developerguide/data-param-groups.html#data-params-tls)

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

• ✅ Change the restored cluster's parameter group to the original cluster's custom parameter group.
  Đúng vì: Như giải thích trên, đây là cách trực tiếp khôi phục cấu hình TLS disabled từ cluster gốc. Parameter group là yếu tố quyết định hành vi TLS, và restore không copy nó. Hiệu quả cao, không downtime lớn. 🏆

• ❌ Change the restored cluster's parameter group to the Amazon DocumentDB default parameter group.
  Sai vì: Default group chính là cái đang dùng sau restore (tls_disabled=0), nên thay vào vẫn giữ TLS enforced → vấn đề không giải quyết, thậm chí tệ hơn nếu custom group gốc khác biệt. Không liên quan đến vấn đề gốc! 🚫

• ❌ Configure the interface VPC endpoint and associate the new Amazon DocumentDB cluster.
  Sai vì: Interface VPC endpoint dùng để kết nối private từ VPC đến DocumentDB qua AWS PrivateLink, nhưng vấn đề ở đây là TLS protocol mismatch, không phải network connectivity. Endpoint không ảnh hưởng TLS settings. (DocumentDB hỗ trợ VPC endpoints từ 2021, nhưng không giải quyết TLS.) 🌐❌

• ❌ Run the syncInstances command in AWS DataSync.
  Sai vì: AWS DataSync dùng để sync dữ liệu giữa storage (như S3, EFS), không phải sync instances/cluster DocumentDB. Không có lệnh syncInstances trong DataSync, và nó không liên quan restore hay TLS. Hoàn toàn lạc đề! 🔄🚫

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

• DocumentDB Restore Behavior: https://docs.aws.amazon.com/documentdb/latest/developerguide/backup-restore.html (Restore tạo cluster mới với default params).
• TLS Parameters: https://docs.aws.amazon.com/documentdb/latest/developerguide/data-params.html#DocDB.Latest/UserGuide.PARAMETERS.TLS_DISABLED (tls_disabled chỉ custom group).
• Benchmarking Guide: https://docs.aws.amazon.com/documentdb/latest/developerguide/benchmarking-tls.html (Hướng dẫn tắt TLS cho perf tests).
• Exam Tip (DOP-C02): Parameter groups thường là "hidden gotcha" trong restore scenarios. 🎯

Hy vọng phân tích này giúp bạn nắm vững! Nếu cần thêm ví dụ CLI/modify-db-cluster-parameter-group, hỏi nhé. 🚀

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

Câu hỏi mô tả một công ty đang chạy hệ thống CRM on-premises với cơ sở dữ liệu MySQL làm backend. Hệ thống sử dụng stored procedure tùy chỉnh để gửi thông báo email đến một hệ thống khác mỗi khi dữ liệu được chèn (insert) vào bảng. Tuy nhiên, hiệu suất CRM giảm sút do các ứng dụng báo cáo (reporting applications) từ nhiều đội ngũ truy vấn database. Công ty cần giải pháp AWS đáp ứng các yêu cầu:

• Giảm maintenance (quản trị, bảo trì thấp).
• Cải thiện performance (tăng tốc độ, chịu tải tốt hơn cho reporting).
• Giữ nguyên tính năng gửi email notification.

🛠️ Mục tiêu chính: Di chuyển lên AWS managed database (như Aurora/RDS) để tự động hóa maintenance, sử dụng read replica offload read traffic từ reporting, và tích hợp cơ chế notification qua SNS/SES/Lambda tương thích với stored procedure MySQL.

✅ Đáp án đúng: Lựa chọn D

Use Amazon Aurora MySQL with a read replica for the reporting applications. Configure a stored procedure and an AWS Lambda function to publish a message to an Amazon SNS topic. Subscribe the other system's email address to the topic.

Lý do chọn đáp án này (dựa trên kiến thức AWS cập nhật 2026):

• Amazon Aurora MySQL là dịch vụ fully managed (giảm maintenance cao: auto backup, patching, scaling, high availability >99.99%), tương thích 100% với MySQL stored procedure.
• Read replica (hỗ trợ lên đến 15 replicas) offload hoàn toàn read traffic từ reporting apps khỏi primary instance, cải thiện performance CRM (write-heavy từ CRM, read-heavy từ reporting).
• Stored procedure giữ nguyên logic gốc; AWS Lambda được trigger (qua DB event hoặc app integration) để publish message đến SNS topic, sau đó SNS subscribe email gửi notification đến hệ thống khác – scalable, serverless, không phụ thuộc SES trực tiếp.
• Toàn bộ giải pháp serverless-oriented, phù hợp DevOps best practices.

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

• AWS Aurora MySQL Docs: Aurora Read Replicas (cập nhật 2025).
• AWS SNS Email Subscriptions: SNS Subscriptions.
• DOP-C02 Exam Guide (2024-2026): Domain 2 - Storage & Database.

🔍 Phân tích tất cả các lựa chọn

Dưới đây là phân tích chi tiết từng phương án. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, đánh dấu ✅/❌, và giải thích lý do đúng/sai bằng tiếng Việt.

• ❌ Lựa chọn A: Use MySQL running on an Amazon EC2 instance with Auto Scaling to accommodate the reporting applications. Configure a stored procedure and an AWS Lambda function that uses Amazon SES to send email notifications to the other system.
  Tại sao sai? EC2 MySQL là self-managed (phải tự cài đặt, patch, backup, HA), không giảm maintenance so với on-premises. Auto Scaling cho EC2 không hỗ trợ DB read scaling hiệu quả (phải manual cluster). Lambda + SES gửi email ok nhưng không giải quyết performance reporting (vẫn tải primary). Không phải giải pháp managed AWS khuyến nghị.

• ❌ Lựa chọn B: Use Amazon Aurora MySQL in a multi-master cluster to accommodate the reporting applications. Configure Amazon RDS event subscriptions to publish a message to an Amazon SNS topic and subscribe the other system's email address to the topic.
  Tại sao sai? Aurora MySQL không hỗ trợ multi-master cluster (chỉ có primary + read replicas; multi-master chỉ cho một số engine khác hoặc Global Databases). RDS event subscriptions (cho DDL/DML changes) không trigger chính xác cho "insert into table" như stored procedure tùy chỉnh. Không giữ nguyên stored procedure, và multi-master làm phức tạp write conflicts, không cải thiện performance reporting đúng cách.

• ❌ Lựa chọn C: Use MySQL running on an Amazon EC2 instance with a read replica to accommodate the reporting applications. Configure Amazon SES integration to send email notifications to the other system.
  Tại sao sai? EC2 MySQL self-managed, read replica phải setup manual (sử dụng binlog replication), tốn maintenance cao (không auto failover như RDS/Aurora). SES integration không rõ ràng với stored procedure (phải custom code SMTP trong DB, kém scalable). Không offload reporting hiệu quả, performance vẫn kém.

• ✅ Lựa chọn D: Use Amazon Aurora MySQL with a read replica for the reporting applications. Configure a stored procedure and an AWS Lambda function to publish a message to an Amazon SNS topic. Subscribe the other system's email address to the topic.
  Xác nhận đúng (như phần trên): Managed service, read replica offload read traffic, giữ stored procedure + Lambda/SNS serverless cho notification. Hoàn hảo cho yêu cầu! 🏆

🧩 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) cơ sở dữ liệu Oracle Database Standard Edition đang chạy trên Amazon EC2 instance sang Amazon RDS for Oracle DB instance với tính năng Multi-AZ (đảm bảo high availability qua deployment đa Availability Zone).

• Bối cảnh: Cơ sở dữ liệu hỗ trợ website thương mại điện tử (ecommerce) chạy liên tục 24/7, không chấp nhận downtime dài.
• Ràng buộc quan trọng: Chỉ có cửa sổ bảo trì (maintenance window) tối đa 5 phút, nghĩa là toàn bộ quá trình migrate phải tối ưu hóa downtime ở mức rất thấp.
• Mục tiêu: Tìm giải pháp migrate dữ liệu an toàn, đồng bộ (sync) giữa source (EC2) và target (RDS), sau đó failover nhanh chóng mà không làm gián đoạn ứng dụng lâu.
  Giải pháp phải tận dụng các dịch vụ AWS hỗ trợ replication gần real-time (như CDC - Change Data Capture), phù hợp với Oracle Standard Edition (không hỗ trợ một số tính năng cao cấp như RAC đầy đủ).

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

Đáp án đúng: Configure AWS DMS with the EC2 instance as the source and the RDS DB instance as the destination. Stop the application when the replication is in sync, change the database connection string, and then restart the application.

Lý do chọn đáp án này 🛠️:

• AWS Database Migration Service (DMS) là dịch vụ chuyên dụng cho việc migrate cơ sở dữ liệu với downtime tối thiểu (thường chỉ vài phút ở bước cutover). Nó hỗ trợ full load + ongoing replication (CDC) từ Oracle trên EC2 (source) sang RDS Oracle (target), đảm bảo dữ liệu đồng bộ liên tục.
• Quy trình: Bắt đầu replication, chờ sync hoàn tất (ongoing changes được capture real-time), dừng app ngắn (đổi connection string), restart app → downtime <5 phút.
• Phù hợp Oracle Standard Edition và RDS Multi-AZ (DMS hỗ trợ Multi-AZ target từ phiên bản mới nhất 2024-2026). Không yêu cầu dừng app suốt quá trình.
• Đây là best practice cho homogeneous migration (Oracle-to-Oracle) theo AWS Well-Architected Framework.

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do cụ thể dựa trên tính năng AWS cập nhật đến 2026.

• Phương án A: Configure Oracle Real Application Clusters (RAC) on the EC2 instance and the RDS DB instance. Update the connection string to point to the RAC cluster. Once the EC2 instance and RDS DB instance are in sync, fail over from Amazon EC2 to Amazon RDS.
  ❌ Sai vì: Oracle Standard Edition không hỗ trợ RAC (chỉ Enterprise Edition mới hỗ trợ). RDS for Oracle không cung cấp RAC cho Standard Edition (chỉ Enterprise Edition 19c/21c trở lên). Việc config RAC trên EC2 cũng phức tạp, không đảm bảo sync tự động và downtime <5 phút. Không phải giải pháp migrate chuẩn AWS.

• Phương án B: Export the Oracle database from the EC2 instance using Oracle Data Pump and perform an import into Amazon RDS. Stop the application for the entire process. When the import is complete, change the database connection string and then restart the application.
  ❌ Sai vì: Oracle Data Pump (expdp/impdp) yêu cầu dừng ứng dụng toàn bộ quá trình export/import, downtime có thể hàng giờ/ngày tùy kích thước DB (không phù hợp ecommerce liên tục). Không hỗ trợ ongoing replication, vi phạm ràng buộc 5 phút.

• Phương án C (Đúng - như đã nêu ở trên): Configure AWS DMS with the EC2 instance as the source and the RDS DB instance as the destination. Stop the application when the replication is in sync, change the database connection string, and then restart the application.
  ✅ Đúng vì: DMS hỗ trợ CDC real-time cho Oracle (Supplemental Logging), full load + change capture, cutover nhanh (<5 phút). Hoàn hảo cho RDS Multi-AZ target, low-downtime migration. Đã được AWS khuyến nghị cho Oracle migrations từ 2023-2026.

• Phương án D: Configure AWS DataSync with the EC2 instance as the source and the RDS DB instance as the destination. Stop the application when the replication is in sync, change the database connection string, and then restart the application.
  ❌ Sai vì: AWS DataSync chỉ dùng cho file/block storage transfer (NFS/SMB/HDFS/EFS), không hỗ trợ database replication hay CDC cho Oracle/RDS. Không thể sync DB schema/data real-time, sẽ fail khi apply vào RDS.

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

• AWS DMS Documentation: Using a Oracle database as a source for AWS DMS & Migrating Oracle to RDS – Xác nhận hỗ trợ Standard Edition, CDC, Multi-AZ.
• RDS for Oracle: Oracle on RDS Limitations – Không hỗ trợ RAC cho Standard Edition.
• AWS Migration Guide: Database Migration Best Practices (Well-Architected).
• DataSync Limits: What DataSync supports – Chỉ file-level, không DB.

Giải pháp này đảm bảo zero-ETL mindset với downtime tối ưu! 🚀 Nếu cần lab thực hành, dùng AWS Free Tier DMS.