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

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

Câu hỏi mô tả một tình huống thực tế trong môi trường AWS: Một công ty đang chạy ứng dụng trên hàng loạt instance Amazon EC2 (fleet lớn), ứng dụng này thực hiện các hoạt động đọc và ghi dữ liệu vào một bảng Amazon DynamoDB. Kích thước bảng DynamoDB liên tục tăng trưởng do dữ liệu tích lũy, nhưng ứng dụng chỉ cần dữ liệu từ 30 ngày gần nhất. Yêu cầu chính là tìm giải pháp tối ưu hóa chi phí (minimize cost) bằng cách giảm dung lượng lưu trữ không cần thiết, đồng thời giảm thiểu nỗ lực phát triển (minimize development effort) – nghĩa là không cần code phức tạp, quản lý thủ công hay tài nguyên thừa.
🛠️ Mục tiêu cốt lõi: Tự động hóa việc xóa dữ liệu cũ (older than 30 days) một cách hiệu quả, tiết kiệm, và dễ triển khai, phù hợp với kiến trúc serverless/scalable của AWS (cập nhật đến 2026, DynamoDB vẫn hỗ trợ TTL mạnh mẽ cho auto-cleanup).

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

Đáp án đúng là lựa chọn D:
Extend the application to add an attribute that has a value of the current timestamp plus 30 days to each new item that is created in the table. Configure DynamoDB to use the attribute as the TTL attribute.

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

• Đây là giải pháp tích hợp sẵn của DynamoDB gọi là TTL (Time to Live) – tính năng miễn phí, tự động xóa item khi hết hạn mà không tốn throughput (không tính RCU/WCU).
• Chỉ cần extend app nhẹ nhàng (thêm 1 attribute timestamp + 30 ngày khi insert item), sau đó config TTL trên bảng DynamoDB – dev effort tối thiểu (không cần Lambda, script, hay redeploy).
• Tiết kiệm chi phí cao: Dữ liệu cũ tự động biến mất sau 48h, giảm stored data → bill DynamoDB thấp (chỉ tính phí lưu trữ thực tế). Phù hợp fleet EC2 lớn, không cần tài nguyên bổ sung.
• Cập nhật 2026: TTL vẫn là best practice cho data expiration (hỗ trợ số nguyên 64-bit epoch time), không thay đổi từ DynamoDB v2019+.

📋 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 một cách khách quan, giữ nguyên nội dung gốc bằng tiếng Anh. Mỗi phương án được đánh giá đúng/sai với lý do cụ thể dựa trên nguyên tắc AWS DevOps (cost-effective, low-effort, reliable).

• Lựa chọn A:
  Use an AWS CloudFormation template to deploy the complete solution. Redeploy the CloudFormation stack every 30 days, and delete the original stack.
  ❌ Sai vì: Giải pháp này phức tạp và tốn kém – yêu cầu tạo CloudFormation template toàn bộ stack (bao gồm EC2 fleet + DynamoDB), rồi redeploy thủ công mỗi 30 ngày (delete stack cũ → mất data liên tục, downtime cao). Không tự động, dev effort lớn (viết template, script redeploy), vi phạm minimize cost (tốn thời gian engineer + potential data loss). Không phù hợp DynamoDB (table không xóa toàn bộ mà chỉ data cũ).

• Lựa chọn B:
  Use an EC2 instance that runs a monitoring application from AWS Marketplace. Configure the monitoring application to use Amazon DynamoDB Streams to store the timestamp when a new item is created in the table. Use a script that runs on the EC2 instance to delete items that have a timestamp that is older than 30 days.
  ❌ Sai vì: Tốn kém và effort cao – thêm EC2 riêng (chi phí always-on ~$10-50/tháng), mua app Marketplace (license phí), config DynamoDB Streams (tốn $0.02/100k reads), và script cron job delete (cần scan toàn bảng → tốn RCU/WCU lớn, throttle nếu table to). Không scalable cho fleet EC2 lớn, rủi ro single point failure (EC2 down → không delete).

• Lựa chọn C:
  Configure Amazon DynamoDB Streams to invoke an AWS Lambda function when a new item is created in the table. Configure the Lambda function to delete items in the table that are older than 30 days.
  ❌ Sai vì: Không hiệu quả và tốn dev effort – DynamoDB Streams + Lambda chỉ trigger khi new item (không phải data cũ), nên Lambda phải scan toàn bảng mỗi lần để delete old items → tốn RCU/WCU khổng lồ (O(n) complexity, bill cao cho table lớn), timeout nếu >15p. Streams tốn phí ($0.02/100k), Lambda invocations tích lũy. Không minimize cost/effort so với TTL native.

• Lựa chọn D (Đúng – đã giải thích ở trên):
  Extend the application to add an attribute that has a value of the current timestamp plus 30 days to each new item that is created in the table. Configure DynamoDB to use the attribute as the TTL attribute.
  ✅ Đúng vì: TTL native, zero-cost deletion (background process, no billing), chỉ thêm 1 attr đơn giản vào app (dev effort thấp), config 1-click trên console/API. Hoàn hảo cho yêu cầu.

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

• DynamoDB TTL: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/ttl.html (Best practice cho auto-expiration, ví dụ code Node.js/Python).
• DynamoDB Pricing: https://aws.amazon.com/dynamodb/pricing/ (Xác nhận TTL free, chỉ bill storage thực tế).
• DevOps Pro Exam Guide: https://d1.awsstatic.com/training-and-certification/docs-devops-pro/AWS-Certified-DevOps-Engineer-Professional_Exam-Guide.pdf (Topic: DynamoDB optimization, TTL là key solution).
  🛠️ Lời khuyên DevOps: Luôn ưu tiên native features như TTL trước custom logic để scale zero-effort! Nếu table có query phức tạp, kết hợp GSI cho data cũ.

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

📝 Giải thích nội dung câu hỏi một cách chi tiết và rõ ràng:
Câu hỏi mô tả một công ty có ứng dụng Microsoft .NET chạy trên Windows Server on-premises, lưu trữ dữ liệu bằng Oracle Database Standard Edition. Họ đang lập kế hoạch migrate sang AWS, với các yêu cầu chính:

• Tối thiểu hóa thay đổi phát triển (minimize development changes): Nghĩa là ưu tiên các chiến lược migration như "lift-and-shift" (rehost/replatform) thay vì refactor lớn.
• Môi trường AWS phải highly available (HA): Sử dụng các tính năng như Multi-AZ để đảm bảo tính sẵn sàng cao, tránh single point of failure.
  Câu hỏi yêu cầu chọn TWO actions (hai hành động kết hợp) để đáp ứng. Đây là chủ đề thuộc AWS Migration Strategies (theo mô hình 7 Rs: Rehost, Replatform, Refactor, Re-architect, v.v.), tập trung vào Application Migration và Database Migration trên AWS. Kiến thức cập nhật đến 2026 vẫn giữ nguyên: Elastic Beanstalk hỗ trợ .NET trên Windows, RDS Oracle Multi-AZ, và DMS hỗ trợ migrate Oracle seamless.

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

Hai đáp án đúng là:

• Rehost the application in AWS Elastic Beanstalk with the .NET platform in a Multi-AZ deployment.
• Use AWS Database Migration Service (AWS DMS) to migrate from the Oracle database to Oracle on Amazon RDS in a Multi-AZ deployment.

Lý do chọn:
🛠️ Rehost với Elastic Beanstalk (.NET on Multi-AZ) là "lift-and-shift" hoàn hảo cho app Windows .NET, không cần code changes lớn – Elastic Beanstalk tự động quản lý deployment, scaling, và load balancing trên Windows IIS. Multi-AZ đảm bảo HA bằng cách replicate instances qua Availability Zones.
🗄️ DMS migrate Oracle sang RDS Oracle Multi-AZ giữ nguyên engine database (Oracle Standard Edition tương thích RDS), minimize schema changes, hỗ trợ homogeneous migration (Oracle-to-Oracle) với CDC (Change Data Capture) cho zero-downtime. Multi-AZ trên RDS cung cấp failover automatic <60s.
Kết hợp hai actions này migrate toàn bộ app + DB mà không thay đổi dev, đạt HA cao. (Theo AWS Migration Hub và Well-Architected Framework 2024+).

🧐 Phân tích tất cả các phương án (đúng và sai)

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên text 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 best practices AWS mới nhất (2026).

• ❌ Refactor the application as serverless with AWS Lambda functions running .NET Core.
  Phương án này yêu cầu refactor lớn (chuyển sang serverless Lambda .NET Core), thay đổi code architecture từ monolithic Windows sang event-driven, không minimize dev changes. Lambda .NET Core hỗ trợ tốt nhưng cần rewrite handlers, connections – vi phạm yêu cầu chính. Không phù hợp rehost.

• ✅ Rehost the application in AWS Elastic Beanstalk with the .NET platform in a Multi-AZ deployment.
  ✅ Đúng hoàn hảo: Rehost "lift-and-shift" app .NET Windows lên Elastic Beanstalk (.NET on Windows platform), tự động handle IIS, deployment. Multi-AZ deployment đảm bảo HA qua Auto Scaling Groups + ELB cross-AZ. Không cần code changes, chỉ upload bundle – lý tưởng cho minimize dev. (Hỗ trợ .NET 8+ trên Windows Server 2022 AMI đến 2026).

• ❌ Replatform the application to run on Amazon EC2 with the Amazon Linux Amazon Machine Image (AMI).
  ❌ Sai vì không tương thích: App .NET chạy trên Windows, nhưng Amazon Linux AMI là Linux-based (RHEL derivative). Cần replatform lớn: port code sang .NET Core/Linux, thay đổi dependencies (Windows APIs → Linux), tăng dev effort cao. Không minimize changes, dù EC2 có thể Multi-AZ nhưng không phải lựa chọn tối ưu.

• ❌ Use AWS Database Migration Service (AWS DMS) to migrate from the Oracle database to Amazon DynamoDB in a Multi-AZ deployment.
  ❌ Sai lớn về compatibility: DMS hỗ trợ migrate nhưng Oracle (RDBMS SQL) sang DynamoDB (NoSQL key-value) yêu cầu schema redesign hoàn toàn (từ relational tables sang partitions/items), thay đổi queries/app code. Không minimize dev changes, dù DynamoDB Global Tables cho HA nhưng không phù hợp Oracle Standard Edition.

• ✅ Use AWS Database Migration Service (AWS DMS) to migrate from the Oracle database to Oracle on Amazon RDS in a Multi-AZ deployment.
  ✅ Đúng xuất sắc: DMS hỗ trợ homogeneous migration Oracle-to-Oracle RDS (Standard Edition tương thích), full-load + CDC cho minimal downtime. RDS Multi-AZ cung cấp synchronous replication, automatic failover, read replicas. Giữ nguyên SQL queries/app connections – minimize changes tuyệt đối. (DMS engine v3.4.7+ hỗ trợ Oracle 19c/21c đến 2026).

📘 Tài liệu tham khảo

• AWS Documentation: Elastic Beanstalk .NET Platforms (Windows .NET support).
• AWS DMS User Guide: Migrating Oracle to Oracle RDS (Heterogeneous/Homogeneous).
• AWS Well-Architected Framework - Migration Pillar (2024+): Nhấn mạnh Rehost cho minimize changes.
• AWS Migration Whitepaper: "Application Migration Strategies" (7 Rs model).

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ụ thực tế, hỏi nhé!

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

Câu hỏi mô tả một công ty đang chạy ứng dụng containerized trên Kubernetes cluster tại data center on-premises, sử dụng MongoDB làm cơ sở dữ liệu. Họ muốn migrate một phần môi trường lên AWS, nhưng KHÔNG ĐƯỢC thay đổi code hoặc phương thức deployment (tức là phải giữ nguyên Kubernetes và tương thích MongoDB). Giải pháp cần giảm thiểu operational overhead (tức là ít quản lý hạ tầng nhất có thể, ưu tiên managed/serverless services).

📌 Yêu cầu cốt lõi:

• Giữ nguyên Kubernetes cho deployment (không chuyển sang ECS).
• Tương thích MongoDB cho database (không dùng DynamoDB vì không compatible API).
• Minimize overhead: Sử dụng serverless như Fargate cho compute và managed DB như DocumentDB.

✅ Đáp án đúng

Use Amazon Elastic Kubernetes Service (Amazon EKS) with AWS Fargate for compute and Amazon DocumentDB (with MongoDB compatibility) for data storage.

Lý do lựa chọn:

• EKS giữ nguyên Kubernetes API và deployment method (kubectl, manifests), không cần thay code. ✅
• AWS Fargate là serverless compute cho EKS, tự động scale và quản lý nodes, giảm overhead (không cần patch EC2). 🛠️
• Amazon DocumentDB (with MongoDB compatibility) hỗ trợ MongoDB wire protocol và API (tương thích 4.0/5.0), chỉ cần đổi endpoint connection string, không thay code. 📊
• Giải pháp hoàn toàn managed, phù hợp migrate lift-and-shift với zero-downtime. 🚀

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

• Use Amazon Elastic Container Service (Amazon ECS) with Amazon EC2 worker nodes for compute and MongoDB on EC2 for data storage.
  ❌ Sai vì: Chuyển từ Kubernetes sang ECS yêu cầu thay đổi deployment method (task definitions, ECS CLI thay vì kubectl), vi phạm "no deployment method changes". EC2 worker nodes và MongoDB self-managed trên EC2 tăng operational overhead (quản lý patching, scaling). Không phù hợp migrate không thay code.

• Use Amazon Elastic Container Service (Amazon ECS) with AWS Fargate for compute and Amazon DynamoDB for data storage.
  ❌ Sai vì: ECS vẫn thay đổi deployment từ Kubernetes (phải rewrite manifests thành ECS tasks), vi phạm yêu cầu. DynamoDB là NoSQL key-value, không compatible MongoDB API (document model khác biệt), buộc thay code ứng dụng. Fargate tốt nhưng không cứu vãn được.

• Use Amazon Elastic Kubernetes Service (Amazon EKS) with Amazon EC2 worker nodes for compute and Amazon DynamoDB for data storage.
  ❌ Sai vì: EKS giữ nguyên Kubernetes (tốt), nhưng EC2 worker nodes yêu cầu quản lý nodes (AMI, ASG, patching) → overhead cao. DynamoDB không tương thích MongoDB (API khác, cần refactor code queries), vi phạm "no code changes".

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

• AWS EKS + Fargate: Amazon EKS Documentation - Fargate Pods (hỗ trợ EKS 1.30+, serverless pods).
• Amazon DocumentDB MongoDB compatibility: DocumentDB Docs - MongoDB Compatibility (compatible 5.0+, multi-AZ, auto-scale).
• Migration patterns: AWS Well-Architected Framework - Migration Whitepaper (2024 update), nhấn mạnh lift-and-shift với EKS Anywhere/Fargate cho Kubernetes.
• Exam context: DOP-C02 (DevOps Pro 2024 syllabus), chủ đề EKS migration và managed services.

Giải pháp này đảm bảo seamless migration với chi phí thấp nhất! 🌟

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

Câu hỏi mô tả một công ty telemarketing đang thiết kế chức năng trung tâm gọi điện khách hàng trên AWS. Yêu cầu chính bao gồm:

• Nhận diện nhiều người nói (multiple speaker recognition): Phân biệt và nhận dạng các giọng nói khác nhau trong cuộc gọi.
• Tạo file transcript: Chuyển đổi âm thanh cuộc gọi thành văn bản (transcript files).
• Phân tích pattern kinh doanh: Truy vấn (query) các file transcript để phân tích xu hướng kinh doanh.
• Lưu trữ lâu dài: Giữ file transcript trong 7 năm để phục vụ kiểm toán (auditing).

🛠️ Giải pháp cần thiết: Phải chọn dịch vụ AWS phù hợp nhất cho transcription audio với speaker recognition, lưu trữ bền vững (như S3), và công cụ query serverless cho dữ liệu lớn (hỗ trợ phân tích mà không cần quản lý database). Kiến thức dựa trên AWS cập nhật 2026: Amazon Transcribe hỗ trợ speaker identification qua speaker labels (diarization) lên đến 10 speakers, output JSON/CSV vào S3; Athena query trực tiếp trên S3 với SQL.

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

Đáp án đúng: Use Amazon Transcribe for multiple speaker recognition. Use Amazon Athena for transcript file analysis.

Lý do chi tiết:

• 📘 Amazon Transcribe là dịch vụ chuyên dụng cho Automatic Speech Recognition (ASR), hỗ trợ multiple speaker diarization (nhận diện và gắn nhãn speaker 1, speaker 2,...). Nó tạo transcript files (JSON/CSV) từ audio calls, phù hợp hoàn hảo cho telemarketing.
• Amazon Athena là engine query serverless, sử dụng SQL để phân tích transcript files lưu trong S3 (không cần ETL), lý tưởng cho business analytics trên dữ liệu lớn.
• Giải pháp này ngầm hỗ trợ lưu trữ 7 năm trên S3 (với lifecycle policies). Không cần dịch vụ khác, tiết kiệm chi phí và scalable.

🧩 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, 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 dựa trên tính năng AWS mới nhất (2026).

• Use Amazon Rekognition for multiple speaker recognition. Store the transcript files in Amazon S3. Use machine learning models for transcript file analysis.
  ❌ Sai: Amazon Rekognition chuyên phân tích video/image (face detection, celebrity recognition), không hỗ trợ audio speaker recognition. Không tạo transcript từ audio. Phần "machine learning models" quá mơ hồ, không scalable cho query lớn và không chỉ rõ dịch vụ cụ thể. S3 đúng cho lưu trữ nhưng toàn bộ giải pháp không khớp yêu cầu.

• Use Amazon Transcribe for multiple speaker recognition. Use Amazon Athena for transcript file analysis.
  ✅ Đúng: Như đã giải thích ở trên. Transcribe xử lý hoàn hảo multiple speaker recognition (speaker labels/diarization), xuất transcript trực tiếp vào S3. Athena query SQL trên S3 transcripts để phân tích patterns, hỗ trợ lưu trữ 7 năm dễ dàng. Đây là best practice cho contact center analytics.

• Use Amazon Translate for multiple speaker recognition. Store the transcript files in Amazon Redshift. Use SQL queries for transcript file analysis.
  ❌ Sai: Amazon Translate chỉ dịch văn bản giữa ngôn ngữ, không làm transcription hay speaker recognition từ audio. Redshift là data warehouse quản lý (expensive, không serverless), không tối ưu cho file-based transcripts so với Athena + S3. SQL queries đúng nhưng nền tảng sai.

• Use Amazon Rekognition for multiple speaker recognition. Store the transcript files in Amazon S3. Use Amazon Textract for transcript file analysis.
  ❌ Sai: Rekognition lại sai vì không hỗ trợ audio (chỉ video/image). Amazon Textract extract text từ documents/images/PDF, không phân tích transcript text từ audio. S3 đúng lưu trữ nhưng hai dịch vụ chính đều không phù hợp.

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

• Amazon Transcribe: docs.aws.amazon.com/transcribe/latest/dg/speaker-diarization.html – Speaker identification.
• Amazon Athena: docs.aws.amazon.com/athena/latest/ug/querying.html – Query S3 transcripts.
• Contact Center Best Practices: AWS Well-Architected Framework for Machine Learning (Contact Centers pillar).
• S3 Lifecycle: Hỗ trợ 7-year retention với Glacier/Deep Archive.

🛠️ Kết luận: Giải pháp đúng tối ưu chi phí, scalable và tuân thủ yêu cầu audit! Nếu cần thiết kế chi tiết hơn (như CDK/CloudFormation), hãy hỏi thêm. 🚀

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

Câu hỏi tập trung vào việc bảo mật và kiểm soát truy cập (authorization) cho một REST API được host trên Amazon API Gateway, nơi ứng dụng fetch dữ liệu từ Amazon DynamoDB. Công ty sử dụng Amazon Cognito để quản lý người dùng (user management). Yêu cầu chính là tìm giải pháp được AWS quản lý (AWS managed solution) giúp kiểm soát truy cập API một cách ít nỗ lực phát triển (reduce development efforts) và ít overhead vận hành nhất (LEAST operational overhead).

🔍 Chi tiết ngữ cảnh:

• Người dùng đăng nhập qua Cognito → Nhận token (JWT) → Gửi request đến API Gateway → API Gateway gọi DynamoDB.
• Cần authorize request dựa trên thông tin user từ Cognito, mà không phải tự code logic phức tạp.
• Giải pháp phải tích hợp sẵn với Cognito, tự động validate token, và AWS chịu trách nhiệm scale/maintain để giảm công việc DevOps.

🛠️ Yêu cầu then chốt: Sử dụng tính năng authorizer của API Gateway (cập nhật mới nhất 2026: hỗ trợ đầy đủ Cognito User Pools, JWT authorizers với IAM roles fine-grained).

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

Đáp án đúng: Configure an Amazon Cognito user pool authorizer in API Gateway to allow Amazon Cognito to validate each request.

Lý do chi tiết:

• Đây là giải pháp AWS managed hoàn toàn 📘 (tích hợp native giữa API Gateway và Cognito User Pools).
• API Gateway tự động validate JWT token từ Cognito mà không cần code Lambda hay logic tùy chỉnh → Giảm development efforts tối đa (chỉ config vài bước qua Console/CLI/CDK).
• Least operational overhead: AWS handle scale, rotate keys, validation logic (claim mapping, scopes). Hỗ trợ caching authorization results để tối ưu latency/cost.
• Phù hợp nhất với kiến trúc serverless hiện đại (Cognito + API Gateway + DynamoDB), tuân thủ best practices AWS Well-Architected Framework (Security Pillar).

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

• ❌ Configure an AWS Lambda function to be an authorizer in API Gateway to validate which user made the request.
  Phương án này sai vì yêu cầu tự code Lambda authorizer (Lambda Proxy hoặc Token) để parse JWT từ Cognito, kiểm tra claims/user ID. Dẫn đến development efforts cao (viết code, handle errors, secrets), operational overhead lớn (monitor Lambda, debug failures). Không phải AWS fully managed – bạn phải maintain code.

• ❌ For each user, create and assign an API key that must be sent with each request. Validate the key by using an AWS Lambda function.
  Phương án này sai vì API keys không phù hợp cho user auth (chỉ cho client/app, không secure cho end-users). Phải tự tạo/manage key per user + Lambda validate → Vi phạm least overhead (scale issues, key rotation thủ công, không tích hợp Cognito). API keys deprecated cho user auth từ 2023+, khuyến nghị dùng JWT.

• ❌ Send the user’s email address in the header with every request. Invoke an AWS Lambda function to validate that the user with that email address has proper access.
  Phương án này sai vì gửi email header không secure (dễ spoof/fake), phải dùng Lambda query Cognito/DynamoDB để verify → Development cao (code validation, handle rate limits), overhead lớn (Lambda invocations tốn kém, no caching native). Không leverage Cognito token, dễ bị tấn công.

• ✅ Configure an Amazon Cognito user pool authorizer in API Gateway to allow Amazon Cognito to validate each request.
  Phương án này đúng như đã giải thích ở trên: AWS managed 100%, config đơn giản (chọn User Pool ARN, token source Authorization), auto-validate ID/Access tokens. Hỗ trợ scopes/claims mapping trực tiếp đến IAM policies hoặc Lambda.

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

• AWS Docs chính thức: API Gateway Authorizers with Cognito – Hướng dẫn config User Pool authorizer.
• Cognito + API Gateway Best Practices: Serverless Auth Patterns (blog AWS Compute, updated 2025).
• Exam Prep DOP-C02: AWS Certified DevOps Engineer Professional – Domain 3: Implementation (Security focus).
• Well-Architected Tool: Security Pillar checklist cho API auth (free audit tool trên AWS Console).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần demo code CDK/Serverless Framework, hãy hỏi thêm nhé!

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

Câu hỏi mô tả một công ty đang phát triển dịch vụ truyền thông marketing nhắm đến người dùng ứng dụng di động. Họ cần gửi tin nhắn xác nhận qua SMS (Short Message Service) đến người dùng, đồng thời người dùng phải có thể trả lời (reply) tin nhắn SMS. Các phản hồi từ người dùng phải được lưu trữ ít nhất 1 năm để phục vụ mục đích phân tích dữ liệu.

Yêu cầu chính bao gồm:

• Gửi SMS outbound (từ hệ thống đến người dùng).
• Xử lý SMS inbound (phản hồi từ người dùng).
• Lưu trữ và phân tích dữ liệu lâu dài (1 năm), phù hợp với quy trình marketing tự động hóa (journeys/campaigns).
• Giải pháp phải scalable, tích hợp tốt với AWS services cho messaging và analytics (dựa trên kiến thức AWS cập nhật đến 2026, nơi Amazon Pinpoint hỗ trợ SMS hai chiều toàn diện và tích hợp Kinesis cho real-time streaming).

Mục tiêu là chọn kiến trúc tối ưu nhất từ Solutions Architect perspective, đảm bảo tính năng two-way SMS, automation journeys, và data persistence/archiving.

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

Đáp án đúng: Build an Amazon Pinpoint journey. Configure Amazon Pinpoint to send events to an Amazon Kinesis data stream for analysis and archiving.

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

• Amazon Pinpoint (cập nhật 2026) là dịch vụ chuyên biệt cho customer engagement và marketing campaigns, hỗ trợ SMS hai chiều (two-way SMS) hoàn hảo: gửi outbound SMS qua Journeys (luồng tự động hóa cá nhân hóa dựa trên user segments), và tự động capture inbound replies/events.
• Journeys cho phép xây dựng quy trình marketing phức tạp, trigger SMS dựa trên events, và xử lý responses real-time.
• Pinpoint tích hợp native với Amazon Kinesis Data Streams để stream tất cả events (gửi/nhận SMS, replies, analytics metrics) cho phân tích và archiving (Kinesis + S3/Glacier cho lưu 1 năm+).
• Scalable, cost-effective, compliant với quy định SMS (như opt-in/opt-out), và hỗ trợ global delivery. Đây là best practice cho marketing SMS theo AWS Well-Architected Framework.

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

• ❌ [SAI] Create an Amazon Connect contact flow to send the SMS messages. Use AWS Lambda to process the responses.
  Amazon Connect là dịch vụ contact center cho voice/SMS inbound/outbound, nhưng không phù hợp cho marketing campaigns quy mô lớn (thiếu journeys/segments tự động). Contact flows hỗ trợ SMS nhưng chủ yếu cho customer service (không optimize cho bulk marketing). Xử lý responses qua Lambda thủ công, không có native analytics/archiving 1 năm. Pinpoint vượt trội hơn cho use case này.

• ✅ [ĐÚNG] Build an Amazon Pinpoint journey. Configure Amazon Pinpoint to send events to an Amazon Kinesis data stream for analysis and archiving.
  Như đã giải thích ở phần đáp án đúng: Hoàn hảo cho two-way SMS marketing với journeys automation, event streaming native đến Kinesis (real-time analysis + archiving via Kinesis Data Firehose/S3). Tích hợp end-to-end, scalable globally.

• ❌ [SAI] Use Amazon Simple Queue Service (Amazon SQS) to distribute the SMS messages. Use AWS Lambda to process the responses.
  Amazon SQS là message queue cho decoupling apps, không hỗ trợ gửi SMS trực tiếp (cần thêm SNS/Lambda để integrate, phức tạp và không native). Không xử lý inbound SMS replies tự động, thiếu marketing features (journeys, personalization). Lưu trữ responses qua Lambda thủ công không đảm bảo 1 năm analysis scalable.

• ❌ [SAI] Create an Amazon Simple Notification Service (Amazon SNS) FIFO topic. Subscribe an Amazon Kinesis data stream to the SNS topic for analysis and archiving.
  Amazon SNS hỗ trợ gửi SMS outbound qua topic (bao gồm FIFO cho ordering), nhưng không xử lý inbound replies tự động (replies không route về SNS/Kinesis). Subscription Kinesis đến SNS chỉ cho outbound messages, không capture responses. Thiếu two-way SMS và marketing journeys; không phải best practice cho use case này (SNS one-way oriented).

📘 Tài liệu tham khảo

• Amazon Pinpoint Documentation (2026): SMS and Voice with Pinpoint & Journeys & Event Streaming to Kinesis.
• AWS Well-Architected Framework - Reliability Pillar: Khuyến nghị Pinpoint cho customer engagement.
• Exam Prep DOP-C02/SA Pro: Best practice cho two-way SMS marketing (Q&A tương tự trong AWS practice exams 2025-2026).

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

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

Câu hỏi tập trung vào việc di chuyển dữ liệu vào Amazon S3 bucket với hai yêu cầu chính:

• Dữ liệu phải được mã hóa (encrypted) khi lưu trữ trong S3 (server-side encryption).
• Khóa mã hóa (encryption key) phải được tự động xoay vòng (rotated) hàng năm.
  Mục tiêu là chọn giải pháp có operational overhead thấp nhất (ít công việc quản lý nhất), phù hợp với nguyên tắc DevOps trên AWS.
  📘 Bối cảnh AWS cập nhật 2026: Amazon S3 hỗ trợ nhiều loại mã hóa server-side như SSE-S3 (S3-managed keys), SSE-KMS (KMS-managed keys), và client-side encryption. SSE-S3 là lựa chọn đơn giản nhất vì S3 tự quản lý khóa và tự động rotate hàng năm mà không cần can thiệp thủ công. (Nguồn: AWS S3 Security Documentation).

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

Đáp án đúng:
Move the data to the S3 bucket. Use server-side encryption with Amazon S3 managed encryption keys (SSE-S3). Use the built-in key rotation behavior of SSE-S3 encryption keys.

🛠️ Lý do:

• SSE-S3 sử dụng khóa do S3 quản lý hoàn toàn (S3-managed keys), tự động áp dụng mã hóa server-side cho mọi object.
• Built-in key rotation: AWS tự động xoay khóa hàng năm (mỗi 365 ngày), không cần cấu hình thêm.
• Least operational overhead: Chỉ cần enable SSE-S3 trên bucket (mặc định hoặc qua bucket policy/default encryption), di chuyển data là xong. Không tạo key, không quản lý rotation → Tiết kiệm thời gian và chi phí nhất.
  ✅ Hoàn hảo khớp yêu cầu!

❌ 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/sai với lý do chi tiết:

• Move the data to the S3 bucket. Use server-side encryption with Amazon S3 managed encryption keys (SSE-S3). Use the built-in key rotation behavior of SSE-S3 encryption keys.
  ✅ Đúng (như đã giải thích ở trên). Giải pháp đơn giản nhất, S3 tự rotate key hàng năm mà không cần overhead quản lý.

• Create an AWS Key Management Service (AWS KMS) customer managed key. Enable automatic key rotation. Set the S3 bucket’s default encryption behavior to use the customer managed KMS key. Move the data to the S3 bucket.
  ❌ Sai: Mặc dù hỗ trợ auto rotation (cho customer managed keys từ 2018 và cập nhật 2026), nhưng cần tạo key trong KMS, enable rotation, và cấu hình bucket default encryption → Overhead cao hơn SSE-S3 (quản lý IAM permissions, audit logs KMS, chi phí KMS API calls). Không phải "least overhead".

• Create an AWS Key Management Service (AWS KMS) customer managed key. Set the S3 bucket’s default encryption behavior to use the customer managed KMS key. Move the data to the S3 bucket. Manually rotate the KMS key every year.
  ❌ Sai: Tương tự phương án trước, nhưng manual rotation yêu cầu can thiệp thủ công hàng năm (tạo alias mới, re-encrypt data) → Overhead rất cao, không tự động, dễ lỗi. Vi phạm yêu cầu "automatic rotation" và không phải least overhead.

• Encrypt the data with customer key material before moving the data to the S3 bucket. Create an AWS Key Management Service (AWS KMS) key without key material. Import the customer key material into the KMS key. Enable automatic key rotation.
  ❌ Sai: Đây là client-side encryption với imported key material vào KMS (hỗ trợ auto rotation cho imported keys từ 2023+), nhưng quy trình phức tạp: encrypt trước khi upload, tạo KMS key "externally sourced", import material → Overhead cực cao (quản lý client-side tools như AWS Encryption SDK, re-encrypt khi rotate, chi phí upload cao hơn). Không phải server-side thuần túy và không least overhead.

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

• Amazon S3 Server-Side Encryption → Chi tiết SSE-S3 rotation.
• AWS KMS Key Rotation → So sánh auto/manual rotation.
• S3 Bucket Default Encryption.
• DOP-C02 Exam Guide: Nhấn mạnh SSE-S3 cho least overhead encryption.

Hy vọng phân tích này giúp bạn ôn thi AWS DevOps Professional hiệu quả! 🚀 Nếu cần thêm câu hỏi, cứ hỏi nhé!

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

Câu hỏi mô tả một hệ thống xử lý yêu cầu đặt lịch hẹn cho khách hàng của công ty tài chính:

• Khách hàng gửi SMS để yêu cầu đặt lịch với cố vấn tài chính.
• Một web application chạy trên Amazon EC2 nhận yêu cầu này và publish tin nhắn vào Amazon SQS queue.
• Một ứng dụng khác chạy trên EC2 đọc từ SQS, gửi lời mời họp (meeting invitations) và email xác nhận cho khách hàng, sau đó lưu thông tin cuộc họp vào Amazon DynamoDB.

🔍 Vấn đề chính: Khi công ty mở rộng (scale up), khách hàng phàn nàn rằng lời mời họp đến chậm hơn (meeting invitations taking longer to arrive).
Điều này chỉ ra bottleneck nằm ở giai đoạn xử lý SQS queue và gửi invitation từ ứng dụng EC2 thứ hai, vì lượng yêu cầu tăng dẫn đến queue backlog (hàng đợi tích tụ).
🛠️ Mục tiêu: Solutions Architect cần đề xuất giải pháp tối ưu hóa throughput của ứng dụng xử lý queue để giảm độ trễ (latency) mà không ảnh hưởng các phần khác.

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

• AWS Well-Architected Framework: Reliability Pillar (Queue-based scaling).
• AWS Docs: Auto Scaling for EC2 with Amazon SQS (cập nhật 2024-2026).
• AWS Best Practices: Scaling based on SQS ApproximateNumberOfMessages metric via Amazon CloudWatch.

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

Đáp án đúng: Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue.

Lý do:

• Vấn đề cốt lõi là queue depth (số lượng tin nhắn tích tụ trong SQS) tăng cao do ứng dụng gửi invitation không scale kịp với lượng yêu cầu.
• Thêm Auto Scaling Group (ASG) cho fleet EC2 chạy ứng dụng này, và cấu hình scale dựa trên metric "ApproximateNumberOfMessages" từ CloudWatch (queue depth), sẽ tự động tăng/giảm instances để xử lý queue nhanh chóng.
• Đây là best practice của AWS cho decouple systems: Producer (web app) đẩy vào SQS, Consumer (invitation app) scale theo queue backlog → Giảm delay hiệu quả, chi phí tối ưu (scale out/in tự động).
• ✅ Hiệu quả ngay lập tức cho bottleneck đã xác định, không cần thay đổi kiến trúc lớn.

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

• Add a DynamoDB Accelerator (DAX) cluster in front of the DynamoDB database.
  ❌ Sai: DAX là in-memory cache cho DynamoDB, giúp tăng tốc read latency (đọc dữ liệu nhanh hơn 10x). Tuy nhiên, bottleneck ở đây là xử lý SQS và gửi email/invitation, KHÔNG phải đọc/ghi DynamoDB (chỉ lưu sau khi gửi thành công). Thêm DAX không giải quyết queue backlog, thậm chí lãng phí nếu workload DynamoDB không phải read-heavy.

• Add an Amazon API Gateway API in front of the web application that accepts the appointment requests.
  ❌ Sai: API Gateway giúp quản lý API, throttling, caching cho frontend requests (nhận SMS qua web app). Nhưng vấn đề KHÔNG nằm ở web app nhận yêu cầu (không delay ở bước publish SQS), mà ở consumer app xử lý queue. Thêm Gateway chỉ scale phần đầu, không chạm đến delay invitation.

• Add an Amazon CloudFront distribution. Set the origin as the web application that accepts the appointment requests.
  ❌ Sai: CloudFront là CDN cho static/dynamic content caching, giảm latency global cho web app nhận request. Tuy nhiên: (1) Delay không ở accept requests mà ở xử lý queue sau; (2) Web app EC2 xử lý business logic (publish SQS), không phải static → CloudFront ít lợi ích; (3) Không giải quyết consumer scaling.

• Add an Auto Scaling group for the application that sends meeting invitations. Configure the Auto Scaling group to scale based on the depth of the SQS queue.
  ✅ Đúng: Như giải thích ở trên. Đây là giải pháp target trực tiếp bottleneck, sử dụng CloudWatch Alarm trên SQS queue depth để trigger ASG scale out (tăng instances khi queue > threshold, ví dụ 1000 messages). Đảm bảo high availability và cost-effective theo AWS patterns mới nhất (2026).

🛠️ Khuyến nghị bổ sung: Sau triển khai, monitor với CloudWatch Dashboard (SQS metrics: ApproximateNumberOfMessagesVisible, NumberOfMessagesSent) và X-Ray để trace end-to-end latency. Nếu cần, kết hợp SQS FIFO cho ordering nếu business yêu cầu.

🧩 Giải thích nội dung câu hỏi
Câu hỏi mô tả một công ty bán lẻ trực tuyến lớn với hơn 50 triệu khách hàng hoạt động và hơn 25.000 đơn hàng mỗi ngày. Dữ liệu mua hàng (purchase data) được lưu trữ trong Amazon S3, còn dữ liệu khách hàng bổ sung nằm trong Amazon RDS.
Công ty muốn:

• Làm cho tất cả dữ liệu có sẵn cho các đội ngũ để thực hiện analytics (phân tích dữ liệu).
• Hỗ trợ quản lý quyền truy cập chi tiết (fine-grained permissions) cho dữ liệu.
• Giảm thiểu overhead vận hành (operational overhead) – nghĩa là giải pháp phải tự động hóa cao, ít quản lý thủ công.
  Đây là yêu cầu điển hình cho một data lake quy mô lớn trên AWS, cần tích hợp dữ liệu từ S3 và RDS, với kiểm soát truy cập tinh tế và không tốn công quản lý hạ tầng.

✅ Đáp án đúng và lý do lựa chọn
Đáp án đúng: Create a data lake by using AWS Lake Formation. Create an AWS Glue JDBC connection to Amazon RDS. Register the S3 bucket in Lake Formation. Giải thích:

• AWS Lake Formation (cập nhật đến 2026) là dịch vụ quản lý data lake serverless, tích hợp trực tiếp với S3 (đăng ký bucket) và RDS (qua Glue JDBC connection).
• Nó cung cấp fine-grained access controls (quyền truy cập cấp cột, hàng, database/table) qua Lake Formation Permissions, dễ dàng quản lý cho nhiều team.
• Minimize operational overhead: Không cần quản lý cluster, tự động catalog dữ liệu qua Glue, hỗ trợ query bằng Athena/Spectrum mà không copy dữ liệu thủ công.
  Giải pháp này khớp hoàn hảo yêu cầu, tuân thủ best practices AWS cho data lake quy mô lớn.

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 ✅ cho đúng và ❌ cho sai, kèm giải thích rõ ràng:

• ❌ Migrate the purchase data to write directly to Amazon RDS. Use RDS access controls to limit access.
  Giải thích sai: Di chuyển dữ liệu mua hàng lớn (25k orders/ngày) từ S3 sang RDS không phù hợp vì RDS là OLTP database, không scale tốt cho analytics lớn (chi phí cao, performance kém với volume petabyte). RDS access controls chỉ cơ bản (user/role), không fine-grained như data lake. Tăng operational overhead do migrate và quản lý schema.

• ❌ Schedule an AWS Lambda function to periodically copy data from Amazon RDS to Amazon S3. Create an AWS Glue crawler. Use Amazon Athena to query the data. Use S3 policies to limit access.
  Giải thích sai: Copy dữ liệu từ RDS sang S3 bằng Lambda định kỳ gây operational overhead cao (quản lý Lambda, schedule, error handling, dữ liệu delay). S3 bucket policies chỉ kiểm soát bucket-level/object-level, không fine-grained (không cấp cột/hàng). Glue + Athena tốt cho query nhưng thiếu centralized governance cho permissions đa team.

• ✅ Create a data lake by using AWS Lake Formation. Create an AWS Glue JDBC connection to Amazon RDS. Register the S3 bucket in Lake Formation. Use Lake Formation access controls to limit access.
  Giải thích đúng: Như đã phân tích ở trên. Lake Formation (phiên bản mới nhất 2026 hỗ trợ hybrid data lakes tốt hơn) tạo data lake thống nhất, tích hợp S3/RDS mà không copy dữ liệu, permissions chi tiết (column-level, tag-based), serverless hoàn toàn – lý tưởng cho 50M customers.

• ❌ Create an Amazon Redshift cluster. Schedule an AWS Lambda function to periodically copy data from Amazon S3 and Amazon RDS to Amazon Redshift. Use Amazon Redshift access controls to limit access.
  Giải thích sai: Redshift là data warehouse tốt cho analytics nhưng yêu cầu provision cluster (overhead cao: scaling, maintenance, cost idle). Copy dữ liệu bằng Lambda định kỳ gây delay và quản lý phức tạp. Redshift access controls (VPC/ IAM) chưa fine-grained bằng Lake Formation cho data lake đa nguồn.

🛠️ Lời khuyên thực hành

• Sử dụng Lake Formation kết hợp Athena/QuickSight cho analytics nhanh.
• Theo dõi chi phí qua AWS Cost Explorer, vì data lake scale lớn.

📘 Tài liệu tham khảo

• AWS Lake Formation Documentation: https://docs.aws.amazon.com/lake-formation/latest/dg/what-is-lake-formation.html (cập nhật 2026: Enhanced hybrid integrations).
• AWS Well-Architected Framework - Data Analytics Lens: https://aws.amazon.com/architecture/well-architected?lens=data-analytics.
• Exam Guide DOP-C02 (DevOps Professional 2024+): Nhấn mạnh Lake Formation cho data governance.

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

Câu hỏi mô tả một công ty đang host website marketing tĩnh (chỉ chứa tài liệu static như HTML, CSS, JS, hình ảnh) trên on-premises data center với một server duy nhất. Quản trị viên cập nhật nội dung không thường xuyên và sử dụng SFTP client để upload file mới.

Bây giờ, công ty muốn chuyển sang AWS, sử dụng Amazon CloudFront làm CDN để phân phối nội dung. Solutions architect đã tạo CloudFront distribution, và nhiệm vụ là thiết kế origin (nguồn gốc nội dung cho CloudFront) sao cho:

• Cost-effective nhất (tiết kiệm chi phí).
• Resilient nhất (bền bỉ, khả năng chịu lỗi cao).

📌 Yêu cầu chính: Website tĩnh → ưu tiên giải pháp serverless, không cần server luôn chạy; tích hợp tốt với CloudFront; hỗ trợ upload nội dung (tương tự SFTP nhưng tối ưu hơn). Kiến thức cập nhật đến 2026: AWS ưu tiên S3 + CloudFront cho static website với Origin Access Control (OAC) (thay thế OAI từ 2022, nhưng OAI vẫn hỗ trợ legacy).

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

Đáp án đúng: Create a private Amazon S3 bucket. Use an S3 bucket policy to allow access from a CloudFront origin access identity (OAI). Upload website content by using the AWS CLI.

Lý do:

• Cost-effective: S3 là serverless, chỉ tính phí storage + requests, không tốn server idle. Rẻ hơn Lightsail/EC2/ASG.
• Resilient: S3 có 99.999999999% durability, multi-AZ, tự động replicate. Private bucket + OAI/OAC đảm bảo chỉ CloudFront truy cập được, an toàn cao.
• Phù hợp: Upload bằng AWS CLI (tương đương SFTP, dễ script hóa, hỗ trợ batch). Hoàn hảo cho static content với CloudFront origin.
• Cập nhật 2026: AWS khuyến nghị OAC thay OAI, nhưng OAI vẫn work và là lựa chọn chuẩn trong exam DOP-C02.

🛠️ 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 một cách chi tiết. Tôi giữ nguyên nội dung 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.

• ❌ Create a virtual server by using Amazon Lightsail. Configure the web server in the Lightsail instance. Upload website content by using an SFTP client.
  Phương án này sai vì: Lightsail là VPS đơn giản (giống EC2 nhỏ), tốn phí fixed (instance luôn chạy ~$3.5/tháng trở lên), không serverless → kém cost-effective cho static site. Resilient thấp (single instance, cần manual backup). SFTP ok nhưng không tối ưu bằng S3. Không resilient bằng S3 multi-AZ.

• ❌ Create an AWS Auto Scaling group for Amazon EC2 instances. Use an Application Load Balancer. Upload website content by using an SFTP client.
  Phương án này sai vì: ASG + ALB + EC2 quá phức tạp/overkill cho static site, tốn kém cao (EC2 instances + ALB data processing ~$20+/tháng + traffic). Auto Scaling không cần vì traffic static thấp. Resilient tốt nhưng không phải "most cost-effective". SFTP cần config EFS/shared storage phức tạp.

• ✅ Create a private Amazon S3 bucket. Use an S3 bucket policy to allow access from a CloudFront origin access identity (OAI). Upload website content by using the AWS CLI.
  Phương án này đúng vì: S3 private + OAI (hoặc OAC mới) tích hợp hoàn hảo với CloudFront, chỉ cho phép CloudFront pull content → secure & resilient (S3 11 9's durability). Cost thấp nhất (~$0.023/GB storage + requests). AWS CLI upload nhanh, scriptable, thay thế SFTP hiệu quả. Lý tưởng cho static website.

• ❌ Create a public Amazon S3 bucket. Configure AWS Transfer for SFTP. Configure the S3 bucket for website hosting. Upload website content by using the SFTP client.
  Phương án này sai vì: Public bucket dễ bị access unauthorized → kém secure/resilient (không khuyến khích với CloudFront). AWS Transfer for SFTP tốn phí cao (~$0.30/GB transfer + $0.04/giờ endpoint). Static website hosting trên S3 chỉ cho direct access, không tối ưu làm CloudFront origin (cần private + OAI). Cost cao hơn S3 CLI thuần.

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

• AWS Documentation: Host a static website using S3 and CloudFront – Chi tiết OAI/OAC setup.
• Best Practices: AWS Well-Architected Framework - Cost Optimization Pillar – Ưu tiên S3 cho static.
• Exam Guide DOP-C02: AWS re:Post & A Cloud Guru – Xác nhận pattern S3 + CloudFront là standard cho static origins.
• Cập nhật mới: Origin Access Control (OAC) từ 2022 docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html.

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 Terraform/CLI, hãy hỏi nhé!