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

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

Câu hỏi tập trung vào việc bảo mật dữ liệu tại chỗ nghỉ (data at rest) trong Amazon Simple Queue Service (SQS). Công ty sử dụng SQS để tách rời (decouple) kiến trúc microservices, và một số tin nhắn (messages) chứa thông tin nhạy cảm. Yêu cầu là triển khai giải pháp mã hóa tất cả dữ liệu tại chỗ nghỉ trong hàng đợi SQS.

📌 Điểm chính cần lưu ý:

• Data at rest nghĩa là dữ liệu được lưu trữ trên đĩa hoặc trong hệ thống lưu trữ của AWS (không phải dữ liệu đang truyền - in transit).
• SQS hỗ trợ mã hóa server-side encryption (SSE) để tự động mã hóa messages khi lưu trữ, sử dụng các loại key quản lý bởi AWS hoặc khách hàng.
• Giải pháp phải áp dụng cho toàn bộ queue, không chỉ một phần messages, và phải tuân thủ các tính năng bảo mật mới nhất của AWS (cập nhật đến 2026, bao gồm SSE-SQS mặc định với AWS-managed keys).

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

Đáp án đúng: Enable server-side encryption for the SQS queue by using an SQS managed encryption key (SSE-SQS).

Lý do chi tiết 🛠️:

• SSE-SQS là tính năng mã hóa server-side tự động cho toàn bộ messages trong queue, sử dụng AWS-managed encryption key (key được AWS quản lý hoàn toàn).
• Khi kích hoạt, tất cả dữ liệu at rest sẽ được mã hóa ngay lập tức mà không cần thay đổi code gửi/nhận messages.
• Đây là giải pháp đơn giản, chi phí thấp, và phù hợp nhất với yêu cầu "encrypt all the data at rest" vì áp dụng queue-wide.
• Tính năng này đã ổn định từ 2017 và được khuyến nghị trong best practices bảo mật AWS mới nhất (2026), hỗ trợ compliance như PCI DSS, HIPAA.

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

• ✅ Enable server-side encryption for the SQS queue by using an SQS managed encryption key (SSE-SQS).
  Giải thích đúng 🟢: Phương án này kích hoạt mã hóa server-side trực tiếp trên queue bằng key do AWS quản lý (SSE-SQS). Nó mã hóa tất cả messages at rest tự động, không cần can thiệp code, và hỗ trợ đầy đủ các API SendMessage/ReceiveMessage. Hoàn hảo cho yêu cầu queue-wide encryption.

• ❌ Use the aws:SecureTransport condition in the queue policy to ensure that only HTTPS (TLS) is used for all requests to the SQS queue.
  Giải thích sai 🔴: Điều kiện aws:SecureTransport chỉ bắt buộc sử dụng HTTPS/TLS cho dữ liệu in-transit (truyền giữa client và SQS endpoint), không mã hóa data at rest. Nó bảo vệ dữ liệu đang di chuyển nhưng không ảnh hưởng đến lưu trữ trên AWS.

• ❌ Use AWS Certificate Manager (ACM) to generate an SSL/TLS certificate. Reference the certificate when messages are sent to the queue.
  Giải thích sai 🔴: ACM dùng để tạo certificate SSL/TLS cho mã hóa in-transit (như HTTPS endpoints), không áp dụng cho SQS messages at rest. SQS không hỗ trợ reference certificate khi gửi messages; điều này chỉ liên quan đến client-side TLS, không mã hóa lưu trữ.

• ❌ Set a message attribute in the SQS SendMessage request for messages that are sent to the queue. Set the Name to ENCRYPT. Set the Value to TRUE.
  Giải thích sai 🔴: Message attributes chỉ là metadata đi kèm messages (không mã hóa nội dung), và SQS không có attribute tên "ENCRYPT" để kích hoạt mã hóa at rest. Encryption phải cấu hình ở mức queue (SSE), không phải per-message qua attributes.

📘 Tài liệu tham khảo

• AWS SQS Developer Guide - Server-side encryption: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-security-encryption.html (Cập nhật 2026: SSE-SQS là mặc định khuyến nghị).
• AWS Security Best Practices: https://docs.aws.amazon.com/whitepapers/latest/aws-security-best-practices/security-at-the-queue-level.html.
• AWS Well-Architected Framework - Security Pillar (2026 edition).

Hy vọng phân tích này giúp bạn ôn thi DOP-C02 hiệu quả! 🚀

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

Câu hỏi tập trung vào vấn đề hiệu suất trong ứng dụng serverless trên AWS: Một công ty triển khai portal người dùng mới sử dụng Amazon API Gateway làm endpoint chính, tích hợp với AWS Lambda. Người dùng báo cáo portal chậm, và phân tích ban đầu chỉ ra một endpoint API Gateway cụ thể gây ra vấn đề. Lambda function này gọi các API bên ngoài và các dịch vụ AWS khác, dẫn đến thời gian phản hồi (response time) tăng cao.

Mục tiêu: Tìm nguồn gốc chính xác gây chậm bằng operational best practices (các thực hành vận hành tốt nhất). Điều này yêu cầu công cụ theo dõi (tracing) chi tiết để phân tích luồng thực thi end-to-end, đặc biệt trong môi trường serverless nơi Lambda có thể bị ảnh hưởng bởi cold starts, throttles, hoặc độ trễ từ các dịch vụ downstream (như API calls hoặc AWS services).

Ngữ cảnh quan trọng (dựa trên best practices AWS 2025-2026): Trong serverless, AWS X-Ray là công cụ tracing phân tán chuẩn để debug latency, hỗ trợ trace chi tiết qua API Gateway, Lambda, và các dịch vụ khác mà không cần code thủ công nhiều.

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

• AWS X-Ray Developer Guide (2026): https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html
• AWS Well-Architected Framework - Operational Excellence Pillar: https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html
• Lambda Best Practices: https://docs.aws.amazon.com/lambda/latest/dg/best-practices.html

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

Đáp án đúng: Instrument the Lambda function with the AWS X-Ray SDK. Add HTTP and HTTPS interceptors and SDK client handlers. Deploy the updated Lambda function. Turn on X-Ray tracing. After accumulating enough usage data, use the X-Ray service map to examine the average response times to determine the likely sources.

Lý do chọn 🛠️: Đây là operational best practice chuẩn cho tracing serverless apps trên AWS. AWS X-Ray SDK tự động thu thập trace data từ Lambda, API calls (HTTP/HTTPS interceptors), và AWS SDK clients (handlers). Service map trực quan hóa luồng end-to-end, hiển thị average response times cho từng segment (ví dụ: Lambda init, external API calls), giúp pinpoint nguồn chậm chính xác (như dịch vụ downstream chậm). Không cần phân tích thủ công logs/metrics; X-Ray hỗ trợ sampling tự động, tích hợp CloudWatch, và scale đến production traffic (cập nhật 2026: hỗ trợ enhanced tracing cho Lambda Provisioned Concurrency).

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

Dưới đây là phân tích từng phương án một cách chi tiết, giữ nguyên văn bản gốc tiếng Anh. Sử dụng ✅ cho đúng, ❌ cho sai, với giải thích rõ ràng dựa trên best practices AWS mới nhất.

• Phương án 1: Update the Lambda function by adding logging statements with high-precision timestamps before and after each external request. Deploy the updated Lambda function. After accumulating enough usage data, examine the Amazon CloudWatch logs for the Lambda function to determine the likely sources for the increased response time.
  ❌ Sai vì: Phương pháp thủ công thêm logs với timestamps (dù dùng CloudWatch Logs Insights) không phải best practice cho tracing phân tán. Logs chỉ ghi 1D data (khó correlate qua nhiều calls), tốn code maintenance, và khó scale với high traffic. Không trace end-to-end (bỏ qua API Gateway/Lambda init/downstream). AWS khuyến nghị X-Ray thay vì custom logging cho latency issues (Well-Architected 2026).

• Phương án 2: Instrument the Lambda function with the AWS X-Ray SDK. Add HTTP and HTTPS interceptors and SDK client handlers. Deploy the updated Lambda function. Turn on X-Ray tracing. After accumulating enough usage data, use the X-Ray service map to examine the average response times to determine the likely sources.
  ✅ Đúng vì: Best practice hoàn hảo cho serverless tracing. X-Ray SDK (cập nhật 2026: hỗ trợ Node.js/Python/Java/etc.) tự động instrument HTTP/HTTPS và AWS SDK calls. Service map visualize traces, tính p50/p95/p99 latencies per segment, dễ xác định bottleneck (ví dụ: external API chậm 80% thời gian). Tích hợp native với API Gateway/Lambda, bật tracing chỉ bằng config (sampling rules linh hoạt).

• Phương án 3: Review the Lambda function's Amazon CloudWatch metrics by using the metrics explorer. Apply anomaly detection to the Duration metric and the Throttles metric. Review the anomalies to determine the likely sources.
  ❌ Sai vì: CloudWatch Metrics (Duration/Throttles) chỉ cho aggregate data (không drill-down chi tiết vào external calls). Anomaly detection hữu ích detect spikes tổng quát, nhưng không trace nguồn gốc cụ thể (ví dụ: không phân biệt Lambda code vs. downstream API). Không phù hợp operational best practice cho root cause analysis trong distributed systems (X-Ray tốt hơn cho trace-level insights).

• Phương án 4: Use Amazon CloudWatch Synthetics to create a new canary. Turn on AWS X-Ray tracing on the canary. Configure the canary to scan the user portal. After accumulating enough usage data, use the CloudWatch Synthetics canary dashboard to view the metrics from the canary.
  ❌ Sai vì: CloudWatch Synthetics canaries chỉ simulate traffic từ client-side (tốt cho end-to-end monitoring), nhưng không capture internal Lambda behavior hoặc downstream calls từ production traffic. Canary traces chỉ phản ánh synthetic runs, không đại diện real-user data tích lũy. Không pinpoint "single API Gateway endpoint" issues chính xác; phù hợp proactive monitoring chứ không phải debug production latency (best dùng cho alerting, không root cause).

Kết luận 🚀: Sử dụng AWS X-Ray là cách hiệu quả nhất, tuân thủ AWS Well-Architected Framework, giúp debug nhanh mà không ảnh hưởng performance (overhead <1%). Khuyến nghị enable X-Ray từ đầu cho serverless apps!

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

Câu hỏi mô tả một lập trình viên đang xây dựng ứng dụng event-driven sử dụng AWS Lambda và Amazon EventBridge. Cụ thể:

• Lambda function cần push events lên EventBridge event bus bằng cách gọi API PutEvents qua SDK (không chỉ định credentials trong code).
• Sau khi deploy, function thất bại với lỗi AccessDeniedException trong logs.

Vấn đề cốt lõi 📉: Lambda không có quyền truy cập để thực hiện hành động PutEvents trên EventBridge. Lý do là Lambda luôn sử dụng IAM execution role (vai trò thực thi) để xác thực với các dịch vụ AWS khác, thay vì credentials hard-code. Nếu role thiếu policy cho phép events:PutEvents, sẽ bị từ chối quyền (AccessDenied). Đây là tình huống phổ biến khi tích hợp Lambda với EventBridge mà không cấu hình IAM đúng cách.

Mục tiêu: Tìm cách resolve để Lambda có thể push events thành công, dựa trên nguyên tắc least privilege và best practices AWS (cập nhật đến 2026, EventBridge vẫn dùng IAM roles cho cross-service access).

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

Đáp án đúng: Modify the Lambda function execution role to include permissions for the PutEvents EventBridge action.

Lý do chi tiết 🛠️:

• Lambda function không sử dụng credentials trong code mà dựa hoàn toàn vào execution role (IAM role được attach lúc tạo function). Role này cần policy cho phép events:PutEvents trên resource EventBridge bus cụ thể (ví dụ: arn:aws:events:region:account:event-bus-name).
• Giải pháp này đơn giản, an toàn và tuân thủ AWS best practices: Sử dụng IAM roles để grant quyền tạm thời, tránh hard-code secrets.
• Sau khi update role (qua IAM console/CLI/Terraform), Lambda sẽ tự động sử dụng role mới mà không cần redeploy code.
• Xác nhận lỗi: AccessDeniedException chính xác chỉ ra thiếu IAM permission trên execution role.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, đánh dấu ✅/❌ và giải thích hoàn toàn bằng tiếng Việt dựa trên kiến thức AWS mới nhất (2026).

• ❌ Configure a VPC peering connection between the Lambda function and EventBridge.
  Sai vì: EventBridge là fully managed service của AWS, truy cập qua public endpoints (không yêu cầu VPC peering). Lambda có thể gọi EventBridge từ VPC hoặc non-VPC miễn là IAM role đúng. VPC peering chỉ dùng cho private connectivity giữa VPCs riêng biệt, không liên quan đến API calls qua internet/AWS network. Thêm peering sẽ phức tạp hóa và không fix AccessDenied (vẫn thiếu IAM).

• ❌ Modify their AWS credentials to include permissions for the PutEvents EventBridge action.
  Sai vì: "Their AWS credentials" ám chỉ local/user credentials (access key/secret của developer), nhưng Lambda không dùng credentials từ code mà dùng execution role. Hard-code credentials vào code vi phạm security best practices (AWS khuyến cáo chống lại), dễ leak và không scale. Lỗi xảy ra ở runtime Lambda, không phải local dev.

• ✅ Modify the Lambda function execution role to include permissions for the PutEvents EventBridge action.
  Đúng vì: Execution role là cơ chế xác thực chính của Lambda khi gọi AWS services (docs AWS: Lambda assumes role để generate temporary creds). Cần attach managed policy như AmazonEventBridgeFullAccess hoặc custom policy với events:PutEvents. Đây là fix chuẩn và hiệu quả nhất, resolve ngay AccessDenied mà không thay đổi code.

• ❌ Add a resource-based policy to the Lambda function to include permissions for the PutEvents EventBridge action.
  Sai vì: Resource-based policy trên Lambda chỉ dùng để cho phép các principal khác invoke Lambda (lambda:InvokeFunction), không grant quyền cho Lambda gọi service khác như EventBridge. Quyền outbound từ Lambda luôn qua execution role, không phải resource policy. Thêm policy này vô ích và không fix lỗi.

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

• Lambda execution roles: docs.aws.amazon.com/lambda/latest/dg/lambda-intro-execution-role.html – Giải thích role grant permissions.
• EventBridge PutEvents permissions: docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutEvents.html – Yêu cầu IAM action events:PutEvents.
• Troubleshoot Lambda AccessDenied: docs.aws.amazon.com/lambda/latest/dg/troubleshooting-permissions.html – Xác nhận lỗi từ execution role.
• Best practices EventBridge + Lambda: aws.amazon.com/blogs/compute/using-aws-lambda-with-amazon-eventbridge/.

Lời khuyên DevOps 🚀: Luôn dùng AWS IAM Access Analyzer kiểm tra permissions dư thừa, và CloudFormation/CDK để manage roles tự động!

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

Câu hỏi xoay quanh việc giám sát hiệu suất (throughput) của một AWS Lambda function xử lý tin nhắn từ các thiết bị IoT. ✅ Yêu cầu chính là đo lường throughput gần thời gian thực (near real-time) dựa trên số lượng tin nhắn mà Lambda nhận và xử lý thành công trong một khoảng thời gian nhất định. 🛠️ Quan trọng: Không tính thời gian khởi tạo (initialization) và hậu xử lý (post-processing) vào phép đo này, vì chúng không phản ánh đúng hiệu suất xử lý cốt lõi.

Công ty cần một giải pháp để đảm bảo Lambda đạt SLA (Service Level Agreement). Developer phải triển khai cách tính throughput chính xác, loại trừ các bước không liên quan. 📈 Throughput ở đây được hiểu là tốc độ xử lý tin nhắn (messages per time unit), đòi hỏi metrics chi tiết và tùy chỉnh để theo dõi gần real-time qua Amazon CloudWatch.

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

Đáp án đúng: Modify the application to publish custom Amazon CloudWatch metrics when the Lambda function receives and processes each message. Use the metrics to calculate the throughput.

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

• Phương án này tùy chỉnh metrics CloudWatch bằng cách publish metric riêng khi nhận tin nhắn (receive) và xử lý xong (process). Điều này cho phép tính toán throughput chính xác (ví dụ: SUM metric "MessagesProcessed" chia cho thời gian qua CloudWatch Metric Math).
• ✅ Near real-time: Custom metrics được publish ngay lập tức, CloudWatch hỗ trợ dashboard/alarms real-time (1-minute granularity).
• ❌ Loại trừ init/post-processing: Metrics chỉ emit tại điểm nhận/xử lý cốt lõi, không bị ảnh hưởng bởi cold start hay cleanup.
• Đây là best practice theo AWS Well-Architected Framework (Operational Excellence pillar), cập nhật đến 2026 với hỗ trợ PutMetricData API trong Lambda runtime mới nhất (Node.js 20, Python 3.12,...).

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

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

• ❌ [SAI] Use the Lambda function's ConcurrentExecutions metric in Amazon CloudWatch to measure the throughput.
  Giải thích sai: Metric ConcurrentExecutions chỉ đo số lượng execution đồng thời (concurrent invocations), không phản ánh số tin nhắn nhận/xử lý. 🧮 Nó bị ảnh hưởng bởi concurrency limit (mặc định 1000), không tính riêng receive/process, và không loại trừ init/post-processing. Không phù hợp cho throughput near real-time vì chỉ là snapshot, không phải count messages.

• ❌ [SAI] Modify the application to log the calculated throughput to Amazon CloudWatch Logs. Use Amazon EventBridge to invoke a separate Lambda function to process the logs on a schedule.
  Giải thích sai: Cách này phụ thuộc logs và schedule EventBridge (ví dụ: cron job), dẫn đến độ trễ (không near real-time) vì phải parse logs định kỳ. 🕒 Logs Insights tốn kém, phức tạp, và tính toán throughput từ logs không chính xác bằng metrics trực tiếp. AWS khuyến nghị tránh dùng logs cho metrics quantitative (favor custom metrics thay vì).

• ✅ [ĐÚNG] Modify the application to publish custom Amazon CloudWatch metrics when the Lambda function receives and processes each message. Use the metrics to calculate the throughput.
  Giải thích đúng: Như đã phân tích ở trên. 🛠️ Sử dụng putMetricData API (qua AWS SDK) để emit metrics như "MessagesReceived" và "MessagesProcessed". CloudWatch tự động aggregate (SUM/AVG) và hỗ trợ Metric Math (RATE/SUM) cho throughput dashboard. Hỗ trợ embedded metric format từ Lambda năm 2020, cập nhật 2026 với high-resolution metrics (1s).

• ❌ [SAI] Use the Lambda function's Invocations metric and Duration metric to calculate the throughput in Amazon CloudWatch.
  Giải thích sai: Invocations chỉ đếm số lần invoke Lambda, không đảm bảo mỗi invoke xử lý đúng 1 message (có thể batch). Duration bao gồm toàn bộ thời gian chạy, kể cả init/post-processing (cold starts lên đến 10s+). 📉 Tính throughput từ Invocations/Duration không chính xác, không loại trừ các bước thừa, và không near real-time cho message-level.

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

• AWS Lambda Metrics: Amazon CloudWatch Metrics for Lambda – Chi tiết Invocations, Duration, ConcurrentExecutions.
• Custom Metrics: Publishing Custom Metrics from Lambda – Hướng dẫn PutMetricData và Embedded Metric Format.
• CloudWatch Metric Math: Using Metric Math – Tính throughput (RATE, SUM).
• AWS Well-Architected: Lambda Monitoring Best Practices.
• DevOps Pro Exam Guide: DOP-C02 (2023+), phần Monitoring & Logging với Lambda/CloudWatch.

Giải pháp này đảm bảo SLA monitoring hiệu quả, scalable! 🚀 Nếu cần code sample, hãy hỏi thêm.

🧩 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 tích hợp CI/CD cho ứng dụng Java sử dụng AWS CodePipeline. Một lập trình viên cần cập nhật pipeline để hỗ trợ dependency mới dưới dạng file .jar. Yêu cầu chính là pipeline phải tự động kích hoạt build ngay khi phiên bản mới của file .jar được phát hành (publish).

🔍 Chi tiết vấn đề:

• Ứng dụng Java thường sử dụng các dependency như .jar từ repository quản lý artifact (ví dụ: Maven Central, JFrog Artifactory).
• Pipeline hiện tại cần trigger build dựa trên sự kiện khi dependency thay đổi, không phải manual trigger.
• Giải pháp phải tự động, đáng tin cậy, và phù hợp với best practices DevOps trên AWS (tích hợp native services).
• Thách thức: Không chỉ lưu trữ .jar mà còn phát hiện sự thay đổi phiên bản và kích hoạt pipeline một cách liền mạch.

🛠️ Yêu cầu giải pháp: Phải sử dụng dịch vụ AWS hỗ trợ quản lý artifact cho Java/.jar, kết hợp event-driven trigger để start CodePipeline build khi có version mới (dựa trên kiến thức AWS cập nhật đến 2026, với CodeArtifact v2 và EventBridge enhancements).

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

Đáp án đúng: Create an AWS CodeArtifact repository. Publish the dependency .jar file to the repository. Use an Amazon EventBridge rule to start a CodePipeline pipeline build.

Lý do chọn 📈:

• AWS CodeArtifact là dịch vụ quản lý artifact chuyên dụng cho Java/Maven/Gradle (hỗ trợ .jar hoàn hảo), proxy đến public repos như Maven Central, và lưu trữ private packages. Khi publish .jar mới, CodeArtifact tự động tạo event "Package Version Created".
• Amazon EventBridge (trước là CloudWatch Events) có native integration với CodeArtifact: Tạo rule match event này → target là StartPipelineExecution API của CodePipeline → tự động start build.
• Giải pháp serverless, scalable, secure (IAM policies chi tiết), phù hợp CI/CD Java. Đáp ứng yêu cầu trigger chính xác trên version mới mà không cần polling thủ công.
• Theo AWS Well-Architected Framework (DevOps Pillar, 2023+), đây là best practice cho dependency management.

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

Dưới đây là phân tích từng lựa chọn. Giữ nguyên văn bản gốc (tiếng Anh), đánh dấu ✅/❌, và giải thích chi tiết bằng tiếng Việt.

• Create an Amazon S3 bucket to store the dependency .jar file. Publish the dependency .jar file to the S3 bucket. Use an Amazon Simple Notification Service (Amazon SNS) notification to start a CodePipeline pipeline build.
  ❌ Sai vì: S3 chỉ là object storage, không phải repository artifact cho .jar (không hỗ trợ versioning semantic như Maven coordinates: groupId:artifactId:version). SNS có thể trigger từ S3 Event (PUT object), nhưng không detect "new version" tự động (cần custom logic parse filename/object key). Không tích hợp native với CodePipeline cho dependencies Java → phức tạp, không scalable, vi phạm least privilege (S3 public risk).

• Create an Amazon Elastic Container Registry (Amazon ECR) private repository. Publish the dependency .jar file to the repository. Use an ECR source action to start a CodePipeline pipeline build.
  ❌ Sai vì: ECR dành cho Docker container images (.tar.gz layers), không hỗ trợ .jar trực tiếp (upload .jar sẽ fail validation). ECR source action chỉ pull image làm source cho pipeline stage, không trigger build khi "publish .jar" (ECR events chỉ cho image push/pull). Không phù hợp Java deps → gây lỗi runtime và không event-driven đúng yêu cầu.

• Create an Amazon Elastic Container Registry (Amazon ECR) private repository. Publish the dependency .jar file to the repository. Use an Amazon Simple Notification Service (Amazon SNS) notification to start a CodePipeline pipeline build.
  ❌ Sai vì: Tương tự trên, ECR không phải cho .jar (chỉ images), publish .jar sẽ không work. SNS từ ECR Image Scan/Push events không match "new .jar version" (ECR events không hỗ trợ non-image artifacts). Giải pháp lạc hướng, tốn kém (ECR storage/lifecycle), không theo AWS patterns cho Java artifacts.

• Create an AWS CodeArtifact repository. Publish the dependency .jar file to the repository. Use an Amazon EventBridge rule to start a CodePipeline pipeline build.
  ✅ Đúng vì: Như đã giải thích ở trên. CodeArtifact + EventBridge là integration chính thức (AWS docs 2024-2026): Event source codeartifact.amazonaws.com, pattern {"source": ["aws.codeartifact"], "detail-type": ["Package Version State Change"], "detail": {"state": ["Published"]}} → target CodePipeline. Hoàn hảo cho Java CI/CD, hỗ trợ Maven mvn deploy.

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

• AWS CodeArtifact User Guide: CodeArtifact Events với EventBridge (hỗ trợ "PackageVersionCreated" từ 2022+, enhanced 2025).
• CodePipeline Developer Guide: StartPipelineExecution via EventBridge.
• AWS Well-Architected DevOps: Artifact Management (khuyến nghị CodeArtifact cho Java).
• Blog AWS: "Using CodeArtifact with CodePipeline and EventBridge" (2024) - link.

Giải pháp này đảm bảo zero-downtime CI/CD, an toàn (encryption at rest/transit), và chi phí tối ưu (~$0.05/GB/month cho CodeArtifact). Nếu cần implement, dùng CDK/Terraform cho IaC! 🚀

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

Câu hỏi xoay quanh một ứng dụng phân tích và báo cáo của công ty có nhiều chi nhánh (branch locations). Mỗi chi nhánh đẩy báo cáo bán hàng (sales report) vào một Amazon S3 bucket chung tại một thời điểm cố định mỗi ngày. Công ty đã phát triển một AWS Lambda function để phân tích tất cả các báo cáo từ các chi nhánh trong một lần duy nhất (single pass), sau đó lưu kết quả vào cơ sở dữ liệu (database).

Yêu cầu chính: Khởi động quá trình phân tích chỉ một lần mỗi ngày tại thời điểm cụ thể (predefined time), và giải pháp phải tiết kiệm chi phí nhất (MOST cost-effectively).

🛠️ Điểm then chốt:

• Các báo cáo được upload vào S3 theo lịch cố định, nhưng Lambda cần chạy một lần duy nhất để xử lý tất cả (không phải từng báo cáo riêng lẻ).
• Phải đảm bảo lịch trình chính xác và tối ưu chi phí (tránh chạy thừa, polling liên tục hoặc dịch vụ đắt đỏ).
• Kiến thức cập nhật đến 2026: AWS khuyến nghị sử dụng Amazon EventBridge (trước đây là CloudWatch Events) cho các lịch trình cron-like, với chi phí gần như miễn phí cho rule schedule (chỉ tính phí invocation nếu vượt giới hạn cao).

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

• AWS EventBridge Scheduling (cập nhật 2025).
• AWS Lambda Pricing và EventBridge Pricing (EventBridge rule schedule miễn phí đến 14 triệu invocations/tháng).
• AWS Well-Architected Framework - Cost Optimization Pillar.

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

Đáp án đúng: Create an Amazon EventBridge scheduled rule that invokes the Lambda function once each day at the predefined time.

Lý do:

• 🕐 EventBridge hỗ trợ lịch trình cron chính xác (ví dụ: cron(0 9 * * ? *) cho 9h sáng hàng ngày), invoke Lambda chỉ một lần/ngày.
• Lambda chạy single pass phân tích tất cả reports đã upload vào S3 (giả sử chúng sẵn sàng lúc đó).
• Tiết kiệm chi phí nhất (MOST cost-effectively): EventBridge rule schedule miễn phí (không tính phí cho schedule, chỉ invocation Lambda ~0.00001667 USD/1.000 requests), không lãng phí tài nguyên.
• Không phụ thuộc vào thời gian upload cụ thể của từng chi nhánh, phù hợp yêu cầu "once each day".

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

• Configure an S3 event notification to invoke the Lambda function when a branch office uploads a sales report.
  ❌ Sai: S3 event notification sẽ trigger Lambda mỗi khi có upload từ bất kỳ chi nhánh nào (có thể nhiều lần/ngày nếu chi nhánh upload không đồng bộ). Không đảm bảo "single pass" một lần duy nhất, dẫn đến phân tích lặp lại và chi phí cao hơn (nhiều invocation Lambda). Không kiểm soát thời gian chính xác.

• Create an AWS Step Functions state machine that invokes the Lambda function once each day at the predefined time.
  ❌ Sai: Step Functions có thể schedule qua EventBridge, nhưng bản thân Step Functions tính phí theo state transition (~0.000025 USD/1.000 transitions, cộng thêm Lambda). Đắt hơn EventBridge trực tiếp invoke Lambda. Phức tạp không cần thiết cho task đơn giản chỉ invoke một Lambda.

• Configure the Lambda function to run continuously and to begin analysis only at the predefined time each day.
  ❌ Sai: Lambda là serverless event-driven, không hỗ trợ chạy continuously (không có chế độ "always on" như EC2). Không thể config để "chờ" và begin lúc cụ thể mà không dùng scheduler ngoài; nếu dùng loop/poll sẽ tốn kém cực kỳ (duration billing cao, timeout 15 phút). Vi phạm nguyên tắc serverless.

• Create an Amazon EventBridge scheduled rule that invokes the Lambda function once each day at the predefined time.
  ✅ Đúng: Như giải thích ở trên – lịch trình chính xác, single invocation, chi phí thấp nhất (gần zero cho schedule). Hoàn hảo cho batch processing hàng ngày trên S3 data.

🧩 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 mô tả một ứng dụng (application) gọi asynchronously (không đồng bộ) một hàm AWS Lambda. Khi lời gọi thất bại (failed invocations), developer muốn lưu trữ các messages gây ra thất bại để ứng dụng có thể retry (thử lại) sau. Mục tiêu là thực hiện với LEAST operational overhead (ít chi phí vận hành nhất, nghĩa là giải pháp đơn giản, tự động hóa cao, không cần code phức tạp hay quản lý thủ công nhiều).
✅ Chủ đề chính: Xử lý lỗi và retry cho Lambda invocations không đồng bộ (async), tận dụng các dịch vụ AWS tích hợp sẵn như Dead Letter Queue (DLQ) để giảm thiểu công sức quản lý.
🛠️ Bối cảnh AWS cập nhật 2026: Lambda hỗ trợ DLQ từ lâu (cho async invocations qua API Gateway, ALB, SQS, v.v.), và tính năng này được cải tiến với hỗ trợ SQS FIFO DLQ, retry policies linh hoạt hơn (theo AWS Lambda docs 2024-2026). Không cần thay đổi lớn.

✅ Đáp án ĐÚNG và lý do lựa chọn:
Implement a dead-letter queue for discarded messages. Set the dead-letter queue as an event source for the Lambda function.
🧩 Lý do chi tiết: Đây là giải pháp built-in của AWS Lambda cho async invocations thất bại (sau maximum age hoặc retries). DLQ (thường là Amazon SQS queue) tự động lưu messages discarded (bị loại bỏ). Sau đó, set DLQ làm event source cho Lambda để tự động trigger retry mà không cần code thêm hoặc quản lý thủ công. Operational overhead thấp nhất vì hoàn toàn serverless, tự động hóa 100%. Theo best practices AWS, đây là cách recommend cho retry failed async Lambdas.

🔍 Giải thích TẤT CẢ các phương án (đúng/sai)

• ❌ [SAI] Set up Amazon CloudWatch Logs log groups to filter and store the messages in an Amazon S3 bucket. Import the messages in Lambda. Run the Lambda function again.
  🛠️ Phân tích sai: CloudWatch Logs chỉ lưu logs (nhật ký), không lưu payload/messages gốc của invocation một cách tự động. Phải setup filter/export thủ công sang S3 (qua subscription filters), rồi viết code Lambda import từ S3 và run lại → operational overhead cao (quản lý logs, parsing, custom code). Không phù hợp cho retry messages, dễ mất dữ liệu.

• ❌ [SAI] Configure Amazon EventBridge to send the messages to Amazon Simple Notification Service (Amazon SNS) to initiate the Lambda function again.
  🛠️ Phân tích sai: EventBridge + SNS không tự động capture failed Lambda invocations. Developer phải custom logic trong app để detect failure và push event thủ công → overhead lớn (code thêm, monitoring). SNS chỉ fan-out notifications, không lưu trữ/retry tự động như DLQ. Không least effort cho async failures.

• ✅ [ĐÚNG] Implement a dead-letter queue for discarded messages. Set the dead-letter queue as an event source for the Lambda function.
  🛠️ Phân tích đúng: Như đã giải thích, DLQ (SQS/SNS) là feature native của Lambda async (config qua Console/CLI/Terraform). Messages thất bại sau retry policy/max age tự động vào DLQ. Set DLQ làm source → Lambda poll và retry tự động. Zero custom code, fully managed → least overhead. Hỗ trợ visibility timeout, redrive policies (cập nhật 2026).

• ❌ [SAI] Send Amazon EventBridge events to an Amazon Simple Queue Service (Amazon SQS) queue. Configure the Lambda function to pull messages from the SQS queue. Run the Lambda function again.
  🛠️ Phân tích sai: Yêu cầu app gửi EventBridge events thủ công đến SQS khi failure → không tự động, phải code logic detect/send trong app. Lambda pull từ SQS cần config event source mapping riêng, rồi "run again" thủ công → overhead cao (custom integration, monitoring queue). Không tận dụng DLQ built-in.

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

• AWS Lambda Dead-Letter Queues: https://docs.aws.amazon.com/lambda/latest/dg/invocation-retries.html#invocation-retries-async (DLQ cho async, SQS as source).
• Lambda Event Source Mappings: https://docs.aws.amazon.com/lambda/latest/dg/with-sqs.html (Poll DLQ tự động).
• Best Practices DevOps: AWS Well-Architected Framework - Reliability Pillar (Retries & DLQ recommended).
• Exam Prep DOP-C02: Q&A về Lambda error handling trong AWS Certified DevOps Engineer Professional guide (2024 edition).

🛠️ Kết luận: Giải pháp DLQ là optimal cho least overhead, phù hợp DOP-C02 exam! Nếu cần demo code Terraform, hỏi thêm nhé! 🚀

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

📖 Nội dung câu hỏi:
Câu hỏi tập trung vào quy trình cập nhật AWS CloudFormation stack – một dịch vụ tự động hóa việc triển khai và quản lý tài nguyên AWS thông qua các template (mẫu). Công ty đang sử dụng CloudFormation để deploy tài nguyên và giờ cần cập nhật một stack hiện có. Vấn đề chính là: Làm thế nào để dự đoán và xem trước tác động của những thay đổi này lên các tài nguyên đang chạy (running resources)?

✅ Điều này rất quan trọng trong DevOps vì cập nhật stack có thể gây gián đoạn (disruption), thay thế (replace), hoặc cập nhật tài nguyên mà không làm ảnh hưởng đến production. AWS cung cấp công cụ preview để tránh rủi ro trước khi apply thay đổi thực tế. (Kiến thức cập nhật đến 2026: CloudFormation vẫn hỗ trợ tính năng này mạnh mẽ, với tích hợp IAM roles và cross-stack references cải tiến).

✅ Đáp án đúng: Investigate the change sets.
Lý do lựa chọn: Change Sets là tính năng cốt lõi của CloudFormation cho phép tạo một bộ thay đổi (change set) từ template cập nhật, sau đó preview chi tiết tác động như: tài nguyên nào sẽ được thêm (add), cập nhật (update), thay thế (replace), hoặc xóa (delete). Bạn có thể xem action type, replacement reasons, và estimated downtime trước khi execute. Điều này giúp đánh giá rủi ro mà không ảnh hưởng đến stack đang chạy. Quy trình: Create Change Set → Review → Execute (hoặc Discard).

🛠️ Phân tích tất cả các phương án trả lời

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với giải thích chi tiết bằng tiếng Việt:

• Investigate the change sets.
  ✅ Đúng. Như đã giải thích ở trên, đây là cách chính thức và an toàn nhất để preview tác động của cập nhật stack. Change Sets cung cấp báo cáo trực quan trong AWS Console hoặc CLI, hiển thị resource-level changes và drift detection (kiểm tra lệch lạc). Không có công cụ nào khác thay thế tốt hơn cho mục đích này.

• Investigate the stack policies.
  ❌ Sai. Stack Policies chỉ dùng để bảo vệ (protect) tài nguyên cụ thể khỏi cập nhật không mong muốn bằng cách định nghĩa quy tắc (ví dụ: Update:Deny cho EC2 instances). Chúng không preview hoặc phân tích tác động thay đổi, mà chỉ kiểm soát hành vi khi execute update. Không liên quan đến việc "find out how changes impact".

• Investigate the Metadata section.
  ❌ Sai. Metadata section trong CloudFormation template chỉ chứa thông tin mô tả, tags, hoặc custom data (như AWS::CloudFormation::Init cho cfn-init). Nó không cung cấp bất kỳ preview nào về tác động cập nhật stack, chỉ là phần static của template.

• Investigate the Resources section.
  ❌ Sai. Resources section định nghĩa các tài nguyên AWS (như EC2, S3) trong template, bao gồm properties và dependencies. Tuy nhiên, nó chỉ mô tả desired state tĩnh, không simulate hoặc preview tác động thực tế khi so sánh với stack hiện tại (current stack). Bạn cần tool như Change Sets để so sánh diff.

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

• CloudFormation Change Sets: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-change-sets.html – Hướng dẫn chi tiết tạo và review change sets.
• Stack Policies: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/protect-stack-resources.html.
• Template Anatomy: https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-anatomy.html.

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ụ CLI hoặc template mẫu, hãy hỏi nhé!

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

Câu hỏi này xoay quanh cross-account access (truy cập tài nguyên giữa các AWS Account khác nhau) đến một bảng Amazon DynamoDB lưu trữ thông tin cá nhân (PII) trong Account A. Ứng dụng chạy trên các instance Amazon EC2 thuộc Account B cần quyền truy cập bảng PII này.

Quản trị viên ở Account A đã chuẩn bị sẵn:

• IAM Role tên AccessPII với quyền truy cập bảng PII.
• Trust policy cho phép Account B (làm principal) có thể assume role này.

Nhiệm vụ của developers ở Account B là thực hiện các bước để ứng dụng EC2 có thể sử dụng role từ Account A, lấy temporary credentials an toàn thay vì hardcode credentials. Đây là mô hình cross-account role assumption tiêu chuẩn theo best practices AWS, giúp tuân thủ nguyên tắc least privilege và bảo mật cao. Câu hỏi yêu cầu chọn TWO bước đúng mà developers ở Account B phải thực hiện.

Kiến thức cập nhật: Theo tài liệu AWS mới nhất (2024-2026), cơ chế này sử dụng STS AssumeRole cho cross-account delegation, hỗ trợ DynamoDB với IAM policies fine-grained (như resource-based policies nếu cần, nhưng ở đây dùng role assumption). Không thay đổi lớn từ phiên bản trước.

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

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

1. Allow the EC2 IAM role the permission to assume the AccessPII role.
2. Include the AssumeRole API operation in the application code logic to obtain temporary credentials to access the PII table.

Lý do lựa chọn:

• 🛠️ Bước 1: EC2 instances ở Account B chạy với một EC2 IAM Role (instance profile). Để assume role AccessPII từ Account A, role này cần policy cho phép sts:AssumeRole nhắm đến ARN của AccessPII. Đây là điều kiện tiên quyết ở phía Account B.
• 🛠️ Bước 2: Trong code ứng dụng (ví dụ SDK AWS như boto3), gọi STS AssumeRole để lấy temporary credentials (AccessKeyId, SecretKey, SessionToken) từ role AccessPII, sau đó dùng credentials này truy cập DynamoDB PII.
• Kết hợp hai bước tạo luồng: EC2 role → Assume AccessPII → Truy cập DynamoDB. An toàn, không chia sẻ long-term keys!

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên quy trình cross-account role assumption chuẩn AWS:

• ✅ Allow the EC2 IAM role the permission to assume the AccessPII role.
  Đúng 🟢: Đây là bước đầu tiên ở Account B. Attach IAM policy vào EC2 role với action sts:AssumeRole và resource là ARN của AccessPII (Account A). Trust policy ở Account A đã cho phép, giờ Account B cần cấp quyền assume. Không có bước này, app không thể gọi AssumeRole.

• ❌ Allow the EC2 IAM role the permission to access the PII table.
  Sai 🔴: Sai vì DynamoDB ở Account A không cho phép trực tiếp IAM role từ Account B truy cập (cross-account policy). Phải dùng role delegation qua AssumeRole, không phải direct permission đến table. Nếu làm vậy, cần resource policy trên table (phức tạp hơn, không best practice).

• ❌ Include the AWS API in the application code logic to obtain temporary credentials from the EC2 IAM role to access the PII table.
  Sai 🔴: Lựa chọn mơ hồ ("AWS API" không cụ thể), và sai logic. Temporary credentials từ EC2 role chỉ cho phép tài nguyên trong Account B, không cross-account đến DynamoDB Account A. Không giải quyết vấn đề delegation.

• ✅ Include the AssumeRole API operation in the application code logic to obtain temporary credentials to access the PII table.
  Đúng 🟢: Bước thứ hai cần thiết. Code app gọi sts:AssumeRole với RoleArn của AccessPII, sử dụng credentials từ EC2 role. Nhận về session credentials dùng cho DynamoDB API calls. Ví dụ code boto3: sts_client.assume_role(RoleArn='arn:aws:iam::AccountA:role/AccessPII', RoleSessionName='session').

• ❌ Include the GetSessionToken API operation in the application code logic to obtain temporary credentials to access the PII table.
  Sai 🔴: GetSessionToken chỉ dùng cho MFA hoặc temporary creds từ user/root credentials trong cùng account, không hỗ trợ cross-account role assumption. Phải dùng AssumeRole cho role ở account khác.

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

• Cross-Account IAM Roles: AWS IAM User Guide - AssumeRole – Chi tiết trust policy và sts:AssumeRole policy.
• DynamoDB Cross-Account Access: AWS DynamoDB Developer Guide - IAM Roles – Khuyến nghị role assumption.
• STS AssumeRole API: AWS STS API Reference – Ví dụ code và limitations.
• EC2 Instance Profiles: AWS EC2 User Guide - IAM Roles for EC2.
• Best Practices DOP-C02 Exam: AWS Certified DevOps Engineer Professional (2024) – Topic: Security & IAM (30-40% exam weight).

Nếu cần ví dụ code chi tiết hoặc lab thực hành, hãy hỏi thêm! 🚀

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

Câu hỏi mô tả một nền tảng website game cho phép người dùng trao đổi (trade) các vật phẩm game với nhau. Yêu cầu chính là cập nhật và lưu trữ dữ liệu của cả hai người dùng trong một giao dịch (transaction) duy nhất, đảm bảo tính atomicity (tất cả thành công hoặc rollback toàn bộ nếu có lỗi). Điều này tránh tình trạng một bên cập nhật thành công nhưng bên kia thất bại, dẫn đến dữ liệu không nhất quán.
Mục tiêu: Chọn hai giải pháp AWS hỗ trợ transactional capability (khả năng giao dịch ACID: Atomicity, Consistency, Isolation, Durability).
✅ Đây là yêu cầu điển hình cho strong consistency và atomic updates trong môi trường phân tán cao như gaming platform.

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

Hai đáp án đúng là:
Amazon DynamoDB with reads and writes made by using Transact operations*
Amazon Aurora MySQL with operations made within a transaction block

Lý do lựa chọn:
🛠️ DynamoDB Transact* (TransactWriteItems/TransactGetItems): Hỗ trợ giao dịch atomic lên đến 100 items/actions, đảm bảo tất cả reads/writes thành công hoặc rollback hoàn toàn. Phù hợp cho NoSQL high-throughput như gaming trades (cập nhật inventory hai users). Đây là tính năng native từ 2018, ổn định đến 2026.
🛠️ Aurora MySQL transaction block (BEGIN/COMMIT/ROLLBACK): RDS Aurora hỗ trợ đầy đủ ACID transactions như MySQL truyền thống, lý tưởng cho relational data với foreign keys/constraints trong trades. Serverless v2 (2026) vẫn giữ nguyên.
📈 Cả hai đều đảm bảo zero-downtime consistency cho use case này.

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

• ❌ Amazon DynamoDB with operations made with the ConsistentRead parameter set to true
  🛠️ Sai: ConsistentRead chỉ đảm bảo eventual consistency → strong consistency cho reads (đọc dữ liệu mới nhất), nhưng KHÔNG hỗ trợ atomic writes/transactions. Không rollback nếu write fail, chỉ dùng cho query an toàn, không phù hợp trade items.

• ❌ Amazon ElastiCache for Memcached with operations made within a transaction block
  🛠️ Sai: ElastiCache Memcached là in-memory caching, hỗ trợ multi-get/set nhưng KHÔNG có transaction block thực thụ (không ACID, không rollback). Dữ liệu dễ mất nếu node fail, chỉ cache tạm thời, không persist trades.

• ✅ Amazon DynamoDB with reads and writes made by using Transact operations*
  🛠️ Đúng: TransactWriteItems/TransactGetItems cung cấp atomic transactions đa items (max 100), all-or-nothing semantics. Hoàn hảo cho cập nhật inventory hai users, hỗ trợ conditional writes tránh race conditions. Throughput cao cho gaming.

• ✅ Amazon Aurora MySQL with operations made within a transaction block
  🛠️ Đúng: Aurora MySQL (và PostgreSQL) hỗ trợ full ACID transactions với BEGIN...COMMIT/ROLLBACK. Lý tưởng relational schemas (users, items tables), auto-scaling, multi-AZ durability. Phiên bản 2026 vẫn giữ.

• ❌ Amazon Athena with operations made within a transaction block
  🛠️ Sai: Athena là serverless query engine cho S3 data (read-only analytics), KHÔNG hỗ trợ writes/updates/transactions. Chỉ query immutable data, không persist changes hay rollback.

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

• DynamoDB Transactions: AWS DynamoDB Developer Guide - Transactions (Transact* ops atomic 100 items).
• Aurora Transactions: AWS Aurora Docs - MySQL Transactions (ACID full support).
• So sánh: AWS Database Blog - Transactions in DynamoDB vs RDS (2024-2026 updates).
  ✅ Kiến thức dựa trên AWS Certified DevOps Engineer Professional DOP-C02 syllabus, xác nhận qua re:Post/forums 2026.