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

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

Câu hỏi xoay quanh việc kích hoạt lại Point-in-Time Recovery (PITR) cho một instance Amazon RDS for MySQL Multi-AZ sau khi đã tắt nó trong giai đoạn testing.

• Bối cảnh: Công ty tạo RDS MySQL Multi-AZ làm data store cho ứng dụng custom. Trong tests, họ tắt PITR (thường bằng cách đặt backup retention period = 0), dẫn đến không có automated backups và binary logs cần thiết cho PITR. Giờ, trước khi dùng cho production data, họ cần enable PITR để có thể khôi phục database về bất kỳ thời điểm nào trong khoảng retention period (thường 1-35 ngày).
• Yêu cầu chính: Database specialist phải thực hiện hành động nào để PITR hoạt động thành công (successful). PITR trên RDS MySQL yêu cầu automated backups enabled (retention > 0 ngày) và binary logging (được RDS tự động quản lý khi backups bật).
• Kiến thức cập nhật 2026: Theo AWS RDS phiên bản mới nhất (RDS Multi-AZ DB clusters và Single-AZ/ Multi-AZ deployments), PITR chỉ khả dụng khi backup retention period được set từ 1-35 ngày. RDS tự động kích hoạt binary logging và tạo transaction logs cho PITR mà không cần config thủ công thêm (nếu parameter group hỗ trợ).

✅ Đáp án đúng

Modify the DB instance and configure a backup retention period

Lý do lựa chọn:

• Đây là bước cốt lõi và trực tiếp để enable PITR. Khi modify DB instance và set backup retention period > 0 (ví dụ: 7 ngày), RDS sẽ tự động:
  • Bật automated daily backups (full snapshots).
  • Kích hoạt transaction logs (binary logs cho MySQL) để hỗ trợ PITR.
  • Cho phép restore về bất kỳ giây nào trong retention period.
• Trong tests, PITR disabled ngụ ý retention=0, nên chỉ cần modify này là đủ. Không cần restart instance hoặc thay đổi parameter group riêng (RDS handles binary logging tự động).
• Hiệu quả ngay lập tức: Áp dụng cho production mà không downtime lớn (Multi-AZ hỗ trợ failover seamless).

📋 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 đầy đủ bằng tiếng Việt:

• Enable binary logging in the DB parameter group used by the DB instance.
  ❌ Sai: Binary logging (qua parameters như binlog_format, log_bin=1) là cần thiết cho PITR trên MySQL, nhưng không phải bước đầu tiên hoặc đủ. RDS tự động enable binary logging khi bạn set backup retention >0. Nếu chỉ enable binary log mà retention=0, PITR vẫn fail vì không có automated backups. Modify parameter group chỉ là bổ sung, không giải quyết gốc rễ (retention period).

• Modify the DB instance and enable audit logs to be pushed to Amazon CloudWatch Logs.
  ❌ Sai: Audit logs (qua parameter server_audit_logging) dùng để ghi trace truy vấn/user actions và push sang CloudWatch Logs cho compliance/monitoring. Không liên quan đến PITR, vì PITR dựa vào binary logs và automated backups, không phải audit logs. Enable cái này chỉ tốn chi phí storage mà không giúp khôi phục data.

• Modify the DB instance and configure a backup retention period
  ✅ Đúng: Như giải thích ở trên. Đây là hành động chính xác và đơn giản nhất. Modify DB instance qua Console/CLI/API, set retention 1-35 ngày → RDS enable backups + PITR ngay. Hỗ trợ Multi-AZ seamless, chi phí thấp (~0.095 USD/GB/tháng theo 2026 pricing).

• Set up a scheduled job to create manual DB instance snapshots.
  ❌ Sai: Manual snapshots (qua Lambda/EventBridge hoặc cron job) chỉ tạo point-in-time snapshots cố định, không hỗ trợ PITR granular (đến từng giây). PITR yêu cầu automated backups + transaction logs, manual snapshots không thay thế được và tốn công quản lý, dễ miss data loss trong production.

🛠️ Lời khuyên thực hành

• Cách thực hiện: Sử dụng AWS Console > RDS > Modify > Backup retention period > Apply immediately (hoặc maintenance window). CLI: aws rds modify-db-instance --db-instance-identifier mydb --backup-retention-period 7.
• Best practice 2026: Kết hợp với RDS Proxy cho connection pooling và Performance Insights để monitor PITR usage. Test PITR bằng lệnh aws rds restore-db-instance-to-point-in-time.

📘 Tài liệu tham khảo

• AWS RDS User Guide (2026 update): Automated backups and point-in-time recovery – Chi tiết PITR requirements.
• RDS MySQL Parameters: Parameter groups for binary logging.
• Exam prep DOP-C02: AWS Certified DevOps Engineer Professional blueprint, section RDS resilience (Q&A tương tự).

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 Terraform/CloudFormation, hỏi thêm nhé!

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

Câu hỏi tập trung vào việc mã hóa dữ liệu lưu trữ (at-rest encryption) và mã hóa kết nối (in-transit encryption) cho một instance Amazon RDS for MySQL hiện đang không được mã hóa.

• Yêu cầu chính:
  • Bật mã hóa cho DB instance (storage encryption bằng AWS KMS key).
  • Mã hóa tất cả kết nối đến DB instance (sử dụng SSL/TLS).
• Thách thức: RDS không hỗ trợ bật mã hóa trực tiếp trên instance đang chạy và không mã hóa (theo tài liệu AWS cập nhật đến 2026). Phải sử dụng snapshot hoặc read replica để migrate.
• Loại câu hỏi: Chọn ba hành động kết hợp (choose three) để đáp ứng đầy đủ.
  📘 Tài liệu tham khảo:
• Encrypting Amazon RDS resources (AWS RDS User Guide, cập nhật 2024+).
• Encrypting data in transit.

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

Các đáp án đúng (chọn 3):

1. Create a snapshot of the unencrypted DB instance. Encrypt the snapshot by using an AWS Key Management Service (AWS KMS) key. Restore the DB instance from the encrypted snapshot. Delete the original DB instance.

   • ✅ Lý do: Đây là cách chuẩn để mã hóa storage của RDS instance không mã hóa. Snapshot được mã hóa bằng KMS key, restore tạo instance mới đã mã hóa, sau đó xóa instance cũ để tránh downtime lớn (có thể dùng blue-green deployment).

2. Require SSL connections for applicable database user accounts.

   • ✅ Lý do: Buộc user accounts MySQL sử dụng SSL (qua tham số require SSL trong GRANT), đảm bảo tất cả kết nối từ client đều được mã hóa in-transit.

3. Use SSL/TLS from the application to encrypt a connection to the DB instance.

   • ✅ Lý do: Ứng dụng phải cấu hình kết nối SSL/TLS (sử dụng certificate bundle từ AWS), mã hóa dữ liệu truyền giữa app và RDS, bổ sung cho yêu cầu mã hóa tất cả kết nối.

🛠️ Kết hợp ba hành động này hoàn chỉnh: Mã hóa storage (snapshot) + mã hóa in-transit (SSL từ app và user accounts).

❌ 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 bằng tiếng Anh, với lý do đúng/sai dựa trên tính năng AWS RDS for MySQL (cập nhật 2026):

• In the RDS console, choose “Enable encryption” to encrypt the DB instance by using an AWS Key Management Service (AWS KMS) key.
  ❌ Sai: Không thể bật mã hóa trực tiếp trên RDS instance đang chạy và không mã hóa qua console. Tính năng "Enable encryption" chỉ áp dụng khi tạo instance mới, không hỗ trợ retrofit existing instance (sẽ báo lỗi). Phải dùng snapshot hoặc read replica.

• Encrypt the read replica of the unencrypted DB instance by using an AWS Key Management Service (AWS KMS) key. Fail over the read replica to the primary DB instance.
  ❌ Sai: Mặc dù có thể tạo encrypted read replica từ unencrypted primary và failover (promote thành primary), cách này không đảm bảo mã hóa tất cả kết nối (chỉ mã hóa storage). Hơn nữa, failover gây downtime ngắn và không phải lựa chọn ưu tiên so với snapshot (ít rủi ro hơn cho production). AWS khuyến nghị snapshot cho trường hợp này.

• Create a snapshot of the unencrypted DB instance. Encrypt the snapshot by using an AWS Key Management Service (AWS KMS) key. Restore the DB instance from the encrypted snapshot. Delete the original DB instance.
  ✅ Đúng: Phương pháp chuẩn, zero-downtime nếu dùng Multi-AZ hoặc DMS migration. Snapshot mã hóa bằng KMS, restore tạo instance encrypted đầy đủ, xóa cũ để tuân thủ audit.

• Require SSL connections for applicable database user accounts.
  ✅ Đúng: Sử dụng SQL command ALTER USER ... REQUIRE SSL; để enforce SSL trên user accounts MySQL, từ chối kết nối không mã hóa. Bổ sung cho app-side SSL.

• Use SSL/TLS from the application to encrypt a connection to the DB instance.
  ✅ Đúng: App phải tải RDS SSL certificate (rds-combined-ca-bundle.pem), cấu hình connection string với sslmode=REQUIRED (cho JDBC/ODBC). Đảm bảo in-transit encryption end-to-end.

• Enable SSH encryption on the DB instance.
  ❌ Sai: RDS không hỗ trợ SSH trực tiếp (managed service, không expose bastion host). Kết nối chỉ qua port 3306 (MySQL) với SSL/TLS, không dùng SSH. Đây là nhầm lẫn với EC2.

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

Câu hỏi mô tả một công ty có trang web thương mại điện tử (ecommerce) chạy trên AWS, sử dụng cơ sở dữ liệu Amazon RDS for MySQL. Chuyên gia cơ sở dữ liệu muốn ép buộc sử dụng temporary credentials (tín dụng tạm thời) để truy cập cơ sở dữ liệu.
🛠️ Yêu cầu chính: Tìm giải pháp đảm bảo không sử dụng mật khẩu hoặc credentials vĩnh viễn, mà thay vào đó sử dụng credentials tự động hết hạn (thường là token ngắn hạn, ví dụ 15 phút), tăng cường bảo mật bằng cách tránh rủi ro lộ thông tin đăng nhập lâu dài.
📈 Bối cảnh AWS: Với RDS MySQL (hỗ trợ IAM database authentication từ phiên bản 5.6+), AWS cung cấp cơ chế native để tạo temporary credentials dựa trên IAM roles/policies, phù hợp với best practices bảo mật zero-trust đến năm 2026.

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

Đáp án đúng: Use AWS Identity and Access Management (IAM) database authentication.
🧠 Lý do: IAM database authentication cho RDS MySQL cho phép ứng dụng sử dụng IAM roles hoặc users để tạo temporary authentication token (hết hạn sau 15 phút), thay vì username/password vĩnh viễn. Quy trình: Generate token bằng AWS Signature Version 4, kết nối DB qua SSL. Điều này ép buộc temporary credentials, giảm rủi ro và tuân thủ AWS security best practices (như trong Well-Architected Framework). Hỗ trợ đầy đủ trên RDS MySQL đến 2026, không cần thay đổi DB engine.

🔍 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 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 tính năng AWS mới nhất:

• ❌ Use MySQL native database authentication.
  Sai vì: Phương pháp native của MySQL sử dụng username/password tĩnh (long-lived credentials), lưu trữ trực tiếp trong DB. Không hỗ trợ temporary credentials tự động hết hạn, dẫn đến rủi ro bảo mật cao nếu password bị lộ. Không đáp ứng yêu cầu "enforce temporary credentials".

• ❌ Use AWS Secrets Manager to rotate the credentials.
  Sai vì: Secrets Manager cho phép tự động rotate credentials (ví dụ: thay đổi password định kỳ), nhưng credentials vẫn là long-lived (dù được xoay). Ứng dụng phải fetch secret trước khi connect, không tạo temporary token native như yêu cầu. Phù hợp cho secret management nhưng không "enforce temporary" thuần túy.

• ✅ Use AWS Identity and Access Management (IAM) database authentication.
  Đúng vì: Đây là giải pháp native của AWS cho RDS MySQL, sử dụng IAM để generate temporary token (hết hạn 15 phút, tự động renew). Không cần password DB, chỉ cần IAM policy với quyền rds-db:connect. Hoàn hảo để enforce temporary access, hỗ trợ EC2/Lambda/Containers.

• ❌ Use AWS Systems Manager Parameter Store for authentication.
  Sai vì: Parameter Store lưu trữ credentials dưới dạng parameter (có thể secure string), hỗ trợ rotate qua Lambda, nhưng vẫn là static/long-lived values khi fetch. Không tạo temporary token tự động như IAM auth, và kém an toàn hơn cho DB access so với IAM integration.

📘 Tài liệu tham khảo

• AWS Documentation chính thức (cập nhật 2026): IAM database authentication for MySQL and PostgreSQL – Chi tiết setup và token generation.
• RDS User Guide: Enabling IAM DB authentication.
• AWS Well-Architected Security Pillar: Khuyến nghị temporary credentials cho DB access.
• Exam Prep: AWS Certified DevOps Engineer Professional DOP-C02 blueprint, phần Security & Compliance (Domain 3).

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

Câu hỏi tập trung vào một hệ thống quản lý hàng tồn kho của công ty sản xuất, sử dụng Amazon Aurora MySQL DB cluster với kích thước 3 TB và các bảng được phân vùng (partitioned). Người dùng chạy các truy vấn một lần (one-time queries) qua SQL client, đặc biệt các truy vấn sử dụng equijoin (kết nối bằng dấu = giữa các bảng lớn) đang chạy rất chậm.
Mục tiêu: Tìm hành động cải thiện hiệu suất truy vấn với ít nỗ lực vận hành nhất (LEAST operational effort).
🛠️ Vấn đề cốt lõi: Equijoin trên bảng lớn (big tables) thường chậm do thuật toán join mặc định (nested loop hoặc block nested loop) không tối ưu cho dữ liệu lớn. Aurora MySQL cần tối ưu hóa join mà không thay đổi lớn về kiến trúc.

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

Đáp án đúng: Enable hash joins on the database by setting the variable optimizer_switch to hash_join=on.

Lý do:

• Aurora MySQL (từ phiên bản 2.x tương ứng MySQL 5.7 và 3.x tương ứng MySQL 8.0 – cập nhật đến 2026) hỗ trợ hash join qua biến optimizer_switch. Việc set hash_join=on kích hoạt optimizer sử dụng hash join cho equijoin trên bảng lớn, thay vì nested loop chậm chạp, giúp tăng tốc đáng kể mà không cần thay đổi cấu trúc DB.
• Ít nỗ lực nhất: Chỉ cần chỉnh biến động (dynamic variable) qua SQL command hoặc parameter group, áp dụng ngay mà không downtime, migrate dữ liệu hay tạo instance mới. Hoàn hảo cho one-time queries trên bảng partitioned lớn.
  📘 Nguồn tham khảo: AWS Documentation - Amazon Aurora MySQL Reference Manual (MySQL 8.0): Optimizer Hints and Switches (cập nhật 2024-2026, hash_join được khuyến nghị cho join lớn).

📋 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, đánh dấu ✅ đúng hoặc ❌ sai, giữ nguyên văn bản gốc bằng tiếng Anh:

• Migrate the database to a new Amazon Redshift data warehouse.
  ❌ Sai: Redshift là data warehouse chuyên phân tích OLAP, không phù hợp thay thế Aurora MySQL (OLTP). Việc migrate 3 TB dữ liệu partitioned yêu cầu ETL phức tạp (schema conversion, data transfer qua DMS/SCT), downtime lớn, chi phí cao và nỗ lực vận hành rất lớn. Không giải quyết trực tiếp equijoin chậm trên MySQL mà phải rewrite queries columnar. Không phải "least effort".

• Enable hash joins on the database by setting the variable optimizer_switch to hash_join=on.
  ✅ Đúng: Như giải thích ở trên. Đây là cách tối ưu hóa optimizer ngay lập tức cho equijoin lớn trong Aurora MySQL, hỗ trợ hash join hiệu quả trên bộ nhớ/in-memory hash table. Áp dụng qua SET GLOBAL optimizer_switch = 'hash_join=on'; hoặc parameter group, zero downtime, phù hợp one-time queries. Effort thấp nhất!

• Take a snapshot of the DB cluster. Create a new DB instance by using the snapshot, and enable parallel query mode.
  ❌ Sai: Parallel query mode chỉ hỗ trợ trên Aurora PostgreSQL (từ 2019, cập nhật 2026 vẫn vậy), KHÔNG có trên Aurora MySQL. Tạo snapshot và instance mới mất thời gian restore (giờ cho 3 TB), thêm chi phí instance riêng, và vẫn không giải quyết join chậm nếu không có parallel query. Effort cao hơn hash join đơn giản.

• Add an Aurora read replica.
  ❌ Sai: Read replica scale read traffic, nhưng truy vấn equijoin lớn vẫn chậm trên replica vì cùng engine MySQL (không tự động parallelize join). Với one-time queries từ SQL client, replica chỉ phân tải nếu app kết nối replica, nhưng vấn đề cốt lõi (join algorithm) không thay đổi. Effort trung bình (tạo replica ~15-30 phút), nhưng không tối ưu bằng chỉnh optimizer.

🧩 Tóm tắt khuyến nghị: Ưu tiên hash join cho Aurora MySQL với dữ liệu lớn partitioned. Nếu queries phức tạp hơn, xem xét Aurora Serverless v2 hoặc HTAP features mới (2024+), nhưng ở đây hash join là giải pháp nhanh nhất! 🚀

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

Câu hỏi tập trung vào việc migrate một instance Microsoft SQL Server Standard edition từ on-premises sang AWS Cloud, chạy trên Amazon EC2 Windows instances. Ứng dụng là business-critical, chứa nhiều databases, và yêu cầu high availability (HA) với không có single point of failure trong kiến trúc SQL Server.

🔍 Chi tiết yêu cầu chính:

• Sử dụng SQL Server Standard edition (không phải Enterprise).
• Triển khai trên EC2 Windows instances (không phải dịch vụ managed như RDS).
• Đảm bảo failover tự động cho toàn bộ instance/databases mà không downtime lớn.
• Shared storage phải multi-AZ để tránh SPOF (Single Point of Failure).

🛠️ Bối cảnh AWS cập nhật đến 2026: AWS hỗ trợ SQL Server HA qua EC2 với Always On Failover Cluster Instances (FCI) cho Standard edition, kết hợp Amazon FSx for Windows File Server Multi-AZ làm shared storage (SMB protocol, hỗ trợ cluster failover cross-AZ). Đây là giải pháp chuẩn cho SQL Server FCI trên EC2, theo AWS Well-Architected Framework cho databases (phiên bản mới nhất 2024+).

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

• AWS Documentation: High availability for SQL Server on EC2
• Amazon FSx for Windows File Server Multi-AZ
• SQL Server Standard Edition HA features

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

Đáp án đúng: Set up Always On Failover Cluster Instances as a single SQL Server instance. Use Multi-AZ Amazon FSx for Windows File Server as a shared storage option to host the databases.

Lý do chi tiết 🏆:

• Always On Failover Cluster Instances (FCI) là tính năng HA chuẩn của SQL Server Standard edition, cho phép failover toàn bộ instance (bao gồm system databases và user databases) như một single logical instance, sử dụng shared storage để tránh data loss.
• Amazon FSx for Windows File Server Multi-AZ cung cấp shared storage SMB cross-AZ với automatic failover <60 giây, tích hợp Windows Failover Clustering (WSFC), loại bỏ SPOF hoàn toàn (data replicated synchronously giữa primary và secondary AZ).
• Giải pháp này phù hợp EC2 Windows, migrate từ on-premises dễ dàng (dùng FSx thay SAN/NAS truyền thống), và đáp ứng business-critical với RTO/RPO thấp.
• Không cần Enterprise edition (FCI hỗ trợ Standard từ SQL 2012+).

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

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

• Create Amazon RDS for SQL Server Multi-AZ DB instances. Use Amazon S3 as a shared storage option to host the databases.
  ❌ Sai hoàn toàn. RDS for SQL Server Multi-AZ chỉ dùng synchronous replication nội bộ (không phải shared storage), và không hỗ trợ custom shared storage như S3. RDS là managed service (không phải EC2 instances), không cho phép cài Always On FCI hoặc truy cập trực tiếp storage. S3 là object storage, không phải block/file storage cho SQL databases (không mount được như SAN). Không migrate được instance on-premises với several databases mà không refactor lớn.

• Set up Always On Failover Cluster Instances as a single SQL Server instance. Use Multi-AZ Amazon FSx for Windows File Server as a shared storage option to host the databases.
  ✅ Đúng 100%. Như giải thích ở phần đáp án trên: FCI + FSx Multi-AZ là best practice AWS cho SQL Standard trên EC2, đảm bảo HA cross-AZ, failover nhanh, không SPOF. FSx hỗ trợ up to 65 PB, throughput cao, tích hợp WSFC hoàn hảo.

• Set up Always On availability groups to group one or more user databases that fail over together across multiple SQL Server instances. Use Multi-AZ Amazon FSx for Windows File Server as a shared storage option to host the databases.
  ❌ Sai. Always On Availability Groups (AG) yêu cầu SQL Server Enterprise edition (Standard chỉ hỗ trợ Basic AG hạn chế, không failover full instance). AG là replication-based (không cần shared storage), dùng log shipping giữa instances độc lập – việc dùng FSx shared storage là không cần thiết và sai kiến trúc (gây conflict). Chỉ phù hợp user databases riêng lẻ, không cho system databases hoặc full instance migrate.

• Create an Application Load Balancer to distribute database traffic across multiple EC2 instances in multiple Availability Zones. Use Amazon S3 as a shared storage option to host the databases.
  ❌ Sai cơ bản. ALB dùng cho HTTP/HTTPS traffic (Layer 7), không phù hợp database traffic (TCP port 1433, cần sticky sessions phức tạp). S3 không phải shared block storage cho SQL (không hỗ trợ NTFS/SMB, latency cao, không ACID-compliant). Không có failover mechanism thực sự cho SQL instance, dẫn đến data corruption và SPOF. Giải pháp này chỉ là scale-out giả tạo, không HA chuẩn.

🧠 Kết luận nhanh: Chọn FCI + FSx để migrate seamless, HA production-ready! Nếu cần lab, dùng AWS Quick Start for SQL FCI. 🚀

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

Câu hỏi tập trung vào việc tích hợp xác thực người dùng cho Amazon RDS for SQL Server sử dụng tài khoản Microsoft Active Directory (AD) từ on-premises (hệ thống nội bộ công ty). Công ty muốn người dùng RDS DB instance xác thực bằng credentials AD hiện có, thay vì tạo tài khoản riêng trên RDS.

📌 Yêu cầu chính: Chọn 3 bước kết hợp (combination of steps) mà database specialist cần thực hiện. Đây là tính năng Windows Authentication cho RDS SQL Server, hỗ trợ tích hợp với AD để cho phép Kerberos/NTLM authentication.

🛠️ Quy trình tổng quát (dựa trên tài liệu AWS cập nhật 2024-2026):

• RDS SQL Server hỗ trợ join domain từ AWS Managed Microsoft AD (qua Directory Service).
• Không hỗ trợ trực tiếp AD Connector hoặc self-managed DC trên EC2 cho RDS auth.
• Cần IAM role (không phải user) để RDS truy cập Directory Service.
• Thiết lập one-way forest trust từ AWS Managed AD sang on-premises AD để đồng bộ credentials.

Kiến thức này dựa trên AWS RDS User Guide (phiên bản mới nhất 2026), nơi nhấn mạnh AWS Directory Service for Microsoft AD là giải pháp managed tốt nhất cho enterprise workloads.

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

Các đáp án đúng là bộ ba bước sau, tạo thành quy trình hoàn chỉnh để RDS join AWS Managed AD và trust với on-premises AD:

1. Create a directory by using AWS Directory Service for Microsoft Active Directory.
   ✅ Lý do đúng: Bước đầu tiên phải tạo AWS Managed Microsoft AD (Standard Edition) qua AWS Directory Service. Đây là domain managed đầy đủ tính năng, hỗ trợ RDS SQL Server join domain và forest trust với on-premises AD. Không dùng Simple AD vì thiếu trust features.

2. Create an IAM role that uses the AmazonRDSDirectoryServiceAccess managed IAM policy.
   ✅ Lý do đúng: RDS cần IAM role với policy AmazonRDSDirectoryServiceAccess (read-only access đến Directory Service) để join DB instance vào domain. Role này attach vào RDS khi modify DB instance (qua AWS Management Console/CLI). IAM user không dùng vì RDS là service principal, không phải user-based.

3. Create a one-way forest trust from the AWS Directory Service for Microsoft Active Directory directory to the on-premises Active Directory.
   ✅ Lý do đúng: Để người dùng on-premises AD truy cập RDS, cần one-way outgoing forest trust từ AWS Managed AD → on-premises AD. Điều này cho phép AWS AD "tin tưởng" credentials từ on-premises, hỗ trợ cross-domain authentication cho RDS apps. Trust hai chiều không cần thiết và phức tạp hơn.

Kết quả: Quy trình này cho phép RDS SQL Server sử dụng Integrated Windows Authentication với on-premises users/groups.

📋 Giải thí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ính khả thi, best practice và hỗ trợ chính thức từ AWS (không phải tất cả đều dùng được riêng lẻ).

• Extend the on-premises Active Directory to AWS by using AD Connector.
  ❌ Sai: AD Connector chỉ proxy kết nối từ AWS đến on-premises AD (không managed directory), phù hợp cho apps như WorkSpaces/SMB, nhưng không hỗ trợ RDS SQL Server join domain hoặc Windows Auth. RDS yêu cầu full Managed AD để promote domain member. (Theo AWS Directory Service docs: AD Connector thiếu Kerberos realm cho RDS).

• Create an IAM user that uses the AmazonRDSDirectoryServiceAccess managed IAM policy.
  ❌ Sai: Policy AmazonRDSDirectoryServiceAccess dùng cho IAM role (service-linked), không phải IAM user. RDS service sử dụng role để assume quyền truy cập Directory Service khi join domain. IAM user chỉ dùng cho human access, sẽ gây lỗi permission denied.

• Create a directory by using AWS Directory Service for Microsoft Active Directory.
  ✅ Đúng: Như giải thích trên, đây là nền tảng bắt buộc cho RDS SQL Server AD integration. AWS Directory Service cung cấp fully managed AD tương đương on-premises, hỗ trợ lên đến 500k users (cập nhật 2025).

• Create an Active Directory domain controller on Amazon EC2.
  ❌ Sai: Tự quản lý DC trên EC2 (self-managed AD) có thể làm được nhưng không phải best practice cho RDS, vì AWS khuyến nghị Managed AD để tránh operational overhead (patching, HA, backup). RDS docs không liệt kê self-managed như option chính thức cho integration, và khó thiết lập trust ổn định.

• Create an IAM role that uses the AmazonRDSDirectoryServiceAccess managed IAM policy.
  ✅ Đúng: IAM role là thành phần cốt lõi, attach policy để RDS có quyền ds:CreateComputer, ds:AuthorizeApplication trên Directory Service.

• Create a one-way forest trust from the AWS Directory Service for Microsoft Active Directory directory to the on-premises Active Directory.
  ✅ Đúng: Trust một chiều (AWS AD trusts on-premises) là yêu cầu chuẩn để propagate credentials. Hướng dẫn AWS chỉ rõ "outgoing trust from AWS to on-premises".

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

• AWS RDS for SQL Server - Windows Authentication: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_SQLServerWinAuth.html – Chi tiết steps join domain.
• AWS Directory Service for Microsoft AD: docs.aws.amazon.com/directoryservice/latest/admin-guide/directory_microsoft_ad.html – Forest trust setup.
• IAM Policies for RDS: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAM.html – Xác nhận role vs user.
• AWS re:Post & Well-Architected Framework: Best practices tránh self-managed DC cho hybrid AD.

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

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

Câu hỏi mô tả một ứng dụng thực hiện các hoạt động intensive in-memory (xử lý dữ liệu trong bộ nhớ với cường độ cao) trên các cấu trúc dữ liệu nâng cao như sorted sets (tập hợp có thứ tự). Ứng dụng yêu cầu độ trễ sub-millisecond (dưới 1 mili giây) cho cả đọc và ghi. Ngoài ra, ứng dụng thỉnh thoảng cần chạy một nhóm lệnh dưới dạng ACID-compliant operation (giao dịch tuân thủ ACID: Atomicity, Consistency, Isolation, Durability). Chuyên gia cơ sở dữ liệu cần thiết lập database hỗ trợ tạo cluster mới từ bản backup mới nhất của cluster production (khả năng khôi phục hoặc tạo cluster từ snapshot backup).
🛠️ Yêu cầu chính: Dịch vụ phải là in-memory database/cache, hỗ trợ sorted sets, latency thấp, giao dịch ACID, và backup/restore cluster. Đây là tình huống điển hình cho các workload caching/NoSQL in-memory với tính năng enterprise.

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

Đáp án đúng: Amazon ElastiCache for Redis
Lý do:

• Redis là in-memory data store hỗ trợ đầy đủ sorted sets (ZSET) qua lệnh ZADD/ZRANGE/ZREVRANGE, phù hợp với intensive operations.
• Đảm bảo sub-ms latency cho read/write nhờ kiến trúc in-memory thuần túy.
• Hỗ trợ ACID transactions qua MULTI/EXEC blocks hoặc Lua scripts (atomic execution), đáp ứng yêu cầu group of commands ACID-compliant.
• Backup & Restore: ElastiCache for Redis hỗ trợ point-in-time recovery (PITR) và snapshots (manual/automated), cho phép tạo cluster mới từ backup production một cách dễ dàng qua AWS Console/CLI/API (tính năng Multi-AZ với replication).
• Cập nhật 2026: Redis trên ElastiCache hỗ trợ engine version 7.x+, với Online Cluster Resizing, Global Datastore, và enhanced backup retention lên đến 35 ngày.
  📘 Tài liệu tham khảo: AWS ElastiCache for Redis - Features, Backup & Restore, Transactions.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh:

• ❌ Amazon ElastiCache for Memcached
  Sai vì Memcached chỉ hỗ trợ key-value đơn giản (không có sorted sets hay data structures phức tạp như lists/sets/hashes). Không hỗ trợ transactions ACID (không có MULTI/EXEC). Backup chỉ là snapshot cơ bản nhưng không hỗ trợ tạo cluster mới từ backup production một cách linh hoạt như Redis (Memcached thiếu replication/multi-AZ đầy đủ). Không đáp ứng intensive operations trên advanced data structures.

• ❌ Amazon Neptune
  Sai vì Neptune là graph database (hỗ trợ Property Graph & RDF), không phải in-memory cache thuần túy, dẫn đến latency cao hơn sub-ms (thường 10-100ms cho graph traversals). Không hỗ trợ sorted sets native (chỉ edges/vertices). Transactions ACID có nhưng tập trung vào graph queries, không phải group commands in-memory. Backup hỗ trợ snapshots, nhưng không dành cho workload in-memory intensive như mô tả.

• ✅ Amazon ElastiCache for Redis
  Đúng hoàn toàn như giải thích ở phần đáp án trên: Hỗ trợ sorted sets, sub-ms latency, ACID via MULTI/Lua, và tạo cluster từ backup production (snapshot restore). Đây là lựa chọn tối ưu cho ứng dụng này, được AWS khuyến nghị cho high-performance caching với persistence.

• ❌ Amazon DynamoDB Accelerator (DAX)
  Sai vì DAX là in-memory cache layer cho DynamoDB (không phải standalone cluster), chỉ hỗ trợ key-value đơn giản tương tự DynamoDB (không có sorted sets). Latency sub-ms có, nhưng không hỗ trợ ACID transactions độc lập (phụ thuộc DynamoDB transactions). Backup không áp dụng trực tiếp (DAX dùng cluster snapshots riêng, không tạo từ DynamoDB backup, và đã deprecated từ 2023 - khuyến nghị dùng DynamoDB với on-demand). Không phù hợp tạo cluster độc lập từ production backup.
  📘 Tài liệu: DAX Deprecation Notice.

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

Câu hỏi tập trung vào việc tạo dashboard hiển thị thông tin về kết nối người dùng (user connections) đến các cơ sở dữ liệu Amazon Aurora MySQL, đồng thời phải lưu trữ tất cả connection logs ít nhất 7 năm theo yêu cầu tuân thủ (compliance). Công ty sử dụng Aurora MySQL làm database chính cho nhiều ứng dụng, và giải pháp cần tiết kiệm chi phí nhất (MOST cost-effectively).

🔍 Yêu cầu chính cần giải quyết:

• Theo dõi và ghi log kết nối (CONNECT events) cụ thể (không chỉ metrics tổng quát).
• Lưu trữ logs dài hạn (7 năm) trên Amazon S3 (rẻ tiền cho lưu trữ lâu dài).
• Xây dựng dashboard để hiển thị dữ liệu (visualization).
• Ưu tiên giải pháp cost-effective: Tránh các dịch vụ đắt đỏ như real-time streaming không cần thiết, tận dụng logging native của Aurora và các công cụ serverless rẻ tiền.

📘 Kiến thức AWS cập nhật đến 2026: Aurora MySQL hỗ trợ Advanced Auditing (từ version 2.08+ và 3.02+), cho phép log chi tiết CONNECT events trực tiếp vào CloudWatch Logs. Có thể export định kỳ sang S3 với Lambda + EventBridge để lưu trữ dài hạn. QuickSight là lựa chọn dashboard rẻ, serverless. (Nguồn: AWS Aurora MySQL Auditing Docs, CloudWatch Logs Export).

✅ Đáp án đúng

Đáp án đúng là phương án đầu tiên:
Enable advanced auditing on the Aurora cluster to log CONNECT events. Export audit logs from Amazon CloudWatch to Amazon S3 by using an AWS Lambda function that is invoked by an Amazon EventBridge (Amazon CloudWatch Events) scheduled event. Build a dashboard by using Amazon QuickSight.

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

• Advanced Auditing của Aurora MySQL ghi log chi tiết CONNECT events (ai kết nối, từ đâu, khi nào) trực tiếp vào CloudWatch Logs – phù hợp chính xác với yêu cầu theo dõi user connections.
• Export sang S3 qua Lambda + EventBridge scheduled: Chạy định kỳ (ví dụ hàng ngày), serverless, chi phí thấp (Lambda chỉ tính theo execution time, S3 Intelligent-Tiering cho lưu trữ 7 năm rẻ ~0.00099 USD/GB/tháng). Không cần real-time, tiết kiệm hơn streaming.
• QuickSight dashboard: Kết nối trực tiếp S3/CloudWatch, phân tích SPICE engine rẻ tiền cho visualization.
• Cost-effective nhất: Native logging, không overhead cao, tuân thủ 7 năm lưu trữ. Tổng chi phí thấp so với các lựa chọn khác.

📋 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 một cách rõ ràng, 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ể bằng tiếng Việt.

• Enable advanced auditing on the Aurora cluster to log CONNECT events. Export audit logs from Amazon CloudWatch to Amazon S3 by using an AWS Lambda function that is invoked by an Amazon EventBridge (Amazon CloudWatch Events) scheduled event. Build a dashboard by using Amazon QuickSight.
  ✅ Đúng hoàn toàn 🏆: Như giải thích ở trên, đây là giải pháp native, chi tiết logs CONNECT, lưu trữ dài hạn S3, dashboard rẻ. Hoàn hảo cho compliance 7 năm và cost-effective.

• Capture connection attempts to the Aurora cluster with AWS Cloud Trail by using the DescribeEvents API operation. Create a CloudTrail trail to export connection logs to Amazon S3. Build a dashboard by using Amazon QuickSight.
  ❌ Sai 🚫: CloudTrail ghi log API calls (như Connect/DescribeDBInstances), KHÔNG ghi connection attempts đến database (user login vào MySQL). DescribeEvents API chỉ query events RDS, không capture connections real-time. Không đáp ứng yêu cầu logs chi tiết user connections.

• Start a database activity stream for the Aurora cluster. Push the activity records to an Amazon Kinesis data stream. Build a dynamic dashboard by using AWS Lambda.
  ❌ Sai 🚫: Database Activity Stream (DAS) chỉ ghi DDL/DML activity (query changes), KHÔNG ghi CONNECT events (connections). Kinesis + Lambda real-time đắt đỏ (Kinesis ~0.015 USD/GB ingested), không cần thiết cho dashboard đơn giản và lưu trữ 7 năm (phải thêm lưu S3 thủ công). Không cost-effective.

• Publish the DatabaseConnections metric for the Aurora DB instances to Amazon CloudWatch. Build a dashboard by using CloudWatch dashboards.
  ❌ Sai 🚫: DatabaseConnections chỉ là metric tổng số connections (số lượng, không chi tiết user/IP/time). CloudWatch dashboards chỉ hiển thị metrics/graph, KHÔNG lưu logs chi tiết và không hỗ trợ retain 7 năm (CloudWatch Logs chỉ giữ 30 ngày default, export thủ công phức tạp). Không đáp ứng compliance logs đầy đủ.

🏅 Kết luận & Lời khuyên DevOps

Giải pháp đúng tận dụng Aurora native features kết hợp serverless, đảm bảo scalability, security & cost-optimized. Để implement: Bật auditing qua Parameter Group (server_audit_logging=1, server_audit_events='CONNECT'). Test với QuickSight datasets từ S3.

📚 Tài liệu tham khảo thêm:

• Aurora Advanced Auditing (2024 update).
• EventBridge + Lambda Export Logs.
• QuickSight S3 Integration.

Nếu cần code Terraform/CloudFormation mẫu, hãy cho tôi biết! 🚀

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

Câu hỏi tập trung vào nhu cầu của một công ty cần thông báo gần thời gian thực (near-real-time) khi có thay đổi trên Amazon RDS DB security groups (nhóm bảo mật của cơ sở dữ liệu RDS). 🛡️️

• Yêu cầu chính: Giải pháp phải đáp ứng thông báo nhanh chóng, với mức độ vận hành thấp nhất (LEAST operational overhead) – nghĩa là ưu tiên giải pháp tự động, native của AWS, không cần code custom, polling thủ công hay quản lý phức tạp.
• Bối cảnh AWS: Amazon RDS hỗ trợ theo dõi thay đổi cấu hình như security groups qua các sự kiện (events). Security groups kiểm soát truy cập vào DB instance, nên thay đổi (thêm/xóa rule) cần được giám sát kịp thời để đảm bảo an ninh. 📈
• Phiên bản cập nhật (2026): RDS Event Notifications vẫn là tính năng cốt lõi, hỗ trợ SNS/SMS/Email và tích hợp Lambda/EventBridge cho near-real-time (thường trong vài giây). Không có thay đổi lớn từ AWS re:Invent 2025.

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

Đáp án đúng: Configure an RDS event notification subscription for DB security group events.

• Lý do: Đây là giải pháp native của AWS RDS, chỉ cần tạo subscription qua Console/CLI/API, chọn event category "security group" (ví dụ: RDS-EVENT-2017-05 hoặc security-group-update). Thông báo được gửi qua SNS ngay lập tức (near-real-time), không cần code, polling hay quản lý tài nguyên thêm. Overhead thấp nhất: chỉ cấu hình một lần, tự động scale. Hoàn hảo cho DevOps! 🚀

📋 Phân tích 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do chi tiết:

• ✅ Configure an RDS event notification subscription for DB security group events.
  Đúng: Như đã giải thích, đây là tính năng built-in của RDS (Event Subscriptions), hỗ trợ chính xác events liên quan đến DB security groups (e.g., modification, snapshot creation). Near-real-time qua SNS, zero custom code, overhead tối thiểu. Lý tưởng cho production!

• ❌ Create an AWS Lambda function that monitors DB security group changes. Create an Amazon Simple Notification Service (Amazon SNS) topic for notification.
  Sai: Yêu cầu code custom Lambda để poll API (DescribeDBSecurityGroups) hoặc dùng EventBridge, cộng thêm quản lý SNS. Overhead cao: phát triển/test/deploy code, xử lý permissions/IAM, chi phí invocation, và không đảm bảo near-real-time nếu polling interval lớn. Không phải giải pháp least overhead!

• ❌ Turn on AWS CloudTrail. Configure notifications for the detection of changes to DB security groups.
  Sai: CloudTrail ghi log API calls (e.g., ModifyDBSecurityGroup), nhưng không có metric/metric trực tiếp cho notifications. Cần thêm EventBridge rule hoặc Lambda để filter/parse logs, dẫn đến delay (log delivery 5-15 phút) và overhead cao (quản lý trails, rules, storage S3). Không near-real-time và phức tạp hơn RDS events!

• ❌ Configure an Amazon CloudWatch alarm for RDS metrics about changes to DB security groups.
  Sai: RDS CloudWatch metrics chỉ theo dõi performance (CPU, connections, IOPS), KHÔNG có metric cho config changes như security groups. Alarm sẽ không trigger vì thiếu dữ liệu. Overhead vô ích: cấu hình alarm không hiệu quả, phải fallback sang custom solution khác!

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

• RDS Event Notifications: AWS RDS User Guide - Events and Notifications – Chi tiết events cho security groups.
• RDS Events List: RDS Event Categories – Xác nhận "security group" events.
• CloudTrail for RDS: CloudTrail RDS Integration – Chỉ log, không notify trực tiếp.
• Best Practices DevOps: AWS Well-Architected Framework - Operational Excellence Pillar (2025 update).

Giải pháp này giúp tối ưu DevOps pipeline! Nếu cần lab thực hành, dùng AWS Free Tier nhé. 🧑‍💻

🧩 Phân tích chi tiết câu hỏi trắc nghiệm AWS RDS

📘 Nội dung câu hỏi:
Câu hỏi yêu cầu một database specialist tạo bản sao của instance Amazon RDS for MySQL sản xuất (production) mỗi sáng, để đội ngũ phát triển (development team) sử dụng làm môi trường testing. Bản sao phải:

• Được lưu trữ ở VPC khác so với instance gốc, nhưng cùng AWS account.
• Sẵn sàng sử dụng lúc 6 AM hàng ngày.
• Sử dụng cùng một endpoint address mỗi ngày (không thay đổi).
  Mục tiêu là giải pháp cost-effective nhất (tiết kiệm chi phí nhất), chọn 3 bước kết hợp.

🛠️ Yêu cầu kỹ thuật chính:

• Snapshot RDS là cách rẻ tiền để sao lưu point-in-time.
• Restore snapshot tạo instance mới (có thể chọn size nhỏ hơn production để tiết kiệm).
• Vì instance mới mỗi ngày → endpoint thay đổi → cần DNS alias ổn định (Route 53).
• Different VPC: Snapshot có thể restore cross-VPC trong same account/region.
  (Kiến thức cập nhật AWS 2024-2026: RDS hỗ trợ automated/manual snapshot restore cross-VPC dễ dàng, Route 53 CNAME lý tưởng cho RDS endpoint stability).

✅ Đáp án đúng (chọn 3):
Các bước đúng là:

1. Create a snapshot of the production database each day before the 6 AM deadline.
2. Create an RDS for MySQL DB instance from the snapshot. Select the desired DB instance size.
3. Update a defined Amazon Route 53 CNAME record to point to the copied DB instance.

🔍 Lý do chọn đáp án đúng (cost-effective nhất):

• Snapshot hàng ngày (manual snapshot trước 6 AM) → Chi phí thấp (~$0.095/GB-tháng, rẻ hơn full copy).
• Restore snapshot → Tạo instance testing nhanh (size nhỏ hơn production để tiết kiệm ~50-70% chi phí instance). Cross-VPC ok trong same account.
• Route 53 CNAME → Giữ endpoint ổn định (CNAME trỏ động đến RDS endpoint mới mỗi ngày), chi phí Route 53 rẻ (~$0.50/hosted zone/tháng).
  Kết hợp này tự động hóa qua Lambda/EventBridge, total cost < DMS/replication, sẵn sàng 6 AM. (Cost-effective vì tránh live replication/DMS đắt đỏ).

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

• ✅ Create a snapshot of the production database each day before the 6 AM deadline.
  Đúng: Bước đầu tiên cần thiết để capture dữ liệu production point-in-time. Manual snapshot (qua CLI/API/Lambda) trước 6 AM, chi phí thấp, sẵn sàng restore ngay. Không ảnh hưởng production.

• ✅ Create an RDS for MySQL DB instance from the snapshot. Select the desired DB instance size.
  Đúng: Restore snapshot tạo instance mới ở VPC khác (chọn subnet group phù hợp). Có thể resize nhỏ hơn (e.g., db.t4g.micro) để tiết kiệm chi phí testing (~70% rẻ hơn production). Thời gian restore ~15-60 phút, kịp 6 AM.

• ✅ Update a defined Amazon Route 53 CNAME record to point to the copied DB instance.
  Đúng: RDS endpoint thay đổi mỗi lần restore → CNAME record (e.g., dev-db.example.com) update trỏ đến endpoint mới. DNS propagation <1 phút, giữ endpoint ổn định cho dev team. Route 53 CNAME hỗ trợ full RDS endpoint (không giới hạn như alias).

• ❌ Set up an AWS Database Migration Service (AWS DMS) migration task to copy the snapshot to the copied DB instance.
  Sai: DMS dùng cho live migration/ongoing replication (full load + CDC), không phải copy snapshot (RDS restore trực tiếp hiệu quả hơn). DMS tốn kém (instance hours + storage), phức tạp setup task từ snapshot → không cost-effective.

• ❌ Use the CopySnapshot action on the production DB instance to create a snapshot before 6 AM.
  Sai: CopySnapshot dùng cho cross-region/account sharing (tạo snapshot copy riêng). Trong same account/region, chỉ cần CreateDBSnapshot (không copy). CopySnapshot tăng chi phí lưu trữ gấp đôi không cần thiết.

• ❌ Update a defined Amazon Route 53 alias record to point to the copied DB instance.
  Sai: Route 53 Alias chỉ hỗ trợ AWS resources cụ thể (ELB, S3, CloudFront, ACM...). RDS DB endpoint không hỗ trợ alias (là custom DNS name). Phải dùng CNAME để alias linh hoạt → alias sẽ fail validation.

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

• RDS Snapshots: AWS RDS User Guide - Working with DB snapshots (restore cross-VPC same account).
• Route 53 cho RDS: AWS Best Practices - DNS for RDS (khuyến nghị CNAME).
• Cost Calculator: AWS Pricing - RDS Snapshots (~$0.095/GB).
• Automation: Sử dụng EventBridge + Lambda cho daily snapshot/restore (AWS Well-Architected DevOps pillar).

🛠️ Gợi ý triển khai: Tự động hóa bằng Lambda (CloudWatch Events trigger 5 AM: snapshot → restore → update Route53 via boto3). Tiết kiệm 80% so với read replica cross-VPC!