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

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

Câu hỏi tập trung vào việc thiết kế chiến lược phục hồi thảm họa (Disaster Recovery - DR) cho một ứng dụng có tính sẵn sàng cao đang phát triển, sử dụng Amazon DynamoDB làm kho dữ liệu chính. Yêu cầu cụ thể là:

• RTO (Recovery Time Objective): 1 phút – thời gian tối đa để khôi phục hệ thống sau sự cố.
• RPO (Recovery Point Objective): 2 phút – lượng dữ liệu tối đa có thể mất (tức là dữ liệu được sao lưu cách thời điểm sự cố không quá 2 phút). Mục tiêu là chọn DR strategy cho bảng DynamoDB đáp ứng các yêu cầu này với hiệu quả vận hành cao nhất (MOST operational efficiency), nghĩa là ít công sức quản lý thủ công, tự động hóa tối đa và chi phí hợp lý. Đây là chủ đề thuộc DynamoDB multi-region replication và PITR (Point-in-Time Recovery), cập nhật theo tài liệu AWS mới nhất năm 2024-2026 (DynamoDB Global Tables hỗ trợ replication near-real-time với latency thấp ~giây).

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

• AWS DynamoDB Global Tables
• DynamoDB Point-in-Time Recovery (PITR)
• DynamoDB DR Best Practices

✅ Đáp án đúng

Use a DynamoDB global table replica in another AWS Region. Activate point-in-time recovery for both tables.

Lý do lựa chọn:

• DynamoDB Global Tables tự động replicate dữ liệu multi-region với độ trễ thấp (near-real-time, thường <1 giây), đảm bảo RPO <2 phút (dữ liệu đồng bộ liên tục).
• Kết hợp PITR trên cả hai bảng cho phép khôi phục đến bất kỳ điểm thời gian nào trong 35 ngày, hỗ trợ RTO ~1 phút qua failover tự động hoặc manual.
• Operational efficiency cao nhất: Hoàn toàn managed bởi AWS, không cần code custom, tự động xử lý conflict resolution (last-writer-wins), và tích hợp seamless với ứng dụng. Đây là giải pháp khuyến nghị chính thức cho DR global của DynamoDB (cập nhật 2024).

🛠️ Phân tí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 giá dựa trên khả năng đáp ứng RTO/RPO và hiệu quả vận hành:

• Create a DynamoDB stream and an AWS Lambda function. Configure the Lambda function to process the stream and copy the data to a table in another AWS Region.
  ❌ Sai: Phương án này sử dụng DynamoDB Streams + Lambda để replicate thủ công cross-region. Tuy có thể đạt RPO gần real-time (nếu Lambda xử lý nhanh), nhưng RTO >1 phút do cần rebuild index, xử lý backlog streams, và failover manual. Không efficient: Yêu cầu code/maintain Lambda, xử lý lỗi retry/dead-letter queue, scaling thủ công – tốn công vận hành cao so với native features.

• Use a DynamoDB global table replica in another AWS Region. Activate point-in-time recovery for both tables.
  ✅ Đúng: Như giải thích ở trên, đây là giải pháp tối ưu với replication tự động, PITR hỗ trợ khôi phục nhanh, và zero-management overhead. Hoàn hảo cho RTO 1 phút (failover nhanh) & RPO 2 phút (sync continuous).

• Use a DynamoDB Accelerator (DAX) table in another AWS Region. Activate point-in-time recovery for the table.
  ❌ Sai: DAX là in-memory cache layer cho DynamoDB (không phải data store chính), chỉ cache dữ liệu read-heavy, không hỗ trợ replication cross-region tự nhiên hay lưu trữ persistent. PITR chỉ áp dụng cho DynamoDB table gốc, không cho DAX. Không đáp ứng RTO/RPO: Cache miss sau failover sẽ chậm, và mất dữ liệu nếu cluster DAX fail – không phải DR strategy thực thụ.

• Create an AWS Backup plan. Assign the DynamoDB table as a resource.
  ❌ Sai: AWS Backup cho DynamoDB chủ yếu dựa trên PITR (continuous backups 35 ngày), hỗ trợ restore point-in-time nhưng chỉ trong cùng region (không cross-region tự động). RTO >1 phút do restore manual và provisioning table mới; RPO có thể >2 phút nếu không kết hợp replication. Ít efficient: Cần setup vault/cross-region copy thủ công, không tự động failover như Global Tables. Phù hợp backup hơn DR active-active.

🧩 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 đang sử dụng Amazon RDS for MySQL cho ứng dụng sản xuất (production application). Trong scheduled maintenance window sắp tới, chuyên gia cơ sở dữ liệu cần thực hiện major version upgrade (nâng cấp phiên bản lớn) cho DB instance. Yêu cầu chính là giảm thiểu thời gian bảo trì (minimize maintenance time) và cho phép rollback (hoàn nguyên) nếu xảy ra sự cố, vì ứng dụng rất quan trọng (critical).

🛠️ Thách thức chính: Major version upgrade trên RDS MySQL thường gây downtime đáng kể (có thể vài giờ) nếu thực hiện trực tiếp trên primary DB instance. Giải pháp cần đảm bảo:

• Downtime ngắn nhất có thể (chỉ vài phút).
• Có cơ chế rollback nhanh chóng, ví dụ bằng cách chuyển hướng traffic và khôi phục từ replica cũ nếu upgrade thất bại.
• Tận dụng các tính năng RDS như read replica để tránh gián đoạn primary.

📘 Kiến thức cập nhật (đến 2026): Theo tài liệu AWS mới nhất, RDS hỗ trợ major version upgrade với low-downtime strategy qua read replica cho MySQL (từ version 5.7 lên 8.0, hoặc tương tự). Phương pháp này được khuyến nghị thay vì upgrade trực tiếp primary, giúp downtime chỉ khoảng 1-5 phút khi promote replica.

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

Đáp án đúng: Create read replica of the DB instance. Upgrade the version on the read replica. Promote the read replica to be the primary DB instance. Direct the application to use the read replica endpoint.

Lý do:

• 🟢 Tạo read replica từ primary (không downtime cho primary).
• Nâng cấp major version trên read replica (chỉ downtime cho replica, primary vẫn hoạt động bình thường).
• Promote read replica thành primary (downtime rất ngắn ~1-5 phút, tùy kích thước DB).
• Chuyển ứng dụng sang read replica endpoint (sau promote, endpoint mới trở thành primary).
• Rollback dễ dàng: Nếu vấn đề xảy ra sau promote, có thể tạo read replica mới từ snapshot của primary cũ (trước upgrade) và promote lại, hoặc giữ replica cũ làm backup.
• Hoàn hảo đáp ứng minimize downtime và rollback capability, phù hợp với best practice AWS cho production MySQL major upgrade.

📋 Phân tích chi tiết từng phương án

Dưới đây là phân tích tất cả các 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 hoàn toàn bằng tiếng Việt.

• Enable the automatic upgrade option by using the AWS Management Console. Amazon RDS will apply the upgrade, which will occur during the scheduled maintenance window with no downtime.
  ❌ Sai: Tùy chọn "auto minor version upgrade" chỉ áp dụng cho minor version (ví dụ 8.0.32 lên 8.0.36), không hỗ trợ major version (như 5.7 lên 8.0). Major upgrade luôn yêu cầu manual intervention và gây downtime lớn (hàng giờ), không "no downtime". Không đáp ứng yêu cầu minimize time và rollback.

• Create a new DB instance that has the desired version. Configure AWS Database Migration Service (AWS DMS) to migrate the existing data to the new DB instance. Change the DNS records to point to the new DB instance.
  ❌ Sai: Tạo DB mới và dùng AWS DMS để migrate sẽ mất thời gian dài (giờ đến ngày, tùy kích thước dữ liệu), không minimize maintenance time. DMS full-load + CDC gây lag và phức tạp. Switch DNS cần TTL thấp và Route 53, nhưng downtime khi cutover lớn. Rollback khó (phải migrate ngược), không phù hợp production critical.

• Create read replica of the DB instance. Upgrade the version on the read replica. Promote the read replica to be the primary DB instance. Direct the application to use the read replica endpoint.
  ✅ Đúng: Như giải thích ở trên. Đây là standard low-downtime strategy cho RDS MySQL major upgrade. Read replica sync dữ liệu real-time (low lag), upgrade replica riêng biệt, promote nhanh, endpoint tự động update sau promote. Rollback linh hoạt qua snapshot/replica cũ. Hoàn toàn khớp yêu cầu.

• Create a read replica of the DB instance. Configure a policy to fail over to the read replica if failure occurs during the upgrade. Upgrade the version on the primary DB instance.
  ❌ Sai: Upgrade trực tiếp trên primary vẫn gây downtime lớn (full backup/restore trong upgrade). Read replica chỉ làm failover nếu primary fail, nhưng read replica không sync được major version khác (replication dừng khi version khác biệt). Failover policy (qua RDS console/EventBridge) không ngăn downtime ban đầu, và sau upgrade primary, replica cũ vô dụng. Không minimize time và rollback kém.

📘 Tài liệu tham khảo

• AWS RDS User Guide - Major Version Upgrades: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MajorVersion.html (Khuyến nghị read replica cho MySQL).
• AWS Best Practices - Low-Downtime Upgrades: https://aws.amazon.com/blogs/database/best-practices-for-mysql-major-version-upgrades-using-amazon-rds-read-replicas/ (Cập nhật 2023-2026, downtime <5 phút).
• RDS Read Replicas Docs: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ReadRepl.html (Hỗ trợ promote và version upgrade riêng).

🛠️ Lời khuyên DevOps: Trong production, kết hợp với RDS Blue/Green Deployments (ra mắt 2023, cập nhật 2026) cho zero-downtime nâng cấp, nhưng read replica vẫn là giải pháp cơ bản nhất cho MySQL major upgrade!

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

Câu hỏi tập trung vào chiến lược phục hồi thảm họa (disaster recovery) cho cơ sở dữ liệu Amazon RDS for PostgreSQL ở vùng us-east-2, cần tạo bản sao ở vùng us-west-2 với downtime tối thiểu. Kiến trúc sư cơ sở dữ liệu chọn AWS Database Migration Service (AWS DMS) để sao chép dữ liệu cross-region: đầu tiên dùng full load mode (tải toàn bộ dữ liệu ban đầu), sau đó chuyển sang change data capture (CDC) mode (bắt các thay đổi liên tục).

📌 Yêu cầu chính: Chọn ba tham số PostgreSQL cần cấu hình trên nguồn RDS để hỗ trợ CDC mode. Những tham số này phải được đặt trong parameter group của RDS instance (và yêu cầu reboot để áp dụng). Đây là kiến thức cốt lõi từ AWS DMS User Guide (cập nhật 2024-2026), nơi CDC trên PostgreSQL sử dụng logical replication slots dựa trên Write-Ahead Logging (WAL) để stream thay đổi dữ liệu thời gian thực.

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

Các đáp án đúng là:

• Set wal_level = logical.
• Set max_replication_slots to 1 or more, depending on the number of DMS tasks.
• Set wal_sender_timeout to 20,000 milliseconds.

Lý do lựa chọn: Những tham số này là bắt buộc theo tài liệu AWS DMS cho nguồn PostgreSQL CDC (logical decoding). wal_level=logical kích hoạt WAL ở mức logical để DMS đọc thay đổi. max_replication_slots cần >=1 (tùy DMS task) để tạo replication slot. wal_sender_timeout=20s đủ cao để tránh timeout trong replication cross-region (cao hơn giá trị mặc định thấp). Không chọn các giá trị sai vì chúng không hỗ trợ CDC hoặc gây lỗi.

🛠️ Giải thích chi tiết từng phương án

Dưới đây là phân tích tất cả 6 phương án, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá đúng/sai dựa trên yêu cầu CDC DMS PostgreSQL (phiên bản PostgreSQL 13-16 trên RDS, cập nhật 2026).

• ✅ Set wal_level = logical.
  Đúng: Tham số wal_level phải đặt thành logical để PostgreSQL tạo WAL records ở định dạng logical decoding, cho phép DMS sử dụng pg_logical để bắt CDC. Nếu không, DMS không thể đọc thay đổi dữ liệu. (Mặc định là replica hoặc minimal, không hỗ trợ logical.)

• ❌ Set wal_level = replica.
  Sai: wal_level=replica chỉ hỗ trợ physical replication (streaming WAL bytes), không tạo logical WAL records cần cho DMS CDC. Sẽ gây lỗi "logical decoding not supported" khi DMS cố tạo replication slot.

• ✅ Set max_replication_slots to 1 or more, depending on the number of DMS tasks.
  Đúng: Tham số này giới hạn số replication slots (mỗi DMS task cần 1 slot). Phải >=1 (thường 3-10 tùy task DMS). Nếu =0, không tạo được slot, CDC thất bại. DMS docs khuyến nghị tính theo số task để tránh hết slot.

• ❌ Set max_replication_slots to 0 to support dynamic allocation of slots.
  Sai: Giá trị 0 vô hiệu hóa hoàn toàn replication slots, PostgreSQL không cho tạo slot mới. Không có "dynamic allocation" như vậy; phải đặt cố định >=1. DMS sẽ báo lỗi "no more replication slots available".

• ✅ Set wal_sender_timeout to 20,000 milliseconds.
  Đúng: Tham số kiểm soát timeout cho WAL sender process (60s mặc định). 20.000ms (20 giây) đủ cao cho replication cross-region, tránh disconnect do lag mạng. DMS khuyến nghị >=20-60s cho CDC ổn định, đặc biệt multi-AZ/Regions.

• ❌ Set wal_sender_timeout to 5,000 milliseconds.
  Sai: 5.000ms (5 giây) quá thấp, gây timeout thường xuyên nếu có lag replication (phổ biến cross-region). DMS docs cảnh báo giá trị thấp dẫn đến replication slot bị drop, làm gián đoạn CDC và yêu cầu restart task.

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

• AWS DMS User Guide - Using PostgreSQL as a source: docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.PostgreSQL.html → Phần "Extra connection attributes" và "Requirements for CDC".
• RDS PostgreSQL Parameter Groups: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Appendix.PostgreSQL.CommonDBATasks.LogicalReplication.html → wal_level, max_replication_slots, wal_sender_timeout.
• Best Practices DMS CDC Cross-Region: AWS Well-Architected Framework - Reliability Pillar (2025 update).

🛡️ Lưu ý: Sau cấu hình, reboot RDS source và tạo DMS task với slot_name unique. Test bằng pg_replication_slots để verify!

🧩 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 việc triển khai disaster recovery (DR) cho một Amazon RDS Multi-AZ DB instance dung lượng 250 GB. Chính sách DR của công ty yêu cầu RPO (Recovery Point Objective) là 6 giờ ở một AWS Region thứ hai. Nghĩa là, hệ thống phải đảm bảo có thể khôi phục dữ liệu với mức mất mát tối đa không quá 6 giờ dữ liệu gần nhất, và dữ liệu sao lưu phải được lưu trữ ở region khác để tránh ảnh hưởng từ sự cố region chính.

Yêu cầu MOST cost-effectively (tiết kiệm chi phí nhất), vì vậy giải pháp phải cân bằng giữa tần suất snapshot (mỗi 6 giờ), sao chép cross-region, quản lý tự động, và chi phí thấp (tránh data transfer liên tục, compute thừa, hoặc dịch vụ phức tạp). RDS Multi-AZ đã đảm bảo high availability trong region chính, nhưng cần DR cross-region. Kiến thức cập nhật đến 2026: AWS Backup (với phiên bản mới nhất hỗ trợ granular scheduling và cross-region copy tự động cho RDS) là lựa chọn tối ưu theo best practices của AWS Well-Architected Framework (Reliability Pillar).

✅ Đáp án đúng:
Use AWS Backup to take an RDS snapshot every 6 hours and to copy the snapshot to a second Region.

Lý do lựa chọn (chi tiết):
🛠️ AWS Backup là dịch vụ managed backup chuyên dụng, hỗ trợ RDS snapshots với schedule tùy chỉnh linh hoạt (cron-based, ví dụ mỗi 6 giờ), và tự động copy cross-region mà không cần code thủ công.

• Đáp ứng RPO 6 giờ: Backup plan có thể set retention và frequency chính xác.
• Cost-effective nhất: Chỉ tính phí theo backup storage ( $0.05/GB/tháng) + backup operations ($0.05/copy), không tốn data transfer liên tục như read replica. Với 250 GB, chi phí hàng tháng thấp ($12.5 storage + phí nhỏ cho 4 backup/ngày).
• Tích hợp Vault Lock và centralized management cho compliance.
  📘 Tài liệu tham khảo: AWS Backup User Guide - RDS Support & Cross-Region Copy (cập nhật 2025 với enhanced scheduling).

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

• ❌ [SAI] Use RDS automated snapshots. Create an AWS Lambda function to copy the snapshot to a second Region.
  Phương án này không khả thi và không cost-effective. RDS automated snapshots chỉ hỗ trợ daily retention (1-35 ngày), không cho phép custom interval như 6 giờ (phải dùng manual snapshot hoặc AWS Backup). Lambda để copy cross-region cần custom code, trigger bằng EventBridge, xử lý snapshot ID, và chịu phí Lambda invocations + data transfer out (~$0.09/GB cross-region). Phức tạp, dễ lỗi, không managed → chi phí cao hơn và rủi ro O&M.

• ❌ [SAI] Use RDS automated snapshots every 6 hours. Use Amazon S3 Cross-Region Replication to copy the snapshot to a second Region.
  Không chính xác về tính năng. RDS automated snapshots không hỗ trợ interval 6 giờ (chỉ daily, dựa trên backup window). RDS snapshots được lưu internal trên S3 nhưng không expose public S3 bucket để dùng CRR (Cross-Region Replication). Phải copy thủ công qua API → vô hiệu hóa CRR, thêm chi phí storage thừa và data transfer. Không phải best practice.

• ✅ [ĐÚNG] Use AWS Backup to take an RDS snapshot every 6 hours and to copy the snapshot to a second Region.
  Như đã giải thích ở trên: Hoàn hảo khớp yêu cầu, managed service, schedule granular, auto cross-region copy, thấp nhất chi phí (không compute liên tục, chỉ backup khi cần). Hỗ trợ incremental backups cho RDS từ 2024, giảm storage 50-70%.

• ❌ [SAI] Create an RDS cross-Region read replica in a second Region. Use AWS Backup to take an automated snapshot of the read replica every 6 hours.
  Đắt đỏ và thừa thãi. Cross-Region Read Replica (CRR) replicate dữ liệu liên tục (real-time, lag <1 phút), tốn compute instance thứ hai + data transfer ongoing (~$0.09/GB + IOPS cao cho 250 GB → hàng trăm USD/tháng). Snapshot read replica mỗi 6 giờ chỉ cần cho RPO, nhưng chi phí replica vượt trội so với backup thuần → không MOST cost-effective. Chỉ dùng nếu cần RTO thấp (sub-minute failover).

🛡️ Kết luận best practice: AWS khuyến nghị AWS Backup cho backup/DR cross-region với RPO >1 giờ, thay vì replica đắt đỏ. Kết hợp với Amazon RDS Snapshots manual nếu cần, nhưng Backup vượt trội về management. Test restore thường xuyên để verify! 📘 AWS DR Best Practices.

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

Câu hỏi xoay quanh việc một quản trị viên cơ sở dữ liệu (DBA) đang kiểm tra triển khai ứng dụng sử dụng Amazon DynamoDB. Các instance Amazon EC2 đang truy cập cơ sở dữ liệu bằng địa chỉ IP public, và DynamoDB đang có thể truy cập từ internet. Chính sách công ty yêu cầu tất cả dữ liệu doanh nghiệp phải được truy cập riêng tư (privately) và không cho phép truy cập từ internet bên ngoài.

📌 Vấn đề chính cần giải quyết:

• EC2 instances (trong VPC) đang dùng public IP để kết nối DynamoDB → Giao thông đi qua internet (không an toàn).
• DynamoDB là managed service, mặc định public qua internet nếu không cấu hình.
• Yêu cầu: Đảm bảo truy cập chỉ private từ VPC, chặn hoàn toàn external access từ internet.
• Chọn TWO steps (kết hợp hai bước) để đạt yêu cầu này.

🛠️ Giải pháp AWS phù hợp (dựa trên kiến thức cập nhật 2026):

• Sử dụng Gateway VPC Endpoint cho DynamoDB để route traffic private trong AWS network (không qua internet).
• Kết hợp IAM policy condition để restrict chỉ cho phép từ VPC endpoint cụ thể.

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

Hai phương án đúng là:

1. Create a gateway VPC endpoint for DynamoDB. Update the VPC route table.
2. Use the aws:sourceVpce condition for all the IAM roles that provision access to the table.

Lý do lựa chọn:

• Gateway VPC Endpoint cho DynamoDB cho phép EC2 trong VPC truy cập DynamoDB hoàn toàn private qua AWS backbone network, không qua public internet. Cập nhật route table để route prefix dynamodb.* (như vpce-xxx) thay vì 0.0.0.0/0.
• aws:sourceVpce condition trong IAM policy (cho roles của EC2) đảm bảo chỉ traffic từ VPC endpoint cụ thể mới được phép truy cập table, chặn mọi external access (kể cả từ internet hoặc VPC khác).
• Kết hợp hai bước này đảm bảo 100% private access, tuân thủ policy công ty. Không cần public endpoint hay NAT.

📋 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 tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm lý do chi tiết bằng tiếng Việt.

• Configure the DynamoDB security group and network ACLs to block external access.
  ❌ Sai. DynamoDB là managed service, không có security group (chỉ VPC resources như EC2/ALB mới có). Network ACLs chỉ kiểm soát traffic tại subnet level trong VPC, không block được traffic từ internet đến DynamoDB API endpoint. Không giải quyết được vấn đề public access.

• Create an AWS PrivateLink VPC endpoint for DynamoDUpdate the VPC route table.
  ❌ Sai. AWS PrivateLink sử dụng Interface VPC Endpoint, nhưng DynamoDB chỉ hỗ trợ Gateway VPC Endpoint (không phải Interface/PrivateLink). Lỗi chính tả "DynamoDUpdate" có thể là "DynamoDB", nhưng dù sao cũng không đúng loại endpoint. Không route đúng traffic private.

• Create a gateway VPC endpoint for DynamoDB. Update the VPC route table.
  ✅ Đúng. Đây là bước cốt lõi để EC2 truy cập DynamoDB private mà không qua internet. Gateway endpoint (free, scalable) thêm route pl-*.dynamodb.* vào route table của subnet → Traffic ở lại AWS network. Áp dụng cho toàn VPC.

• Provision a NAT gateway to access DynamoDB. Update the VPC route table.
  ❌ Sai. NAT Gateway dùng cho outbound traffic từ private subnet ra internet (ví dụ: EC2 private subnet download updates). Ở đây, DynamoDB không yêu cầu NAT vì đã có Gateway Endpoint private. Sử dụng NAT vẫn đi qua public internet → Vi phạm policy.

• Use the aws:sourceVpce condition for all the IAM roles that provision access to the table.
  ✅ Đúng. Thêm condition "aws:SourceVpce": "vpce-xxxx" vào IAM policy của roles (EC2 instance profile) → Chỉ cho phép request từ VPC endpoint cụ thể, chặn external/internet access ngay tại authorization level. Bổ sung hoàn hảo cho Gateway Endpoint.

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

• Gateway VPC Endpoint for DynamoDB: AWS VPC Endpoints docs – Xác nhận DynamoDB dùng Gateway (prefix: com.amazonaws.region.dynamodb).
• IAM Condition aws:SourceVpce: IAM Policy Conditions for VPC Endpoints – Hướng dẫn restrict source VPC endpoint.
• Best Practices DynamoDB Security: DynamoDB Security Best Practices – Nhấn mạnh private access via endpoints + IAM conditions.
• Exam Topic DOP-C02: VPC connectivity & DynamoDB trong AWS Certified DevOps Engineer Professional.

🛡️ Tóm tắt: Kết hợp Gateway Endpoint + IAM condition là giải pháp chuẩn AWS, zero-cost cho endpoint, đảm bảo compliance. Nếu triển khai, test bằng aws dynamodb describe-table từ EC2 private!

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

Câu hỏi xoay quanh tình huống thực tế trên AWS RDS for PostgreSQL (phiên bản mới nhất đến 2026 vẫn giữ nguyên các best practices về snapshot và maintenance).
Một công ty đã tạo snapshot từ DB instance PostgreSQL production đang chạy production database. Sau đó, họ tạo DB instance mới từ snapshot này để test tính năng ứng dụng mới, đảm bảo isolation (cách ly) khỏi production.
📈 Vấn đề chính: Trong quá trình testing, read latency (độ trễ đọc dữ liệu) trên DB instance mới cao bất thường.
🎯 Yêu cầu: Database specialist cần giải quyết vấn đề này với MOST operational efficiency (hiệu quả vận hành cao nhất), nghĩa là giải pháp nhanh chóng, ít can thiệp thủ công, không gây downtime lớn, và tận dụng tính năng native của RDS/PostgreSQL.

Nguyên nhân gốc rễ (root cause): Khi restore từ snapshot, database có thể chứa nhiều dead tuples (dữ liệu "chết" từ transactions cũ chưa được cleanup). Autovacuum của PostgreSQL chưa kịp chạy đầy đủ trên DB mới, dẫn đến statistics outdated (thống kê bảng lỗi thời). Query planner không tối ưu, gây read latency cao đặc biệt với các query phức tạp. Giải pháp cần tập trung vào maintenance tasks như VACUUM để rebuild stats nhanh chóng.

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

• AWS RDS Documentation: Amazon RDS for PostgreSQL Snapshots and Restore (cập nhật 2025).
• PostgreSQL Docs 16+: VACUUM Command (DISABLE_PAGE_SKIPPING option từ PG 13+, khuyến nghị cho snapshot restores).
• AWS Best Practices: RDS Performance Insights & Parameter Groups (2026 updates nhấn mạnh proactive vacuuming post-restore).

✅ Đáp án đúng

Login to the database by using the PostgreSQL administration tool. Issue the VACUUM (ANALYZE, DISABLE_PAGE_SKIPPING) command.

Lý do lựa chọn (chi tiết):

• 🛠️ Command VACUUM ANALYZE sẽ scan toàn bộ table, cleanup dead tuples, và cập nhật statistics cho query planner → Giảm read latency ngay lập tức bằng cách giúp optimizer chọn execution plan tốt hơn.
• DISABLE_PAGE_SKIPPING: Bắt buộc vacuum tất cả pages (không skip các page "sạch"), rất cần thiết sau restore snapshot vì snapshot capture state có thể có dead space phân bố không đều → Đảm bảo thorough cleanup.
• Operational efficiency cao nhất ✅: Chỉ cần login (qua psql hoặc pgAdmin), chạy 1 command duy nhất, không reboot, không config changes, hoàn thành nhanh (tùy size DB), và là best practice native của PostgreSQL trên RDS. Không ảnh hưởng production.

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

• Log in to the database by using the PostgreSQL administration tool. Issue a SELECT * command against each table in the database.
  ❌ Sai vì: Command SELECT * chỉ query toàn bộ dữ liệu từng table, gây tăng tải CPU/IO nặng hơn, làm latency tệ hơn thay vì fix root cause (outdated stats/dead tuples). Đây là hành động không hiệu quả, tốn tài nguyên vô ích, không phải maintenance task.

• Create a new parameter group and set the max_connections parameter to 100. Assign the parameter group to the new database. Apply the changes immediately.
  ❌ Sai vì: max_connections kiểm soát số kết nối đồng thời (default RDS PostgreSQL thường 100-5000 tùy instance size), không liên quan đến read latency. Thay đổi này chỉ ảnh hưởng connections overload, không fix stats/vacuum. Tạo parameter group mới + apply immediately vẫn yêu cầu dynamic parameter apply (nhưng max_connections thường cần reboot), kém efficiency so với vacuum trực tiếp.

• Edit the default parameter group for the matching PostgreSQL engine. Set the max_connections parameter to 100. Reboot the new database to pick up the changes to the parameter group.
  ❌ Sai vì:

  • Không nên edit default parameter group (AWS khuyến cáo tạo custom group để tránh ảnh hưởng global).
  • max_connections lại không fix read latency (như trên).
  • Reboot DB gây downtime tạm thời (5-10 phút), kém operational efficiency nhất → Không đáp ứng "MOST operational efficiency".

Giải pháp đúng là tối ưu nhất theo AWS best practices 2026! 🚀 Nếu áp dụng, theo dõi qua RDS Performance Insights để verify latency giảm.

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

Câu hỏi tập trung vào việc xây dựng một recommendation engine (hệ thống gợi ý) trên AWS cho công ty nghiên cứu pháp lý. Hệ thống cần kết nối các bộ dữ liệu từ hàng triệu tài liệu văn bản không cấu trúc (unstructured text documents) thu thập từ các nguồn bên thứ ba. Mục tiêu là tự động xác định các mối liên hệ (connections) giữa các tài liệu, giúp luật sư xây dựng lập luận pháp lý mà không cần so sánh thủ công.

Yêu cầu chính: Giải pháp phải có mức độ vận hành thấp nhất (LEAST operational overhead), nghĩa là ưu tiên các dịch vụ managed/serverless, dễ mở rộng, không cần quản lý hạ tầng thủ công. Đây là bài toán điển hình về graph analytics vì cần tìm kiếm mối quan hệ phức tạp giữa các tài liệu (như vertices và edges trong đồ thị).

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

Đáp án đúng: Build a graph-based recommendation engine by using Amazon Neptune. Search the documents for vertices with relationships among the different sources to connect.

Lý do chọn:

• 🛠️ Amazon Neptune là dịch vụ graph database managed của AWS, chuyên xử lý dữ liệu đồ thị (graph data) với các truy vấn nhanh chóng về mối quan hệ (relationships) giữa các nút (vertices). Hoàn hảo cho recommendation engine vì có thể mô hình hóa tài liệu làm vertices và liên kết làm edges, tự động phát hiện connections mà không cần code phức tạp.
• 📈 Least operational overhead: Neptune là fully managed, hỗ trợ serverless (Neptune Serverless từ 2023), auto-scaling, backup tự động, tích hợp Gremlin/SPARQL queries – giảm thiểu quản lý cluster, patching, scaling thủ công.
• 🔄 Phù hợp với dữ liệu unstructured: Kết hợp với các tool như Amazon Comprehend hoặc OpenSearch để extract entities/relations trước khi ingest vào Neptune.
• Cập nhật 2026: Neptune hỗ trợ Neptune Analytics (graph ML engine) cho recommendation nhanh hơn, tích hợp IAM Auth, VPC endpoints.

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

• ✅ Build a graph-based recommendation engine by using Amazon Neptune. Search the documents for vertices with relationships among the different sources to connect.
  Đúng vì: Như đã giải thích ở trên, Neptune được thiết kế chuyên biệt cho graph-based recommendation, xử lý hàng triệu vertices/edges hiệu quả với truy vấn sub-second. Giảm overhead nhờ managed service, không cần tự build graph engine từ scratch. Lý tưởng cho việc "identify connections" tự động.

• ❌ Create an AWS Lambda application in which the documents are uploaded into Amazon S3. Populate Amazon DynamoDB tables with the metadata of the documents for users to search.
  Sai vì: DynamoDB là NoSQL key-value/document store, không hỗ trợ graph queries hiệu quả cho relationships phức tạp giữa tài liệu. Lambda + S3 chỉ xử lý upload/metadata cơ bản, nhưng users vẫn phải manual search hoặc code phức tạp để tìm connections – tăng operational overhead (quản lý Lambda functions, indexing metadata). Không phù hợp unstructured text analysis sâu.

• ❌ Develop a serverless document scanner by using Amazon Textract to analyze the text from the various sources. Store the detected text in an Amazon Aurora database for analysis.
  Sai vì: Textract giỏi extract text/tables từ documents (OCR), nhưng Aurora (SQL relational DB) không mạnh về graph relationships – truy vấn connections sẽ chậm với JOINs phức tạp trên hàng triệu records. Overhead cao do cần develop custom scanner và optimize Aurora queries/indexes thủ công, không phải giải pháp end-to-end cho recommendation engine.

• ❌ Define the data sources in an Amazon S3 data lake. Analyze the documents by using AWS Glue. Query the documents for relationships by using Amazon Athena.
  Sai vì: S3 + Glue (ETL) + Athena (query engine) phù hợp data lake analytics, nhưng Athena chỉ query SQL trên structured/semi-structured data, kém hiệu quả cho graph relationships (cần custom SQL phức tạp, chậm với unstructured text). Overhead lớn do Glue jobs thủ công, partitioning, không có graph-native support – không "least overhead" cho recommendation.

📘 Tài liệu tham khảo

• AWS Neptune Documentation: Neptune for Recommendation Engines (cập nhật Neptune Serverless & Analytics 2025).
• AWS Well-Architected Framework - ML Lens: Recommendation systems với graph DB (Least overhead pillar).
• AWS Blog: "Building Graph-Powered Recommendation Engines with Amazon Neptune" (2024).
• Exam Guide DOP-C02 (DevOps Pro 2026): Nhấn mạnh managed graph services cho complex relationships.

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

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

Câu hỏi tập trung vào việc di chuyển (migrate) một bảng dữ liệu từ cụm Aurora PostgreSQL DB cluster cũ sang một cụm database cluster mới hoàn toàn riêng biệt. Yêu cầu chính bao gồm:

• Ongoing replication: Bảng mới phải được cập nhật liên tục với mọi thay đổi (insert, update, delete) trên bảng gốc trong suốt quá trình di chuyển.
• Bảng gốc có cột chứa LOB (Large Objects - binary lớn) với kích thước tối đa 2 GB, nhưng hầu hết dữ liệu LOB nhỏ hơn 32 KB, chỉ một vài bản ghi có kích thước lớn.
• Mục tiêu: Cách NHANH NHẤT (FASTEST) để replicate toàn bộ dữ liệu từ bảng gốc.

Thách thức chính: Xử lý LOB lớn một cách hiệu suất cao với CDC (Change Data Capture - ongoing replication), vì Aurora PostgreSQL hỗ trợ DMS cho migrate table-level. Cần chọn mode LOB phù hợp trong AWS DMS để tối ưu tốc độ, tránh truncate dữ liệu lớn và hỗ trợ CDC đầy đủ. (Kiến thức cập nhật AWS DMS phiên bản 2024-2026: Hỗ trợ PostgreSQL 15+, Aurora 15.x với LOB modes tối ưu hơn).

✅ Đáp án đúng

Use AWS Database Migration Service (AWS DMS) with ongoing replication in inline LOB mode.

Lý do lựa chọn:

• Đây là cách NHANH NHẤT để replicate dữ liệu bảng với ongoing replication (CDC) trên Aurora PostgreSQL.
• Inline LOB mode nhúng trực tiếp LOB nhỏ (≤ 32 KB - mặc định InlineLobMaxSize) vào dòng dữ liệu (row), không cần bảng LOB riêng → tối ưu hiệu suất cao, đặc biệt khi hầu hết LOB < 32 KB.
• Hỗ trợ full load + CDC hoàn chỉnh, replicate toàn bộ thay đổi realtime.
• Với vài LOB lớn (2 GB), DMS xử lý NULL cho phần vượt quá (nhưng vì ít, tổng thời gian migrate vẫn nhanh nhất). Phù hợp replicate "all data" trong ngữ cảnh hầu hết dữ liệu nhỏ, tránh overhead của full/limited mode.
• DMS hỗ trợ migrate chỉ một bảng (table selection), target là cluster mới.

📋 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 text gốc), đánh dấu ✅/❌ và giải thích bằng tiếng Việt:

• Use AWS Database Migration Service (AWS DMS) with ongoing replication in full LOB mode.
  ❌ Sai. Full LOB mode replicate toàn bộ LOB không giới hạn kích thước (kể cả 2 GB), nhưng CHẬM NHẤT vì CDC yêu cầu extract/extract toàn bộ LOB mỗi khi thay đổi row chứa LOB (dùng bảng LOB phụ riêng). Overhead cao với LOB lớn, không phù hợp "FASTEST". Chỉ dùng khi cần 100% không NULL/truncate.

• Take a snapshot of the database. Create a new DB instance by using the snapshot.
  ❌ Sai. Snapshot Aurora là point-in-time (không ongoing replication), không cập nhật thay đổi sau snapshot. Restore tạo toàn bộ cluster/DB (không chỉ 1 bảng), không linh hoạt cho "new distinct database cluster" và migrate table-specific. Không hỗ trợ CDC realtime.

• Use AWS Database Migration Service (AWS DMS) with ongoing replication in limited LOB mode.
  ❌ Sai. Limited LOB mode (LobMaxSize mặc định 64 KB) replicate LOB đến giới hạn, LOB lớn hơn → NULL, nhưng chậm hơn inline vì vẫn xử lý chunk LOB riêng (dù nhanh hơn full). Không phải FASTEST với hầu hết LOB nhỏ <32 KB, mặc dù có thể config LobMaxSize=2GB nhưng vẫn kém hiệu suất inline.

• Use AWS Database Migration Service (AWS DMS) with ongoing replication in inline LOB mode.
  ✅ Đúng (như đã giải thích ở trên). FASTEST nhờ inline small LOBs trực tiếp vào stream dữ liệu, CDC mượt mà, phù hợp scenario "most LOB <32 KB, few large". DMS task setup: Source Aurora PostgreSQL endpoint + table mapping + target cluster mới.

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

• AWS DMS User Guide - LOB Support 🧩 Chi tiết 3 LOB modes, inline là "best performance".
• AWS DMS - Change Processing LOB Data ✅ Inline hỗ trợ CDC PostgreSQL/Aurora, null large LOBs.
• Aurora PostgreSQL DMS Migration 🛠️ Hỗ trợ table-level + CDC full load.
• DOP-C02 Exam Guide (AWS Certified DevOps Engineer Professional): Nhấn mạnh DMS LOB modes cho migrate performant.

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 🚀 Nếu cần demo task DMS, 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 bảo mật kết nối cho Amazon Aurora PostgreSQL DB cluster trong một dự án với cơ quan chính phủ. Yêu cầu cụ thể:

• Tất cả giao tiếp database phải được mã hóa in transit (sử dụng SSL/TLS).
• Từ chối hoàn toàn các kết nối không sử dụng SSL/TLS (non-SSL/TLS connection requests).

🛠️ Giải pháp cần tìm: Một Database Specialist phải cấu hình tham số phù hợp trong DB cluster parameter group để ép buộc (force) SSL cho tất cả kết nối, đảm bảo tuân thủ quy định bảo mật nghiêm ngặt. Đây là tính năng chuẩn của Aurora PostgreSQL (hỗ trợ từ các phiên bản mới nhất đến 2026, như PostgreSQL 15+ trong Aurora).

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

Đáp án đúng: Set the rds.force_ssl parameter in the DB cluster parameter group to 1.

Lý do:

• Tham số rds.force_ssl là tham số dành riêng cho Aurora PostgreSQL trong DB cluster parameter group.
• Giá trị 1 sẽ ép buộc tất cả kết nối phải sử dụng SSL/TLS, tự động từ chối các kết nối non-SSL (gửi lỗi ngay lập tức).
• Điều này đáp ứng chính xác yêu cầu: mã hóa in transit và reject non-SSL requests.
• Sau khi thay đổi, cần reboot DB cluster để áp dụng (theo best practice AWS).

📋 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 bằng tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích rõ ràng:

• ❌ Set the rds.force_ssl parameter in the DB cluster parameter group to default.
  Sai vì: Giá trị default tương đương 0 (không ép buộc SSL). Kết nối non-SSL vẫn được phép, vi phạm yêu cầu từ chối non-SSL requests. Tham số này mặc định cho phép kết nối không mã hóa.

• ✅ Set the rds.force_ssl parameter in the DB cluster parameter group to 1.
  Đúng vì: Như đã giải thích ở trên, giá trị 1 kích hoạt chế độ force SSL, mã hóa tất cả giao tiếp in transit và reject ngay các kết nối không SSL/TLS. Đây là cách chính thức AWS khuyến nghị cho PostgreSQL.

• ❌ Set the rds.force_ssl parameter in the DB cluster parameter group to 0.
  Sai vì: Giá trị 0 tắt force SSL, cho phép kết nối non-SSL tự do. Điều này hoàn toàn ngược với yêu cầu bảo mật (không mã hóa in transit và không reject non-SSL).

• ❌ Set the SQLNET.SSL_VERSION option in the DB cluster option group to 1.2.
  Sai vì: SQLNET.SSL_VERSION là tham số của Oracle Database (không áp dụng cho PostgreSQL/Aurora PostgreSQL). Option group cũng không hỗ trợ tham số này cho PostgreSQL. Sử dụng sẽ không có hiệu lực và gây lỗi cấu hình.

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

• AWS Documentation - Aurora PostgreSQL SSL Connections: Using SSL/TLS to encrypt a connection to a DB cluster – Xác nhận rds.force_ssl=1 để force và reject non-SSL.
• Parameter Groups for Aurora PostgreSQL: DB cluster parameter group – Chi tiết tham số rds.force_ssl.
• AWS re:Post & Best Practices: Tìm kiếm "force_ssl Aurora PostgreSQL" trên re:Post cho case thực tế (ổn định từ 2023-2026).
• Aurora PostgreSQL Versions: Hỗ trợ đầy đủ ở engine version 13+ (PostgreSQL 15.5+ đến 2026).

🛠️ Lời khuyên thực hành: Sau cấu hình, kiểm tra bằng psql với --sslmode=require và test reject với --sslmode=disable. Sử dụng IAM auth hoặc Secrets Manager để tăng bảo mật!

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

Câu hỏi tập trung vào tình huống một công ty thương mại điện tử đang sử dụng Amazon RDS for Microsoft SQL Server với dữ liệu được mã hóa bằng AWS KMS. Họ muốn chia sẻ snapshot RDS được mã hóa KMS từ môi trường production (tài khoản AWS chính) sang môi trường development (tài khoản AWS riêng biệt) để thực hiện testing với dữ liệu production. Cả hai môi trường đều có snapshot thủ công (manual) và tự động (automated), nhưng snapshot phải được mã hóa.

📌 Yêu cầu chính: Chuyên viên database cần chọn kết hợp 3 bước để chia sẻ snapshot an toàn, tuân thủ quy trình cross-account sharing của AWS RDS và KMS (cập nhật đến 2026: RDS hỗ trợ sharing encrypted snapshots cross-account qua KMS keys với key policies hoặc grants).

🛠️ Thách thức kỹ thuật:

• Snapshot RDS mã hóa KMS không thể copy trực tiếp cross-account mà phải share.
• Automated snapshots không hỗ trợ sharing cross-account (chỉ manual snapshots).
• Để dev account restore snapshot, cần quyền truy cập KMS key của production account (không dùng default key của dev).

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

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

1. Create a manual snapshot. Share the snapshot from the production account to the development account.
2. Share the snapshot that is encrypted by using the production account custom KMS encryption key.
3. Allow the development account to access the production account KMS encryption key.

Lý do chọn (tóm tắt quy trình chuẩn AWS DOP-C02/2026):

• Bước 1: Tạo manual snapshot từ production DB, sau đó share với dev account (ARN snapshot).
• Bước 2: Snapshot phải dùng custom KMS key của production (không phải default).
• Bước 3: Cập nhật KMS key policy ở production account để grant quyền kms:Decrypt, kms:DescribeKey cho dev account (hoặc dùng grants). Dev account sau đó có thể restore snapshot thành DB mới.
  ✅ Quy trình này đảm bảo bảo mật dữ liệu, tuân thủ least privilege, và hỗ trợ SQL Server (khác MySQL/PostgreSQL ở một số hạn chế legacy).

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

• ❌ Create an automated snapshot. Share the snapshot from the production account to the development account.
  Sai vì: Automated snapshots của RDS không hỗ trợ sharing cross-account (AWS docs xác nhận chỉ manual snapshots mới share được). Nếu thử, sẽ lỗi "Snapshot not found" hoặc permission denied. Phải dùng manual snapshot thay thế.

• ✅ Create a manual snapshot. Share the snapshot from the production account to the development account.
  Đúng vì: Đây là bước đầu tiên chuẩn – tạo manual snapshot từ RDS console/CLI (aws rds create-db-snapshot), sau share với dev account ID (aws rds modify-db-snapshot --db-snapshot-identifier ... --shared-with-account-ids <dev-account-id>). Dev account thấy snapshot trong "Shared with me".

• ❌ Share the snapshot that is encrypted by using the development account default KMS encryption key.
  Sai vì: Không thể share snapshot dùng default KMS key của dev account (snapshot được tạo ở production với key production). AWS yêu cầu snapshot giữ nguyên key gốc khi share; dev không thể re-encrypt bằng default key cross-account mà không có quyền.

• ✅ Share the snapshot that is encrypted by using the production account custom KMS encryption key.
  Đúng vì: RDS snapshots mã hóa KMS phải dùng custom key của owner account (production). Default key (aws/rds) không hỗ trợ cross-account sharing đầy đủ; custom key cho phép policy linh hoạt hơn cho dev access.

• ✅ Allow the development account to access the production account KMS encryption key.
  Đúng vì: Bắt buộc phải update KMS key policy ở production: thêm principal là dev account ARN với actions như kms:Decrypt, kms:ReEncrypt*, kms:DescribeKey. CLI ví dụ: aws kms put-key-policy. Không có quyền này, dev không restore được (lỗi "KMS access denied").

• ❌ Allow the production account to access the development account KMS encryption key.
  Sai vì: Quy trình ngược lại – production là owner snapshot/key, dev là receiver. Không cần production access dev's key; việc này vi phạm bảo mật (dev chỉ cần quyền đọc key production để decrypt).

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

• RDS User Guide: Sharing encrypted snapshots – Xác nhận manual + custom KMS key.
• KMS Developer Guide: Sharing KMS keys cross-account – Key policies cho RDS snapshots.
• DOP-C02 Exam Guide: Domain 3.1 – RDS automation & security (manual snapshots cho testing cross-account).
• CLI refs: aws rds copy-db-snapshot (không dùng cho share), aws kms create-grant.

🛠️ Lời khuyên thực tế: Test trong sandbox với 2 accounts liên kết Organizations để tránh phí. Sử dụng CloudTrail audit sharing actions!