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

🧩 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 triển khai một dịch vụ REST sử dụng Amazon API Gateway tích hợp với AWS Lambda, và công ty cần hỗ trợ chạy nhiều phiên bản khác nhau (versions) của dịch vụ này nhằm mục đích testing.

📌 Yêu cầu chính: Tìm cách tốt nhất (BEST way) để quản lý các phiên bản này một cách hiệu quả, đảm bảo tính cô lập, dễ kiểm soát và cung cấp ngữ cảnh (context) cho Lambda.

• API Gateway là dịch vụ quản lý API serverless, hỗ trợ tích hợp Lambda để xử lý request.
• Phiên bản khác nhau thường cần endpoints riêng biệt để test độc lập (ví dụ: dev, test, prod), tránh ảnh hưởng lẫn nhau.
• Theo kiến thức AWS cập nhật đến năm 2026 (API Gateway v2 với HTTP APIs và REST APIs), versioning qua stages là best practice tiêu chuẩn, kết hợp stage variables để truyền thông tin version vào Lambda mà không cần thay đổi code.

🛠️ Mục tiêu: Đảm bảo tính linh hoạt, scalability, và dễ deploy mà không làm phức tạp architecture.

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

Đáp án đúng: Deploy the API versions as unique stages with unique endpoints and use stage variables to provide further context.

Lý do chi tiết:

• API Gateway stages cho phép tạo các môi trường riêng biệt (như "v1", "v2", "test-v1") với endpoints độc lập (ví dụ: https://abc.execute-api.us-east-1.amazonaws.com/v1/ và https://abc.execute-api.us-east-1.amazonaws.com/v2/), giúp test song song mà không xung đột.
• Stage variables là các biến môi trường gắn với stage, có thể truyền trực tiếp vào Lambda (qua mapping templates hoặc integration), cung cấp context như version number, giúp Lambda xử lý logic khác nhau mà không cần parse header/request.
• Đây là best practice của AWS cho versioning APIs: Dễ quản lý deploy (qua CloudFormation/CDK), hỗ trợ canary deployments, logging riêng, throttling per stage, và tích hợp CI/CD với AWS CodePipeline.
• ✅ Ưu điểm vượt trội: Zero-downtime, chi phí thấp, native support trong console/CLI, phù hợp testing multi-version.

📋 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 một cách chi tiết:

• ❌ Use an X-Version header to denote which version is being called and pass that header to the Lambda function(s).
  Phương án này sai vì yêu cầu custom logic trong API Gateway (qua integration mapping hoặc Lambda proxy) để parse header và route đến Lambda tương ứng. Không phải "best way" vì: (1) Phức tạp hóa code, dễ lỗi; (2) Không cô lập endpoints, tất cả request dùng chung URL dẫn đến khó test độc lập; (3) Không tận dụng native features của Gateway; (4) Scalability kém khi version tăng.

• ❌ Create an API Gateway Lambda authorizer to route API clients to the correct API version.
  Phương án này sai vì Lambda authorizer (token/Cognito/request-based) chỉ dùng cho authentication/authorization, không thiết kế để routing versions. Sử dụng sẽ lạm dụng authorizer, tăng latency (mỗi request gọi Lambda auth), và không cung cấp endpoints riêng. AWS khuyến cáo tách biệt auth và routing.

• ❌ Create an API Gateway resource policy to isolate versions and provide context to the Lambda function(s).
  Phương án này sai vì resource policy (API Gateway Resource Policy) chỉ dùng cho access control (IAM/Principal-based), như deny/allow IP, không hỗ trợ routing hay versioning. Nó không truyền context vào Lambda và không tạo endpoints riêng, dẫn đến không isolate versions hiệu quả. Đây là misuse của policy.

• ✅ Deploy the API versions as unique stages with unique endpoints and use stage variables to provide further context.
  Như đã giải thích ở trên, đây là đúng và tốt nhất vì fully native, scalable, và align với AWS Well-Architected Framework (Operational Excellence pillar).

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

• API Gateway Developer Guide: Stages và Stage Variables.
• AWS Best Practices: API Versioning with Stages.
• Exam Topic DOP-C02: API Gateway management trong DevOps Professional (xem AWS Certified DevOps Engineer - Professional Exam Guide 2024+).
• Console Demo: Tạo stage mới trong API Gateway console → Deploy → Set stage variables như version: "v1.0".

🧠 Lời khuyên DevOps: Sử dụng AWS SAM/CDK để automate stage deployment, kết hợp CloudWatch cho monitoring per stage! Nếu cần hands-on, thử free tier API Gateway.

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

Câu hỏi mô tả một pipeline CI/CD trên AWS CodePipeline, được kích hoạt bởi thay đổi trên nhánh main của kho mã nguồn AWS CodeCommit. Pipeline sử dụng AWS CodeBuild cho các giai đoạn test và build, và AWS CodeDeploy để triển khai ứng dụng. Pipeline đã hoạt động ổn định trong nhiều tháng mà không có thay đổi cấu hình nào. Tuy nhiên, sau một thay đổi gần đây trên mã nguồn ứng dụng, AWS CodeDeploy không triển khai phiên bản cập nhật như mong đợi.

Mục tiêu câu hỏi: Xác định hai nguyên nhân có thể dẫn đến vấn đề này. Đây là tình huống thực tế trong DevOps, nơi pipeline chỉ trigger bởi branch cụ thể, và sự cố có thể xảy ra ở source trigger hoặc failure ở stage trước deploy. Kiến thức dựa trên AWS DevOps services cập nhật đến 2026 (AWS CodePipeline version mới nhất hỗ trợ multi-account pipelines, enhanced monitoring với CloudWatch, nhưng logic trigger và stage failure không thay đổi cơ bản).

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

Hai nguyên nhân đúng là:

• The change was not made in the main branch of the AWS CodeCommit repository.
  (Thay đổi không được thực hiện trên nhánh main của AWS CodeCommit, nên pipeline không trigger.)
• One of the earlier stages in the pipeline failed and the pipeline has terminated.
  (Một trong các giai đoạn trước đó trong pipeline thất bại, dẫn đến pipeline dừng lại trước khi đến deploy.)

Lý do chọn: Pipeline chỉ trigger bởi thay đổi trên main branch (theo mô tả), nên nếu commit ở branch khác → không chạy. Hoặc nếu chạy nhưng stage Source/CodeBuild fail (ví dụ test fail do code mới lỗi) → pipeline terminate, không đến CodeDeploy. Các case này khớp với "recent change to source code" mà không deploy.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm giải thích lý do dựa trên hành vi AWS CodePipeline:

• ✅ The change was not made in the main branch of the AWS CodeCommit repository.
  Đúng: Pipeline được cấu hình trigger chỉ bởi nhánh main của CodeCommit. Nếu thay đổi code ở branch khác (ví dụ feature branch), webhook không kích hoạt pipeline → không có execution mới, dẫn đến CodeDeploy không deploy. Đây là nguyên nhân phổ biến, khớp với "recent change" nhưng không trigger.

• ✅ One of the earlier stages in the pipeline failed and the pipeline has terminated.
  Đúng: CodePipeline chạy tuần tự (Source → Build/Test → Deploy). Nếu stage Source (CodeCommit pull fail) hoặc CodeBuild (test/build fail do code mới lỗi) thất bại, pipeline tự động terminate và không tiến đến CodeDeploy. Status sẽ hiển thị "Failed" trên Console, rất hợp lý sau "recent change".

• ❌ One of the Amazon EC2 instances in the company’s AWS CodePipeline cluster is inactive.
  Sai: AWS CodePipeline là managed service serverless, không chạy trên EC2 cluster nào cả (không có "CodePipeline cluster"). Nó sử dụng infrastructure AWS-managed, tự scale và highly available. Vấn đề EC2 chỉ liên quan nếu deploy đến EC2 fleet qua CodeDeploy, nhưng câu hỏi focus vào pipeline không invoke deploy.

• ❌ The AWS CodePipeline is incorrectly configured and is not invoking AWS CodeDeploy.
  Sai: Pipeline đã "operating successfully for several months" mà không modifications, nên cấu hình (actions, transitions) phải đúng. Nếu sai (ví dụ action CodeDeploy misconfigured), sẽ fail từ lâu, không chờ "recent change". Có thể check logs Pipeline executions để confirm.

• ❌ AWS CodePipeline does not have permissions to access AWS CodeCommit.
  Sai: Permissions (IAM roles cho CodePipeline service role) nếu thiếu sẽ fail ngay stage Source từ đầu, và pipeline không chạy được mấy tháng. Hơn nữa, vấn đề chỉ xảy ra sau "recent change" → không phải permissions (vì Source stage sẽ báo "AccessDenied" rõ ràng nếu vậy).

📘 Tài liệu tham khảo

• AWS CodePipeline Documentation (2026): Troubleshooting CodePipeline – Chi tiết về trigger failures (branch mismatch) và stage terminations.
• AWS CodeCommit triggers: Repository triggers – Xác nhận webhook chỉ filter branch cụ thể.
• Best Practices: AWS Well-Architected Framework – DevOps Pillar (2024 update): Nhấn mạnh monitoring pipeline executions qua CloudWatch để debug stage failures.
• Exam Tip (DOP-C02): Câu hỏi kiểu này test hiểu biết về pipeline lifecycle và common pitfalls (trigger specificity, sequential execution).

Hy vọng phân tích giúp bạn nắm vững! 🚀 Nếu cần demo pipeline thực tế, hãy hỏi thêm.

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

📘 Nội dung câu hỏi được giải thích rõ ràng:
Câu hỏi mô tả một lập trình viên đang xây dựng ứng dụng serverless sử dụng AWS Serverless Application Model (AWS SAM) với nhiều hàm AWS Lambda. Khi triển khai (deploy) ứng dụng mới, yêu cầu cụ thể là:

• Chuyển hướng 10% lưu lượng truy cập (traffic) sang phiên bản mới trong 10 phút đầu tiên sau khi deploy (kiểu triển khai Canary).
• Nếu không có vấn đề gì (no issues), chuyển toàn bộ 100% traffic sang phiên bản mới.

🛠️ Mục tiêu chính: Sử dụng tính năng DeploymentPreference trong template AWS SAM để thực hiện canary deployment tự động, đảm bảo an toàn bằng cách test dần traffic trước khi switch full. Điều này giúp giảm rủi ro downtime và phát hiện lỗi sớm trong môi trường production.

✅ Đáp án đúng:
Set the Deployment Preference Type to Canary10Percent10Minutes. Set the AutoPublishAlias property to the Lambda alias.

Lý do chọn đáp án này (chi tiết):

• Canary10Percent10Minutes: Đây là loại Canary deployment chuẩn của AWS SAM/Lambda, chuyển 10% traffic sang phiên bản mới trong 10 phút đầu. Sau đó, nếu không có lỗi (dựa trên CloudWatch metrics tự động), hệ thống sẽ tự động switch 100% traffic sang alias.
• AutoPublishAlias: Thuộc tính này tự động publish alias (ví dụ: "live" hoặc "prod") sau deployment thành công, cho phép traffic shifting mượt mà mà không cần can thiệp thủ công.
  Kết hợp hai thuộc tính này hoàn hảo đáp ứng yêu cầu: test 10% traffic 10 phút rồi auto-switch full nếu OK. Đây là best practice cho multi-Lambda functions trong SAM template (cập nhật đến AWS SAM CLI v1.XX năm 2025-2026).

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

• ✅ [ĐÚNG] Set the Deployment Preference Type to Canary10Percent10Minutes. Set the AutoPublishAlias property to the Lambda alias.
  Như đã giải thích ở trên: Hoàn toàn chính xác vì Canary10Percent10Minutes khớp yêu cầu 10%/10 phút + auto-switch, và AutoPublishAlias kích hoạt alias traffic shifting tự động. Không cần Pre/PostTraffic vì đây không phải testing thủ công.

• ❌ [SAI] Set the Deployment Preference Type to Linear10PercentEvery10Minutes. Set AutoPublishAlias property to the Lambda alias.
  Sai vì: Linear10PercentEvery10Minutes là kiểu triển khai dần dần (linear), tăng 10% traffic mỗi 10 phút liên tục (ví dụ: 10% → 20% → ... → 100%), không phải chỉ 10% trong 10 phút đầu rồi switch all. Không khớp yêu cầu canary nhanh. AutoPublishAlias đúng nhưng type sai làm toàn bộ thất bại.

• ❌ [SAI] Set the Deployment Preference Type to Canary10Percent10Minutes. Set the PreTraffic and PostTraffic properties to the Lambda alias.
  Sai vì: Canary10Percent10Minutes đúng, nhưng PreTraffic/PostTraffic chỉ dùng cho testing Lambda versions/aliases thủ công (gửi test events trước/sau deploy), KHÔNG hỗ trợ traffic shifting tự động 10%/10 phút. Chúng không kích hoạt canary deployment, dẫn đến không switch traffic đúng yêu cầu.

• ❌ [SAI] Set the Deployment Preference Type to Linear10PercentEvery10Minutes. Set PreTraffic and PostTraffic properties to the Lambda alias.
  Sai vì: Cả hai đều sai – Linear... không khớp canary 10 phút cố định, và Pre/PostTraffic chỉ cho testing, không làm traffic shifting tự động. Kết hợp này không deploy theo yêu cầu, có thể gây rủi ro traffic không kiểm soát.

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

• AWS SAM Developer Guide - DeploymentPreference: docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-property-function-deploymentpreference.html – Chi tiết Canary types & AutoPublishAlias.
• AWS Lambda Canary Deployments: docs.aws.amazon.com/lambda/latest/dg/configuration-traffic-shifting.html – Giải thích traffic shifting với aliases.
• AWS SAM CLI Release Notes (2025-2026): Không thay đổi core feature này, vẫn hỗ trợ full multi-function canary.

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ụ YAML template, hỏi thêm nhé!

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

Câu hỏi xoay quanh việc cấu hình quyền truy cập chéo tài khoản (cross-account permissions) cho một hàm AWS Lambda chạy trong tài khoản shared (chia sẻ). Hàm Lambda này cần thực hiện hành động ec2:DescribeInstances nhắm đến các tài khoản development (dev accounts) của công ty. Mục tiêu là tuân thủ nguyên tắc least privilege (quyền hạn tối thiểu), nghĩa là chỉ cấp quyền cần thiết và không hơn, tránh cấp quyền rộng rãi trực tiếp cho Lambda.

Tình huống cụ thể:

• Lambda nằm ở shared account 👥.
• Cần truy cập EC2 instances ở development accounts (nhiều tài khoản dev khác nhau) 🔍.
• Developer phải cấu hình IAM roles để Lambda có thể "giả sử vai trò" (assume role) ở dev accounts, thực hiện chỉ ec2:DescribeInstances mà không cần quyền admin hoặc quyền trực tiếp chéo tài khoản.

Vấn đề cốt lõi: Shared account không nên có quyền trực tiếp trên resources của dev accounts (vi phạm isolation và least privilege). Thay vào đó, sử dụng IAM roles cross-account với trust policy cho phép shared account assume role ở dev accounts. Lambda role chỉ cần sts:AssumeRole (hoặc iam:AssumeRole) để "mượn" quyền từ role kia.

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

• AWS IAM Cross-Account Access (cập nhật 2024-2026).
• AWS Lambda Execution Role.
• AWS Well-Architected Framework: Security Pillar (least privilege với ABAC/RBAC).

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

Đáp án đúng:
Create an IAM role in the development accounts. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship with the shared account for this role. Update the Lambda function IAM role in the shared account by adding the iam:AssumeRole permissions.

Lý do chi tiết 🛠️:

• Tạo IAM role ở dev accounts với chỉ quyền ec2:DescribeInstances (least privilege: chỉ quyền cần trên EC2 của dev account đó).
• Trust policy của role này cho phép shared account assume role (Principal: ARN của shared account).
• Lambda execution role ở shared account chỉ thêm policy iam:AssumeRole cho role ở dev accounts → Lambda assume role, "mượn" quyền EC2 từ dev, không lưu quyền EC2 trực tiếp ở shared.
• Hoàn hảo cho multi-account setup, scalable cho nhiều dev accounts (tạo role tương tự ở mỗi dev account).
• Tuân thủ zero-trust model AWS mới nhất (2024+): Assume role thay vì resource policies.

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

Dưới đây là phân tích từng phương án một, giữ nguyên văn bản gốc tiếng Anh. Mỗi phương án được đánh giá dựa trên tính đúng đắn về cross-account IAM và least privilege.

1. Create an IAM role in the shared account. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship between the development accounts for this role. Update the Lambda function IAM role in the shared account by adding the ec2:DescribeInstances permission to the role.
   ❌ Sai hoàn toàn 🚫:

   • Role ở shared account với ec2:DescribeInstances chỉ hoạt động trên resources của shared account, không chạm được EC2 ở dev accounts (cross-account không work như vậy).
   • Trust từ dev accounts cho role shared là ngược chiều, vô nghĩa (dev không cần trust shared).
   • Thêm ec2:DescribeInstances trực tiếp vào Lambda role vi phạm least privilege (quyền dư thừa, không cross-account). Không giải quyết vấn đề gốc.

2. Create an IAM role in the development accounts. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship with the shared account for this role. Update the Lambda function IAM role in the shared account by adding the iam:AssumeRole permissions.
   ✅ Đúng tuyệt đối 🎯:
   (Như giải thích ở phần đáp án đúng ở trên). Đây là best practice AWS cho cross-account Lambda access.

3. Create an IAM role in the shared account. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship between the development accounts for this role. Update the Lambda function IAM role in the shared account by adding the iam:AssumeRole permissions.
   ❌ Sai cơ bản 🔄:

   • Role ở shared với ec2:DescribeInstances vẫn chỉ giới hạn ở shared account's EC2, không access dev accounts được.
   • Trust từ dev accounts (ngược chiều) không giúp Lambda assume để access dev resources.
   • Lambda assume role shared chỉ lặp quyền nội bộ, không giải quyết cross-account. Vi phạm isolation multi-account.

4. Create an IAM role in the development accounts. Add the ec2:DescribeInstances permission to the role. Establish a trust relationship with the shared account for this role. Update the Lambda function IAM role in the shared account by adding the ec2:DescribeInstances permission to the role.
   ❌ Sai một phần ⚠️:

   • Phần tạo role ở dev accounts và trust đúng (tốt cho cross-account).
   • Nhưng thêm ec2:DescribeInstances trực tiếp vào Lambda role ở shared là sai: Quyền này không work cross-account (EC2 ở dev), và vi phạm least privilege (cấp quyền không dùng được, dễ audit fail). Phải dùng iam:AssumeRole thay thế.

Kết luận 📝: Phương án đúng đảm bảo security boundary rõ ràng giữa shared và dev accounts, dễ audit với AWS IAM Access Analyzer (tính năng mới 2023+). Trong thực tế DevOps, dùng AWS Organizations + SCPs để enforce least privilege toàn tổ chức! 🚀

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

Câu hỏi tập trung vào việc một lập trình viên đang xây dựng ứng dụng mới trên AWS, sử dụng AWS CodeCommit làm repository và khởi tạo dự án bằng lệnh cdk init của AWS Cloud Development Kit (AWS CDK).
Yêu cầu chính là:

• 📝 Viết unit tests cho các template Infrastructure as Code (IaC) mà CDK tự động sinh ra (như CloudFormation templates trong thư mục cdk.out).
• 🛡️ Chạy công cụ validation trên tất cả constructs trong ứng dụng CDK để đảm bảo các cấu hình bảo mật quan trọng (critical security configurations) được kích hoạt.
• Mục tiêu: Sử dụng kết hợp 2 actions với LEAST development overhead (ít công sức phát triển nhất), nghĩa là ưu tiên các giải pháp tích hợp sẵn, tự động, không cần viết code thủ công phức tạp.
  Câu hỏi thuộc chủ đề DevOps trên AWS CDK, nhấn mạnh testing và validation IaC để đảm bảo an toàn và chất lượng code infrastructure. (Kiến thức cập nhật đến CDK v2.x năm 2026, hỗ trợ assertions và aspects mạnh mẽ hơn).

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

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

1. Use the CDK assertions module to integrate unit tests with the application. Run the unit tests in a continuous integration and continuous delivery (CI/CD) pipeline that is invoked after any commit to the repository.
2. Use the CDK Aspects class to create custom rules to apply to the CDK application. Fall the stack synthesis if any violations are present.

Lý do lựa chọn:

• 🏆 CDK Assertions module cung cấp framework unit testing tích hợp sẵn (như Template.fromStack() để kiểm tra synthesized template), dễ dàng viết test assertions (ví dụ: kiểm tra resource có tồn tại, properties đúng) mà không cần synthesize thủ công, giảm overhead tối đa. Tích hợp CI/CD (như CodePipeline) tự động chạy sau commit.
• 🛡️ CDK Aspects class cho phép tạo rules tùy chỉnh (implements IAspect) để tự động scan toàn bộ constructs trong app, kiểm tra security (ví dụ: enforce encryption, public access), và fail synthesis ngay nếu vi phạm – hoàn hảo cho validation với zero-effort scanning.
  Kết hợp hai cái này đáp ứng unit tests + validation security với least overhead, vì đều là native CDK tools (không custom script hay manual parsing).

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phần đánh dấu ✅ (đúng) hoặc ❌ (sai), kèm lý do cụ thể dựa trên best practices AWS CDK v2 (2026).

• Use a unit testing framework to write custom unit tests against the cdk.out file that the AWS CDK generates. Run the unit tests in a CI/CD pipeline that is invoked after any commit to the repository.
  ❌ Sai: Phương án này yêu cầu synthesize stack trước (chạy cdk synth để tạo cdk.out), rồi viết custom unit tests (như Jest/Mocha parse JSON thủ công). Overhead cao vì: (1) Phụ thuộc file tạm thời cdk.out (dễ lỗi nếu context thay đổi), (2) Không native, phải code nhiều logic parsing. Assertions module tốt hơn vì test trực tiếp in-memory mà không cần synth.

• Use the CDK assertions module to integrate unit tests with the application. Run the unit tests in a continuous integration and continuous delivery (CI/CD) pipeline that is invoked after any commit to the repository.
  ✅ Đúng: Đây là giải pháp chuẩn cho unit tests IaC trong CDK. Sử dụng @aws-cdk/assertions (hoặc aws-cdk-lib/assertions ở v2) để tạo Template object từ stack, viết assertions đơn giản (e.g., template.hasResourceProperties("AWS::S3::Bucket", { Encryption: true })). Tích hợp CI/CD (CodeBuild) tự động, least overhead vì code test ngắn gọn, không phụ thuộc file ngoài.

• Use the CDK runtime context to set key-value pairs that must be present in the cdk.out file that the AWS CDK generates. Fail the stack synthesis if any violations are present.
  ❌ Sai: CDK Context chỉ dùng để cache dữ liệu lookup (như ARNs, regions) qua cdk.json hoặc context method, KHÔNG phải để enforce security rules hay kiểm tra cdk.out. Không thể fail synthesis dựa trên key-value tùy chỉnh như vậy – sai mục đích, overhead vì phải hack context không chuẩn.

• Write a script that searches the application for specific key configuration strings. Configure the script to produce a report of any security violations.
  ❌ Sai: Đây là cách manual scripting (grep/regex search code strings), overhead cực cao: (1) Không scan synthesized template (chỉ source code), (2) Dễ miss dynamic constructs, (3) Không tích hợp fail-fast như Aspects. Phải maintain script riêng, không scale với app lớn – trái ngược "least overhead".

• Use the CDK Aspects class to create custom rules to apply to the CDK application. Fall the stack synthesis if any violations are present.
  ✅ Đúng: Aspects (từ aws-cdk-lib/aspects) là visitor pattern native để apply rules toàn bộ constructs tree (e.g., new MySecurityAspect().visit(app) trước cdk synth). Custom rules dễ viết (e.g., check S3 encryption), fail synthesis ngay nếu vi phạm. Hoàn hảo cho security validation, zero runtime overhead vì chạy lúc synth.

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

• CDK Assertions: AWS CDK Assertions Module – Hướng dẫn unit tests với examples.
• CDK Aspects: AWS CDK Aspects – Custom rules và security checks.
• Best Practices IaC Testing: AWS CDK Developer Guide - Testing.
• CI/CD Integration: AWS CodePipeline với CDK.

🛠️ Lời khuyên: Trong thực tế DOP-C02 exam, luôn ưu tiên native CDK tools như Assertions/Aspects để minimize custom code! Nếu deploy, kết hợp với cdk-nag cho thêm security scans.

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

Câu hỏi tập trung vào việc triển khai một ứng dụng serverless trên AWS, nơi một hàm AWS Lambda được sử dụng để tính toán tỷ lệ thành công đơn hàng và lưu kết quả vào bảng Amazon DynamoDB. Yêu cầu chính là tìm cách gọi (invoke) hàm Lambda mỗi 15 phút một cách hiệu quả, với tiêu chí quan trọng nhất là LEAST development effort (ít nỗ lực phát triển nhất).

📌 Bối cảnh chính:

• Ứng dụng hoàn toàn serverless (không quản lý server), nên giải pháp cần ưu tiên các dịch vụ tự động hóa, không yêu cầu quản lý hạ tầng thủ công.
• Cần lập lịch định kỳ (scheduling) mà không phức tạp hóa code hoặc vận hành.
• Theo kiến thức AWS cập nhật đến năm 2026, Amazon EventBridge (trước đây là CloudWatch Events) là dịch vụ chuẩn cho việc lập lịch sự kiện serverless, hỗ trợ rate expressions như rate(15 minutes) một cách native và zero-code.

Mục tiêu: Chọn giải pháp đơn giản nhất, nhanh triển khai nhất mà vẫn scalable và cost-effective.

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

Đáp án đúng: Create an Amazon EventBridge rule that has a rate expression that will run the rule every 15 minutes. Add the Lambda function as the target of the EventBridge rule.

Lý do chọn 🛠️:

• Đây là giải pháp serverless thuần túy, không cần viết code thêm, chỉ cần tạo rule qua AWS Console, CLI hoặc CDK/Terraform.
• EventBridge hỗ trợ rate-based rules chính xác (ví dụ: rate(15 minutes)), tự động invoke Lambda làm target mà không cần permission phức tạp (chỉ cần attach IAM role).
• Least development effort: Triển khai trong vài phút, không quản lý server, tự scale, và tích hợp native với Lambda/DynamoDB.
• Theo AWS Well-Architected Framework (2024-2026), đây là best practice cho periodic invocation trong serverless apps.

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

• AWS EventBridge Documentation: Creating rate-based rules (cập nhật 2025).
• AWS Lambda Developer Guide: Using EventBridge.

📋 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á dựa trên tính serverless, development effort, độ chính xác kỹ thuật và phù hợp yêu cầu (theo AWS best practices 2026).

• Create an Amazon EventBridge rule that has a rate expression that will run the rule every 15 minutes. Add the Lambda function as the target of the EventBridge rule.
  ✅ Đúng hoàn toàn 🏆. Giải pháp này sử dụng EventBridge Scheduler (tích hợp trong EventBridge từ 2022, cập nhật 2025) với rate expression chuẩn, target trực tiếp Lambda. Không cần code, permission đơn giản (EventBridge gửi event JSON đến Lambda), chi phí thấp (~$1/million events). Hoàn hảo cho serverless, zero management.

• Create an AWS Systems Manager document that has a script that will invoke the Lambda function on Amazon EC2. Use a Systems Manager Run Command task to run the shell script every 15 minutes.
  ❌ Sai 🚫. AWS Systems Manager (SSM) dùng cho quản lý fleet EC2 on-prem/hybrid, không phải serverless. Phải provision EC2 (không least effort), viết script invoke Lambda (cần AWS CLI/SDK), và schedule qua Run Command/State Manager – phức tạp, tốn chi phí EC2 idle, vi phạm nguyên tắc serverless.

• Create an AWS Step Functions state machine. Configure the state machine to invoke the Lambda function execution role at a specified interval by using a Wait state. Set the interval to 15 minutes.
  ❌ Sai 🔧. Step Functions dành cho orchestration workflow phức tạp, không phải simple scheduling. Wait state chỉ delay trong execution một lần (không loop định kỳ tự động), phải dùng trigger ngoài (như EventBridge) để start state machine – tăng effort và cost (state transitions $0.025/1k). Không invoke "execution role" trực tiếp như mô tả (sai kỹ thuật), không least effort.

• Provision a small Amazon EC2 instance. Set up a cron job that invokes the Lambda function every 15 minutes.
  ❌ Sai 🖥️. Đây là giải pháp truyền thống, không serverless – phải provision/maintain EC2 (tự động hóa AMI, patching, scaling), cài cron job với AWS CLI/SDK. Tốn effort cao (quản lý OS, security), chi phí liên tục (EC2 chạy idle), không scalable và contradict với ứng dụng serverless gốc.

🏅 Kết luận và khuyến nghị

Giải pháp EventBridge là optimal choice cho serverless scheduling, đảm bảo reliability cao (99.99% SLA) và least operational overhead. Nếu triển khai thực tế, dùng AWS CDK để provision rule tự động. Test bằng AWS Console để verify invocation logs trong CloudWatch Logs!

📚 Nguồn bổ sung: AWS re:Invent 2025 sessions về EventBridge (video trên AWS Events) và Serverless Land: Lambda Scheduling Patterns.

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

Câu hỏi tập trung vào việc triển khai đo lường thời gian xử lý ảnh trên một ứng dụng chạy trên Amazon EC2 instance và gửi thông báo cho đội ngũ phát triển nếu thời gian xử lý vượt quá 5 giây, với yêu cầu ít nhất overhead vận hành (LEAST operational overhead).

📌 Yêu cầu chính:

• Ứng dụng xử lý từng ảnh riêng lẻ, cần đo thời gian chính xác cho mỗi ảnh (<5 giây).
• Nếu bất kỳ ảnh nào >5 giây → thông báo ngay lập tức cho dev team.
• Least operational overhead: Nghĩa là giải pháp phải tự động hóa cao, không cần quản lý thêm server, queue, stream hoặc ứng dụng custom phức tạp, tận dụng dịch vụ managed của AWS để giảm công quản lý.

🛠️ Bối cảnh AWS: Sử dụng CloudWatch để theo dõi metrics (bao gồm custom metrics), alarms với threshold tĩnh, và SNS cho notifications là cách chuẩn mực, serverless, chi phí thấp (cập nhật đến AWS 2026: CloudWatch hỗ trợ custom metrics với độ phân giải cao 1 giây, alarms real-time).

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

Đáp án đúng: Create an Amazon CloudWatch custom metric. Each time a photo is processed, publish the processing time as a metric value. Create a CloudWatch alarm that is based on a static threshold of 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.

Lý do chọn 🏆:

• Least overhead: CloudWatch là dịch vụ fully managed, không cần code thêm app consume hay quản lý queue/stream. Chỉ cần publish metric từ code app (ví dụ: dùng AWS SDK put_metric_data) mỗi lần xử lý ảnh → alarm tự động trigger nếu metric >5s (static threshold đảm bảo phát hiện mỗi ảnh riêng lẻ, không average).
• Chính xác: Static threshold trên individual metric values (không average) → phát hiện ngay >5s.
• Notification: SNS topic là serverless push notification, hỗ trợ email/SMS/Slack, low latency.
• Cập nhật AWS 2026: CloudWatch custom metrics hỗ trợ Contributor Insights và real-time alarms (1s resolution), tối ưu cho workload real-time như xử lý ảnh.

📋 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 nội dung gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với đánh giá đúng/sai:

✅ Phương án đúng (như đã nêu ở trên):
Create an Amazon CloudWatch custom metric. Each time a photo is processed, publish the processing time as a metric value. Create a CloudWatch alarm that is based on a static threshold of 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.
Giải thích: Hoàn hảo vì tự động, managed hoàn toàn. Publish metric đơn giản (1 API call), static threshold phát hiện per photo (không aggregate), SNS notify real-time. Overhead thấp nhất: không code thêm, scale tự động.

❌ Phương án sai 1:
Create an Amazon Simple Queue Service (Amazon SQS) queue. Each time a photo is processed, publish the processing time to the queue. Create an application to consume from the queue and to determine whether any values are more than 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.
Giải thích: Overhead cao vì cần deploy ứng dụng riêng (EC2/Lambda) để poll/consumer queue liên tục → quản lý scaling, error handling, chi phí compute. SQS chỉ là queue messaging, không phải monitoring tool → không "least overhead". Phù hợp batch processing, không real-time per photo.

❌ Phương án sai 2:
Create an Amazon CloudWatch custom metric. Each time a photo is processed, publish the processing time as a metric value. Create a CloudWatch alarm that enters ALARM state if the average of values is greater than 5 seconds. Notify the development team by sending an Amazon Simple Email Service (Amazon SES) message.
Giải thích: Không chính xác vì dùng average threshold → chỉ alarm nếu trung bình >5s (ví dụ: 10 ảnh, 9 ảnh 1s + 1 ảnh 10s → average 1.9s, không báo dù có ảnh chậm). Cần static per value cho per photo. SES là email service, cần config domain/DKIM phức tạp → overhead cao hơn SNS (SNS managed topics, multi-channel).

❌ Phương án sai 3:
Create an Amazon Kinesis data stream. Each time a photo is processed, publish the processing time to the data stream. Create an Amazon CloudWatch alarm that enters ALARM state if any values are more than 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.
Giải thích: Overhead cao vì Kinesis là streaming data (shard management, retention, throughput provisioning) → phức tạp cho simple metric publishing. CloudWatch không trực tiếp alarm trên Kinesis stream values (cần Lambda/Kinesis Analytics trung gian để push metrics) → thêm layer, không "least". Phù hợp high-volume streams, không per-photo monitoring.

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

• CloudWatch Custom Metrics & Alarms: Amazon CloudWatch User Guide - Publishing Custom Metrics & Static Threshold Alarms (hỗ trợ 1s resolution từ 2023).
• SNS Notifications: Amazon SNS Developer Guide.
• Exam Tips DOP-C02: AWS Well-Architected Framework - Operational Excellence pillar ưu tiên managed services như CloudWatch cho monitoring (Least overhead).
• Best Practice: AWS re:Post & Blogs: "Monitoring EC2 with Custom Metrics" (2025 updates cho real-time photo processing workloads).

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 publish metric, hãy hỏi nhé!

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

Câu hỏi tập trung vào AWS Elastic Beanstalk – dịch vụ quản lý ứng dụng web chạy trên Amazon EC2 instances. Một developer cần thực hiện thay đổi cấu hình (configuration changes) và deploy chỉ đến các instances mới (new instances only), nghĩa là không ảnh hưởng hoặc cập nhật trực tiếp lên các instances đang chạy hiện tại.

Yêu cầu chọn hai loại deployment policy trong Elastic Beanstalk hỗ trợ điều này. Elastic Beanstalk cung cấp các deployment strategies để kiểm soát cách cập nhật ứng dụng, giảm thiểu downtime và rủi ro. Các policy này được cấu hình qua .ebextensions hoặc console/CLI, và phiên bản mới nhất (tính đến 2026) vẫn giữ nguyên các option chính như Immutable và Blue/Green để đảm bảo zero-downtime với new instances. 📘

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

• Immutable
• Blue/green

Lý do lựa chọn: Hai phương án này đảm bảo deploy hoàn toàn lên new instances (tạo ASG hoặc environment mới), kiểm tra trước khi switch traffic, và terminate old instances sau. Không chạm vào running instances hiện tại, phù hợp yêu cầu "new instances only". Điều này giúp zero-downtime và dễ rollback. 🛠️ Theo AWS best practices cho production environments.

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

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

• All at once ❌
  Phương án này deploy đồng thời lên tất cả instances hiện tại, gây downtime ngắn và rủi ro cao nếu lỗi. Không tạo new instances riêng, vi phạm yêu cầu "new instances only".

• Immutable ✅
  Elastic Beanstalk tạo new Auto Scaling Group (ASG) với instances mới, deploy version mới lên đó, test health, rồi thay thế toàn bộ fleet cũ một cách atomic. Running instances không bị cập nhật trực tiếp – lý tưởng cho config changes lớn, zero-impact đến production traffic ban đầu.

• Rolling ❌
  Deploy theo batch trên các instances hiện tại, thay thế dần dần (ví dụ: batch size 25%). Các instances đang chạy bị cập nhật trực tiếp, có thể gây partial downtime hoặc inconsistency, không đáp ứng "new instances only".

• Blue/green ✅
  Tạo một environment mới hoàn toàn (green) song song với environment cũ (blue), deploy changes lên new instances ở green env. Sau test, swap CNAME records để chuyển traffic. Old instances giữ nguyên đến khi terminate thủ công – hoàn hảo cho "new instances only" và dễ rollback.

• Rolling with additional batch ❌
  Tạo batch instances bổ sung mới để deploy version mới, thêm vào load balancer, rồi terminate batch cũ dần. Mặc dù dùng new instances, nhưng vẫn tích hợp vào ASG hiện tại và shift traffic dần, có thể ảnh hưởng indirect đến existing instances qua load balancing, không pure "new instances only" như Immutable/Blue-green.

📚 Tài liệu tham khảo

• AWS Elastic Beanstalk Deployment Policies: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.rolling-version-deploy.html (Immutable & Rolling details).
• Blue/Green Deployments: https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/environment-mgmt-bluegreendeploy.html.
• AWS DOP-C02 Exam Guide (2023-2026): Xác nhận Immutable & Blue/Green cho zero-impact deployments.
  (Kiến thức cập nhật từ AWS re:Invent 2025 – không thay đổi core policies này). 🚀

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

Câu hỏi tập trung vào việc mã hóa dữ liệu tại chỗ (encryption at rest) cho bảng Amazon DynamoDB lưu trữ đơn hàng khách hàng (customer orders). Yêu cầu cụ thể:

• Tất cả dữ liệu khách hàng phải được mã hóa tại chỗ bằng khóa mã hóa (key) do chính công ty của developer tạo ra (company generates).
• Developer cần chọn giải pháp phù hợp để đáp ứng yêu cầu này một cách tự động, an toàn và tích hợp native với DynamoDB, mà không yêu cầu mã hóa thủ công từ ứng dụng.

📘 Kiến thức nền tảng (cập nhật AWS 2026):

• DynamoDB hỗ trợ mã hóa tại chỗ mặc định (default encryption at rest) bằng AWS-owned hoặc AWS-managed keys từ năm 2018, và từ 2023 trở đi, tất cả bảng mới đều được mã hóa mặc định.
• Để sử dụng khóa tùy chỉnh do khách hàng tạo (customer-generated key), phải dùng Customer Managed Key (CMK) trong AWS KMS. AWS-managed key không đáp ứng vì không do company generate.
• Khi tạo bảng, chỉ định ARN của KMS CMK qua tham số ServerSideEncryptionSpecification (SSESpecification).

Nguồn tham khảo:

• AWS DynamoDB Encryption at Rest (cập nhật 2025).
• AWS KMS Customer Managed Keys (cập nhật 2026).
• AWS Well-Architected Framework: Security Pillar (2025 edition).

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

Đáp án đúng: Store the key by using AWS Key Management Service (AWS KMS). Choose an AWS KMS customer managed key during creation of the DynamoDB table. Provide the Amazon Resource Name (ARN) of the AWS KMS key.

Lý do:

• Phương án này hoàn toàn đáp ứng yêu cầu: Lưu trữ khóa trong KMS (an toàn, quản lý vòng đời tự động 🛠️), sử dụng Customer Managed Key (CMK) do company tạo (generate key material), và chỉ định ARN khi tạo bảng DynamoDB.
• DynamoDB sẽ tự động mã hóa tất cả dữ liệu tại chỗ bằng CMK này, không cần can thiệp code ứng dụng. Đây là cách native, tuân thủ best practice AWS (zero-effort encryption).
• ✅ Hoàn hảo cho DevOps: Tích hợp IAM policies cho KMS key usage, audit qua CloudTrail.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, chỉ giải thích bằng tiếng Việt với emoji đánh dấu.

• ❌ Phương án SAI: Create the DynamoDB table with encryption set to None. Code the application to use the key to decrypt the data when the application reads from the table. Code the application to use the key to encrypt the data when the application writes to the table.
  Giải thích sai: Tắt mã hóa native (encryption None) và ép ứng dụng tự mã hóa/giải mã (client-side encryption) là cách thủ công, phức tạp, dễ lỗi 🧩. Không đáp ứng "encrypted at rest" native của DynamoDB (dữ liệu lưu trữ plain-text trên đĩa nếu app crash). Vi phạm best practice AWS, tăng tải CPU app và không scalable.

• ✅ Phương án ĐÚNG: Store the key by using AWS Key Management Service (AWS KMS). Choose an AWS KMS customer managed key during creation of the DynamoDB table. Provide the Amazon Resource Name (ARN) of the AWS KMS key.
  Giải thích đúng: Như đã nêu ở phần trên. Sử dụng CMK (do company generate key material), chỉ định ARN qua API CreateTable (SSESpecification.KMSMasterKeyId). DynamoDB quản lý toàn bộ quá trình mã hóa tự động, hỗ trợ rotation key hàng năm. Lý tưởng cho compliance (GDPR, PCI-DSS) 📘.

• ❌ Phương án SAI: Store the key by using AWS Key Management Service (AWS KMS). Create the DynamoDB table with default encryption. Include the kms:Encrypt parameter with the Amazon Resource Name (ARN) of the AWS KMS key when using the DynamoDB software development kit (SDK).
  Giải thích sai: Default encryption dùng AWS-managed key (không do company generate). kms:Encrypt là IAM policy action cho quyền truy cập KMS, không ảnh hưởng đến SSE của bảng DynamoDB. SDK chỉ dùng cho API calls, không thay đổi cấu hình table encryption. Sai hoàn toàn về cơ chế 🛠️.

• ❌ Phương án SAI: Store the key by using AWS Key Management Service (AWS KMS). Choose an AWS KMS AWS managed key during creation of the DynamoDB table. Provide the Amazon Resource Name (ARN) of the AWS KMS key.
  Giải thích sai: AWS-managed key (như alias/aws/dynamodb) do AWS tạo và quản lý hoàn toàn, KHÔNG do company generate. Company chỉ có quyền sử dụng hạn chế, không kiểm soát key material hay rotation. Không đáp ứng yêu cầu "key that the company generates". CMK mới là lựa chọn đúng ở đây.

Kết luận 💡: Chọn đáp án đúng giúp triển khai nhanh qua CDK/Terraform, với chi phí KMS ~$1/key/tháng + API calls. Nếu cần scale, kết hợp DynamoDB Accelerator (DAX) vẫn giữ encryption!

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

Câu hỏi xoay quanh việc triển khai ứng dụng trên AWS sử dụng AWS CloudFormation để deploy một ứng dụng kết hợp Amazon API Gateway REST API (tích hợp với AWS Lambda) và Amazon DynamoDB làm nơi lưu trữ dữ liệu. Ứng dụng có ba môi trường (stages): development (dev), testing (test), và production (prod). Mỗi stage sử dụng bảng DynamoDB riêng biệt để tránh xung đột dữ liệu.

🔍 Vấn đề chính: Công ty gặp lỗi bất ngờ khi promote (thăng cấp) thay đổi từ dev/test lên prod, dù thành công ở các stage trước. Developer cần giải pháp để next production release route 20% traffic đến API prod mới (với thay đổi), và 80% traffic đến API prod hiện tại. Yêu cầu quan trọng: Giảm thiểu số lỗi mà bất kỳ khách hàng cá nhân nào gặp phải (minimize errors for single customer), nghĩa là tránh tình trạng một user bị ảnh hưởng nặng (ví dụ: sticky routing hoặc canary để test dần dần).

🛠️ Mục tiêu: Cần một cơ chế canary deployment hoặc traffic shifting an toàn, native với API Gateway, hỗ trợ CloudFormation, và cập nhật theo phiên bản AWS mới nhất (2024-2026: API Gateway vẫn hỗ trợ Canary cho REST API với traffic shifting % chính xác).

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

• AWS API Gateway Canary Deployments: docs.aws.amazon.com/apigateway/latest/developerguide/canary-deployment.html
• AWS Well-Architected Framework - DevOps Pillar (2024): Nhấn mạnh canary/blue-green cho zero-downtime.

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

Đáp án đúng: Configure canary settings for the production stage API. Change the percentage of traffic directed to canary deployment to 20%. Make the planned updates to the production stage. Deploy the changes.

Lý do chọn 🏆:

• API Gateway REST API native hỗ trợ Canary deployments từ lâu (vẫn cập nhật 2026), cho phép deploy version mới như "canary" và route chính xác % traffic (đây là 20%) đến nó, trong khi 80% đi version cũ.
• Giảm thiểu lỗi single customer: Canary sử dụng sticky routing dựa trên request headers/cookies, đảm bảo một user luôn route đến cùng version (tránh flip-flop gây lỗi).
• Tích hợp hoàn hảo với CloudFormation (sử dụng DeploymentCanarySettings), không cần tool ngoài, zero-downtime, và dễ monitor qua CloudWatch/ X-Ray.
• Phù hợp yêu cầu: Deploy thay đổi vào prod stage với canary 20%, test dần, promote full nếu OK.

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

• Phương án A: Update 20% of the planned changes to the production stage. Deploy the new production stage. Monitor the results. Repeat this process five times to test all planned changes.
  ❌ Sai vì: Đây là cách manual và không scale, chỉ update "20% changes" (không phải traffic), lặp 5 lần gây downtime lặp lại, không route traffic %, và không minimize single customer errors (user có thể gặp lỗi random). Không native AWS, vi phạm best practice DevOps.

• Phương án B: Update the Amazon Route 53 DNS record entry for the production stage API to use a weighted routing policy. Set the weight to a value of 80. Add a second record for the production domain name. Change the second routing policy to a weighted routing policy. Set the weight of the second policy to a value of 20. Change the alias of the second policy to use the testing stage API.
  ❌ Sai vì: Route 53 weighted routing chỉ hoạt động ở DNS level (TTL-based, ~1-5 phút propagate), gây inconsistency cho single user (user có thể switch version giữa requests). Hơn nữa, dùng testing stage thay vì new prod (không đúng yêu cầu), và API Gateway stages có domain riêng (như api-id.execute-api.region.amazonaws.com/stage), phức tạp alias. Không sticky, tăng lỗi customer.

• Phương án C: Deploy an Application Load Balancer (ALB) in front of the REST API. Change the production API Amazon Route 53 record to point traffic to the ALB. Register the production and testing stages as targets of the ALB with weights of 80% and 20%, respectively.
  ❌ Sai vì: ALB không native hỗ trợ API Gateway REST API làm target (API Gateway là HTTP proxy, ALB target cần IP/port chuẩn; dùng custom domain phức tạp). Lại dùng testing stage (không phải new prod), ALB weight routing không sticky (dựa session cookie tùy chỉnh, nhưng không minimize single errors tốt bằng canary). Thêm chi phí, latency, và không tích hợp CloudFormation dễ dàng.

• Phương án D (Đúng, như đã nêu trên): Configure canary settings for the production stage API. Change the percentage of traffic directed to canary deployment to 20%. Make the planned updates to the production stage. Deploy the changes.
  ✅ Đúng vì: Như giải thích ở phần đáp án, đây là giải pháp native, an toàn nhất cho API Gateway REST API, hỗ trợ CloudFormation template với CanarySettings: { PercentTraffic: 20, StageVariableOverrides: {...} }. Dễ rollback, monitor real-time, và zero-impact cho 80% traffic.

🧪 Lời khuyên thực hành: Trong CloudFormation, thêm DeploymentCanarySettings vào AWS::ApiGateway::Deployment. Test với CloudWatch alarms cho canary metrics (5xx errors, latency). Nâng cao: Kết hợp AWS AppConfig hoặc CodeDeploy cho Lambda canary nếu cần!