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 quản lý credentials (tài khoản truy cập) cho một ứng dụng chạy trên Amazon EC2 instances kết nối đến Amazon RDS for SQL Server. Yêu cầu chính là:

• Lưu trữ và truy cập credentials một cách an toàn nhất (MOST secure).
• Tự động xoay vòng (rotate) credentials định kỳ để tăng bảo mật.
• Không lưu credentials trực tiếp trong code (tránh hardcode, giảm rủi ro lộ thông tin).

🔍 Bối cảnh chi tiết:

• EC2 cần kết nối đến RDS SQL Server qua username/password (SQL Server không hỗ trợ IAM database authentication như MySQL/PostgreSQL).
• Giải pháp phải hỗ trợ retrieve động credentials khi cần, tích hợp rotation tự động (thay đổi mật khẩu định kỳ mà không gián đoạn app), và tuân thủ best practices bảo mật AWS (zero-trust model, least privilege).
• Theo kiến thức AWS cập nhật đến 2026, AWS Secrets Manager là dịch vụ chuyên dụng cho secrets với rotation built-in cho RDS (bao gồm SQL Server), tích hợp Lambda và caching để tránh downtime.

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

Đáp án đúng: Store the credentials as secrets in AWS Secrets Manager. Create an AWS Lambda function to update the secrets and the database. Retrieve the credentials from Secrets Manager as needed.

Lý do chọn 🛡️:

• Đây là giải pháp MOST secure vì AWS Secrets Manager được thiết kế chuyên biệt cho việc lưu trữ, quản lý và rotate secrets với encryption tại chỗ (KMS-managed), audit logs qua CloudTrail, và fine-grained IAM permissions.
• Rotation tự động: Secrets Manager hỗ trợ Lambda rotation function built-in hoặc custom cho RDS SQL Server – tự động cập nhật secret trong Secrets Manager VÀ thay đổi password trên RDS mà không downtime (app retrieve mới nhất mỗi lần).
• Retrieve động: EC2 app dùng Secrets Manager API (qua IAM role) để fetch secrets runtime, không lưu trữ lâu dài.
• Tuân thủ AWS Well-Architected Framework (Security Pillar): Giảm attack surface, automatic rotation (mặc định 30 ngày), VPC endpoint hỗ trợ private access.

📋 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. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên bảo mật, tính khả thi và best practices AWS 2026.

• ❌ SAI: Create an IAM role that has permissions to access the database. Attach the IAM role to the EC2 instances.
  Giải thích: IAM role chỉ cấp quyền truy cập AWS services (như RDS API), KHÔNG cung cấp username/password cho kết nối SQL client đến RDS SQL Server. SQL Server không hỗ trợ IAM database authentication (chỉ MySQL, PostgreSQL, MariaDB, Aurora). Không rotate credentials, vi phạm yêu cầu chính. Rủi ro: App vẫn cần hardcode creds hoặc fail kết nối.

• ✅ ĐÚNG: Store the credentials as secrets in AWS Secrets Manager. Create an AWS Lambda function to update the secrets and the database. Retrieve the credentials from Secrets Manager as needed.
  Giải thích: Như phần đáp án đúng ở trên – giải pháp chuẩn AWS, hỗ trợ rotation đầy đủ cho RDS SQL Server qua Lambda (template có sẵn). Secure nhất với caching, versioning secrets, và integration EC2 IAM role gọi GetSecretValue. Không lưu trong code, retrieve on-demand.

• ❌ SAI: Store the credentials in an encrypted text file in an Amazon S3 bucket. Configure the EC2 instance launch template to download the credentials from Amazon S3 as the instance launches. Create an AWS Lambda function to update the secrets and the database.
  Giải thích: Dù S3 encrypt (SSE-KMS), việc lưu file text trên S3 và download lúc launch tạo rủi ro: Credentials lưu trữ lâu dài trên disk EC2 (dễ leak nếu instance compromise), không retrieve động (phải restart/relaunch để update). Rotation Lambda phức tạp, không atomic như Secrets Manager. Kém secure hơn, vi phạm principle of ephemeral secrets.

• ❌ SAI: Store the credentials in an Amazon DynamoDB table. Configure an Amazon CloudWatch Events rule to invoke an AWS Lambda function to periodically update the secrets and database.
  Giải thích: DynamoDB không phải secrets store – dù có encryption (DynamoDB Encryption Library), thiếu built-in rotation, versioning, caching như Secrets Manager. Lưu plaintext/encrypted items dễ bị truy cập rộng (scan/query), audit kém (không CloudTrail integration secrets-specific). CloudWatch Events + Lambda thủ công, dễ lỗi, không secure bằng managed service.

📘 Tài liệu tham khảo

• AWS Secrets Manager Rotation for RDS: docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets-tutorial-rds.html (hỗ trợ SQL Server, Lambda templates cập nhật 2025).
• RDS SQL Server IAM Auth: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html (xác nhận KHÔNG hỗ trợ SQL Server).
• AWS Well-Architected Security Pillar: docs.aws.amazon.com/wellarchitected/latest/security-pillar (recommend Secrets Manager cho credentials).
• Exam Topic DOP-C02 (2026 version): Secrets Management trong DevOps Professional.

🛠️ Lời khuyên: Trong thực tế, kết hợp với Parameter Store (SSM) cho non-sensitive, nhưng Secrets Manager ưu tiên cho DB creds với rotation!

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

Câu hỏi xoay quanh một công ty đang triển khai ứng dụng web bằng AWS CloudFormation với các stack riêng biệt cho từng môi trường (như dev, staging, preprod, prod). Họ sử dụng cùng một template CloudFormation để deploy qua các giai đoạn lifecycle phát triển, giúp kiểm soát phiên bản hóa và tự động hóa.

Mục tiêu chính: Developer cần thiết lập thông báo (notifications) tự động cho team QA chỉ khi có deployments mới (new deployments) ở môi trường pre-production cuối cùng (final preproduction environment). Điều này giúp QA test ứng dụng thường xuyên hơn mà không bỏ lỡ các bản deploy quan trọng trước khi lên production.

Yêu cầu cốt lõi: Giải pháp phải tích hợp trực tiếp với CloudFormation, chỉ trigger ở stack preprod cụ thể, và gửi thông báo đến QA team một cách đơn giản, đáng tin cậy. Không cần theo dõi metrics phức tạp hay custom logic, vì đây là sự kiện deploy stack (như UPDATE_COMPLETE).

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

• AWS CloudFormation Stack Notifications – Hỗ trợ gửi events đến SNS.
• CloudFormation Events in EventBridge – Giải thích CFN events chỉ stream nếu cấu hình đúng.

✅ Đáp án đúng: Phương án đầu tiên

Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the QA team to the Amazon SNS topic. Update the CloudFormation stack options to point to the SNS topic in the pre-production environment.

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

• CloudFormation hỗ trợ tham số NotificationARNs khi create/update stack, cho phép gửi tất cả stack events (bao gồm CREATE_IN_PROGRESS, UPDATE_COMPLETE, v.v.) trực tiếp đến SNS topic.
• Chỉ cần subscribe email/SMS của QA team vào SNS topic, họ sẽ nhận thông báo ngay khi deploy mới ở preprod hoàn tất.
• Đơn giản, native: Không cần Lambda hay rule phức tạp; chỉ update stack options (qua CLI, SDK, hoặc CI/CD) để point đến SNS ở preprod. Hoạt động với cùng template, chỉ khác ARN stack.
• Phù hợp nhất cho "new deployments" vì trigger trên stack events realtime, không phụ thuộc metrics hay polling.

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

• ✅ Phương án ĐÚNG (như trên):
  Create an Amazon Simple Notification Service (Amazon SNS) topic. Subscribe the QA team to the Amazon SNS topic. Update the CloudFormation stack options to point to the SNS topic in the pre-production environment.
  🟢 Giải thích: Đây là giải pháp chuẩn AWS cho CloudFormation notifications. Stack events được push trực tiếp đến SNS mà không cần trung gian, đảm bảo thông báo cho QA chỉ ở preprod. Hiệu quả cao, chi phí thấp, và scale tốt đến 2026.

• ❌ Phương án SAI 1:
  Create an AWS Lambda function that notifies the QA team. Create an Amazon EventBridge rule to invoke the Lambda function on the default event bus. Filter the events on the CloudFormation service and on the CloudFormation stack Amazon Resource Name (ARN).
  🔴 Giải thích: CloudFormation không tự động publish events đến EventBridge default bus. Events chỉ stream vào EventBridge nếu đã cấu hình NotificationARNs (qua SNS), hoặc dùng custom bus. Filter ARN hoạt động nhưng cần setup trước; nếu không, rule sẽ không trigger gì. Phức tạp hơn SNS native, không "out-of-box".

• ❌ Phương án SAI 2:
  Create an Amazon CloudWatch alarm that monitors the metrics from CloudFormation. Filter the metrics on the stack name and the stack status. Configure the CloudWatch alarm to notify the QA team.
  🔴 Giải thích: CloudFormation không có CloudWatch metrics chi tiết cho stack events như "deploy mới" hay status changes. Metrics CFN chỉ cơ bản (như số stack active), không filter theo stack name/status realtime. Alarms dùng cho threshold (ví dụ: CPU), không phù hợp notify events discrete như deployment complete. Sẽ miss notifications.

• ❌ Phương án SAI 3:
  Create an AWS Lambda function that notifies the QA team. Configure the event source mapping to receive events from CloudFormation. Specify the filtering values to limit invocations to the desired CloudFormation stack.
  🔴 Giải thích: Event source mapping của Lambda chỉ hỗ trợ polling sources như S3, DynamoDB, Kinesis – không hỗ trợ CloudFormation (CFN là push-based events, không stream trực tiếp). Không có filtering values cho CFN stack. Giải pháp này không khả thi, sẽ lỗi khi setup.

🏆 Kết luận: Giải pháp SNS + NotificationARNs là best practice DevOps cho CI/CD notifications trên CloudFormation, giúp automate QA testing pipeline hiệu quả! 🚀

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

Câu hỏi tập trung vào việc quản lý người dùng (users) trong các cơ sở dữ liệu Amazon RDS một cách nhất quán (consistent) trên ba AWS accounts riêng biệt. Mỗi account có một RDS DB instance nằm trong private subnet, nghĩa là không thể truy cập trực tiếp từ internet mà cần qua VPC peering, bastion host hoặc các cơ chế an toàn khác. Yêu cầu chính là:

• Tạo và cập nhật users giống hệt nhau ở tất cả ba databases.
• Giải pháp phải có operational efficiency cao nhất (ít công sức vận hành nhất), ưu tiên tự động hóa, dễ scale và maintain (Infrastructure as Code - IaC).

Thách thức chính 📌: AWS CloudFormation (CFN) không hỗ trợ native việc tạo hoặc quản lý DB users thông thường trong RDS (chỉ hỗ trợ master user qua DBParameterGroup hoặc snapshot). Do đó, cần cơ chế mở rộng để tự động hóa việc này cross-account mà không cần manual intervention. Giải pháp phải deploy được ở từng account để tránh cross-account access phức tạp (như IAM roles, VPC peering).

Kiến thức AWS cập nhật đến 2026 🛠️: Theo AWS re:Post và docs mới nhất (CloudFormation v6.x, RDS Multi-AZ v3+), Custom Resources trong CFN là cách chuẩn để xử lý actions không native, đặc biệt với Lambda-backed resources cho database scripting (sử dụng RDSDataService API hoặc Proxy).

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

Đáp án đúng: Create an AWS CloudFormation template that contains a custom resource to create the users in the database. Deploy the template in each account.

Lý do 🎯:

• Operational efficiency cao nhất vì sử dụng IaC (CloudFormation StackSets hoặc manual deploy): Deploy một lần template ở mỗi account → tự động tạo/update users qua Custom Resource (thường backed by Lambda function gọi SQL scripts via AWS Secrets Manager/RDS Proxy).
• Nhất quán tuyệt đối: Mọi thay đổi (add/update user) chỉ edit template một nơi, redeploy → propagate everywhere.
• An toàn cho private subnet: Custom Resource chạy trong cùng VPC/account, kết nối RDS qua IAM DB auth hoặc Proxy, không cần cross-account.
• Tiết kiệm chi phí/vận hành: Không cần EC2/Lambda riêng, tự động hóa full lifecycle (create/update/delete).
• Best practice DevOps theo AWS Well-Architected Framework (Operational Excellence pillar).

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

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

• Create an AWS CloudFormation template. Declare the users in the template. Attach the users to the database. Deploy the template in each account.
  ❌ Sai vì CloudFormation không hỗ trợ native declare/attach DB users trong RDS resources (AWS::RDS::DBInstance chỉ quản lý instance-level, không có schema/user props). Nếu cố declare, stack sẽ fail validation. Không efficient vì phải manual SQL sau deploy, không consistent khi update. (Không đạt MOST efficiency so với custom resource).

• Create an AWS CloudFormation template that contains a custom resource to create the users in the database. Deploy the template in each account.
  ✅ Đúng (như đã giải thích ở trên). Custom Resource (AWS::CloudFormation::CustomResource) gọi Lambda handler chạy SQL script (qua rds-data API hoặc SSM), đảm bảo idempotent (chỉ tạo nếu chưa tồn tại). Deploy via StackSets cho multi-account tự động. Hiệu quả cao nhất 🏆.

• Write a script that creates the users. Deploy an Amazon EC2 instance in each account to run the script on the databases. Run the script in each account.
  ❌ Sai vì operational overhead cao: Quản lý 3 EC2 instances (patch, scale, cost ~$0.1/giờ/instance), script manual cron/job → dễ lỗi, khó consistent/update (phải SSH/copy script mỗi nơi). Không IaC, vi phạm DevOps principles. Private subnet cần Security Group/VPC config thêm phức tạp.

• Implement an AWS Lambda function that creates the users in the database. Provide the function with the details of all three accounts.
  ❌ Sai vì cross-account access khó khăn và kém an toàn: Lambda ở 1 account không dễ connect RDS private subnet ở accounts khác (cần VPC peering + IAM cross-account roles + endpoint policies). Dễ fail scalability, không idempotent tự nhiên, và update phải trigger manual. Không efficient cho multi-account (AWS khuyến nghị account isolation).

📘 Tài liệu tham khảo

• AWS Docs - CloudFormation Custom Resources: docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html (cập nhật 2025, ví dụ Lambda-backed cho DB ops).
• RDS User Management: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html (IAM DB auth cho scripting).
• AWS re:Invent 2025 - DOP302: Session về IaC multi-account với Custom Resources (YouTube/transcript).
• Well-Architected Framework: Operational Excellence (trang 45-50, IaC best practices).

Kết luận 🚀: Giải pháp B là DevOps gold standard cho scenario này, dễ audit via CloudTrail và CloudFormation events! Nếu cần template sample, tôi có thể hướng dẫn thêm.

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

Câu hỏi mô tả một công ty đang xây dựng ứng dụng mới trên AWS, sử dụng Amazon API Gateway để expose các API. Các team developer làm việc song song trên các thành phần khác nhau. Yêu cầu chính là publish một API mà KHÔNG cần backend thực tế (integrated backend), nhằm cho phép các team phụ thuộc vào backend API có thể tiếp tục phát triển dựa trên API đó, ngay cả khi backend chưa hoàn thành.

📌 Mục tiêu cốt lõi: Tạo API "giả" (mock) để hỗ trợ phát triển song song (parallel development), tránh blocking. Điều này thường dùng trong mô hình contract-first API development, nơi frontend hoặc client dev có thể test dựa trên API spec mà không cần backend thật. API Gateway hỗ trợ tính năng Mock Integration chính xác cho trường hợp này, trả về response cố định với HTTP status code mà không gọi backend nào.

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

Đáp án đúng: Create API Gateway resources and set the integration type value to MOCK. Configure the method integration request and integration response to associate a response with an HTTP status code. Create an API Gateway stage and deploy the API.

Lý do chi tiết 🛠️:

• Mock Integration là tính năng native của API Gateway (từ phiên bản 2015 và vẫn cập nhật đến 2026), cho phép tạo API hoàn chỉnh mà KHÔNG cần backend thực. Bạn chỉ cần config resources/methods, set integration type = MOCK, rồi định nghĩa integration request/response để map response giả (ví dụ: JSON mock data) với các HTTP status code (200, 400, 500...).
• Sau đó, tạo stage và deploy để publish API ngay lập tức. Các client có thể gọi API và nhận response mock, giúp dev song song mà không phụ thuộc backend.
• Giải pháp này tiết kiệm chi phí (không tốn Lambda/EC2), đơn giản, và chuẩn AWS best practice cho mocking APIs.

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

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

• ✅ Create API Gateway resources and set the integration type value to MOCK. Configure the method integration request and integration response to associate a response with an HTTP status code. Create an API Gateway stage and deploy the API.
  Giải thích đúng: Như đã nêu ở trên, đây là cách chuẩn xác nhất. Mock integration không yêu cầu backend, chỉ config request/response mapping để trả response tĩnh. Deploy stage để publish ngay. Hoàn hảo cho yêu cầu "no integrated backend".

• ❌ Create an AWS Lambda function that returns mocked responses and various HTTP status codes. Create API Gateway resources and set the integration type value to AWS_PROXY. Deploy the API.
  Giải thích sai: Phương án này vẫn cần backend thực (Lambda function phải tạo và deploy trước). Integration type AWS_PROXY (hay Lambda Proxy) yêu cầu Lambda thật để xử lý request và return response. Không đáp ứng "without an integrated backend" vì Lambda chính là backend. Thêm chi phí và phức tạp không cần thiết so với Mock.

• ❌ Create an EC2 application that returns mocked HTTP responses. Create API Gateway resources and set the integration type value to AWS. Create an API Gateway stage and deploy the API.
  Giải thích sai: Hoàn toàn không phù hợp. Integration type AWS dùng cho AWS services native như DynamoDB, SQS, không phải EC2 (EC2 cần HTTP hoặc VPC_LINK). EC2 app là backend thực tế (phải quản lý instance, scaling), vi phạm yêu cầu "no integrated backend". Sai cả về type integration và tăng chi phí quản lý infra.

• ❌ Create API Gateway resources and set the integration type value set to HTTP_PROXY. Add mapping templates and deploy the API. Create an AWS Lambda layer that returns various HTTP status codes. Associate the Lambda layer with the API deployment.
  Giải thích sai: Nhiều lỗi chồng chéo. HTTP_PROXY dùng cho HTTP endpoint bên ngoài (như web server), không phải mock. Mapping templates chỉ hỗ trợ transform data, không tạo response giả độc lập. Lambda layer là code reuse cho Lambda functions, KHÔNG associate trực tiếp với API deployment (layer chỉ dùng trong Lambda runtime). Không có backend HTTP thật nên không work, và không phải mock native.

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

• Mock Integrations chính thức: Set up mock integrations in API Gateway – Hướng dẫn chi tiết config MOCK.
• API Gateway Integrations Overview: Choose an integration type for HTTP APIs – So sánh MOCK vs Proxy/AWS/HTTP.
• Best Practices DevOps: AWS Well-Architected Framework - Reliability Pillar: Sử dụng mock cho CI/CD pipelines.
• Exam Prep DOP-C02: Topic "API Gateway" trong blueprint AWS Certified DevOps Engineer Professional (2023-2026).

Giải pháp này giúp team dev tối ưu workflow! 🚀 Nếu cần demo code Terraform/CLI, 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 một ứng dụng chạy trên AWS, nhận tin nhắn (messages) từ một hàng đợi Amazon SQS (queue), xử lý chúng theo lô (batches), sau đó gửi dữ liệu sang một hàng đợi SQS khác để hệ thống legacy (hệ thống cũ) tiêu thụ và xử lý. Hệ thống legacy có thể mất tối đa 5 phút để xử lý một số dữ liệu giao dịch (transaction data).

Yêu cầu chính: Đảm bảo không có cập nhật ngoài thứ tự (no out-of-order updates) trong hệ thống legacy, mà không được thay đổi hành vi của hệ thống legacy.

🛠️ Vấn đề cốt lõi:

• Hàng đợi SQS thứ hai (dành cho legacy) phải duy trì thứ tự tin nhắn (order preservation) để legacy nhận và xử lý theo đúng thứ tự gửi.
• Thời gian xử lý dài (5 phút) đòi hỏi cấu hình phù hợp để tránh tin nhắn bị xử lý trùng lặp hoặc mất thứ tự do timeout.
• SQS có 2 loại: Standard (không đảm bảo thứ tự, at-least-once delivery) và FIFO (First-In-First-Out, đảm bảo thứ tự nghiêm ngặt và exactly-once với deduplication).

📘 Kiến thức AWS cập nhật đến 2026: SQS FIFO hỗ trợ message group ID và message deduplication ID để đảm bảo thứ tự và không trùng lặp. Visibility timeout (thời gian ẩn) phải >= thời gian xử lý để tránh consumer (legacy) poll lại tin nhắn sớm. (Nguồn: AWS SQS Documentation - FIFO queues, Visibility Timeout, cập nhật 2024-2026).

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

Đáp án đúng: Use an SQS FIFO queue. Configure the visibility timeout value.

Lý do chi tiết:

• 🧩 SQS FIFO queue đảm bảo thứ tự nghiêm ngặt (strict ordering) dựa trên message group ID, ngăn chặn out-of-order updates ở legacy. Đây là yêu cầu bắt buộc vì Standard queue không hỗ trợ thứ tự.
• 🛠️ Configure visibility timeout (>= 5 phút, tối đa 12 giờ ở FIFO) để legacy có đủ thời gian xử lý mà không bị các consumer khác "thấy" lại tin nhắn sớm, tránh xử lý trùng hoặc rối thứ tự.
• Giải pháp hoàn hảo, không cần thay đổi legacy. (Nguồn: AWS SQS FIFO Features).

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

• ✅ Use an SQS FIFO queue. Configure the visibility timeout value.
  Đúng vì: Như phân tích trên, FIFO đảm bảo thứ tự + visibility timeout khớp với thời gian xử lý 5 phút của legacy, tránh re-processing sớm. Hoàn toàn phù hợp yêu cầu.

• ❌ Use an SQS standard queue with a SendMessageBatchRequestEntry data type. Configure the DelaySeconds values.
  Sai vì: SQS Standard không đảm bảo thứ tự (messages có thể out-of-order do sharding). SendMessageBatchRequestEntry chỉ hỗ trợ gửi batch (tối đa 10 messages), DelaySeconds chỉ trì hoãn gửi tin nhắn (0-900 giây) nhưng không giải quyết thứ tự hoặc xử lý legacy. Legacy vẫn nhận out-of-order.

• ❌ Use an SQS standard queue with a SendMessageBatchRequestEntry data type. Configure the visibility timeout value.
  Sai vì: Standard queue vẫn không đảm bảo thứ tự, dù visibility timeout giúp tránh re-processing. SendMessageBatchRequestEntry chỉ là cách gửi batch, không liên quan đến ordering. Legacy dễ gặp out-of-order updates.

• ❌ Use an SQS FIFO queue. Configure the DelaySeconds value.
  Sai vì: FIFO đúng là đảm bảo thứ tự, nhưng DelaySeconds chỉ trì hoãn thời điểm tin nhắn khả dụng khi gửi (không ảnh hưởng consumer/legacy). Không giải quyết vấn đề timeout xử lý 5 phút, dẫn đến legacy poll lại tin nhắn sớm nếu visibility timeout mặc định (30 giây) quá ngắn.

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

• Amazon SQS FIFO Queues ✅ (Ordering & Deduplication).
• SQS Visibility Timeout 🛠️ (Config cho long-processing).
• SQS Standard vs FIFO.
• AWS Exam Guide DOP-C02 (DevOps Professional, 2024+): Nhấn mạnh FIFO cho ordered messaging.

Giải pháp này tối ưu chi phí và độ tin cậy cao! 🚀

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

Câu hỏi xoay quanh việc xây dựng một ứng dụng compute-intensive (yêu cầu tính toán cao) chạy trên fleet Amazon EC2 instances (nhóm các instance EC2). Ứng dụng sử dụng Amazon EBS volumes (ổ đĩa khối lưu trữ bền vững gắn trực tiếp vào EC2) để lưu trữ dữ liệu, và các volume này được tạo tại thời điểm triển khai ban đầu (initial deployment). Dữ liệu là thông tin nhạy cảm (sensitive information), nên tất cả dữ liệu phải được mã hóa (encrypted). Giải pháp phải không ảnh hưởng đến hiệu suất ứng dụng (no impact on performance).

Yêu cầu chính:

• ✅ Lưu trữ trên EBS (block storage gắn trực tiếp, phù hợp cho ứng dụng cần I/O cao).
• ✅ Mã hóa toàn bộ dữ liệu at-rest (tại chỗ lưu trữ).
• ✅ Không làm chậm ứng dụng (performance-neutral).
• 🛠️ Đây là tình huống thực tế trong AWS, nơi EBS encryption là giải pháp chuẩn cho EC2 workloads nhạy cảm dữ liệu, theo best practices AWS (cập nhật đến 2026 với Nitro System và AWS Key Management Service - KMS).

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

• Amazon EBS encryption (AWS Docs, 2024+).
• AWS Security Best Practices for EC2 (Whitepaper cập nhật 2025).

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

Đáp án đúng: Configure the fleet of EC2 instances to use encrypted EBS volumes to store data.

Lý do:

• EBS hỗ trợ mã hóa tự động (encryption by default) với AWS-managed keys hoặc customer-managed KMS keys, mã hóa dữ liệu at-rest mà không ảnh hưởng hiệu suất nhờ hardware acceleration trên Nitro-based instances (từ 2018, tối ưu đến 2026).
• Volumes được tạo lúc initial deployment, dễ cấu hình encrypted ngay từ đầu qua CloudFormation, SDK hoặc Console.
• Hoàn hảo cho sensitive data trên block storage gắn EC2, đảm bảo compliance (GDPR, HIPAA) mà transparent cho app (không cần thay đổi code).
• 🏆 Đây là giải pháp native AWS, scalable và managed, phù hợp DevOps Professional level.

📋 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. Tôi giữ nguyên nội dung văn bản gốc tiếng Anh, chỉ giải thích đúng/sai bằng tiếng Việt với lý do dựa trên kiến thức AWS mới nhất.

• Configure the fleet of EC2 instances to use encrypted EBS volumes to store data.
  ✅ Đúng. Như đã giải thích ở trên, EBS encryption là giải pháp lý tưởng: mã hóa toàn bộ volume (data, snapshots), performance không thay đổi (IOPS/throughput giống unencrypted nhờ offload encryption/decryption sang hardware). Hỗ trợ tất cả instance types hiện đại (Nitro, Graviton3/4 đến 2026). Không cần custom code, chỉ set Encrypted: true khi create volume.

• Configure the application to write all data to an encrypted Amazon S3 bucket.
  ❌ Sai. S3 là object storage (không phải block storage), không thể "attach" như EBS volumes cho compute-intensive app cần low-latency I/O trực tiếp. Việc write/read qua API sẽ impact performance nghiêm trọng (latency cao hơn EBS gp3/io2), không phù hợp initial deployment với attached volumes. S3 chỉ tốt cho archival/unstructured data.

• Configure a custom encryption algorithm for the application that will encrypt and decrypt all data.
  ❌ Sai. Custom encryption yêu cầu app tự handle encrypt/decrypt, dẫn đến overhead CPU cao (impact performance lớn trên compute-intensive workloads), phức tạp key management, và rủi ro bảo mật (không FIPS-compliant như AWS KMS). AWS khuyến cáo KHÔNG dùng custom crypto cho sensitive data; dùng native services thay thế.

• Configure an Amazon Machine Image (AMI) that has an encrypted root volume and store the data to ephemeral disks.
  ❌ Sai. Ephemeral disks (instance store) là non-persistent (dữ liệu mất khi stop/reboot instance), không phù hợp lưu sensitive data lâu dài. Encrypted root volume chỉ cho OS/boot, không dành cho app data trên EBS. Giải pháp này không đảm bảo persistence và vi phạm yêu cầu EBS-attached volumes.

🛡️ Kết luận DevOps Pro tip: Luôn ưu tiên EBS encryption + KMS cho EC2 data security. Sử dụng IAM policies để enforce encryption tại account level (default encrypted volumes từ 2025 policy updates). Nếu scale fleet, tích hợp Auto Scaling Groups với Launch Templates có encrypted EBS!

🧩 Nội dung câu hỏi
Câu hỏi tập trung vào việc triển khai cập nhật (rollout) dần dần cho một AWS Lambda function trong môi trường production để sửa lỗi (fix defect). Developer đã test code mới ở môi trường test, giờ muốn chỉ expose 10% users production với code mới trước, còn lại 90% vẫn dùng version cũ (production version). Mục tiêu là canary deployment hoặc weighted traffic shifting an toàn, giảm rủi ro downtime hoặc lỗi lan rộng. Đây là kỹ thuật phổ biến trong DevOps trên AWS Lambda, sử dụng versions và aliases để kiểm soát traffic mà không cần tạo function mới hay thay đổi trigger.

📘 Kiến thức liên quan (cập nhật đến 2026):
AWS Lambda hỗ trợ function versions (immutable snapshots của code/config) và aliases (pointer linh hoạt đến version, với routing config để split traffic % giữa các versions). Tính năng này ổn định từ lâu và vẫn là best practice cho gradual rollout (theo AWS Well-Architected Framework - Reliability Pillar). Không cần API Gateway hay proxy riêng vì alias xử lý trực tiếp tại Lambda level.

✅ Đáp án đúng: Phương án D
Update the Lambda code and create a new version of the Lambda function. Create a Lambda function alias. Configure the traffic weights in the Lambda alias between the two Lambda function versions. Send 90% of the traffic to the production version, and send 10% of the traffic to the new version.

Lý do chọn:

• Quy trình chuẩn: Update code → Tự động tạo new version (ví dụ: $LATEST → version 2).
• Tạo alias (ví dụ: "prod") trỏ đến version cũ (90%) và version mới (10%).
• Traffic shifting diễn ra tự động tại Lambda runtime, invocation từ bất kỳ trigger nào (API Gateway, SQS, etc.) đều tuân theo weights.
• Dễ monitor qua CloudWatch, điều chỉnh weights dần (shift lên 100% khi ổn). An toàn, không downtime.
  🛠️ Ví dụ CLI: aws lambda update-alias --function-name myfunc --name prod --function-version 1 --routing-config AdditionalVersionWeights='{"2":0.1}' (90% v1, 10% v2).

Tài liệu tham khảo:

• AWS Lambda Aliases & Versions (cập nhật 2024-2026).
• AWS Well-Architected: Lambda Deployment Strategies.

🔍 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. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, đánh dấu ✅/❌, và giải thích lý do đúng/sai bằng tiếng Việt rõ ràng.

• Phương án A (SAI) ❌
  Update the Lambda code and create a new version of the Lambda function. Create a Lambda function trigger. Configure the traffic weights in the trigger between the two Lambda function versions. Send 90% of the traffic to the production version, and send 10% of the traffic to the new version.
  Giải thích sai: Lambda không có "function trigger" hỗ trợ traffic weights. Trigger (event source như API Gateway, EventBridge) chỉ invoke function/alias, không config weights. Weights chỉ làm được ở alias level, không phải trigger. Sai concept cơ bản.

• Phương án B (SAI) ❌
  Create a new Lambda function that uses the updated code. Create a Lambda alias for the production Lambda function. Configure the Lambda alias to send 90% of the traffic to the production Lambda function, and send 10% of the traffic to the test Lambda function.
  Giải thích sai: Alias chỉ trỏ đến các versions của CÙNG MỘT function, không cross-function. Tạo "new Lambda function" riêng sẽ yêu cầu update tất cả trigger (ARN thay đổi), phức tạp và không gradual. Phải dùng publish version trên function gốc để alias split traffic nội bộ.

• Phương án C (SAI) ❌
  Update the Lambda code and create a new version of the Lambda function. Create a Lambda proxy integration. Configure the Lambda proxy to split traffic between the two Lambda function versions. Send 90% of the traffic to the production version, and send 10% of the traffic to the new version.
  Giải thích sai: "Lambda proxy integration" là tính năng của API Gateway (proxy requests đến Lambda), không phải Lambda gốc. Nó không split traffic giữa versions. Lambda alias mới là cách native, không phụ thuộc API Gateway.

🧠 Kết luận & Best Practice: Sử dụng Lambda aliases cho weighted deployments là zero-downtime rollout chuẩn DevOps. Kết hợp CloudWatch Metrics/Alarms để auto-rollback nếu lỗi (Provisioned Concurrency cho latency ổn định). Nếu scale lớn, cân nhắc AWS AppConfig hoặc CodeDeploy cho Lambda! 🚀

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

Câu hỏi mô tả tình huống một lập trình viên đang phát triển hàm AWS Lambda để tiêu thụ (consume) tin nhắn từ hàng đợi Amazon SQS standard queue. Vấn đề phát sinh là hàm Lambda xử lý một số tin nhắn nhiều lần (duplicate processing). Lý do chính là SQS Standard queue chỉ đảm bảo at-least-once delivery (giao ít nhất một lần), không phải exactly-once, dẫn đến tình trạng tin nhắn có thể được gửi lại nếu Lambda không xử lý kịp hoặc timeout. Câu hỏi yêu cầu giải pháp MOST cost-effectively (tiết kiệm chi phí nhất) để khắc phục vấn đề này. ✅

✅ Đáp án đúng

Change the Amazon SQS standard queue to an Amazon SQS FIFO queue by using the Amazon SQS message deduplication ID.

Lý do lựa chọn:
Đây là giải pháp tiết kiệm chi phí nhất vì SQS FIFO queue hỗ trợ exactly-once processing thông qua cơ chế message deduplication ID (ID khử trùng lặp tự động trong 5 phút) và message group ID (đảm bảo thứ tự). Không cần thay đổi code Lambda nhiều, chỉ cần migrate queue từ Standard sang FIFO (chi phí SQS FIFO chỉ cao hơn nhẹ so với Standard, nhưng tránh lãng phí do xử lý duplicate). Lambda trigger với SQS FIFO vẫn hoạt động mượt mà, giải quyết triệt để vấn đề mà không tốn thêm tài nguyên. 🛠️

📋 Giải thí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, với ✅ đúng hoặc ❌ sai, giữ nguyên nội dung tiếng Anh gốc:

• ✅ Change the Amazon SQS standard queue to an Amazon SQS FIFO queue by using the Amazon SQS message deduplication ID.
  Phương án này đúng vì SQS FIFO được thiết kế chuyên biệt để tránh duplicate nhờ deduplication ID (tự động loại bỏ tin nhắn trùng lặp dựa trên content hoặc ID) và content-based deduplication (từ năm 2018). Chi phí thấp (FIFO chỉ ~20-30% đắt hơn Standard nhưng tiết kiệm do không xử lý thừa), phù hợp với yêu cầu "MOST cost-effectively". Không ảnh hưởng đến throughput cao của Lambda.

• ❌ Set up a dead-letter queue.
  Phương án này sai vì Dead-Letter Queue (DLQ) chỉ dùng để lưu tin nhắn thất bại sau nhiều lần retry (ví dụ: Lambda throw exception), không ngăn chặn duplicate từ at-least-once delivery của SQS Standard. Nó chỉ giúp debug, không giải quyết gốc rễ vấn đề xử lý lặp lại, và có thể tăng chi phí lưu trữ DLQ không cần thiết.

• ❌ Set the maximum concurrency limit of the AWS Lambda function to 1.
  Phương án này sai vì đặt reserved concurrency = 1 chỉ giới hạn một invocation Lambda duy nhất, giảm concurrent processing nhưng không loại bỏ duplicate (vẫn xảy ra do visibility timeout của SQS - nếu Lambda chậm > timeout, message được visible lại). Giải pháp này làm giảm throughput nghiêm trọng (không scale), tăng độ trễ, và không cost-effective vì Lambda vẫn tính phí theo thời gian chạy lâu hơn.

• ❌ Change the message processing to use Amazon Kinesis Data Streams instead of Amazon SQS.
  Phương án này sai vì Kinesis Data Streams hỗ trợ exactly-once processing qua checkpointing với Lambda (enhanced fan-out), nhưng rất tốn kém (shard-hour billing, provisioned throughput), phức tạp hơn (cần manage shards, retention), và yêu cầu refactor code lớn. Không phải lựa chọn "MOST cost-effectively" so với FIFO queue đơn giản. 🛑

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

• AWS SQS Documentation: FIFO queues & Standard vs FIFO - Xác nhận deduplication ID cho exactly-once.
• AWS Lambda with SQS: Using Lambda with SQS - Hỗ trợ FIFO trigger từ 2018, không thay đổi đến 2026.
• Best Practices: AWS Well-Architected Framework - Reliability Pillar (2024 update): Khuyến nghị FIFO cho deduplication thay vì hack concurrency.
• Pricing (2026): SQS FIFO ~$0.50/million requests (tương đương Standard), Kinesis ~$0.015/shard-hour (đắt hơn nhiều).

Giải pháp này đảm bảo hệ thống scalable, reliable mà tiết kiệm nhất! 🚀

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

Câu hỏi tập trung vào việc tối ưu hóa và triển khai thử nghiệm (A/B testing hoặc canary release) một AWS Lambda function trong môi trường production, nhưng chỉ áp dụng cho một phần nhỏ traffic (ví dụ: 10%). Lambda function này đang phục vụ các request từ REST API trên Amazon API Gateway. Yêu cầu chính là:

• Deploy code mới (đã tối ưu) và test ngay trên production.
• KHÔNG thay đổi URL của API Gateway (nghĩa là giữ nguyên endpoint URL hiện tại, tránh tạo stage mới hoặc thay đổi integration URI).
• Sử dụng cơ chế canary release của API Gateway để routing % traffic nhỏ đến version mới, phần còn lại giữ nguyên production code.

🛠️ Kiến thức cốt lõi (cập nhật AWS 2026): API Gateway hỗ trợ canary release deployments trên existing production stage cho Lambda integrations. Điều này yêu cầu sử dụng Lambda Versions và Aliases để shift traffic weighted (ví dụ: alias "prod" routing 90% đến version cũ, 10% đến version mới). Không cần tạo stage mới (sẽ thay đổi URL). Quy trình chuẩn: Tạo alias từ $LATEST, integrate API Gateway với alias, publish version mới từ code optimized, rồi config canary trên stage để tự động update alias routing config cho % traffic.

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

Đáp án đúng là phương án thứ 3:

Define an alias on the $LATEST version of the Lambda function. Update the API Gateway endpoint to reference the new Lambda function alias. Upload and publish the optimized Lambda function code. On the production API Gateway stage, define a canary release and set the percentage of traffic to direct to the canary release. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Publish to the canary stage.

Lý do chọn:

• ✅ Sử dụng Lambda Alias (từ $LATEST) làm integration point cho API Gateway → Cho phép traffic shifting mượt mà qua canary config mà không thay đổi URL (giữ nguyên production stage).
• ✅ Quy trình đúng: Tạo alias → Update integration URI sang alias → Upload code mới (cập nhật $LATEST) và publish version → Config canary release trên production stage với % traffic → Update endpoint sang $LATEST (cho canary dùng version mới) → Publish đến canary stage (API Gateway tự tạo canary deployment trên same stage, không thay URL).
• ✅ Phù hợp best practice AWS 2026: Canary với aliases hỗ trợ gradual rollout, monitor metrics qua CloudWatch, auto-rollback nếu lỗi.
• ❌ Các phương án khác sai sequence hoặc dùng version trực tiếp (không hỗ trợ shifting tốt), tạo stage mới (thay URL), hoặc deploy trực tiếp prod.

📋 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 phương án (giữ nguyên văn bản gốc tiếng Anh). Mỗi cái được đánh dấu ✅ (đúng) hoặc ❌ (sai), với giải thích rõ ràng dựa trên docs AWS mới nhất.

• Phương án 1:

  Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. On the production API Gateway stage, define a canary release and set the percentage of traffic to direct to the canary release. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Publish the API to the canary stage.

  ❌ Sai vì: Bắt đầu bằng publish version cho production hiện tại rồi update endpoint sang version mới trước khi upload code → Gây downtime hoặc mismatch code/version. Canary cần alias để shift traffic, không phải version trực tiếp. Update sang $LATEST sau upload là thừa, và "Publish to canary stage" không khớp sequence chuẩn (canary deploy trên existing stage).

• Phương án 2:

  Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Deploy a new API Gateway stage.

  ❌ Sai vì: Deploy new API Gateway stage → Tạo URL mới (stage-specific như https://api.execute-api.region.amazonaws.com/newstage), vi phạm yêu cầu không thay đổi URL. Không dùng canary hoặc alias, chỉ publish version và $LATEST → Không test % traffic nhỏ, rủi ro full rollout.

• Phương án 3 (Đúng - như trên):

  Define an alias on the $LATEST version of the Lambda function. Update the API Gateway endpoint to reference the new Lambda function alias. Upload and publish the optimized Lambda function code. On the production API Gateway stage, define a canary release and set the percentage of traffic to direct to the canary release. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Publish to the canary stage.

  ✅ Đúng hoàn toàn: Alias cho phép canary traffic splitting trên production stage (giữ URL). Sequence logic: Alias đầu vào → Code mới publish version → Canary config % → $LATEST cho canary → Publish canary deployment.

• Phương án 4:

  Define a function version for the currently deployed production Lambda function. Update the API Gateway endpoint to reference the new Lambda function version. Upload and publish the optimized Lambda function code. Update the API Gateway endpoint to use the $LATEST version of the Lambda function. Deploy the API to the production API Gateway stage.

  ❌ Sai vì: Không có canary release → Deploy thẳng full traffic đến production stage, không test % nhỏ. Update version/$LATEST trước upload code → Rủi ro sai lệch. Không dùng alias → Không hỗ trợ weighted shift an toàn.

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

• 🛠️ API Gateway Canary Release Deployments – Hướng dẫn config canary với Lambda aliases trên production stage.
• 🧩 Lambda Aliases & Versions for Traffic Shifting – Canary traffic với % routing qua aliases.
• 📊 API Gateway Stages & Deployments – Xác nhận canary không thay URL.
• 🔍 Exam prep: AWS Certified DevOps Engineer Professional (DOP-C02) – Topic: Serverless CI/CD & Safe Deployments.

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

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

Câu hỏi mô tả tình huống một công ty đang lưu trữ credentials (tài khoản xác thực API) dùng để kết nối với nhà cung cấp SaaS (Software as a Service) bên ngoài trong file cấu hình dưới dạng plaintext (văn bản thuần), dẫn đến rủi ro bảo mật cao.
Nhiệm vụ của developer là:

• Bảo mật credentials (secure API credentials).
• Ép buộc xoay vòng credentials tự động hàng quý (enforce automatic credentials rotation on a quarterly basis).

Yêu cầu giải pháp bảo mật nhất (MOST securely), phù hợp với best practices AWS cho việc quản lý secrets nhạy cảm, đặc biệt với external SaaS vendors.
🛠️ Vấn đề cốt lõi: Không chỉ mã hóa mà còn cần tự động hóa rotation (xoay vòng credentials định kỳ) mà không để lộ secrets, và tích hợp dễ dàng vào ứng dụng.

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

Đáp án đúng: Store the credentials in AWS Secrets Manager and enable rotation. Configure the API to have Secrets Manager access.

Lý do chi tiết:

• AWS Secrets Manager là dịch vụ chuyên dụng để lưu trữ, quản lý và xoay vòng secrets (như API keys, passwords) một cách an toàn.
• Hỗ trợ rotation tự động qua Lambda functions tùy chỉnh hoặc tích hợp sẵn (có thể đặt lịch quarterly - hàng quý).
• Ứng dụng có thể retrieve secrets động qua API mà không lưu trữ plaintext, sử dụng IAM roles để truy cập (least privilege).
• Đây là giải pháp MOST securely vì: Không lưu secrets lâu dài, tự động cập nhật credentials mới cho SaaS vendor, và audit logs đầy đủ qua CloudTrail.
• Cập nhật 2026: Secrets Manager hỗ trợ rotation cho nhiều loại secrets external (custom Lambda), tích hợp IAM Access Analyzer để kiểm tra quyền.

📋 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, giữ nguyên văn bản gốc bằng tiếng Anh. Mỗi phương án được đánh giá ✅ (đúng) hoặc ❌ (sai), kèm giải thích chi tiết bằng tiếng Việt:

• ❌ [SAI] Use AWS Key Management Service (AWS KMS) to encrypt the configuration file. Decrypt the configuration file when users make API calls to the SaaS vendor. Enable rotation.
  Lý do sai: KMS chỉ dùng để mã hóa dữ liệu (encrypt/decrypt symmetric/asymmetric), không phải dịch vụ quản lý secrets. Việc decrypt file mỗi lần API call sẽ lộ secrets tạm thời và không hỗ trợ rotation credentials tự động cho SaaS (chỉ rotate KMS keys riêng). Không giải quyết gốc rễ plaintext storage, kém bảo mật và phức tạp.

• ❌ [SAI] Retrieve temporary credentials from AWS Security Token Service (AWS STS) every 15 minutes. Use the temporary credentials when users make API calls to the SaaS vendor.
  Lý do sai: STS cung cấp temporary credentials cho AWS services (như AssumeRole), không dùng cho external SaaS vendors. Không rotate được credentials SaaS (chỉ AWS creds), và chu kỳ 15 phút không khớp quarterly. Không lưu trữ/rotate secrets gốc, chỉ là workaround tạm thời không an toàn.

• ✅ [ĐÚNG] Store the credentials in AWS Secrets Manager and enable rotation. Configure the API to have Secrets Manager access.
  Lý do đúng: Như đã giải thích ở trên, đây là giải pháp chuẩn AWS cho secrets external. Enable rotation qua console/Lambda (quarterly schedule), ứng dụng dùng SDK retrieve secrets động với caching (TTL). Bảo mật cao nhất với VPC endpoints, encryption at rest/transit, và versioning.

• ❌ [SAI] Store the credentials in AWS Systems Manager Parameter Store and enable rotation. Retrieve the credentials when users make API calls to the SaaS vendor.
  Lý do sai: Parameter Store lưu parameters (có SecureString mã hóa KMS), nhưng KHÔNG hỗ trợ rotation tự động built-in (cần custom script/Lambda bên ngoài, phức tạp và không enforced). Phù hợp config thông thường hơn secrets nhạy cảm. Kém an toàn hơn Secrets Manager cho rotation SaaS.

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

• AWS Secrets Manager: docs.aws.amazon.com/secretsmanager/latest/userguide/rotating-secrets.html - Hướng dẫn rotation custom cho SaaS.
• So sánh Secrets Manager vs Parameter Store: aws.amazon.com/blogs/security/ (best practices 2025+).
• AWS Well-Architected Framework - Security Pillar: Nhấn mạnh Secrets Manager cho external credentials.
• Exam DOP-C02: Chủ đề DevOps quản lý secrets (phiên bản mới nhất).

🛠️ Lời khuyên thực tế: Trong production, kết hợp Secrets Manager với IAM policies least-privilege và Lambda rotation cho SaaS cụ thể!