Ngân hàng đề — AWS Certified Developer Associate

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

📘 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi xoay quanh việc quản lý phiên bản (S3 Versioning) trong Amazon S3 bucket. 🛡️ Công ty lưu trữ dữ liệu trong S3 bucket, dữ liệu được cập nhật nhiều lần mỗi ngày từ ứng dụng chạy trên server on-premises (trung tâm dữ liệu nội bộ). Họ đã kích hoạt S3 Versioning, dẫn đến tình trạng có nhiều phiên bản của cùng một object tích tụ theo thời gian.

Yêu cầu cụ thể: Bucket chỉ cần giữ phiên bản hiện tại (current version) của mỗi object và phiên bản ngay trước đó (immediately previous version, tức là 1 noncurrent version mới nhất). Mục tiêu là giảm số lượng phiên bản thừa để tối ưu chi phí lưu trữ và quản lý, mà không làm mất dữ liệu quan trọng gần nhất.

🛠️ Đây là tình huống phổ biến trong DevOps khi xử lý dữ liệu động (dynamic data) với versioning enabled, cần áp dụng S3 Lifecycle policies để tự động hóa việc expire (xóa) các phiên bản cũ không cần thiết. Kiến thức dựa trên AWS S3 docs phiên bản mới nhất 2024-2026, nơi Lifecycle rules hỗ trợ tinh chỉnh noncurrent versions một cách linh hoạt.

✅ Đáp án đúng:
Configure an S3 Lifecycle rule to retain one newer noncurrent version of the objects.

Lý do lựa chọn (chi tiết):
S3 Lifecycle rule là công cụ chính thức và tối ưu nhất của AWS để quản lý vòng đời object versions. 🏆 Bạn có thể cấu hình rule với NoncurrentVersionExpiration (xóa noncurrent versions sau X ngày) kết hợp transition/expiration rules để chỉ giữ lại 1 noncurrent version mới nhất (newer noncurrent version). Ví dụ: Set "Delete noncurrent versions after 1 day" – vì dữ liệu update nhiều lần/ngày, rule sẽ tự động xóa các noncurrent cũ hơn, giữ đúng current + 1 previous. Điều này tự động, không cần code, scale tốt và tuân thủ best practices AWS. Không ảnh hưởng đến versioning hiện tại.

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

• ❌ [SAI] Configure an S3 bucket policy to retain one newer noncurrent version of the objects.
  Bucket policy chỉ kiểm soát quyền truy cập (access control) như IAM permissions, deny/allow actions (ví dụ: PreventDelete), không quản lý lifecycle hay xóa versions tự động. ❌ Không thể "retain" cụ thể 1 noncurrent version qua policy – sẽ gây lỗi hoặc không hiệu quả. Bucket policy dành cho security, không phải versioning management.

• ✅ [ĐÚNG] Configure an S3 Lifecycle rule to retain one newer noncurrent version of the objects.
  Như đã giải thích ở trên: Hoàn hảo match yêu cầu. 🛠️ Lifecycle rule hỗ trợ NoncurrentVersionExpiration rule để expire noncurrent versions sau thời gian nhất định (ví dụ: 1 ngày), đảm bảo chỉ giữ current + 1 newer noncurrent. Áp dụng ngay trên bucket với versioning enabled. Hiệu suất cao, chi phí thấp.

• ❌ [SAI] Enable S3 Object Lock. Configure an S3 Object Lock policy to retain one newer noncurrent version of the objects.
  S3 Object Lock là tính năng immutability (không thể sửa/xóa) cho compliance (WORM - Write Once Read Many), áp dụng ở object level với retention periods cố định (Governance/Compliance mode). ❌ Không liên quan đến versioning management; nó khóa tất cả versions thay vì expire cụ thể 1 noncurrent. Object Lock policy không hỗ trợ "retain one newer noncurrent" – sẽ làm phức tạp hóa và không giải quyết vấn đề.

• ❌ [SAI] Suspend S3 Versioning. Modify the application code to check the number of object versions before updating the objects.
  Suspend versioning sẽ dừng tạo new versions, overwrite object cũ và mất vĩnh viễn các versions hiện có (không recover được). ❌ Phải sửa code app on-premises để "check versions" trước update là non-scalable, error-prone, không tự động, vi phạm nguyên tắc AWS Well-Architected (favor managed services). Không meet yêu cầu giữ "current + previous version".

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

• S3 Versioning & Lifecycle Management: docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html và Lifecycle Configuration – Chi tiết NoncurrentVersionExpiration.
• S3 Object Lock: docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html – So sánh với versioning.
• AWS DOP-C02 Exam Guide (DevOps Professional): Nhấn mạnh Lifecycle cho cost-optimized versioning.

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

🧩 Giải thích nội dung câu hỏi
Câu hỏi mô tả một công ty đang phát triển tính năng mới cho phần mềm hiện tại. Họ muốn kiểm tra tính năng này với một nhóm người dùng nhỏ trước khi phát hành toàn bộ phiên bản mới, trong khi phiên bản phần mềm hiện tại vẫn được triển khai và chạy bình thường. Nếu kiểm tra thành công (dựa trên phản hồi), công ty cần triển khai phiên bản mới cho tất cả người dùng còn lại cùng một lúc.
Yêu cầu chính là:

• Test dần dần với nhóm nhỏ (không ảnh hưởng toàn bộ).
• Rollout toàn bộ nếu OK (không dần dần).
  Chiến lược triển khai phù hợp phải hỗ trợ canary testing (test với subset users) kết hợp khả năng deploy all-at-once sau khi xác nhận. Điều này thường áp dụng trong AWS services như Amazon ECS, EKS, CodeDeploy, Lambda với các deployment strategies.

✅ Đáp án đúng: Canary deployment
Lý do lựa chọn:
Canary deployment là chiến lược lý tưởng vì nó cho phép triển khai tính năng mới chỉ đến một nhóm nhỏ người dùng (ví dụ: 5-10% traffic) trong khi phiên bản cũ vẫn chạy cho đa số. Công ty có thể thu thập phản hồi (metrics như error rate, latency) từ nhóm test. Nếu thành công, dễ dàng scale up để deploy toàn bộ traffic cùng lúc (không dần dần). AWS hỗ trợ Canary qua AWS CodeDeploy (với traffic shifting), Amazon ECS/ECS Blue/Green, AWS App Runner, hoặc Lambda Provisioned Concurrency. Điều này khớp hoàn hảo với yêu cầu "gather feedback from small group" và "deploy to all other users at the same time".
(Cập nhật đến 2026: AWS tiếp tục khuyến nghị Canary cho microservices và serverless, với tích hợp Amazon SageMaker cho ML-based canary analysis).

🛠️ Phân tích tất cả các phương án
Dưới đây là giải thích chi tiết từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh, và đánh giá đúng/sai dựa trên yêu cầu câu hỏi:

• ❌ All-at-once deployment
  Phương án này triển khai toàn bộ phiên bản mới cùng lúc cho tất cả người dùng, không hỗ trợ test với nhóm nhỏ trước (không có giai đoạn "small group of users"). Nếu có lỗi, toàn hệ thống bị ảnh hưởng ngay, vi phạm yêu cầu test dần dần trong khi version cũ vẫn chạy. AWS CodeDeploy hỗ trợ kiểu này nhưng không phù hợp ở đây.

• ✅ Canary deployment
  Như đã giải thích ở trên, đây là lựa chọn đúng vì cho phép route traffic nhỏ đến version mới, thu thập feedback, rồi shift 100% traffic nếu OK. Hoàn hảo khớp yêu cầu.

• ❌ In-place deployment
  Đây là kiểu triển khai thay thế trực tiếp trên instances hiện tại (không tạo môi trường mới), thường dùng cho EC2 với CodeDeploy. Không hỗ trợ test với nhóm nhỏ users (traffic-based), dễ gây downtime và không tách biệt version cũ/mới rõ ràng, không đáp ứng "current software version remains deployed".

• ❌ Linear deployment
  Cũng gọi là rolling deployment, triển khai dần dần theo tỷ lệ tuyến tính (ví dụ: 10% mỗi 5 phút đến 100%). Nó hỗ trợ test dần nhưng không tập trung vào nhóm nhỏ cố định để feedback, và rollout là dần dần chứ không "all other users at the same time". AWS CodeDeploy hỗ trợ linear traffic shifting, nhưng không khớp yêu cầu deploy toàn bộ cùng lúc sau test.

📘 Tài liệu tham khảo

• AWS Well-Architected Framework - DevOps Pillar: Deployment Strategies (cập nhật 2024-2026).
• AWS CodeDeploy User Guide: Deployment Types (Canary & Linear).
• AWS Compute Services: ECS Blue/Green & Canary docs: Amazon ECS Deployment.
  (Kiến thức dựa trên AWS re:Invent 2025 updates về AI-driven Canary với Amazon Q).

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

Câu hỏi tập trung vào tình huống cross-account access giữa hai AWS Account:

• Account A: Chạy ứng dụng với một IAM Role cần truy cập secret từ AWS Secrets Manager ở Account B. Role này đã có quyền truy cập secret (qua resource policy của Secrets Manager).
• Account B: Lưu trữ secret được mã hóa bằng AWS KMS key.
• Yêu cầu chính: Thêm statement vào key policy của KMS key ở Account B để cho phép Role ở Account A sử dụng KMS key (cụ thể là để decrypt secret). Phải tuân thủ least privilege (quyền hạn tối thiểu, không cấp thừa).

Quy trình hoạt động: Khi ứng dụng gọi secretsmanager:GetSecretValue, Secrets Manager ở Account B sẽ sử dụng KMS key để decrypt secret. Do đó, KMS key policy phải cho phép principal (Role từ Account A) thực hiện các hành động cần thiết trên key, nếu không sẽ bị từ chối decrypt (lỗi KMSAccessDeniedException).
✅ Đây là kiến thức cốt lõi về KMS cross-account access (cập nhật đến 2026, không thay đổi lớn từ AWS re:Invent 2023-2025).

✅ Đáp án đúng: kms:Decrypt and kms:DescribeKey

Lý do lựa chọn:

• kms:Decrypt: Bắt buộc để Role ở Account A có thể decrypt secret qua Secrets Manager. Secrets Manager gọi KMS decrypt dữ liệu, và key policy phải ủy quyền explicit cho external principal.
• kms:DescribeKey: Cần thiết để Role có thể mô tả key (metadata), hỗ trợ quá trình decrypt mà không cấp quyền thừa (least privilege). Không cần kms:Encrypt hay các quyền khác.
• Điều này đảm bảo least privilege: Chỉ cấp đúng 2 quyền tối thiểu cho decrypt secret cross-account.
  🛠️ Ví dụ statement trong key policy (Account B):

{
  "Sid": "AllowCrossAccountDecrypt",
  "Effect": "Allow",
  "Principal": {"AWS": "arn:aws:iam::AccountA:role/AppRole"},
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "*"
}

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

• kms:Decrypt and kms:DescribeKey
  ✅ Đúng. Đây là bộ quyền least privilege chuẩn cho KMS key policy trong cross-account Secrets Manager. kms:Decrypt cho phép decrypt secret, kms:DescribeKey hỗ trợ metadata lookup. Không cấp quyền thừa như encrypt/generateDataKey.

• secretsmanager:DescribeSecret and secretsmanager:GetSecretValue
  ❌ Sai. Các quyền này thuộc IAM policy hoặc resource policy của Secrets Manager secret (không phải KMS key policy). Role ở Account A đã có quyền này rồi (theo câu hỏi). Thêm vào KMS policy sẽ vô hiệu vì KMS không nhận Secrets Manager actions.

• kms:*
  ❌ Sai. Cấp toàn bộ quyền KMS (gồm encrypt, sign, revoke,...), vi phạm least privilege. Chỉ cần 2 quyền cụ thể là đủ, cấp * bị coi là bad practice (AWS Well-Architected Framework: Security Pillar).

• secretsmanager:*
  ❌ Sai. Không liên quan đến KMS key policy. Secrets Manager actions chỉ áp dụng cho Secrets Manager resources, không dùng trong KMS policy. Sẽ bị KMS từ chối ngay lập tức.

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

• AWS Secrets Manager Documentation: Cross-account access with KMS – Xác nhận kms:Decrypt trong key policy.
• AWS KMS Developer Guide: Allowing users in other accounts to use a KMS key – Chi tiết least privilege cho cross-account.
• AWS re:Post & Well-Architected Labs: DOP-C02 Sample Questions – Tương tự câu DOP-C02 (2024-2026 exam blueprint).
  🧠 Lưu ý: Kiểm tra bằng AWS CLI: aws kms describe-key --key-id <key-arn> và test GetSecretValue để verify!

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

Câu hỏi xoay quanh một lập trình viên đã tạo nhiều hàm AWS Lambda để ghi dữ liệu vào một bucket Amazon S3 duy nhất. Tất cả các hàm Lambda đều được cấu hình gửi logs và metrics đến Amazon CloudWatch. 📊 Vấn đề là một hàm Lambda cụ thể ghi dữ liệu vào S3 rất chậm, và lập trình viên cần đo lường chính xác độ trễ (latency) giữa hàm Lambda đó và bucket S3.

🛠️ Yêu cầu chính: Tìm giải pháp đo latency cụ thể giữa Lambda và S3, không phải tổng thời gian chạy của hàm Lambda hay metrics chung chung. Điều này đòi hỏi công cụ tracing phân tích chi tiết các subsegment (phần con) trong quá trình thực thi, đặc biệt là phần gọi API đến S3 (như PutObject). Kiến thức AWS cập nhật đến 2026: AWS X-Ray là dịch vụ tracing chuẩn cho microservices serverless, hỗ trợ trace map topology để visualize và đo latency từng segment.

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

Đáp án đúng: Enable AWS X-Ray on the Lambda function. In the generated trace map, select the line between Lambda and Amazon S3.

Lý do: AWS X-Ray tạo trace chi tiết cho từng invocation của Lambda, bao gồm subsegments cho các AWS services như S3. Trace map (bản đồ trace) hiển thị topology trực quan dưới dạng graph, với đường nối (line/edge) giữa Lambda và S3. Khi chọn đường nối này, bạn có thể xem latency histogram, p50/p90/p99 latency cụ thể cho S3 calls, giúp xác định chính xác độ trễ mạng/API. Đây là cách trực tiếp nhất để đo latency end-to-end giữa hai services. 🚀 Hoàn hảo cho troubleshooting chậm trễ ở serverless.

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

• ✅ Enable AWS X-Ray on the Lambda function. In the generated trace map, select the line between Lambda and Amazon S3.
  Giải thích đúng: Như trên, trace map của X-Ray cung cấp visualization topology chính xác, cho phép select edge giữa Lambda-S3 để xem latency breakdown (remote calls, retries). Không cần code thêm, chỉ enable X-Ray trên Lambda (qua console/CLI). Hỗ trợ đến 2026 với enhancements như sampled traces và ML anomaly detection. 🗺️

• ❌ Query the Lambda function’s log file in Amazon CloudWatch Logs Insights. Return the average of the auto-discovered @duration field.
  Giải thích sai: @duration trong Logs Insights chỉ đo tổng thời gian thực thi toàn bộ invocation Lambda (bao gồm init, code run, tất cả calls). Không phân tích riêng latency đến S3, chỉ là aggregate metrics. Không phù hợp để isolate vấn đề S3-specific. 📈

• ❌ Enable CloudWatch Lambda Insights on the function. View the latency graph that CloudWatch Lambda Insights provides.
  Giải thích sai: Lambda Insights (enhanced monitoring via CloudWatch Agent) cung cấp metrics như tổng duration, cold starts, memory usage, và graph latency tổng quát. Không có breakdown chi tiết đến S3 (không trace service-to-service). Chỉ metrics cấp hàm, không phải tracing. ⚠️

• ❌ Enable AWS X-Ray on the Lambda function. Select Amazon S3 in the latency graph to view the latency histogram.
  Giải thích sai: X-Ray có latency graph/service map, nhưng không select trực tiếp "Amazon S3" để xem histogram. Thay vào đó, phải dùng trace map hoặc trace details để drill-down edge cụ thể. "Latency graph" chủ yếu aggregate all services, không isolate Lambda-to-S3 chính xác như trace map. Sai ở chi tiết visualization. 🔍

📘 Tài liệu tham khảo

• AWS X-Ray Documentation (2026): AWS X-Ray Trace Maps – Chi tiết về selecting edges trong trace map.
• AWS Lambda Monitoring: Using AWS X-Ray with Lambda – Hướng dẫn enable và trace S3 calls.
• CloudWatch Lambda Insights: Lambda Insights Docs – Xác nhận chỉ metrics tổng, không tracing.
• Best Practices: AWS Well-Architected Framework – Reliability Pillar: Sử dụng X-Ray cho distributed tracing (Well-Architected Tool v6+).

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

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

Câu hỏi tập trung vào việc kích hoạt Amazon CloudWatch Logs Insights cho các hàm AWS Lambda trong một ứng dụng serverless được triển khai bằng AWS Serverless Application Model (SAM) template.

• Bối cảnh: Công ty có một template SAM bao gồm logical resource tên là CloudWatchLogGroup (nhóm log CloudWatch). Nhà phát triển cần chỉnh sửa template này để Logs Insights có thể hoạt động hiệu quả với logs từ các Lambda functions.
• Mục tiêu chính: Logs Insights là công cụ query và phân tích logs mạnh mẽ của CloudWatch. Với Lambda, logs được tự động gửi vào CloudWatch Logs, nhưng để tối ưu hóa (như embedded metrics, traces chi tiết), cần kích hoạt Lambda Insights – một extension đặc biệt giúp thu thập dữ liệu định dạng chuẩn cho Logs Insights query dễ dàng hơn. Điều này yêu cầu thêm layer extension và IAM policy quản lý vào từng Lambda function trong SAM template.
• Phiên bản AWS cập nhật (đến 2026): AWS khuyến nghị sử dụng Lambda Insights (với layer ARN mới nhất theo region, ví dụ: arn:aws:lambda:<region>:580247275435:layer:LambdaInsightsExtension:41) và managed policy CloudWatchLambdaInsightsExecutionRolePolicy để enable đầy đủ tính năng Logs Insights cho Lambda metrics/logs. SAM hỗ trợ qua properties Layers và Policies trong resource AWS::Serverless::Function.

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

• AWS Docs: Using Lambda Insights (cập nhật 2025).
• AWS SAM Docs: Lambda Layers & Policies.
• CloudWatch Logs Insights for Lambda.

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

Đáp án đúng: For each Lambda function, add the layer for the Lambda Insights extension and the CloudWatchLambdaInsightsExecutionRolePolicy AWS managed policy.

Lý do 🛠️:

• Đây là cách chuẩn và trực tiếp nhất để kích hoạt Logs Insights cho Lambda theo best practices AWS.
• Lambda Insights extension layer (ARN cụ thể theo region) thu thập metrics, traces, và logs định dạng embedded metrics – giúp Logs Insights query nhanh chóng và visualize dữ liệu Lambda (như cold starts, duration, errors).
• Managed policy CloudWatchLambdaInsightsExecutionRolePolicy cấp quyền cho Lambda IAM role (PutMetricData, PutLogEvents vào CloudWatch).
• Trong SAM template, thêm vào từng AWS::Serverless::Function: Layers: [!Ref LambdaInsightsLayer] và Policies: [arn:aws:iam::aws:policy/CloudWatchLambdaInsightsExecutionRolePolicy]. Resource CloudWatchLogGroup hiện có sẽ nhận logs tối ưu.

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

• ❌ Phương án SAI: Add an output named CloudWatchinsightRule that contains a value of the Amazon Resource Name (ARN) for the CloudWatchLogGroup resource.
  Giải thích: Outputs trong SAM chỉ dùng để expose thông tin sau deploy (như ARN), không kích hoạt Insights. "CloudWatchinsightRule" không tồn tại (có lẽ nhầm với Contributor Insights rules hoặc metric alarms). Không liên quan đến Lambda Insights hay Logs query.

• ❌ Phương án SAI: Add a parameter named CloudWatchLogGroupNamePrefix that contains a value of the application name. Reference the new parameter in the CloudWatchLogGroup resource.
  Giải thích: Parameter LogGroupNamePrefix (trong SAM CLI) chỉ tự động tạo log groups với prefix tên app, giúp quản lý logs nhưng không enable Insights. Logs vẫn vào CloudWatch Logs cơ bản, thiếu embedded metrics cho query tối ưu.

• ✅ Phương án ĐÚNG: For each Lambda function, add the layer for the Lambda Insights extension and the CloudWatchLambdaInsightsExecutionRolePolicy AWS managed policy.
  Giải thích: Như đã nêu ở phần đáp án đúng. Đây là giải pháp hoàn chỉnh, scale cho nhiều Lambda functions trong SAM. AWS khuyến nghị từ 2023-2026 cho production workloads.

• ❌ Phương án SAI: For each Lambda function, set Tracing mode to Active and add the CloudWatchLambdaInsightsExecutionRolePolicy AWS managed policy.
  Giải thích: "Tracing mode: Active" kích hoạt AWS X-Ray tracing (thu thập traces riêng), không phải Lambda Insights hay Logs Insights. Policy đúng nhưng tracing chỉ bổ sung, không thay thế layer extension cần thiết cho metrics/logs Insights.

🧠 Lưu ý bổ sung: Sau khi modify SAM, chạy sam deploy để apply. Kiểm tra Logs Insights qua console CloudWatch > Logs > Logs Insights, query mẫu: fields @timestamp, @message | filter lambdaInsightsExtension = true. Nếu cần dashboard tự động, dùng CloudWatch dashboards với Lambda Insights metrics!

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

Câu hỏi xoay quanh vấn đề thiết kế khóa chính (primary key) trong Amazon DynamoDB – một dịch vụ cơ sở dữ liệu NoSQL serverless của AWS.

• Bối cảnh: Một lập trình viên đang xây dựng game lưu trữ dữ liệu người chơi vào bảng DynamoDB. Partition key được chọn là quốc gia của người chơi (country).
• Vấn đề: Sau khi số lượng người chơi từ một quốc gia cụ thể tăng đột ngột, hệ thống gặp lỗi ProvisionedThroughputExceededException.
  • Lỗi này xảy ra khi throttling (giới hạn throughput) trên một partition cụ thể bị vượt quá, vì tất cả request từ người chơi cùng quốc gia đổ dồn vào một partition duy nhất (gọi là hot partition). DynamoDB phân phối dữ liệu dựa trên partition key, nên partition key kém (không uniform) dẫn đến imbalance.
• Mục tiêu: Tìm giải pháp remediate (khắc phục) lỗi này một cách hiệu quả, phù hợp với best practices DynamoDB (cập nhật đến 2026: DynamoDB vẫn ưu tiên thiết kế partition key để đảm bảo even distribution).

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

• AWS DynamoDB Developer Guide: Best practices for designing partition keys.
• Managing throughput capacity.

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

Đáp án đúng: Revise the primary key to use more unique identifiers.

Lý do 🛠️:

• Vấn đề cốt lõi là partition key "country" quá coarse (kém phân tán), dẫn đến hot partition khi traffic từ một quốc gia spike.
• Giải pháp: Sửa lại primary key (partition key hoặc composite key với sort key) để sử dụng unique identifiers như player_id, timestamp, hoặc country#player_id (randomized hoặc high-cardinality). Điều này đảm bảo even distribution dữ liệu qua nhiều partition, tránh throttling.
• Theo best practices AWS 2026: Partition key phải có high cardinality (nhiều giá trị unique) để scale horizontally. Có thể dùng DynamoDB composite keys hoặc random suffixes.

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

Dưới đây là phân tích từng lựa chọn giữ nguyên văn bản gốc bằng tiếng Anh, kèm giải thích sai/đúng bằng tiếng Việt:

• Use strongly consistent table reads.
  ❌ Sai. Strongly consistent reads tiêu tốn gấp đôi RCU (Read Capacity Units) so với eventually consistent, làm tăng throttling thay vì giảm. Không giải quyết gốc rễ hot partition, chỉ làm tình hình tệ hơn (theo DynamoDB capacity mode docs).

• Revise the primary key to use more unique identifiers.
  ✅ Đúng. Như đã giải thích ở trên, đây là giải pháp root cause 🛠️: Tái thiết kế key để phân tán traffic đều, hỗ trợ auto-scaling provisioned/on-demand capacity. AWS khuyến nghị migrate data qua DynamoDB Streams + Lambda nếu cần.

• Use pagination to reduce the size of the items that the queries return.
  ❌ Sai. Pagination (LastEvaluatedKey) chỉ giảm item size per query, giúp tránh ItemCollectionSizeLimitExceeded nhưng không giảm RCU/WCU trên partition hot. Traffic spike vẫn throttle partition gốc.

• Use the Scan operation to retrieve the data.
  ❌ Sai. Scan quét toàn bảng, tiêu tốn toàn bộ table RCU (rất inefficient, full table scan), làm tăng throttling nghiêm trọng hơn Query (targeted). AWS khuyên tránh Scan cho production workload lớn.

🏆 Kết luận & Best Practices bổ sung

• Khắc phục ngay: Chuyển sang On-Demand capacity tạm thời (auto-scale), nhưng tái thiết kế key là lâu dài. Test với DynamoDB Partition Calculator trên AWS Console.
• Mẹo DevOps: Sử dụng CloudWatch alarms cho ConsumedReadCapacityUnits và DynamoDB Global Tables nếu multi-region.
• ✅ Áp dụng kiến thức DOP-C02 (DevOps Pro 2026): Tập trung vào design for scalability và partition management.

Nếu cần ví dụ code Terraform/ CDK để revise table, hãy hỏi thêm! 🚀