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

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

Câu hỏi tập trung vào việc chia sẻ snapshot tự động (automated snapshot) của Amazon RDS được mã hóa bằng custom AWS KMS key từ tài khoản "WeShare" (tài khoản chia sẻ) sang tài khoản "WeReceive" (tài khoản nhận). Đây là tình huống phổ biến trong môi trường multi-account AWS, nơi đội ngũ phát triển ứng dụng cần chia sẻ dữ liệu RDS một cách an toàn và tuân thủ quy định mã hóa.

📌 Các điểm chính cần lưu ý theo tài liệu AWS mới nhất (cập nhật đến 2026):

• Automated snapshots của RDS không thể chia sẻ trực tiếp cross-account. Phải copy thành manual snapshot trước.
• Snapshot được mã hóa bằng custom KMS key chỉ chia sẻ cross-account được nếu chỉnh sửa key policy để cấp quyền cho tài khoản nhận (WeReceive) sử dụng key (quyền như kms:Decrypt, kms:ReEncrypt*, kms:CreateGrant).
• Unencrypted snapshots hoặc dùng default KMS key (aws/rds) không hỗ trợ chia sẻ cross-account.
• Quy trình chuẩn: Copy snapshot → Cập nhật KMS key policy → Share manual snapshot với account đích.

Câu hỏi yêu cầu chọn TWO actions (hai hành động) mà đội ngũ "WeShare" phải thực hiện.

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

Dựa trên quy trình AWS RDS sharing encrypted snapshots cross-account, hai hành động đúng là:

1. Add access from the "WeReceive" account to the custom AWS KMS key policy of the sharing team.
   🛠️ Lý do: Custom KMS key policy phải được cập nhật để cấp quyền cho account "WeReceive" truy cập key (ví dụ: thêm principal là ARN của account nhận và các action cần thiết). Không làm vậy, account nhận không thể restore snapshot được.

2. Make a copy of the DB snapshot, and set the encryption option to enable.
   🛠️ Lý do: Automated snapshot không share trực tiếp, phải copy thành manual snapshot và bật encryption (sử dụng cùng custom KMS key gốc). Điều này đảm bảo snapshot mới vẫn encrypted và có thể share cross-account sau khi update key policy.

📋 Phân tích tất cả các phương án (Giải thích chi tiết từng lựa chọn)

• ✅ Add access from the "WeReceive" account to the custom AWS KMS key policy of the sharing team.
  🛠️ Đúng: Đây là bước bắt buộc cho custom KMS key. Theo AWS, key policy phải explicitly grant quyền cho external account (root hoặc IAM role cụ thể ở WeReceive) để RDS service có thể decrypt/re-encrypt khi restore. Ví dụ policy snippet:

  {
    "Sid": "Allow RDS CrossAccount",
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::WeReceive-account-ID:root"},
    "Action": ["kms:Decrypt", "kms:ReEncrypt*", "kms:CreateGrant"],
    "Resource": "*"
  }
  

• ❌ Make a copy of the DB snapshot, and set the encryption option to disable.
  🛠️ Sai: Tắt encryption tạo unencrypted snapshot, mà AWS không cho phép chia sẻ unencrypted snapshots cross-account (chỉ intra-account). Điều này vi phạm yêu cầu giữ mã hóa dữ liệu.

• ❌ Share the DB snapshot by setting the DB snapshot visibility option to public.
  🛠️ Sai: Public visibility chỉ áp dụng cho unencrypted manual snapshots và không an toàn (ai cũng restore được). Với encrypted custom KMS, public share không hoạt động và không được khuyến nghị (vi phạm best practice security).

• ✅ Make a copy of the DB snapshot, and set the encryption option to enable.
  🛠️ Đúng: Bước đầu tiên để chuyển automated → manual snapshot. "Enable encryption" đảm bảo copy giữ nguyên custom KMS key, sẵn sàng cho bước share sau khi update policy. AWS yêu cầu encrypted để cross-account share.

• ❌ Share the DB snapshot by using the default AWS KMS encryption key.
  🛠️ Sai: Default KMS key (aws/rds) không hỗ trợ cross-account sharing. Chỉ custom KMS key mới linh hoạt qua key policy. Copy sang default key cũng không giải quyết được vấn đề automated snapshot.

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

• RDS User Guide - Sharing Snapshots: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html (Chi tiết automated → manual và cross-account limits).
• Encrypted Snapshots Cross-Account: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ShareSnapshot.html#USER_ShareSnapshot.encrypted (KMS key policy ví dụ).
• KMS Developer Guide: https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html (Cấp quyền cross-account).

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

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

Câu hỏi này thuộc chủ đề tối ưu hóa hiệu suất (performance optimization) của Amazon Redshift – một dịch vụ data warehouse columnar storage trên AWS. Công ty đang sử dụng Redshift cluster để xử lý ba loại workload chính:

• Real-time inserts qua Amazon Kinesis Data Firehose (dữ liệu streaming thời gian thực).
• Bulk inserts qua lệnh COPY từ Amazon S3 (dữ liệu lớn tải hàng loạt).
• Analytics qua các truy vấn SQL (phân tích dữ liệu).

Gần đây, cluster gặp vấn đề hiệu suất (performance issues), có thể do tải streaming gây lock table, file S3 không parallel tốt, hoặc query SQL chưa tối ưu. Nhiệm vụ là chọn 3 hành động kết hợp để cải thiện performance.

🛠️ Lưu ý quan trọng từ best practices AWS Redshift (cập nhật đến 2024-2026): Redshift sử dụng distribution keys, sort keys, slices (compute units trên nodes), và khuyến nghị temporary tables cho streaming để tránh ảnh hưởng workload khác. Không dùng multi-threading trực tiếp trong COPY, mà parallel qua file splitting.

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

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

• Stream real-time data into Redshift temporary tables before loading the data into permanent tables.
• For bulk inserts, split input files on Amazon S3 into multiple files to match the number of slices on Amazon Redshift. Then use the COPY command to load data into Amazon Redshift.
• Optimize analytics SQL queries to use sort keys.

Lý do lựa chọn:
Những hành động này trực tiếp giải quyết từng workload:

• Temporary tables giúp streaming inserts nhanh, tránh lock permanent tables (🛡️ bảo vệ analytics).
• Splitting files match slices để parallel COPY tối đa hóa throughput (tăng tốc bulk load 10x+).
• Sort keys giúp zone maps và compression query nhanh hơn, giảm scan data không cần thiết (phù hợp analytics).
  Kết hợp chúng cải thiện tổng thể mà không thay đổi architecture lớn.

📋 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 nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên tài liệu AWS mới nhất:

• ❌ Modify the Kinesis Data Firehose delivery stream to stream the data to Amazon S3 with a high buffer size and to load the data into Amazon Redshift by using the COPY command.
  Sai vì: Tăng buffer size làm delay dữ liệu real-time (không còn "real-time"), và chuyển sang COPY từ S3 chỉ phù hợp bulk, không giải quyết vấn đề streaming trực tiếp gây performance bottleneck. Firehose đã hỗ trợ direct to Redshift, nhưng buffer cao làm tích tụ data, tăng latency thay vì cải thiện.

• ✅ Stream real-time data into Redshift temporary tables before loading the data into permanent tables.
  Đúng vì: Redshift khuyến nghị dùng temporary tables (STV_ tables hoặc CREATE TEMP TABLE) cho streaming inserts từ Firehose/Kinesis để tránh table locks ảnh hưởng bulk/analytics. Sau đó, dùng INSERT INTO permanent tables theo batch (ví dụ: mỗi 5-10 phút). Giảm contention, tăng throughput lên đến 3x.

• ✅ For bulk inserts, split input files on Amazon S3 into multiple files to match the number of slices on Amazon Redshift. Then use the COPY command to load data into Amazon Redshift.
  Đúng vì: Redshift phân phối workload qua slices (số slices = nodes x slice count/node). Splitting files (1 file/slice, max 4-8 files/node) kích hoạt parallel COPY tự động, tăng tốc load 5-10x so file lớn đơn lẻ (single-threaded bottleneck).

• ❌ For bulk inserts, use the parallel parameter in the COPY command to enable multi-threading.
  Sai vì: Không tồn tại parameter "parallel" trong lệnh COPY của Redshift. Parallelism tự động dựa trên file splitting và distribution key, không cần flag này (dựa trên docs COPY syntax 2024). Sử dụng sẽ lỗi syntax.

• ✅ Optimize analytics SQL queries to use sort keys.
  Đúng vì: Sort keys (compound/interleaved) sắp xếp data columnar, kích hoạt zone maps để skip blocks không cần, giảm I/O và CPU cho query (analytics workload chính). Kết hợp VACUUM/ANALYZE sau load để duy trì hiệu suất.

• ❌ Avoid using temporary tables in analytics SQL queries.
  Sai vì: Ngược lại, temporary tables rất tốt cho analytics phức tạp (CTAS - CREATE TABLE AS SELECT), tránh ảnh hưởng production tables và hỗ trợ materialized views. Tránh temp tables chỉ làm chậm query staging data.

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

• Redshift Best Practices: Loading Data & Performance – Nhấn splitting files & sort keys.
• Kinesis Firehose to Redshift: Streaming Ingestion – Khuyến nghị temp tables.
• DOP-C02 Exam Guide: Domain 4.1 (Automation of Data Management) – Câu tương tự về Redshift optimization.
• Workload Management (WLM): Sử dụng cho concurrency nếu cần scale thêm (ra-dc2.2xlarge+).

🛠️ Khuyến nghị bổ sung: Giám sát qua Redshift Console > Queries & Loads, enable Concise Query và Short Query Acceleration (SQA) cho analytics nhanh hơn!

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

Câu hỏi mô tả một công ty dịch vụ quản lý thông tin đang lưu trữ các tài liệu JSON trên cơ sở hạ tầng tại chỗ (on-premises) bằng cơ sở dữ liệu MongoDB 3.6. Họ muốn di chuyển (migrate) toàn bộ dữ liệu sang AWS, với các yêu cầu chính sau:

• Tương thích (compatible): Giải pháp phải hỗ trợ MongoDB 3.6 và tài liệu JSON.
• Có khả năng mở rộng (scalable): Hệ thống phải dễ dàng scale theo nhu cầu.
• Fully managed: AWS quản lý hoàn toàn, không cần tự quản lý server.
• Ít thời gian ngừng hoạt động nhất (as little downtime as possible): Ưu tiên migration online hoặc near-zero downtime để tránh gián đoạn kinh doanh.

🛠️ Mục tiêu chính: Tìm giải pháp migration tối ưu sử dụng dịch vụ AWS, tận dụng tính tương thích MongoDB và giảm thiểu downtime.

✅ Đáp án đúng

Đáp án đúng là phương án đầu tiên:
Create an AWS Database Migration Service (AWS DMS) replication instance, a source endpoint for MongoDB, and a target endpoint of Amazon DocumentDB (with MongoDB compatibility).

Lý do lựa chọn:
Giải pháp này đáp ứng toàn bộ yêu cầu một cách hoàn hảo. AWS DMS (Database Migration Service) hỗ trợ migration ongoing replication (sao chép thay đổi liên tục) từ MongoDB on-premises (source endpoint) sang Amazon DocumentDB (target endpoint), giúp minimal downtime nhờ tính năng Change Data Capture (CDC). DocumentDB là dịch vụ fully managed, scalable của AWS, tương thích hoàn toàn với MongoDB 3.6 qua wire protocol (API tương thích), hỗ trợ JSON documents native. DMS replication instance xử lý toàn bộ quá trình tự động, an toàn.

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

Dưới đây là phân tích tất cả 4 phương á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 chi tiết bằng tiếng Việt dựa trên kiến thức AWS mới nhất (tính đến 2026, DMS và DocumentDB vẫn hỗ trợ MongoDB 3.6/4.0+).

• Create an AWS Database Migration Service (AWS DMS) replication instance, a source endpoint for MongoDB, and a target endpoint of Amazon DocumentDB (with MongoDB compatibility).
  ✅ Đúng hoàn toàn. AWS DMS chính thức hỗ trợ MongoDB làm source (từ version 3.6) và DocumentDB làm target, với full-load + CDC để migration online, downtime gần zero. DocumentDB là fully managed (auto-scaling storage/compute), tương thích MongoDB API/JSON. Đây là best practice cho migration MongoDB sang AWS (xem DMS schema conversion nếu cần).

• Create an AWS Database Migration Service (AWS DMS) replication instance, a source endpoint for MongoDB, and a target endpoint of a MongoDB image that is hosted on Amazon EC2.
  ❌ Sai. Mặc dù DMS hỗ trợ MongoDB source, nhưng target là MongoDB trên EC2 không fully managed (phải tự cài đặt, patch, scale, backup thủ công). Không đáp ứng yêu cầu "fully managed" và scalable tự động. EC2 chỉ là IaaS, tăng chi phí vận hành và downtime cao hơn do thiếu auto-healing.

• Use the mongodump and mongorestore tools to migrate the data from the source MongoDB deployment to Amazon DocumentDB (with MongoDB compatibility).
  ❌ Sai. mongodump/mongorestore chỉ hỗ trợ offline migration (export/import toàn bộ data), gây downtime lớn (phải dừng ứng dụng source). Không đáp ứng "as little downtime as possible". DocumentDB tương thích tốt, nhưng thiếu CDC realtime. AWS khuyến nghị DMS cho migration low-downtime thay vì tools thủ công này.

• Use the mongodump and mongorestore tools to migrate the data from the source MongoDB deployment to a MongoDB image that is hosted on Amazon EC2.
  ❌ Sai toàn diện. Tương tự phương án trước, downtime cao do offline. Target MongoDB trên EC2 không fully managed, không scalable tự động, phải tự quản lý cluster/replica sets. Không phù hợp với yêu cầu AWS-native managed service.

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

• AWS DMS User Guide: Using MongoDB as a source for AWS DMS và Using Amazon DocumentDB as a target – Xác nhận hỗ trợ MongoDB 3.6+ với CDC.
• Amazon DocumentDB Documentation: Migrate from self-managed MongoDB – Khuyến nghị DMS cho minimal downtime.
• AWS Well-Architected Framework - Database Lens: Nhấn mạnh DocumentDB cho workloads MongoDB-compatible, fully managed.
• AWS Re:Invent 2025 Sessions (cập nhật): DMS enhancements for NoSQL migrations với zero-ETL options.

🛠️ Lời khuyên DevOps: Trong thực tế, test DMS full-load + CDC trước production, sử dụng DMS Fleet Advisor để assess schema. Scale DocumentDB clusters dễ dàng qua Console/CLI!

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

📖 Nội dung câu hỏi:
Câu hỏi xoay quanh hành vi của Amazon RDS for MySQL DB instances khi bị stop (dừng). Một công ty lưu trữ dữ liệu quan trọng trong các DB instance RDS MySQL. Bộ phận liên quan đóng cửa trong 3 tuần, và chuyên viên database được yêu cầu không cho phép bất kỳ ai truy cập vào các DB instance này. Chuyên viên đã stop tất cả DB instances nhưng không chọn tùy chọn tạo snapshot. Kết quả bất ngờ: Trước khi 3 tuần kết thúc, người dùng vẫn kết nối thành công vào database.

Câu hỏi yêu cầu xác định lý do tại sao DB instances vẫn có thể truy cập được dù đã stop. Đây là tình huống kiểm tra kiến thức về hành vi tự động của RDS khi stop instance, đặc biệt với engine MySQL (hỗ trợ stop/start từ RDS phiên bản mới nhất). AWS RDS cho phép stop DB instance để tiết kiệm chi phí (không tính phí compute nhưng vẫn tính storage), nhưng có cơ chế tự động restart để tránh tình trạng "quên" instance stopped quá lâu.

✅ Đáp án đúng:
Stopped DB instances will automatically restart if the instance is not manually started after 7 days.

Lý do chọn đáp án này (dựa trên tài liệu AWS mới nhất 2024-2026):
🛠️ Khi stop một RDS DB instance (áp dụng cho single-AZ instances hỗ trợ engine như MySQL), instance sẽ chuyển sang trạng thái stopped và không chấp nhận kết nối. Tuy nhiên, AWS có cơ chế bảo vệ: Nếu instance không được start thủ công trong vòng 7 ngày, nó sẽ tự động restart về trạng thái available. Trong trường hợp này, bộ phận đóng cửa 3 tuần (>7 ngày), nhưng chuyên viên phát hiện vấn đề trước 3 tuần hết hạn – rất có thể sau đúng 7 ngày, instance đã tự restart, cho phép người dùng kết nối lại. Không tạo snapshot không ảnh hưởng đến việc restart (snapshot chỉ là tùy chọn backup). Đây là hành vi chuẩn của RDS để đảm bảo tính khả dụng.

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

• AWS RDS User Guide: Stopping and starting a DB instance (xác nhận: "If you don't manually restart the DB instance within seven days, the DB instance is restarted automatically.").
• AWS Well-Architected Framework: RDS Best Practices (2024 edition).

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

• When stopping the DB instance, the option to create a snapshot should have been selected.
  ❌ Sai. Tạo snapshot khi stop là tùy chọn bổ sung để backup dữ liệu trước khi dừng (snapshot được lưu trữ và có thể restore sau). Tuy nhiên, không bắt buộc và không ảnh hưởng đến việc restart tự động. Việc không tạo snapshot chỉ có nghĩa là không có backup mới, nhưng instance vẫn stop bình thường và có thể tự restart sau 7 ngày – đây không phải lý do người dùng vẫn kết nối được.

• When stopping the DB instance, the duration for stopping the DB instance should have been selected.
  ❌ Sai. RDS không có tùy chọn "duration for stopping" (thời gian dừng). Khi stop, instance dừng vô thời hạn cho đến khi start thủ công hoặc tự động sau 7 ngày. Không có tham số nào cho phép đặt thời gian dừng cụ thể (như 3 tuần). Đây là hiểu lầm về tính năng RDS; chỉ có cơ chế tự động 7 ngày cố định.

• Stopped DB instances will automatically restart if the number of attempted connections exceeds the threshold set.
  ❌ Sai. RDS stopped instance hoàn toàn từ chối kết nối (trạng thái stopped không lắng nghe port). Không có cơ chế tự restart dựa trên số lượng kết nối thử hoặc bất kỳ threshold nào. Restart chỉ xảy ra tự động sau đúng 7 ngày không start thủ công, không liên quan đến connection attempts. Đây là sai lệch với CloudWatch alarms hoặc Auto Scaling (không áp dụng cho stopped state).

• Stopped DB instances will automatically restart if the instance is not manually started after 7 days.
  ✅ Đúng (như đã giải thích ở trên). Đây là hành vi mặc định của AWS RDS để tránh tình trạng instance "bị quên" stopped quá lâu, đảm bảo tính khả dụng dữ liệu. Trong kịch bản, sau 7 ngày (trước 3 tuần), instance tự available lại → người dùng kết nối được.

💡 Lưu ý thực hành DevOps: Để tránh restart tự động, nên start thủ công định kỳ mỗi 6 ngày hoặc sử dụng Automation scripts qua Lambda + EventBridge theo dõi stopped >6 ngày. Multi-AZ instances không hỗ trợ stop/start (chỉ failover). Kiểm tra bằng AWS CLI: aws rds describe-db-instances --db-instance-identifier <id>.

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

Câu hỏi mô tả một công ty đang sử dụng Microsoft SQL Server on-premises để lưu trữ dữ liệu relational (dữ liệu quan hệ theo bảng) và JSON (dữ liệu bán cấu trúc), đồng thời chạy ETL hàng ngày (Extract, Transform, Load) và advanced analytics (phân tích nâng cao như BI, ML trên dữ liệu lớn). Công ty muốn migrate sang AWS Cloud, và chuyên gia database phải chọn một hoặc nhiều dịch vụ AWS để chạy workload này một cách MOST operationally efficient (hiệu quả vận hành cao nhất, nghĩa là giảm thiểu số lượng dịch vụ, dễ quản lý, chi phí thấp, tích hợp tốt cho ETL/analytics).

Yêu cầu chính: Giải pháp phải hỗ trợ cả relational & JSON data, ETL, analytics trên quy mô lớn, và ưu tiên hiệu quả vận hành (ví dụ: dùng ít service nhất, tự động scale, managed service).

📘 Kiến thức AWS cập nhật 2026: Amazon Redshift là data warehouse columnar storage, hỗ trợ SQL chuẩn (bao gồm relational), JSON functions đầy đủ (như JSON_PARSE, JSON_EXTRACT_PATH_TEXT), tích hợp ETL với AWS Glue/Spectrum, advanced analytics với Redshift ML/RA3 nodes, và query trực tiếp trên S3. Đây là lựa chọn tối ưu cho workload analytics/ETL từ SQL Server (hỗ trợ DMS migration).

✅ Đáp án đúng: Use Amazon Redshift for relational data and JSON data.

Lý do lựa chọn 🛠️:

• Redshift hỗ trợ đầy đủ cả hai loại dữ liệu: Relational data qua columnar storage (tối ưu query analytics nhanh gấp hàng trăm lần OLTP), JSON data qua built-in functions (query/extract nested JSON dễ dàng mà không cần transform riêng).
• Phù hợp ETL & advanced analytics: Tích hợp AWS Glue cho ETL serverless, Redshift Spectrum query dữ liệu ngoài (S3), Redshift ML cho analytics/ML zero-code.
• MOST operationally efficient: Chỉ dùng MOT service duy nhất (managed, auto-scale với Concurrency Scaling/RA3), giảm complexity so với multi-service (tiết kiệm 30-50% ops effort theo AWS case studies). Migrate từ SQL Server dễ dàng qua AWS DMS/SCT.
• Cập nhật 2026: Redshift hỗ trợ JSON vector embeddings cho AI analytics, zero-ETL integration với Aurora/S3.

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

• AWS Redshift JSON Support
• Redshift for Analytics Workloads
• Migration Guide SQL Server to Redshift

📋 Giải thích tất cả các phương án (giữ nguyên text gốc)

Dưới đây là phân tích từng lựa chọn, đánh dấu ✅ đúng hoặc ❌ sai dựa trên yêu cầu hiệu quả vận hành cao nhất:

• ❌ Use Amazon Redshift for relational data. Use Amazon DynamoDB for JSON data
  Phân tích sai: Redshift tốt cho relational/analytics, nhưng DynamoDB là NoSQL key-value (tối ưu OLTP/high-throughput, KHÔNG hỗ trợ complex analytics/ETL trên JSON như JOIN/AGGREGATE). Phải dùng 2 services riêng biệt → tăng ops complexity (sync data, query federated), không efficient. DynamoDB thiếu SQL analytics engine.

• ✅ Use Amazon Redshift for relational data and JSON data.
  Phân tích đúng: Như đã giải thích ở trên – một service duy nhất xử lý tất cả, columnar + JSON native → tối ưu query speed (petabyte-scale), ETL zero-downtime, analytics built-in. Hoàn hảo migrate từ SQL Server.

• ❌ Use Amazon RDS for relational data. Use Amazon Neptune for JSON data
  Phân tích sai: RDS (OLTP relational) không scale cho analytics lớn (row-based chậm query scan), Neptune là graph database (tối ưu property graph/Gremlin, KHÔNG dành cho JSON general/ETL/analytics). 2 services → kém efficient, RDS thiếu columnar/JSON analytics depth, Neptune overkill & không hỗ trợ SQL ETL.

• ❌ Use Amazon Redshift for relational data. Use Amazon S3 for JSON data.
  Phân tích sai: Redshift tốt cho relational, nhưng S3 chỉ là object storage (không phải database, query JSON thủ công qua Athena/Glue kém hiệu quả, thiếu ACID/transaction). Phải federate query (Spectrum) → latency cao, ops phức tạp (partitioning/maintenance), không "database-like" cho workload hàng ngày.

Kết luận 🎯: Lựa chọn ✅ là operationally efficient nhất vì đơn giản hóa architecture, giảm TCO, và khớp hoàn hảo workload ETL/analytics từ SQL Server! Nếu cần migrate thực tế, dùng AWS DMS + Glue.

🧩 Phân tí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 ứng dụng dựa trên MySQL từ môi trường on-premises sang AWS. Ứng dụng này thực hiện các phép nối bảng (database joins) trên nhiều bảng và sử dụng chỉ mục (indexes) để tăng tốc độ phản hồi truy vấn. Yêu cầu chính là cơ sở dữ liệu phải có tính sẵn sàng cao (highly available - HA) với chuyển đổi dự phòng tự động (automatic failover), đồng thời chọn giải pháp có chi phí vận hành thấp nhất (LEAST operational overhead).

🛠️ Các yếu tố then chốt cần xem xét:

• MySQL tương thích: Phải hỗ trợ MySQL (không phải NoSQL).
• Joins và indexes: Cần RDBMS truyền thống như RDS, không phải DynamoDB (NoSQL).
• HA + Auto failover: Tự động chuyển sang standby khi primary fail.
• Least overhead: AWS managed service, tránh tự quản lý nhiều instance thủ công.

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

Đáp án đúng: Deploy an Amazon RDS Multi-AZ DB instance.

Lý do chi tiết:

• Amazon RDS Multi-AZ cho MySQL tự động tạo standby instance ở Availability Zone (AZ) khác, đồng bộ dữ liệu synchronous, và chuyển failover tự động trong vòng 60-120 giây nếu primary fail (ví dụ: hardware crash, AZ outage).
• Hỗ trợ đầy đủ MySQL features: Joins, indexes, stored procedures – phù hợp migrate từ on-prem.
• Least operational overhead 🛠️: AWS tự quản lý failover, backup, patching; không cần config thủ công DNS hay multiple instances.
• Theo AWS cập nhật 2024-2026: RDS Multi-AZ DB instance deployments v2 (default từ 2023) cải thiện RTO <60s, hỗ trợ MySQL 8.0+ với zero-ETL integration nếu cần.

📋 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 một cách chi tiết, đánh dấu ✅ đúng hoặc ❌ sai, giữ nguyên nội dung phương án gốc bằng tiếng Anh. Mỗi phân tích dựa trên tính phù hợp với yêu cầu (MySQL, joins/indexes, HA auto failover, least overhead).

• Deploy an Amazon RDS DB instance with a read replica.
  ❌ Sai vì: Read replica chỉ dùng cho read scaling (asynchronous replication), không hỗ trợ automatic failover cho writes. Nếu primary fail, phải manually promote replica (overhead cao). Không đáp ứng HA tự động, và joins/indexes vẫn ok nhưng không HA đầy đủ.

• Deploy an Amazon RDS Multi-AZ DB instance.
  ✅ Đúng vì: Như giải thích trên, full HA với synchronous replication + auto failover, managed hoàn toàn bởi AWS. Ít overhead nhất cho MySQL workload với joins/indexes.

• Deploy Amazon DynamoDB global tables.
  ❌ Sai vì: DynamoDB là NoSQL key-value/document store, không hỗ trợ SQL joins hoặc indexes truyền thống (dùng GSI/LSI thay thế, không tương đương). Migrate MySQL cần schema redesign lớn. Global tables chỉ multi-region replication, không phải HA AZ-level auto failover cho relational data.

• Deploy multiple Amazon RDS DB instances. Use Amazon Route 53 DNS with failover health checks configured.
  ❌ Sai vì: Overhead cao: Phải tự deploy/manage nhiều RDS instances, setup replication thủ công, config Route 53 health checks + failover routing (manual intervention thường cần). Không automatic failover native như Multi-AZ; dễ lỗi config, tốn công vận hành.

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

• RDS Multi-AZ Deployment: AWS RDS Multi-AZ Documentation – Chi tiết failover <60s với Deployment v2.
• RDS vs Read Replicas: High Availability for Amazon RDS.
• DynamoDB Limitations: DynamoDB vs RDS Comparison.
• Exam Prep DOP-C02: AWS Certified DevOps Engineer Professional – Topic: Database Migration & HA (Blueprints 2024).

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

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

Câu hỏi tập trung vào vấn đề hiệu suất của Amazon DynamoDB khi các bảng lưu trữ dữ liệu profile người dùng và hoạt động người dùng phát triển lớn nhanh chóng (size tables grow significantly), dẫn đến bottlenecks hiệu suất khi developers đọc/ghi dữ liệu.
📌 Mục tiêu chính: Đề xuất giải pháp đọc items NHANH NHẤT (FASTEST) mà KHÔNG TIÊU THỤ TOÀN BỘ throughput đã provisioned (không dùng hết Read Capacity Units - RCU của bảng).
🛠️ Bối cảnh DynamoDB:

• DynamoDB là NoSQL database với provisioned throughput (RCU/WCU cố định) hoặc on-demand.
• Các API đọc dữ liệu khác nhau về tốc độ và tiêu thụ RCU: GetItem (nhanh cho 1 item), Query (nhanh cho nhiều items cùng partition key), Scan (chậm nhất, quét toàn bảng), BatchGetItem (hiệu quả cho nhiều items riêng lẻ).
• Scan tiêu thụ RCU cao vì quét toàn bộ dữ liệu (charged theo GB scanned), ngay cả với filter (filter chỉ áp dụng sau scan, không giảm RCU). Để nhanh và tiết kiệm, ưu tiên API cụ thể, tránh Scan toàn bộ.
• Cập nhật 2026: DynamoDB vẫn giữ nguyên các API cốt lõi (không thay đổi lớn từ 2023-2026), khuyến nghị dùng Global Secondary Indexes (GSI) hoặc DynamoDB Streams cho query phức tạp, nhưng câu hỏi tập trung vào API cơ bản.

✅ Đáp án đúng: Lựa chọn thứ 2 (B)

Use the Scan API operation with a filter expression that allows multiple items to be read. Use the Query API operation to read multiple items that have a specific partition key and sort key. Use the GetItem API operation to read a single item.

Lý do chọn (chi tiết):
🟢 Đây là bộ API chuẩn nhất theo best practices AWS để đọc nhanh nhất cho từng pattern mà không ép buộc consume toàn bộ RCU:

• Scan + filter: Dùng khi cần đọc nhiều items từ toàn bảng (không phải tất cả), filter giúp trả về chỉ items khớp (giảm dữ liệu output, tránh bottleneck network/time dù RCU vẫn dựa trên scanned data). Không quét "all items" nên tránh consume hết throughput.
• Query: Siêu nhanh cho nhiều items cùng partition key (PK) + sort key (SK), chỉ consume RCU theo dữ liệu trả về (rất efficient).
• GetItem: Nhanh nhất tuyệt đối cho 1 item theo primary key đầy đủ, chỉ 1 RCU.
  Kết hợp này giải quyết bottlenecks mà developers thường gặp khi đọc dữ liệu lớn, phù hợp provisioned mode (tránh Scan không filter hoặc parallel full-scan consume hết RCU).

📋 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 một cách chi tiết, 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 tốc độ, tiêu thụ RCU và best practices AWS (2026).

• ❌ Phương án 1 (A) - SAI
  Use the Scan API operation in parallel with many workers to read all the items. Use the Query API operation to read multiple items that have a specific partition key and sort key. Use the GetItem API operation to read a single item.
  Giải thích sai: Phần Scan parallel với many workers để read ALL items là KHÔNG phù hợp vì parallel scan (chia segments) chỉ tăng tốc full table scan nhưng consume gần như TOÀN BỘ RCU (phân bổ throughput nhưng vẫn quét hết dữ liệu). Vi phạm yêu cầu "without consuming all provisioned throughput". Query và GetItem đúng nhưng phần Scan làm sai toàn bộ.

• ✅ Phương án 2 (B) - ĐÚNG (như đã giải thích ở trên)
  Use the Scan API operation with a filter expression that allows multiple items to be read. Use the Query API operation to read multiple items that have a specific partition key and sort key. Use the GetItem API operation to read a single item.
  Giải thích đúng: Bộ 3 API tối ưu tốc độ + tiết kiệm RCU: Filter trên Scan target chỉ items cần (multiple, không all), Query efficient cho partition cụ thể, GetItem fastest cho single. Hoàn hảo cho social media data (profiles/activities thường theo PK user).

• ❌ Phương án 3 (C) - SAI
  Use the Scan API operation with a filter expression that allows multiple items to be read. Use the Query API operation to read a single item that has a specific primary key. Use the BatchGetItem API operation to read multiple items.
  Giải thích sai: Phần Query để read single item với specific primary key là KHÔNG CHÍNH XÁC. Query yêu cầu partition key condition (không phải full primary key = PK+SK); dùng Query cho single item chậm hơn GetItem (Query có overhead). BatchGetItem tốt cho multiple arbitrary keys (nhanh, max 100 items), nhưng lỗi Query làm sai. Scan + filter đúng nhưng không cứu vãn.

• ❌ Phương án 4 (D) - SAI
  Use the Scan API operation in parallel with many workers to read all the items. Use the Query API operation to read a single item that has a specific primary key Use the BatchGetItem API operation to read multiple items.
  Giải thích sai: Tương tự A, Scan parallel read ALL items consume hết RCU. Query single primary key sai (như C). BatchGetItem đúng (nhanh cho multiple keys, efficient RCU ~1 RCU/item), nhưng 2 lỗi lớn làm phương án kém.

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

• DynamoDB Developer Guide - Read Operations: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/GettingStartedDynamoDB.html (GetItem/Query/Scan/BatchGetItem).
• Best Practices for Scans: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-optimize-scan.html (Khuyến nghị filter expression và tránh full scan).
• Capacity Management: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html (Provisioned RCU chi tiết).
• Exam Context (DOP-C01 / DBS-C01): AWS Certified DevOps Engineer Professional - Domain 3: Automation & Optimization.

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ụ code, hỏi nhé!

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

Câu hỏi xoay quanh một API tìm kiếm thuốc của công ty dược phẩm đang sử dụng Amazon Neptune DB cluster (cơ sở dữ liệu đồ thị hỗ trợ RDF và Property Graph). Quy trình bulk uploader (tải dữ liệu hàng loạt) tự động cập nhật thông tin vào cơ sở dữ liệu vài lần mỗi tuần. Vài tuần trước, trong một lần bulk upload, chuyên viên cơ sở dữ liệu nhận thấy lỗi ThrottlingException xuất hiện thường xuyên. Lỗi này tiếp tục xảy ra ở các lần upload sau.

Nguyên nhân chính: ThrottlingException ở Neptune thường do vượt quá write throughput quota (WTQ) hoặc read throughput quota (RTQ) trên instance primary (ví dụ: do bulk write operations quá nặng). Neptune scale theo instance size (db.r5/r6g large/4xlarge/8xlarge/16xlarge/24xlarge/32xlarge), và WTQ tăng theo kích thước instance lớn hơn.

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

• Ngăn chặn ThrottlingException (tăng capacity write cho bulk upload).
• Giảm thiểu downtime của cluster (không muốn gián đoạn lâu).

📘 Kiến thức cập nhật AWS Neptune (phiên bản 2026): Neptune hỗ trợ read replicas (từ 2021, multi-AZ), failover tự động (RTO ~60 giây), và instance sizing quyết định throughput (WTQ lên đến hàng triệu writes/giây với instance lớn). Không hỗ trợ autoscaling trực tiếp cho writes, phải dùng replica/failover/resize.

🛠️ Nguồn tham khảo:

• AWS Neptune User Guide - Managing Capacity
• Neptune Read Replicas
• Neptune Limits (WTQ scale theo instance class).

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

Đáp án đúng: Create a read replica that uses a larger instance size than the primary DB instance. Fail over the primary DB instance to the read replica.

Lý do:

• Tạo read replica với instance lớn hơn (ví dụ: primary db.r6g.large → replica db.r6g.8xlarge) sẽ có WTQ/RTQ cao hơn đáng kể, phù hợp xử lý bulk writes.
• Failover primary sang replica: Replica lớn promote thành primary mới (Neptune cluster hỗ trợ zero-data-loss failover trong multi-AZ), app tự động redirect qua endpoint cluster. Downtime tối thiểu (~60 giây RTO, không restore dữ liệu).
• Giải quyết gốc rễ throttling (tăng write capacity) mà không offload reads (vấn đề là writes), và minimize downtime so với resize/restore.

🔍 Phân tích tất cả các phương án (Đúng/Sai)

• Create a read replica that uses a larger instance size than the primary DB instance. Fail over the primary DB instance to the read replica.
  ✅ Đúng. Như giải thích trên: Tăng capacity write qua replica lớn, failover nhanh chóng minimize downtime. Đây là best practice AWS cho Neptune scale writes (không autoscaling trực tiếp).

• Add a read replica to each Availability Zone. Use an instance for the read replica that is the same size as the primary DB instance. Keep the traffic between the API and the database within the Availability Zone.
  ❌ Sai. Thêm replica cùng size chỉ tăng high availability và offload reads (intra-AZ latency thấp), nhưng không tăng WTQ trên primary (vẫn throttle khi bulk write). Không giải quyết vấn đề gốc.

• Create a read replica that uses a larger instance size than the primary DB instance. Offload the reads from the primary DB instance.
  ❌ Sai. Replica lớn chỉ offload reads hiệu quả hơn, nhưng bulk upload là writes nặng vẫn trên primary nhỏ → vẫn throttle. Không failover nên primary không scale up.

• Take the latest backup, and restore it in a DB cluster of a larger size. Point the application to the newly created DB cluster.
  ❌ Sai. Restore backup tạo cluster mới lớn hơn sẽ tăng capacity, nhưng downtime cao (thời gian restore + cutover DNS/app endpoint, có thể hàng giờ/phút). Mất tính liên tục, không minimize downtime như yêu cầu.

🛠️ Khuyến nghị thực tế: Sau failover, resize primary cũ (nếu cần) làm replica. Sử dụng Neptune IAM auth và Parameter Groups để optimize bulk loader (Loader tool với S3). Test với CloudWatch metrics (WriteThroughput, ThrottleCount).

🧩 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 việc chọn giải pháp cơ sở dữ liệu trên AWS cho một ứng dụng toàn cầu triển khai qua nhiều Region. Các yêu cầu chính bao gồm:

• Low latency (độ trễ thấp) ở mỗi Region → Nghĩa là đọc/ghi dữ liệu phải nhanh chóng từ vị trí gần người dùng nhất.
• Automatic disaster recovery (phục hồi thảm họa tự động) → Hỗ trợ sao lưu và đồng bộ dữ liệu liên tục để tránh mất mát.
• Active-active configuration (cấu hình hoạt động song song hai chiều) với automatic data synchronization (đồng bộ dữ liệu tự động giữa các Region) → Mỗi Region đều có thể đọc VÀ ghi dữ liệu độc lập, đồng bộ hai chiều tự động mà không có điểm nghẽn đơn lẻ (single point of failure).

Mục tiêu chính: Giải pháp phải đáp ứng TẤT CẢ yêu cầu trên với LOWEST latency (độ trễ thấp nhất). Đây là chủ đề nâng cao trong AWS về multi-Region database replication, thường xuất hiện trong kỳ thi AWS Certified DevOps Engineer Professional (DOP-C02 hoặc phiên bản mới nhất 2024-2026), nhấn mạnh vào DynamoDB cho NoSQL workloads toàn cầu.

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

• AWS Documentation: DynamoDB Global Tables (cập nhật 2024-2026).
• Aurora Global Database.
• RDS Cross-Region Read Replicas.
• AWS Well-Architected Framework: Reliability Pillar (multi-Region active-active).

✅ Đáp án đúng: Amazon DynamoDB global tables

Lý do lựa chọn 🛠️:

• DynamoDB Global Tables là giải pháp true active-active multi-master (mỗi Region đều đọc/ghi độc lập), với đồng bộ dữ liệu hai chiều tự động sử dụng DynamoDB Streams và multi-Region replication (last-writer-wins conflict resolution).
• Low latency thấp nhất: Ghi/đọc cục bộ ở mỗi Region (single-digit ms), không cần cross-Region traffic cho writes. Hỗ trợ automatic failover và disaster recovery với RTO <1 phút.
• Phù hợp hoàn hảo cho ứng dụng toàn cầu, NoSQL, scalable. Đây là lựa chọn tối ưu nhất theo best practices AWS 2026 cho global apps (ví dụ: Netflix, Duolingo sử dụng).

📋 Phân tích tất cả các phương án (giữ nguyên nội dung gốc)

• ❌ Amazon RDS with cross-Region read replicas
  Giải thích sai: RDS Cross-Region read replicas chỉ hỗ trợ read-only ở replica Regions (writes chỉ ở primary Region). Không phải active-active thực sự (không ghi được ở replica), đồng bộ async có thể gây latency cao (giây đến phút). Không đáp ứng "active-active with writes in each Region". Phù hợp hơn cho read-heavy workloads, không phải low-latency global writes.

• ✅ Amazon DynamoDB global tables
  Giải thích đúng: Như đã phân tích ở trên. Đây là giải pháp duy nhất cung cấp multi-Region writes với latency thấp nhất (~ms), active-active đầy đủ, auto-sync, và built-in DR. Scaling tự động theo DAX/Streams cho performance cao nhất 2026.

• ❌ Amazon Aurora global database
  Giải thích sai: Aurora Global DB là one-primary multi-secondary (primary Region xử lý writes, secondaries chỉ reads). Đồng bộ async (RPO ~1 phút), latency cross-Region cao hơn DynamoDB cho writes (không active-active thực thụ). Tốt cho relational DB với reads global, nhưng không lowest latency cho writes everywhere như yêu cầu.

• ❌ Amazon Athena and Amazon S3 with S3 Cross Region Replication
  Giải thích sai: Athena là serverless query engine cho dữ liệu S3 (không phải transactional database). S3 CRR chỉ replicate objects (không real-time sync), không hỗ trợ active-active reads/writes, không có low-latency queries (Athena scan S3 chậm ~giây/phút). Hoàn toàn không phải database solution, chỉ cho analytics/batch, vi phạm mọi yêu cầu.

🧠 Kết luận: DynamoDB Global Tables là lựa chọn chuẩn AWS cho global active-active với lowest latency. Trong thực tế DevOps, kết hợp với AWS Global Accelerator hoặc CloudFront để tối ưu thêm! 🚀

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

Câu hỏi xoay quanh một công ty dược phẩm sử dụng Amazon Quantum Ledger Database (Amazon QLDB) để lưu trữ dữ liệu thử nghiệm lâm sàng. Ứng dụng chạy trên AWS Lambda nằm trong private subnet của VPC, không có quyền truy cập internet. Ứng dụng cần đọc (read-only) một số bản ghi dữ liệu từ QLDB, nhưng công ty lo ngại traffic giữa QLDB ledger và VPC có thể rời khỏi mạng AWS (public internet).

Yêu cầu chính 📋:

• Bảo mật truy cập vào QLDB ledger.
• Cho phép traffic từ VPC chỉ read-only.
• Đảm bảo traffic không rời AWS network (private connectivity).

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

• QLDB là dịch vụ managed ledger database (không phải relational DB như RDS), hỗ trợ immutable ledger cho dữ liệu không thể thay đổi.
• Lambda trong private subnet → Không dùng public endpoint của QLDB (yêu cầu internet).
• Cần giải pháp private, secure với kiểm soát granular (read-only).

Kiến thức cập nhật AWS (2026) ⚡: QLDB hỗ trợ AWS PrivateLink (Interface VPC Endpoint) từ năm 2020, cho phép kết nối private từ VPC đến QLDB mà không qua internet. Không hỗ trợ deploy QLDB trực tiếp vào VPC subnets.

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

Đáp án đúng: Create an AWS PrivateLink VPC endpoint for the QLDB ledger. Attach a VPC policy to the VPC endpoint to allow read-only traffic for the Lambda functions that run inside the VPC.

Lý do chọn 🏆:

• AWS PrivateLink tạo Interface VPC Endpoint cho QLDB, giữ traffic hoàn toàn trong AWS network (private IP từ VPC endpoint).
• VPC Endpoint Policy (IAM policy gắn vào endpoint) cho phép granular control như chỉ SELECT (read-only) actions trên QLDB ledger.
• Lambda trong VPC tự động route traffic qua endpoint → Không cần NAT Gateway hay internet.
• Hoàn hảo match yêu cầu: Secure, read-only, zero exposure ngoài AWS.
• Hiệu suất cao, scalable, không cần quản lý proxy/VPN.

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

• Phương án A: Move the QLDB ledger into a private database subnet inside the VPC. Run the Lambda functions inside the same VPC in an application private subnet. Ensure that the VPC route table allows read-only flow from the application subnet to the database subnet.
  ❌ Sai vì QLDB là fully managed service (region-level), KHÔNG THỂ di chuyển vào VPC subnet như RDS. Không có "database subnet" cho QLDB. Route table chỉ control intra-VPC, không áp dụng cho managed service ngoài VPC.

• Phương án B: Create an AWS PrivateLink VPC endpoint for the QLDB ledger. Attach a VPC policy to the VPC endpoint to allow read-only traffic for the Lambda functions that run inside the VPC.
  ✅ Đúng như giải thích ở trên. Sử dụng **com.amazonaws..qldbservice name** cho endpoint. Policy ví dụ: Allowqldb:SendCommandvớiSELECT` only. Traffic private 100%, zero egress.

• Phương án C: Add a security group to the QLDB ledger to allow access from the private subnets inside the VPC where the Lambda functions that access the QLDB ledger are running.
  ❌ Sai vì QLDB KHÔNG hỗ trợ Security Groups (không phải EC2/RDS). QLDB dùng IAM policies và PrivateLink cho access control, không attach SG vào ledger.

• Phương án D: Create a VPN connection to ensure pairing of the private subnet where the Lambda functions are running with the private subnet where the QLDB ledger is deployed.
  ❌ Sai vì QLDB KHÔNG deploy vào private subnet (managed service). VPN dùng cho on-prem connectivity, không cần thiết và phức tạp hóa (traffic vẫn có thể public nếu không config đúng). Không match private AWS-to-AWS.

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

• QLDB VPC Endpoints: AWS QLDB Developer Guide - VPC Endpoints 🛠️ (Hướng dẫn tạo PrivateLink cho QLDB).
• PrivateLink cho QLDB: AWS PrivateLink Documentation - QLDB 📖.
• QLDB IAM Permissions: QLDB Permissions Reference (Cho read-only policy).
• Lambda in VPC: Lambda VPC Docs (Tích hợp endpoint).

Giải pháp này best practice cho enterprise security! 🚀 Nếu cần code mẫu hoặc diagram, hỏi thêm nhé!