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

🔍 Phân tích câu hỏi
Câu hỏi hỏi: “Which AWS service can companies use to subscribe to RSS feeds for updates about all AWS service issues?”
Nội dung yêu cầu một dịch vụ của AWS cho phép đăng ký (subscribe) RSS feed để nhận thông báo về tất cả các vấn đề, sự cố của các dịch vụ AWS (ví dụ: outage, degraded performance, scheduled maintenance). Đây là tính năng cung cấp cập nhật thời gian thực cho người dùng về trạng thái hoạt động của toàn bộ nền tảng AWS.

✅ Đáp án đúng

🟢 [ĐÚNG] AWS Health Dashboard

Lý do:

• AWS Health Dashboard (còn gọi là AWS Personal Health Dashboard) cung cấp một RSS feed cho mỗi loại sự kiện sức khỏe (service health, scheduled changes, etc.).
• Các công ty có thể đăng ký RSS để nhận thông báo tự động qua trình đọc RSS hoặc các công cụ tích hợp (ví dụ: Feedly, Outlook).
• Feed này bao phủ tất cả các vấn đề của các dịch vụ AWS trên toàn cầu, không chỉ riêng một region hay một dịch vụ cụ thể.
• Đây là nguồn thông tin chính thức, được cập nhật ngay khi AWS công bố sự cố hoặc thay đổi.

📚 Tham khảo: AWS Documentation – “AWS Health Dashboard – RSS feeds for health events” (phiên bản 2026).

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

• 🟥 [SAI] Amazon Simple Notification Service (Amazon SNS)

  • SNS là dịch vụ phân phối thông báo (email, SMS, SQS, HTTP/S, Lambda) nhưng không cung cấp RSS feed cho các sự kiện sức khỏe AWS.
  • SNS thường được dùng để đẩy thông báo do người dùng hoặc ứng dụng tạo ra, không phải để nhận cập nhật trạng thái dịch vụ AWS.

• 🟥 [SAI] AWS Config

  • AWS Config là dịch vụ quản lý cấu hình và đánh giá các tài nguyên AWS (tracking thay đổi, compliance).
  • Nó không liên quan tới việc cung cấp RSS feed cho các vấn đề dịch vụ; chức năng chính là ghi lại lịch sử cấu hình và đánh giá quy tắc.

• 🟥 [SAI] AWS CodeCommit - CodeCommit là dịch vụ lưu trữ repository Git được quản lý hoàn toàn bởi AWS.

  • Nó không có tính năng RSS feed cho các sự kiện sức khỏe dịch vụ; chỉ phục vụ việc lưu trữ và quản lý mã nguồn.

🧩 Tóm tắt nhanh

• AWS Health Dashboard → cung cấp RSS feed cho tất cả các sự kiện sức khỏe dịch vụ AWS → đúng.
• Amazon SNS, AWS Config, AWS CodeCommit → không có chức năng RSS feed cho vấn đề dịch vụ → sai.

📖 Nguồn tham khảo

1. AWS Health Documentation – “Getting started with AWS Health Dashboard” (phiên bản 2026).
2. AWS Blog – “Subscribe to AWS Health RSS feeds to stay informed about service health events”.
3. AWS Well‑Architected Framework – Chapter on Operational Excellence (đề cập việc giám sát và nhận cảnh báo qua AWS Health).

💡 Mẹo thực tiễn: Khi triển khai môi trường đa‑region, hãy đăng ký RSS feed của AWS Health Dashboard và đồng thời đẩy thông báo vào kênh Slack/Teams bằng cách kết hợp SNS → Lambda → webhook để toàn bộ đội ngũ luôn nhận được cảnh báo kịp thời.

🔎 Phân tích câu hỏi
Câu hỏi: “Which Amazon EC2 Reserved Instances term commitment will give users the MOST cost savings?”

• Yêu cầu bạn chọn khoảng thời gian cam kết (term) của Reserved Instances (RI) mang lại mức tiết kiệm chi phí lớn nhất so với việc chạy instance theo kiểu On‑Demand.
• Reserved Instances hiện nay (theo tài liệu AWS cập nhật đến 2026) chỉ có ba lựa chọn thời hạn: 1 year, 2 years, và 3 years. Không tồn tại “5 years” trong mô hình RI truyền thống.

✅ Đáp án đúng

• 🟢 3 years

🧩 Lý do chọn “3 years”

• Ưu đãi giảm giá sâu hơn: Khi bạn cam kết lâu hơn, AWS có thể dự đoán tải công việc tốt hơn và do đó giảm giá đáng kể.
• Mức giảm giá chuẩn (theo bảng giá AWS 2026):
  • 1‑year Standard RI: giảm khoảng 30‑40 % so với On‑Demand.
  • 2‑year Standard RI: giảm khoảng 40‑45 %.
  • 3‑year Standard RI: giảm up to 60 % (đối với một số loại instance và khu vực).
• Không có tùy chọn “5 years” trong RI, vì vậy không thể so sánh; nếu muốn cam kết dài hơn, bạn sẽ phải chuyển sang Savings Plans hoặc các hợp đồng doanh nghiệp (Enterprise Agreement) ngoài phạm vi câu hỏi.

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

• [SAI] 1 year
  ❌ Sai – Mặc dù 1 year là một tùy chọn hợp lệ, mức tiết kiệm so với On‑Demand thấp hơn so với 2 year và 3 year. Đối với hầu hết các loại instance, mức giảm chỉ khoảng 30‑40 %, không phải là mức cao nhất.

• [SAI] 2 years
  ❌ Sai – 2 year cung cấp mức giảm tốt hơn 1 year, nhưng vẫn thấp hơn so với 3 year. Đối với một số instance, mức giảm trung bình là 40‑45 %, chưa đạt mức tối đa có thể.

• [ĐÚNG] 3 years
  ✅ Đúng – Đây là thời gian cam kết dài nhất được hỗ trợ trong mô hình Reserved Instances và mang lại giảm giá sâu nhất (tối đa ~60 %). Do thời gian cam kết dài, AWS có thể tối ưu hoá tài nguyên và cung cấp mức chiết khấu cao nhất.

• [SAI] 5 years
  ❌ Sai – Không tồn tại tùy chọn “5 years” trong chương trình Reserved Instances. Nếu muốn cam kết lâu hơn, khách hàng phải sử dụng Savings Plans (cũng chỉ hỗ trợ 1‑3 years) hoặc các thỏa thuận doanh nghiệp tùy chỉnh. Do vậy, lựa chọn này không hợp lệ và không thể so sánh được.

🛠️ Kiến thức cập nhật (2026)

1. Reserved Instances (RI) – Standard & Convertible

   • Standard RI cho phép giảm giá cao nhất nhưng không thay đổi loại instance.
   • Convertible RI cho phép đổi sang các loại instance khác, nhưng mức giảm giá thấp hơn một chút.
   • Cả hai đều chỉ có các term 1, 2, 3 years.

2. Savings Plans (được giới thiệu 2019, vẫn còn hiệu lực 2026)

   • Cung cấp giảm giá linh hoạt hơn (Compute Savings Plans & EC2 Instance Savings Plans).
   • Term chỉ hỗ trợ 1 hoặc 3 năm; không có 2‑year hay 5‑year.

3. Enterprise Agreements (EA)

   • Dành cho khách hàng lớn, có thể đàm phán cam kết lâu dài (có thể >3 years) nhưng không thuộc phạm vi câu hỏi về “Reserved Instances”.

📘 Tham khảo

• AWS Documentation – Amazon EC2 Reserved Instances (phiên bản 2026).
• AWS Pricing – Savings Plans vs Reserved Instances (2026).
• AWS Blog – “New Savings Plans and Reserved Instance pricing updates” (tháng 2/2025).

🔑 Kết luận
Để đạt tiết kiệm chi phí tối đa khi sử dụng Reserved Instances, người dùng nên chọn kỳ cam kết 3 years. Đây là thời gian dài nhất được hỗ trợ trong mô hình RI và mang lại mức giảm giá cao nhất so với các tùy chọn ngắn hơn. 🚀

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

• Bối cảnh: Công ty đang thực hiện big data analytics và các massive parallel computations trên các máy chủ test và development trong môi trường AWS.
• Yêu cầu đặc biệt: “Có thể chấp nhận occasional downtime” (tạm dừng không thường xuyên).
• Mục tiêu: Tìm phương án mua EC2 rẻ nhất (MOST cost‑effective) đáp ứng được tính chất công việc cực kỳ không quan trọng về thời gian (có thể dừng lại khi bị thu hồi).

Với thông tin này, chúng ta cần so sánh các kiểu mua EC2 hiện có (tính đến tháng 4/2026):

Vì công việc test/dev và có thể chấp nhận downtime, Spot Instances là lựa chọn tiết kiệm nhất. Các tùy chọn còn lại (On‑Demand, Reserved, Savings) đều tốn nhiều hơn và không tận dụng được khả năng chịu gián đoạn của workload.

✅ Đáp án đúng

🔹 Spot Instances

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

1. On-Demand Instances (đánh dấu [SAI])

• Mô tả: Trả tiền theo giờ/phút, không cần cam kết trước.
• Chi phí: Là mức giá chuẩn, cao nhất trong các tùy chọn.
• Độ tin cậy: Không bị gián đoạn, luôn sẵn sàng.
• Tại sao sai ở đây?
  • Mặc dù đáp ứng được “có thể chấp nhận downtime”, nhưng không tận dụng được khả năng giảm chi phí mà công việc không yêu cầu uptime liên tục. Do công ty muốn giảm chi phí tối đa, On‑Demand không phải là lựa chọn hợp lý.

2. Spot Instances (đánh dấu [ĐÚNG])

• Mô tả: Mua tài nguyên EC2 từ dư thừa công suất với mức giá được giảm sâu (thường 70‑90 % so với On‑Demand).
• Chi phí: Rẻ nhất; có thể giảm tới 95 % trong một số vùng (ví dụ: us‑west‑2b khi có dư thừa).
• Độ tin cậy: Khi giá Spot tăng trên mức đặt hoặc tài nguyên hết, phiên sẽ được terminate với thông báo 2 phút. Điều này tạo “downtime” tạm thời.
• Điều kiện sử dụng: Phù hợp với workload có thể checkpoint/restart (big‑data jobs, batch processing, CI/CD, test môi trường).
• Vì sao là đáp án đúng?
  • Công ty có tolerate occasional downtime → Spot phù hợp.
  • Chi phí là rẻ nhất, đáp ứng mục tiêu “MOST cost‑effective”.

3. Reserved Instances (đánh dấu [SAI])

• Mô tả: Cam kết sử dụng một loại instance cố định trong 1‑3 năm, giảm giá 30‑60 % so với On‑Demand.
• Chi phí: Rẻ hơn On‑Demand nhưng đắt hơn Spot.
• Độ tin cậy: Không bị gián đoạn, nhưng phải trả tiền ngay cả khi không sử dụng.
• Tại sao sai?
  • Dù giảm chi phí, nhưng công ty không muốn cam kết lâu dài cho môi trường test/dev và không cần tính ổn định cao. Spot còn rẻ hơn nhiều.

4. Savings Plans (đánh dấu [SAI])

• Mô tả: Cam kết mức chi tiêu (đơn vị $/hour) cho bất kỳ loại EC2 nào, giảm 30‑55 % so với On‑Demand.
• Chi phí: Giảm đáng kể, nhưng không thấp bằng Spot.
• Độ tin cậy: Giống Reserved – không bị gián đoạn, nhưng cần dự đoán mức chi tiêu ổn định.
• Tại sao sai?
  • Không tận dụng được khả năng “downtime” và vẫn phải cam kết chi tiêu, do đó không phải là phương án tiết kiệm nhất cho môi trường test/dev không quan trọng.

🛠️ Khi nào nên cân nhắc các tùy chọn khác?

📘 Tham khảo (2026)

1. AWS Documentation – EC2 Pricing – https://docs.aws.amazon.com/ec2/pricing/on-demand/
2. AWS Spot Instances – Best Practices – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-bidding.html (cập nhật 2026, có phần “Spot Fleet” và “Capacity Optimized allocation strategy”).
3. AWS Savings Plans – Overview – https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/savings-plans.html
4. AWS Well‑Architected Framework – Cost Optimisation Pillar – https://wa.aws.amazon.com/wellarchitected/2026/cost-optimisation/

Tóm lại: Với môi trường test & development, big‑data batch jobs và khả năng chấp nhận downtime, Spot Instances là lựa chọn tiết kiệm chi phí nhất. Các tùy chọn còn lại đều không tận dụng được đặc tính “có thể dừng lại” và vì thế không đáp ứng mục tiêu “MOST cost‑effective”. 🎯

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

Công ty có các instance Amazon EC2 trong phòng thí nghiệm nghiên cứu.

• Mỗi instance chỉ chạy 3 giờ mỗi tuần (khoảng 156 giờ mỗi năm).
• Không được gián đoạn – nghĩa là khi instance đã khởi động, nó phải chạy đến khi công việc hoàn tất; không thể bị dừng bất ngờ bởi AWS.

Yêu cầu: Lựa chọn mô hình mua instance có chi phí thấp nhất đồng thời đảm bảo không bị gián đoạn.

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

Lý do lựa chọn:

• On‑Demand cho phép trả tiền theo giờ (hoặc giây) không cần cam kết thời gian sử dụng, vì vậy phù hợp với khối lượng công việc “thỉnh thoảng” – chỉ 3 giờ/tuần.
• Không có rủi ro bị dừng hoặc thu hồi, đáp ứng yêu cầu không thể bị gián đoạn.
• Khi so sánh chi phí với các tùy chọn có cam kết (Savings Plans, Reserved Instances) hoặc có tính rủi ro (Spot), On‑Demand thường rẻ hơn cho mức sử dụng rất thấp như vậy, vì các mô hình cam kết yêu cầu mức tiêu thụ tối thiểu để đạt được mức giảm giá.

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

1. Compute Savings Plan (đánh dấu SAI)

• Giải thích: Savings Plans là cam kết đầu ra tiền (dollar/hour) cho một khoảng thời gian 1 hoặc 3 năm, cho phép giảm giá lên tới ~66 % so với On‑Demand.
• Vì sao không phù hợp: Với chỉ 3 giờ/tuần, việc cam kết một mức chi tiêu cố định (ví dụ $0.10/giờ) sẽ gây lãng phí lớn vì phần thời gian không sử dụng sẽ vẫn bị tính phí. Ngoài ra, Savings Plans không giải quyết được vấn đề “không thể bị gián đoạn”, nhưng chi phí cam kết khiến chúng không phải là lựa chọn tiết kiệm nhất trong trường hợp sử dụng ít.

2. On-Demand Instances (đánh dấu ĐÚNG)

• Giải thích: Trả tiền theo giờ (hoặc giây) thực tế sử dụng, không có cam kết dài hạn, không có rủi ro bị thu hồi.
• Lý do phù hợp: Đối với khối lượng công việc chỉ 3 giờ/tuần, chi phí thực tế sẽ là giờ * giá On‑Demand. Không có phí “đặt cọc” hay “không sử dụng”. Đảm bảo không bị gián đoạn vì instance luôn có sẵn khi bạn khởi tạo.

3. Convertible Reserved Instances (đánh dấu SAI)

• Giải thích: Reserved Instances (RI) cung cấp giảm giá lên tới 72 % so với On‑Demand khi cam kết 1‑3 năm. Loại Convertible cho phép thay đổi loại, khu vực, hoặc OS trong thời gian cam kết.
• Vì sao không phù hợp: Đòi hỏi cam kết tối thiểu 1 năm, vì vậy chi phí hàng tháng/giờ cố định sẽ cao hơn so với thực tế sử dụng (156 giờ/năm). Khi sử dụng quá ít, bạn sẽ trả tiền cho thời gian không dùng, dẫn đến chi phí tổng lớn hơn so với On‑Demand.

4. Spot Instances (đánh dấu SAI)

• Giải thích: Spot cho phép mua công suất EC2 với mức giá giảm mạnh (đôi khi tới 90 % so với On‑Demand) dựa trên khả dụng dư thừa. Tuy nhiên, Spot có thể bị thu hồi bất cứ lúc nào khi giá Spot vượt quá giá thầu hoặc khi AWS cần tài nguyên.
• Vì sao không phù hợp: Yêu cầu không thể bị gián đoạn khiến Spot không đáp ứng được. Nếu công việc quan trọng dừng lại giữa chừng, kết quả sẽ không đạt yêu cầu, dù chi phí Spot rất hấp dẫn.

🛠️ Khi nào nên xem xét các tùy chọn khác?

• Compute Savings Plan / Reserved Instances: Thích hợp khi có khối lượng công việc ổn định, cao (ví dụ: chạy 24/7 hoặc ≥ 40 giờ/tuần) và bạn có thể cam kết dài hạn.
• Spot Instances: Phù hợp cho tải công việc không quan trọng thời gian, có thể chịu được việc dừng và khởi động lại (ví dụ: batch processing, big data, CI/CD pipelines có khả năng retry).

Trong trường hợp công việc ngắn, không thường xuyên và không cho phép dừng, On‑Demand luôn là lựa chọn an toàn và chi phí hợp lý nhất.

📘 Tham khảo

• Amazon EC2 Pricing – AWS Documentation (phiên bản 2026). https://docs.aws.amazon.com/ec2/pricing/on-demand/
• Savings Plans – AWS Docs. https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plan.html
• Reserved Instances – AWS Docs. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances.html
• Spot Instances – AWS Docs. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-requests.html

Kết luận: Đối với một lab chạy EC2 chỉ 3 giờ mỗi tuần và không thể bị gián đoạn, On‑Demand Instances là lựa chọn chi phí thấp nhất và đáp ứng đầy đủ yêu cầu. ✅

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

Một người dùng mới của AWS muốn tương tác với AWS Support bằng các cuộc gọi API (ví dụ: Support API để tạo case, lấy thông tin case, …).
Yêu cầu của đề bài: chọn gói AWS Support phù hợp nhất với chi phí thấp nhất nhưng đảm bảo khả năng gọi API.

✅ Đáp án đúng

🟢 AWS Business Support

Lý do: Gói Business Support (và Enterprise) là hai gói duy nhất cung cấp quyền truy cập vào AWS Support API. So sánh chi phí, Business Support có mức phí cố định $100/tháng (cộng phần trăm chi phí sử dụng AWS) – rẻ hơn rất nhiều so với Enterprise Support (tối thiểu $15.000/tháng và phí dịch vụ cao hơn). Vì vậy, Business Support là lựa chọn đúng và tiết kiệm nhất cho yêu cầu này.

🧩 Phân tích từng phương án

1️⃣ AWS Basic Support

• ❌ Không có quyền truy cập vào Support API.
• Chỉ cung cấp các tính năng hỗ trợ cơ bản: tài liệu, diễn đàn, và hỗ trợ 24/7 cho các vấn đề tài khoản, thanh toán.
• Do không đáp ứng yêu cầu “sử dụng API”, nên bị loại.

2️⃣ AWS Developer Support

• ❌ Không có quyền truy cập vào Support API.
• Cung cấp hỗ trợ qua email trong giờ làm việc (business hours) và một số công cụ giám sát, nhưng không cho phép gọi API.
• Chi phí (khoảng $29/tháng) thấp hơn Business, nhưng không thỏa mãn yêu cầu kỹ thuật, vì vậy sai.

3️⃣ AWS Business Support (ĐÚNG)

• ✅ Cung cấp AWS Support API (được mô tả trong tài liệu AWS Support API).
• Đáp ứng đầy đủ yêu cầu “interact with AWS Support by using API calls”.
• Chi phí cố định $100/tháng + 10 % phí dịch vụ trên chi phí AWS (tối đa 10 % tùy mức tiêu thụ).
• So với Enterprise, chi phí thấp hơn rất nhiều, nên lựa chọn tiết kiệm nhất.

4️⃣ AWS Enterprise Support

• ✅ Cũng có quyền truy cập vào Support API, đồng thời cung cấp các tính năng cao cấp như Technical Account Manager (TAM), tư vấn kiến trúc, review bảo mật…
• Tuy nhiên, chi phí tối thiểu $15.000/tháng (cùng với phí dịch vụ %).
• Vì mục tiêu là chi phí hiệu quả nhất, Enterprise quá đắt so với Business cho cùng một tính năng API, nên sai.

📌 Các điểm cần nhớ (cập nhật đến 2026)

• Support API: Được công bố trong [AWS Support API documentation] (https://docs.aws.amazon.com/awssupport/latest/APIReference/Welcome.html). Chỉ các gói Business và Enterprise được phép tạo, liệt kê, và cập nhật case qua API.
• Giá cả (tháng 2026):
  • Business – $100 + 10 % phí dịch vụ (cực đa 10 % của chi phí AWS).
  • Enterprise – $15.000 + 10 % phí dịch vụ (cũng tối đa 10 %).
• Basic và Developer không có khả năng sử dụng API, chỉ hỗ trợ qua console hoặc email (Developer) / forum (Basic).

Vì vậy, khi yêu cầu cần gọi API, lựa chọn duy nhất đáp ứng và đồng thời tiết kiệm là AWS Business Support.

📚 Tham khảo

• AWS Support Plans – trang chính thức AWS, mô tả các tính năng và mức giá của từng gói (https://aws.amazon.com/premiumsupport/plans/).
• AWS Support API Reference – chi tiết các API và quyền truy cập (https://docs.aws.amazon.com/awssupport/latest/APIReference/).
• AWS Pricing – Support – cập nhật giá tháng 2026 (https://aws.amazon.com/premiumsupport/pricing/).

🔚 Kết luận: Để tương tác với AWS Support qua API một cách tiết kiệm chi phí, chọn AWS Business Support. Các gói khác không hỗ trợ API (Basic, Developer) hoặc chi phí quá cao (Enterprise).

🔍 Phân tích câu hỏi
Câu hỏi mô tả một công ty đã chuyển sang sử dụng AWS Cloud và hiện trả tiền cho các dịch vụ dựa trên nhu cầu thực tế (pay‑as‑you‑go). Yêu cầu là xác định điểm lợi thế mà công ty đang hưởng từ mô hình điện toán đám mây.

Trong 5 “đặc tính” chính của cloud computing (theo NIST và tài liệu AWS), “pay‑as‑you‑go” / “elasticity” cho phép doanh nghiệp chuyển đổi chi phí cố định (CAPEX) thành chi phí biến đổi (OPEX). Khi sử dụng tài nguyên theo nhu cầu, công ty chỉ trả tiền cho những gì họ thực sự dùng, thay vì phải đầu tư và duy trì cơ sở hạ tầng vật lý.

Do đó, đáp án đúng là “Trade fixed expense for variable expense.”

✅ Đáp án đúng

🟢 Trade fixed expense for variable expense

• Lý do:
  • Khi chuyển sang AWS, công ty không còn phải mua, lắp đặt và bảo trì máy chủ vật lý (chi phí vốn cố định). Thay vào đó, họ trả tiền theo mức độ sử dụng (chi phí hoạt động biến đổi).
  • Đây là một trong những lợi thế cốt lõi của mô hình pay‑as‑you‑go, giúp tối ưu hóa ngân sách, giảm rủi ro tài chính và tăng tính linh hoạt trong việc mở rộng hoặc thu hẹp tài nguyên.
  • Tài liệu AWS: AWS Pricing và AWS Well‑Architected Framework – Cost Optimization pillar (cập nhật đến 2026) luôn nhấn mạnh việc “convert capital expense to operational expense”.

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

• 🟥 Stop spending money running and maintaining data centers

  • Giải thích: Mặc dù di chuyển lên cloud thực sự giảm chi phí vận hành trung tâm dữ liệu, nhưng câu hỏi tập trung vào cách trả tiền dựa trên nhu cầu chứ không phải việc ngừng chi trả cho việc duy trì. Phương án này nói tới việc bỏ hoàn toàn chi phí vận hành, trong khi thực tế công ty vẫn trả cho dịch vụ AWS (đó chính là chi phí biến đổi). Do đó không phản ánh đúng lợi thế đang được nêu.

• 🟥 Increase speed and agility

  • Giải thích: Đúng là cloud mang lại tốc độ triển khai nhanh và độ linh hoạt cao, nhưng câu hỏi không đề cập tới thời gian triển khai hay khả năng phản hồi nhanh. Nó chỉ nói về cách thanh toán dựa trên nhu cầu, vì vậy đây không phải là đáp án phù hợp.

• 🟥 Go global in minutes

  • Giải thích: Khả năng phân phối ứng dụng toàn cầu nhanh chóng là một lợi thế của AWS (vùng Availability Zones, Edge Locations). Tuy nhiên, câu hỏi không liên quan tới việc mở rộng địa lý hay thời gian triển khai dịch vụ toàn cầu, mà chỉ nói tới mô hình thanh toán. Do vậy, tùy chọn này không đáp ứng yêu cầu câu hỏi.

📚 Tham khảo

• AWS Pricing – https://aws.amazon.com/pricing/ (phiên bản 2026)
• AWS Well‑Architected Framework – Cost Optimization Pillar, cập nhật 2026 – https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/
• NIST Definition of Cloud Computing, 2024 revision – https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf

🧩 Tóm tắt:
Công ty đang tận hưởng lợi thế “Trade fixed expense for variable expense” – chuyển đổi từ chi phí vốn cố định sang chi phí hoạt động biến đổi nhờ mô hình pay‑as‑you‑go của AWS. Các tùy chọn khác dù là lợi thế thực sự của cloud nhưng không phản ánh đúng ngữ cảnh câu hỏi. 🚀

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

• Bối cảnh: Công ty có một khối lượng công việc (workload) trên Amazon EC2 có tính ổn định, dự đoán trước được trong 3 năm tới. Đây là workload quan trọng (critical), nghĩa là không thể chấp nhận thời gian gián đoạn hoặc mất tài nguyên đột ngột.
• Mục tiêu: Tối ưu chi phí khi chạy workload trong thời gian dài, đồng thời đảm bảo tính sẵn sàng và độ ổn định.

Vì workload dự đoán được, thời gian chạy dài (3 năm) và có tính quan trọng cao, chúng ta cần một cơ chế giảm giá dựa trên cam kết sử dụng (commitment) nhưng không làm mất tính ổn định. Các lựa chọn đưa ra:

1. Spot Instances
2. Dedicated Hosts
3. Savings Plans
4. On‑Demand Instances

Ta sẽ xem xét từng phương án để chọn ra đáp án đúng.

✅ Đáp án đúng: Savings Plans

• Savings Plans là mô hình giảm giá dựa trên cam kết tiêu thụ (commitment) về số tiền (Compute Savings Plans) hoặc số lượng vCPU (EC2 Instance Savings Plans) trong 1 hoặc 3 năm.
• Ưu điểm chính:
  • Tiết kiệm lên tới 72 % so với giá On‑Demand, tùy thuộc vào loại plan và thời gian cam kết.
  • Linh hoạt: không cần chọn loại instance, khu vực, hay OS cụ thể (đối với Compute Savings Plans). Khi workload chuyển đổi giữa các loại instance, Savings Plans vẫn áp dụng.
  • Không bị gián đoạn: Không giống Spot, tài nguyên không bị thu hồi đột ngột; do đó phù hợp với workload critical.
  • Thời gian cam kết 3 năm phù hợp với thời gian dự kiến của công ty (3 năm).

Vì các yêu cầu “predictable workload”, “critical”, và “cost optimization over 3 years”, Savings Plans là giải pháp tối ưu nhất.

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

• Spot Instances

  • ❌ Không phù hợp vì Spot Instances cung cấp giá rẻ nhất (giảm tới 90 % so với On‑Demand), nhưng có thể bị thu hồi bất cứ lúc nào khi nhu cầu thị trường thay đổi.
  • Đối với workload quan trọng và cần độ ổn định cao, việc bị gián đoạn không thể chấp nhận.
  • Thêm vào đó, mặc dù workload “predictable”, Spot không cung cấp cam kết thời gian và đảm bảo tài nguyên trong 3 năm.

• Dedicated Hosts

  • ❌ Không phải là giải pháp chi phí tối ưu. Dedicated Hosts cung cấp máy chủ vật lý riêng cho tài khoản, giúp đáp ứng các yêu cầu tuân thủ (licensing, BYOL) và kiểm soát số lượng vCPU.
  • Tuy nhiên, giá thuê Dedicated Hosts thường cao hơn so với On‑Demand và rất ít khi được giảm giá như Savings Plans hay Reserved Instances.
  • Đối với mục tiêu tối ưu chi phí và không có yêu cầu đặc biệt về licensing hoặc compliance, Dedicated Hosts không phải là lựa chọn hợp lý.

• On‑Demand Instances

  • ❌ Không đáp ứng mục tiêu tối ưu chi phí. On‑Demand trả phí theo giờ (hoặc giây) mà không có bất kỳ cam kết nào, nên giá cao nhất trong các tùy chọn.
  • Dù cung cấp tính linh hoạt tuyệt đối, nhưng với workload dự đoán trước trong 3 năm, việc trả On‑Demand sẽ tốn kém đáng kể so với Savings Plans hoặc Reserved Instances.

🛠️ Khi nào có thể cân nhắc các giải pháp khác?

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

1. AWS Savings Plans – Documentation
   https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plan.html
2. AWS EC2 Spot Instances – Best Practices (2025 update)
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-batch.html
3. AWS Dedicated Hosts – Overview
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/dedicated-hosts-overview.html
4. AWS Pricing – Compute Savings vs. Instance Savings Plans (2026 Whitepaper)
   https://aws.amazon.com/whitepapers/pricing-compute-savings-plans/

🏁 Kết luận

• Đáp án đúng: Savings Plans – vì đáp ứng đầy đủ yêu cầu độ ổn định, dự đoán được, cam kết dài hạn (3 năm) và tiết kiệm chi phí tối đa.
• Các phương án còn lại đều không phù hợp do either rủi ro gián đoạn (Spot), chi phí cao (Dedicated Hosts, On‑Demand) hoặc không đáp ứng cam kết dài hạn.

💡 Mẹo thực hành: Khi triển khai workload quan trọng trong thời gian dài, hãy tính toán chi phí dựa trên Compute Savings Plans (linh hoạt hơn) và kiểm tra cân bằng giữa chi phí và nhu cầu compliance để quyết định có cần Dedicated Hosts hay không.

Chúc bạn ôn luyện thành công! 🚀

🔎 Phân tích câu hỏi
Công ty muốn ước tính chi phí cho kiến trúc AWS trước khi thực hiện di chuyển. Đây là nhu cầu “pre‑migration cost estimation” – tức là cần một công cụ cho phép nhập các dịch vụ, cấu hình, vùng, lượng sử dụng dự kiến và nhận ra số tiền dự kiến sẽ trả hàng tháng hoặc hàng năm.

AWS cung cấp một số dịch vụ liên quan tới chi phí, nhưng chỉ AWS Pricing Calculator được thiết kế đặc biệt để tính toán chi phí dựa trên các thông số người dùng nhập vào. Các dịch vụ khác (Amazon Detective, AWS Budgets, AWS Resource Explorer) không có chức năng này.

✅ Đáp án đúng: AWS Pricing Calculator

• Lý do chọn:
  • Là công cụ web‑based miễn phí, cho phép người dùng chọn các dịch vụ (EC2, RDS, S3, Lambda, …), cấu hình chi tiết (loại instance, loại lưu trữ, mức I/O, khu vực, thời gian chạy, …) và nhận ước tính chi phí ngay lập tức.
  • Hỗ trợ xuất bản báo cáo chi phí dưới dạng PDF/CSV, tích hợp với AWS Cost Explorer để so sánh thực tế sau khi triển khai.
  • Được cập nhật thường xuyên với giá mới nhất (ví dụ: giá Spot, Savings Plans, Reserved Instances, và các thay đổi giá vùng) và bao gồm các dịch vụ mới ra mắt đến tháng 03/2026 (ví dụ: Amazon Bedrock, AWS Mainframe Modernization).

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

• [SAI] Amazon Detective

  • Amazon Detective là dịch vụ phân tích bảo mật, giúp tự động thu thập, tổ chức và hiển thị dữ liệu log (VPC Flow Logs, CloudTrail, GuardDuty) để hỗ trợ điều tra sự cố bảo mật.
  • Nó không cung cấp khả năng tính toán chi phí hay ước lượng ngân sách. Vì vậy không đáp ứng yêu cầu “estimate cost”.

• [SAI] AWS Budgets

  • AWS Budgets cho phép đặt ngân sách và giám sát chi phí thực tế so với ngân sách đã định, đồng thời gửi cảnh báo khi vượt ngưỡng.
  • Tuy là công cụ quản lý chi phí, nhưng nó không có chức năng nhập các thông số kiến trúc để tính toán chi phí trước khi triển khai. Do đó không phù hợp với yêu cầu ước tính trước khi di chuyển.

• [SAI] AWS Resource Explorer

  • AWS Resource Explorer là tính năng đánh chỉ mục và tìm kiếm tài nguyên trên toàn tài khoản/region, giúp người dùng nhanh chóng tìm thấy EC2, RDS, S3 … đang tồn tại.
  • Nó không liên quan tới việc dự báo chi phí, mà chỉ hỗ trợ khám phá tài nguyên hiện có. Vì vậy không phải đáp án đúng.

• [ĐÚNG] AWS Pricing Calculator (đã giải thích ở trên)

📚 Tham khảo tài liệu (đến năm 2026)

1. AWS Pricing Calculator – Documentation
   https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/pricing-calculator.html (cập nhật lần cuối: March 2026).
2. AWS Cost Management Tools Overview – AWS Whitepaper, 2025 edition.
   https://d1.awsstatic.com/whitepapers/aws-cost-management-overview.pdf.
3. What's New in AWS – March 2026 – liệt kê các dịch vụ mới đã được tích hợp vào Pricing Calculator.
   https://aws.amazon.com/new/.

🎯 Kết luận

Để ước tính chi phí cho kiến trúc AWS trước khi thực hiện migration, công cụ phù hợp nhất là AWS Pricing Calculator. Các dịch vụ còn lại đều phục vụ mục đích quản lý, bảo mật hoặc khám phá tài nguyên, không cung cấp chức năng tính toán chi phí dựa trên cấu hình dự kiến.

✅ Đáp án cuối cùng: AWS Pricing Calculator.

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

• Yêu cầu của doanh nghiệp: “Quản lý trung tâm (centralized) quyền truy cập của nhân viên vào nhiều tài khoản AWS.”
• Điểm then chốt: Cần một giải pháp cho định danh (identity) và kiểm soát truy cập (access control) xuyên suốt các tài khoản, cho phép người dùng đăng nhập một lần (single sign‑on) và được gán quyền ở mức tài khoản hoặc ở mức tài nguyên.

Trong môi trường đa tài khoản, AWS cung cấp một số tính năng/ dịch vụ liên quan: AWS IAM Identity Center (trước đây là AWS SSO), AWS Organizations, AWS STS, IAM Access Analyzer, Secrets Manager, … Tuy nhiên, chỉ một trong số chúng đáp ứng đầy đủ yêu cầu “quản lý trung tâm quyền truy cập của nhân viên vào nhiều tài khoản”.

✅ Đáp án đúng: AWS IAM Identity Center

Lý do chọn:

• IAM Identity Center (trước tên AWS Single Sign‑On) cho phép đăng nhập một lần (SSO) và phân phối quyền (permission sets) tới các tài khoản AWS trong một tổ chức (AWS Organizations).
• Quản trị viên có thể tạo user, group và permission set trong IAM Identity Center, sau đó gán chúng cho tài khoản đích. Việc này thực hiện quản lý trung tâm: mọi thay đổi về quyền truy cập được thực hiện duy nhất tại IAM Identity Center, tự động phản ánh trên mọi tài khoản.
• Hỗ trợ đồng bộ với các IdP (Active Directory, Okta, Azure AD…) qua SAML 2.0 hoặc OIDC, giúp tích hợp với hệ thống quản lý danh tính hiện có của doanh nghiệp.
• Từ 2022 đến 2026, AWS đã nâng cấp IAM Identity Center, cho phép giao diện quản lý toàn diện, tích hợp với AWS Control Tower, và cung cấp audit logs trong AWS CloudTrail.

Do đó, IAM Identity Center là dịch vụ phù hợp nhất để “công ty muốn quản lý trung tâm quyền truy cập của nhân viên vào nhiều tài khoản AWS”.

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

1. AWS Identity and Access Management Access Analyzer

❌ Sai

• Chức năng thực tế: Access Analyzer giúp phân tích và hiển thị các chính sách IAM (policy) để xác định xem có tài nguyên nào đang được chia sẻ công khai ra ngoài tài khoản hay không.
• Không phải là công cụ quản lý người dùng hoặc SSO. Nó không cung cấp khả năng tạo, quản lý người dùng, nhóm, hoặc gán quyền truy cập xuyên tài khoản.
• Do vậy, nó không đáp ứng yêu cầu “quản lý trung tâm quyền truy cập” cho nhân viên.

2. AWS Secrets Manager

❌ Sai

• Chức năng thực tế: Secrets Manager lưu trữ, quay vòng và quản lý bí mật (password, API keys, DB credentials…) một cách an toàn.
• Nó không liên quan tới việc quản lý danh tính người dùng, cấp quyền truy cập tài khoản AWS, hay cung cấp SSO.
• Vì vậy, không phù hợp với yêu cầu của câu hỏi.

3. AWS IAM Identity Center

✅ Đúng

• Chức năng: Cung cấp đăng nhập một lần (SSO), quản lý danh tính trung tâm, phân phối permission sets tới nhiều tài khoản AWS trong AWS Organizations.
• Lợi ích:
  • Quản lý người dùng và quyền truy cập ở một nơi duy nhất.
  • Hỗ trợ tích hợp IdP SAML/OIDC.
  • Ghi lại mọi hoạt động trong CloudTrail.
  • Được cập nhật liên tục (đến 2026) với tính năng Permission Set versioning và Custom attribute mapping.

=> Đây là lựa chọn đúng.

4. AWS Security Token Service (AWS STS)

❌ Sai

• Chức năng thực tế: STS cung cấp các token tạm thời (temporary security credentials) cho người dùng hoặc dịch vụ, giúp thực hiện AssumeRole, AssumeRoleWithWebIdentity, v.v.
• STS là công cụ cấp quyền tạm thời, không phải công cụ quản lý danh tính trung tâm.
• Để dùng STSThông thể tự mình quản lý người dùng, nhóm hay permission sets cho nhiều tài khoản; nó thường được kết hợp với IAM hoặc IAM Identity Center, nhưng không đủ một mình để đáp ứng yêu cầu câu hỏi.

📚 Tham khảo tài liệu (đến năm 2026)

1. AWS Documentation – IAM Identity Center (phiên bản 2026):
   https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
2. AWS Security Blog – New features in IAM Identity Center 2025‑2026:
   https://aws.amazon.com/blogs/security/iam-identity-center-updates-2025-2026/
3. AWS Whitepaper – Managing Multi‑Account Environments with AWS Organizations and IAM Identity Center (2025):
   https://d1.awsstatic.com/whitepapers/aws-multi-account-management.pdf
4. AWS IAM Access Analyzer – Documentation:
   https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer.html

🛠️ Kết luận

• Để quản lý trung tâm quyền truy cập nhân viên vào nhiều tài khoản AWS, AWS IAM Identity Center là dịch vụ đúng và phù hợp nhất.
• Các lựa chọn còn lại (IAM Access Analyzer, Secrets Manager, STS) không cung cấp tính năng quản lý danh tính và phân quyền xuyên tài khoản, vì vậy chúng là sai trong ngữ cảnh câu hỏi.

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

• Bối cảnh: Một trường đại học nhận được khoản trợ cấp (grant) để thực hiện nghiên cứu bằng cách sử dụng các dịch vụ của AWS.
• Yêu cầu: Đảm bảo khoản tiền trợ cấp kéo dài suốt năm học. Nhóm nghiên cứu muốn phân bổ ngân sách theo tháng và cần được cảnh báo ngay khi chi tiêu vượt quá mức đã lên kế hoạch.

Vậy câu hỏi đặt ra: “Dịch vụ hoặc tính năng nào của AWS sẽ gửi thông báo khi chi tiêu vượt quá số tiền đã định?”

Điều này liên quan đến quản lý chi phí và ngân sách (cost management) trên AWS. AWS cung cấp một loạt công cụ để theo dõi, phân tích và kiểm soát chi phí, trong đó AWS Budgets là công cụ chuyên dụng để đặt ngân sách và gửi cảnh báo (via Amazon SNS, email, hoặc SMS) khi chi tiêu hoặc sử dụng tài nguyên vượt ngưỡng đã định.

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

• Lý do:
  • AWS Budgets cho phép bạn tạo ngân sách chi phí (Cost Budget), ngân sách sử dụng (Usage Budget) hoặc ngân sách dự án (Reservation Budget).
  • Khi chi tiêu thực tế (Actual) hoặc dự báo (Forecasted) vượt qua ngưỡng bạn đã thiết lập (ví dụ: 100 % ngân sách tháng), Budgets gửi cảnh báo tự động tới một hoặc nhiều Amazon SNS topics, email, hoặc SMS.
  • Bạn có thể cấu hình cảnh báo đa mức (ví dụ: 80 %, 100 %, 110 %) và lập lịch gửi thông báo hàng ngày hoặc hàng giờ.
  • Từ năm 2024 trở đi, AWS Budgets đã được nâng cấp để hỗ trợ Budget Actions, cho phép tự động dừng hoặc hạn chế dịch vụ khi vượt ngân sách (ví dụ: tắt EC2, giảm quy mô Auto Scaling). Tính năng này vẫn tồn tại và được mở rộng trong năm 2026.

Nguồn: AWS Documentation – AWS Budgets (phiên bản 2026) – https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html

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

1. Cost Explorer

   • Cost Explorer là công cụ phân tích chi phí và lập báo cáo. Nó cho phép bạn xem xu hướng chi tiêu, phân đoạn chi phí theo dịch vụ, thẻ tag, hoặc thời gian. Tuy nhiên, không có chức năng gửi cảnh báo tự động khi vượt mức ngân sách. Bạn có thể dùng Cost Explorer để đánh giá nếu có cảnh báo, nhưng không thể đặt ngưỡng và tự động thông báo.
   • 📌 Vì vậy, đây không phải là đáp án đúng.

2. Cost allocation tags

   • Cost allocation tags là nhãn (tag) mà bạn gắn vào các tài nguyên AWS để phân loại chi phí trong báo cáo (ví dụ: “Project=Research”, “Environment=Dev”). Chúng giúp phân tách chi phí theo mục đích hoặc sở hữu, nhưng không có khả năng theo dõi hoặc cảnh báo khi chi tiêu vượt ngưỡng.
   • 📌 Vai trò chỉ là gắn nhãn, không phải công cụ cảnh báo.

3. Cost categories

   • Cost categories cho phép bạn nhóm các chi phí dựa trên tag, tài khoản, hoặc dịch vụ thành các danh mục tùy chỉnh (ví dụ: “Research Grant”, “Operational”). Giúp đơn giản hóa báo cáo và đánh giá chi phí theo nhóm. Tuy nhiên, giống như Cost Explorer, không cung cấp cơ chế cảnh báo khi chi tiêu vượt mức.
   • 📌 Vì vậy, đây cũng là đáp án sai.

🛠️ Cách triển khai AWS Budgets để đáp ứng yêu cầu của đội nghiên cứu

1. Tạo Budget

   • Vào AWS Billing console → Budgets → Create budget.
   • Chọn Cost budget, đặt period là Monthly, nhập số tiền dự kiến cho mỗi tháng (tổng trợ cấp chia cho 12).

2. Cấu hình Alerts

   • Thêm Alert thresholds: 80 % (cảnh báo sớm), 100 % (cảnh báo vượt ngân sách), 110 % (cảnh báo quá mức).
   • Chọn Notification channel: Amazon SNS topic (ví dụ: arn:aws:sns:us-east-1:123456789012:GrantAlerts).

3. Thiết lập Budget Actions (tùy chọn)

   • Kích hoạt Budget Action để tự động dừng các tài nguyên EC2, RDS, hoặc giảm quy mô khi vượt 100 % ngân sách.
   • Điều này giúp ngăn chặn việc tiêu hết khoản trợ cấp trước thời hạn.

4. Theo dõi và báo cáo

   • Sử dụng AWS Cost Explorer kết hợp để phân tích chi tiết các mục tiêu chi tiêu đã vượt.
   • Đặt IAM policy để chỉ cho phép các thành viên có quyền view budgets và receive alerts, tránh thay đổi ngưỡng không mong muốn.

📚 Tham khảo

• AWS Budgets – Managing Your Costs (AWS Documentation, cập nhật 2026).
  https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/budgets-managing-costs.html
• AWS Billing and Cost Management – Best Practices (AWS Whitepaper, 2025).
  https://d1.awsstatic.com/whitepapers/aws-billing-cost-management-best-practices.pdf
• AWS Budgets Actions – Automate Cost Controls (AWS Blog, 2024).
  https://aws.amazon.com/blogs/aws/aws-budgets-actions-automate-cost-controls/

Tóm tắt: Để nhận thông báo khi chi tiêu vượt ngân sách hàng tháng, AWS Budgets là công cụ duy nhất trong các lựa chọn được đưa ra có khả năng đặt ngưỡng ngân sách và gửi cảnh báo tự động. Các công cụ còn lại (Cost Explorer, Cost allocation tags, Cost categories) chỉ phục vụ cho việc phân tích và phân loại chi phí, không hỗ trợ cảnh báo. ✅