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

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

Công ty có một khối lượng công việc (workload) chạy trên EC2 có các đặc điểm:

• Steady – tải không thay đổi, luôn ở mức tương đồng qua thời gian.
• Predictable – khả năng dự đoán được số lượng tài nguyên (CPU, RAM, …) cần thiết.
• Uninterruptible – không chấp nhận việc máy bị dừng hoặc “đánh bật” (interrupt).

Yêu cầu: chọn các tùy chọn mua EC2 sao cho đáp ứng được các đặc tính trên và đồng thời tối ưu chi phí. Câu hỏi yêu cầu chọn hai đáp án (choose two).

✅ Đáp án đúng

1. Reserved Instances
2. Saving Plans

Cả hai tùy chọn này đều cung cấp giảm giá lớn (từ 30 % đến hơn 70 % so với On‑Demand) khi cam kết sử dụng tài nguyên trong một hoặc ba năm. Chúng thích hợp cho workload ổn định, dự đoán được và không thể bị dừng, vì:

• Reserved Instances (RI) – Bạn mua “capacity reservation” (có hoặc không có) và nhận mức giá cố định trong suốt thời gian cam kết. Đối với workload không thay đổi, việc mua RI “Standard” (có “capacity reservation”) hoặc “Convertible” (linh hoạt chuyển đổi loại) sẽ tối đa hoá chi phí.
• Savings Plans – Được giới thiệu năm 2019 và đến 2026 đã mở rộng thành Compute Savings Plans (áp dụng cho mọi loại instance, vùng và OS) và EC2 Instance Savings Plans (giống như RI nhưng linh hoạt hơn). Khi workload ổn định, bạn có thể mua Compute Savings Plan 1‑ hoặc 3‑năm để giảm tới 66 % chi phí mà không cần “reserve capacity” cụ thể.

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

• On-Demand Instances

  • Giải thích: Đây là mô hình trả phí “the‑pay‑as‑you‑go” không có cam kết thời gian. Mặc dù đáp ứng được yêu cầu uninterruptible, nhưng chi phí cao hơn nhiều so với RI hoặc Savings Plans cho workload ổn định và dự đoán. Do không có giảm giá lâu dài, nên không phải là lựa chọn cost‑effective nhất.

• Spot Instances

  • Giải thích: Spot Instances cho phép mua tài nguyên với mức giá rất rẻ (đôi khi lên tới 90 % giảm so với On‑Demand), nhưng chúng có thể bị tắt bất cứ lúc nào khi giá Spot vượt ngưỡng hoặc tài nguyên hết. Vì workload của công ty không thể bị gián đoạn, Spot không phù hợp.

• Dedicated Hosts

  • Giải thích: Dedicated Hosts cung cấp máy chủ vật lý dành riêng cho tài khoản, thích hợp khi cần tuân thủ giấy phép phần mềm (License Mobility) hoặc yêu cầu cách ly phần cứng. Chi phí của Dedicated Hosts rất cao và không mang lại ưu đãi chi phí cho workload “steady & predictable” nếu không có yêu cầu đặc biệt về giấy phép hoặc bảo mật. Do đó không phải là lựa chọn tối ưu về chi phí.

🧩 Tổng hợp lý do lựa chọn

Vì vậy, Reserved Instances và Saving Plans là hai tùy chọn đáp ứng tất cả ba yêu cầu và mang lại chi phí thấp nhất.

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

1. AWS Documentation – Amazon EC2 Instance Purchasing Options (2026 update).
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-purchasing-options.html
2. AWS Savings Plans – Overview (2026).
   https://aws.amazon.com/savingsplans/
3. AWS Reserved Instances – Types and Pricing (2025).
   https://aws.amazon.com/ec2/pricing/reserved-instances/
4. AWS Well‑Architected Framework – Cost Optimization Pillar (2026).
   https://docs.aws.amazon.com/wellarchitected/latest/cost-optimization-pillar/welcome.html

🔚 Kết luận:
Đối với một workload đều đặn, có thể dự đoán và không thể ngắt quãng, các tùy chọn mua EC2 tiết kiệm chi phí nhất là Reserved Instances và Saving Plans. Các tùy chọn còn lại (On‑Demand, Spot, Dedicated Hosts) không đáp ứng đồng thời ba tiêu chí quan trọng và/hoặc có chi phí không tối ưu.

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

Câu hỏi yêu cầu xác định mô hình định giá Amazon EC2 nào tiết kiệm chi phí nhất cho một workload không thể gián đoạn (không được phép dừng lại) chỉ chạy 1 lần mỗi năm, trong 24 giờ.

Các yếu tố quan trọng cần cân nhắc:

1. Tần suất sử dụng rất thấp – chỉ 24 giờ trong một năm.
2. Không chấp nhận bị gián đoạn – nên tránh các tùy chọn có rủi ro “termination” (như Spot).
3. Không có nhu cầu “đặt trước” tài nguyên lâu dài – vì chỉ dùng một lần, việc trả phí trước (Reserved, Dedicated) sẽ không thu lại chi phí.

Do đó, mô hình trả tiền theo giờ sử dụng thực tế (pay‑as‑you‑go) là lựa chọn hợp lý nhất.

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

• Lý do:
  • Không cần cam kết thời gian sử dụng (không cần trả trước).
  • Thanh toán theo giờ hoặc giây (tùy loại instance) chỉ cho thời gian thực tế chạy, nên cho công việc 24 h/ năm, chi phí chỉ bằng thời gian thực tế.
  • Đảm bảo không bị gián đoạn vì tài nguyên luôn sẵn sàng khi bạn khởi tạo.

❌ Các phương án còn lại và lý do chúng không phù hợp

1. Reserved Instances

• Giải thích: Reserved Instances (RI) yêu cầu cam kết sử dụng 1‑ hoặc 3‑năm và thường yêu cầu trả trước (hoặc trả góp).
• Tại sao sai: Với workload chỉ chạy 24 giờ một năm, chi phí trả trước cho RI sẽ không bao giờ được “hoàn lại” bằng mức sử dụng thực tế, nên chi phí tổng thể cao hơn so với On‑Demand.

2. Spot Instances

• Giải thích: Spot Instances cung cấp giá rẻ nhất (thường 70‑90 % so với On‑Demand) nhưng có thể bị termination bất cứ lúc nào khi giá Spot vượt ngưỡng bạn đặt.
• Tại sao sai: Workload được mô tả là “uninterruptible” (không thể dừng). Nếu instance bị dừng giữa chừng, công việc sẽ thất bại hoặc cần phải thiết kế cơ chế khôi phục phức tạp, làm mất lợi thế chi phí. Vì vậy Spot không đáp ứng yêu cầu.

3. Dedicated Instances

• Giải thích: Dedicated Instances chạy trên phần cứng riêng dành riêng cho tài khoản của bạn, mang lại mức cách ly vật lý và chi phí cao hơn so với On‑Demand.
• Tại sao sai: Không có yêu cầu về cách ly phần cứng trong đề bài, và chi phí cao hơn không hợp lý cho một workload chỉ dùng 24 giờ/năm.

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

• Amazon EC2 Pricing – trang chính thức AWS (https://aws.amazon.com/ec2/pricing/) – mô tả chi tiết các mô hình On‑Demand, Reserved, Spot và Dedicated.
• AWS Documentation: EC2 Instance Pricing Options (2026) – phần “When to use On-Demand vs Reserved vs Spot”.
• AWS Well‑Architected Framework – Cost Optimization Pillar – khuyến nghị sử dụng On‑Demand cho workloads “infrequent and non‑interruptible”.

🧩 Tóm tắt nhanh

• On‑Demand Instances → ✅ Phù hợp nhất cho “once‑a‑year, 24‑hour, uninterruptible” workload.
• Reserved Instances → ❌ Cam kết dài hạn, không hiệu quả cho usage hiếm.
• Spot Instances → ❌ Rủi ro gián đoạn, không đáp ứng yêu cầu “uninterruptible”.
• Dedicated Instances → ❌ Chi phí cao, không cần thiết cho nhu cầu này.

Hy vọng phân tích chi tiết trên giúp bạn nắm rõ lý do lựa chọn On‑Demand là mô hình tối ưu nhất trong trường hợp này! 🚀

🔎 Phân tích câu hỏi
Câu hỏi hỏi: “Which option is a shared responsibility between AWS and its customers under the AWS shared responsibility model?”
Trong mô hình Shared Responsibility Model của AWS, trách nhiệm bảo mật được chia thành hai phần:

• AWS chịu trách nhiệm bảo mật “Cơ sở hạ tầng của AWS” (hạ tầng vật lý, mạng, trung tâm dữ liệu, server, lưu trữ, …).
• Khách hàng chịu trách nhiệm bảo mật “Các lớp mà họ kiểm soát” (hệ điều hành, cấu hình, ứng dụng, dữ liệu, quản lý khoá, patch …).

Một số nhiệm vụ được chia sẻ (shared) khi cả hai bên đều có vai trò: AWS cung cấp các công cụ, nền tảng, và quy trình cập nhật cơ bản; khách hàng phải sử dụng và duy trì chúng. Ví dụ điển hình là quản lý patch (patch management) cho hệ điều hành, phần mềm nền tảng, hoặc các dịch vụ do khách hàng tự quản lý.

✅ Đáp án đúng

✅ Patch management

Giải thích:

• AWS cung cấp các công cụ tự động (AWS Systems Manager Patch Manager, Amazon Inspector, Amazon Linux AMI tự cập nhật…) và đảm bảo rằng hạ tầng nền tảng (hypervisor, host) luôn được vá lỗi.
• Khách hàng vẫn phải lập kế hoạch, triển khai và kiểm tra các bản vá cho hệ điều hành, middleware và ứng dụng trên các instance EC2, RDS, hoặc container mà họ quản lý.
• Vì cả hai bên đều có trách nhiệm thực hiện và giám sát, nên patch management là một trách nhiệm chia sẻ.

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

• ❌ Configuration of Amazon EC2 instance operating systems

  • Lý do: Đây là trách nhiệm hoàn toàn của khách hàng. AWS chỉ cung cấp hạ tầng (hypervisor, mạng, lưu trữ). Việc cấu hình hệ điều hành, cài đặt phần mềm, thiết lập firewall nội bộ, v.v… thuộc quyền kiểm soát của người dùng.

• ❌ Application file system server-side encryption

  • Lý do: Mặc dù AWS cung cấp công cụ mã hoá (AWS KMS, S3 SSE, EBS encryption), việc quyết định, cấu hình và quản lý việc mã hoá dữ liệu ở mức ứng dụng là trách nhiệm của khách hàng. AWS không tự động mã hoá dữ liệu của ứng dụng nếu khách hàng không bật.

• ❌ Security of the physical infrastructure

  • Lý do: Đây là trách nhiệm độc quyền của AWS. AWS quản lý và bảo vệ các trung tâm dữ liệu, thiết bị phần cứng, hệ thống làm mát, nguồn điện, kiểm soát truy cập vật lý, v.v… Khách hàng không có quyền can thiệp vào lớp này.

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

1. AWS Documentation – Security Documentation – Shared Responsibility Model (phiên bản 2026).
   https://docs.aws.amazon.com/whitepapers/latest/aws-security-best-practices/shared-responsibility.html
2. AWS Systems Manager – Patch Manager (cập nhật 2026).
   https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html
3. AWS Well‑Architected Framework – Security Pillar (2026).
   https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html

🧩 Kết luận

Trong mô hình chia sẻ trách nhiệm, Patch management là ví dụ tiêu biểu cho một nhiệm vụ mà cả AWS (cung cấp công cụ và cập nhật lớp hạ tầng) và khách hàng (triển khai, kiểm tra, và duy trì các bản vá trên môi trường của mình) đều phải thực hiện. Các phương án còn lại thuộc về một bên duy nhất, vì vậy chúng không phải là trách nhiệm chung.

📖 Giải thích nội dung câu hỏi
Công ty muốn chuyển các workload hiện đang chạy on‑premises lên AWS và đồng thời muốn phân tách các workload để thực hiện chargeback (tính chi phí cho từng phòng/bộ phận). Vì vậy cần một cách để:

1. Tách biệt môi trường hoặc tài nguyên cho mỗi bộ phận (có thể là tài khoản riêng, hoặc một cơ chế quản lý chi phí).
2. Thu thập, báo cáo chi phí cho từng bộ phận một cách rõ ràng, đồng thời vẫn có thể hợp nhất (aggregate) chi phí tổng thể của công ty nếu muốn.

✅ Đáp án đúng (Choose two)

- Consolidated billing
- Multiple AWS accounts

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

1. Placement groups (SAI)

• Chức năng: Nhóm các EC2 instance lại với nhau để tối ưu hoá hiệu năng mạng (cluster, partition, spread).
• Tại sao không đáp ứng yêu cầu?
  • Không cung cấp bất kỳ cơ chế nào để tách biệt chi phí hay tạo báo cáo chargeback.
  • Chỉ liên quan tới việc bố trí tài nguyên để giảm độ trễ, không liên quan tới quản lý tài chính.

2. Consolidated billing (ĐÚNG)

• Chức năng: Cho phép một tổ chức (thông qua AWS Organizations) hợp nhất các hoá đơn của nhiều tài khoản AWS vào một hoá đơn duy nhất.
• Lợi ích cho chargeback:
  • Mỗi phòng/bộ phận có thể được cấp một tài khoản AWS riêng, nhưng vẫn được tổng hợp hoá đơn ở cấp tổ chức.
  • Kèm theo Cost Allocation Tags và AWS Cost Explorer, công ty có thể phân tích chi phí theo tài khoản hoặc thẻ tag, hỗ trợ việc tính phí lại (chargeback) cho từng bộ phận.
• Cập nhật tới 2026: Consolidated billing hiện là một tính năng mặc định của AWS Organizations; không cần bật riêng, nhưng vẫn được gọi là “Consolidated Billing” trong nhiều tài liệu.

3. Edge locations (SAI)

• Chức năng: Các điểm mạng (POP) của Amazon CloudFront, AWS Global Accelerator, và các dịch vụ khác để đưa nội dung gần người dùng cuối hơn.
• Tại sao không đáp ứng yêu cầu?
  • Chỉ liên quan tới việc phân phối nội dung, không có khả năng tách biệt hay báo cáo chi phí theo bộ phận.

4. AWS Config (SAI)

• Chức năng: Dịch vụ ghi lại cấu hình tài nguyên AWS và cho phép đánh giá tuân thủ (compliance).
• Tại sao không đáp ứng yêu cầu?
  • Mặc dù hữu ích để audit và tracking thay đổi, nhưng không cung cấp cơ chế tách chi phí hoặc tạo các đơn vị tính phí riêng cho các phòng ban.

5. Multiple AWS accounts (ĐÚNG)

• Chức năng: Tạo nhiều tài khoản AWS độc lập trong một tổ chức.
• Lợi ích cho chargeback:
  • Mỗi bộ phận/đơn vị kinh doanh có thể sở hữu một tài khoản riêng, giúp tách biệt tài nguyên, quyền truy cập, và chi phí.
  • Khi kết hợp với Consolidated billing, công ty vẫn nhận được một hoá đơn tổng hợp nhưng có thể phân tích chi phí từng tài khoản riêng biệt.
  • Hỗ trợ các tính năng bảo mật mạnh mẽ như Service Control Policies (SCPs), IAM Identity Center, giúp quản lý quyền hạn giữa các phòng ban.

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

• AWS Organizations – “Consolidated Billing” và “Multiple accounts” : https://docs.aws.amazon.com/organizations/latest/userguide/what-is.html
• AWS Cost Explorer & Cost Allocation Tags : https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
• Best practices for multi‑account strategy : https://aws.amazon.com/architecture/multi-account-strategy/
• Placement groups : https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html
• Edge locations (CloudFront) : https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/edge-locations.html
• AWS Config : https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html

✅ Tổng kết

• Để đáp ứng yêu cầu phân tách workload & chargeback, công ty nên sử dụng Multiple AWS accounts kết hợp với Consolidated billing (được quản lý qua AWS Organizations).
• Các lựa chọn còn lại (Placement groups, Edge locations, AWS Config) không liên quan tới việc tách chi phí và do đó không phù hợp với mục tiêu của câu hỏi.

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

Which option is a benefit of using AWS for cloud computing?

Câu hỏi yêu cầu bạn xác định điểm mạnh / lợi ích khi chọn Amazon Web Services (AWS) làm nền tảng điện toán đám mây. Ở mức độ cơ bản, AWS mang lại các ưu điểm về chi phí, tốc độ triển khai, tính linh hoạt, độ tin cậy và quản lý. Khi trả lời, bạn cần nhận ra đâu là lợi ích thực tế và đâu là khái niệm ngược lại (chi phí cố định, giảm tốc độ, v.v.).

✅ Đáp án đúng

• Pay‑as‑you‑go pricing

💡 Lý do:
AWS áp dụng mô hình “pay‑as‑you‑go” – bạn chỉ trả tiền cho tài nguyên mà mình thực sự sử dụng (tính theo giây, phút, hoặc giờ tùy dịch vụ). Điều này giúp:

1. Giảm chi phí ban đầu (không cần đầu tư hạ tầng vật lý).
2. Tối ưu hoá chi phí khi tải công việc thay đổi theo thời gian (scale up/scale down).
3. Tránh lãng phí tài nguyên nhờ tính năng tự động dừng, tắt, hoặc giảm quy mô (Auto Scaling, Spot Instances).
4. Dễ dự báo ngân sách qua các báo cáo chi tiết (AWS Cost Explorer, Budgets).

Nguồn: AWS Documentation – Billing and Cost Management (phiên bản 2026) 📘.

❌ Các phương án sai và phân tích

• Trade variable expense for fixed expense

  • Giải thích: Đây là đảo ngược lợi ích thực tế. AWS chuyển chi phí biến đổi (variable) thành chi phí cố định (fixed) không phải là một lợi thế; ngược lại, mô hình truyền thống (điện toán on‑premise) thường có chi phí cố định (đầu tư máy chủ, bảo trì). AWS giúp doanh nghiệp tránh chi phí cố định bằng cách trả theo mức sử dụng, vì vậy lựa chọn này không phải là lợi ích của AWS.

• Decreased speed and agility

  • Giải thích: AWS tăng tốc độ triển khai và tăng cường tính linh hoạt (agility) nhờ các dịch vụ như Elastic Beanstalk, CloudFormation, và các công cụ CI/CD (CodePipeline, CodeBuild). Việc nói “decreased speed and agility” là hoàn toàn ngược lại với thực tế; do đó đây là đáp án sai.

• Spending money running and maintaining data centers

  Giải thích: Khi sử dụng AWS, bạn không phải chi tiền để vận hành và bảo trì trung tâm dữ liệu của riêng mình – đây là một trong những lợi ích chính của dịch vụ đám mây (được gọi là “no‑ops” hoặc “operational excellence”). Vì vậy, việc phải chi tiền cho các data center không phải là lợi ích, mà ngược lại là nhược điểm của mô hình truyền thống.

🧩 Tổng hợp các lợi ích chính của AWS (để nhớ khi làm bài)

1. Pay‑as‑you‑go pricing – chỉ trả cho những gì dùng.
2. Scalability & elasticity – tự động mở rộng/thu hẹp tài nguyên.
3. Reduced capital expenditure (CapEx) – không cần đầu tư phần cứng.
4. Global infrastructure – triển khai nhanh trên nhiều vùng địa lý.
5. Managed services – giảm gánh nặng quản trị (RDS, DynamoDB, EKS…).

📚 Tham khảo

1. AWS Documentation – Billing and Cost Management, phiên bản cập nhật 2026.
2. AWS Well‑Architected Framework, đặc biệt là trục “Cost Optimization”.
3. AWS Whitepaper – “Overview of Amazon Web Services”, 2026 edition.

Kết luận: Đáp án đúng là “Pay‑as‑you‑go pricing”, vì đây là một trong những lợi ích cốt lõi nhất của việc sử dụng AWS cho điện toán đám mây. Các phương án còn lại đều mô tả những khía cạnh không đúng hoặc đảo ngược lợi ích thực tế của AWS. 🚀

📚 Câu hỏi:
Which option is an AWS Cloud Adoption Framework (AWS CAF) business perspective capability?

1️⃣ Giải thích nội dung câu hỏi

AWS Cloud Adoption Framework (CAF) là một khung chuẩn hướng dẫn doanh nghiệp chuyển đổi lên đám mây một cách có hệ thống. CAF chia ra 6 perspective (Business, People, Governance, Platform, Security, Operations) và mỗi perspective lại có nhiều capability (khả năng) cụ thể mà tổ chức cần phát triển để đạt được mục tiêu chuyển đổi.

Câu hỏi muốn bạn nhận diện khả năng (capability) thuộc perspective “Business” trong danh sách được đưa ra.

2️⃣ Đáp án đúng

✅ ĐÚNG – “Data monetization”

“Data monetization” là một trong các Business perspective capabilities của AWS CAF (được cập nhật trong phiên bản CAF 2024‑2025). Đây là khả năng giúp doanh nghiệp khai thác dữ liệu hiện có để tạo ra các nguồn thu mới hoặc cải thiện giá trị kinh doanh, phù hợp với mục tiêu “tăng giá trị kinh doanh” của perspective Business.

3️⃣ Phân tích toàn bộ các phương án

Lưu ý: Nội dung các lựa chọn được giữ nguyên bằng tiếng Anh, phần giải thích bằng tiếng Việt.

🔹 Culture evolution

• ❌ Sai – “Culture evolution” không nằm trong Business perspective mà thuộc People perspective (cụ thể là “Organizational Change Management”). Nó liên quan tới việc thay đổi văn hoá, tư duy và hành vi của nhân viên để thích ứng với môi trường đám mây, chứ không phải là một năng lực kinh doanh trực tiếp.

🔹 Event management

• ❌ Sai – “Event management” (quản lý sự kiện) là một Operations perspective capability. Trong CAF, Operations tập trung vào việc vận hành, giám sát, và phản ứng với các sự kiện, sự cố trong môi trường AWS. Do đó, nó không phải là năng lực thuộc Business perspective.

🔹 Data monetization

• ✅ Đúng – Như đã nêu ở trên, đây là Business perspective capability. Nó giúp doanh nghiệp xác định, thiết kế và triển khai các mô hình kiếm tiền từ dữ liệu (data‑driven revenue streams), đồng thời đo lường tác động tài chính của việc sử dụng dữ liệu trong đám mây.

🔹 Platform architecture

• ❌ Sai – “Platform architecture” là một Platform perspective capability. Nó liên quan tới thiết kế kiến trúc nền tảng (compute, storage, networking, databases…) trên AWS, chứ không phải về mục tiêu kinh doanh hay tạo ra giá trị kinh doanh trực tiếp.

4️⃣ Kiến thức cập nhật đến năm 2026

• AWS CAF 2025 (phiên bản mới nhất được công bố vào Q4 2024) đã mở rộng Business perspective để bao gồm các năng lực mới như Data monetization, Customer experience innovation, và Revenue model transformation.
• Tài liệu chính thức: AWS Cloud Adoption Framework – Business Perspective (AWS Documentation, phiên bản 2025).
• Các tài liệu liên quan:
  • AWS Well‑Architected Framework – Business Lens (2024).
  • AWS Whitepaper: “Driving Business Value with Data Monetization on AWS” (2025).

5️⃣ Tổng kết

• Đáp án đúng: Data monetization
• Lý do: Đây là năng lực (capability) thuộc Business perspective của AWS CAF, giúp doanh nghiệp tạo ra giá trị kinh doanh từ dữ liệu.
• Các đáp án còn lại thuộc các perspective khác (People, Operations, Platform), vì vậy chúng không phù hợp với yêu cầu câu hỏi.

🔎 Tham khảo:

1. AWS Cloud Adoption Framework (CAF) – Business Perspective, AWS Documentation, phiên bản 2025.
2. AWS Well‑Architected Framework – Business Lens, AWS, 2024.
3. Driving Business Value with Data Monetization on AWS, AWS Whitepaper, 2025.

Chúc bạn ôn tập hiệu quả và đạt điểm cao trong kỳ thi AWS Certified DevOps Engineer – Professional! 🚀✨

🔎 Phân tích câu hỏi
Công ty đang xem xét gói AWS Business Support hiện tại và cân nhắc chuyển sang AWS Enterprise Support.
Yêu cầu: “Which additional benefit will the company receive with AWS Enterprise Support?”
Nghĩa là: Khi nâng cấp lên Enterprise, công ty sẽ được hưởng một lợi ích mới mà Business không có.

✅ Đáp án đúng

✔️ A designated technical account manager (TAM) to assist in monitoring and optimization

💡 Lý do:

• Gói Enterprise Support cung cấp Technical Account Manager (TAM) riêng cho mỗi khách hàng doanh nghiệp. TAM là người liên hệ duy nhất, giúp theo dõi môi trường, đưa ra khuyến nghị tối ưu hoá chi phí, hiệu năng và bảo mật.
• Business Support không có TAM; chỉ có quyền truy cập vào đội ngũ Support Engineers qua kênh 24/7.

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

1️⃣ A full set of AWS Trusted Advisor checks

• 🔍 Thực tế: Cả Business và Enterprise đều cung cấp full set (tất cả 53) các kiểm tra của AWS Trusted Advisor.
• ❌ Vì vậy đây không phải là lợi ích “mới” khi chuyển lên Enterprise; nó đã có trong Business.

2️⃣ Phone, email, and chat access to cloud support engineers 24 hours a day, 7 days a week

• 🔍 Thực tế: Cả hai gói Business và Enterprise đều cho phép liên hệ hỗ trợ 24/7 qua điện thoại, email và chat.
• ❌ Vì vậy không phải là lợi ích bổ sung khi nâng cấp.

3️⃣ A designated technical account manager (TAM) to assist in monitoring and optimization (ĐÚNG)

• 🔍 Thực tế: Enterprise Support duy nhất có TAM (có thể là “Enterprise TAM” hoặc “Designated TAM”).
• ✅ Lợi ích: TAM cung cấp:
  • Theo dõi môi trường AWS, đưa ra khuyến nghị tối ưu hoá chi phí, hiệu năng và bảo mật.
  • Định kỳ tổ chức Well‑Architected Reviews, Infrastructure Event Management (IEM) cho các sự kiện lớn.
  • Hỗ trợ dự án chiến lược, lập kế hoạch migrattion, và quản lý rủi ro.
• ❎ Business Support chỉ có AWS Support Concierge (đối với các tài khoản Enterprise mới) và không có TAM riêng.

4️⃣ A consultative review and architecture guidance for the company’s applications

• 🔍 Thực tế: Enterprise Support cung cấp Well‑Architected Review và Architecture Guidance, tuy nhiên chúng luôn đi kèm với việc có TAM.
• ❌ Vì vậy, khi câu hỏi hỏi “benefit additional” thì đáp án đúng là “designated TAM”. Phần “consultative review” không được coi là lợi ích riêng biệt, mà là một trong các dịch vụ mà TAM thực hiện.

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

• AWS Support Plans – Comparison (AWS Documentation, cập nhật 2026): https://docs.aws.amazon.com/awssupport/latest/user/compare-awssupport-plans.html
• AWS Trusted Advisor – Feature Set (2026): https://aws.amazon.com/trusted-advisor/
• Technical Account Manager (TAM) – Enterprise Support (AWS Blog, 2025): https://aws.amazon.com/blogs/aws/enterprise-support-technical-account-manager/
• Well‑Architected Review – Enterprise Benefits (AWS Well‑Architected Tool, 2026): https://aws.amazon.com/well-architected-tool/

🧩 Tổng kết nhanh

• Enterprise Support bổ sung Technical Account Manager (TAM) – đây là lợi ích duy nhất không có trong Business Support.
• Các tùy chọn khác (Trusted Advisor đầy đủ, hỗ trợ 24/7, và consultative review) đã có sẵn trong Business hoặc là phần của TAM, nên không được xem là “additional benefit”.

🚀 Khi công ty muốn có đối tác kỹ thuật chuyên trách, tối ưu hoá chi phí và kiến trúc, việc nâng cấp lên Enterprise Support và nhận TAM là lựa chọn đúng đắn.

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

Câu hỏi yêu cầu xác định mô hình giá (pricing model) của Amazon EC2 mà sẽ làm gián đoạn (interrupt) một instance đang chạy khi khả năng cung cấp tài nguyên (capacity) tạm thời không có.

Điều này liên quan tới cơ chế pre‑emptible (có thể bị dừng) của một số loại EC2. Khi AWS không còn đủ năng lực phần cứng cho loại instance mà bạn đang sử dụng, các instance thuộc mô hình giá có tính chất “giá rẻ nhưng rủi ro” sẽ bị dừng lại (hoặc chuyển sang trạng thái “stopped/terminated”) để nhường chỗ cho các yêu cầu có độ ưu tiên cao hơn (ví dụ: On‑Demand hoặc Reserved).

✅ Đáp án đúng: Spot Instances

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

• On-Demand Instances

  • Giải thích: On‑Demand là mô hình trả phí theo giờ/phút, không bị gián đoạn khi capacity thay đổi. AWS luôn cố gắng duy trì khả năng cung cấp cho các instance On‑Demand; nếu thiếu capacity, AWS sẽ không khởi tạo instance mới, nhưng các instance đã chạy sẽ không bị dừng.
  • Kết luận: ❌ Không phải đáp án đúng.

• Standard Reserved Instances

  • Giải thích: Reserved Instances (RI) là cam kết sử dụng một loại instance nhất định trong 1‑3 năm để được giảm giá. Standard RI không ảnh hưởng tới trạng thái chạy của instance; chúng chỉ cung cấp giá ưu đãi và đảm bảo capacity (khi bạn mua “Capacity Reservation” kèm RI). Do đó, chúng không bị interrupt.
  • Kết luận: ❌ Không phải đáp án đúng.

• Spot Instances

  • Giải thích: Spot Instances cho phép mua sức mạnh tính toán không sử dụng ở mức giá chiết khấu lớn. AWS có thể đình chỉ (terminate) hoặc dừng (stop) instance khi:
    1. Giá Spot vượt mức giá bid của bạn.
    2. Capacity trở nên không khả dụng cho loại instance đó (ví dụ, tăng nhu cầu từ khách hàng On‑Demand).
       Khi xảy ra các trường hợp trên, AWS sẽ thông báo trước (thông thường 2 phút) và thực hiện interruption. Mô hình này được thiết kế để chấp nhận rủi ro gián đoạn, vì đổi lại người dùng được mức giá rất thấp.
  • Kết luận: ✅ Đây là đáp án duy nhất đáp ứng yêu cầu “interrupt a running instance if capacity becomes temporarily unavailable”.

• Convertible Reserved Instances

  • Giải thích: Convertible RI cho phép thay đổi loại, hệ điều hành, hoặc AZ trong thời hạn hợp đồng mà vẫn giữ mức giá ưu đãi. Tuy có tính linh hoạt cao hơn Standard RI, nhưng không có cơ chế interrupt. Khi capacity giảm, AWS sẽ cố gắng đảm bảo capacity cho các RI này (nếu bạn đã mua “Capacity Reservation” kèm).
  • Kết luận: ❌ Không phải đáp án đúng.

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

1. Amazon EC2 Pricing – phần “Spot Instances”
   https://aws.amazon.com/ec2/pricing/
2. AWS Spot Instances – How they work (AWS Documentation, cập nhật 2025)
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instancess.html
3. Reserved Instances – Types and Benefits (AWS Docs)
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/reserved-instances.html
4. On‑Demand Instances – Pricing and Availability (AWS Docs)
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/on-demand-instances.html

🧩 Tóm tắt nhanh

• On‑Demand, Standard RI, Convertible RI → Không bị interrupt khi capacity tạm thời mất.
• Spot Instances → Có khả năng bị interrupt (terminate hoặc stop) khi giá vượt mức đặt giá hoặc capacity tạm thời không có → Đáp án đúng.

Hy vọng phân tích trên giúp bạn nắm rõ nguyên tắc hoạt động của các mô hình giá EC2 và lý do Spot Instances là lựa chọn duy nhất phù hợp với mô tả trong câu hỏi. 🚀

🔎 Phân tích câu hỏi
Công ty muốn chạy một khối tải (workload) liên tục trên Amazon EC2 trong hơn 1 năm. Yêu cầu của đề là tìm phương án cho phép giảm giá giờ so với mức On‑Demand (giá trả theo giờ khi không có bất kỳ cam kết nào). Vì thời gian chạy dài và liên tục, AWS cung cấp các cơ chế chiết khấu như Reserved Instances, Savings Plans, Spot Instances… trong các lựa chọn đưa ra, chúng ta cần xác định cái nào thực sự mang lại “discounted hourly rate” so với On‑Demand.

✅ Đáp án đúng

🟢 EC2 Instance Savings Plans

• Giải thích: Savings Plans là một cam kết chi phí linh hoạt (1‑ hoặc 3‑năm) cho điểm tính năng CPU hoặc đối tượng Instance.
  • EC2 Instance Savings Plans cho phép bạn cam kết một loại instance cụ thể (family, region, OS, tenancy) và nhận giảm giá lên tới 72 % so với On‑Demand.
  • Vì workload chạy liên tục hơn 1 năm, công ty có thể ký Savings Plan 1‑year để nhận mức chiết khấu ổn định, đồng thời vẫn có thể thay đổi kích thước (instance type) trong cùng family mà không mất ưu đãi.
  • Đây là đáp án duy nhất trong các lựa chọn cung cấp giảm giá giờ so với On‑Demand.

📚 Tham khảo:

• AWS Documentation – Savings Plans (phiên bản 2026): https://docs.aws.amazon.com/savingsplans/latest/userguide/what-is-savings-plans.html
• AWS Blog – New Savings Plans Updates 2024‑2025: https://aws.amazon.com/blogs/aws/new-savings-plans-updates/

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

❌ AWS Graviton processor

• Giải thích: Graviton là bộ xử lý dựa trên ARM của AWS (Graviton2, Graviton3). Việc dùng Graviton có thể giảm chi phí so với các instance x86 vì mức giá giờ thấp hơn, nhưng không phải là “discounted hourly rate” được cung cấp bởi một cơ chế chiết khấu (như Savings Plans hay Reserved Instances).
• Kết luận: Không phải là lựa chọn đúng vì không phải là chương trình giảm giá có cam kết; nó chỉ là một loại instance với giá bản thân nó đã thấp hơn.

❌ Dedicated Hosts

• Giải thích: Dedicated Hosts cung cấp máy chủ vật lý độc quyền cho một tài khoản AWS, giúp đáp ứng các yêu cầu về giấy phép phần mềm hoặc tuân thủ.
• Dedicated Hosts không cung cấp chiết khấu so với On‑Demand; ngược lại, giá thường cao hơn do bạn trả tiền cho toàn bộ máy chủ vật lý, bất kể mức độ sử dụng.
• Kết luận: Không phải là đáp án đúng vì không mang lại mức giảm giá giờ so với On‑Demand.

❌ Amazon EC2 Auto Scaling instances

• Giải thích: Auto Scaling là dịch vụ quản lý quy mô tự động (tăng/giảm số lượng instance) dựa trên các quy tắc. Nó không thay đổi giá của các instance; Auto Scaling chỉ giúp tối ưu hoá số lượng instance đang chạy.
• Để giảm chi phí, người dùng vẫn cần kết hợp với Savings Plans, Reserved Instances hoặc Spot Instances, nhưng Auto Scaling tự thân không cung cấp mức giảm giá giờ.
• Kết luận: Không đáp án đúng.

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

• ✅ EC2 Instance Savings Plans – Cam kết 1‑ hoặc 3‑năm cho một family instance → giảm giá giờ so với On‑Demand (lên tới 72 %).
• ❌ AWS Graviton processor – Loại instance có giá gốc thấp hơn, không phải chương trình giảm giá cam kết.
• ❌ Dedicated Hosts – Cung cấp phần cứng độc quyền, giá thường cao hơn, không có chiết khấu.
• ❌ Amazon EC2 Auto Scaling instances – Tự động điều chỉnh số lượng instance, không thay đổi giá giờ.

🛠️ Lời khuyên thực tiễn (đối với bài toán thực tế)

1. Đánh giá mức độ ổn định của workload: nếu thực sự liên tục và dự đoán được, hãy cân nhắc Savings Plans 1‑year hoặc 3‑year để tối ưu chi phí.
2. Kết hợp với Graviton: nếu workload tương thích với ARM, bạn có thể chọn Graviton instance trong Savings Plan để tận dụng cả giá gốc thấp và chiết khấu.
3. Theo dõi usage qua AWS Cost Explorer để xác nhận mức tiết kiệm thực tế và điều chỉnh cam kết nếu cần.

🚀 Kết luận:
Trong bối cảnh công ty muốn chạy workload EC2 liên tục hơn 1 năm, EC2 Instance Savings Plans là lựa chọn duy nhất trong các phương án đưa ra cung cấp giảm giá giờ so với On‑Demand. Các tùy chọn khác (Graviton, Dedicated Hosts, Auto Scaling) không đáp ứng yêu cầu về “discounted hourly rate” theo nghĩa chương trình chiết khấu có cam kết.

🔍 Câu hỏi:
Which characteristic of the AWS Cloud helps users eliminate underutilized CPU capacity?

1. Giải thích nội dung câu hỏi 📖

Câu hỏi đang hỏi đặc điểm (characteristic) nào của nền tảng AWS Cloud cho phép người dùng “loại bỏ” (eliminate) việc sử dụng CPU không hiệu quả (under‑utilized CPU capacity).

Trong môi trường điện toán đám mây, “CPU không được tận dụng” thường xuất hiện khi chúng ta khởi tạo một máy ảo (EC2 instance) với kích thước cố định và chỉ sử dụng một phần nhỏ tài nguyên CPU của nó. Khi nhu cầu thay đổi, chúng ta muốn tự động mở rộng hay thu hẹp tài nguyên để luôn duy trì mức sử dụng hợp lý, tránh trả tiền cho tài nguyên thừa. Vì vậy, câu hỏi đang hướng tới khả năng “điều chỉnh quy mô” (scale) một cách linh hoạt và tự động – chính là Elasticity (tính đàn hồi) của AWS.

2. Đáp án đúng ✅

• Elasticity

Lý do:
Elasticity (tính đàn hồi) là khả năng của hệ thống tự động mở rộng (scale‑out) khi nhu cầu tăng và thu hẹp (scale‑in) khi nhu cầu giảm, dựa trên các chỉ số như CPU utilization, network traffic, … Điều này cho phép các workload chỉ chi trả cho tài nguyên CPU thực sự đang được sử dụng, tránh hiện tượng “under‑utilized CPU capacity”.

Trong AWS, Elastic Load Balancing (ELB) kết hợp với Auto Scaling groups, Lambda, Fargate, và các dịch vụ serverless khác là các công cụ thực thi tính đàn hồi. Khi CPU utilization giảm dưới ngưỡng định trước, Auto Scaling sẽ giảm số lượng instance, hoặc thay đổi loại instance (ví dụ: từ m5.large sang t3.micro), nhờ đó loại bỏ CPU không được sử dụng.

3. Giải thích các phương án khác ❌

• Agility

  • Agility (tính nhanh nhạy) mô tả khả năng phát triển, triển khai và thay đổi ứng dụng nhanh chóng nhờ các dịch vụ như AWS CodePipeline, CloudFormation, và các môi trường dev/test. Nó không trực tiếp liên quan tới việc tối ưu hoá hoặc “loại bỏ” CPU không sử dụng; thay vào đó, nó tập trung vào tốc độ và linh hoạt trong việc xây dựng và cập nhật phần mềm.

• Reliability

  • Reliability (độ tin cậy) đề cập tới khả năng đảm bảo hệ thống luôn sẵn sàng và hoạt động đúng chức năng (high availability, fault tolerance). Các tính năng như Multi‑AZ deployments, Amazon RDS Multi‑AZ, và health checks giúp duy trì dịch vụ ổn định, nhưng không giải quyết vấn đề về tài nguyên CPU dư thừa.

• Durability

  • Durability (độ bền) liên quan tới khả năng bảo tồn dữ liệu lâu dài và không mất mát (ví dụ: S3 99.999999999% durability). Nó tập trung vào lưu trữ dữ liệu, không ảnh hưởng tới việc sử dụng CPU hay tối ưu hoá tài nguyên tính toán.

4. Tham khảo tài liệu 📚

• AWS Well‑Architected Framework – Pillar: Performance Efficiency – phần về Elasticity và Auto Scaling (https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/elasticity.html)
• Amazon EC2 Auto Scaling – cách thiết lập policies dựa trên CPU utilization (https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html)
• AWS Cloud Adoption Framework – Business Perspective – Agility (để phân biệt với Elasticity) (https://aws.amazon.com/caf/)

5. Tổng kết 🏁

• Đặc điểm Elasticity là đáp án đúng vì nó cho phép hệ thống tự động điều chỉnh quy mô CPU dựa trên nhu cầu thực tế, từ đó loại bỏ tài nguyên CPU không được tận dụng.
• Các lựa chọn còn lại (Agility, Reliability, Durability) dù quan trọng trong kiến trúc đám mây, nhưng không giải quyết trực tiếp vấn đề “under‑utilized CPU capacity”.

Chúc bạn ôn tập tốt và đạt điểm cao trong kỳ thi AWS Certified DevOps Engineer – Professional! 🚀