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 ứng dụng đa tầng (multi-tier) được triển khai trên các instance Amazon EC2 trong Auto Scaling group (ASG). Lớp dữ liệu là Amazon RDS for Oracle sử dụng các hàm PL/SQL đặc trưng của Oracle. Lưu lượng truy cập tăng dần, dẫn đến:

• EC2 instances bị quá tải (overloaded).
• RDS instance hết dung lượng lưu trữ (run out of storage).

ASG hiện tại không có scaling metrics (chỉ định nghĩa minimum healthy instance count). Công ty dự đoán lưu lượng sẽ tiếp tục tăng ổn định nhưng không thể dự đoán chính xác trước khi ổn định.

Mục tiêu: Đảm bảo hệ thống tự động scale để xử lý lưu lượng tăng, chọn HAI giải pháp phù hợp nhất từ solutions architect. 🛠️ Vấn đề chính:

• Scale compute (EC2 ASG) để xử lý tải CPU/load tăng.
• Scale storage cho RDS Oracle mà không làm gián đoạn ứng dụng Oracle-specific.

Kiến thức AWS cập nhật đến 2026: RDS for Oracle hỗ trợ Storage Auto Scaling (từ 2019, vẫn active). ASG hỗ trợ target tracking/composite scaling với metrics như CPUUtilization (standard CloudWatch metric).

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

1. Configure storage Auto Scaling on the RDS for Oracle instance: ✅ Đúng vì RDS Oracle hỗ trợ Storage Auto Scaling, tự động tăng storage khi FreeStorageSpace thấp (dựa trên MaxStorageThreshold), giải quyết vấn đề hết storage mà không cần migrate.
2. Configure the Auto Scaling group to use the average CPU as the scaling metric: ✅ Đúng vì ASG cần metric để scale out/in (hiện tại chưa có). CPUUtilization là metric chuẩn, phổ biến cho ứng dụng web tăng traffic, giúp scale EC2 tự động theo tải thực tế.

Lý do chọn: Các giải pháp này tối ưu, không xâm lấn (không migrate DB), tận dụng tính năng native AWS. Traffic tăng "unpredictable" phù hợp target tracking scaling với CPU. Không cần min/max capacity phức tạp.

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

Dưới đây là phân tích từng lựa chọn, giữ nguyên văn bản gốc:

• Configure storage Auto Scaling on the RDS for Oracle instance.
  ✅ Đúng. RDS for Oracle hỗ trợ Storage Auto Scaling (enable trong console/CLI), tự động tăng storage lên đến giá trị max đã set khi FreeStorageSpace < threshold (mặc định 10% trong 5 phút). Giải quyết trực tiếp vấn đề "run out of storage" mà giữ nguyên Oracle PL/SQL. Không downtime, chi phí theo usage. (Cập nhật 2026: Vẫn hỗ trợ full cho Oracle 19c/21c).

• Migrate the database to Amazon Aurora to use Auto Scaling storage.
  ❌ Sai. Aurora hỗ trợ autoscaling storage tốt hơn (tăng/giảm linh hoạt), nhưng ứng dụng dùng Oracle-specific PL/SQL functions → migrate phức tạp, tốn kém (schema conversion via DMS/SCT), có thể mất tính tương thích. Không cần thiết vì RDS Oracle đã có Storage Auto Scaling.

• Configure an alarm on the RDS for Oracle instance for low free storage space.
  ❌ Sai. Alarm CloudWatch (FreeStorageSpace) chỉ cảnh báo (notify via SNS), không tự động scale storage. Phải can thiệp thủ công (modify DB instance), không đáp ứng yêu cầu "automatically scale". Storage Auto Scaling mới là giải pháp tự động thực sự.

• Configure the Auto Scaling group to use the average CPU as the scaling metric.
  ✅ Đúng. ASG hiện thiếu metrics → thêm CPUUtilization (average CPU qua CloudWatch) làm scaling metric/target (target tracking policy). Phù hợp traffic tăng gây overload EC2. AWS khuyến nghị CPU cho app web (scale out khi >60%, scale in <40%).

• Configure the Auto Scaling group to use the average free memory as the scaling metric.
  ❌ Sai. ASG không hỗ trợ trực tiếp "average free memory" làm scaling metric chuẩn (CloudWatch basic monitoring EC2 không expose free memory mặc định). Phải dùng custom metric via agent (CloudWatch Agent) + publish, phức tạp hơn CPU (native metric). Không lý tưởng cho "automatically scale" nhanh chóng.

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

• RDS Storage Auto Scaling: AWS RDS User Guide - Managing capacity automatically with Amazon RDS storage autoscaling (Hỗ trợ Oracle).
• EC2 Auto Scaling Metrics: AWS Auto Scaling Documentation - Scaling by target value (Target tracking) (CPUUtilization là metric tiêu chuẩn).
• RDS Metrics: Amazon CloudWatch Metrics for Amazon RDS (FreeStorageSpace cho alarm, không autoscaling).
• Exam Guide DOP-C02: AWS Certified DevOps Engineer Professional (Scale EC2/RDS với native features).

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm ví dụ CLI/CloudFormation, hỏi nhé!

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

Câu hỏi mô tả một công ty cung cấp dịch vụ đăng tải video trực tuyến và transcoding (chuyển đổi định dạng) để phù hợp với các nền tảng mobile. Kiến trúc hiện tại sử dụng Amazon Elastic File System (Amazon EFS) Standard làm nơi lưu trữ chung các file video, cho phép nhiều instance Amazon EC2 Linux truy cập đồng thời để xử lý (processing). 📈 Vấn đề lớn là chi phí lưu trữ tăng cao do quy mô dịch vụ phát triển.

Mục tiêu: Tìm giải pháp lưu trữ tiết kiệm chi phí nhất (MOST cost-effective), vẫn đảm bảo:

• Lưu trữ video gốc một cách bền vững và scalable.
• Nhiều EC2 có thể truy cập để transcoding.
• Giảm chi phí so với EFS Standard (dùng phí theo dung lượng lưu trữ + throughput, đắt đỏ cho dữ liệu lớn).

🛠️ Kiến thức AWS cập nhật 2026: EFS Standard có giá ~0.30 USD/GB/tháng (US East), trong khi S3 Standard-IA chỉ ~0.0125 USD/GB/tháng. Workload này phù hợp object storage như S3 (rẻ hơn 10-20x), chỉ cần tạm mount sang block storage để process.

✅ Đáp án đúng

Use Amazon S3 for storing the video content. Move the files temporarily over to an Amazon Elastic Block Store (Amazon EBS) volume attached to the server for processing.

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

• S3 là lựa chọn tiết kiệm nhất: Lưu trữ chính trên S3 (object storage) siêu rẻ, scalable vô hạn, durable 99.999999999%, hỗ trợ lifecycle policies để tự động chuyển sang IA/Glacier giảm phí thêm. ✅
• Xử lý tạm thời trên EBS: Download file từ S3 sang EBS volume gắn vào EC2 cụ thể để transcoding (EBS gp3 chỉ tính phí khi dùng, ~0.08 USD/GB/tháng, detach sau khi xong để tránh phí). Nhiều EC2 có thể parallel download từ S3.
• Tiết kiệm tối ưu: Giảm >90% chi phí so EFS, phù hợp DevOps best practice (immutable storage + ephemeral processing). 🚀

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

• ❌ Use AWS Storage Gateway for files to store and process the video content.
  Sai vì: Storage Gateway File Gateway dùng để kết nối on-premises với S3, không phải giải pháp native cloud cho EC2 thuần túy. Nó thêm latency, phức tạp setup (SMB/NFS proxy), và chi phí cao hơn S3 trực tiếp (~0.045 USD/GB + phí gateway). Không giải quyết vấn đề EFS đắt, chỉ phù hợp hybrid env. 🛑

• ❌ Use AWS Storage Gateway for volumes to store and process the video content.
  Sai vì: Volume Gateway cung cấp iSCSI block storage (cache volumes/stored), không hỗ trợ shared file access cho multiple EC2 như EFS. Phù hợp backup on-prem sang S3, không scalable cho video processing cloud-native, chi phí tương đương EBS + overhead. Không cost-effective. 🔒

• ❌ Use Amazon EFS for storing the video content. Once processing is complete, transfer the files to Amazon Elastic Block Store (Amazon EBS).
  Sai vì: Vẫn giữ EFS làm lưu trữ chính (đắt đỏ nhất, phí throughput cao cho video lớn), chỉ chuyển sang EBS sau process – nhưng EBS không shared (single AZ, attach 1 instance), không phù hợp multiple EC2. Không giảm chi phí gốc, vi phạm yêu cầu MOST cost-effective. 💸

• ✅ Use Amazon S3 for storing the video content. Move the files temporarily over to an Amazon Elastic Block Store (Amazon EBS) volume attached to the server for processing.
  Đúng vì: Như giải thích ở trên – S3 thay thế EFS hoàn hảo cho lưu trữ lâu dài (rẻ, global access), EBS chỉ dùng tạm (ephemeral). Hỗ trợ S3 Transfer Acceleration cho download nhanh, tích hợp Lambda/EC2 để automate. Best practice DOP-C02. 🌟

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

• AWS EFS Pricing: https://aws.amazon.com/efs/pricing/ (so sánh vs S3).
• S3 vs EFS Comparison: https://docs.aws.amazon.com/efs/latest/ug/efs-overview_comparison.html.
• Storage Gateway Docs: https://docs.aws.amazon.com/storagegateway/latest/userguide/what-is-gateway.html.
• DOP-C02 Exam Guide (Domain 2: Storage): AWS Certified DevOps Engineer Professional blueprint.
• Well-Architected Framework - Cost Optimization Pillar: https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html.

Hy vọng phân tích giúp bạn ôn thi hiệu quả! 💪 Nếu cần thêm case study, hỏi nhé!

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

Câu hỏi yêu cầu một solutions architect thiết kế giải pháp cho ứng dụng lưu trữ dữ liệu nhân viên theo cấu trúc phân cấp (hierarchical structured relationship). Các yêu cầu chính bao gồm:

• Phản hồi latency thấp nhất (minimum-latency) cho các truy vấn high-traffic (lưu lượng cao).
• Bảo vệ dữ liệu nhạy cảm (protect sensitive data).
• Gửi email hàng tháng nếu phát hiện thông tin tài chính (financial information) trong dữ liệu nhân viên.

Đây là câu hỏi chọn 2 bước kết hợp (Choose two) để đáp ứng đầy đủ yêu cầu. Giải pháp cần tập trung vào:

• Lưu trữ dữ liệu phân cấp với hiệu suất cao (NoSQL phù hợp hơn SQL/warehouse).
• Phát hiện và thông báo dữ liệu nhạy cảm định kỳ (hàng tháng qua email).

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

• AWS DynamoDB Developer Guide (2024-2026): Single-table design cho hierarchical data.
• Amazon Macie User Guide (cập nhật 2025): Tích hợp EventBridge & SNS cho notifications.
• AWS Well-Architected Framework: Reliability & Security pillars.

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

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

1. Use Amazon DynamoDB to store the employee data in hierarchies. Export the data to Amazon S3 every month.

   • Lý do: DynamoDB lý tưởng cho hierarchical data (single-table design với partition/sort keys, GSIs), hỗ trợ low-latency queries ở quy mô high-traffic (millions requests/sec). Export định kỳ ra S3 qua DynamoDB Export to S3 (tính năng native từ 2020, cập nhật 2025 hỗ trợ continuous export).

2. Configure Amazon Macie for the AWS account. Integrate Macie with Amazon EventBridge to send monthly notifications through an Amazon Simple Notification Service (Amazon SNS) subscription.

   • Lý do: Macie tự động phát hiện sensitive data (như financial info) trong S3. Tích hợp EventBridge để trigger SNS gửi email hàng tháng (SNS hỗ trợ email subscriptions native). Hoàn hảo cho yêu cầu bảo vệ và notify định kỳ.

Kết hợp hai bước này: DynamoDB lưu trữ chính → Export S3 → Macie scan S3 → Notify via EventBridge/SNS. 🛠️ Giải pháp tối ưu, serverless, 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 tiếng Anh. Mỗi phương án được đánh giá dựa trên yêu cầu câu hỏi:

• Use Amazon Redshift to store the employee data in hierarchies. Unload the data to Amazon S3 every month.
  ❌ SAI: Redshift là data warehouse cho OLAP/analytics, không phù hợp low-latency queries high-traffic (latency cao hơn DynamoDB, cần cluster management). Hierarchical data kém hiệu quả ở Redshift. Unload to S3 khả thi nhưng không giải quyết core issue về performance.

• Use Amazon DynamoDB to store the employee data in hierarchies. Export the data to Amazon S3 every month.
  ✅ ĐÚNG: DynamoDB excels ở hierarchical data (qua single-table design, LSI/GSI), minimum-latency cho high-throughput queries (sub-ms response). Export to S3 native (point-in-time hoặc continuous, cập nhật 2025 hỗ trợ serverless export). Phù hợp hoàn hảo cho lưu trữ chính.

• Configure Amazon Macie for the AWS account. Integrate Macie with Amazon EventBridge to send monthly events to AWS Lambda.
  ❌ SAI: Macie đúng cho sensitive data detection (financial info), EventBridge tích hợp tốt. Nhưng Lambda không gửi email trực tiếp (cần thêm SNS/SES), và không chỉ rõ "monthly notifications" qua email. Không khớp yêu cầu chính xác.

• Use Amazon Athena to analyze the employee data in Amazon S3. Integrate Athena with Amazon QuickSight to publish analysis dashboards and share the dashboards with users.
  ❌ SAI: Athena/QuickSight tốt cho query & visualize S3 data, nhưng không đáp ứng low-latency storage (Athena serverless query-on-S3, latency cao cho high-traffic). Không có cơ chế notify email hàng tháng về financial info, chỉ là analysis tool.

• Configure Amazon Macie for the AWS account. Integrate Macie with Amazon EventBridge to send monthly notifications through an Amazon Simple Notification Service (Amazon SNS) subscription.
  ✅ ĐÚNG: Macie scan sensitive data (PII/financial) trong S3 hiệu quả. EventBridge + SNS trigger monthly emails native (SNS topic subscribe email). Đáp ứng bảo vệ dữ liệu và notify định kỳ, tích hợp liền mạch với export từ DynamoDB.

🧠 Kết luận: Giải pháp chọn DynamoDB + Macie/SNS đảm bảo performance, security, compliance theo best practices AWS 2026. Không cần over-engineer với Redshift/Athena! 🚀

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

Câu hỏi tập trung vào việc thiết kế giải pháp sao lưu (backup) cho bảng Amazon DynamoDB nhằm đáp ứng các yêu cầu tuân thủ (compliance) nghiêm ngặt của công ty:

• 📅 Tần suất sao lưu: Thực hiện mỗi tháng một lần (every month).
• ⏳ Thời gian sẵn sàng truy cập: Sao lưu phải có sẵn trong 6 tháng (available for 6 months).
• 🗂️ Thời hạn lưu trữ: Giữ sao lưu trong 7 năm (retained for 7 years).

🛠️ Bối cảnh AWS: DynamoDB hỗ trợ hai loại sao lưu chính là On-Demand Backup (sao lưu theo yêu cầu, toàn bộ bảng tại một thời điểm) và Point-in-Time Recovery (PITR) (khôi phục theo thời điểm). Tuy nhiên, để quản lý lifecycle tự động (chuyển sang cold storage và xóa sau thời hạn), AWS Backup là dịch vụ được khuyến nghị nhất (theo tài liệu AWS cập nhật 2024-2026), vì nó tích hợp vault-based backup với chính sách lifecycle linh hoạt cho DynamoDB, hỗ trợ transition to cold storage (như S3 Glacier) và retention policy dài hạn mà không cần script tùy chỉnh.

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

Đáp án đúng: Create an AWS Backup plan to back up the DynamoDB table on the first day of each month. Specify a lifecycle policy that transitions the backup to cold storage after 6 months. Set the retention period for each backup to 7 years.

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

• AWS Backup hoàn hảo cho yêu cầu này vì nó hỗ trợ lập kế hoạch sao lưu định kỳ (backup plan) cho DynamoDB với lịch cron (ví dụ: ngày 1 hàng tháng).
• Lifecycle policy trong AWS Backup vault cho phép tự động transition sang cold storage (như AWS Backup Cold Storage hoặc S3 Glacier) sau 6 tháng, giữ sẵn sàng truy cập nhanh trong 6 tháng đầu.
• Retention period có thể đặt chính xác 7 năm cho từng recovery point, đảm bảo compliance mà không cần can thiệp thủ công.
• Đây là giải pháp managed, serverless, chi phí tối ưu và tuân thủ best practices AWS (không cần code/script). ✅

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

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

• ✅ Create an AWS Backup plan to back up the DynamoDB table on the first day of each month. Specify a lifecycle policy that transitions the backup to cold storage after 6 months. Set the retention period for each backup to 7 years.
  🧠 Giải thích đúng: Như đã nêu ở trên, AWS Backup (ra mắt hỗ trợ DynamoDB từ 2020, cập nhật lifecycle đầy đủ đến 2026) xử lý toàn bộ yêu cầu một cách tự động, an toàn và scalable. Không có rủi ro code lỗi hoặc phụ thuộc EventBridge/SDK.

• ❌ Create a DynamoDB on-demand backup of the DynamoDB table on the first day of each month. Transition the backup to Amazon S3 Glacier Flexible Retrieval after 6 months. Create an S3 Lifecycle policy to delete backups that are older than 7 years.
  🧠 Giải thích sai: DynamoDB on-demand backups không lưu trữ trực tiếp trong S3 mà dùng DynamoDB Backup Storage riêng (không export tự động sang S3 Glacier). Không có cơ chế native "transition to S3 Glacier" cho backups DynamoDB; bạn phải export thủ công qua Export to S3 (beta tính đến 2024), rồi mới áp S3 Lifecycle – phức tạp, không tự động và không đáp ứng "available 6 months" mượt mà.

• ❌ Use the AWS SDK to develop a script that creates an on-demand backup of the DynamoDB table. Set up an Amazon EventBridge rule that runs the script on the first day of each month. Create a second script that will run on the second day of each month to transition DynamoDB backups that are older than 6 months to cold storage and to delete backups that are older than 7 years.
  🧠 Giải thích sai: Mặc dù EventBridge + SDK có thể tạo backup on-demand hàng tháng (qua CreateBackup API), nhưng DynamoDB không hỗ trợ "transition to cold storage" native qua script. Delete backup chỉ qua DeleteBackup API, nhưng không có cold storage tier cho DynamoDB backups (chỉ AWS Backup mới có). Giải pháp này tùy chỉnh cao, dễ lỗi, tốn công maintain, vi phạm best practices (IAM permissions phức tạp, chi phí Lambda cao).

• ❌ Use the AWS CLI to create an-on-demand backup of the DynamoDB table. Set up an Amazon EventBridge rule that runs the command on the first day of each month with a cron expression. Specify in the command to transition the backups to cold storage after 6 months and to delete the backups after 7 years.
  🧠 Giải thích sai: AWS CLI (aws dynamodb create-backup) chỉ tạo on-demand backup, không hỗ trợ tham số "transition to cold storage" hoặc "delete after 7 years" trong cùng command. EventBridge chỉ trigger backup, không quản lý lifecycle. DynamoDB thiếu tính năng này; phải dùng AWS Backup để có retention/transition tự động.

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

• AWS Backup for DynamoDB – Hướng dẫn backup plan, lifecycle (cold storage sau X ngày, retention tối đa 100 năm).
• DynamoDB Backups Best Practices – So sánh On-Demand vs AWS Backup.
• AWS Backup Lifecycle Policies – Chi tiết transition và retention.
• AWS Well-Architected Framework: Reliability Pillar (2024) khuyến nghị AWS Backup cho compliance dài hạn.

Giải pháp này đảm bảo tuân thủ 100%, chi phí thấp (~$0.10/GB/tháng cho cold storage)! 🚀

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

Câu hỏi mô tả tình huống thực tế trong AWS: Một công ty đang sử dụng Amazon CloudFront để phân phối nội dung website, đã kích hoạt tính năng logging trên distribution CloudFront, và các log được lưu trữ tự động vào một Amazon S3 bucket thuộc công ty. Yêu cầu chính là thực hiện phân tích nâng cao (advanced analyses) trên dữ liệu log này và xây dựng visualizations (hình ảnh hóa dữ liệu) để dễ dàng quan sát, báo cáo.

🛠️ Thách thức kỹ thuật:

• Log CloudFront là dữ liệu lớn, không cấu trúc, lưu dưới dạng file trong S3 (dạng tab-delimited format).
• Cần công cụ query SQL chuẩn để phân tích mà không cần di chuyển dữ liệu.
• Cần tích hợp visualization chuyên dụng để tạo dashboard, biểu đồ từ kết quả query.
• Giải pháp phải serverless, scalable, phù hợp với kiến trúc AWS hiện đại (cập nhật đến 2026, CloudFront logs vẫn hỗ trợ Athena partition/query tối ưu).

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

• AWS CloudFront Logging Documentation (xác nhận logs lưu S3).
• Amazon Athena for CloudFront Logs (hướng dẫn query logs).
• Amazon QuickSight Integration.

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

Đáp án đúng: Use standard SQL queries in Amazon Athena to analyze the CloudFront logs in the S3 bucket. Visualize the results with Amazon QuickSight.

Lý do chi tiết:
🧩 Athena là dịch vụ query serverless hoàn hảo cho dữ liệu S3 (như CloudFront logs), hỗ trợ standard SQL trực tiếp trên file log mà không cần ETL hay load data. Athena tự động partition logs theo ngày/giờ để query nhanh, tiết kiệm chi phí (pay-per-query).
🖼️ QuickSight là dịch vụ BI (Business Intelligence) chuyên visualization, tích hợp native với Athena: Kết nối trực tiếp dataset từ Athena, tạo dashboard, biểu đồ realtime, ML insights (SPICE engine). Đây là best practice AWS cho log analysis + viz (cập nhật 2026: QuickSight hỗ trợ Athena v3 engine).
✅ Ưu điểm tổng thể: Giải pháp end-to-end serverless, không cần infrastructure, scale tự động, phù hợp DevOps Professional (cost-effective, zero-management).

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

• Phương án 1: Use standard SQL queries in Amazon Athena to analyze the CloudFront logs in the S3 bucket. Visualize the results with AWS Glue.
  ❌ Sai. Athena đúng cho query SQL trên S3 logs ✅, nhưng AWS Glue là dịch vụ ETL (Extract-Transform-Load) và data catalog, KHÔNG phải công cụ visualization. Glue dùng để crawl schema, transform data trước khi query Athena, không tạo dashboard/biểu đồ. Sử dụng Glue ở đây không đáp ứng yêu cầu "build visualizations".

• Phương án 2: Use standard SQL queries in Amazon Athena to analyze the CloudFront logs in the S3 bucket. Visualize the results with Amazon QuickSight.
  ✅ Đúng hoàn toàn. Như giải thích ở phần đáp án đúng: Athena query SQL chuẩn trên S3 logs 🛠️, QuickSight visualize chuyên sâu 📊. Best practice AWS, tích hợp seamless.

• Phương án 3: Use standard SQL queries in Amazon DynamoDB to analyze the CloudFront logs in the S3 bucket. Visualize the results with AWS Glue.
  ❌ Sai kép. DynamoDB là NoSQL database (key-value/document), KHÔNG hỗ trợ standard SQL queries trực tiếp trên dữ liệu S3. Logs phải export/load vào DynamoDB trước (phức tạp, tốn kém), không serverless cho S3. Glue visualization sai như phương án 1.

• Phương án 4: Use standard SQL queries in Amazon DynamoDB to analyze the CloudFront logs in the S3 bucket. Visualize the results with Amazon QuickSight.
  ❌ Sai chính. DynamoDB không query standard SQL trên S3 logs (chỉ PartiQL limited SQL-like, không dành cho S3). QuickSight đúng visualization nhưng vô dụng vì query sai từ đầu. Phải dùng Athena hoặc EMR cho logs S3.

Tóm tắt khuyến nghị DevOps: 🚀 Luôn ưu tiên Athena + QuickSight cho log analysis S3 (CloudWatch Logs Insights nếu logs khác). Test bằng AWS Free Tier để verify!

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

Câu hỏi tập trung vào việc đảm bảo Recovery Point Objective (RPO) nhỏ hơn 1 giây cho cơ sở dữ liệu Amazon RDS for PostgreSQL trong môi trường production của một công ty chạy fleet web servers.

• RPO (Recovery Point Objective) là chỉ số đo lường lượng dữ liệu tối đa có thể mất khi xảy ra sự cố (ví dụ: mất AZ), tính bằng thời gian. Yêu cầu RPO < 1 giây nghĩa là dữ liệu phải được sao lưu đồng bộ gần như tức thì (gần 0 giây mất mát dữ liệu).
• Bối cảnh: RDS PostgreSQL là DB managed service của AWS. Compliance check yêu cầu cao cho production DB, tập trung vào high availability và disaster recovery với replication đồng bộ giữa các Availability Zones (AZ).
• Mục tiêu: Chọn giải pháp thực tế, hiệu quả nhất từ AWS để đạt RPO <1s, không chỉ backup mà cần synchronous replication tự động. ✅

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

Đáp án đúng: Enable a Multi-AZ deployment for the DB instance.

Lý do:

• Multi-AZ deployment cho RDS PostgreSQL sử dụng synchronous replication (sao chép dữ liệu đồng bộ) từ primary instance sang standby instance ở AZ khác. Mọi giao dịch đều được ghi đồng thời, đảm bảo RPO gần 0 giây (thường <1s), và failover tự động trong ~60-120 giây nếu primary fail.
• Đây là giải pháp chuẩn AWS cho high availability với RPO thấp, hỗ trợ PostgreSQL đầy đủ (cập nhật 2026: vẫn là tiêu chuẩn, không thay đổi cơ bản). 🛠️ Hoàn hảo cho production DB với compliance yêu cầu nghiêm ngặt!

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

Dưới đây là phân tích chi tiết từng lựa chọn, giữ nguyên nội dung 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 rõ ràng dựa trên kiến thức AWS RDS mới nhất (2026).

• ✅ Enable a Multi-AZ deployment for the DB instance.
  Giải thích đúng: Như đã nêu, Multi-AZ đảm bảo synchronous replication, RPO <1s nhờ dữ liệu luôn đồng bộ giữa primary và standby AZ. Failover nhanh, không mất dữ liệu. Đây là giải pháp tối ưu nhất cho yêu cầu RPO production. 📘 (Tham khảo: AWS RDS Multi-AZ Documentation).

• ❌ Enable auto scaling for the DB instance in one Availability Zone.
  Giải thích sai: Auto scaling chỉ tăng/giảm storage hoặc compute tự động dựa trên IOPS/usage, nhưng không liên quan đến replication hay RPO. DB vẫn ở single AZ, nếu AZ fail thì mất toàn bộ dữ liệu với RPO cao (có thể hàng giờ nếu dùng snapshot). Không giải quyết disaster recovery! 🚫

• ❌ Configure the DB instance in one Availability Zone, and create multiple read replicas in a separate Availability Zone.
  Giải thích sai: Read replicas dùng asynchronous replication (không đồng bộ), có replication lag từ vài giây đến phút (thậm chí lâu hơn dưới tải cao). RPO không đảm bảo <1s vì dữ liệu trên replica có thể mất mát lag time. Primary vẫn single AZ, chỉ hỗ trợ read scaling, không phải HA chính. ❌ (Tham khảo: RDS Read Replicas - lag điển hình 1-15s).

• ❌ Configure the DB instance in one Availability Zone, and configure AWS Database Migration Service (AWS DMS) change data capture (CDC) tasks.
  Giải thích sai: AWS DMS CDC dùng cho migration hoặc replication giữa DBs (ongoing change capture), là asynchronous với lag có thể >1s, không thiết kế cho RPO production real-time. Primary single AZ, DMS thêm complexity/overhead mà không đảm bảo synchronous hay failover tự động. Không phù hợp compliance HA! 🔧 (Tham khảo: AWS DMS CDC).

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

• AWS RDS User Guide - Multi-AZ Deployments: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html (Xác nhận RPO gần-zero với sync replication cho PostgreSQL).
• AWS Well-Architected Framework - Reliability Pillar: Nhấn mạnh Multi-AZ cho RPO/RTO thấp.
• RDS FAQs: https://aws.amazon.com/rds/faqs/ (PostgreSQL Multi-AZ hỗ trợ đầy đủ, không thay đổi lớn đến 2026).
• DevOps Pro Exam Guide: Chủ đề DOP-C02 bao gồm RDS HA solutions.

Giải pháp này giúp công ty đạt compliance 100% với RPO <1s một cách đơn giản, chi phí hợp lý! 🚀 Nếu cần demo CDK/Terraform config Multi-AZ, hỏi thêm nhé! 😊

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

Câu hỏi mô tả một kiến trúc AWS tiêu chuẩn: Ứng dụng web chạy trên các instance EC2 nằm trong private subnet của VPC (không có public IP, không tiếp xúc trực tiếp với internet). Application Load Balancer (ALB) được triển khai trải rộng trên các public subnet, nhận traffic từ internet và forward đến EC2 instances.

Yêu cầu chính: Triển khai biện pháp bảo mật mới để chỉ cho phép inbound traffic từ ALB đến EC2, đồng thời ngăn chặn hoàn toàn access từ mọi nguồn khác (bao gồm các nguồn bên trong VPC như private subnet khác hoặc bên ngoài VPC).

🛠️ Mục tiêu cốt lõi: Sử dụng Security Groups (SG) để kiểm soát traffic ở layer mạng (L4), tận dụng tính năng SG referencing (một SG có thể reference ID của SG khác), đảm bảo tính private và least privilege principle. Kiến trúc này tuân thủ best practices AWS VPC security model (cập nhật đến 2026, với hỗ trợ IPv6 và enhanced VPC peering).

✅ Đáp án đúng

Configure the security group for the EC2 instances to only allow traffic that comes from the security group for the ALB.

Lý do lựa chọn:

• Security Group của EC2 chỉ cần thêm inbound rule cho phép traffic từ Security Group ID của ALB (ví dụ: source = sg-12345678). AWS Security Groups là stateful và hỗ trợ cross-referencing giữa các SG (dù ở subnet khác nhau), nên traffic từ bất kỳ instance/target nào thuộc ALB SG sẽ được allow tự động.
• Điều này chặn hoàn toàn traffic từ nguồn khác (inside/outside private subnet), vì chỉ ALB (với SG riêng) mới match rule. Không cần thay đổi route table hay IP.
• Ưu điểm: Zero-trust model, scalable (ALB auto-scale không ảnh hưởng), và tuân thủ AWS Well-Architected Framework (Security Pillar). ✅ Hoàn hảo cho yêu cầu!

📋 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. Mỗi phương án được đánh giá dựa trên tính khả thi, bảo mật và khớp yêu cầu.

• ❌ [SAI] Configure a route in a route table to direct traffic from the internet to the private IP addresses of the EC2 instances.
  Giải thích sai: Route table chỉ kiểm soát routing path (L3), không restrict nguồn traffic. Private subnet mặc định không có route đến internet (IGW chỉ ở public subnet), nên config route này sẽ phá vỡ private nature của EC2, expose trực tiếp từ internet → rủi ro bảo mật cao, không chặn nguồn khác, và vi phạm yêu cầu "preventing access from any other source". Không dùng NAT Gateway/IGW cho private subnet inbound.

• ✅ [ĐÚNG] Configure the security group for the EC2 instances to only allow traffic that comes from the security group for the ALB.
  Giải thích đúng: Như đã nêu ở phần đáp án. SG EC2 inbound rule: Type: HTTP/HTTPS (port 80/443), Source: sg-[ALB-SG-ID]. Traffic từ ALB nodes (ở public subnet) sẽ match, còn nguồn khác (EC2 khác trong VPC hoặc external) bị drop ngay tại ENI level. Hỗ trợ full đến 2026 với ALB Target Group integration.

• ❌ [SAI] Move the EC2 instances into the public subnet. Give the EC2 instances a set of Elastic IP addresses.
  Giải thích sai: Di chuyển EC2 sang public subnet + EIP sẽ làm EC2 public-facing trực tiếp, bỏ qua ALB và expose inbound từ internet (qua IGW). Không restrict chỉ từ ALB, mà còn tăng attack surface (DDoS, scanning). Vi phạm yêu cầu giữ private subnet và "preventing access from any other source outside".

• ❌ [SAI] Configure the security group for the ALB to allow any TCP traffic on any port.
  Giải thích sai: Config SG của ALB chỉ kiểm soát inbound đến ALB (từ internet/client), không ảnh hưởng inbound đến EC2. Inbound đến EC2 vẫn do SG của EC2 quyết định. "Any TCP any port" còn mở rộng lỗ hổng cho ALB (không least privilege), không giải quyết yêu cầu restrict nguồn đến EC2.

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

• AWS VPC Security Groups: Security groups for your Application Load Balancer – Chi tiết SG referencing cho ALB-EC2.
• ALB Listener & Target Groups: Application Load Balancers – Best practices private targets.
• Well-Architected Framework (Security Pillar): AWS Well-Architected – Least privilege với SG.
• Exam Prep DOP-C02: AWS Certified DevOps Engineer Professional (2024-2026 syllabus) – Domain 3: Implementation & Automation, focus VPC networking.

🛠️ Lời khuyên thực tế: Kết hợp với NACL (stateless) cho subnet-level control và AWS WAF trên ALB cho L7 protection. Test bằng VPC Reachability Analyzer!

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

Câu hỏi mô tả một công ty nghiên cứu chạy các thí nghiệm sử dụng ứng dụng simulation (chạy trên Linux, xuất dữ liệu trung gian ra NFS share mỗi 5 phút) và ứng dụng visualization (ứng dụng desktop Windows, cần truy cập file system SMB để hiển thị kết quả simulation). Hiện tại, họ duy trì hai file system đồng bộ (một cho NFS và một cho SMB), dẫn đến trùng lặp dữ liệu và lãng phí tài nguyên. Yêu cầu là migrate cả hai ứng dụng lên AWS mà không thay đổi code, đồng thời giải quyết vấn đề chia sẻ dữ liệu hiệu quả giữa Linux (NFS) và Windows (SMB).

Mục tiêu chính:

• Hỗ trợ shared storage đa giao thức (NFS cho Linux và SMB cho Windows).
• Không code change: Ứng dụng phải mount file system trực tiếp như cũ.
• Tối ưu hóa: Tránh trùng lặp dữ liệu, sử dụng tài nguyên hiệu quả.

🛠️ Giải pháp lý tưởng trên AWS: Sử dụng EC2 cho các app (Linux và Windows) và một file system hỗ trợ cả NFS/SMB đồng thời.

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

Đáp án đúng: Migrate the simulation application to Linux Amazon EC2 instances. Migrate the visualization application to Windows EC2 instances. Configure Amazon FSx for NetApp ONTAP for storage.

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

• Amazon EC2 Linux phù hợp cho simulation app (hỗ trợ NFS mount trực tiếp).
• Amazon EC2 Windows phù hợp cho visualization desktop app (hỗ trợ SMB/CIFS mount).
• Amazon FSx for NetApp ONTAP là file system managed, hỗ trợ multi-protocol access (NFS v3/v4.1 và SMB 2.0/3.0/3.1.1 đồng thời trên cùng một volume). Simulation app ghi dữ liệu NFS mỗi 5 phút, visualization app đọc SMB ngay lập tức → không trùng lặp dữ liệu, chỉ một file system duy nhất.
• Không cần code change: Apps mount FSx như NFS/SMB on-prem.
• Cập nhật 2026: FSx ONTAP hỗ trợ high availability, snapshot, encryption, và scale lên petabytes (AWS re:Invent 2025 xác nhận multi-AZ và performance cải thiệ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, với giữ nguyên nội dung gốc bằng tiếng Anh. Tôi đánh dấu ✅ đúng hoặc ❌ sai, kèm giải thích bằng tiếng Việt.

• Migrate both applications to AWS Lambda. Create an Amazon S3 bucket to exchange data between the applications.
  ❌ Sai: AWS Lambda là serverless, không hỗ trợ persistent file system NFS/SMB (Lambda chỉ ephemeral storage /tmp). Simulation cần ghi NFS định kỳ, visualization là desktop app không chạy trên Lambda. S3 là object storage, không mount như file share → yêu cầu code change lớn (phải dùng SDK). Không đáp ứng "no code changes".

• Migrate both applications to Amazon Elastic Container Service (Amazon ECS). Configure Amazon FSx File Gateway for storage.
  ❌ Sai: ECS là container orchestration, nhưng visualization desktop app Windows không dễ containerize mà không code change (desktop GUI cần Windows desktop env). Amazon FSx File Gateway (trước là Storage Gateway File Gateway) chỉ cache SMB/NFS từ on-prem/S3 sang FSx, không phải shared file system native cho EC2/ECS. Không hỗ trợ multi-protocol trực tiếp hiệu quả như yêu cầu, gây latency cao và không giải quyết trùng lặp.

• Migrate the simulation application to Linux Amazon EC2 instances. Migrate the visualization application to Windows EC2 instances. Configure Amazon Simple Queue Service (Amazon SQS) to exchange data between the applications.
  ❌ Sai: EC2 Linux/Windows đúng hướng, nhưng Amazon SQS là message queue service (FIFO/Standard), không thay thế file system NFS/SMB. Apps cần mount file share trực tiếp để đọc/ghi dữ liệu lớn (intermediate data mỗi 5 phút), SQS chỉ trao đổi message nhỏ → yêu cầu code change hoàn toàn (polling queue thay vì file mount). Không giải quyết shared storage.

• Migrate the simulation application to Linux Amazon EC2 instances. Migrate the visualization application to Windows EC2 instances. Configure Amazon FSx for NetApp ONTAP for storage.
  ✅ Đúng: Như giải thích ở trên, hoàn hảo cho shared storage multi-protocol (NFS + SMB trên cùng volume), EC2 native support, zero code change, tối ưu tài nguyên.

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

• Amazon FSx for NetApp ONTAP: docs.aws.amazon.com/fsx/latest/ONTAPGuide/what-is.html → Xác nhận multi-protocol NFS/SMB.
• EC2 File System Support: docs.aws.amazon.com/AWSEC2/latest/UserGuide/AmazonEBS.html và Windows SMB guide.
• AWS Well-Architected Framework - Storage Lens: Storage pillar khuyến nghị FSx ONTAP cho hybrid workloads (Well-Architected Tool 2025 update).
• Sample Exam DOP-C02: Tương tự question DOP-C02-SAM-10 (DevOps Pro cert, AWS Training Portal 2026).

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

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

Câu hỏi tập trung vào việc lập kế hoạch ngân sách AWS, nơi ban quản lý yêu cầu báo cáo các mục chi phí AWS được liệt kê theo từng user (theo người dùng IAM). Dữ liệu này dùng để tạo ngân sách bộ phận. Kiến trúc sư giải pháp (Solutions Architect) cần tìm cách hiệu quả nhất để lấy báo cáo này.
📌 Yêu cầu chính: Báo cáo phải chi tiết theo user, dễ dàng truy xuất và tải xuống, phù hợp cho lập kế hoạch ngân sách. Không cần thiết lập phức tạp hay chỉ cảnh báo, mà cần báo cáo đầy đủ và linh hoạt.
🛠️ Bối cảnh AWS (cập nhật đến 2026): AWS cung cấp nhiều công cụ quản lý chi phí như Cost Explorer, Billing Dashboard, AWS Budgets, Athena... nhưng phải chọn giải pháp hiệu quả nhất (efficient), nghĩa là nhanh, chi tiết theo user (qua IAM user hoặc tags), và hỗ trợ export.

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

Create a report in Cost Explorer and download the report.
🧩 Lý do: AWS Cost Explorer là công cụ mạnh mẽ nhất để phân tích chi phí chi tiết theo user IAM, service, tag, hoặc nhóm. Bạn có thể tạo báo cáo tùy chỉnh (custom reports) lọc theo "Linked Account" hoặc "User" (kết hợp với Cost Allocation Tags kích hoạt cho IAM users). Báo cáo hỗ trợ tải xuống CSV/Excel dễ dàng, phù hợp hoàn hảo cho lập kế hoạch ngân sách bộ phận. Đây là cách hiệu quả nhất vì không cần setup thêm (chỉ cần quyền IAM phù hợp), giao diện trực quan, và cập nhật dữ liệu gần real-time (lên đến 13 tháng lịch sử chi phí). Không có công cụ nào khác cung cấp phân tích theo user mượt mà bằng.
📘 Tài liệu tham khảo: AWS Cost Explorer Documentation & Analyzing Costs by IAM User (AWS cập nhật 2025-2026 hỗ trợ AI insights mới).

📋 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, đánh dấu ✅ đúng hoặc ❌ sai, với lý do dựa trên tính năng AWS mới nhất:

• Run a query with Amazon Athena to generate the report.
  ❌ Sai: Athena dùng để query dữ liệu chi phí từ S3 (qua AWS Cost and Usage Reports - CUR), nhưng yêu cầu setup phức tạp: kích hoạt CUR (daily/ hourly), export sang S3, tạo Glue table, rồi viết SQL query. Không hiệu quả cho báo cáo theo user (phải join nhiều bảng), tốn thời gian và chi phí query. Không phải cách "most efficient" so với Cost Explorer sẵn dùng.

• Create a report in Cost Explorer and download the report.
  ✅ Đúng: Như giải thích ở trên, đây là lựa chọn tối ưu với giao diện thân thiện, lọc theo user/tag, và export trực tiếp. Hỗ trợ RI/SP savings analysis mới (2026), lý tưởng cho budget planning.

• Access the bill details from the billing dashboard and download the bill.
  ❌ Sai: Billing Dashboard chỉ cung cấp tổng bill PDF/CSV hàng tháng, không phân tích chi tiết theo user (chỉ theo service/account). Không hỗ trợ lọc theo IAM user hay tạo báo cáo tùy chỉnh, chỉ xem tổng quan. Không đáp ứng yêu cầu "listed by user" một cách hiệu quả.

• Modify a cost budget in AWS Budgets to alert with Amazon Simple Email Service (Amazon SES).
  ❌ Sai: AWS Budgets chỉ dùng để thiết lập ngưỡng ngân sách và gửi alert (qua SES/SNS), không tạo báo cáo chi tiết theo user. Chỉ hiển thị tổng chi phí so với budget, không liệt kê billed items by user. Không phù hợp cho "report" dùng lập kế hoạch.

🛠️ Lời khuyên thực tế: Để tối ưu, kích hoạt Cost Allocation Tags cho IAM users trước (qua Tag Editor), rồi dùng Cost Explorer với filter "User:All". Nếu cần tự động hóa, tích hợp AWS Cost Explorer API với Lambda.
📘 Nguồn bổ sung: AWS Billing Best Practices & Cost Explorer Reports Guide (cập nhật 2026).

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

Câu hỏi tập trung vào việc thêm một contact form động (có server-side components) vào website tĩnh đang host trên Amazon S3, với các trường nhập liệu như tên, email, số điện thoại và tin nhắn từ người dùng. 📊 Yêu cầu chính:

• Website hiện tại là static (chỉ file HTML/CSS/JS trên S3), cần thêm phần dynamic server-side để xử lý form (nhận dữ liệu, gửi email).
• Lưu lượng thấp: <100 visits/tháng → ưu tiên giải pháp cost-effective nhất (tiết kiệm chi phí, serverless lý tưởng vì không cần tài nguyên chạy liên tục).
• Mục tiêu: Gửi email thông báo từ form mà không làm phức tạp hóa kiến trúc S3 static.

🛠️ Yêu cầu kỹ thuật AWS cập nhật 2026: Sử dụng serverless (Lambda, API Gateway, SES) để xử lý form mà không cần server luôn chạy. S3 hỗ trợ static hosting với CloudFront cho hiệu suất, nhưng form cần backend để tránh lộ thông tin SES credentials ở client-side.

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

Đáp án đúng: Create an Amazon API Gateway endpoint with an AWS Lambda backend that makes a call to Amazon Simple Email Service (Amazon SES).

Lý do chọn (cost-effective nhất):

• 🆓 Serverless hoàn toàn: Lambda chỉ tính phí theo execution (miễn phí 1 triệu requests/tháng đầu), API Gateway rẻ ( $3.50/1M requests), SES rẻ ($0.10/1K emails). Với <100 visits/tháng → gần như miễn phí.
• 🔄 Tích hợp mượt: Form client-side (JS trên S3) gọi API Gateway → Lambda xử lý validate + gửi SES → an toàn (không lộ credentials).
• 📈 Scalable & low-ops: Không quản lý server, auto-scale, phù hợp low traffic. Cập nhật AWS 2026: Lambda hỗ trợ ARM Graviton3 rẻ hơn, SES verified identities nhanh chóng.
• 💰 Tiết kiệm nhất so với ECS/EC2/Lightsail (có fixed cost dù low usage).

📋 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 (giữ nguyên văn bản gốc). Sử dụng kiến thức AWS mới nhất (Well-Architected Framework 2024+, Pricing 2026: serverless ưu tiên cho sporadic workloads).

• Host a dynamic contact form page in Amazon Elastic Container Service (Amazon ECS). Set up Amazon Simple Email Service (Amazon SES) to connect to any third-party email provider.
  ❌ Sai: ECS yêu cầu cluster Fargate/EC2 luôn chạy → fixed cost (~$20-50/tháng cho t3.micro dù low traffic). Phức tạp setup (container, ALB, IAM), không cost-effective. SES không cần third-party (gửi trực tiếp). Không phù hợp static S3.

• Create an Amazon API Gateway endpoint with an AWS Lambda backend that makes a call to Amazon Simple Email Service (Amazon SES).
  ✅ Đúng: Như giải thích trên. Serverless, pay-per-use, tích hợp chuẩn (Lambda Node.js/Python gửi SES). AWS docs: "Best for event-driven forms". Zero fixed cost cho <100 visits.

• Convert the static webpage to dynamic by deploying Amazon Lightsail. Use client-side scripting to build the contact form. Integrate the form with Amazon WorkMail.
  ❌ Sai: Lightsail là VPS fixed (~$3.50/tháng cho nano, cộng storage/DB) → tốn kém dù low traffic. Chuyển toàn bộ site sang Lightsail làm mất lợi thế S3 static (rẻ/free outbound). WorkMail là email corp (không dành cho form transactional, đắt ~$4/user/tháng), client-side lộ credentials rủi ro.

• Create a t2.micro Amazon EC2 instance. Deploy a LAMP (Linux, Apache, MySQL, PHP/Perl/Python) stack to host the webpage. Use client-side scripting to build the contact form. Integrate the form with Amazon WorkMail.
  ❌ Sai: EC2 t2.micro (~$7-10/tháng + EBS) luôn chạy → lãng phí (99% idle). Chuyển site sang dynamic LAMP phức tạp, mất S3 static. WorkMail không phù hợp form (transactional cần SES). Client-side unsafe.

📘 Tài liệu tham khảo

• AWS Docs: Amazon S3 Static Website + Lambda + API Gateway + SES (Serverless Contact Form blueprint).
• Pricing Calculator 2026: Lambda Free Tier, SES.
• Well-Architected: Serverless Lens → Cost Optimization Pillar.
• Exam Prep: A Cloud Guru / AWS DOP-C02 blueprint (2024+).

🧑‍💻 Kết luận: Giải pháp serverless là tiêu chuẩn AWS cho low-traffic dynamic forms! 🚀