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

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

Câu hỏi tập trung vào việc cho phép một Amazon Redshift cluster hiện có truy cập dữ liệu từ các Redshift cluster khác, Amazon RDS for PostgreSQL, và bảng trong AWS Glue Data Catalog. Yêu cầu là chọn kết hợp 3 bước đạt hiệu quả vận hành cao nhất (MOST operational efficiency), nghĩa là ưu tiên các phương pháp không cần sao chép dữ liệu thủ công, tự động hóa cao, ít tốn tài nguyên, và hỗ trợ truy cập trực tiếp mà vẫn giữ tính bảo mật và khả năng mở rộng.

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

• Redshift khác: Cần chia sẻ dữ liệu giữa các cluster mà không unload/load.
• RDS PostgreSQL: Hỗ trợ truy vấn liên kết (federated) để query trực tiếp.
• Glue Data Catalog: Sử dụng Redshift Spectrum để tạo external tables truy cập metadata từ Catalog (dữ liệu thực tế nằm trên S3).
• Tiêu chí MOST operational efficiency: Tránh snapshot, unload/COPY, hoặc ETL thủ công vì chúng tốn thời gian, chi phí, và không real-time. Ưu tiên tính năng native của Redshift như Data Sharing, Federated Queries, và External Tables (Spectrum).

Câu hỏi thuộc chủ đề Redshift Advanced Querying & Sharing trong kỳ thi AWS Certified DevOps Engineer - Professional ( DOP-C02 ), nhấn mạnh kiến trúc serverless và zero-ETL.

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

Các đáp án đúng là b, d, e vì chúng sử dụng tính năng native của Redshift để truy cập trực tiếp dữ liệu mà không cần di chuyển dữ liệu, đạt hiệu quả cao nhất:

• Create external tables in the existing Redshift database to connect to the AWS Glue Data Catalog tables. 🛤️ (Truy cập Glue Catalog qua Spectrum).
• Use federated queries to access data in Amazon RDS. 🔗 (Query RDS trực tiếp).
• Use data sharing to access data from the other Redshift clusters. 📤 (Chia sẻ datashare giữa clusters).

Lý do lựa chọn:

• Những bước này zero-copy (không sao chép dữ liệu), real-time query, tự động scale, và quản lý qua IAM policies. Giảm chi phí lưu trữ (không duplicate data), thời gian setup thấp, và hỗ trợ workload lớn. Đây là best practice theo AWS Well-Architected Framework (Reliability & Cost Optimization pillars) phiên bản 2024-2026.

📋 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 hoặc ❌ Sai, kèm giải thích đầy đủ bằng tiếng Việt dựa trên tài liệu AWS mới nhất (Redshift ra mắt Data Sharing 2020, Federated Queries 2019, Spectrum 2017 - vẫn là core features đến 2026).

• Take a snapshot of the required tables from the other Redshift clusters. Restore the snapshot into the existing Redshift cluster.
  ❌ Sai. Phương án này chỉ áp dụng cho Redshift-to-Redshift, không hỗ trợ RDS hay Glue Catalog. Snapshot/restore tạo dữ liệu duplicate (tốn storage), không real-time (cần manual refresh), và không efficient vì vi phạm zero-ETL. Phù hợp migrate ban đầu chứ không phải access liên tục.

• Create external tables in the existing Redshift database to connect to the AWS Glue Data Catalog tables.
  ✅ Đúng. Sử dụng Redshift Spectrum để tạo external tables query trực tiếp dữ liệu S3 qua Glue Data Catalog (làm metadata catalog). Hiệu quả cao: Không cần load data vào Redshift, hỗ trợ Parquet/ORC/JSON, scale serverless, chi phí chỉ tính query scan. Bước: CREATE EXTERNAL SCHEMA ... DATABASE 'glue_catalog'; CREATE EXTERNAL TABLE ...;.

• Unload the RDS tables and the tables from the other Redshift clusters into Amazon S3. Run COPY commands to load the tables into the existing Redshift cluster.
  ❌ Sai. Đây là cách thủ công ETL (unload từ RDS/Redshift → S3 → COPY vào target), rất inefficient: Tốn thời gian sync (không real-time), duplicate storage, chi phí UNLOAD/COPY cao, và phức tạp quản lý schema changes. Không phù hợp MOST operational efficiency.

• Use federated queries to access data in Amazon RDS.
  ✅ Đúng. Redshift Federated Query cho phép query trực tiếp RDS PostgreSQL qua JDBC/ODBC driver tích hợp. Hiệu quả: Push-down predicates (chỉ scan data cần), IAM auth, cache results. Bước: CREATE EXTERNAL TABLE rds_table... ENGINE = 'postgres'; SELECT * FROM rds_table;. Hỗ trợ PostgreSQL 9.5+ (mới nhất 16.x đến 2026).

• Use data sharing to access data from the other Redshift clusters.
  ✅ Đúng. Redshift Data Sharing (cross-account/region) cho phép chia sẻ live data giữa clusters mà zero-copy. Producer tạo datashare (CREATE DATASHARE), consumer access như local (CREATE DATABASE FROM DATA SHARE). Hiệu quả tối ưu: Real-time, read-only, low-latency, scale petabyte, không tốn ETL. Hỗ trợ ra/multi-cluster đến 2026.

• Use AWS Glue jobs to transfer the AWS Glue Data Catalog tables into Amazon S3. Create external tables in the existing Redshift database to access this data.
  ❌ Sai. Glue Catalog đã là metadata cho S3, không cần "transfer" thêm qua Glue jobs (thừa ETL). Tạo external tables trực tiếp từ Catalog đã đủ (như phương án b). Phương án này thêm bước không cần, tốn chi phí Glue Crawler/Job, delay data freshness, kém efficient.

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

• Redshift Data Sharing: docs.aws.amazon.com/redshift/latest/mgmt/data-sharing.html – Zero-ETL sharing.
• Federated Queries: docs.aws.amazon.com/redshift/latest/mgmt/querying-external-data.html – RDS integration.
• Spectrum & External Tables: docs.aws.amazon.com/redshift/latest/dg/querying-external-data-glue.html – Glue Catalog direct access.
• Exam Guide DOP-C02: aws.amazon.com/certification/certified-devops-engineer-professional – Domain 4: Automation.

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần ví dụ code SQL, 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 đang lập kế hoạch di chuyển cơ sở dữ liệu Oracle 40 TB sang Amazon Aurora PostgreSQL DB cluster bằng một AWS DMS task duy nhất trên một replication instance. Trong quá trình thử nghiệm ban đầu, AWS DMS không scale theo nhu cầu: giai đoạn full load và CDC (Change Data Capture) mất nhiều ngày.

✅ Điều kiện đã đủ:

• Server nguồn và target DB cluster có đủ network bandwidth và CPU bandwidth.
• Replication instance có đủ resources để hỗ trợ replication.

🎯 Yêu cầu giải quyết:

• Cải thiện hiệu suất DMS.
• Giảm thời gian di chuyển dữ liệu.
• Tạo nhiều DMS tasks (multiple DMS tasks).

Câu hỏi yêu cầu chọn TWO thay đổi kết hợp để đáp ứng (dựa trên AWS DMS best practices cập nhật đến 2026, tập trung vào parallel load, sub-tasks và task splitting cho large-scale migrations >10TB).

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

Đáp án đúng là:

• Use a smaller set of tables with each DMS task. Set the MaxFullLoadSubTasks parameter to a higher value.
• Use parallel load with different data boundaries for larger tables.

Lý do lựa chọn (bằng tiếng Việt chi tiết):
🛠️ Kết hợp này tối ưu cho migration lớn (40TB):

• Tạo multiple DMS tasks với smaller sets of tables để phân tải song song trên nhiều replication instances hoặc tasks, tránh bottleneck single task.
• Tăng MaxFullLoadSubTasks (default=8, max=49 theo DMS 3.5+ năm 2024-2026): Cho phép DMS chia table lớn thành nhiều sub-tasks parallel (dựa trên primary key/range), tăng throughput full load lên gấp 5-10x mà không cần instance lớn hơn.
• Parallel load với data boundaries: DMS hỗ trợ parallel-load-types như range, primary-key-range, partition (cập nhật DMS 3.4.7+), chia table lớn theo ranh giới dữ liệu (ví dụ: theo PK values), load song song các chunks → giảm thời gian full load từ days xuống hours.
  Kết quả: Scale horizontally (multiple tasks) + vertically (sub-tasks/parallel per table), phù hợp khi resources đã đủ, không vi phạm single-instance limit.

📋 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 dựa trên AWS DMS Documentation (Best Practices for Migrating Large Databases, cập nhật 2026):

• ❌ [SAI] Increase the value of the ParallelLoadThreads parameter in the DMS task settings for the tables.
  ❌ Sai vì: Parameter ParallelLoadThreads (default=1, max=16) chỉ kiểm soát số threads per table cho small/medium tables (<1GB), không scale hiệu quả cho 40TB (gây I/O bottleneck trên single instance). AWS khuyến nghị dùng MaxFullLoadSubTasks và parallel-load-types thay thế cho large DB, tránh overload CPU/memory single task.

• ✅ [ĐÚNG] Use a smaller set of tables with each DMS task. Set the MaxFullLoadSubTasks parameter to a higher value.
  ✅ Đúng vì: Splitting tables vào multiple tasks cho phép chạy parallel replication (nhiều instances/tasks cùng lúc). Tăng MaxFullLoadSubTasks (>8) kích hoạt sub-task parallelism per table (chia theo rows/PK), tăng tốc full load 5-10x cho large tables mà không cần thêm hardware (phù hợp khi instance đã đủ resources).

• ❌ [SAI] Use a smaller set of tables with each DMS task. Set the MaxFullLoadSubTasks parameter to a lower value.
  ❌ Sai vì: Giảm MaxFullLoadSubTasks (<8) sẽ giảm parallelism, làm full load chậm hơn (ít sub-tasks hơn → sequential hơn). Ngược với yêu cầu scale và reduce time; AWS docs khuyên tăng giá trị này cho large migrations.

• ✅ [ĐÚNG] Use parallel load with different data boundaries for larger tables.
  ✅ Đúng vì: DMS hỗ trợ parallel full load với parallel-load-type (e.g., bounds, range, lob) + table-settings để chia large tables theo data boundaries (PK ranges/partitions). Giảm thời gian load table lớn từ days xuống <1 ngày, kết hợp CDC seamless (cập nhật DMS engine 3.5.x+).

• ❌ [SAI] Run the DMS tasks on a larger instance class. Increase local storage on the instance.
  ❌ Sai vì: Câu hỏi đã xác nhận replication instance đủ resources (CPU/network/storage). Nâng instance class/storage chỉ tốn kém, không giải quyết single task bottleneck (DMS limit ~16 vCPU/instance). Ưu tiên horizontal scaling (multiple tasks/sub-tasks) theo AWS best practices.

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

• AWS DMS Developer Guide: Using parallel load for large tables & MaxFullLoadSubTasks.
• Best Practices for Large Migrations: Migrating Oracle to Aurora PostgreSQL (2024-2026 updates).
• DMS Engine Version 3.5.x: Hỗ trợ enhanced parallelism cho >10TB DBs.

🎓 Lời khuyên DevOps: Test với DMS Preview mode + CloudWatch metrics (FullLoadThroughput) để tune parameters trước production! 🚀

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

Câu hỏi mô tả một công ty dịch vụ tài chính đang chạy cơ sở dữ liệu MySQL on-premises, lưu trữ thông tin tương tác khách hàng và lời khuyên tài chính. Write traffic (lưu lượng ghi) ổn định và dự đoán được, nhưng read traffic (lưu lượng đọc) tăng đột biến vào cuối tháng do báo cáo, dẫn đến tình trạng quá tải.

Công ty muốn chuyển sang AWS với giải pháp:

• Scale read traffic linh hoạt để đáp ứng biến động lớn.
• Không ảnh hưởng performance của write traffic.
• Scaling events không gây downtime (không gián đoạn dịch vụ).

Yêu cầu giải pháp hiệu quả vận hành nhất (MOST operationally efficient), tận dụng dịch vụ AWS để tự động hóa, giảm can thiệp thủ công. 📘 (Dựa trên best practices AWS Database Migration và Scaling, cập nhật đến 2026 với Aurora Serverless v2 và Auto Scaling replicas).

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

Đáp án đúng:
Deploy an Amazon Aurora MySQL DB cluster. Select a Cross-AZ configuration with an Aurora Replica. Create an Aurora Auto Scaling policy to adjust the number of Aurora Replicas based on CPU utilization. Direct all read-only reporting traffic to the reader endpoint for the DB cluster.

Lý do 🛠️:

• Aurora MySQL là dịch vụ managed, tương thích hoàn hảo với MySQL on-prem, hỗ trợ read replicas tự động scale dựa trên CPU (Aurora Auto Scaling - tính năng từ 2019, cập nhật ổn định đến 2026).
• Cross-AZ đảm bảo HA (high availability), replicas scale từ 1-15 mà không downtime (thêm replica trong giây lát).
• Reader endpoint tự động phân tải read traffic sang replicas, không ảnh hưởng writer instance (primary chịu write ổn định).
• Operationally efficient nhất: Tự động, serverless-like scaling, không cần thủ công schedule hay DMS replication phức tạp. Tiết kiệm chi phí chỉ scale khi cần.
  Nguồn: AWS Aurora Auto Scaling Docs (2026 update).

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

• ❌ Phương án SAI:
  Deploy a MySQL primary node on Amazon EC2 in one Availability Zone. Deploy a MySQL read replica on Amazon EC2 in a different Availability Zone. Configure a scheduled scaling event to increase the CPU capacity and RAM capacity within the MySQL read replica the day before each known traffic surge. Configure a scheduled scaling event to reduce the CPU capacity and RAM capacity within the MySQL read replica the day after each known traffic surge.
  Giải thích sai 🚫: Sử dụng EC2 self-managed MySQL thay vì RDS/Aurora, tốn công quản lý OS/patches. Scheduled scaling thủ công (dựa lịch cuối tháng) không linh hoạt với "sudden increases" bất ngờ, có thể gây downtime khi resize instance (vertical scale EC2 ~5-15 phút). Không hiệu quả vận hành, thiếu auto scaling thông minh. Không dùng managed service.

• ✅ Phương án ĐÚNG (đã giải thích chi tiết ở trên):
  Deploy an Amazon Aurora MySQL DB cluster. Select a Cross-AZ configuration with an Aurora Replica. Create an Aurora Auto Scaling policy to adjust the number of Aurora Replicas based on CPU utilization. Direct all read-only reporting traffic to the reader endpoint for the DB cluster.
  Giải thích đúng 🌟: Hoàn hảo đáp ứng scale read tự động, zero-downtime qua horizontal scaling replicas, tách biệt read/write, managed bởi AWS.

• ❌ Phương án SAI:
  Deploy an Amazon RDS for MySQL Multi-AZ database as a write database. Deploy a second RDS for MySQL Multi-AZ database that is configured as an auto scaling read-only database. Use AWS Database Migration Service (AWS DMS) to continuously replicate data from the write database to the read-only database. Direct all read-only reporting traffic to the reader endpoint for the read-only database.
  Giải thích sai 🚫: Hai RDS Multi-AZ riêng biệt + DMS replication tạo độ trễ (lag) dữ liệu (không real-time như native replication), phức tạp quản lý hai cluster, chi phí cao gấp đôi. RDS read replicas chỉ scale thủ công hoặc qua ASG hạn chế, không mượt như Aurora Auto Scaling. Không efficient, DMS thường dùng cho migration chứ không production read scaling.

• ❌ Phương án SAI:
  Deploy an Amazon DynamoDB database. Create a DynamoDB auto scaling policy to adjust the read capacity of the database based on target utilization. Direct all read traffic and write traffic to the DynamoDB database.
  Giải thích sai 🚫: DynamoDB NoSQL không tương thích MySQL relational schema (cần refactor app lớn, không feasible cho financial data phức tạp). Scale read/write chung một table, có thể ảnh hưởng write nếu surge read. Không giữ nguyên MySQL queries, yêu cầu migrate dữ liệu lớn gây downtime ban đầu. Không phù hợp migrate MySQL trực tiếp.
  Nguồn bổ sung: AWS RDS vs Aurora Comparison (2026).

Tóm tắt khuyến nghị 💡: Chọn Aurora để tối ưu scale read/write riêng biệt, zero-downtime, managed. Migrate dùng DMS hoặc native snapshot cho seamless chuyển đổi! 🚀

🧩 Phân tí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 2017 Enterprise Edition trên Amazon RDS với tùy chọn Multi-AZ được bật (để đảm bảo tính sẵn sàng cao qua failover tự động). Automatic backups được kích hoạt và thời gian lưu trữ bản sao lưu (retention period) là 7 ngày. Yêu cầu là thêm một read replica (bản sao chỉ đọc) vào DB instance RDS hiện tại để mở rộng khả năng đọc dữ liệu, giảm tải cho DB chính.

📘 Bối cảnh kỹ thuật chính:

• Read Replica trong RDS là bản sao chỉ đọc của DB source, sử dụng asynchronous replication (trên SQL Server), giúp scale read traffic.
• Điều kiện tạo read replica cho SQL Server trên RDS (cập nhật đến 2026): SQL Server Enterprise/Standard từ 2016+, backup retention ≥1 ngày, source DB phải ở chế độ Single-AZ hoặc Multi-AZ (không yêu cầu thay đổi).
• Không có ràng buộc nào yêu cầu tắt Multi-AZ, thay đổi backup retention, hay dùng snapshot để tạo replica.

🛠️ Mục tiêu: Tìm cách thêm read replica đơn giản nhất, tuân thủ best practices AWS mà không gián đoạn dịch vụ.

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

Đáp án đúng: Add the new read replica without making any other changes to the RDS database.

Lý do:

• Với SQL Server 2017 Enterprise trên RDS, bạn có thể tạo read replica trực tiếp từ DB source qua AWS Console, CLI hoặc SDK mà không cần thay đổi bất kỳ cấu hình nào (Multi-AZ vẫn bật, retention 7 ngày >0).
• RDS tự động sử dụng automatic backups để khởi tạo replica (seed process), và replication diễn ra asynchronous.
• Đây là cách native, nhanh chóng nhất, không downtime, phù hợp Multi-AZ (replica sẽ là Single-AZ mặc định).
• Cập nhật AWS 2026: Hỗ trợ đầy đủ read replicas cho SQL Server Enterprise Multi-AZ mà không có hạn chế mới.

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

• E ❌ Phương án SAI: Turn off the Multi-AZ feature, add the read replica, and turn Multi-AZ back on again.
  Giải thích: Không cần thiết! Multi-AZ không cản trở việc tạo read replica trên RDS SQL Server (từ 2016+). Tắt Multi-AZ gây downtime ngắn (failover ~1-2 phút), rủi ro mất HA tạm thời. AWS docs xác nhận source có thể Multi-AZ.

• E ❌ Phương án SAI: Set the backup retention period to 0, add the read replica, and set the backup retention period to 7 days again.
  Giải thích: Sai lầm lớn! Để tạo read replica, retention phải ≥1 ngày (RDS dùng backup để seed replica). Retention=0 ngăn tạo replica. Ở đây đã là 7 ngày, không cần thay đổi, tránh gián đoạn backup và tăng chi phí thao tác không cần.

• E ❌ Phương án SAI: Restore a snapshot to a new RDS DB instance and add the DB instance as a replica to the original database.
  Giải thích: Không khả thi! Restore snapshot tạo standalone DB instance, không tự động replicate từ source. RDS không hỗ trợ "add as replica" sau restore (chỉ tạo replica trực tiếp từ source). Cách này lỗi thời, phức tạp, và không async replicate liên tục.

• A ✅ Phương án ĐÚNG: Add the new read replica without making any other changes to the RDS database.
  Giải thích: Hoàn hảo! RDS hỗ trợ tạo read replica trực tiếp (max 15 replicas), dùng backup hiện tại để sync. Multi-AZ source OK, retention 7 ngày lý tưởng. Lệnh ví dụ: aws rds create-db-instance-read-replica --db-instance-identifier replica-name --source-db-instance-identifier source-id.

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

• AWS RDS Read Replicas for SQL Server ✅ (Xác nhận Multi-AZ hỗ trợ, retention ≥1).
• RDS SQL Server Best Practices 🛠️ (Enterprise 2016+ full support).
• RDS Multi-AZ & Replication Limits (Không yêu cầu tắt Multi-AZ).

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 cụ thể, hỏi thêm nhé!

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

Câu hỏi tập trung vào một tình huống bảo mật AWS RDS: Một công ty đang sử dụng Amazon RDS for PostgreSQL DB instance dung lượng 1 TB để lưu trữ dữ liệu người dùng, nhưng qua kiểm tra bảo mật, phát hiện instance này không được mã hóa tại chỗ (not encrypted at rest).
📌 Mục tiêu chính: Chuyên viên database cần sửa chữa vấn đề này với ÍT NHẤT thời gian gián đoạn (LEAST downtime) và KHÔNG MẤT DỮ LIỆU (no data loss).
🛠️ Bối cảnh kỹ thuật: RDS PostgreSQL không hỗ trợ bật mã hóa at-rest sau khi tạo instance (theo tài liệu AWS cập nhật 2024-2026). Phải sử dụng các phương pháp gián tiếp như snapshot, read replica hoặc DMS để migrate sang instance mới có mã hóa (sử dụng AWS KMS). Với dung lượng lớn 1TB, cần ưu tiên phương pháp hỗ trợ ongoing replication để đồng bộ liên tục, giảm thiểu downtime khi cutover.

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

Create a new encrypted DB instance and use AWS Database Migration Service (AWS DMS) to migrate the existing database to the encrypted DB instance. Once the instances are in sync, modify the application to connect to the new DB instance.

Lý do lựa chọn:

• 🟢 Phương pháp này đảm bảo zero data loss nhờ DMS hỗ trợ full load + ongoing CDC (Change Data Capture) cho PostgreSQL (homogeneous migration).
• ⏱️ Least downtime: Chỉ gián đoạn ngắn khi cutover (modify application endpoint), thường vài giây đến phút, vì DMS đồng bộ real-time.
• 📈 Phù hợp quy mô 1TB: DMS xử lý lớn hiệu quả, hỗ trợ multi-AZ cho high availability.
• Theo AWS best practices (2026), DMS là lựa chọn khuyến nghị cho migration encrypted với minimal impact.

📋 Giải thích tất cả các phương án (A, B, C, D)

• Phương án A: Modify the DB instance by using the RDS management console, and enable encryption. Apply the changes immediately.
  ❌ Sai: RDS không hỗ trợ bật mã hóa at-rest trên instance đang chạy (irrespective of engine như PostgreSQL). Thao tác này sẽ thất bại, gây lỗi. Không có downtime nhưng không khả thi, vi phạm nguyên tắc "correct this issue".

• Phương án B: Create a manual DB instance snapshot and then create an encrypted copy of that snapshot. Use this snapshot to create a new encrypted DB instance. Modify the application to connect to the new DB instance.
  ❌ Sai: Snapshot thủ công và copy encrypted tạo DB mới có data loss (dữ liệu ghi sau snapshot bị mất) và downtime cao (restore 1TB mất hàng giờ, rebuild indexes, rồi switch app). Không hỗ trợ ongoing sync, không phải "least downtime".

• Phương án C: Create a new encrypted DB instance and use AWS Database Migration Service (AWS DMS) to migrate the existing database to the encrypted DB instance. Once the instances are in sync, modify the application to connect to the new DB instance.
  ✅ Đúng: Như đã giải thích ở trên. DMS (với PostgreSQL source/target) hỗ trợ CDC full để sync liên tục, cutover nhanh chóng. Hoàn hảo cho no data loss + minimal downtime.

• Phương án D: Create an encrypted read replica. Once the read replica is in sync, promote it to primary. Modify the application to connect to the new primary instance.
  ❌ Sai: Không thể tạo encrypted read replica từ primary unencrypted (RDS yêu cầu encryption status phải khớp). Promote replica chỉ có downtime ngắn (~1-2 phút), nhưng bước tạo replica sẽ fail. Không khả thi theo RDS docs.

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

• 🖥️ AWS RDS Encryption: Xác nhận không modify encryption post-creation; dùng snapshot/DMS/read replica.
• 🔄 AWS DMS for PostgreSQL: Hỗ trợ CDC, homogeneous migration encrypted.
• 📊 RDS Read Replicas Limitations: Encryption phải giống primary.
• 🎯 Best Practices: AWS Well-Architected Framework - Reliability Pillar (Migration patterns).

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 Terraform/CLI, hãy hỏi nhé!

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

Câu hỏi mô tả một công ty quảng cáo đang xây dựng backend cho nền tảng bidding platform (nền tảng đấu giá/thầu), nơi cần một giải pháp datastore tiết kiệm chi phí (cost-effective). Các yêu cầu chính bao gồm:

• Chịu được sự tăng đột ngột về lượng giao dịch ghi (sudden increase in write transactions): Cần khả năng scale writes tự động và linh hoạt để xử lý burst traffic mà không gián đoạn.
• Làm cho các thay đổi dữ liệu có sẵn trong luồng dữ liệu gần thời gian thực (near real-time data stream): Dữ liệu thay đổi phải được stream ra ngay lập tức để các ứng dụng khác (như analytics hoặc bidding logic) có thể consume.

Đây là tình huống điển hình cho NoSQL database với tính năng auto-scaling và change data capture (CDC) streams, phù hợp với workload bidding cao writes (mỗi bid là một write) và cần stream để trigger real-time actions. Kiến thức cập nhật đến 2026: AWS ưu tiên DynamoDB cho các use case này nhờ DynamoDB Streams (near real-time, max 24h retention) và auto scaling (provisioned hoặc on-demand mode).

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

• AWS DynamoDB Developer Guide: DynamoDB Streams và Auto Scaling.
• AWS Well-Architected Framework: Reliability Pillar cho bursty workloads.

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

Đáp án đúng: Amazon DynamoDB table with DynamoDB auto scaling

Lý do:

• Cost-effective: DynamoDB hỗ trợ on-demand capacity mode (pay-per-request, không cần provision RCU/WCU trước) hoặc provisioned mode với auto scaling (tự động scale writes/reads từ min đến max capacity dựa trên utilization >70%, scale up/down trong 1-5 phút). Hoàn hảo cho sudden write spikes mà không lãng phí.
• Sudden write increase: Auto scaling xử lý burst writes seamless, kết hợp DynamoDB Accelerator (DAX) nếu cần low-latency.
• Near real-time data stream: DynamoDB Streams capture item-level changes (insert/update/delete) trong <200ms, stream ra Kinesis/ Lambda/ Spark real-time.
• Phù hợp bidding platform: High writes (bids), low reads, serverless, multi-AZ by default.

🛠️ Phân tích tất cả các phương án (đúng/sai)

• ❌ Amazon Aurora MySQL Multi-AZ DB cluster
  Sai vì: Aurora MySQL là relational DB, scale reads tốt với replicas nhưng writes chỉ scale vertically (instance size) hoặc Aurora Serverless v2 (auto scale compute), không hiệu quả cho sudden write spikes (cần manual scale hoặc Serverless v2 với cold start). Multi-AZ chỉ cho HA, không có native streams (phải dùng DMS CDC, latency cao hơn). Costly cho write-heavy, không cost-effective so với NoSQL.

• ❌ Amazon Keyspaces (for Apache Cassandra)
  Sai vì: Keyspaces là managed Cassandra, xuất sắc cho high writes (partition-tolerant, scale horizontal bằng adding nodes). Tuy nhiên, không có native near real-time streams như DynamoDB (chỉ hỗ trợ CDC export to S3/Kinesis với delay, không item-level real-time). Auto scaling có nhưng phức tạp hơn (manual token ranges), và cost cao hơn DynamoDB cho bursty writes không predictable.

• ✅ Amazon DynamoDB table with DynamoDB auto scaling
  Đúng vì: Như giải thích trên – auto scaling xử lý write spikes tự động (scale RCU/WCU trong vài giây), DynamoDB Streams cung cấp near real-time data changes (shard-based, low latency). Serverless, pay-per-use, lý tưởng cho bidding (ví dụ: real-time leaderboards via Streams + Lambda). Cập nhật 2026: Hỗ trợ Global Tables cho multi-region nếu cần.

• ❌ Amazon DocumentDB (with MongoDB compatibility) cluster with a replica instance in a second Availability Zone
  Sai vì: DocumentDB scale reads với replicas (multi-AZ cho HA), nhưng writes chỉ primary node, scale bằng sharding manual/complex (không auto scaling đơn giản cho writes). Có change streams (MongoDB oplog-like), nhưng latency cao hơn DynamoDB Streams và yêu cầu cluster config phức tạp. Không cost-effective cho sudden writes (provisioned instances), dễ over-provision.

🧩 Kết luận: DynamoDB là lựa chọn tối ưu cho workload write-heavy, bursty, real-time stream trên AWS, theo best practices DevOps (Infrastructure as Code với CDK/Terraform).

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

Câu hỏi xoay quanh một công ty thương mại điện tử sử dụng Amazon Aurora MySQL DB cluster để xử lý thanh toán. Chuyên viên cơ sở dữ liệu nhận thấy Aurora tự động thực hiện các hành động bảo trì (maintenance actions) định kỳ, nhưng cửa sổ bảo trì sắp tới xung đột với sự kiện bán hàng lớn của công ty. Yêu cầu là tìm giải pháp với nỗ lực vận hành thấp nhất (LEAST operational effort) để giải quyết vấn đề này.

🔍 Bối cảnh kỹ thuật:

• Amazon Aurora là dịch vụ cơ sở dữ liệu quan hệ được quản lý (managed relational database) trên AWS, hỗ trợ MySQL/PostgreSQL với tính năng cluster cao khả dụng (high availability).
• Các hành động bảo trì định kỳ của Aurora bao gồm cập nhật engine, vá lỗi bảo mật, hoặc cải thiện hiệu suất, thường diễn ra trong maintenance window (cửa sổ bảo trì) được cấu hình (mặc định 60 phút, có thể tùy chỉnh).
• Theo tài liệu AWS mới nhất (cập nhật đến 2026), Aurora cho phép quản lý maintenance actions một cách linh hoạt qua Console, CLI, hoặc API, nhằm giảm thiểu downtime (thời gian ngừng hoạt động thường <60 giây với Multi-AZ).

Mục tiêu: Tránh gián đoạn dịch vụ trong sự kiện bán hàng mà không cần can thiệp phức tạp.

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

Đáp án đúng: Defer the maintenance action in the AWS Management Console or by using the AWS CLI.

Lý do chi tiết 🛠️:

• AWS cho phép hoãn (defer) hành động bảo trì lên đến 3 lần, mỗi lần tối đa 7 ngày, giúp tránh xung đột ngay lập tức mà không cần thay đổi kiến trúc cluster.
• Đây là giải pháp ít nỗ lực nhất: Chỉ cần vài lệnh CLI (như aws rds defer-maintenance-action) hoặc click trong Console, không yêu cầu tạo instance mới, scale cluster, hay failover thủ công.
• Sau khi defer, maintenance sẽ tự động lên lịch lại vào cửa sổ tiếp theo, đảm bảo cluster vẫn an toàn lâu dài.
• Phù hợp với best practice DevOps: Tối ưu hóa automation và minimal intervention.

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

• AWS Documentation: Managing maintenance actions for Amazon Aurora (cập nhật 2025-2026).
• AWS CLI Reference: aws rds defer-maintenance-action (CLI v2.15+).

📋 Phân tích tất cả các phương án (đúng/sai)

• Add a new Aurora Replica so that the maintenance action occurs on the Aurora Replica first.
  ❌ Sai: Việc thêm Aurora Replica (read replica) không thay đổi thứ tự maintenance. Maintenance luôn bắt đầu từ writer instance (primary) trước, sau đó mới đến replicas. Thêm replica chỉ tăng read capacity, nhưng không tránh được downtime trên primary (vẫn xung đột sales event). Nỗ lực cao: Phải scale cluster, monitor failover (có thể mất 1-2 phút).

• Defer the maintenance action in the AWS Management Console or by using the AWS CLI.
  ✅ Đúng: Như đã giải thích ở trên. Đây là cách chính thức và đơn giản nhất từ AWS, hỗ trợ cả auto-defer cho một số minor updates (tính năng mới từ 2024). Không ảnh hưởng HA, zero thêm resource.

• Delete the maintenance action in the AWS Management Console or by using the AWS CLI.
  ❌ Sai: AWS không hỗ trợ xóa (delete) maintenance actions vĩnh viễn. Chỉ có tùy chọn defer hoặc apply ngay. Xóa sẽ vi phạm security compliance (bỏ qua critical patches), dẫn đến rủi ro bảo mật. CLI không có lệnh delete-maintenance-action.

• Add a new Aurora standby DB instance so that the maintenance action occurs on the standby DB instance first.
  ❌ Sai: Aurora không sử dụng khái niệm "standby DB instance" riêng biệt như RDS Single-AZ. Thay vào đó là Aurora Replicas (reader/writer promotion). Thêm standby không tồn tại và không làm maintenance chạy trên standby trước – primary vẫn bị ảnh hưởng đầu tiên. Nỗ lực cao tương tự option A, không giải quyết gốc rễ.

🏆 Kết luận và best practice

Giải pháp defer là optimal cho scenario production như payments (high traffic). Để tránh tương lai: 📅 Cấu hình maintenance window ngoài giờ cao điểm (Modifiable via Console), enable auto minor version upgrade (tự động patch không downtime), và monitor qua Amazon RDS Event Notifications + CloudWatch Events. Nếu cluster lớn, xem xét Aurora Serverless v2 cho elastic scaling (cập nhật 2025).

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! 🚀

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

🧩 Câu hỏi tập trung vào quy trình copy một manual snapshot mã hóa (encrypted) của Amazon RDS for PostgreSQL từ tài khoản chính (main account) ở vùng us-east-1 sang tài khoản test mới ở vùng us-west-2, trong môi trường sử dụng AWS Organizations để cô lập các tài khoản. Snapshot gốc đã được tạo và mã hóa bằng KMS customer managed key (CMK).

🛠️ Thách thức chính:

• Cross-region (us-east-1 → us-west-2): Không thể share snapshot trực tiếp cross-region; phải copy snapshot sang vùng đích trong cùng tài khoản source trước.
• Cross-account: Snapshot mã hóa yêu cầu quyền truy cập KMS key qua key policy (cho phép decrypt/re-encrypt). Tài khoản đích phải copy shared snapshot để sở hữu và restore thành DB instance (không restore trực tiếp từ shared snapshot).
• Encryption: Phải duy trì mã hóa, sử dụng KMS CMK phù hợp ở vùng đích. AWS hỗ trợ multi-Region keys (MRKs) và key replication/sharing cross-account (cập nhật 2023-2026 với delegated admin trong Organizations).
• Chọn 3 bước kết hợp để hoàn thành.

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

Các phương án đúng là: thứ 2 (Create a new AWS Key Management Service (AWS KMS) customer managed key in the main account in us-east-1. Copy the key to the test account in us-west-2.), thứ 3 (Copy the snapshot of the source DB instance to us-west-2 by using the AWS Key Management Service (AWS KMS) customer managed key. Enable encryption on the new snapshot. Share the snapshot with the test account.), và thứ 6 (In the test account, copy the shared snapshot by using the copied AWS Key Management Service (AWS KMS) key to create a final encrypted snapshot. Use the final snapshot to create a new RDS for PostgreSQL DB instance.).

📈 Lý do chọn (kết hợp 3 bước này hoàn thiện quy trình):

• Tạo và copy KMS key từ main us-east-1 sang test us-west-2 để test account có key riêng ở vùng đích, tránh phụ thuộc hoàn toàn vào source key policy (an toàn hơn với Organizations).
• Copy snapshot cross-region trong main account sử dụng KMS key (enable encryption), sau đó share với test account (bây giờ ở cùng vùng us-west-2).
• Trong test account, sử dụng copied KMS key để copy shared snapshot thành snapshot riêng (final), rồi restore thành DB instance. 🛡️ Điều này đảm bảo encryption xuyên suốt, tuân thủ least privilege, và hỗ trợ MRK replication (cập nhật AWS KMS 2023+).

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

✅ Phương án 2: Create a new AWS Key Management Service (AWS KMS) customer managed key in the main account in us-east-1. Copy the key to the test account in us-west-2.
✅ Đúng. Tạo CMK mới ở main us-east-1 (có thể là MRK primary), sau đó copy key (qua replication feature trong KMS với AWS Organizations delegated admin, hỗ trợ cross-account cross-region từ 2023). Key replica ở test us-west-2 cho phép test account encrypt/decrypt độc lập, cần thiết cho bước copy final snapshot.

✅ Phương án 3: Copy the snapshot of the source DB instance to us-west-2 by using the AWS Key Management Service (AWS KMS) customer managed key. Enable encryption on the new snapshot. Share the snapshot with the test account.
✅ Đúng. Trong main account: Copy snapshot cross-region sang us-west-2 sử dụng CMK (từ bước 2), bật encryption cho snapshot mới. Sau đó share manual snapshot với test account (cùng vùng). Bước bắt buộc vì share chỉ same-region.

✅ Phương án 6: In the test account, copy the shared snapshot by using the copied AWS Key Management Service (AWS KMS) key to create a final encrypted snapshot. Use the final snapshot to create a new RDS for PostgreSQL DB instance.
✅ Đúng. Test account copy shared snapshot sử dụng copied KMS key (từ bước 2) để tạo snapshot encrypted riêng (final), vì không restore trực tiếp từ shared snapshot. Sau đó restore final snapshot thành RDS DB instance PostgreSQL.

❌ Phương án 1: Create a new AWS Key Management Service (AWS KMS) customer managed key in the main account in us-east-1. Replicate the key ID and key material to the test account in us-west-2.
❌ Sai. Không thể thủ công "replicate key ID và key material" (KMS không export material trực tiếp cho customer keys do security; chỉ import external material nếu cần). Sử dụng copy key hoặc policy sharing/MRK replication thay thế.

❌ Phương án 4: Copy the snapshot of the source DB instance to the test account in us-east-1. Switch to the test account and share the snapshot with us-west-2.
❌ Sai. Copy cross-account same-region (us-east-1) trước rồi "share with us-west-2" không khả thi vì snapshot share chỉ same-region. Phải copy cross-region trong source account trước.

❌ Phương án 5: In the test account, copy the shared snapshot to create a final snapshot. Use the final snapshot to create a new RDS for PostgreSQL DB instance.
❌ Sai. Thiếu chỉ định KMS key cụ thể cho encryption (snapshot source encrypted, copy cần key để re-encrypt). Không đề cập "copied KMS key", có thể fail nếu không access source key hoặc dùng key riêng đúng cách.

📘 Tài liệu tham khảo

• 🛡️ RDS User Guide - Copying an encrypted snapshot cross-Region: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_CopySnapshot.html#USER_CopySnapshot.encryption (Cross-region yêu cầu KMS key ở dest region).
• 🔑 KMS Developer Guide - Sharing keys across accounts: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying-external-accounts.html (Key policy cho decrypt/re-encrypt).
• 🌍 RDS User Guide - Sharing snapshots: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html (Same-region only, copy trước khi restore).
• 🔄 KMS Multi-Region keys & replication (cập nhật 2023-2026): https://docs.aws.amazon.com/kms/latest/developerguide/multi-region-keys-overview.html (Hỗ trợ copy/replicate cross-account qua Organizations).
• 📋 AWS Exam DOP-C02 blueprint: AWS Certified DevOps Engineer Professional - Domain 4: Automation (RDS/KMS integration).

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

Câu hỏi xoay quanh một chuyên gia cơ sở dữ liệu (database specialist) đang hỗ trợ công ty triển khai website mới sử dụng Amazon Aurora MySQL DB cluster với nhiều Aurora Replicas (các bản sao đọc). Website này thay thế hệ thống on-premises cũ kết nối với cơ sở dữ liệu quan hệ legacy có vấn đề ổn định (stability issues). Công ty muốn kiểm tra khả năng phục hồi (resiliency) của Aurora cluster để đảm bảo độ tin cậy. 🛠️

Mục tiêu chính: Tìm hành động phù hợp để test resiliency của Aurora cluster, tập trung vào khả năng chịu lỗi như failover, replica promotion mà không làm gián đoạn production. Aurora nổi bật với high availability (HA) tự động failover trong vòng 30 giây, và các công cụ test fault tolerance. (Kiến thức cập nhật AWS 2024-2026: Aurora hỗ trợ Fault Injection Queries từ phiên bản 3.x+).

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

Đáp án đúng: Submit a fault injection query to one of the Aurora Replica instances by connecting to the endpoint for the Aurora Replica.

Lý do chi tiết:
🧩 Aurora cung cấp Fault Injection Queries (FIQ) – một tính năng mạnh mẽ để inject faults (tiêm lỗi) vào cụ thể Aurora Replica qua endpoint riêng, giúp simulate các tình huống như failover, replica lag, hoặc crash mà không ảnh hưởng writer instance (primary). Điều này test resiliency thực tế, đo lường thời gian failover (thường <30s), replication lag, và khả năng tự heal. Kết nối qua Replica endpoint đảm bảo an toàn, chỉ test read replicas. Đây là best practice từ AWS để verify HA mà không dùng công cụ bên ngoài. ✅ Hoàn hảo cho kịch bản test stability thay thế legacy DB!

📋 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 nội dung gốc tiếng Anh. Tôi sử dụng ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng dựa trên tài liệu AWS mới nhất.

• Simulate a failover test of the Aurora cluster resiliency by using the failover testing feature from the Resiliency Toolkit.
  ❌ Sai hoàn toàn. Không tồn tại Resiliency Toolkit hoặc "failover testing feature" dành riêng cho Aurora/RDS trong AWS (tính đến 2026). AWS có AWS Fault Injection Simulator (FIS) cho EC2/ECS, nhưng không tích hợp trực tiếp với Aurora như vậy. Sử dụng sẽ không test được resiliency cụ thể của cluster, dẫn đến confusion hoặc không khả dụng.

• Submit a fault injection query to one of the Aurora Replica instances by connecting to the endpoint for the Aurora Replica.
  ✅ Đúng. Như giải thích trên, FIQ là công cụ chính thức của Aurora (hỗ trợ MySQL/PostgreSQL), cho phép chạy query như ADMIN_INJECT_FAILOVER trên Replica endpoint để simulate failover/resiliency. An toàn, granular, và khuyến nghị bởi AWS cho testing HA. Test thực tế replication và promotion.

• Simulate a failover test of the Aurora cluster by using the PromoteReadReplica API operation to promote one of the read replica DB instances to a standalone Aurora DB instance.
  ❌ Sai. PromoteReadReplica API chỉ áp dụng cho RDS read replicas (không phải Aurora). Trong Aurora, promotion tự động qua failover, không dùng API này để tạo "standalone instance" – sẽ gây split cluster, data inconsistency, và downtime lớn. Không phù hợp test resiliency mà làm hỏng cluster!

• Use Amazon RDS Performance Insights to capture resiliency-related metrics for the Aurora cluster during periods of high load.
  ❌ Sai. Performance Insights là tool monitoring/performance (metrics như CPU, I/O, queries chậm), không dùng để inject faults hoặc simulate failover. Nó chỉ capture metrics thụ động trong high load, không test resiliency chủ động như crash/replica failure. Phù hợp observe, không phải test!

📘 Tài liệu tham khảo

• AWS Documentation - Fault Injection Queries: Testing failover for Aurora with fault injection queries (Cập nhật 2024+).
• Aurora High Availability Best Practices: Amazon Aurora Resiliency.
• Exam Prep DOP-C02: AWS Certified DevOps Engineer Professional guide nhấn mạnh FIQ cho resiliency testing (2024 edition).
• AWS re:Post & Blogs: Tìm "Aurora Fault Injection" cho case studies thực tế.

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

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

Câu hỏi xoay quanh việc khắc phục sự cố (troubleshoot) cho cơ sở dữ liệu Amazon Aurora Serverless MySQL. Ban đầu, công ty triển khai với instance class db.t3.medium, tải sử dụng nhẹ nên hiệu suất bình thường. Tuy nhiên, khi số lượng kết nối client tăng lên, ứng dụng gặp độ trễ cao (higher latency) và mất kết nối偶尔 (occasional lost connections). Chuyên gia xác định cần hỗ trợ tối đa 2.000 kết nối đồng thời (simultaneous connections).
Yêu cầu chính: Tìm giải pháp tiết kiệm chi phí nhất (MOST cost-effectively) để đáp ứng.
🛠️ Vấn đề cốt lõi: Giới hạn max_connections mặc định của MySQL (thường ~150-300 tùy instance) không đủ, dẫn đến từ chối kết nối khi vượt ngưỡng. Với Aurora Serverless (phiên bản v2 hỗ trợ instance class như db.t3), giải pháp cần tập trung vào tối ưu hóa parameter mà không scale tài nguyên không cần thiết, vì tải nhẹ chỉ tăng connections.

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

• AWS RDS Parameter Groups (cập nhật 2024-2026: Không chỉnh sửa default group).
• Aurora MySQL Parameters (max_connections là dynamic parameter, apply ngay).
• Aurora Serverless v2 Limits (connections scale theo capacity, nhưng parameter quyết định max).

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

Đáp án đúng: Create a new parameter group for the MySQL engine that the database uses. Set the max_connections value to 2,000. Assign the parameter group to the DB instance. Apply the changes immediately.

Lý do:

• 🛠️ Tạo parameter group mới (custom) là best practice của AWS để tránh ảnh hưởng default group (có thể dùng lại cho DB khác).
• max_connections=2000 giải quyết trực tiếp vấn đề connections mà không cần reboot (dynamic parameter, apply ngay lập tức).
• Tiết kiệm chi phí nhất vì không scale instance (giữ db.t3.medium, tải nhẹ), chỉ thay đổi config miễn phí. Với Aurora Serverless v2, capacity tự scale theo nhu cầu mà không tốn thêm.
• ✅ Hoàn hảo cho tình huống: Latency/lost connections do hết slot connections, không phải CPU/RAM overload.

🧩 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, đánh dấu ✅/❌ và giải thích hoàn toàn bằng tiếng Việt:

• Modify the instance class to db.r3.xlarge. Apply the changes immediately.
  ❌ Sai: db.r3.xlarge là instance thế hệ cũ (R3 gen3, 2013), không còn hỗ trợ mới trên Aurora Serverless v2 (chỉ dùng T4g/R6g/R7g/M6g mới nhất đến 2026). Scale lên lớn (4 vCPU, 30.5 GiB RAM) tốn kém hơn nhiều (giá ~4-5x db.t3.medium), dù hỗ trợ connections cao hơn nhưng không cần vì tải nhẹ. Không giải quyết trực tiếp max_connections parameter.

• Edit the default parameter group for the MySQL engine that the database uses. Change the max_connections value to 2,000. Reboot the DB instance to apply the new value.
  ❌ Sai: Không được chỉnh sửa default parameter group (AWS best practice: Default là read-only cho engine chuẩn, chỉnh sửa gây lỗi và không khuyến khích). Reboot không cần thiết vì max_connections là dynamic (apply ngay). Giải pháp này rủi ro cao và không cost-effective do downtime reboot.

• Create a new parameter group for the MySQL engine that the database uses. Set the max_connections value to 2,000. Assign the parameter group to the DB instance. Apply the changes immediately.
  ✅ Đúng: Như giải thích trên – custom group mới, set parameter đúng, apply ngay không reboot. Tiết kiệm, an toàn, phù hợp Aurora Serverless v2 (cập nhật 2026: Hỗ trợ max_connections lên hàng nghìn tùy capacity).

• Modify the instance class to db.t3.large. Apply the changes immediately.
  ❌ Sai: Scale lên db.t3.large (2 vCPU, 8 GiB RAM) tăng chi phí ~2x so với medium, dù hỗ trợ connections nhiều hơn (nhờ RAM lớn). Nhưng không tối ưu vì không chỉnh max_connections parameter – connections vẫn bị giới hạn bởi config MySQL. Tải nhẹ nên scale thừa, không cost-effective nhất.