Ngân hàng đề — AWS Certified Cloud Practitioner

📖 Phân tích câu hỏi

Công ty muốn đánh giá (không phải triển khai ngay) cấu hình và mức độ sử dụng hiện tại của môi trường on‑premises trước khi thực hiện chuyển đổi lên AWS.
Yêu cầu quan trọng:

1. Thu thập dữ liệu về tài nguyên, mạng, phụ thuộc ứng dụng, hiệu suất … trên máy chủ, máy ảo, container, …
2. Không cần phải di chuyển (replicate) các workload ngay lập tức.
3. Muốn có một công cụ/ dịch vụ AWS giúp thực hiện việc “discovery” (phát hiện) và tạo ra báo cáo, bản đồ phụ thuộc để lên kế hoạch migration.

Vì vậy câu hỏi đang hỏi: “Công cụ AWS nào đáp ứng nhu cầu khám phá môi trường on‑premises mà không thực hiện sao chép workload?”

✅ Đáp án đúng

🔹 AWS Application Discovery Service

Lý do chọn:

• Đây là dịch vụ được thiết kế chuyên để phát hiện (discover) tài nguyên on‑premises, thu thập thông tin cấu hình, hiệu suất, và quan hệ phụ thuộc giữa các ứng dụng.
• Dịch vụ cung cấp báo cáo chi tiết (CSV, JSON) và sẵn sàng tích hợp với AWS Migration Hub, giúp lên kế hoạch di chuyển sau này.
• Không yêu cầu di chuyển hay sao chép workload; chỉ thực hiện thu thập dữ liệu qua agent hoặc discovery agentless.
• Tính năng mới (tính tới 2026): hỗ trợ phát hiện môi trường container/Kubernetes on‑prem, và tích hợp AI‑driven insights để đề xuất nhóm migration.

🧩 Giải thích các phương án (giữ nguyên nội dung tiếng Anh)

1️⃣ AWS Application Discovery Service (ĐÚNG)

• Giải thích: Dịch vụ này cung cấp khả năng phát hiện tự động các máy chủ, máy ảo, và các thành phần phần mềm trong data center nội bộ. Nó thu thập dữ liệu về CPU, memory, network, và đặc biệt là đồ thị phụ thuộc ứng dụng. Kết quả được xuất ra để phân tích trong AWS Migration Hub hoặc các công cụ third‑party. Không thực hiện việc replicate hay migrate workload, đáp ứng đúng yêu cầu “hiểu hiện trạng trước khi di chuyển”.

2️⃣ AWS Application Migration Service (SAI)

• Giải thích: Trước đây gọi là Server Migration Service (SMS), công cụ này được dùng để di chuyển (lift‑and‑shift) các máy chủ on‑premises lên AWS bằng cách tạo các bản sao (replication) và sau đó khởi chạy chúng trên EC2. Vì câu hỏi không muốn sao chép workload, nên dịch vụ này không phù hợp.

3️⃣ Cloud Migration Factory (SAI)

• Giải thích: “Cloud Migration Factory” không phải là một dịch vụ riêng biệt của AWS. Thuật ngữ này thường được dùng để chỉ một phương pháp luận hoặc môi trường làm việc (framework) do các đối tác tư vấn (VD: Accenture, Capgemini) xây dựng để quản lý quy trình migration. Vì không phải là dịch vụ AWS và không cung cấp chức năng discovery tự động, nên đây là lựa chọn sai.

4️⃣ AWS Transfer Family (SAI)

• Giải thích: Dịch vụ này cung cấp đánh đổi (transfer) dữ liệu an toàn qua các giao thức SFTP, FTPS, và FTP tới và từ Amazon S3 hay EFS. Nó không liên quan đến việc khám phá cấu hình hay phụ thuộc hệ thống on‑premises. Do đó không đáp ứng yêu cầu câu hỏi.

📚 Tham khảo (tính đến năm 2026)

• AWS Documentation – Application Discovery Service
  https://docs.aws.amazon.com/application-discovery/latest/userguide/what-is-appdiscovery.html

• AWS Migration Hub – Integration with Application Discovery Service
  https://aws.amazon.com/migration-hub/

• AWS Blog – New AI‑driven insights in Application Discovery Service (2025)
  https://aws.amazon.com/blogs/migration/ai-insights-application-discovery/

• AWS Documentation – Application Migration Service (formerly SMS)
  https://docs.aws.amazon.com/mgn/latest/ug/what-is-aws-application-migration-service.html

• AWS Transfer Family Documentation
  https://docs.aws.amazon.com/transfer/latest/userguide/what-is-awstransfer.html

🛠️ Kết luận:
Để hiểu rõ môi trường on‑premises mà không cần thực hiện sao chép hay di chuyển ngay, AWS Application Discovery Service là công cụ phù hợp nhất. Các lựa chọn còn lại either thực hiện migration (Application Migration Service), không phải dịch vụ AWS (Cloud Migration Factory), hoặc không liên quan tới việc discovery (AWS Transfer Family). ✅

📝 Phân tích câu hỏi

Công ty muốn cho nhân viên làm việc từ xa (home) bằng máy tính để bàn Windows hoặc Linux. Yêu cầu quan trọng:

1. Truy cập bất kỳ lúc nào, từ bất kỳ địa điểm nào.
2. Hỗ trợ mọi thiết bị (PC, laptop, tablet, smartphone) có cài client hoặc trình duyệt.
3. Cung cấp một môi trường Desktop đầy đủ (hệ điều hành, ứng dụng, dữ liệu người dùng) như khi ngồi tại văn phòng.

Do đó, cần một dịch vụ Desktop‑as‑a‑Service (DaaS) của AWS, cho phép người dùng kết nối tới một máy ảo Windows hoặc Linux được quản lý hoàn toàn bởi AWS.

✅ Đáp án đúng: Amazon WorkSpaces

• Amazon WorkSpaces là dịch vụ DaaS được thiết kế chính xác cho kịch bản “remote desktop”.
• Cung cấp máy ảo Windows 10/11 hoặc Linux với khả năng lưu trữ dữ liệu người dùng (persistent).
• Khả năng truy cập từ mọi thiết bị: có client native cho Windows, macOS, iOS, Android và WorkSpaces Web (trình duyệt) cho phép kết nối không cần cài phần mềm – đáp ứng yêu cầu “any supported devices”.
• Hỗ trợ đăng nhập 24/7, tích hợp IAM, MFA, và hiện tại (2026) cho phép đồng bộ Azure AD / Okta để quản lý người dùng doanh nghiệp.
• Tính năng GPU‑based WorkSpaces đáp ứng nhu cầu đồ họa cao, và Auto‑Stop giúp giảm chi phí khi không sử dụng.

Vì vậy, Amazon WorkSpaces là dịch vụ duy nhất trong các lựa chọn đáp ứng đầy đủ các tiêu chí của câu hỏi.

❌ Phân tích các phương án còn lại

1. Amazon AppStream 2.0

• Mô tả: Dịch vụ streaming ứng dụng (application streaming) chứ không phải toàn bộ desktop. Người dùng chỉ thấy các ứng dụng được xuất ra dưới dạng video, còn hệ điều hành và môi trường không được truy cập trực tiếp.
• Tại sao không phù hợp: Yêu cầu “employees use Windows or Linux desktops” → cần môi trường desktop đầy đủ, không chỉ các ứng dụng riêng lẻ. Ngoài ra, AppStream 2.0 không hỗ trợ lưu trữ trạng thái người dùng một cách persistent như WorkSpaces.

2. Amazon Keyspaces (for Apache Cassandra)

• Mô tả: Dịch vụ Cassandra‑compatible NoSQL database được quản lý, dùng để lưu trữ dữ liệu quy mô lớn.
• Tại sao không phù hợp: Hoàn toàn không liên quan tới việc cung cấp desktop hay môi trường làm việc từ xa. Nó chỉ là một hệ thống cơ sở dữ liệu, không cung cấp giao diện người dùng, client desktop, hay khả năng truy cập từ bất kỳ thiết bị nào.

3. AWS Cloud9

• Mô tả: Môi trường IDE (Integrated Development Environment) dựa trên trình duyệt dành cho lập trình viên.
• Tại sao không phù hợp: Cloud9 chỉ cung cấp một trình soạn thảo mã và một máy ảo Linux tạm thời cho mục đích phát triển. Nó không cung cấp một desktop Windows/Linux đầy đủ, không hỗ trợ các ứng dụng doanh nghiệp thông thường, và không đáp ứng yêu cầu “any supported devices” cho toàn bộ môi trường làm việc.

📚 Tham khảo (cập nhật đến năm 2026)

• Amazon WorkSpaces Documentation – https://docs.aws.amazon.com/workspaces/latest/adminguide/what-is-workspaces.html
• WorkSpaces Web – tính năng ra mắt 2023, được cập nhật liên tục tới 2026, hỗ trợ truy cập qua trình duyệt mà không cần client.
• Amazon AppStream 2.0 Documentation – https://docs.aws.amazon.com/appstream2/latest/developerguide/what-is-appstream.html
• Amazon Keyspaces Documentation – https://docs.aws.amazon.com/keyspaces/latest/devguide/what-is-keyspaces.html
• AWS Cloud9 Documentation – https://docs.aws.amazon.com/cloud9/latest/user-guide/welcome.html

🔚 Kết luận: Đối với nhu cầu “cung cấp desktop Windows hoặc Linux cho nhân viên làm việc từ xa, truy cập bất kỳ lúc nào, từ bất kỳ thiết bị nào”, Amazon WorkSpaces là dịch vụ phù hợp nhất trong các lựa chọn đưa ra. 🚀

🔎 Phân tích câu hỏi
Công ty muốn test một ứng dụng mới. Khi nói “test” thường có nghĩa là:

• Tạo môi trường trong thời gian ngắn, không cố định.
• Không muốn “khóa” tài nguyên hay chi phí dài hạn.
• Muốn tận dụng khả năng mở rộng/thu hẹp nhanh chóng để mô phỏng tải, rồi dừng lại ngay khi test xong.

Vì vậy, câu hỏi đang hỏi về nguyên tắc (principle) của AWS nào hỗ trợ cách làm này.

✅ Đáp án đúng

✅ Scale up and down when needed without any long‑term commitments.

Giải thích:

• Nguyên tắc này phản ánh elasticity (tính co dãn) và pay‑as‑you‑go của AWS.
• Khi test, bạn có thể khởi tạo các tài nguyên (EC2, ECS, Lambda, RDS…) chỉ trong thời gian cần thiết, sau đó giảm quy mô hoặc tắt hẳn mà không bị ràng buộc hợp đồng dài hạn hay chi phí cố định.
• Điều này giúp giảm chi phí, tăng tốc độ triển khai, đồng thời đáp ứng nhanh các nhu cầu tải thay đổi trong quá trình test.
• Đây là một trong những AWS Well‑Architected Pillars – Cost Optimization và Reliability – khuyến khích sử dụng tài nguyên linh hoạt, chỉ trả tiền khi sử dụng.

❌ Các phương án sai và lý do

• ❌ Make long‑term commitments in exchange for a cost discount.

  • Giải thích: Việc ký hợp đồng dài hạn (Reserved Instances, Savings Plans) mang lại chiết khấu, nhưng lại đòi hỏi cam kết về thời gian (1‑3 năm). Đối với môi trường test ngắn hạn, việc này không hợp lý vì bạn sẽ trả tiền cho tài nguyên mà không dùng hết, làm tăng chi phí thay vì giảm.

• ❌ Have total control over the application infrastructure.

  • Giải thích: AWS cung cấp độ linh hoạt cao, nhưng “toàn quyền kiểm soát” thường ám chỉ việc tự quản lý toàn bộ hạ tầng (cấu hình, cập nhật, bảo mật…). Khi test, mục tiêu chính không phải là kiểm soát sâu mà là tận dụng dịch vụ quản lý, giảm gánh nặng vận hành. Vì vậy, nguyên tắc này không phải là “điểm mạnh” giúp test nhanh chóng.

• ❌ Manage all of the maintenance tasks associated with the cloud.

  • Giải thích: AWS đã tự động hoá hầu hết các tác vụ bảo trì (patching, backup, scaling). Việc tự mình “quản lý tất cả” các nhiệm vụ bảo trì sẽ làm tăng độ phức tạp và thời gian chuẩn bị môi trường test, trái ngược với mục tiêu “đơn giản, nhanh chóng”. Do đó, đây không phải là nguyên tắc hỗ trợ việc test.

📘 Kiến thức cập nhật đến năm 2026

• Elastic Compute Cloud (EC2) Spot Instances và Savings Plans: cung cấp chi phí linh hoạt, nhưng Spot phù hợp cho workloads ngắn hạn, không cần cam kết.
• AWS Auto Scaling và AWS Application Auto Scaling: tự động mở rộng/thu hẹp tài nguyên dựa trên metric, hỗ trợ môi trường test chịu tải biến động.
• AWS Lambda & Serverless: cho phép chạy code mà không cần provision server, rất thích hợp cho việc test nhanh.
• AWS Well‑Architected Framework (2025 edition): vẫn nhấn mạnh “Cost Optimization” – pay for what you use – và “Reliability” – scale on demand.

📚 Tham khảo

1. AWS Well‑Architected Framework – Cost Optimization Pillar (2025).
2. Amazon EC2 Spot Instances – “Run workloads with no long‑term commitments”.
3. AWS Auto Scaling Documentation – “Scale your applications up or down automatically based on demand”.
4. AWS Lambda – Serverless compute – “Pay only for the compute time you consume”.

Tóm lại: Để test một ứng dụng mới, công ty nên tận dụng nguyên tắc “Scale up and down when needed without any long‑term commitments” – cho phép tạo môi trường linh hoạt, giảm chi phí và thời gian triển khai. Các phương án còn lại either yêu cầu cam kết dài hạn, hoặc không liên quan tới nhu cầu test nhanh, ngắn hạn. 🚀

🔎 Phân tích câu hỏi

• Bối cảnh: Một công ty sẽ ra mắt website thương mại điện tử có rất nhiều hình ảnh sản phẩm.
• Yêu cầu: Công ty cần giám sát chi phí vận hành của website để đảm bảo không vượt quá ngân sách đã định.
• Câu hỏi: “Which AWS service or tool should the company use to monitor the ongoing costs of the website?” – tức là cần chọn dịch vụ/ công cụ AWS nào giúp theo dõi, phân tích và báo cáo chi phí một cách chi tiết, có thể lập ngân sách, cảnh báo, và đưa ra đề xuất tối ưu chi phí.

Trong các tùy chọn, AWS Cost Explorer là dịch vụ được thiết kế riêng cho mục đích này: nó cung cấp biểu đồ, báo cáo chi phí, phân tích chi phí theo dịch vụ, thẻ tag, thời gian, và cho phép tạo ngân sách, cảnh báo chi phí. Các dịch vụ còn lại (AWS SDKs, EC2 Image Builder, AWS CloudFormation) không phải là công cụ giám sát chi phí.

✅ Đáp án đúng

AWS Cost Explorer

• Lý do: Cost Explorer cho phép người dùng xem, phân tích và dự báo chi phí dựa trên dữ liệu chi phí và usage của AWS. Bạn có thể tạo báo cáo tùy chỉnh, lọc theo dịch vụ (ví dụ: Amazon S3 lưu trữ hình ảnh, EC2, CloudFront), thẻ tag, và thời gian. Ngoài ra, nó tích hợp với AWS Budgets để thiết lập cảnh báo khi chi phí/đúng ngân sách. Đối với một website có lượng lớn ảnh, chi phí lưu trữ S3, truyền tải CloudFront và các instance EC2 sẽ được hiển thị chi tiết, giúp công ty tối ưu và giữ trong ngân sách.

Nguồn tham khảo:

• AWS Documentation – AWS Cost Explorer (phiên bản cập nhật 2026) – https://docs.aws.amazon.com/cost-management/latest/userguide/cost-explorer-what-it-does.html
• AWS Blogs – “New Cost Explorer features for 2025‑2026” – https://aws.amazon.com/blogs/aws/category/management-tools/

❌ Giải thích các phương án còn lại

1️⃣ AWS SDKs

• Giải thích: AWS SDKs (Software Development Kits) là các thư viện lập trình (Python boto3, Java, JavaScript, …) cho phép các nhà phát triển tương tác với các dịch vụ AWS (tạo, đọc, cập nhật tài nguyên).
• Tại sao sai: SDK không cung cấp giao diện hay tính năng để giám sát chi phí. Bạn có thể dùng SDK để gọi API Cost Explorer, nhưng SDK bản thân nó không phải là công cụ “monitor chi phí”. Nó chỉ là công cụ để phát triển ứng dụng, không phải công cụ quản lý tài chính.

2️⃣ EC2 Image Builder

• Giải thích: EC2 Image Builder giúp tự động tạo, kiểm thử và phân phối Amazon Machine Images (AMIs) cho EC2.
• Tại sao sai: Công cụ này tập trung vào quản lý hình ảnh máy ảo, không liên quan đến việc thu thập, phân tích hay báo cáo chi phí hoạt động của website. Nó không cung cấp dashboard chi phí, báo cáo ngân sách hay cảnh báo tài chính.

3️⃣ AWS CloudFormation

• Giải thích: CloudFormation là dịch vụ Infrastructure as Code (IaC), cho phép bạn mô tả và triển khai toàn bộ kiến trúc AWS bằng template JSON/YAML.
• Tại sao sai: Mặc dù CloudFormation có thể giúp tiết kiệm chi phí bằng cách chuẩn hoá tài nguyên, nó không phải là công cụ giám sát chi phí. CloudFormation không cung cấp báo cáo chi phí, phân tích usage, hoặc cảnh báo ngân sách. Để xem chi phí, bạn vẫn cần Cost Explorer hoặc AWS Budgets.

🧩 Tổng kết

• Công cụ phù hợp để giám sát chi phí của website ecommerce là AWS Cost Explorer.
• Các công cụ khác (AWS SDKs, EC2 Image Builder, AWS CloudFormation) phục vụ các mục đích phát triển, tạo AMI, và triển khai hạ tầng chứ không phải theo dõi chi phí.

💡 Mẹo thực tiễn: Khi triển khai website có nhiều hình ảnh, hãy gắn thẻ (tag) cho các tài nguyên (S3 buckets, CloudFront distributions, EC2 instances) và dùng Cost Explorer cùng với AWS Budgets để thiết lập cảnh báo khi chi phí gần đạt ngưỡng ngân sách. Điều này giúp công ty phản ứng kịp thời, tối ưu chi phí (ví dụ: chuyển sang S3 Intelligent‑Tiering, sử dụng CloudFront cache, hoặc giảm kích thước EC2).

🔗 Tài liệu tham khảo

• AWS Cost Management – Getting Started with Cost Explorer (2026) – https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started.html
• AWS Well‑Architected Framework – Cost Optimization Pillar (2025‑2026) – https://aws.amazon.com/architecture/well-architected/

Chúc bạn thành công trong việc quản lý ngân sách cho dự án ecommerce! 🚀

🔎 Phân tích câu hỏi

Công ty đã triển khai một số public applications (ứng dụng công khai) và đặt chúng phía sau Application Load Balancers (ALB).
Mục tiêu hiện tại là cải thiện hiệu năng (performance) của các ứng dụng này.

Trong ngữ cảnh AWS, “cải thiện hiệu năng” cho các ứng dụng công khai thường liên quan tới:

• Giảm độ trễ mạng (latency) khi người dùng truy cập từ các vị trí địa lý khác nhau.
• Tối ưu hoá đường truyền dữ liệu, tránh “hop” không cần thiết qua Internet công cộng.
• Đưa người dùng tới điểm cuối (endpoint) gần nhất, đồng thời vẫn giữ được tính năng cân bằng tải của ALB.

Vì vậy, dịch vụ cần tăng tốc độ truyền tải và tối ưu hoá routing cho các kết nối internet toàn cầu, đồng thời vẫn có thể tích hợp với ALB đã hiện hữu.

✅ Đáp án đúng: AWS Global Accelerator

Vì sao AWS Global Accelerator là lựa chọn đúng?

1. Tối ưu hoá routing toàn cầu

   • Global Accelerator sử dụng mạng backbone của AWS (các Edge Locations) để đưa lưu lượng tới điểm cuối (endpoint) gần nhất (có thể là ALB, NLB, EC2, hoặc Elastic IP). Điều này giảm độ trễ mạng đáng kể so với việc người dùng phải đi qua Internet công cộng.

2. Cải thiện độ ổn định và tốc độ

   • Khi một đường truyền gặp sự cố, Global Accelerator tự động chuyển hướng sang đường truyền khỏe mạnh hơn mà không gây gián đoạn cho người dùng.
   • Các IP tĩnh (static anycast IP) của Global Accelerator cho phép khách hàng sử dụng DNS một lần duy nhất, giảm thời gian DNS resolution.

3. Tích hợp sẵn với Application Load Balancer

   • ALB có thể được khai báo làm endpoint cho Global Accelerator. Khi đó, mọi yêu cầu từ người dùng sẽ tới Global Accelerator trước, sau đó được chuyển tới ALB ở khu vực AWS gần nhất.

4. Không cần thay đổi kiến trúc hiện tại

   • Bạn chỉ cần tạo một accelerator, gán các ALB làm endpoint, và cập nhật DNS để trỏ tới IP anycast của accelerator. Các ứng dụng và ALB không cần thay đổi cấu hình nội bộ.

5. Các tính năng bảo mật & kiểm soát

   • Hỗ trợ AWS Shield Standard tự động bảo vệ trước các DDoS lớp mạng.
   • Có thể kết hợp với AWS WAF (đính kèm vào ALB) để lọc lưu lượng.

Với những lợi ích trên, AWS Global Accelerator chính là dịch vụ đáp ứng yêu cầu “cải thiện hiệu năng” cho các ứng dụng công khai đang chạy sau ALB.

❌ Giải thích các phương án sai

1️⃣ Amazon Connect

• Mô tả: Dịch vụ cloud‑based contact center giúp xây dựng và quản lý trung tâm cuộc gọi (call center).
• Tại sao không phù hợp: Connect tập trung vào giao tiếp thoại, chat và ticket cho khách hàng, không phải là công cụ tăng tốc mạng hay tối ưu hoá routing cho các ứng dụng web. Nó không can thiệp tới latency hoặc throughput của các ALB.

2️⃣ Amazon ElastiCache

• Mô tả: Dịch vụ in‑memory cache (Redis hoặc Memcached) giúp giảm tải cơ sở dữ liệu bằng cách lưu trữ dữ liệu tạm thời.
• Tại sao không phù hợp: Mặc dù ElastiCache cải thiện thời gian đáp ứng của các truy vấn dữ liệu nội bộ, nó không giảm độ trễ mạng giữa người dùng cuối và ALB. Câu hỏi yêu cầu cải thiện hiệu năng toàn cầu cho các ứng dụng công khai, không chỉ tối ưu hoá truy xuất dữ liệu.

3️⃣ Amazon CloudWatch

• Mô tả: Dịch vụ giám sát, thu thập log và metric cho tài nguyên AWS.
• Tại sao không phù hợp: CloudWatch đánh giá hiệu năng, cung cấp cảnh báo và dashboard, nhưng không can thiệp vào việc truyền tải dữ liệu hay giảm latency. Nó là công cụ giám sát, không phải tối ưu hoá mạng.

📚 Tham khảo (tính đến 2026)

1. AWS Global Accelerator Documentation – “How Global Accelerator works”, https://docs.aws.amazon.com/global-accelerator/latest/dg/what-is-global-accelerator.html (phiên bản 2026).
2. AWS Well‑Architected Framework – Performance Efficiency Pillar, 2025 revision, https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/.
3. Application Load Balancer Integration with Global Accelerator, AWS Blog, 2024, https://aws.amazon.com/blogs/networking-and-content-delivery/alb-global-accelerator-integration/.
4. Amazon ElastiCache Developer Guide, https://docs.aws.amazon.com/elasticache/latest/developerguide/ (đối chiếu tính năng caching).
5. Amazon CloudWatch User Guide, https://docs.aws.amazon.com/cloudwatch/latest/monitoring/ (đối chiếu chức năng giám sát).

🧩 Kết luận

• AWS Global Accelerator là dịch vụ duy nhất trong các lựa chọn có khả năng giảm độ trễ toàn cầu và cải thiện hiệu năng cho các ứng dụng công khai được đặt sau ALB.
• Các dịch vụ còn lại (Amazon Connect, Amazon ElastiCache, Amazon CloudWatch) phục vụ các mục đích khác (trung tâm liên hệ, caching, giám sát) và không đáp ứng yêu cầu cải thiện latency mạng toàn cầu.

✅ Vì vậy, đáp án đúng là AWS Global Accelerator.

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

• Công ty hiện có một ứng dụng chạy trên môi trường on‑premises.
• 1️⃣ Thời gian xử lý của mỗi lần chạy nhỏ hơn 5 phút.
• 2️⃣ Ứng dụng chỉ được gọi vài lần mỗi ngày (tần suất rất thấp).
• 3️⃣ Mục tiêu: di chuyển lên AWS và tiết kiệm chi phí tối đa.

Câu hỏi yêu cầu chọn dịch vụ AWS nào phù hợp nhất với đặc điểm “thời gian chạy ngắn, tần suất thấp” để giảm chi phí (cũng cần đáp ứng được giới hạn thời gian chạy ≤ 15 phút của dịch vụ tính phí theo lượt gọi).

✅ Đáp án đúng: AWS Lambda

Vì sao AWS Lambda là lựa chọn “most cost‑effective”?

• Pricing theo lượt gọi: Lambda tính phí dựa trên số lần thực thi (request) và thời gian tính bằng GB‑seconds. Với vài lần chạy mỗi ngày, chi phí gần như bằng 0 (đối với 1 triệu request và 400 ms đầu tiên mỗi tháng là miễn phí).
• Giới hạn thời gian chạy: Lambda hỗ trợ thời gian thực thi lên tới 15 phút (từ 2023 đã tăng lên 15 phút, duy trì tới 2026). Ứng dụng của công ty (< 5 phút) nằm trong giới hạn này.
• Không cần quản lý server: Không phải provisioning, scaling, patching EC2/ECS/EKS → giảm chi phí vận hành và nhân lực.
• Tự động scaling: Khi có 1‑2 request/ngày, Lambda sẽ chạy on‑demand và dừng ngay sau khi kết thúc, không giữ tài nguyên dư thừa.

Kết luận: Với tải thấp và thời gian chạy ngắn, Lambda cho phép trả tiền chỉ cho thời gian thực sự sử dụng, là giải pháp rẻ nhất hiện nay.

🧩 Phân tích các phương án khác (đúng & sai)

• Amazon Elastic Container Service (Amazon ECS)

  • ✅ Mô tả: Dịch vụ quản lý container, có thể chạy trên EC2 hoặc Fargate.
  • ❌ Tại sao không tối ưu:
    • Khi chạy trên Fargate, chi phí tính theo vCPU‑seconds và memory‑seconds, còn phải trả tiền cho tài nguyên đã provision trong suốt thời gian container chạy, ngay cả khi chỉ chạy vài phút.
    • Đối với few invocations per day, chi phí Fargate (hoặc EC2) sẽ cao hơn Lambda vì phải duy trì môi trường container (image pull, task definition).
    • Thêm vào đó, ECS không có mức miễn phí tương tự Lambda.

• Amazon Elastic Kubernetes Service (Amazon EKS)

  • ✅ Mô tả: Quản lý cụm Kubernetes, hỗ trợ cả EC2 và Fargate.
  • ❌ Tại sao không phù hợp:
    • Chi phí quản lý control plane: $0.10‑$0.12 per hour (khoảng $72‑$90/tháng) bất kể có workload hay không.
    • Khi chạy workload ít (vài lần/ngày), chi phí này làm tăng tổng chi phí đáng kể so với Lambda.
    • Quản lý cluster, node groups, và networking tăng độ phức tạp và chi phí vận hành.

• Amazon EC2

  • ✅ Mô tả: Máy ảo truyền thống, bạn tự cấu hình, quản lý, và trả tiền theo giờ (hoặc theo second với On‑Demand, Spot).
  • ❌ Tại sao không rẻ nhất:
    • Dù có tùy chọn Spot hoặc per‑second billing, bạn vẫn phải đảm bảo một instance luôn chạy (hoặc khởi động/dừng thủ công).
    • Với chỉ vài lần chạy/ngày, thời gian chạy < 5 phút, chi phí instance sẽ vượt quá Lambda vì bạn trả cho toàn bộ thời gian instance sẵn sàng, ngay cả khi không có workload.
    • Không có free tier cho instance lâu dài (trừ 750 giờ t2.micro/tháng trong 12 tháng đầu, nhưng vẫn không tối ưu cho workload ngắn hạn).

📚 Tham khảo tài liệu (2026)

1. AWS Lambda – Pricing (2026): https://aws.amazon.com/lambda/pricing/
2. AWS Fargate – Pricing (2026): https://aws.amazon.com/fargate/pricing/
3. Amazon EKS – Pricing (2026): https://aws.amazon.com/eks/pricing/
4. Amazon EC2 – On‑Demand & Spot Pricing (2026): https://aws.amazon.com/ec2/pricing/on-demand/
5. AWS Compute Savings Guide 2025‑2026 – phần so sánh chi phí Lambda vs. container services, AWS Whitepaper.

🛠️ Kết luận nhanh

• ✅ AWS Lambda → trả tiền cho mỗi lần thực thi, miễn phí mức sử dụng thấp, đáp ứng thời gian chạy < 5 phút.
• ❌ Amazon ECS / Amazon EKS / Amazon EC2 → yêu cầu tài nguyên luôn tồn tại hoặc có phí quản lý cố định, không phù hợp với workload “vài lần mỗi ngày, thời gian ngắn”.

Do đó, AWS Lambda là dịch vụ hỗ trợ ứng dụng cực kỳ tiết kiệm chi phí trong kịch bản này. 🚀

🔎 Phân tích câu hỏi

Câu hỏi yêu cầu xác định “perspective” (góc nhìn) nào trong AWS Cloud Adoption Framework (AWS CAF) chịu trách nhiệm cho khả năng “strategy management” (quản lý chiến lược).

AWS CAF gồm sáu góc nhìn (perspectives) được thiết kế để giúp các tổ chức đánh giá và lên kế hoạch chuyển đổi sang đám mây một cách toàn diện:

1. Business
2. People
3. Governance
4. Platform
5. Security
6. Operations

Mỗi góc nhìn chứa các “capabilities” (khả năng) và “outcomes” (kết quả) hỗ trợ các mục tiêu cụ thể. “Strategy management” nằm trong Business perspective – nơi tập trung vào việc định hình tầm nhìn, mục tiêu kinh doanh, và cách mà các sáng kiến đám mây gắn liền với chiến lược doanh nghiệp.

✅ Đáp án đúng

Business perspective

Lý do:

• Trong tài liệu AWS CAF (phiên bản cập nhật 2024‑2026), Business perspective bao gồm các capability sau: Business value, Business outcomes, Business strategy, and Strategy management.
• “Strategy management” được mô tả là khả năng xác định, duy trì và điều chỉnh chiến lược công nghệ và đám mây để đạt được mục tiêu kinh doanh. Do đó, nó thuộc về Business perspective.

❌ Giải thích các phương án còn lại

• People perspective

  • People perspective tập trung vào công tác phát triển lực lượng nhân sự, văn hoá, kỹ năng và đào tạo. Các capability chính là Talent Management, Organizational Change Management, Learning & Development. Không liên quan đến việc quản lý chiến lược doanh nghiệp, mà là việc chuẩn bị con người cho thay đổi.

• Governance perspective

  • Governance perspective liên quan tới quản trị rủi ro, tuân thủ, và quyết định về đầu tư. Các capability bao gồm Risk Management, Compliance, Policy Management. Mặc dù có yếu tố “policy” và “decision‑making”, nhưng không bao gồm “strategy management” – đây là khía cạnh chiến lược chung, không phải chỉ quản trị.

• Operations perspective

  • Operations perspective hướng tới vận hành hạ tầng và dịch vụ đám mây một cách hiệu quả, tự động và liên tục. Các capability chủ yếu: Incident Management, Service Management, Change Management. Không đề cập tới việc xác định hoặc điều chỉnh chiến lược kinh doanh.

📚 Tham khảo tài liệu

• AWS Cloud Adoption Framework (AWS CAF) – 2025 Update, AWS Documentation, Section “Business Perspective – Capabilities”.
• AWS Well‑Architected Framework – phần liên quan đến Business và Governance perspectives (được cập nhật thường niên, 2024‑2026).
• AWS CAF Whitepaper, “AWS Cloud Adoption Framework – Building a Cloud‑Ready Organization”, 2024 edition.

🧩 Tóm tắt nhanh (dạng liệt kê)

• Business perspective – ✅ chứa Strategy Management → đáp án đúng.
• People perspective – ❌ tập trung vào con người, kỹ năng, thay đổi văn hoá.
• Governance perspective – ❌ tập trung vào rủi ro, tuân thủ, chính sách.
• Operations perspective – ❌ tập trung vào vận hành, sự cố, tự động hoá.

Với việc hiểu đúng “perspective” nào chịu trách nhiệm cho “strategy management”, bạn sẽ lựa chọn Business perspective là đáp án chính xác. 🚀

🔎 Phân tích câu hỏi

Câu hỏi yêu cầu: “A company wants to consolidate its call centers to improve the customer voice and chat experience with call center agents. Which AWS service or tool will meet these requirements?”

• Mục tiêu: tập trung (consolidate) các trung tâm cuộc gọi, đồng thời cung cấp trải nghiệm thoại (voice) và chat (text) chất lượng cao cho khách hàng khi tương tác với các đại lý (agents).
• Yêu cầu chính: một nền tảng contact‑center được quản lý, hỗ trợ voice và chat, có khả năng tích hợp AI/ML (ví dụ Amazon Lex), tự động mở rộng, định danh người dùng, và cấu hình luồng làm việc (routing, queues, IVR).

Trong danh mục dịch vụ AWS hiện nay (tính đến năm 2026), dịch vụ đáp ứng đúng nhu cầu này là Amazon Connect – một dịch vụ contact‑center đám mây “fully‑managed” được thiết kế riêng cho các trường hợp sử dụng như trên.

✅ Đáp án đúng: Amazon Connect

Lý do lựa chọn

• Contact‑center toàn diện: Amazon Connect cung cấp một hệ thống trung tâm cuộc gọi tích hợp sẵn tính năng voice‑call handling, chat messaging, và agent desktop.
• Tích hợp AI: có sẵn Amazon Lex để tạo bot thoại & chat, Amazon Polly cho chuyển đổi văn bản‑sang‑giọng, và AWS Lambda để mở rộng logic nghiệp vụ.
• Tự động mở rộng & trả phí theo sử dụng: không cần quản lý hạ tầng, chi phí dựa trên thời gian sử dụng (phút cuộc gọi, tin nhắn chat).
• Quản lý người dùng và bảo mật: tích hợp với AWS IAM, AWS Directory Service, và Amazon Cognito (để xác thực khách hàng trong các kênh chat).
• Dashboard & reporting: cung cấp các báo cáo thời gian thực, phân tích chất lượng dịch vụ (QoS).

Do các yếu tố trên, Amazon Connect là giải pháp duy nhất trong các lựa chọn đáp ứng đầy đủ yêu cầu “consolidate call centers” và “improve voice & chat experience”.

🧩 Giải thích các phương án

1. Amazon Simple Notification Service (Amazon SNS)

• ❌ Sai
  • Mô tả: SNS là dịch vụ pub/sub messaging và mobile push notifications. Nó giúp gửi thông báo tới các endpoint (email, SMS, HTTP, SQS, Lambda…).
  • Tại sao không phù hợp: SNS không cung cấp chức năng quản lý cuộc gọi thoại, luồng chat, IVR hay giao diện cho đại lý. Nó chỉ là kênh truyền tải tin nhắn, không phải nền tảng contact‑center.
  • Kết luận: Không đáp ứng yêu cầu “consolidate call centers” hay cải thiện trải nghiệm voice & chat.

2. AWS Support Center

• ❌ Sai
  • Mô tả: AWS Support Center là giao diện quản lý ticket hỗ trợ cho khách hàng AWS, cung cấp các kênh liên lạc (web, email, chat) với đội ngũ hỗ trợ AWS.
  • Tại sao không phù hợp: Đây là công cụ nội bộ cho AWS Customer Support, không phải giải pháp contact‑center cho doanh nghiệp của khách hàng. Nó không hỗ trợ thoại, không thể tích hợp vào môi trường call‑center của công ty.
  • Kết luận: Không liên quan tới việc tập trung các trung tâm cuộc gọi của công ty.

3. Amazon Cognito

• ❌ Sai
  • Mô tả: Amazon Cognito cung cấp định danh và quản lý người dùng (user sign‑up, sign‑in, federation) cho các ứng dụng web & mobile.
  • Tại sao không phù hợp: Cognito chỉ xử lý xác thực/ủy quyền; nó không cung cấp chức năng thoại, chat, routing, IVR hay giao diện đại lý. Có thể được tích hợp vào Amazon Connect để xác thực khách hàng, nhưng không phải là giải pháp hoàn chỉnh để “consolidate call centers”.
  • Kết luận: Chỉ là một thành phần hỗ trợ, không phải dịch vụ đáp ứng toàn bộ yêu cầu.

4. Amazon Connect

• ✅ Đúng
  • Mô tả: Amazon Connect là dịch vụ cloud‑based contact center được AWS quản lý, hỗ trợ voice và chat, cho phép tạo IVR, routing, queue, và tích hợp AI.
  • Đáp ứng yêu cầu:
    • Consolidation: Tất cả các trung tâm cuộc gọi có thể chuyển sang một môi trường duy nhất trên AWS, giảm phức tạp hạ tầng.
    • Voice & Chat Experience: Cung cấp kênh thoại (SIP, PSTN) và chat (Web, mobile) đồng thời cho phép tạo bot AI bằng Amazon Lex để hỗ trợ khách hàng 24/7.
    • Scalability & Cost‑Efficiency: Tự động mở rộng theo nhu cầu, thanh toán theo phút gọi và tin nhắn chat.
    • Integration: Kết nối với CRM (Salesforce, ServiceNow), Lambda, S3, Kinesis, và các dịch vụ AI khác.

📚 Tham khảo (tính đến 2026)

1. Amazon Connect – Official Documentation – https://docs.aws.amazon.com/connect/latest/adminguide/what-is-amazon-connect.html
2. AWS Blog – “New features for Amazon Connect 2025‑2026” – cập nhật các cải tiến về AI, chat, và tích hợp Amazon SageMaker.
3. AWS Well‑Architected Framework – Operational Excellence Pillar – phần “Designing for high‑volume contact centers”.
4. AWS re:Invent 2025 Session – “Building Scalable Contact Centers with Amazon Connect & AI Services” (Video & Slides).

🛠️ Kết luận:
Với yêu cầu tập trung các trung tâm cuộc gọi, đồng thời cải thiện trải nghiệm thoại và chat, dịch vụ duy nhất đáp ứng đầy đủ là Amazon Connect. Các lựa chọn còn lại (SNS, AWS Support Center, Amazon Cognito) chỉ là các công cụ/ dịch vụ hỗ trợ một phần chức năng, không phải giải pháp toàn diện cho contact‑center. 🚀

🔎 Phân tích câu hỏi

Câu hỏi yêu cầu một loại mua EC2 đáp ứng 2 yêu cầu quan trọng:

1. Không bị gián đoạn (uninterruptible) – khi instance được khởi chạy, nó phải chạy liên tục cho tới khi người dùng tắt nó.
2. Trả tiền theo giây (pay‑by‑the‑second) – chi phí phải được tính theo thời gian thực, không cần cam kết trước hay trả trước.

Vì vậy, chúng ta cần tìm “purchasing option” mà:

• Có thể tạo ngay khi cần, không cần đặt trước hoặc đấu giá.
• Không có rủi ro bị dừng (không bị “interrupt”).
• Tính phí theo giây (từ 1 s trở lên, tính tối thiểu 60 s).

✅ Đáp án đúng: On‑Demand Instances

• Không bị gián đoạn: On‑Demand instances luôn sẵn sàng và chỉ bị dừng khi người dùng tự dừng hoặc terminate chúng. Không có cơ chế “interrupt” như Spot.
• Thanh toán theo giây: Từ ngày 2 tháng 10 năm 2017, AWS tính phí EC2 theo giây (đối với hầu hết các loại instance, ngoại trừ những loại legacy). Điều này vẫn được duy trì và mở rộng đến năm 2026.
• Khởi tạo khi cần: Bạn có thể launch instance bất kỳ lúc nào, không cần đặt trước hay cam kết tài nguyên.

🧩 Giải thích các phương án (giữ nguyên nội dung tiếng Anh)

- Reserved Instances

• Tại sao sai: Reserved Instances (RI) yêu cầu cam kết 1 hoặc 3 năm và trả trước một phần hoặc toàn bộ chi phí. Dù RI cung cấp mức giảm giá lớn, không phù hợp với yêu cầu “pay‑by‑the‑second” vì chi phí đã được trả trước (hoặc trả theo tháng) và không thể “tự do” bật/tắt ngay khi cần. Ngoài ra, RI không thay đổi cách tính thời gian chạy; nó chỉ là một công cụ chiết khấu cho các instance On‑Demand hiện có.

- Spot Instances

• Tại sao sai: Spot Instances được cung cấp dựa trên đấu giá giá thị trường và có thể bị dừng đột ngột (interrupted) khi giá spot vượt ngưỡng bạn đặt hoặc khi AWS cần tài nguyên. Vì yêu cầu “uninterruptible”, Spot không đáp ứng. Ngoài ra, Spot cũng tính phí theo giây, nhưng tính không ổn định do khả năng bị dừng.

- On‑Demand Instances

• Tại sao đúng: Như đã nêu ở trên, On‑Demand cho phép khởi tạo ngay, không có rủi ro gián đoạn, và tính phí theo giây. Đây là lựa chọn “pay‑as‑you‑go” thuần túy, phù hợp nhất với yêu cầu.

- Dedicated Instances

• Tại sao sai: Dedicated Instances chạy trên phần cứng riêng biệt cho tài khoản của bạn, giúp cô lập với các khách hàng khác. Tuy chúng không bị interrupt, nhưng:
  1. Chi phí cao hơn đáng kể so với On‑Demand vì phải trả phí “dedicated tenancy”.
  2. Không có tính năng tính phí theo giây cho toàn bộ thời gian (được tính theo giờ hoặc giây, nhưng mức giá cao).
  3. Yêu cầu “uninterruptible” đã được đáp ứng bởi On‑Demand mà không cần trả thêm phí “dedicated”.

📚 Tham khảo nguồn tài liệu (2026)

1. AWS Documentation – Amazon EC2 Pricing
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-pricing.html

   • Giải thích chi tiết về On‑Demand, Reserved, Spot, và Dedicated pricing models, bao gồm per‑second billing (được áp dụng cho hầu hết các instance loại “Linux/Unix” và “Windows”).

2. AWS Blog – “Per‑Second Billing for EC2 Instances” (2024 Update)
   https://aws.amazon.com/blogs/aws/per-second-billing-ec2/

   • Cập nhật về việc mở rộng tính phí theo giây tới các loại instance mới và vùng mới, xác nhận tính năng vẫn còn hiệu lực tới 2026.

3. AWS Well‑Architected Framework – Cost Optimization Pillar
   https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/overview.html

   • Hướng dẫn lựa chọn On‑Demand khi cần tính linh hoạt và tránh rủi ro gián đoạn.

🎯 Tóm tắt nhanh

• Câu hỏi: Cần EC2 không bị gián đoạn và trả tiền theo giây.
• Đáp án: On‑Demand Instances ✅
• Lý do: Đáp ứng 100 % yêu cầu, không cần cam kết, không có nguy cơ interrupt, và tính phí theo giây.
• Các lựa chọn khác: Reserved (cần cam kết), Spot (có thể interrupt), Dedicated (đắt và không cần).

Hy vọng phần phân tích trên giúp bạn nắm rõ lý do lựa chọn On‑Demand cho nhu cầu này! 🚀

📖 Giải thích nội dung câu hỏi
Câu hỏi yêu cầu xác định dịch vụ AWS nào có khả năng di chuyển (migrate) các instance Amazon EC2 từ một Region sang Region khác. Đây là tác vụ “lift‑and‑shift” toàn bộ máy ảo, bao gồm hệ điều hành, cấu hình, dữ liệu và các thiết lập mạng, mà không cần phải tái tạo lại từ đầu.

✅ Đáp án đúng

• AWS Application Migration Service

🔍 Lý do chọn:

• AWS Application Migration Service (trước đây là “AWS Server Migration Service” – S​MS) cung cấp khả năng sao chép, đồng bộ và chuyển đổi các instance EC2 qua lại giữa các Region một cách tự động.
• Dịch vụ này thực hiện replication continuous của máy chủ nguồn, tạo AMI (Amazon Machine Image) trong Region đích và cho phép launch instance mới dựa trên AMI đó.
• Từ 2024 AWS đã nâng cấp MGN để hỗ trợ cross‑region migration trực tiếp, giảm thời gian cut‑over và tối ưu chi phí.
• Được thiết kế để di chuyển workloads (Windows, Linux) mà không cần thay đổi ứng dụng hay kiến trúc mạng.

Tham khảo: AWS Application Migration Service – “What is AWS Application Migration Service?” (được cập nhật đến tháng 3/2026) 📘

❌ Các phương án sai và giải thích

• AWS Database Migration Service (AWS DMS)

  • DMS chuyên di chuyển dữ liệu của các cơ sở dữ liệu (RDS, Aurora, DynamoDB, MySQL, PostgreSQL, …) sang các môi trường đích, bao gồm cả chuyển Region.
  • Nó không di chuyển toàn bộ instance EC2, chỉ sao chép dữ liệu bảng và schema. Vì vậy không đáp ứng yêu cầu di chuyển máy ảo.
  • 👉 DMS là công cụ data‑level, không phải instance‑level.

• AWS DataSync

  • DataSync được thiết kế để đồng bộ và chuyển dữ liệu (file, object) giữa on‑premise, S3, EFS, FSx hoặc giữa các Region.
  • Nó không tạo AMI, không sao chép cấu hình hệ điều hành, không khởi chạy lại instance EC2 tại Region đích.
  • Vì vậy DataSync chỉ là công cụ chuyển file, không phải di chuyển toàn bộ máy ảo.

• AWS Migration Hub

  • Migration Hub là bảng điều khiển trung tâm để theo dõi tiến độ của các dự án di chuyển sử dụng các công cụ khác (MGN, SMS, DMS, …).
  • Nó không thực hiện việc di chuyển mà chỉ cung cấp tổng quan, báo cáo và tích hợp.
  • Do đó không phải là dịch vụ thực hiện migration EC2 qua Region.

Tham khảo:

• AWS Database Migration Service – “What is AWS DMS?” (2026) 📘
• AWS DataSync – “How DataSync works” (2025) 📘
• AWS Migration Hub – “Overview of AWS Migration Hub” (2024) 📘

🧩 Tóm tắt nhanh (danh sách)

• ✅ AWS Application Migration Service – đúng: Di chuyển toàn bộ EC2 instance giữa Region.
• ❌ AWS Database Migration Service (AWS DMS) – sai: Chỉ di chuyển dữ liệu cơ sở dữ liệu.
• ❌ AWS DataSync – sai: Chỉ đồng bộ file/obj, không di chuyển instance.
• ❌ AWS Migration Hub – sai: Chỉ là công cụ giám sát, không thực hiện migration.

💡 Mẹo thi: Khi câu hỏi hỏi “service can migrate Amazon EC2 instances”, hãy nghĩ tới các dịch vụ đối tượng là máy ảo (MGN, Server Migration Service). Các dịch vụ khác thường liên quan tới dữ liệu (DMS, DataSync) hoặc giám sát (Migration Hub). 🚀