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

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

📖 Tóm tắt câu hỏi:
Một Chuyên gia Cơ sở dữ liệu (Database Specialist) đã di chuyển thành công cơ sở dữ liệu Oracle từ on-premises sang Amazon Aurora PostgreSQL, bao gồm schema và dữ liệu. Trên server on-premises cũ, có các cron jobs viết bằng Python để thực hiện các nhiệm vụ bảo trì như xóa dữ liệu cũ (data purging) và xuất dữ liệu (data exports). Các job này thường hoàn thành trong 5 phút, nhưng đôi khi mất đến 10 phút. Bây giờ, cần thiết lập các job này cho Aurora PostgreSQL với yêu cầu tối thiểu bảo trì (minimal maintenance) và tính sẵn sàng cao (high availability).

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

• Lên lịch chạy các job Python định kỳ (như cron).
• Đảm bảo giải pháp serverless hoặc tự động quản lý để tránh bảo trì thủ công.
• Hỗ trợ thời gian chạy linh hoạt (lên đến 10 phút), chịu lỗi cao (multi-AZ, auto-scaling).
• Aurora PostgreSQL là dịch vụ managed (không thể truy cập trực tiếp OS host), nên không dùng cron truyền thống.

⚙️ Bối cảnh AWS cập nhật đến 2026:
Aurora PostgreSQL (phiên bản mới nhất 16.x) hỗ trợ tích hợp với Lambda qua RDS Proxy hoặc direct connect. Lập lịch job serverless dùng Amazon EventBridge (trước đây gọi CloudWatch Events, vẫn tương thích). Lambda hỗ trợ runtime Python 3.12+, timeout lên đến 15 phút, hoàn hảo cho job 5-10 phút.

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

Đáp án đúng: Create AWS Lambda functions to run the maintenance jobs and schedule them with Amazon CloudWatch Events.

Lý do chi tiết (🛠️ Tại sao chọn cái này?):

• Lambda là dịch vụ serverless, tự động scale, high availability (multi-AZ, no single point of failure), không cần quản lý server/EC2.
• CloudWatch Events (nay là EventBridge) cho phép lập lịch chính xác như cron (rate, cron expressions), trigger Lambda định kỳ.
• Minimal maintenance: AWS handle patching, scaling, logging tự động. Lambda connect Aurora qua VPC/endpoint, chạy Python jobs an toàn.
• Thời gian chạy phù hợp (timeout 15 phút > 10 phút). Chi phí thấp, chỉ tính theo execution time.
• Best practice cho RDS/Aurora maintenance jobs theo AWS Well-Architected Framework (2023-2026 updates).

📋 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á với emoji và lý do bằng tiếng Việt rõ ràng:

• ❌ [SAI] Create cron jobs on an Amazon EC2 instance to run the maintenance jobs following the required schedule.
  Giải thích sai: EC2 yêu cầu quản lý thủ công (patching OS, scaling, monitoring), không minimal maintenance. Nếu instance down, job thất bại (không HA tự động trừ khi dùng ASG phức tạp). Tăng chi phí idle time, vi phạm yêu cầu serverless/HA cao. Không phù hợp cho managed service như Aurora.

• ❌ [SAI] Connect to the Aurora host and create cron jobs to run the maintenance jobs following the required schedule.
  Giải thích sai: Aurora là fully managed DB, không cho phép SSH hoặc truy cập trực tiếp host OS (security best practice). Không thể install cron hoặc chạy script trên host. Nếu cố gắng, vi phạm compliance và không HA (host managed bởi AWS).

• ✅ [ĐÚNG] Create AWS Lambda functions to run the maintenance jobs and schedule them with Amazon CloudWatch Events.
  Giải thích đúng: Như phần trên, Lambda + EventBridge/CloudWatch Events là giải pháp serverless lý tưởng, tự động HA, minimal ops. Hỗ trợ Python jobs connect Aurora qua IAM auth/RDS Proxy. Đáp ứng đầy đủ yêu cầu thời gian chạy và scheduling.

• ❌ [SAI] Create the maintenance job using the Amazon CloudWatch job scheduling plugin.
  Giải thích sai: Không tồn tại "Amazon CloudWatch job scheduling plugin" cho việc chạy maintenance jobs Python như vậy (cập nhật 2026). CloudWatch chủ yếu monitor/logs/alarms, không execute code trực tiếp. EventBridge chỉ schedule triggers, không thay thế Lambda/EC2 cho execution.

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

• AWS Documentation - Aurora Scheduling Jobs: Running maintenance scripts on Amazon RDS (Khuyến nghị Lambda).
• Lambda + EventBridge: EventBridge Rule to Invoke Lambda (Cron-like scheduling).
• Exam Guide DOP-C02 (2024-2026): Domain 3: Automation (Lambda for DB maintenance).
• Well-Architected Reliability Pillar: Serverless > Managed Instances cho HA/minimal maintenance.

💡 Lời khuyên DevOps: Sử dụng Lambda Layers cho Python deps, RDS Data API cho stateless jobs, và monitor bằng CloudWatch Logs/Insights! 🚀

🧩 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 lập cơ chế sao lưu (backup) cho Amazon RDS Multi-AZ DB instance có kích thước 200 GB, với RPO (Recovery Point Objective) là 6 giờ. Nghĩa là, công ty cần đảm bảo có thể khôi phục dữ liệu mà không mất quá 6 giờ dữ liệu gần nhất trong trường hợp disaster recovery (DR). Yêu cầu chính là copy bản sao lưu database sang một Region khác để tuân thủ chính sách DR, đồng thời giải pháp phải tiết kiệm chi phí (cost-effective) và hiệu quả vận hành (operationally efficient).

Amazon RDS Multi-AZ cung cấp high availability (HA) trong cùng Region qua standby replica tự động, nhưng không hỗ trợ DR cross-Region tự động. RDS hỗ trợ automated backups (tự động hàng ngày + transaction logs cho PITR) và manual snapshots (bằng tay hoặc tự động hóa). Tuy nhiên, chỉ manual snapshots mới có thể copy cross-Region, automated snapshots không hỗ trợ tính năng này (theo tài liệu AWS cập nhật 2024-2026). Với RPO 6 giờ, cần snapshot định kỳ every 6 giờ thay vì daily backup mặc định.

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

Đáp án đúng: Create an AWS Lambda function to take an Amazon RDS snapshot every 6 hours and use a second Lambda function to copy the snapshot into another Region

Lý do chi tiết:
🛠️ Giải pháp này sử dụng hai AWS Lambda functions để tự động hóa:

• Lambda đầu tiên gọi API create-db-snapshot để tạo manual snapshot every 6 giờ (sử dụng Amazon EventBridge hoặc CloudWatch Events làm trigger scheduler). Manual snapshot hỗ trợ copy cross-Region qua API copy-db-snapshot với tham số SourceRegion.
• Lambda thứ hai copy snapshot sang Region đích.
  ✅ Cost-effective: Lambda serverless (pay-per-use, rẻ cho task định kỳ), snapshot chỉ lưu khi cần (khoảng 200 GB x số lượng), không chạy replica liên tục.
  ✅ Operationally efficient: Tự động hóa hoàn toàn, không can thiệp thủ công, phù hợp RPO 6 giờ. Không ảnh hưởng performance DB (snapshot là từ standby trong Multi-AZ).
  Kiến thức cập nhật 2026: RDS hỗ trợ Lambda integration tốt hơn qua IAM roles và VPC, EventBridge scheduler chính xác đến phút.

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

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

• ❌ [SAI] Use Amazon RDS automated snapshots and use AWS Lambda to copy the snapshot into another Region
  🧩 Sai vì: Automated snapshots của RDS không thể copy cross-Region (AWS restriction từ lâu, vẫn áp dụng 2026). Lambda không thể bypass hạn chế này qua API copy-db-snapshot (yêu cầu manual snapshot). Ngoài ra, automated snapshots là daily (không phải every 6 giờ), không khớp RPO. Giải pháp không efficient vì Lambda sẽ fail khi copy.

• ❌ [SAI] Use Amazon RDS automated snapshots every 6 hours and use Amazon S3 cross-Region replication to copy the snapshot into another Region
  🧩 Sai vì: RDS không hỗ trợ automated snapshots every 6 giờ (chỉ daily + PITR logs, không customizable schedule như vậy). Snapshots lưu nội bộ S3 managed (không expose bucket public cho CRR). S3 Cross-Region Replication (CRR) chỉ áp dụng cho user-owned S3 objects, không dùng cho RDS snapshots. Toàn bộ invalid và không cost-effective.

• ✅ [ĐÚNG] Create an AWS Lambda function to take an Amazon RDS snapshot every 6 hours and use a second Lambda function to copy the snapshot into another Region
  🛠️ Đúng vì: Như giải thích ở phần đáp án trên. Manual snapshots via Lambda + EventBridge là best practice cho custom RPO cross-Region. Hỗ trợ encryption, tags, và retention tự động delete old snapshots để tiết kiệm chi phí.

• ❌ [SAI] Create a cross-Region read replica for Amazon RDS in another Region and take an automated snapshot of the read replica
  🧩 Sai vì: Cross-Region read replica (async replication) không phải backup copy, mà là live replica chạy liên tục (chi phí cao: compute + storage ~200 GB + data transfer). Automated snapshots của replica vẫn không copy cross-Region được, và lag replication có thể >6 giờ (không đảm bảo RPO). Không efficient cho DR thuần túy (replica dùng cho read scaling hơn), vi phạm cost-effective.

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

• RDS Snapshots & Cross-Region Copy: Amazon RDS User Guide - Copying a DB Snapshot (xác nhận chỉ manual snapshots).
• Lambda + EventBridge cho Scheduling: AWS Lambda Developer Guide - EventBridge.
• DR Best Practices: AWS Whitepaper - Amazon RDS Disaster Recovery (khuyến nghị manual snapshots + Lambda cho custom RPO).
• RPO/RTO với RDS: AWS Well-Architected Framework - Reliability Pillar.

Giải pháp này align hoàn hảo với DevOps practices: IaC, serverless, và monitoring qua CloudWatch! 🚀

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

Câu hỏi mô tả tình huống sau:
Một instance Amazon RDS được tối ưu hóa EBS (EBS-optimized) sử dụng lưu trữ Provisioned IOPS (PIOPS - thường là io1 hoặc io2), nhưng chỉ sử dụng dưới một nửa IOPS được cấp phát trong nhiều giờ dưới tải liên tục. Tuy nhiên, instance gặp độ trễ đọc/ghi cao (multi-second latency), đã đạt giới hạn băng thông tối đa cho throughput đọc (read throughput), trong khi CPU và RAM chỉ sử dụng dưới một nửa tài nguyên.

Vấn đề cốt lõi:
📈 Instance bị nghẽn cổ chai (bottleneck) ở băng thông đọc (read bandwidth), không phải IOPS, CPU hay RAM. Dù IOPS còn dư thừa, nhưng throughput đọc đã max out dẫn đến latency cao. Mục tiêu là tăng performance, giảm latency xuống dưới 1 giây (sub-second).

Bối cảnh AWS (cập nhật đến 2026):
RDS EBS-optimized instances có bandwidth cố định theo instance class (ví dụ: db.m5.large có bandwidth thấp hơn db.m5.4xlarge). PIOPS cung cấp IOPS cao nhưng throughput phụ thuộc bandwidth của instance và EBS volume. Nếu read throughput max out, cần nâng cấp instance class để tăng bandwidth tối đa.

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

Đáp án đúng: Change the DB instance to an instance class with a higher maximum bandwidth

Lý do chi tiết:
🛠️ Instance đang sử dụng hết bandwidth đọc tối đa của class hiện tại, gây latency cao dù IOPS chưa hết. Việc chuyển sang instance class lớn hơn (ví dụ: từ db.t3.medium lên db.m5.2xlarge) sẽ tăng maximum bandwidth (theo specs AWS, có thể lên gấp 2-10 lần tùy class), giải phóng bottleneck read throughput. Latency sẽ giảm xuống sub-second vì dữ liệu đọc nhanh hơn, tận dụng tốt IOPS PIOPS. Đây là giải pháp trực tiếp, hiệu quả nhất theo best practices AWS RDS (không ảnh hưởng storage hay EBS type).

📋 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 văn bản gốc tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai) với giải thích chi tiết bằng tiếng Việt:

• ❌ Increase the size of the DB instance storage
  🧠 Sai vì: Tăng kích thước storage (ví dụ: từ 100GB lên 500GB) chỉ tăng IOPS tối đa cho PIOPS (theo công thức AWS: IOPS max = 50 * kích thước GB, tối đa 256.000 IOPS đến 2026), nhưng không giải quyết bottleneck bandwidth read. Instance đã dùng <50% IOPS và max bandwidth, nên tăng storage vô ích, latency vẫn cao.

• ❌ Change the underlying EBS storage type to General Purpose SSD (gp2)
  🚫 Sai vì: gp2 (nay là gp3 theo cập nhật 2023-2026) có throughput baseline thấp hơn PIOPS (io1/io2: lên đến 1.000 MB/s per volume), và IOPS burst-based thay vì provisioned. Việc downgrade từ PIOPS sang gp2 sẽ giảm performance, tăng latency hơn vì gp2 không phù hợp tải constant read-heavy. RDS PIOPS dành cho high IOPS/low latency, gp2 chỉ cho workload nhẹ.

• ❌ Disable EBS optimization on the DB instance
  ⚠️ Sai vì: EBS optimization cung cấp dedicated bandwidth giữa instance và EBS (tăng throughput ổn định). Disable sẽ làm giảm bandwidth chung, chia sẻ với traffic khác, tăng latency read/write nghiêm trọng hơn (multi-second → hàng chục giây). AWS khuyến cáo luôn enable EBS-optimized cho RDS PIOPS.

• ✅ Change the DB instance to an instance class with a higher maximum bandwidth
  🎯 Đúng vì: (Như giải thích ở phần đáp án đúng). AWS specs (2026): Bandwidth tăng theo instance size/family (ví dụ: db.r6g.2xlarge có ~4.750 Mbps read, cao hơn db.r6g.large ~937 Mbps). Giải pháp này nhanh chóng, không downtime lớn (hỗ trợ Multi-AZ failover).

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

• RDS Storage & IOPS: Amazon RDS Storage Types – Chi tiết PIOPS bandwidth limits.
• Instance Bandwidth Specs: RDS Instance Types & EBS-Optimized Instances – Bảng maximum bandwidth per class.
• Troubleshooting Latency: RDS Performance Insights – Hướng dẫn detect read throughput bottleneck.
• Best Practices: AWS Well-Architected Framework - Reliability Pillar (2024 update): Scale instance class cho bandwidth.

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 case study, hỏi nhé!

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

Câu hỏi này tập trung vào vấn đề kết nối (connectivity) với một instance Amazon RDS sau khi khôi phục (restore) từ snapshot được tạo cách đây 3 ngày. Cụ thể:

• Một công ty đã restore snapshot RDS từ 3 ngày trước, tạo ra một DB instance mới.
• Development team không thể kết nối đến DB instance này (có thể là lỗi timeout, refused connection, v.v.).
• Nguyên nhân có thể (likely cause): Chúng ta cần xác định lý do phổ biến nhất dựa trên hành vi mặc định của AWS RDS khi restore snapshot.

📌 Kiến thức cốt lõi (cập nhật đến 2026): Khi restore RDS snapshot, AWS tạo DB instance mới với các thiết lập mặc định như default security group của VPC (không kế thừa SG từ production DB). Default SG chỉ cho phép inbound traffic từ các instance cùng SG (self-referencing), không mở cổng cho kết nối từ bên ngoài (như dev team từ EC2, local machine, hoặc VPC khác) trừ khi thêm inbound rules. Production DB thường có SG tùy chỉnh (custom SG) với rules cho phép kết nối từ CIDR cụ thể (ví dụ: 0.0.0.0/0 cho public, hoặc VPC peering).

Vấn đề này phổ biến vì dev team có thể connect production DB (có custom SG), nhưng không connect restored DB do thiếu inbound rules trong default SG.

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

Đáp án đúng: The restored DB instance is using the default security group

🛠️ Lý do chi tiết:

• Restore snapshot RDS tạo instance mới, tự động gắn default security group của VPC (không copy SG từ source DB).
• Default SG không có inbound rules mặc định cho phép kết nối từ dev team (thường cần rule cho port 3306/MySQL, 5432/PostgreSQL, v.v., từ IP/CIDR của team).
• Kết quả: Dev team không connect được (lỗi "cannot connect"), trong khi production DB dùng custom SG với rules phù hợp.
• Đây là likely cause phổ biến nhất, theo best practice AWS (phải manually associate custom SG sau restore).

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

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

• ✅ [ĐÚNG] The restored DB instance is using the default security group
  🧩 Giải thích đúng: Như trên, default SG thiếu inbound rules cần thiết cho kết nối từ dev team. Phải tạo/attach custom SG sau restore để fix (qua Console/CLI: modify-db-instance --db-security-groups). Đây là hành vi chuẩn AWS RDS (không thay đổi đến 2026).

• ❌ [SAI] The restored DB instance does not have Enhanced Monitoring enabled
  🧩 Giải thích sai: Enhanced Monitoring (CloudWatch Logs + agent) chỉ dùng để monitor metrics/performance (CPU, memory), không ảnh hưởng đến connectivity. Có thể enable/disable mà không impact kết nối. Snapshot restore không copy monitoring settings, nhưng không liên quan vấn đề.

• ❌ [SAI] The production DB instance is using a custom parameter group
  🧩 Giải thích sai: Parameter group (custom hoặc default) dùng để tune DB parameters (như buffer pool, timeouts), không kiểm soát network access. Restore snapshot dùng parameter group từ snapshot (hoặc default), nhưng production's custom group không ảnh hưởng restored instance's connectivity.

• ❌ [SAI] The production DB instance is using a custom option group
  🧩 Giải thích sai: Option group dùng cho DB options/features (như TDE encryption, MEMcached), không liên quan security/connectivity. Restore snapshot không copy option group từ production, nhưng vấn đề là network (SG), không phải options.

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

• AWS RDS User Guide: Restoring from a DB Snapshot – Xác nhận restored instance dùng default SG/VPC.
• RDS Security Best Practices: Controlling access with security groups – Default SG rules hạn chế inbound.
• Exam Tips (DOP-C02): Topic "RDS High Availability" & "Networking" – Thường test default behaviors post-restore.
• Kiểm tra CLI: aws rds describe-db-instances --db-instance-identifier <id> để verify VpcSecurityGroups.

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! 🚀 Nếu cần lab thực hành, dùng AWS Free Tier restore snapshot và check SG.

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

Câu hỏi xoay quanh một công ty game sử dụng Amazon ElastiCache for Redis với cấu trúc dữ liệu Sorted Set để triển khai bảng xếp hạng (leaderboard). Cluster hiện tại được triển khai với cluster mode bị tắt (cluster mode disabled), và có một replication group với hai replica bổ sung (tức là 1 node primary + 2 node replica). Công ty sắp tổ chức sự kiện game toàn cầu, dự kiến tăng tải write cao hơn khả năng chịu tải của cluster hiện tại.
Mục tiêu: Database Specialist cần chọn phương pháp scale cluster ElastiCache kịp thời trước sự kiện để xử lý write load tăng vọt.
🛠️ Điểm then chốt: Sorted Set là một key duy nhất trong Redis, tất cả các lệnh write (như ZADD, ZINCRBY) đều hướng đến node primary duy nhất (vì cluster mode disabled, không có sharding). Bottleneck chính là throughput write của primary node, cần scale vertical (tăng kích thước instance) để tăng CPU/RAM/network bandwidth.

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

Đáp án đúng: Increase the size of the ElastiCache cluster nodes to a larger instance size.
Lý do:

• Với cluster mode disabled, cluster chỉ có single shard, tất cả write traffic đổ dồn vào primary node. Tăng kích thước instance (ví dụ từ cache.m5.large lên cache.m5.xlarge hoặc lớn hơn) sẽ tăng ngay lập tức CPU, memory và network throughput của primary node, giúp xử lý write load cao hơn mà không cần downtime (online vertical scaling).
• Đây là phương pháp nhanh nhất và phù hợp nhất cho sự kiện sắp tới, theo best practice AWS cho Redis non-clustered (scale up nodes).
• Kiến thức cập nhật 2026: ElastiCache Redis hỗ trợ Multi-AZ with Auto-Failover và vertical scaling seamless, throughput có thể tăng gấp đôi hoặc hơn tùy instance type (ví dụ cache.r7g series mới với Graviton3/Graviton4).

📋 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 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ể:

• ❌ [SAI] Enable cluster mode on the existing ElastiCache cluster and configure separate shards for the Sorted Set across all nodes in the cluster.
  Giải thích sai: Không thể enable cluster mode trên cluster existing mà không recreate cluster mới hoặc migrate dữ liệu thủ công (không hỗ trợ in-place enable). Cluster mode enabled hỗ trợ sharding đa shard, nhưng Sorted Set là single key atomic, không thể tự động "configure separate shards" cho một Sorted Set duy nhất (cần hash tags thủ công để pin key vào shard cụ thể). Việc này gây downtime lớn và phức tạp, không phù hợp scale nhanh trước event.

• ✅ [ĐÚNG] Increase the size of the ElastiCache cluster nodes to a larger instance size.
  Giải thích đúng: Như đã nêu ở phần đáp án, đây là vertical scaling lý tưởng cho non-clustered replication group. AWS cho phép scale node type online (không mất dữ liệu), primary node mới sẽ có throughput write cao hơn đáng kể. Phù hợp với workload leaderboard (high write trên single key).

• ❌ [SAI] Create an additional ElastiCache cluster and load-balance traffic between the two clusters.
  Giải thích sai: Tạo cluster mới và load balance không giải quyết được vấn đề single Sorted Set key (leaderboard data phải nhất quán trên một cluster duy nhất). Load balancing giữa clusters riêng biệt sẽ gây data inconsistency (Redis không hỗ trợ cross-cluster replication tự động cho Sorted Set), tăng độ phức tạp và latency, không scale write cho primary node hiện tại.

• ❌ [SAI] Use the EXPIRE command and set a higher time to live (TTL) after each call to increment a given key.
  Giải thích sai: Lệnh EXPIRE với TTL cao hơn chỉ ảnh hưởng đến memory eviction (giảm tải memory bằng cách giữ data lâu hơn), không tăng write throughput. Write load cao vẫn bottleneck ở primary node (ZINCRBY gọi liên tục), TTL chỉ gián tiếp giảm background tasks chứ không scale CPU/network cho writes.

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

• AWS ElastiCache User Guide - Scaling Redis clusters: docs.aws.amazon.com/AmazonElastiCache/latest/red-ug/Scaling.Redis.Cluster.html → Chi tiết vertical scaling cho non-clustered.
• Best Practices for Redis leaderboards: aws.amazon.com/blogs/database/amazon-elasticache-for-redis-leaderboards/ → Khuyến nghị scale up nodes cho high-write Sorted Sets.
• ElastiCache Scaling Limits (2026): Instance types mới như cache.r8g (Graviton4) hỗ trợ lên đến 15x throughput so với thế hệ cũ.
• Console/CLI: Sử dụng ModifyReplicationGroup API với NodeGroupConfiguration để scale node type.

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 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ử yêu cầu Database Specialist xây dựng dashboard báo cáo hiển thị các chỉ số kinh doanh quan trọng từ cơ sở dữ liệu sản xuất chính chạy trên Amazon Aurora DB cluster. 📊
Yêu cầu chính:

• Dữ liệu đọc bởi dashboard phải sẵn sàng trong vòng 100 milliseconds (ms) sau khi cập nhật (low latency replication). ⚡
• Giải pháp phải tiết kiệm chi phí, xử lý workload đọc không dự đoán được từ dashboard, không ảnh hưởng đến tính sẵn sàng và hiệu suất ghi của cluster chính. 🛡️
  Database Specialist cần xem xét cấu hình hiện tại của Aurora DB cluster và đề xuất giải pháp phù hợp nhất.
  Mục tiêu cốt lõi: Tách biệt workload đọc khỏi workload ghi để tránh bottleneck, đồng thời đảm bảo độ trễ thấp và scale động. (Kiến thức AWS Aurora cập nhật 2026: Aurora hỗ trợ read replicas với replication lag thường <100ms, và auto-scaling replicas từ phiên bản 2019+).

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

Đáp án đúng: Add an automatic scaling policy to the DB cluster to add Aurora Replicas to the cluster based on CPU consumption.
Lý do:

• Aurora Replicas (read replicas) replicate dữ liệu từ primary instance với độ trễ rất thấp (thường dưới 100ms, sub-second replication qua shared storage). Điều này đảm bảo dashboard nhận data fresh ngay lập tức. ⚡
• Automatic scaling policy dựa trên CPU cho phép cluster tự động thêm/bớt replicas (tối đa 15 replicas/cluster), xử lý workload đọc unpredictable mà không ảnh hưởng writes (writes chỉ trên primary). Tiết kiệm chi phí vì scale theo nhu cầu thực tế, chỉ trả cho replicas đang chạy. 💰
• Phù hợp cấu hình hiện tại: Không cần migrate hay tạo cluster mới, chỉ enable policy (qua AWS Console/CLI).
  Nguồn tham khảo: AWS Documentation - Aurora Auto Scaling (cập nhật 2026); Aurora Replication Lag.

📋 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, đánh dấu ✅ đúng hoặc ❌ sai, giữ nguyên văn bản gốc tiếng Anh. Mỗi giải thích tập trung vào lý do phù hợp/không phù hợp với yêu cầu (low latency 100ms, cost-effective, no impact on writes, handle unpredictable reads).

• ❌ Turn on the serverless option in the DB cluster so it can automatically scale based on demand.
  Giải thích sai: Aurora Serverless v2 (cập nhật 2023+) scale compute theo demand, nhưng không đảm bảo latency replication 100ms vì serverless có cold start và pause/resume có thể gây delay >100ms. Hơn nữa, enable serverless yêu cầu migrate toàn bộ cluster (không phải config hiện tại), và writes vẫn chịu ảnh hưởng nếu scale toàn cluster. Không cost-effective cho production OLTP + reporting mix.

• ❌ Provision a clone of the existing DB cluster for the new Application team.
  Giải thích sai: Aurora cluster clone tạo snapshot-based copy (point-in-time), không phải real-time replication, dẫn đến data lag >100ms (có thể hàng phút/giờ). Clone là read-only sau tạo, không scale động cho unpredictable reads, và tạo clone riêng tốn kém (double storage/compute) mà không sync ongoing. Không giải quyết workload reads mà không impact writes.

• ❌ Create a separate DB cluster for the new workload, refresh from the source DB cluster, and set up ongoing replication using AWS DMS change data capture (CDC).
  Giải thích sai: Tạo cluster riêng + DMS CDC (hỗ trợ Aurora sources từ 2022+) có latency cao (thường 1-30 giây, không <100ms do batch processing). DMS overhead cao, phức tạp setup/monitor, tốn chi phí (DMS instances + storage), và không scale tự động cho reads. Refresh ban đầu + ongoing CDC impact performance writes nhẹ do logging overhead.

• ✅ Add an automatic scaling policy to the DB cluster to add Aurora Replicas to the cluster based on CPU consumption.
  Giải thích đúng: Như phần trên, đây là giải pháp tối ưu: Low latency (<100ms), auto-scale reads offload writes, cost-effective (pay-per-use replicas), tích hợp liền mạch với cluster hiện tại. Hoàn hảo cho reporting dashboard! 🚀

Kết luận: Giải pháp tận dụng Aurora read replicas + auto-scaling là best practice AWS cho read-heavy workloads trên production DB. Nếu implement, monitor qua CloudWatch metrics (CPUUtilization, ReplicaLag). 📘

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

Câu hỏi mô tả một công ty bán lẻ đang chuẩn bị di chuyển cửa hàng trực tuyến và di động lên AWS, với kế hoạch mở rộng thương hiệu toàn cầu từ CEO. Database Specialist được giao nhiệm vụ cung cấp hiệu suất đọc/ghi dự đoán được (predictable read and write database performance) và chi phí vận hành tối thiểu (minimal operational overhead).

🛠️ Yêu cầu chính:

• Hỗ trợ mở rộng toàn cầu: Cần cơ chế đồng bộ dữ liệu (synchronize transactions) giữa các vùng (Regions) để đảm bảo tính sẵn sàng cao, độ trễ thấp.
• Hiệu suất dự đoán: Không biến động, phù hợp với lưu lượng truy cập cao từ cửa hàng online/mobile.
• Overhead thấp: Tự động hóa cao, không cần quản lý thủ công phức tạp.
• Bối cảnh: Phù hợp với dữ liệu giao dịch (transactions) như đơn hàng, cần NoSQL cho scalability cao.

Đây là câu hỏi điển hình trong kỳ thi AWS Certified Database - Specialty hoặc DevOps Engineer Professional, tập trung vào dịch vụ managed NoSQL cho multi-region replication (dựa trên cập nhật AWS 2023-2026, với DynamoDB Global Tables v2 hỗ trợ multi-active writes).

✅ Đáp án đúng

Use Amazon DynamoDB global tables to synchronize transactions

Lý do lựa chọn:

• DynamoDB Global Tables cung cấp multi-master replication tự động giữa các Regions, đồng bộ transactions gần thời gian thực (low-latency), đảm bảo hiệu suất đọc/ghi dự đoán nhờ throughput provisioned/on-demand và SLAs 99.999% availability.
• Minimal operational overhead: Hoàn toàn managed, tự động xử lý failover, conflict resolution (last-writer-wins), không cần code custom hay quản lý cluster.
• Phù hợp hoàn hảo cho ứng dụng retail global với traffic cao, scale tự động. (Cập nhật 2026: Global Tables hỗ trợ point-in-time recovery multi-Region).

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

• ✅ Use Amazon DynamoDB global tables to synchronize transactions
  🟢 Đúng vì: Đây là giải pháp tối ưu cho DynamoDB, tự động replicate dữ liệu multi-Region với multi-active writes. Đảm bảo predictable performance (millions requests/sec), zero-downtime global access, và overhead thấp nhất (serverless). Lý tưởng cho transactions retail.

• ❌ Use Amazon EMR to copy the orders table data across Regions
  🔴 Sai vì: Amazon EMR là dịch vụ xử lý big data batch (Hadoop/Spark), chỉ copy dữ liệu thủ công/định kỳ (ETL jobs), không hỗ trợ real-time sync transactions. Overhead cao (quản lý cluster, scaling), không predictable performance cho OLTP, và không phù hợp migrate retail store.

• ❌ Use Amazon Aurora Global Database to synchronize all transactions
  🔴 Sai vì: Aurora Global Database dùng cho relational DB (MySQL/PostgreSQL), chỉ hỗ trợ async replication từ 1 primary sang nhiều read replicas (không multi-master writes). Không predictable cho writes global cao, overhead vận hành cao hơn (quản lý clusters), và kém scale so với NoSQL cho retail non-relational data.

• ❌ Use Amazon DynamoDB Streams to replicate all DynamoDB transactions and sync them
  🔴 Sai vì: DynamoDB Streams chỉ capture changes (event stream), yêu cầu custom application (Lambda/Kinesis) để replicate và sync thủ công giữa Regions. Overhead cao (code, error handling, consistency), không tự động/multi-master như Global Tables, dẫn đến unpredictable performance và phức tạp ops.

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

• DynamoDB Global Tables: docs.aws.amazon.com/amazondynamodb/latest/developerguide/GlobalTables.html – Chi tiết multi-Region replication.
• Aurora Global Database: docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-global-database.html – Giới hạn async replication.
• DynamoDB Streams: docs.aws.amazon.com/amazondynamodb/latest/developerguide/Streams.html – Không thay thế Global Tables.
• AWS Well-Architected Framework - Reliability Pillar: Khuyến nghị Global Tables cho global apps.

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

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

Câu hỏi mô tả tình huống một công ty đang đóng cửa một data center từ xa với 100 TB dữ liệu kho dữ liệu (data warehouse) on-premises. Họ dự định sử dụng AWS Schema Conversion Tool (AWS SCT) và AWS Database Migration Service (AWS DMS) để di chuyển dữ liệu lên AWS. Mạng tại site có băng thông 500 Mbps (khoảng 62.5 MB/s). Việc di chuyển phải hoàn thành trong 2 tuần (14 ngày) khi hệ thống nguồn đang tắt để bảo trì. Dữ liệu cần được mã hóa tại chỗ (at rest) và trong quá trình truyền (in transit). Mục tiêu là sử dụng Amazon S3 làm data lake và Amazon Redshift làm data warehouse.

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

• Lượng dữ liệu khổng lồ (100 TB) với băng thông hạn chế → Tính toán thời gian truyền online: 100 TB ≈ 100.000 GB / 62.5 MB/s ≈ 1,6 triệu giây ≈ 19 ngày (vượt quá 2 tuần).
• Cần phương pháp ít rủi ro nhất (low risk: tránh downtime dài, mất dữ liệu) và khả năng thành công cao (high success: hỗ trợ DMS/SCT, mã hóa KMS, offline transfer).
• Phiên bản AWS mới nhất (2026): AWS Snowball Edge tích hợp DMS cho migration lớn, hỗ trợ schema conversion và data copy offline an toàn.

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

Đáp án đúng: Leverage AWS SCT and apply the converted schema to Amazon Redshift. Start an AWS DMS task with two AWS Snowball Edge devices to copy data from on-premises to Amazon S3 with AWS KMS encryption. Use AWS DMS to finish copying data to Amazon Redshift.

Lý do chọn ✅:

• Phù hợp hoàn hảo với yêu cầu: Sử dụng AWS SCT để convert schema và apply vào Redshift trước. Sau đó, DMS task trên 2 Snowball Edge (mỗi device ~80-100 TB tùy model 2026) để copy dữ liệu on-prem → S3 với KMS encryption (at rest/in transit). Cuối cùng, DMS tiếp tục load từ S3 → Redshift.
• Ít rủi ro & thành công cao 🏆: Offline transfer (Snowball Edge ship vật lý), tránh bottleneck mạng. Thời gian: Copy on-prem ~vài ngày, ship ~3-5 ngày, load DMS nhanh. Hỗ trợ CDC (Change Data Capture) nếu cần delta. Không downtime dài, mã hóa end-to-end.
• Cập nhật 2026: Snowball Edge Compute Optimized hỗ trợ DMS full cho RDBMS → S3/Redshift, cluster mode cho 100 TB+.
• Nguồn tham khảo 📘:
  • AWS DMS with Snowfamily (AWS DMS User Guide 2026).
  • Snowball Edge & DMS Migration.

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

• Phương án 1 ❌: Set up a VPN tunnel for encrypting data over the network from the data center to AWS. Leverage AWS SCT and apply the converted schema to Amazon Redshift. Once complete, start an AWS DMS task to move the data from the source to Amazon S3. Use AWS Glue to load the data from Amazon S3 to Amazon Redshift.
  Giải thích sai ❌: Sử dụng VPN + DMS online để DMS → S3, rồi Glue → Redshift. Rủi ro cao vì truyền 100 TB qua 500 Mbps mất ~19 ngày > 2 tuần, dễ fail do network instability/maintenance window. Glue không tối ưu cho schema-aware migration (thiếu CDC đầy đủ như DMS). Không phù hợp low-risk.

• Phương án 2 ✅: Leverage AWS SCT and apply the converted schema to Amazon Redshift. Start an AWS DMS task with two AWS Snowball Edge devices to copy data from on-premises to Amazon S3 with AWS KMS encryption. Use AWS DMS to finish copying data to Amazon Redshift.
  Giải thích đúng ✅: Như đã phân tích ở trên. Tối ưu nhất 🛠️: SCT schema first, DMS on Snowball Edge (offline, encrypted KMS), 2 devices xử lý 100 TB nhanh chóng, DMS final load Redshift. Low risk (physical ship), high success (native DMS integration). Hoàn hảo cho 2-week window.

• Phương án 3 ❌: Leverage AWS SCT and apply the converted schema to Amazon Redshift. Once complete, use a fleet of 10 TB dedicated encrypted drives using the AWS Import/Export feature to copy data from on-premises to Amazon S3 with AWS KMS encryption. Use AWS Glue to load the data to Amazon redshift.
  Giải thích sai ❌: AWS Import/Export đã deprecated từ 2016, thay bằng Snowball. "Fleet of 10 TB drives" không standard (phải dùng Snowball UI), logistics phức tạp (10 drives cho 100 TB), không hỗ trợ DMS task. Glue load thiếu schema precision. Rủi ro cao (manual handling, no DMS continuity), không recommended 2026.

• Phương án 4 ❌: Set up a VPN tunnel for encrypting data over the network from the data center to AWS. Leverage a native database export feature to export the data and compress the files. Use the aws S3 cp multi-port upload command to upload these files to Amazon S3 with AWS KMS encryption. Once complete, load the data to Amazon Redshift using AWS Glue.
  Giải thích sai ❌: VPN + export manual + s3 cp multi-part upload → online transfer, compress giúp nhưng vẫn ~10-15 ngày cho 100 TB (bandwidth limit). Không dùng DMS/SCT full (manual export mất schema integrity, no CDC). Glue load không atomic. Rủi ro cao (network failure, manual errors), vượt window.

Kết luận 🎯: Phương án 2 là lựa chọn low-risk, high-success duy nhất với Snowball Edge + DMS, phù hợp best practices AWS migration lớn! 🚀

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

Câu hỏi xoay quanh việc tối ưu hóa di chuyển (migration) cơ sở dữ liệu Oracle dung lượng 1 TB từ on-premises sang Amazon Aurora PostgreSQL DB cluster bằng công cụ AWS Database Migration Service (AWS DMS).

🔍 Chi tiết vấn đề:

• Cơ sở dữ liệu Oracle chứa 100 GB dữ liệu LOB (Large Objects - các đối tượng nhị phân lớn) phân bố trên nhiều bảng.
• Kích thước LOB: Tối đa 500 MB, trung bình 350 MB.
• Database Specialist đã chọn AWS DMS với replication instances lớn nhất (largest replication instances) để xử lý tải lớn.
• Mục tiêu: Tối ưu hóa quá trình migration, tập trung vào việc xử lý LOB hiệu quả, tránh chậm trễ hoặc mất dữ liệu.

🛠️ Kiến thức cốt lõi từ AWS DMS (cập nhật đến 2026):

• AWS DMS hỗ trợ migrate LOB từ Oracle sang PostgreSQL/Aurora PostgreSQL.
• Có hai chế độ xử lý LOB:
  • Limited LOB mode: Chỉ migrate LOB nhỏ hơn giới hạn (max LOB size), truncate LOB lớn → Nhanh nhưng không đầy đủ dữ liệu.
  • Full LOB mode: Migrate toàn bộ LOB bằng cách chia thành chunks (kích thước chunk config từ 64 KB đến 64 MB theo tài liệu chuẩn, nhưng có thể tùy chỉnh cao hơn trong một số trường hợp để tối ưu). Chế độ này chậm hơn vì tốn tài nguyên CPU/network.
• Tối ưu hóa khuyến nghị: Tách task riêng cho bảng có LOB (dùng Full LOB mode) và bảng không LOB (dùng chế độ thông thường, nhanh hơn). Single task với Full LOB mode sẽ làm chậm toàn bộ migration.

📘 Nguồn tham khảo:

• AWS DMS User Guide: Handling large binary objects (LOBs) (cập nhật 2024-2026).
• Best Practices: Optimizing DMS for LOB migrations.

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

Đáp án đúng: Create two tasks: task1 with LOB tables using full LOB mode with a LOB chunk size of 500 MB and task2 without LOBs

Lý do:

• 🏆 Tách hai task giúp tối ưu hiệu suất: Task1 chỉ xử lý bảng có LOB (100 GB) với Full LOB mode để migrate đầy đủ dữ liệu lớn (max 500 MB), chunk size 500 MB giúp giảm số lượng chunk (LOB avg 350 MB < 500 MB → ít overhead).
• Task2 migrate dữ liệu còn lại (900 GB không LOB) nhanh chóng mà không bị ảnh hưởng bởi chế độ Full LOB chậm chạp.
• Sử dụng largest replication instances hỗ trợ parallel tasks hiệu quả.
• Tránh mất dữ liệu (không dùng Limited mode) và giảm thời gian tổng thể so với single task.

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

Dưới đây là phân tích từng lựa chọn (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 giải thích chi tiết bằng tiếng Việt:

• ❌ [SAI] Create a single task using full LOB mode with a LOB chunk size of 500 MB to migrate the data and LOBs together
  Lý do sai: Single task áp dụng Full LOB mode cho toàn bộ 1 TB → Làm chậm migration dữ liệu không LOB (900 GB) vì overhead chunking và tài nguyên replication instance bị chiếm dụng. Không tối ưu, vi phạm best practice tách task.

• ✅ [ĐÚNG] Create two tasks: task1 with LOB tables using full LOB mode with a LOB chunk size of 500 MB and task2 without LOBs
  Lý do đúng: Như đã giải thích ở phần đáp án. Tách task thông minh: Task1 (LOB tables) dùng Full LOB + chunk 500 MB để migrate đầy đủ & hiệu quả; Task2 (non-LOB) chạy song song nhanh chóng. Giảm thời gian tổng thể, tận dụng largest instances.

• ❌ [SAI] Create two tasks: task1 with LOB tables using limited LOB mode with a maximum LOB size of 500 MB and task 2 without LOBs
  Lý do sai: Limited LOB mode chỉ migrate LOB ≤ 500 MB, truncate LOB lớn hơn → Mất dữ liệu (mặc dù max LOB là 500 MB nhưng avg 350 MB, vẫn rủi ro). Không đảm bảo migrate đầy đủ 100 GB LOB, vi phạm yêu cầu migration hoàn chỉnh.

• ❌ [SAI] Create a single task using limited LOB mode with a maximum LOB size of 500 MB to migrate data and LOBs together
  Lý do sai: Limited LOB mode truncate LOB > 500 MB → Mất dữ liệu. Single task còn làm migration không tối ưu vì áp dụng giới hạn cho toàn bộ DB, không tận dụng parallel processing.

💡 Lời khuyên thực tế: Sau migration, validate dữ liệu bằng DMS validation hoặc công cụ như pg_dump cho Aurora PostgreSQL. Scale DMS instances nếu cần với AWS DMS Fleet Advisor (tính năng mới 2025+).

🧩 Phân tích 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 bảng Amazon DynamoDB sản xuất. Bảng gốc sử dụng:

• Chế độ dung lượng provisioned read/write capacity mode (dung lượng được cung cấp sẵn).
• Global secondary indexes (GSIs) (các chỉ mục thứ cấp toàn cầu).
• Time to Live (TTL) (tự động xóa dữ liệu hết hạn).

Database Specialist đã restore backup mới nhất vào một bảng mới. Nhiệm vụ là chuẩn bị bảng mới với các thiết lập (settings) giống hệt bảng gốc, bằng cách chọn TWO bước cần thực hiện.

🔍 Mục tiêu chính: Đảm bảo bảng mới sẵn sàng failover DR, kế thừa đầy đủ cấu hình nhưng xử lý các phần không tự động copy từ backup. Theo kiến thức AWS cập nhật đến 2026 (DynamoDB version mới nhất), restore từ backup (Backup & Restore hoặc PITR) tự động sao chép hầu hết settings như capacity, GSIs, encryption, nhưng một số cần cấu hình thủ công do ARN bảng mới khác biệt.

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

• AWS DynamoDB Developer Guide: Backup and Restore (xác nhận settings được inherit).
• AWS Certified Database - Specialty Exam Guide (câu hỏi tương tự trong DBS-C01/DOP-C02).

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

• Define IAM policies for access to the new table
• Define the TTL settings

Lý do lựa chọn 🛠️: Khi restore backup DynamoDB vào bảng mới (sử dụng RestoreTableFromBackup hoặc PITR), hầu hết table settings (như GSIs, provisioned capacity, encryption) được tự động inherit giống hệt. Tuy nhiên:

• IAM policies phải được định nghĩa mới vì ARN bảng mới khác (IAM là permission account-level, không bind trực tiếp vào backup).
• TTL settings cần được định nghĩa lại bằng API UpdateTimeToLive hoặc Console, vì dù config được preserve, xử lý TTL trên dữ liệu restored yêu cầu kích hoạt explicit để đảm bảo xóa items hết hạn giống hệt (tránh gián đoạn DR). Điều này đảm bảo "identical settings" cho failover mượt mà.

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên hành vi restore backup DynamoDB (cập nhật 2026):

• ❌ Re-create global secondary indexes in the new table
  Sai: GSIs được tự động recreate hoàn chỉnh với cùng schema, projection, và capacity khi restore từ backup. Không cần bước thủ công này, vì DynamoDB handle projection indexes trong quá trình restore (có thể mất thời gian backfill data nhưng settings identical ngay).

• ✅ Define IAM policies for access to the new table
  Đúng: IAM policies/roles không được restore từ backup (IAM là service riêng biệt). Bảng mới có ARN và Table Name mới, nên phải tạo policy mới (ví dụ: dynamodb:PutItem trên ARN mới) để applications/users truy cập giống hệt, tránh lỗi permission trong DR.

• ✅ Define the TTL settings
  Đúng: Mặc dù TTL config (enabled attribute) được preserve trong backup, nhưng để TTL processing hoạt động identical trên dữ liệu restored, cần explicit define lại bằng UpdateTimeToLive (chỉ định TTL attribute name). Điều này đảm bảo DynamoDB bắt đầu scan & expire items cũ giống hệt bảng gốc, tránh dữ liệu "treo" trong DR.

• ❌ Encrypt the table from the AWS Management Console or use the update-table command
  Sai: Nếu bảng gốc encrypted (KMS hoặc AWS-managed), encryption settings tự động apply cho bảng mới với cùng key. Không cần update-table hay Console, vì restore inherit encryption at rest đầy đủ.

• ❌ Set the provisioned read and write capacity
  Sai: Provisioned capacity (read/write RCU/WCU) cho bảng chính và GSIs được tự động set giống hệt từ backup. Có thể enable auto-scaling sau nếu cần, nhưng không phải bước bắt buộc để identical settings.

🛡️ Lưu ý DR best practice: Sau restore, monitor CloudWatch metrics (ConsumedReadCapacityUnits, TTLDeletes) và test failover bằng Global Tables nếu áp dụng. Sử dụng AWS CDK/Terraform để automate IAM & TTL cho production DR!