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

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

Câu hỏi mô tả một ứng dụng chạy trên các instance Amazon EC2 thuộc Auto Scaling group (ASG), nằm sau Elastic Load Balancing (ELB) load balancer. Công ty dự đoán spike traffic (tăng đột biến lưu lượng) hàng năm vào dịp lễ hội (holiday), dựa trên lịch sử. Kiến trúc sư giải pháp (solutions architect) cần thiết kế chiến lược chủ động (proactively) để ASG tăng capacity trước, nhằm giảm thiểu tác động hiệu suất cho người dùng ứng dụng.

🔑 Yêu cầu cốt lõi: Phải chủ động tăng dung lượng trước thời điểm dự kiến (predictable spike), không phải phản ứng sau khi xảy ra vấn đề (reactive). Điều này phù hợp với các tính năng Scheduled Scaling của AWS Auto Scaling, giúp scale theo lịch trình định kỳ mà không phụ thuộc vào metrics thời gian thực.

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

Đáp án đúng: Create a recurring scheduled action to scale up the Auto Scaling group before the expected period of peak demand.

Lý do chọn 🛠️:

• Phương án này sử dụng Recurring Scheduled Scaling trong Auto Scaling groups, cho phép thiết lập lịch scale định kỳ hàng năm (recurring), ví dụ tăng desired capacity trước holiday (như +20 instances lúc 8h sáng ngày Black Friday).
• Đây là cách chủ động nhất (proactive), vì scale xảy ra trước peak demand, tránh latency do instance launch thời gian thực. AWS hỗ trợ tính năng này từ lâu và cập nhật đến 2026 với tích hợp tốt hơn với CloudWatch Events/Amazon EventBridge cho lịch phức tạp.
• Hoàn hảo cho predictable spikes như holiday, không cần metric trigger, tiết kiệm chi phí vì có thể scale down sau.

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

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

• ❌ Create an Amazon CloudWatch alarm to scale up the EC2 instances when CPU utilization exceeds 90%.
  🛠️ Sai vì: Đây là reactive scaling dựa trên metric CPU >90% (CloudWatch alarm trigger ASG policy). Scale chỉ xảy ra sau khi CPU cao (có thể gây downtime/performance impact trong spike đột ngột). Không chủ động trước holiday, vi phạm yêu cầu "proactively increases capacity". Phù hợp cho unpredictable load, không phải predictable event.

• ✅ Create a recurring scheduled action to scale up the Auto Scaling group before the expected period of peak demand.
  🛠️ Đúng vì: Như đã giải thích ở trên, scheduled action recurring (qua AWS Console/CLI/API) cho phép scale theo lịch cố định (CRON-like), ví dụ hàng năm trước peak 1-2 giờ. Proactive, tự động, và tối ưu cho seasonal traffic. AWS khuyến nghị chính thức cho trường hợp này.

• ❌ Increase the minimum and maximum number of EC2 instances in the Auto Scaling group during the peak demand period.
  🛠️ Sai vì: Đây là cách thủ công (manual) thay đổi min/max bounds của ASG (qua UpdateAutoScalingGroup API). Không tự động recurring, phải can thiệp hàng năm, dễ lỗi con người và không "design a strategy" tự động. ASG chỉ launch đến desired capacity, không tự scale nếu không có policy.

• ❌ Configure an Amazon Simple Notification Service (Amazon SNS) notification to send alerts when there are autoscaling:EC2_INSTANCE_LAUNCH events.
  🛠️ Sai vì: SNS chỉ gửi thông báo (notification) khi event EC2 launch xảy ra (qua EventBridge/CloudWatch Events). Không trigger scale gì cả, chỉ alert con người – vẫn reactive và thủ công. Không giải quyết vấn đề chủ động tăng capacity.

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

• Scheduled Scaling: AWS Auto Scaling User Guide - Scheduled Scaling – Chi tiết recurring actions với ví dụ CRON.
• Auto Scaling Best Practices: AWS Well-Architected Framework - Reliability Pillar – Khuyến nghị proactive scaling cho predictable workloads.
• EventBridge cho Scheduling: Amazon EventBridge Scheduled Rules – Tích hợp nâng cao cho lịch phức tạp (cập nhật 2024-2026).
• Exam Prep: AWS Certified DevOps Engineer Professional (DOP-C02) Sample Questions – Chủ đề ASG Scaling Strategies.

Hy vọng phân tích này giúp bạn nắm vững! 🚀 Nếu cần lab thực hành, dùng AWS Free Tier với ASG + Scheduled Actions nhé!

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

Câu hỏi tập trung vào việc triển khai xoay vòng mật khẩu (password rotation) cho cơ sở dữ liệu Amazon RDS for PostgreSQL trong kiến trúc data tier của công ty. Yêu cầu chính là chọn giải pháp có chi phí vận hành thấp nhất (LEAST operational overhead), nghĩa là ưu tiên phương pháp tự động hóa cao, ít cần can thiệp thủ công, code tùy chỉnh hoặc quản lý phức tạp.
✅ Mục tiêu: Đảm bảo mật khẩu RDS được thay đổi định kỳ an toàn, giảm rủi ro bảo mật, mà không làm tăng gánh nặng cho đội ngũ DevOps.

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

Đáp án đúng: Store the password in AWS Secrets Manager. Enable automatic rotation on the secret.

Lý do:
🛠️ AWS Secrets Manager cung cấp tính năng rotation tự động tích hợp sẵn cho RDS PostgreSQL (hỗ trợ từ phiên bản mới nhất 2024-2026). Chỉ cần lưu mật khẩu vào Secret, kích hoạt rotation qua console/API, Secrets Manager sẽ tự động:

• Tạo Lambda function managed (không cần viết code).
• Xoay mật khẩu RDS định kỳ (mặc định 30 ngày, tùy chỉnh được).
• Cập nhật RDS và các ứng dụng kết nối mà không downtime.
  📈 Least overhead: Hoàn toàn managed, zero code, phù hợp best practice AWS Well-Architected Framework (Security pillar). Không cần custom logic!

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

• Store the password in AWS Secrets Manager. Enable automatic rotation on the secret.
  ✅ Đúng: Như giải thích trên, đây là giải pháp native, tự động 100% cho RDS PostgreSQL. Rotation Lambda được AWS quản lý, hỗ trợ multi-Region, integration với IAM. Overhead thấp nhất!

• Store the password in AWS Systems Manager Parameter Store. Enable automatic rotation on the parameter.
  ❌ Sai: Parameter Store không hỗ trợ automatic rotation native (Advanced/SecureString parameters chỉ lưu trữ, không rotate tự động). Tính năng này chỉ có ở Secrets Manager. Nếu dùng Parameter Store, phải tự build rotation thủ công – tăng overhead đáng kể.

• Store the password in AWS Systems Manager Parameter Store. Write an AWS Lambda function that rotates the password.
  ❌ Sai: Parameter Store lưu trữ tốt (free tier hấp dẫn), nhưng yêu cầu viết Lambda custom để rotate (gọi RDS ModifyDBInstance, update parameter). Phải xử lý lỗi, quyền IAM, schedule via EventBridge – overhead cao, không managed như Secrets Manager. Không phải least overhead!

• Store the password in AWS Key Management Service (AWS KMS). Enable automatic rotation on the AWS KMS key.
  ❌ Sai: KMS dùng để quản lý khóa mã hóa (keys), không lưu trữ passwords trực tiếp. Rotation KMS chỉ xoay customer managed keys (symmetric/asymmetric), không liên quan đến RDS password. Dùng KMS sẽ không rotate được RDS creds – sai hoàn toàn yêu cầu!

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

• Secrets Manager Rotation for RDS: docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-rds.html – Hướng dẫn chi tiết PostgreSQL rotation.
• RDS Authentication with Secrets Manager: docs.aws.amazon.com/AmazonRDS/latest/UserGuide/UsingWithRDS.IAMDBAuth.html – Integration best practices.
• SSM Parameter Store vs Secrets Manager: docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html – So sánh rõ ràng (không rotation ở Parameter Store).
• AWS Well-Architected Security: aws.amazon.com/architecture/well-architected – Nhấn mạnh Secrets Manager cho secrets rotation.

🛡️ Lời khuyên DevOps: Luôn dùng Secrets Manager cho secrets động như DB passwords để scale tự động! Nếu cần tùy chỉnh, ARN integration với RDS là key.

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

Câu hỏi tập trung vào việc migrate cơ sở dữ liệu Oracle Database Enterprise Edition từ on-premises sang AWS cho một ứng dụng sử dụng third-party database features cần privileged access (quyền truy cập đặc quyền cao, như SYS hoặc OS-level access). Công ty có thể sử dụng mô hình Bring Your Own License (BYOL) để mang license Oracle hiện có sang AWS, giúp tiết kiệm chi phí.

Yêu cầu chính là thiết kế giải pháp migrate database MOST cost-effectively (tiết kiệm chi phí nhất), đồng thời hỗ trợ các tính năng third-party mà không làm gián đoạn ứng dụng. Các yếu tố cần cân nhắc:

• Giữ nguyên engine Oracle để tránh rewrite code ứng dụng.
• Hỗ trợ BYOL và privileged access (RDS thông thường không cho phép customize sâu).
• Sử dụng công cụ migrate hiệu quả (native tools hoặc AWS DMS).
  📘 Kiến thức AWS cập nhật 2026: Amazon RDS Custom for Oracle (ra mắt 2021, cập nhật liên tục) là lựa chọn lý tưởng cho BYOL Oracle với quyền truy cập đặc quyền, cho phép tùy chỉnh OS/database mà vẫn managed bởi AWS.

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

Đáp án đúng: Migrate the database to Amazon RDS Custom for Oracle by using native tools. Customize the new database settings to support the third-party features.

Lý do:

• 🛠️ RDS Custom for Oracle hỗ trợ BYOL đầy đủ, cho phép privileged access (SYS, OS sudo) để cài đặt/customize third-party features mà RDS Oracle tiêu chuẩn không hỗ trợ.
• Native tools (như Oracle Data Pump, RMAN, GoldenGate) migrate trực tiếp, nhanh chóng, chi phí thấp (không cần DMS phức tạp).
• Cost-effective nhất: Giữ nguyên Oracle engine → không rewrite app; BYOL tiết kiệm license; RDS Custom managed tự động backup/scale, chỉ tính phí instance + storage. Tránh chi phí chuyển đổi engine hoặc dịch vụ khác đắt đỏ hơn.
  ✅ Đây là giải pháp chuẩn AWS best practice cho migration Oracle legacy với custom needs.

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

• ❌ Phương án SAI: Migrate the database to Amazon RDS for Oracle by using native tools. Replace the third-party features with AWS Lambda.
  Lý do sai: RDS for Oracle không hỗ trợ privileged access đầy đủ (không thể customize OS/database sâu cho third-party features). Phải thay thế bằng Lambda là workaround phức tạp, tăng chi phí phát triển/app rewrite, không cost-effective. Native tools migrate được nhưng không giải quyết vấn đề core.

• ✅ Phương án ĐÚNG (như đã giải thích ở trên): Migrate the database to Amazon RDS Custom for Oracle by using native tools. Customize the new database settings to support the third-party features.
  Hoàn hảo khớp yêu cầu: BYOL + privileged access + native migrate → tối ưu chi phí và hiệu suất.

• ❌ Phương án SAI: Migrate the database to Amazon DynamoDB by using AWS Database Migration Service (AWS DMS). Customize the new database settings to support the third-party features.
  Lý do sai: DynamoDB là NoSQL key-value, không tương thích Oracle relational SQL → migrate bằng DMS chỉ hỗ trợ schema đơn giản, mất dữ liệu/features Oracle. Không hỗ trợ third-party Oracle features; customize vô nghĩa. Chi phí cao do redesign app hoàn toàn, không BYOL Oracle.

• ❌ Phương án SAI: Migrate the database to Amazon RDS for PostgreSQL by using AWS Database Migration Service (AWS DMS). Rewrite the application code to remove the dependency on third-party features.
  Lý do sai: PostgreSQL là engine khác (open-source), migrate DMS chỉ hỗ trợ schema conversion cơ bản (cần SCT tool), nhưng rewrite app code tốn kém thời gian/chi phí lớn. Không dùng BYOL Oracle (phải license PostgreSQL riêng); bỏ third-party features làm mất chức năng app. Không cost-effective so với giữ Oracle.

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

• Amazon RDS Custom for Oracle → Chi tiết BYOL, privileged access, migrate native tools.
• AWS Database Migration Guide → So sánh native vs DMS cho Oracle.
• AWS Well-Architected Framework - Database Lens → Best practices migration cost-effective.
  🛡️ Lưu ý: Giải pháp tuân thủ AWS re:Invent 2025 updates về RDS Custom scalability.

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

Câu hỏi mô tả một đại học quốc tế lớn đã triển khai toàn bộ dịch vụ tính toán trên AWS Cloud, bao gồm Amazon EC2 (máy ảo), Amazon RDS (cơ sở dữ liệu quan hệ), và Amazon DynamoDB (cơ sở dữ liệu NoSQL). Hiện tại, họ đang sử dụng nhiều script tùy chỉnh để sao lưu (backup) hạ tầng, dẫn đến quản lý phân tán và thủ công. Yêu cầu chính là tập trung hóa quản lý (centralize) và tự động hóa tối đa việc sao lưu dữ liệu bằng các tùy chọn native của AWS (không dùng bên thứ ba).

🛠️ Mục tiêu cốt lõi: Tìm giải pháp AWS gốc hỗ trợ backup cho tất cả các dịch vụ này một cách thống nhất, dễ giám sát, tuân thủ và tự động hóa theo lịch trình. Điều này phù hợp với best practice DevOps trên AWS, nhấn mạnh vào dịch vụ managed để giảm chi phí vận hành và tăng độ tin cậy.

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

Đáp án đúng: Use AWS Backup to configure and monitor all backups for the services in use.

Lý do chi tiết 🏆:

• AWS Backup là dịch vụ trung tâm hóa (centralized) và tự động hóa backup cho nhiều dịch vụ AWS native như EC2 (EBS snapshots), RDS (DB snapshots), DynamoDB (point-in-time recovery và export), cùng các dịch vụ khác (EFS, FSx, etc.).
• Nó hỗ trợ vault-based management, cross-region copy, audit trail qua CloudTrail, compliance với GDPR/HIPAA, và backup plans theo lịch trình tự động.
• Hoàn toàn native AWS, không cần script tùy chỉnh, dễ monitor qua dashboard/console và tích hợp Lambda cho custom logic nếu cần.
• Theo tài liệu AWS mới nhất (2024-2026), AWS Backup đã hỗ trợ DynamoDB continuous backups từ 2023, phù hợp hoàn hảo với yêu cầu.

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

Dưới đây là phân tích từng lựa chọn một cách chi tiết. Tôi giữ nguyên văn bản gốc bằng tiếng Anh, nhưng giải thích lý do đúng/sai hoàn toàn bằng tiếng Việt dựa trên kiến thức AWS DOP-C02 (DevOps Professional) cập nhật đến 2026.

• ❌ Use third-party backup software with an AWS Storage Gateway tape gateway virtual tape library.
  Sai vì: Đây không phải giải pháp native AWS (dùng phần mềm bên thứ ba + Storage Gateway chỉ là tape library cho backup kiểu tape cũ). Storage Gateway phù hợp cho on-premises hybrid backup, không centralize cho EC2/RDS/DynamoDB thuần cloud. Không tự động hóa tối đa, vi phạm yêu cầu "AWS native options" và tăng complexity.

• ✅ Use AWS Backup to configure and monitor all backups for the services in use.
  Đúng vì: Như đã giải thích ở trên, đây là dịch vụ chuyên biệt cho centralized backup hỗ trợ tất cả dịch vụ đề cập (EC2, RDS, DynamoDB). Tự động hóa qua backup plans/vaults, monitor qua metrics/alarms, và scale toàn cầu mà không cần script. Best practice cho enterprise như đại học.

• ❌ Use AWS Config to set lifecycle management to take snapshots of all data sources on a schedule.
  Sai vì: AWS Config là dịch vụ quản lý cấu hình (configuration compliance) và ghi nhận thay đổi, không phải backup tool. Nó có thể trigger Lambda cho lifecycle (như delete old snapshots), nhưng không centralize/automate backup cho RDS/DynamoDB một cách native. Không hỗ trợ monitor backup toàn diện, dễ dẫn đến non-compliance.

• ❌ Use AWS Systems Manager State Manager to manage the configuration and monitoring of backup tasks.
  Sai vì: Systems Manager (SSM) State Manager dùng để quản lý trạng thái instance (patching, config drift), không phải backup dữ liệu. Nó có thể run script backup trên EC2, nhưng không hỗ trợ RDS/DynamoDB native, vẫn cần custom scripts – trái với yêu cầu centralize/automate AWS native.

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

• AWS Backup Documentation: AWS Backup User Guide – Chi tiết supported services (EC2, RDS, DynamoDB PITR).
• DOP-C02 Exam Guide: Domain 3 (Implementation & Automation) – Nhấn mạnh AWS Backup cho centralized data protection.
• AWS Well-Architected Framework - Reliability Pillar: Khuyến nghị AWS Backup cho backup/restore automation.
• Blog AWS 2023+: "Backup DynamoDB with AWS Backup" (tích hợp continuous backups).

Hy vọng phân tích này giúp bạn ôn thi hiệu quả! 🚀 Nếu cần thêm case study, cứ 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 xây dựng bản đồ hạ tầng IT (IT infrastructure map) để xác định và thực thi chính sách trên các tài nguyên có rủi ro bảo mật. Đội ngũ bảo mật cần query dữ liệu một cách nhanh chóng để phát hiện rủi ro. Yêu cầu chính là giải pháp có LEAST operational overhead (ít chi phí vận hành nhất), nghĩa là ưu tiên dịch vụ fully managed, dễ scale, và phù hợp với dữ liệu có cấu trúc graph (đồ thị) – nơi tài nguyên IT là nodes (nút) và mối quan hệ (như kết nối VPC, security groups, IAM policies) là edges (cạnh).

🛠️ Bối cảnh AWS: Hạ tầng IT trên AWS (EC2, S3, VPC, Lambda...) thường có mối quan hệ phức tạp, phù hợp với graph database để query đường đi rủi ro bảo mật (ví dụ: EC2 public-facing kết nối S3 không mã hóa). Giải pháp phải hỗ trợ query ngôn ngữ graph-native để giảm overhead so với relational/NoSQL thông thường.

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

Đáp án đúng: Use Amazon Neptune to store the data. Use SPARQL to query the data to identify security risks.

Lý do:

• 📈 Amazon Neptune là dịch vụ fully managed graph database của AWS, hỗ trợ Property Graph (Gremlin) và RDF (SPARQL) – lý tưởng cho bản đồ hạ tầng IT với mối quan hệ phức tạp.
• SPARQL là ngôn ngữ query chuẩn cho RDF graphs, cho phép đội bảo mật nhanh chóng traverse (duyệt) graph để tìm rủi ro như "tất cả EC2 có security group mở port 22 kết nối Lambda unauthorized".
• LEAST operational overhead: Neptune tự động scale, backup, patching, multi-AZ, tích hợp IAM/VPC – không cần quản lý server, index graph tự động. Phù hợp Security Pillar trong AWS Well-Architected Framework.
• Cập nhật 2026: Neptune hỗ trợ Neptune Analytics (serverless graph analytics) cho query nhanh hơn, tích hợp IAM Access Analyzer-like cho security insights.

📋 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 tiếng Anh. Mỗi phương án được đánh giá dựa trên tính phù hợp với graph data, khả năng query rủi ro bảo mật, và operational overhead.

• ❌ Use Amazon RDS to store the data. Use SQL to query the data to identify security risks.
  Giải thích sai: RDS là relational database (MySQL/PostgreSQL...), phải model graph thành tables với joins phức tạp (nhiều table cho nodes/edges) → query chậm, overhead cao (tự thiết kế schema, index, sharding). Không native hỗ trợ graph traversal, khó scale cho IT map lớn. Overhead vận hành lớn hơn Neptune (quản lý instance, scaling thủ công).

• ✅ Use Amazon Neptune to store the data. Use SPARQL to query the data to identify security risks.
  Giải thích đúng: Như đã phân tích ở trên – Neptune native graph DB, SPARQL query hiệu quả cho RDF, fully managed → least overhead. Hoàn hảo cho security risk paths trong infrastructure graph (ví dụ: query "all paths from public subnets to sensitive S3").

• ❌ Use Amazon Redshift to store the data. Use SQL to query the data to identify security risks.
  Giải thích sai: Redshift là data warehouse cho petabyte-scale analytics (OLAP), không phải real-time graph query. Model graph yêu cầu denormalization phức tạp, query joins chậm với dữ liệu lớn → overhead cao (cluster management, concurrency limits). Không phù hợp cho security team cần query nhanh, động.

• ❌ Use Amazon DynamoDB to store the data. Use PartiQL to query the data to identify security risks.
  Giải thích sai: DynamoDB là NoSQL key-value/document DB, PartiQL (SQL-compatible) tốt cho simple queries nhưng không native graph – phải tự implement relationships qua GSI/secondary indexes, dẫn đến query phức tạp, scan toàn bộ itemset → performance kém, overhead cao (provision capacity, hot partitions). Không hiệu quả cho complex traversals như security risk mapping.

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

• AWS Neptune Documentation: https://docs.aws.amazon.com/neptune/latest/userguide/what-is-neptune.html (Graph use cases for security & compliance).
• AWS Well-Architected Framework - Security Pillar: https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html (Graph DB cho asset inventory & risk analysis).
• Neptune Best Practices: AWS re:Post & Neptune Workshop (2024-2026 updates: IAM integration, Gremlin/SPARQL federation).
• Ví dụ thực tế: AWS Security Reference Architecture sử dụng Neptune cho "attack path analysis" trong multi-account environments.

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 case study, 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 triển khai giải pháp tiết kiệm chi phí nhất (MOST cost-effectively) cho một công ty lớn, cung cấp các cơ sở dữ liệu PostgreSQL được quản lý (managed) riêng biệt, kích thước hạn chế, thể tích dữ liệu thấp (low volume) dành cho developer trên toàn cầu. Các đặc điểm quan trọng:

• Developer chỉ cần DB khi đang làm việc tích cực (actively working), ngụ ý sử dụng on-demand và tự động tắt/mở khi idle.
• Yêu cầu riêng biệt (separate) cho từng developer, nhưng quản lý tập trung để tránh lãng phí.
• Phải sử dụng dịch vụ AWS liên quan đến Amazon RDS hoặc Aurora (vì managed PostgreSQL), ưu tiên tự động hóa và scale linh hoạt để giảm chi phí lưu trữ/chạy liên tục.

🛠️ Thách thức chính: Tránh chi phí cho DB idle (không sử dụng), vì developer toàn cầu có múi giờ khác nhau, và low volume không cần provisioned capacity lớn. Giải pháp lý tưởng phải hỗ trợ auto-scaling down to 0 hoặc gần 0, kết hợp quyền truy cập kiểm soát qua Service Catalog.

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

Đáp án đúng: Create an Amazon Aurora Serverless cluster. Develop an AWS Service Catalog product to launch databases in the cluster with the default capacity settings. Grant the developers access to the product.

Lý do chi tiết:

• Amazon Aurora Serverless (phiên bản v2 cập nhật đến 2026) hỗ trợ PostgreSQL, tự động scale capacity từ 0.5 ACU lên cao hơn dựa trên workload, và auto-pause sau 5 phút idle (pause hoàn toàn, chỉ charge storage ~$0.10/GB/tháng), lý tưởng cho low-volume dev DB chỉ dùng khi actively working ✅.
• AWS Service Catalog cho phép tạo product chuẩn hóa, enforce default capacity nhỏ (hạn chế size), developer tự launch DB riêng trong shared cluster (multi-tenant an toàn nhờ isolation), không cần provision instance riêng → tiết kiệm nhất vì không charge compute khi idle.
• Phù hợp global: Multi-AZ, low latency. Tổng chi phí thấp hơn provisioned RDS/Aurora 70-90% cho sporadic use 🤑.

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

• Give the developers the ability to launch separate Amazon Aurora instances. Set up a process to shut down Aurora instances at the end of the workday and to start Aurora instances at the beginning of the next workday.
  ❌ Sai vì không cost-effective: Aurora provisioned instances vẫn charge storage đầy đủ ngay cả khi shut down (~$0.10/GB/tháng), cộng thêm chi phí start/stop manual (thời gian ~5-15 phút). Quy trình hàng ngày khó scale cho developer global (múi giờ khác), dễ quên → lãng phí và không tự động. Không tận dụng auto-pause thực sự.

• Develop an AWS Service Catalog product that enforces size restrictions for launching Amazon Aurora instances. Give the developers access to launch the product when they need a development database.
  ❌ Sai vì vẫn tốn kém: Service Catalog chỉ enforce size cho provisioned Aurora instances, nhưng instances chạy liên tục charge compute + storage ngay cả idle. Không có cơ chế auto-scale/pause → chi phí cao cho low-volume, on-demand use. Developer phải tự quản lý lifecycle, dễ dẫn đến DB "quên tắt".

• Create an Amazon Aurora Serverless cluster. Develop an AWS Service Catalog product to launch databases in the cluster with the default capacity settings. Grant the developers access to the product.
  ✅ Đúng như đã giải thích ở trên: Kết hợp Serverless auto-pause/scale + Service Catalog kiểm soát là giải pháp tối ưu, tiết kiệm nhất cho dev DB sporadic, low-volume, global.

• Monitor AWS Trusted Advisor checks for idle Amazon Aurora instances. Create a process to terminate identified idle RDS databases.
  ❌ Sai vì reactive và rủi ro: Trusted Advisor chỉ check idle (CPU <10% >14 ngày), không proactive cho dev needs (developer cần DB nhanh chóng). Terminate xóa data/schema → mất dev work, phải recreate. Không hỗ trợ PostgreSQL riêng biệt, low-volume, và không tự động launch → không meet "separate, limited size" requirements.

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

• Aurora Serverless v2: AWS Docs - Amazon Aurora Serverless v2 – Auto-pause, PostgreSQL support, pay-per-use.
• AWS Service Catalog: AWS Docs - Service Catalog – Provision controlled products.
• RDS Pricing Comparison: AWS Pricing - Aurora Serverless – Tiết kiệm 70%+ so provisioned cho bursty workloads.
• Trusted Advisor: AWS Support - Trusted Advisor – Chỉ check, không automate lifecycle.
• Best Practices Dev DB: AWS Well-Architected Framework - Reliability Pillar (2024 update).

Giải pháp này đảm bảo DevOps best practices: IaC, self-service, cost-optimized! 🚀

🧩 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 web phục vụ hệ thống quản lý nội dung (CMS - Content Management System). CMS chạy trên các instance Amazon EC2 nằm sau Application Load Balancer (ALB), và các EC2 này thuộc Auto Scaling Group (ASG) trải rộng trên nhiều Availability Zones (AZ). Người dùng liên tục thêm và cập nhật file, blog, tài nguyên website khác trong CMS.
Yêu cầu chính: Kiến trúc sư giải pháp (Solutions Architect) phải triển khai giải pháp để tất cả EC2 instances chia sẻ nội dung website cập nhật nhất với độ trễ (lag time) thấp nhất có thể.
🛠️ Thách thức kỹ thuật:

• Cần một hệ thống lưu trữ chia sẻ (shared storage) hỗ trợ đa AZ, multi-instance mount (nhiều EC2 mount cùng lúc).
• Phải đảm bảo real-time hoặc gần real-time sync vì nội dung thay đổi liên tục, không chấp nhận lag lớn.
• Tích hợp mượt mà với ứng dụng hosting website trên EC2. Kiến thức AWS cập nhật đến 2026: Amazon EFS (Elastic File System) là lựa chọn lý tưởng cho shared file storage với NFS protocol, hỗ trợ multi-AZ, automatic scaling, và consistency mạnh mẽ (strong consistency sau năm 2020 với EFS IA mode). Không dùng EBS (không shareable cross-instance/AZ) hoặc S3 (object storage, không phải POSIX filesystem).

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

• AWS EFS Documentation: What is Amazon EFS? (cập nhật 2024-2026: Hỗ trợ Provisioned Throughput, EFS Replication).
• AWS Well-Architected Framework - Storage Pillar: Nhấn mạnh EFS cho shared files in multi-AZ workloads.

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

Đáp án đúng: Copy the website assets to an Amazon Elastic File System (Amazon EFS) file system. Configure each EC2 instance to mount the EFS file system locally. Configure the website hosting application to reference the website assets that are stored in the EFS file system.

Lý do 🟢:

• EFS là file system chia sẻ POSIX-compliant, cho phép nhiều EC2 instances mount cùng lúc từ nhiều AZ mà không cần sync thủ công.
• Zero lag time: Thay đổi file trên một instance ngay lập tức visible cho tất cả instances khác nhờ strong read-after-write consistency (cập nhật AWS từ 2020).
• Tự động scale throughput (General Purpose hoặc Max I/O mode), phù hợp CMS với traffic biến động.
• Dễ cấu hình qua ASG launch template/user data (mount EFS via mount command hoặc fstab).
• Chi phí tối ưu, durable (99.999999999% over year), tích hợp IAM policy cho access control.

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

• Phương án 1 ❌: Update the EC2 user data in the Auto Scaling group lifecycle policy to copy the website assets from the EC2 instance that was launched most recently. Configure the ALB to make changes to the website assets only in the newest EC2 instance.
  Tại sao sai: Không khả thi về mặt kỹ thuật. User data chỉ chạy một lần lúc launch instance, không tự động copy từ "newest instance" (không có cơ chế detect newest). ALB chỉ balance traffic/load, không chỉnh sửa file/content. Gây race condition, data inconsistency, và lag cao khi scale up/down. Vi phạm nguyên tắc immutable infrastructure.

• Phương án 2 ✅: Copy the website assets to an Amazon Elastic File System (Amazon EFS) file system. Configure each EC2 instance to mount the EFS file system locally. Configure the website hosting application to reference the website assets that are stored in the EFS file system.
  Tại sao đúng: Như đã giải thích ở phần trên. Đây là best practice AWS cho shared filesystem in multi-AZ ASG, đảm bảo up-to-date content với lag gần zero (sub-second propagation).

• Phương án 3 ❌: Copy the website assets to an Amazon S3 bucket. Ensure that each EC2 instance downloads the website assets from the S3 bucket to the attached Amazon Elastic Block Store (Amazon EBS) volume. Run the S3 sync command once each hour to keep files up to date.
  Tại sao sai: S3 là object storage, không phải filesystem real-time (eventual consistency cho updates). Sync hàng giờ gây lag 1 giờ (không đáp ứng "least possible lag"). Mỗi instance copy về EBS riêng → không shared, tốn storage/IOPS, và phức tạp khi scale (cần cron job sync). Phù hợp static assets, không phải dynamic CMS.

• Phương án 4 ❌: Restore an Amazon Elastic Block Store (EBS) snapshot with the website assets. Attach the EBS snapshot as a secondary EBS volume when a new EC2 instance is launched. Configure the website hosting application to reference the website assets that are stored in the secondary EBS volume.
  Tại sao sai: EBS là block storage single-instance/single-AZ (io1/io2 multi-attach chỉ same AZ, giới hạn 16 instances từ 2023). Snapshot restore tạo volume mới, không shared → mỗi instance có copy riêng, không sync real-time. Launch time delay cao, data cũ (snapshot không live), không scale multi-AZ ASG.

🛠️ Khuyến nghị triển khai: Sử dụng EFS Access Points (tính năng mới 2021+) cho security, kết hợp CloudWatch metrics theo dõi throughput/latency. Test với EFS CSI driver nếu dùng EKS.

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

Câu hỏi mô tả một ứng dụng web của công ty được triển khai trên nhiều instance Amazon EC2 đứng sau Application Load Balancer (ALB) trong một VPC. Dữ liệu được lưu trữ trên Amazon RDS for MySQL. Công ty cần khả năng tự động phát hiện (detect) và phản hồi (respond) với các hành vi đáng ngờ hoặc bất thường trong môi trường AWS. Họ đã tích hợp AWS WAF vào kiến trúc.

Mục tiêu chính: Tăng cường bảo mật bằng cách sử dụng dịch vụ AWS phù hợp để phát hiện mối đe dọa (threat detection) và tích hợp tự động hóa (qua EventBridge và Lambda) để điều chỉnh quy tắc WAF, giúp bảo vệ chống lại các mối đe dọa như tấn công DDoS, khai thác lỗ hổng hoặc hành vi bất thường từ EC2/RDS/ALB. Đây là kịch bản điển hình trong AWS Security best practices (cập nhật đến 2026, với GuardDuty hỗ trợ Machine Learning-based threat detection thời gian thực).

Yêu cầu "next step": Không chỉ dừng ở WAF (chỉ bảo vệ web ACL), mà cần dịch vụ threat intelligence chuyên sâu để detect toàn diện, sau đó automate response.

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

Đáp án đúng:
Use Amazon GuardDuty to perform threat detection. Configure Amazon EventBridge to filter for GuardDuty findings and to invoke an AWS Lambda function to adjust the AWS WAF rules.

Lý do chi tiết 🛠️:

• Amazon GuardDuty là dịch vụ threat detection hàng đầu của AWS (cập nhật 2026: hỗ trợ ML, threat intel từ AWS, partners như CrowdStrike, tích hợp sâu với VPC Flow Logs, CloudTrail, DNS logs). Nó tự động detect các mối đe dọa như reconnaissance (scan port), compromised credentials, crypto mining trên EC2, hoặc unusual API calls liên quan đến ALB/RDS.
• Tích hợp Amazon EventBridge để filter findings (high/medium severity) và trigger AWS Lambda tự động update WAF rules (ví dụ: block IP suspicious). Đây là best practice cho automated remediation, phù hợp với kiến trúc hiện tại (EC2 + ALB + WAF).
• Giải quyết đúng vấn đề: Detect toàn môi trường AWS, không chỉ web traffic như WAF.

📋 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, 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:

• ✅ Use Amazon GuardDuty to perform threat detection. Configure Amazon EventBridge to filter for GuardDuty findings and to invoke an AWS Lambda function to adjust the AWS WAF rules.
  Giải thích: Như phần trên, đây là giải pháp tối ưu. GuardDuty chuyên detect threat ở mức account/VPC (EC2, RDS, ALB), kết hợp EventBridge + Lambda để auto-remediate WAF. Hoàn hảo cho "suspicious behavior" mà không cần cấu hình thủ công. (Cập nhật 2026: GuardDuty Malware Protection hỗ trợ scan EC2 real-time).

• ❌ Use AWS Firewall Manager to perform threat detection. Configure Amazon EventBridge to filter for Firewall Manager findings and to invoke an AWS Lambda function to adjust the AWS WAF web ACL.
  Giải thích: AWS Firewall Manager (FMS) là công cụ quản lý tập trung WAF, Shield, VPC NACL, nhưng KHÔNG phải dịch vụ threat detection. Nó không generate "findings" như GuardDuty; chỉ delegate policy management. Không detect suspicious behavior (như crypto mining trên EC2), nên không phù hợp làm "next step".

• ❌ Use Amazon Inspector to perform threat detection and to update the AWS WAF rules. Create a VPC network ACL to limit access to the web application.
  Giải thích: Amazon Inspector (cập nhật 2026: Network Reachability + EC2 scans) tập trung vulnerability scanning (lỗ hổng software trên EC2), không phải real-time threat detection như hành vi bất thường. Không tự update WAF rules; cần manual/script. Thêm VPC NACL là stateless firewall cơ bản, không auto-detect/response, và thừa vì đã có ALB/WAF.

• ❌ Use Amazon Macie to perform threat detection and to update the AWS WAF rules. Create a VPC network ACL to limit access to the web application.
  Giải thích: Amazon Macie (cập nhật 2026: ML-based sensitive data discovery) chuyên bảo vệ dữ liệu nhạy cảm trong S3 (PII, PHI), không detect threat trên EC2/ALB/RDS hay update WAF. Không liên quan đến web app traffic hoặc suspicious behavior ở compute layer. VPC NACL cũng không giải quyết detect/response.

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

• GuardDuty docs: AWS GuardDuty User Guide – Threat detection & EventBridge integration.
• WAF + Remediation: AWS Security Blog: Automate WAF with GuardDuty.
• So sánh services: AWS Security Services Overview – GuardDuty vs Inspector/Macie/FMS.
• Best Practices: AWS Well-Architected Framework – Security Pillar (2026 edition).

Giải pháp này đảm bảo zero-trust security tự động hóa! 🚀 Nếu cần demo CDK/Terraform, hãy hỏi thêm nhé!

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

Câu hỏi tập trung vào một tình huống thực tế trong môi trường AWS: Một công ty đang lập kế hoạch triển khai nhóm Amazon EC2 instances kết nối với Amazon Aurora database (một dịch vụ RDS managed, hỗ trợ MySQL/PostgreSQL). Họ sử dụng AWS CloudFormation template để deploy cả EC2 và Aurora DB cluster. Yêu cầu chính là cho phép EC2 authenticate (xác thực) với database một cách an toàn, không sử dụng static database credentials (tức không lưu username/password cố định để tránh rủi ro bảo mật như leak hoặc rotate thủ công). Giải pháp phải đạt LEAST operational effort (ít nỗ lực vận hành nhất, nghĩa là tự động hóa cao, ít can thiệp thủ công, dễ scale và maintain).

🛠️ Các yếu tố then chốt cần xem xét:

• Bảo mật cao: Tránh hardcode hoặc lưu trữ credentials tĩnh.
• Tích hợp CloudFormation: Giải pháp phải dễ dàng deploy qua template.
• Aurora hỗ trợ IAM Database Authentication (tính năng IAM auth cho RDS Aurora, cho phép dùng IAM roles/users thay thế password, generate short-lived tokens).
• Least effort: Ưu tiên IAM roles (attach trực tiếp vào EC2 instance) vì tự động, không cần fetch secrets hay quản lý user/password.

📘 Kiến thức cập nhật (AWS 2024-2026): IAM DB Authentication vẫn là best practice cho Aurora (hỗ trợ MySQL 5.6+, PostgreSQL 9.6+), kết hợp với RDS Proxy để scale. Không có thay đổi lớn trong IAM auth mechanism đến 2026 (xem AWS re:Invent 2024 updates).

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

Đáp án đúng: Configure the DB cluster to use IAM database authentication. Create a database user to use with IAM authentication. Associate a role with the EC2 instances to allow applications on the instances to access the database.

Lý do chọn (chi tiết):

• 🛡️ An toàn tối ưu: Sử dụng IAM Database Authentication trên Aurora DB cluster (enable qua CloudFormation parameter IAMAuth=true). Tạo DB user (ví dụ: iam_user) mapped với IAM principal, ứng dụng trên EC2 generate token từ IAM role (short-lived, ~15 phút).
• Least effort: Chỉ cần associate IAM role với EC2 instances (qua CloudFormation InstanceProfile), ứng dụng dùng AWS SDK (như boto3) fetch token tự động. Không cần maintain credentials, rotate, hoặc fetch từ store nào. Hoàn toàn tự động hóa trong template.
• Phù hợp yêu cầu: Không static creds, tích hợp seamless với CloudFormation và EC2.

📋 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 phương án một cách chi tiết. Tôi giữ nguyên nội dung văn bản gốc bằng tiếng Anh, chỉ giải thích lý do đúng/sai hoàn toàn bằng tiếng Việt.

• Create a database user with a user name and password. Add parameters for the database user name and password to the CloudFormation template. Pass the parameters to the EC2 instances when the instances are launched.
  ❌ Sai: Phương án này sử dụng static username/password truyền qua CloudFormation parameters và pass trực tiếp cho EC2 (qua UserData hoặc metadata). Vi phạm yêu cầu "không maintain static credentials" vì phải quản lý password thủ công (rotate định kỳ, rủi ro leak qua logs/template). Operational effort cao (update template mỗi khi thay đổi), không an toàn.

• Create a database user with a user name and password. Store the user name and password in AWS Systems Manager Parameter Store. Configure the EC2 instances to retrieve the database credentials from Parameter Store.
  ❌ Sai: Dù dùng SSM Parameter Store (secure storage với encryption KMS), vẫn cần tạo và maintain static credentials (DB user/password). EC2 phải fetch qua SSM agent (IAM role cần ssm:GetParameters), tăng effort (cấu hình fetch logic trong app/script, handle errors/rotation). Không phải least effort so với IAM auth (vẫn cần rotate password định kỳ).

• Configure the DB cluster to use IAM database authentication. Create a database user to use with IAM authentication. Associate a role with the EC2 instances to allow applications on the instances to access the database.
  ✅ Đúng: Như đã giải thích ở phần trên. Đây là best practice AWS cho Aurora: Enable IAM auth trên DB cluster, tạo DB user mapped IAM (SQL: CREATE USER iam_user IDENTIFIED WITH AWSAuthenticationPlugin as 'RDS';), attach IAM role cho EC2 với policy RDS-DB:connect. Ứng dụng dùng generate_db_auth_token() từ SDK. Zero credential management, fully automated qua CloudFormation.

• Configure the DB cluster to use IAM database authentication with an IAM user. Create a database user that has a name that matches the IAM user. Associate the IAM user with the EC2 instances to allow applications on the instances to access the database.
  ❌ Sai: Sử dụng IAM user (thay vì role) attach với EC2 là không đúng best practice và phức tạp. IAM user cần access key/secret (static creds, vi phạm yêu cầu), phải associate thủ công (không tự động như role). DB user name phải match IAM user ARN (khó scale cho nhiều EC2). Effort cao hơn role-based auth (phải quản lý user keys, rotation).

📚 Tài liệu tham khảo (AWS official, cập nhật 2024-2026)

• IAM Database Authentication for Aurora: AWS Docs - Using IAM with Aurora ✅ (Core guide, ví dụ CloudFormation snippet).
• CloudFormation for Aurora IAM Auth: AWS::RDS::DBCluster IAMAuthEnabled.
• Best Practices DevOps: AWS Well-Architected Framework - Security Pillar (Operational Excellence: Automate auth với IAM roles).
• Exam Tips (DOP-C02): Câu tương tự thường xuất hiện trong AWS Certified DevOps Engineer Professional, ưu tiên IAM roles > users > secrets.

🛡️ Kết luận: Giải pháp IAM role + DB auth là lựa chọn tối ưu, giúp công ty scale dễ dàng mà không lo bảo mật credentials! Nếu cần template CloudFormation mẫu, hãy hỏi thêm.

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

Câu hỏi tập trung vào việc cấu hình Amazon CloudFront distribution sử dụng chứng chỉ SSL/TLS để hỗ trợ HTTPS với tên miền tùy chỉnh (không dùng default domain như d1234567890.cloudfront.net). Công ty muốn triển khai chứng chỉ mà không phát sinh chi phí thêm (without incurring any additional costs).

🛠️ Yêu cầu chính từ AWS (cập nhật đến 2026):

• CloudFront bắt buộc sử dụng chứng chỉ từ AWS Certificate Manager (ACM) ở vùng us-east-1 (Northern Virginia) để kích hoạt HTTPS với custom domain. Chứng chỉ ở vùng khác không thể attach vào CloudFront distribution.
• ACM cung cấp public certificates (do Amazon issue) hoàn toàn miễn phí cho các domain public.
• Private certificates (từ ACM Private CA) thường phát sinh chi phí (ví dụ: root CA khoảng 400 USD/tháng + phí phát hành cert).
• Giải pháp phải đảm bảo không tốn kém, phù hợp với best practice cho CloudFront + custom domain (SNI hoặc dedicated IP, nhưng tập trung vào cert).

📘 Mục tiêu: Tìm phương án deploy cert miễn phí, đúng vùng, hỗ trợ CloudFront.

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

Đáp án đúng: Request an Amazon issued public certificate from AWS Certificate Manager (ACM) in the us-east-1 Region.

Lý do chi tiết:

• Public certificate từ ACM là miễn phí 100% (không giới hạn số lượng, tự động renew).
• Vùng us-east-1 là bắt buộc cho CloudFront (theo docs AWS: CloudFront chỉ hỗ trợ cert từ us-east-1 global endpoint).
• Phù hợp hoàn hảo: Import hoặc request cert cho custom domain (ví dụ: example.com), sau đó attach vào CloudFront Viewer Protocol Policy là HTTPS-only.
• Không tốn chi phí: AWS không charge cho public certs, chỉ cần DNS validation (CNAME/Route53).

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

• ❌ SAI: Request an Amazon issued private certificate from AWS Certificate Manager (ACM) in the us-east-1 Region.
  Giải thích: Private cert từ ACM Private CA phát sinh chi phí cao (root CA ~400 USD/tháng + 0.75 USD/cert/tháng). Không phù hợp yêu cầu "without incurring any additional costs". Dù ở đúng vùng us-east-1 (hỗ trợ CloudFront), nhưng loại cert private chỉ dùng nội bộ (không public domain), không miễn phí.

• ❌ SAI: Request an Amazon issued private certificate from AWS Certificate Manager (ACM) in the us-west-1 Region.
  Giải thích: Hai lỗi lớn: (1) Private cert có phí như trên. (2) Vùng us-west-1 không hỗ trợ CloudFront (chỉ us-east-1). Cert này không attach được, vô dụng cho distribution.

• ✅ ĐÚNG: Request an Amazon issued public certificate from AWS Certificate Manager (ACM) in the us-east-1 Region.
  Giải thích: Như phần đáp án đúng ở trên – miễn phí, đúng vùng, hỗ trợ custom domain public qua DNS validation. Best practice cho CloudFront HTTPS (cập nhật AWS 2026: vẫn giữ quy định này).

• ❌ SAI: Request an Amazon issued public certificate from AWS Certificate Manager (ACM) in the us-west-1 Region.
  Giải thích: Public cert miễn phí, nhưng vùng us-west-1 không tương thích với CloudFront. AWS không cho phép attach cert ngoài us-east-1, dẫn đến lỗi khi deploy distribution.

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

• AWS Certificate Manager User Guide: Using ACM with CloudFront ✅ (Xác nhận us-east-1 bắt buộc).
• CloudFront Developer Guide: Use Custom SSL/TLS Certs 🛠️ (Custom domain + ACM free public certs).
• ACM Pricing 📊 (Public certs miễn phí; private có phí).
• ACM FAQs ❓ (Chi tiết vùng và loại cert).

💡 Lời khuyên DevOps: Sử dụng AWS Console/CLI request public cert ở us-east-1, validate via Route53, attach CloudFront → Zero cost, auto-renew! 🚀