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

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

📖 Nội dung câu hỏi:
Câu hỏi xoay quanh tình huống một công ty sử dụng Amazon Redshift cluster để hỗ trợ đội ngũ Business Intelligence (BI). Cluster có maintenance window (cửa sổ bảo trì) trùng lặp với một số business report jobs chạy long-running queries (các truy vấn chạy lâu). Trong lần bảo trì gần nhất, cluster offline và restart để cập nhật, dẫn đến một số queries bị terminated (chấm dứt đột ngột). Đội BI muốn biết chính xác những queries nào bị terminated trong khoảng thời gian đó.

Nhiệm vụ của database specialist là tìm cách thu thập thông tin này một cách hiệu quả nhất. Đây là vấn đề phổ biến trong Redshift, nơi maintenance (như OS patching, hardware replacement) có thể gián đoạn queries đang chạy, và cần hệ thống log để audit. (Kiến thức cập nhật đến 2026: Redshift vẫn duy trì các system views như SVL_* để monitor queries, với hỗ trợ concurrency scaling và zero-ETL integrations mới, nhưng core logging không thay đổi).

✅ Đáp án đúng: Look for the terminated queries in the SVL_QLOG view.
Lý do chọn:
SVL_QLOG là system view chuyên biệt trong Redshift để lưu trữ thông tin về các queries bị terminated hoặc aborted (bao gồm do maintenance window, user cancel, hoặc lỗi hệ thống). View này ghi lại query ID, user, start/end time, PID, aborted reason (lý do chấm dứt), giúp dễ dàng query để lọc queries bị terminate trong maintenance window (dựa trên timestamp). Đây là cách native, nhanh chóng, không cần code thêm, phù hợp best practice.
Ví dụ query đơn giản: SELECT * FROM SVL_QLOG WHERE aborted_reason LIKE '%maintenance%' AND endtime > 'maintenance_start_time';
🛠️ Nguồn tham khảo: AWS Redshift Docs - SVL_QLOG (https://docs.aws.amazon.com/redshift/latest/dg/r_SVL_QLOG.html) – Cập nhật 2024-2026, vẫn là standard view cho terminated queries.

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

• ✅ [ĐÚNG] Look for the terminated queries in the SVL_QLOG view.
  Như đã giải thích ở trên: Đây là view hệ thống lý tưởng, lưu trữ chính xác dữ liệu về queries terminated do bất kỳ lý do nào, bao gồm maintenance restart. Dễ truy vấn, real-time-ish (retention ~2-7 days tùy cluster size), và không tốn tài nguyên. Best practice cho troubleshooting BI workloads.

• ❌ [SAI] Look for the terminated queries in the SVL_QUERY_REPORT view.
  SVL_QUERY_REPORT cung cấp báo cáo chi tiết về execution của queries đã hoàn thành bình thường (CPU, I/O, steps), nhưng KHÔNG chuyên log terminated/aborted queries. Nó thiếu trường "aborted_reason" và chỉ phù hợp cho performance analysis của successful queries, không phải cho maintenance disruptions.

• ❌ [SAI] Write a scalar SQL user-defined function to find the terminated queries.
  Việc viết scalar UDF (User-Defined Function) là phức tạp hóa không cần thiết, tốn công phát triển/test, và kém hiệu quả vì Redshift đã có ready-made views như SVL_QLOG. UDF chỉ hữu ích cho custom logic phức tạp, không phải để "tìm" log cơ bản – vi phạm nguyên tắc KISS (Keep It Simple, Stupid) trong AWS best practices.

• ❌ [SAI] Use a federated query to find the terminated queries.
  Federated queries (Redshift Spectrum/Federation) dùng để query dữ liệu ngoài Redshift (như S3, RDS, external DB), không áp dụng nội bộ cho system views như SVL_*. Đây là giải pháp sai ngữ cảnh, chậm hơn, và yêu cầu setup IAM roles phức tạp – hoàn toàn không liên quan đến log terminated queries trong cluster local.

📘 Lời khuyên thực tế (DevOps Engineer Pro):
Để tránh vấn đề tương lai, khuyến nghị pause/resume cluster thay vì maintenance overlap (qua API/Console), hoặc dùng Concurrency Scaling cho long-running BI queries (cập nhật 2026: hỗ trợ lên đến 10 clusters). Monitor qua Amazon CloudWatch + Redshift Query Editor v2. Nếu cần audit dài hạn, enable Audit Logging export to S3.
🎯 Kết luận: Chọn SVL_QLOG để giải quyết nhanh, chính xác!

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

Câu hỏi AWS liên quan đến RDS Proxy và quản lý kết nối nhàn rỗi (idle connections):
Một chuyên gia cơ sở dữ liệu (database specialist) phát hiện nhiều kết nối nhàn rỗi trên một DB instance Amazon RDS for MySQL. DB instance này đang sử dụng RDS Proxy, và ứng dụng được cấu hình kết nối qua proxy endpoint.
📌 Vấn đề cốt lõi: RDS Proxy giúp tái sử dụng kết nối đến DB instance để giảm overhead, nhưng nếu có quá nhiều idle connections, nó có thể làm hao phí tài nguyên (như CPU, memory trên DB). Nhiệm vụ là kiểm soát (control) các idle connections này một cách hiệu quả, tận dụng tính năng của RDS Proxy mà không can thiệp trực tiếp vào DB instance.
🛠️ Bối cảnh AWS cập nhật 2026: RDS Proxy (ra mắt từ 2020, cập nhật liên tục) hỗ trợ MySQL/PostgreSQL với các parameter chuyên biệt để quản lý pool connections, đặc biệt hữu ích cho ứng dụng serverless hoặc high-throughput.

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

Đáp án đúng: Modify the MaxIdleConnectionsPercent parameter for the RDS proxy.

Lý do chi tiết:
RDS Proxy cung cấp parameter MaxIdleConnectionsPercent (mặc định 50%) để kiểm soát tỷ lệ phần trăm tối đa các kết nối nhàn rỗi mà proxy được phép giữ trong pool. Bằng cách giảm giá trị này (ví dụ: xuống 20-30%), proxy sẽ tự động đóng các idle connections thừa, giải phóng tài nguyên mà không ảnh hưởng đến DB instance. Đây là cách tối ưu và được khuyến nghị theo best practices AWS, vì RDS Proxy quản lý toàn bộ lifecycle connections từ ứng dụng đến DB. Thay đổi này thực hiện qua AWS Management Console, CLI hoặc API cho RDS Proxy target group.
🔥 Lợi ích: Giảm tải DB, tránh tình trạng connection leak, phù hợp với ứng dụng kết nối qua proxy endpoint.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết:

• ❌ Modify the MaxConnectionsPercent parameter through the RDS Proxy console.
  Phương án này sai vì MaxConnectionsPercent chỉ kiểm soát tổng số kết nối tối đa mà proxy có thể mở đến DB instance (dựa trên max_connections của DB, mặc định 100%). Nó không nhắm trực tiếp vào idle connections, nên không giải quyết được vấn đề nhàn rỗi. Thay đổi parameter này có thể làm giới hạn tổng connections nhưng không kiểm soát idle cụ thể, dẫn đến lãng phí nếu idle vẫn cao.

• ❌ Use CALL mysql.rds_kill(thread-id) for the IDLE threads that are returned from the SHOW FULL PROCESSLIST command.
  Phương án này sai vì lệnh CALL mysql.rds_kill() là thủ công, phải thực hiện lặp lại trên DB instance, và không scalable cho môi trường production (dễ gây downtime hoặc lỗi ứng dụng đang dùng connection). RDS Proxy che giấu các connections thực từ app, nên kill thủ công chỉ là giải pháp tạm thời, không kiểm soát tự động idle connections từ proxy pool. AWS khuyến cáo tránh can thiệp trực tiếp như vậy.

• ✅ Modify the MaxIdleConnectionsPercent parameter for the RDS proxy.
  Phương án này đúng như đã giải thích ở trên. Parameter này được thiết kế chuyên biệt cho idle connections trong RDS Proxy (cập nhật AWS 2024-2026), cho phép cấu hình tự động và an toàn mà không cần restart proxy hay DB.

• ❌ Modify the max_connections configuration setting for the DB instance. Modify the ConnectionBorrowTimeout parameter for the RDS proxy.
  Phương án này sai vì:

  • max_connections trên DB instance chỉ giới hạn tổng connections từ proxy đến DB, không kiểm soát idle (có thể làm DB quá tải nếu tăng).
  • ConnectionBorrowTimeout kiểm soát thời gian chờ mượn connection từ pool (mặc định 120s), không liên quan đến việc đóng idle connections. Kết hợp hai cái này không giải quyết gốc rễ vấn đề idle từ proxy.

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

• AWS RDS Proxy Documentation: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/rds-proxy.html#rds-proxy.configuration (Parameter groups: MaxIdleConnectionsPercent).
• Best Practices for RDS Proxy: https://aws.amazon.com/blogs/database/manage-rds-connections-using-rds-proxy/ (Quản lý idle connections).
• RDS Proxy Parameters: AWS CLI reference modify-db-proxy với --max-idle-connections-percent.
  🧑‍💻 Lời khuyên DevOps: Monitor qua CloudWatch metrics (ProxyIdleConnections, ProxyMaxConnectionsPercent) và set alarms để tự động điều chỉnh!

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

Câu hỏi mô tả một nhà bán lẻ trực tuyến đang sử dụng Amazon DynamoDB để lưu trữ catalog sản phẩm và dữ liệu đơn hàng. Các sản phẩm phổ biến tạo ra các hot keys (key được truy cập thường xuyên), nên công ty triển khai DynamoDB Accelerator (DAX) – một lớp cache in-memory hoàn toàn managed – để tăng tốc độ truy vấn và giảm tải cho DynamoDB. Tuy nhiên, khi số lượng sản phẩm phổ biến tăng dần, nhu cầu cache nhiều items hơn dẫn đến cache miss rate cao (tỷ lệ truy vấn không tìm thấy dữ liệu trong cache, buộc phải fetch từ DynamoDB backend chậm hơn). Vấn đề cốt lõi là cache capacity không đủ để lưu trữ tất cả hot items mà không bị evict (loại bỏ theo cơ chế LRU hoặc TTL). Database specialist cần chọn giải pháp scale DAX phù hợp để đáp ứng yêu cầu thay đổi này, đảm bảo cache hit rate cao hơn, latency thấp, theo kiến thức AWS cập nhật đến 2026 (DAX vẫn hỗ trợ đầy đủ, nhưng AWS khuyến nghị kết hợp với các tính năng DynamoDB mới như Global Tables nếu cần).

✅ Đáp án đúng:
Create a new DAX cluster using a larger node type. Change the DAX endpoint in the application to point to the new cluster.

Lý do lựa chọn (chi tiết):
Giải pháp này thực hiện vertical scaling (scale theo chiều dọc) bằng cách tạo cluster DAX mới với node type lớn hơn (ví dụ: từ dax.t3.medium lên dax.r5.large hoặc cao hơn như r5.24xlarge), giúp tăng đáng kể memory cache per node (lên đến hàng TB tùy type). Với số lượng sản phẩm phổ biến tăng, cần cache nhiều items hơn → larger node type cung cấp cache capacity lớn hơn, giảm eviction và cache miss rate hiệu quả. Lý do kỹ thuật quan trọng: DAX không hỗ trợ thay đổi node type trên cluster hiện tại (immutable sau khi tạo), nên phải tạo cluster mới và cập nhật DAX endpoint trong ứng dụng (zero-downtime nếu dùng blue-green deployment hoặc Route 53). Đây là best practice AWS cho workload memory-intensive với hot keys growing, phù hợp phiên bản 2026 (DAX node types mới nhất: t3/r5 series với tối ưu hóa memory cao hơn).

🛠️ Phân tích tất cả các phương án (đúng/sai):
Tôi sẽ liệt kê từng phương án giữ nguyên văn bản gốc tiếng Anh, kèm giải thích hoàn toàn bằng tiếng Việt với lý do đúng/sai dựa trên tài liệu AWS mới nhất.

• Increase the number of nodes in the existing DAX cluster.
  ❌ Sai. Phương án này thực hiện horizontal scaling (thêm nodes, từ 1 lên tối đa 10 nodes/cluster) qua API ModifyCluster, giúp tăng total cache capacity tuyến tính (tổng memory = nodes × memory/node) và read throughput/availability. Tuy nhiên, nó không giải quyết triệt để cache miss cao do growing items vì: (1) Giới hạn 10 nodes/cluster, nếu đã gần max thì không scale đủ; (2) Không tăng memory per node, hot keys có thể vẫn overload shard trên node nhỏ (DAX shard keys consistent hashing); (3) Không phù hợp "changing requirements" dài hạn so với vertical scaling lớn hơn. Có thể gây latency tạm thời khi rebalance.

• Create a new DAX cluster with more nodes. Change the DAX endpoint in the application to point to the new cluster.
  ❌ Sai. Tương tự phương án trên nhưng tạo cluster mới với nhiều nodes hơn (horizontal scale lớn hơn). Vô ích vì có thể scale nodes trực tiếp trên cluster existing mà không cần tạo mới (tiết kiệm chi phí, ít downtime). Chỉ cần thiết nếu vượt 10 nodes (phải shard multiple clusters), nhưng câu hỏi không đề cập – đây là overkill, không tối ưu cho cache capacity per item phổ biến.

• Create a new DAX cluster using a larger node type. Change the DAX endpoint in the application to point to the new cluster.
  ✅ Đúng. Như đã giải thích ở trên. Vertical scaling hiệu quả nhất cho cache miss do thiếu memory, larger node type (r5 series) cung cấp memory cao gấp nhiều lần (hàng trăm GB/TB/node), cache được nhiều items hơn mà không cần quá nhiều nodes (giảm chi phí, complexity replication). Phù hợp workload hot keys growing đến 2026.

• Modify the node type in the existing DAX cluster.
  ❌ Sai. Không thể thực hiện vì DAX không hỗ trợ modify node type trên cluster existing (cluster config immutable về instance type). Bất kỳ thay đổi vertical đều yêu cầu tạo cluster mới – vi phạm AWS design. Thử sẽ fail.

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

• AWS DAX Scaling Docs: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.concepts.scaling.html (Horizontal: modify node count; Vertical: new cluster for larger type).
• DAX Cluster Management: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/DAX.cluster.management.html (Xác nhận max 10 nodes, vertical scaling procedure).
• DAX Node Types (latest): https://aws.amazon.com/dynamodb/dax/pricing/ (t3.small: ~GBs; r5.24xlarge: TBs memory for cache).
• Best Practice DOP-C02 Exam Guide: Scale DAX vertically for memory-bound cache miss.

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

Câu hỏi xoay quanh tình huống một công ty dịch vụ tài chính đang sử dụng AWS Database Migration Service (AWS DMS) để di chuyển cơ sở dữ liệu từ on-premises lên AWS. Quản trị viên cơ sở dữ liệu đang thực hiện replication với chế độ full load + Change Data Capture (CDC). Trong quá trình CDC, target latency (độ trễ tại đích) cao và tăng dần chậm.
📌 Target latency là thời gian từ khi thay đổi xảy ra trên nguồn đến khi áp dụng thành công trên đích. Vấn đề này thường gặp trong CDC, nơi DMS đọc log thay đổi từ nguồn và áp dụng lên đích. Câu hỏi yêu cầu chọn hai nguyên nhân gốc rễ (root causes) gây ra độ trễ cao và tăng dần, dựa trên kiến thức AWS DMS cập nhật đến năm 2026 (phiên bản DMS hỗ trợ các engine mới như Aurora Serverless v2, multi-region replication, và tối ưu CDC với Elogs).

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

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

• There was no primary key or index in the target database.
• There were resource bottlenecks in the replication instance.

Lý do lựa chọn:
🛠️ Trong CDC, AWS DMS yêu cầu primary key (PK) hoặc unique index trên bảng đích để áp dụng thay đổi nhanh chóng (sử dụng UPSERT/INSERT/UPDATE/DELETE chính xác). Nếu thiếu, DMS phải full table scan để tìm row cần thay đổi, dẫn đến latency cao và tăng dần theo lượng dữ liệu.
🛠️ Resource bottlenecks (CPU, memory, network cao) trên replication instance làm chậm quá trình xử lý log CDC, đặc biệt khi workload tăng, gây tích tụ thay đổi chưa apply → latency tăng dần. Đây là hai nguyên nhân phổ biến nhất theo AWS best practices (xác nhận qua CloudWatch metrics như CDCLatencySource, CDCLatencyTarget).

📋 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. Tôi đánh dấu ✅ ĐÚNG hoặc ❌ SAI dựa trên tài liệu AWS DMS mới nhất:

• ❌ SAI: There was ongoing maintenance on the replication instance.
  🧩 Maintenance trên replication instance (như patching hoặc scaling) sẽ pause task tạm thời chứ không gây latency tăng dần trong CDC đang chạy. DMS tự động resume sau maintenance, và bạn có thể monitor qua CloudWatch Events. Không phải root cause chính cho latency cao liên tục.

• ❌ SAI: The source endpoint was changed by modifying the task.
  🧩 Thay đổi source endpoint qua task modification sẽ restart task hoặc gây lỗi ngay lập tức (task failed), chứ không dẫn đến latency tăng dần chậm. DMS yêu cầu stop task trước khi modify endpoint lớn, tránh tình trạng này.

• ❌ SAI: Loopback changes had affected the source and target instances.
  🧩 Loopback (thay đổi từ đích quay lại nguồn) có thể xảy ra nếu replication hai chiều không cấu hình đúng, nhưng DMS tự detect và skip các thay đổi loopback qua cdc_path hoặc filtering rules. Nó gây conflict chứ không phải latency tăng dần; AWS khuyến nghị dùng Before/After snapshots để tránh.

• ✅ ĐÚNG: There was no primary key or index in the target database.
  🛠️ Thiếu PK/unique index trên đích buộc DMS dùng full scan cho mỗi CDC event (hàng triệu row/table lớn), gây latency cao và tích tụ. AWS docs yêu cầu: "Target tables must have a primary key or unique index for efficient CDC" (xác nhận qua pre-validation task).

• ✅ ĐÚNG: There were resource bottlenecks in the replication instance.
  🛠️ Replication instance undersized (CPU >80%, FreeableMemory thấp, NetworkThroughput cao) làm chậm apply changes từ CDC buffer. Monitor qua CloudWatch (metrics: CPUUtilization, FreeableMemory, CDCLatencyTarget). Giải pháp: Scale up instance (d2/d3 instances mới 2025+).

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

• AWS DMS User Guide - Troubleshooting Latency: docs.aws.amazon.com/dms/latest/userguide/CHAP_Troubleshooting.CDC.html → Phần "High Target Latency" liệt kê chính xác missing PK và resource issues.
• CDC Requirements: docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CDC.html#CDC-PrimaryKeyRequirements → Bắt buộc PK cho target.
• Best Practices 2025+: AWS re:Invent 2025 slides về DMS performance tuning (CloudWatch Embedded Metrics cho CDC latency).
• Monitoring: Sử dụng CloudWatch + DMS Fleet Advisor để detect bottlenecks tự động.

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

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

Câu hỏi yêu cầu một chuyên gia cơ sở dữ liệu thiết lập bảng Amazon DynamoDB tồn tại ở nhiều AWS Regions (multi-Region) và hỗ trợ point-in-time recovery (PITR) – tức khả năng khôi phục dữ liệu đến một thời điểm cụ thể trong quá khứ (lên đến 35 ngày). Giải pháp phải sử dụng global tables của DynamoDB để replicate dữ liệu tự động giữa các Regions, đảm bảo ít overhead vận hành nhất (LEAST operational overhead). Người dùng cần chọn ba bước kết hợp đúng để đạt yêu cầu này.
📘 Lưu ý kiến thức cập nhật (2026): Global tables sử dụng DynamoDB Streams để replicate dữ liệu eventually consistent giữa các Regions. PITR phải kích hoạt riêng trên từng bảng replica (bao gồm base table), không có tùy chọn PITR toàn cục. Table name phải giống nhau ở tất cả Regions, và không được tồn tại sẵn ở Region đích khi thêm replica.

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

Các bước đúng là:

1. Enable DynamoDB Streams for a global table. Set the view type to new and old images.
2. Add a replica table for each Region. Ensure that table names are not already in use in each replica Region.
3. Enable point-in-time recovery for all replica tables.

Lý do lựa chọn:
🛠️ Những bước này tạo global table với replication tự động (qua Streams NEW_AND_OLD_IMAGES bắt buộc cho base table trước khi thêm replica), đảm bảo table name unique ở mỗi Region (nhưng giống nhau toàn cục), và kích hoạt PITR trên tất cả replica tables (base + replicas) để hỗ trợ khôi phục multi-Region. Điều này tối ưu overhead vì DynamoDB tự động quản lý Streams trên replicas, không cần can thiệp thủ công thêm. Nếu thiếu bất kỳ bước nào, global table không hoạt động hoặc PITR không đầy đủ.

📋 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) hoặc ❌ (sai), kèm giải thích bằng tiếng Việt:

• Enable DynamoDB Streams for a global table. Set the view type to new and old images.
  ✅ Đúng. Đây là bước bắt buộc để kích hoạt replication cho global table. Base table phải có Streams với view type NEW_AND_OLD_IMAGES trước khi thêm replica; DynamoDB sẽ tự động enable Streams tương tự trên replicas. Không có loại view khác hỗ trợ global tables.

• Enable DynamoDB Streams for all replica tables.
  ❌ Sai. Streams được tự động kích hoạt trên tất cả replica tables khi thêm vào global table (với NEW_AND_OLD_IMAGES). Việc enable thủ công tạo overhead không cần thiết và có thể gây lỗi nếu cấu hình không khớp.

• Add a replica table for each Region. Ensure that table names are not already in use in each replica Region.
  ✅ Đúng. Để tạo global table, thêm replica ở từng Region đích; DynamoDB yêu cầu table name phải giống base table và không tồn tại sẵn ở Region đó để tránh xung đột. Đây là bước core với overhead thấp nhờ tự động hóa.

• Add a replica table for each Region with a random suffix added to each table name.
  ❌ Sai. Global tables yêu cầu table name giống hệt nhau ở tất cả Regions (không dùng suffix ngẫu nhiên). Sử dụng suffix sẽ tạo các table riêng lẻ, không phải global table, dẫn đến phải quản lý thủ công replication – tăng overhead lớn.

• Enable point-in-time recovery for the global table.
  ❌ Sai. Không tồn tại tùy chọn PITR cho "global table" như một entity duy nhất. PITR chỉ kích hoạt per-table (riêng từng base và replica), nên cách này không hợp lệ và không cung cấp PITR multi-Region.

• Enable point-in-time recovery for all replica tables.
  ✅ Đúng. PITR phải enable riêng trên tất cả replica tables (base + mỗi replica sau khi tạo). Điều này đảm bảo khôi phục point-in-time ở mọi Region, với chi phí tự động scale theo dữ liệu.

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

• DynamoDB Global Tables: Chi tiết steps tạo global table, yêu cầu Streams và table name.
• Point-in-Time Recovery (PITR): Xác nhận PITR per-table, áp dụng cho global tables.
• AWS DOP-C02 Exam Guide: Chủ đề DynamoDB multi-Region trong phần DOP-C02.
  🔍 Kiểm tra thực tế qua AWS Console: Tạo global table sẽ validate Streams và table name tự động!

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

📖 Nội dung câu hỏi:
Câu hỏi xoay quanh một công ty đang sử dụng Amazon Aurora MySQL DB cluster với tính năng automated backup được cấu hình giữ lại trong 10 ngày. Chuyên viên database muốn giảm chi phí lưu trữ backup xuống mức thấp nhất có thể, không gây downtime (không làm gián đoạn hoạt động của DB cluster). Ưu tiên hàng đầu là tối ưu chi phí hơn việc giữ nhiều bản backup.
🛠️ Yêu cầu cụ thể: Thực hiện các hành động trên DB cluster để đáp ứng, tận dụng đặc tính của Aurora: Automated backups hỗ trợ Point-in-Time Recovery (PITR) trong khoảng thời gian retention (0-35 ngày), chi phí lưu trữ backup khoảng $0.095/GB-tháng (giống manual snapshots), nhưng automated backups tự động quản lý và xóa sau retention, giúp tiết kiệm hơn thủ công. Giảm retention period là cách hiệu quả nhất để cắt giảm storage mà vẫn giữ PITR cơ bản, không ảnh hưởng hoạt động (không downtime).

✅ Đáp án đúng:
Change the backup retention period to 1 day. Remove old manual snapshots if they are no longer required.
Lý do chọn: Đây là giải pháp tối ưu chi phí nhất theo phiên bản AWS mới nhất (2026): Giảm retention từ 10 ngày xuống 1 ngày (mức tối thiểu để giữ automated backup và PITR cơ bản), làm giảm đáng kể dung lượng lưu trữ tự động. Đồng thời, xóa manual snapshots cũ giúp dọn dẹp storage thừa. Không gây downtime vì thay đổi retention là online operation (không restart DB). Ưu tiên chi phí > số lượng backup → phù hợp hoàn hảo! 🏆

🔍 Giải thích tất cả các phương án (từng cái một)

• ❌ Disable the automated backup feature by changing the backup retention period to 0 days. Perform manual snapshots daily. Delete old snapshots.
  Sai vì: Việc set retention = 0 tắt hoàn toàn automated backup, mất PITR (chỉ còn manual snapshots tại thời điểm cụ thể, không continuous recovery). Manual snapshots hàng ngày + delete thủ công không tiết kiệm hơn automated (chi phí storage tương đương, nhưng quản lý phức tạp, dễ quên delete → tốn kém hơn dài hạn). Không phải "giảm nhất có thể" vì mất lợi ích PITR tự động của Aurora.

• ✅ Change the backup retention period to 1 day. Remove old manual snapshots if they are no longer required.
  Đúng vì: Như đã giải thích ở trên – giảm retention xuống 1 ngày giữ automated backup tối thiểu (PITR 1 ngày), cắt giảm storage mạnh mẽ (Aurora chỉ giữ backup cần thiết). Xóa manual cũ bổ sung tiết kiệm. Hoàn toàn online, no downtime. Đây là best practice AWS cho cost optimization! 💰

• ❌ Keep the backup retention period at 10 days. Remove old manual snapshots if they are no longer required.
  Sai vì: Giữ 10 ngày không giảm chi phí automated backup (vẫn tốn storage lớn). Chỉ xóa manual cũ là chưa đủ, không đáp ứng "reduce ... as much as possible". Không tối ưu hóa automated storage – phần chính của vấn đề.

• ❌ Disable the automated backup feature by changing the backup retention period to 0 days. Create a backup plan in AWS Backup to perform daily backups.
  Sai vì: Tắt automated (retention=0) rồi dùng AWS Backup cho daily backups thêm chi phí (AWS Backup vault storage + request fees, phức tạp hơn native RDS/Aurora). Không đơn giản, không rẻ hơn automated native, và vẫn cần quản lý delete thủ công. AWS khuyến nghị dùng native automated cho Aurora trước.

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

• AWS RDS User Guide: Managing automated backups – Retention 0-35 ngày, thay đổi online.
• Aurora Best Practices: Cost optimization with backups – Giảm retention là primary way giảm storage.
• AWS Well-Architected Framework (Reliability Pillar): Khuyến nghị retention thấp cho cost-sensitive workloads.
• Pricing: RDS Pricing – Backup storage $0.095/GB-mo, không phân biệt automated/manual.

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 câu hỏi, cứ 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 ứng dụng di động (mobile app) sử dụng Amazon DynamoDB làm cơ sở dữ liệu backend. Ứng dụng gặp phải tình trạng traffic tăng giảm đột ngột trong suốt ngày (sudden increases and decreases in activity), dẫn đến throttling (giới hạn yêu cầu đọc/ghi) ở các thời điểm khác nhau. Điều này gây ra trải nghiệm người dùng kém (negative customer experience).

Vấn đề cốt lõi: DynamoDB đang sử dụng chế độ provisioned capacity (cấu hình RCU/WCU cố định), không đủ linh hoạt để xử lý tải biến động, dẫn đến lỗi ProvisionedThroughputExceededException.

Yêu cầu giải pháp: Phải giải quyết throttling mà KHÔNG yêu cầu thay đổi code ứng dụng (no changes to the app). Giải pháp cần tự động scale theo nhu cầu thực tế, phù hợp với kiến thức AWS cập nhật đến 2024-2026 (DynamoDB On-Demand mode hỗ trợ burst up to 300% và adaptive capacity tự động).

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

• AWS DynamoDB Capacity Modes (cập nhật 2024).
• DynamoDB Best Practices for Handling Throttling.

✅ Đáp án đúng: Use on-demand capacity mode for the DynamoDB table

Lý do lựa chọn:

• On-Demand capacity mode cho phép DynamoDB tự động scale không giới hạn theo traffic thực tế (pay-per-request), xử lý hoàn hảo traffic biến động đột ngột mà không cần dự đoán hoặc cấu hình RCU/WCU.
• Không yêu cầu thay đổi app: Chỉ cần chuyển table sang On-Demand qua Console/CLI/API (ví dụ: UpdateTable API), app vẫn gọi endpoint cũ mà không biết sự khác biệt.
• Hỗ trợ burst capacity lên đến 300% so với phút trước, adaptive throttling tự động phân bổ. Giá: $1.25/ triệu write + $0.25/ triệu read (1MB/request, cập nhật 2024).
• Hoàn hảo cho workload không ổn định như mobile app.

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

• Add a DynamoDB table in a secondary AWS Region. Populate the additional table by using DynamoDB Streams.
  ❌ Sai: Đây là cách thiết lập Global Tables (multi-region replication), giúp high availability và low latency toàn cầu. Tuy nhiên, không giải quyết throttling trên table chính (primary region vẫn throttle nếu traffic cao). Streams chỉ replicate data, không scale capacity. Cần cấu hình app route traffic multi-region → yêu cầu thay đổi app.

• Deploy an Amazon ElastiCache cluster in front of the DynamoDB table.
  ❌ Sai: ElastiCache (Redis/Memcached) là caching layer giảm read latency/load trên DynamoDB. Nhưng không xử lý write throttling (viết vẫn hit DynamoDB trực tiếp), và yêu cầu thay đổi app code để implement caching logic (endpoint mới, TTL, cache invalidation). Không phù hợp no-change-app.

• Use on-demand capacity mode for the DynamoDB table.
  ✅ Đúng: Như giải thích trên. 🛠️ Cách triển khai nhanh: AWS Console > DynamoDB > Tables > Capacity tab > Edit > Chọn "On-demand". Hoặc CLI: aws dynamodb update-table --table-name YourTable --billing-mode PAY_PER_REQUEST.

• Use DynamoDB Accelerator (DAX).
  ❌ Sai: DAX là in-memory cache cho DynamoDB (microsecond latency reads), giảm throttling read bằng cách phục vụ từ cache. Nhưng không xử lý write throttling (viết vẫn provisioned), và yêu cầu thay đổi app endpoint (từ dynamodb.us-east-1.amazonaws.com sang cluster-dax.abc.cache.amazonaws.com). DAX đã deprecated một phần (2023), khuyến nghị Amazon DynamoDB Standard Table với On-Demand.

Kết luận: On-Demand là giải pháp tối ưu, zero-downtime, no-app-change cho throttling do traffic spiky! 🚀 Nếu cần DevOps advice: Monitor bằng CloudWatch Contributor Insights + Auto Scaling nếu hybrid mode.

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

Câu hỏi mô tả một công ty toàn cầu cần di chuyển (migrate) cơ sở dữ liệu Microsoft SQL Server từ on-premises sang giải pháp cơ sở dữ liệu có tính sẵn sàng cao (highly available) trên AWS. Các yêu cầu chính bao gồm:

• Modernize ứng dụng: Chuyển sang công nghệ mới hơn, hiệu suất cao hơn thay vì giữ nguyên SQL Server cũ.
• Giữ chi phí vận hành thấp (low operational costs): Ưu tiên dịch vụ managed để giảm quản lý thủ công.
• Bao gồm secondary indexes và stored procedures: Dữ liệu và schema phức tạp từ SQL Server phải được migrate đầy đủ.
• Ít chuyên gia DB (limited availability of database specialists) và tự động hóa quy trình (automate the process): Cần công cụ tự động, không yêu cầu can thiệp thủ công nhiều.

Giải pháp phải là Multi-AZ deployment (tính sẵn sàng cao qua nhiều Availability Zones) và hướng đến Amazon Aurora MySQL để modernize (Aurora là DB managed, serverless option, chi phí thấp hơn SQL Server on EC2, hỗ trợ MySQL với hiệu suất cao). Đây là tình huống heterogeneous migration (từ SQL Server sang MySQL), đòi hỏi công cụ chuyển đổi schema tự động. Kiến thức cập nhật AWS 2026: AWS DMS và SCT vẫn là best practice cho migration tự động, với hỗ trợ AI-enhanced schema conversion trong SCT mới nhất.

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

Đáp án đúng: Use AWS Database Migration Service (AWS DMS) and the AWS Schema Conversion Tool (AWS SCT) to migrate all database objects from the on-premises SQL Server database to a Multi-AZ deployment of Amazon Aurora MySQL.

Lý do 🛠️:

• Tự động hóa toàn diện: SCT chuyển đổi schema (bao gồm secondary indexes, stored procedures từ SQL Server sang MySQL syntax), DMS migrate data liên tục với minimal downtime. Hoàn hảo cho limited DB specialists.
• Modernize và HA: Aurora MySQL Multi-AZ là managed service, serverless scaling, chi phí thấp hơn (pay-per-use, no EC2 management).
• Đầy đủ objects: SCT hỗ trợ >90% SQL Server features sang Aurora MySQL (cập nhật 2026: cải thiện stored proc conversion với ML).
• Không phương án nào khác tự động hóa schema conversion mà vẫn modernize + low cost.

📋 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 tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích rõ ràng:

• ❌ [SAI] Use AWS Database Migration Service (AWS DMS) to migrate all database objects from the on-premises SQL Server database to a Multi-AZ deployment of Amazon Aurora MySQL.
  Giải thích sai: DMS chỉ migrate data hiệu quả cho homogeneous (cùng engine), nhưng đây là heterogeneous (SQL Server → MySQL). DMS không tự convert schema như indexes/stored procedures (sẽ lỗi syntax). Không automate đầy đủ, cần chỉnh thủ công → vi phạm limited specialists và full objects migration.

• ✅ [ĐÚNG] Use AWS Database Migration Service (AWS DMS) and the AWS Schema Conversion Tool (AWS SCT) to migrate all database objects from the on-premises SQL Server database to a Multi-AZ deployment of Amazon Aurora MySQL.
  Giải thích đúng: Kết hợp hoàn hảo! SCT auto-convert schema (indexes, procs, views từ T-SQL sang MySQL), DMS full data migration ongoing/replication. Aurora MySQL Multi-AZ đảm bảo HA (99.99% uptime), modernize (serverless, auto-scale), low cost (no licensing SQL Server). Best practice AWS cho SQL Server → Aurora (hỗ trợ full automation đến 2026).

• ❌ [SAI] Rehost the on-premises SQL Server as a SQL Server Always On availability group. Host members of the availability group on Amazon EC2 instances. Use AWS Database Migration Service (AWS DMS) to migrate all database objects.
  Giải thích sai: Rehost (lift-and-shift) không modernize (vẫn SQL Server, giữ stored procs cũ). EC2 Always On tốn kém (EC2 + SQL license BYOL), không low cost. DMS chỉ hỗ trợ data, không cần thiết cho rehost → phức tạp, cần specialists quản lý EC2/patching.

• ❌ [SAI] Rehost the on-premises SQL Server as a SQL Server Always On availability group. Host members of the availability group on Amazon EC2 instances in a single subnet that extends across multiple Availability Zones. Use SQL Server tools to migrate the data.
  Giải thích sai: Tương tự trên, không modernize và high cost. "Single subnet across AZs" không phải best practice AWS (deprecated, dùng multi-subnet cho Always On). SQL Server tools (như backup/restore) không automate, downtime cao, cần manual → trái yêu cầu limited specialists.

📘 Tài liệu tham khảo

• AWS DMS Documentation: Heterogeneous Migration with DMS & SCT (cập nhật 2026: hỗ trợ Aurora serverless v2).
• AWS SCT Guide: SQL Server to Aurora MySQL (ML-based conversion >95% accuracy).
• AWS Well-Architected: Database Lens (Migration patterns, low-cost modernization).
• AWS re:Post & Blogs: "Migrating SQL Server to Aurora with SCT/DMS" (2025 updates).

Giải pháp này đạt 6 pillars Well-Architected Framework trên AWS! 🚀

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

Câu hỏi tập trung vào Amazon Aurora PostgreSQL DB cluster đang không được mã hóa tại chỗ (unencrypted at rest), với kích thước 500 GB. Nhiệm vụ là tìm cách NHANH NHẤT để kích hoạt mã hóa tại chỗ (encryption at rest) cho toàn bộ dữ liệu trong cluster.

🔑 Yếu tố quan trọng:

• Aurora hỗ trợ mã hóa tại chỗ bằng AWS KMS keys (từ phiên bản mới nhất 2024-2026, vẫn giữ nguyên cơ chế này).
• Không thể kích hoạt mã hóa trực tiếp trên cluster đang chạy mà không downtime hoặc migration (theo AWS best practices).
• "FASTEST" nghĩa là ưu tiên phương pháp có thời gian thực hiện ngắn nhất, ít phụ thuộc vào kích thước dữ liệu (500 GB), tránh copy đầy đủ hoặc migration liên tục.
• Mã hóa tại chỗ chỉ áp dụng cho storage, không ảnh hưởng performance truy vấn.

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

• Amazon Aurora Encryption Overview (cập nhật 2024).
• Restoring from Snapshots (xác nhận restore snapshot unencrypted thành encrypted cluster).

✅ Đáp án ĐÚNG: Take a manual snapshot of the unencrypted DB cluster. Restore the unencrypted snapshot to a new encrypted Aurora PostgreSQL DB cluster.

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

• Đây là cách nhanh nhất vì snapshot là point-in-time, gần như instantaneous (chỉ metadata, không copy full data ngay lập tức).
• Khi restore snapshot unencrypted, bạn có thể chỉ định KMS key để tạo new cluster encrypted trực tiếp – AWS tự động encrypt data blocks khi restore (lazy loading).
• Thời gian: Phụ thuộc vào kích thước (500 GB ~ vài giờ), nhưng nhanh hơn copy snapshot (không double storage/IO) và nhanh hơn DMS (không cần schema conversion/sync).
• Zero data loss nếu dùng latest snapshot; cluster cũ vẫn chạy song song đến khi switchover.

🛠️ Phân tích TẤT CẢ các phương án (theo thứ tự gốc)

• ❌ Take a manual snapshot of the unencrypted DB cluster. Create an encrypted copy of that snapshot in the same AWS Region as the unencrypted snapshot. Restore a DB cluster from the encrypted snapshot.
  Sai vì: Phải copy snapshot trước (create encrypted copy), quá trình copy full 500 GB data, tốn thời gian (giờ đến ngày, phụ thuộc IO/bandwidth), tăng storage tạm thời. Chậm hơn restore trực tiếp (double steps). Không phải fastest.

• ❌ Create an AWS Key Management Service (AWS KMS) key in the same AWS Region and create a new encrypted Aurora cluster using this key.
  Sai vì: Tạo cluster mới hoàn toàn trống (empty), không migrate data từ cluster cũ. Phải dùng DMS/export/import riêng – không giải quyết encryption cho data hiện tại, chỉ tạo infrastructure mới. Không phải cách secure data gốc.

• ✅ Take a manual snapshot of the unencrypted DB cluster. Restore the unencrypted snapshot to a new encrypted Aurora PostgreSQL DB cluster.
  Đúng vì: Như giải thích trên – snapshot + restore với encryption option là native AWS feature, nhanh nhất cho Aurora (không copy full, chỉ encrypt on-demand khi read/write). Hỗ trợ PostgreSQL cluster đầy đủ.

• ❌ Create a new encrypted Aurora PostgreSQL DB cluster. Use AWS Database Migration Service (AWS DMS) to migrate the data from the unencrypted DB cluster to the encrypted DB cluster.
  Sai vì: DMS là full migration tool (CDC + full load), tốn rất lâu cho 500 GB (task setup, schema conversion, ongoing replication, validation). Có downtime cutover, chi phí cao hơn, không phải fastest (phù hợp cross-region/large-scale, không cho in-place encryption).

💡 Lời khuyên DevOps: Sau restore, update endpoint/app connection, test failover, delete old cluster/snapshot để tiết kiệm chi phí. Sử dụng Automation với Lambda/EventBridge cho production! 🚀

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

Câu hỏi xoay quanh việc thiết kế lại cơ sở dữ liệu cho một ứng dụng SaaS quản lý thông tin nhân viên (employee information application). Hiện tại, kiến trúc sử dụng Amazon RDS for Oracle với một bảng chính lưu thông tin nhân viên và một bảng history (lịch sử thay đổi) được populate tự động qua triggers trên bảng chính.

Hai vấn đề chính cần giải quyết (theo phiên bản AWS mới nhất đến 2026):

• ❌ Không đảm bảo tính bất biến (immutability): Không có cơ chế ngăn chặn việc chỉnh sửa hoặc xóa records trong bảng history sau khi chúng được ghi.
• ❌ Hiệu suất query chậm: Bảng history rất lớn, và các truy vấn thường phải scan qua một lượng dữ liệu khổng lồ (large subset), dẫn đến thời gian phản hồi lâu.

Yêu cầu giải pháp:

• ✅ Ngăn chặn hoàn toàn việc sửa đổi historical records (immutable và verifiable).
• ✅ Tối ưu hóa tốc độ query trên dữ liệu lịch sử lớn.

Giải pháp phải phù hợp với môi trường AWS, tận dụng các dịch vụ managed để dễ scale và bảo mật cao cho SaaS app.

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

Đáp án đúng: Write employee record history to Amazon Quantum Ledger Database (Amazon QLDB) for historical records and to an Amazon OpenSearch Service (Amazon Elasticsearch Service) domain for queries.

Lý do chi tiết:

• 🛡️ Amazon QLDB là dịch vụ ledger database immutable 100%, sử dụng cryptographic hash chain để đảm bảo mọi record lịch sử không thể bị thay đổi, xóa hoặc thêm giả mạo sau khi ghi (verifiable by design). Điều này giải quyết hoàn hảo vấn đề immutability, vượt trội hơn triggers thông thường trên RDS. QLDB hỗ trợ SQL-like queries và tích hợp tốt với SaaS workloads (cập nhật AWS 2023-2026).
• ⚡ Amazon OpenSearch Service (tên mới của Elasticsearch Service từ 2021) là engine tìm kiếm và analytics phân tán, lý tưởng cho full-text search và fast queries trên dữ liệu lớn. Nó index dữ liệu từ QLDB để query siêu tốc (sub-second latency), ngay cả với large subsets, nhờ sharding và caching.
• 🏗️ Kết hợp hoàn hảo: Lưu history chính vào QLDB (immutable storage), replicate/index sang OpenSearch cho query performance. Giải pháp này scalable, serverless, và tuân thủ best practices AWS Well-Architected Framework cho data durability & performance.

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

• AWS QLDB Docs: Quantum Ledger Database (QLDB) (Immutability & Verifiability).
• OpenSearch Service: Amazon OpenSearch Service (Query Optimization).
• AWS Exam Topic DOP-C02 (2026): Database Migration & Ledger Services.

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

• Migrate the current solution to an Amazon DynamoDB table. Use DynamoDB Streams to keep track of changes. Use DynamoDB Accelerator (DAX) to improve query performance.
  ❌ Sai: DynamoDB là NoSQL key-value store tốt cho high-throughput, nhưng không immutable – records có thể bị update/delete. Streams chỉ capture changes (không verifiable), DAX chỉ cache reads (không giải quyết scan large subsets hiệu quả cho history queries). Không phù hợp cho audit/immutability yêu cầu.

• Write employee record history to Amazon Quantum Ledger Database (Amazon QLDB) for historical records and to an Amazon OpenSearch Service (Amazon Elasticsearch Service) domain for queries.
  ✅ Đúng: Như giải thích ở trên – QLDB đảm bảo immutability cryptographic, OpenSearch tối ưu query speed trên large data. Best fit cho requirements (xem tài liệu AWS).

• Use Amazon Aurora PostgreSQL to store employee record history in a single table. Use Aurora Auto Scaling to provision more capacity.
  ❌ Sai: Aurora PostgreSQL là relational DB mạnh mẽ, nhưng không có immutability built-in (records vẫn có thể sửa qua triggers/permissions). Auto Scaling chỉ tăng IOPS/capacity, không cải thiện query speed trên large table scans (vẫn chậm với full scans). Không giải quyết root causes.

• Build a solution that uses an Amazon Redshift cluster for historical records. Query the Redshift cluster directly as needed.
  ❌ Sai: Redshift là data warehouse cho analytics ( columnar storage, good for aggregations), nhưng không immutable (dữ liệu có thể load/update). Query trực tiếp trên large history vẫn chậm nếu không dùng materialized views/Spectrum (latency cao cho ad-hoc queries). Không tối ưu cho real-time SaaS queries.

🛠️ Khuyến nghị thêm: Trong thực tế DOP-C02 exam (2026), ưu tiên ledger services như QLDB cho compliance-heavy workloads. Test với AWS Free Tier để verify!