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

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

Câu hỏi yêu cầu xác định những công việc nào thuộc trách nhiệm của AWS trong mô hình Shared Responsibility Model khi công ty đang sử dụng Amazon DynamoDB làm cơ sở dữ liệu ứng dụng.
Trong mô hình này, AWS chịu trách nhiệm “bảo mật của nền tảng (cloud)” – tức là hạ tầng vật lý, mạng, máy chủ, hệ điều hành, và các dịch vụ nền tảng sẵn sàng cung cấp (ví dụ: endpoint công cộng để truy cập dịch vụ).
Ngược lại, khách hàng chịu trách nhiệm “bảo mật trong nền tảng (in‑cloud)” – bao gồm việc phân loại dữ liệu, thiết lập quyền truy cập, và quyết định/triển khai các tùy chọn mã hoá.

Vì DynamoDB là một Dịch vụ quản lý (managed service), hầu hết các thành phần hạ tầng và phần mềm nền tảng đều do AWS quản lý.

✅ Đáp án đúng (chọn 2)

• Provide public endpoints to store and retrieve data.
• Manage the infrastructure layer and the operating system.

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

1. Classify data. (❌ Sai)

• Giải thích: Việc phân loại dữ liệu (data classification) là trách nhiệm của khách hàng vì họ hiểu nội dung, mức độ nhạy cảm và các yêu cầu tuân thủ (PCI‑DSS, HIPAA, GDPR…). AWS chỉ cung cấp công cụ hỗ trợ (ví dụ: AWS Macie) nhưng không thực hiện việc phân loại thay cho khách hàng.

2. Configure access permissions. (❌ Sai)

• Giải thích: Cấu hình quyền truy cập (IAM policies, resource‑based policies, fine‑grained access control) là việc khách hàng thực hiện. AWS cung cấp cơ chế (IAM, DynamoDB condition keys), nhưng quyết định ai có quyền đọc/ghi dữ liệu thuộc trách nhiệm của người dùng dịch vụ.

3. Manage encryption options. (❌ Sai)

• Giải thích: Quản lý tùy chọn mã hoá (kích hoạt Server‑Side Encryption, tạo/định danh KMS keys, thực hiện client‑side encryption) là trách nhiệm của khách hàng. AWS cung cấp các tính năng (SSE‑KMS, SSE‑AES256) và dịch vụ KMS, nhưng quyết định bật/tắt và quản lý key thuộc về người dùng.

4. Provide public endpoints to store and retrieve data. (✅ Đúng)

• Giải thích: AWS cung cấp các endpoint công cộng (URL, API endpoint) cho DynamoDB để khách hàng có thể gửi yêu cầu PutItem, GetItem, v.v. Đây là một phần của hạ tầng dịch vụ mà AWS vận hành và bảo trì.

5. Manage the infrastructure layer and the operating system. (✅ Đúng)

• Giải thích: Đối với DynamoDB, AWS chịu trách nhiệm quản lý toàn bộ lớp hạ tầng (cụm máy chủ, mạng, lưu trữ SSD, cân bằng tải) và hệ điều hành (và các bản vá, cập nhật bảo mật). Khách hàng không cần lo về provisioning, patching hay scaling của lớp này.

📌 Tóm tắt trách nhiệm theo mô hình Shared Responsibility (đến 2026)

📖 Tham khảo

• AWS Documentation – Shared Responsibility Model (phiên bản 2026). https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response/shared-responsibility-model.html
• Amazon DynamoDB Developer Guide – Security (cập nhật 2026). https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.Security.html
• AWS Well‑Architected Framework – Security Pillar (2025‑2026). https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/

Kết luận:
Trong mô hình chia sẻ trách nhiệm, AWS chịu trách nhiệm cung cấp endpoint công cộng và quản lý hạ tầng, hệ điều hành cho DynamoDB, trong khi khách hàng phải tự phân loại dữ liệu, cấu hình quyền truy cập và quyết định/triển khai các tùy chọn mã hoá. ✅✅

🔎 Phân tích câu hỏi
Câu hỏi yêu cầu: “Một công ty muốn tạo một nền tảng thương mại điện tử có thể truy cập toàn cầu, cần một dịch vụ DNS có tính sẵn sàng cao và có khả năng mở rộng để kết nối người dùng tới nền tảng.”

Các yếu tố cần chú ý:

1. DNS (Domain Name System) – dịch vụ này chịu trách nhiệm chuyển đổi tên miền (ví dụ: www.myshop.com) sang địa chỉ IP thực tế của các tài nguyên (EC2, Load Balancer, CloudFront,…).
2. Highly available & scalable – dịch vụ phải được triển khai trên nhiều vùng (multi‑AZ) và tự động mở rộng để đáp ứng lưu lượng truy cập tăng đột biến, đồng thời không có điểm lỗi đơn lẻ.
3. Globally accessible – người dùng trên toàn thế giới cần có thời gian phản hồi nhanh, vì vậy dịch vụ DNS cần có mạng lưới edge (anycast) trên toàn cầu.

Với những yêu cầu trên, AWS có một dịch vụ DNS chuyên dụng được thiết kế để đáp ứng: Amazon Route 53.

✅ Đáp án đúng: Amazon Route 53

Lý do chọn:

• Highly available: Route 53 chạy trên hạ tầng đa vùng (multiple AWS Regions) và sử dụng Anycast routing, nên khi một edge location gặp sự cố, yêu cầu sẽ được tự động chuyển sang edge khác mà không gián đoạn.
• Scalable: Không cần cấu hình dung lượng; dịch vụ tự động mở rộng để xử lý hàng tỷ truy vấn DNS mỗi ngày.
• Globally distributed: Mạng lưới Anycast của Route 53 có hơn 150 edge locations trên toàn cầu, cung cấp thời gian phản hồi nhanh cho người dùng ở bất kỳ khu vực nào.
• Tích hợp sâu: Hỗ trợ health checks, routing policies (latency‑based, geolocation, weighted, failover) và có thể liên kết trực tiếp với các tài nguyên AWS (ELB, CloudFront, S3, …) – rất thích hợp cho một nền tảng ecommerce toàn cầu.

Tham khảo:

• Amazon Route 53 Documentation – “Highly available and scalable DNS web service” (được cập nhật liên tục, phiên bản 2026).
• AWS Well‑Architected Framework – Reliability Pillar (đề cập tới việc sử dụng Route 53 cho DNS độ tin cậy cao).

🧩 Giải thích các phương án khác (đúng và sai)

• Amazon EC2

  • EC2 là dịch vụ máy ảo (compute) dùng để chạy ứng dụng, không phải là dịch vụ DNS. Mặc dù bạn có thể cài đặt phần mềm DNS trên một instance EC2, nhưng không đáp ứng yêu cầu “highly available & globally distributed DNS” vì bạn sẽ phải tự quản lý HA, scaling và mạng lưới edge. Vì vậy đây không phải đáp án đúng.

• Amazon VPC

  • VPC (Virtual Private Cloud) chỉ là một mạng ảo riêng trong AWS, giúp bạn định nghĩa subnet, routing table, security groups, … Nó không cung cấp dịch vụ DNS công cộng để người dùng cuối truy cập. VPC có một DNS resolver nội bộ (AmazonProvidedDNS) nhưng chỉ phục vụ nội bộ VPC, không phù hợp với mục tiêu “global ecommerce platform”.

• Amazon Route 53

  • Như đã phân tích ở trên, Route 53 là dịch vụ DNS công cộng, được thiết kế để đáp ứng các tiêu chí “highly available, scalable, globally accessible”.

• Amazon RDS

  • RDS (Relational Database Service) là dịch vụ quản lý cơ sở dữ liệu (MySQL, PostgreSQL, Aurora, …). Nó không phải là dịch vụ DNS và không có chức năng chuyển đổi tên miền sang IP. Việc sử dụng RDS cho DNS sẽ là sai lầm về kiến trúc.

📌 Kết luận

Đối với yêu cầu “một DNS web service có tính sẵn sàng cao, có khả năng mở rộng và có thể truy cập toàn cầu” → Amazon Route 53 là dịch vụ phù hợp nhất. Các dịch vụ khác (EC2, VPC, RDS) không đáp ứng các tiêu chí DNS và do đó là các lựa chọn sai.

🔗 Tài liệu tham khảo

1. Amazon Route 53 – Amazon Web Services (https://docs.aws.amazon.com/route53/) – cập nhật tính năng Anycast, health checks, routing policies (2026).
2. AWS Well‑Architected Framework – Reliability Pillar (https://aws.amazon.com/architecture/well-architected/).
3. AWS Global Infrastructure – Regions & Edge Locations (https://aws.amazon.com/about-aws/global-infrastructure/).

💡 Mẹo thực hành: Khi thiết kế một nền tảng ecommerce toàn cầu, hãy kết hợp Route 53 với Amazon CloudFront (CDN) và Elastic Load Balancing để tối ưu hoá latency, cung cấp fallback tự động và cân bằng tải ở mức DNS và tầng ứng dụng. 🚀

🔍 Phân tích câu hỏi
Câu hỏi: “Which maintenance task is the customer’s responsibility, according to the AWS shared responsibility model?”

• Mô hình chia sẻ trách nhiệm (AWS Shared Responsibility Model) phân chia rõ ràng giữa AWS (đảm nhận “Security of the Cloud”) và khách hàng (đảm nhận “Security in the Cloud”).
• “Security of the Cloud” bao gồm hạ tầng vật lý, mạng lõi, máy chủ, lưu trữ và các dịch vụ nền tảng – toàn bộ đều do AWS quản lý.
• “Security in the Cloud” là những gì khách hàng phải tự quản lý: hệ điều hành, ứng dụng, cấu hình bảo mật, bản vá phần mềm, quản lý khóa, IAM, v.v.

Vì vậy, câu hỏi đang hỏi công việc bảo trì nào thuộc trách nhiệm của khách hàng trong mô hình này.

✅ Đáp án đúng

🔹 Amazon EC2 updates and security patches

• Khi khách hàng sử dụng Amazon EC2, họ tự chịu trách nhiệm cập nhật hệ điều hành, phần mềm ứng dụng, và bảo mật (cập nhật bảo mật, vá lỗi, nâng cấp kernel, v.v.) trên các instance của mình.
• AWS chỉ cung cấp hạ tầng vật lý, hypervisor, và điều khiển mạng; nhưng vận hành, vá lỗi và quản lý cấu hình hệ điều hành trên instance là trách nhiệm của người dùng.
• Tài liệu AWS (AWS Security Documentation, “AWS Shared Responsibility Model” – cập nhật đến 2024‑2026) luôn nhấn mạnh: “Customers are responsible for patching the operating system and applications on EC2 instances.”

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

• 🔹 Physical connectivity among Availability Zones

  • Giải thích: Kết nối vật lý giữa các Availability Zones (AZ) – như các dây cáp quang, router, switch lõi – là thành phần hạ tầng vật lý do AWS quản lý. Khách hàng không có quyền truy cập hay can thiệp vào đây. AWS bảo đảm tính sẵn sàng, độ trễ và tính độc lập của các AZ.

• 🔹 Network switch maintenance
  Giải thích: Việc bảo trì, nâng cấp, hay thay thế các network switch trong trung tâm dữ liệu AWS thuộc trách nhiệm của AWS. Khách hàng chỉ tương tác ở lớp virtual networking (VPC, subnet, route tables) và không chịu trách nhiệm bảo trì phần cứng mạng.

• 🔹 Hardware updates and firmware patches
  Giải thích: Các bản cập nhật firmware, BIOS, hoặc thay thế phần cứng (CPU, RAM, ổ SSD…) nằm trong phạm vi Security of the Cloud – do AWS thực hiện thông qua quy trình AWS Global Infrastructure Maintenance. Khách hàng không được phép truy cập vào máy chủ vật lý, do đó không thể thực hiện việc này.

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

• Customer responsibility (Security in the Cloud)

  • 🛠️ Amazon EC2 updates and security patches ✅
  • Quản lý IAM, key, data encryption, firewall rules, OS & ứng dụng, backup, logging, monitoring.

• AWS responsibility (Security of the Cloud)

  • 🏢 Physical infrastructure, data center security, power, cooling.
  • 🌐 Physical connectivity among AZs, network switches, hardware & firmware maintenance.

📚 Tham khảo

1. AWS Documentation – Security Documentation

   • “AWS Shared Responsibility Model” (phiên bản cập nhật 2024‑2026).
   • URL: https://docs.aws.amazon.com/security/

2. AWS Well‑Architected Framework – Security Pillar (2025 revision).

   • Mô tả chi tiết các trách nhiệm của khách hàng trên EC2, RDS, Lambda, v.v.

3. AWS Blog – “What’s new in the AWS Global Infrastructure 2025”

   • Giới thiệu các cải tiến về mạng và bảo trì hạ tầng vật lý, khẳng định rằng hardware maintenance luôn do AWS thực hiện.

🧩 Kết luận:
Trong mô hình chia sẻ trách nhiệm, công việc bảo trì mà khách hàng phải tự thực hiện là “Amazon EC2 updates and security patches”. Các công việc liên quan đến hạ tầng vật lý (kết nối AZ, switch, firmware) đều thuộc trách nhiệm của AWS. 🚀

📖 Phân tích câu hỏi
Công ty muốn “cải thiện vị thế bảo mật bằng cách đánh giá hoạt động của người dùng qua các lời gọi API”. Điều này nghĩa là họ cần một dịch vụ ghi lại, lưu trữ và cung cấp khả năng tra cứu các API request (bao gồm các hành động trên console, SDK, CLI, và các dịch vụ AWS).

Yêu cầu:
1️⃣ Ghi lại tất cả các cuộc gọi API (đối với tài khoản, tổ chức, và các role).
2️⃣ Có thể tìm kiếm, lọc theo người dùng, thời gian, dịch vụ, …
3️⃣ Có khả năng xuất file log, tích hợp với các công cụ phân tích/bảo mật khác.

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

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

• AWS WAF

  • 🔍 Giải thích: AWS WAF (Web Application Firewall) là dịch vụ bảo vệ các ứng dụng web khỏi các tấn công tầng 7 (SQL injection, XSS, …). Nó không ghi lại các API call nội bộ của AWS, mà chỉ lọc lưu lượng HTTP/HTTPS tới các endpoint (CloudFront, ALB, API Gateway).
  • 💡 Vì sao sai: Yêu cầu của câu hỏi là “review user activity through API calls”, không phải “bảo vệ traffic web”. Vì vậy WAF không đáp ứng.

• Amazon Detective

  • 🔍 Giải thích: Amazon Detective là công cụ phân tích và điều tra các sự kiện bảo mật, dựa trên dữ liệu được cung cấp bởi AWS CloudTrail, VPC Flow Logs, và GuardDuty. Nó không tự mình thu thập các API call mà chỉ phân tích dữ liệu đã có.
  • 💡 Vì sao sai: Detective là lớp “phân tích” phía trên CloudTrail, không phải nguồn log gốc. Vì câu hỏi cần dịch vụ “đánh giá hoạt động người dùng qua API calls”, dịch vụ gốc là CloudTrail.

• Amazon CloudWatch

  • 🔍 Giải thích: Amazon CloudWatch chủ yếu dùng để giám sát metric, log, alarm và đánh giá hiệu năng của các tài nguyên AWS. Mặc dù CloudWatch Logs có thể nhận log từ CloudTrail, nó không tự động thu thập các API call.
  • 💡 Vì sao sai: CloudWatch không cung cấp bản ghi chi tiết của mọi API request; nó chỉ là nền tảng để hiển thị/điều kiện log đã được đẩy vào. Do đó không đáp ứng yêu cầu “review user activity” một cách trực tiếp.

• AWS CloudTrail

  • 🔍 Giải thích: AWS CloudTrail là dịch vụ ghi lại toàn bộ API call trong tài khoản (Console, SDK, CLI, các service integration). Nó lưu trữ log ở S3, có thể gửi tới CloudWatch Logs, và hỗ trợ event history để tìm kiếm theo người dùng, thời gian, dịch vụ, và hành động.
  • 💡 Vì sao đúng: Đây chính là dịch vụ “đánh giá hoạt động người dùng qua API calls”. CloudTrail giúp công ty theo dõi, phát hiện hành vi bất thường, và đáp ứng yêu cầu tuân thủ (PCI, HIPAA, …).

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

1. AWS CloudTrail Documentation – “What is CloudTrail?” (phiên bản 2026)
   https://docs.aws.amazon.com/cloudtrail/latest/userguide/cloudtrail-user-guide.html
2. AWS Well‑Architected Framework – Security Pillar – phần “Detective Controls”
   https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/security-pillar.html
3. Amazon Detective – Overview – mô tả mối quan hệ với CloudTrail
   https://docs.aws.amazon.com/detective/latest/adminguide/what-is-detective.html
4. AWS WAF Developer Guide – giới thiệu chức năng lọc web traffic
   https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html
5. Amazon CloudWatch – Metrics & Logs – cách tích hợp với CloudTrail
   https://docs.aws.amazon.com/cloudwatch/index.html

🛠️ Kết luận nhanh gọn

• Câu hỏi: “Muốn xem lại hoạt động người dùng qua API calls → cần dịch vụ ghi lại API.”
• Đáp án: AWS CloudTrail ✅
• Lý do: CloudTrail cung cấp lịch sử chi tiết của mọi API request, hỗ trợ tìm kiếm, lưu trữ lâu dài và tích hợp với các công cụ bảo mật khác.

Hy vọng phần phân tích trên đã giúp bạn nắm rõ lý do lựa chọn CloudTrail và hiểu vì sao các lựa chọn còn lại không phù hợp. 🚀

🔎 Phân tích câu hỏi
Một công ty đang chuyển sang AWS và muốn chạy các workload thử nghiệm trong khoảng 3‑6 tháng. Yêu cầu chính của họ là:

1. Thời gian ngắn – không muốn ký hợp đồng dài hạn.
2. Chi phí hợp lý – muốn trả chỉ cho những gì sử dụng, không cần giảm giá sâu dựa trên cam kết lâu dài.

Do vậy, cần chọn mô hình giá phù hợp với khối lượng công việc ngắn hạn, không ổn định.

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

• On‑Demand cho phép bạn khởi tạo, tạm dừng hoặc xóa các EC2 instance bất cứ lúc nào và trả tiền theo giờ (hoặc giây) sử dụng thực tế.
• Không yêu cầu cam kết thời gian (không có kỳ hạn 1‑3‑5 năm).
• Thích hợp cho workload thử nghiệm, dự án ngắn hạn, hoặc môi trường phát triển nơi nhu cầu tài nguyên có thể thay đổi nhanh.

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

1. Use Savings Plans for a 3‑year term

• Savings Plans (Compute Savings Plans hoặc EC2 Instance Savings Plans) cung cấp giảm giá lên tới 72 % so với On‑Demand, **nhưng bắt buộc cam kết tối thiểu 1 năm (với một số loại 3 năm).
• Với thời gian 3‑6 tháng của dự án, việc ký kế hoạch 3 năm sẽ phải trả tiền cho 36 tháng dù chỉ sử dụng trong 3‑6 tháng → lỗ tài chính.
• Vì vậy không phù hợp.

2. Use Dedicated Hosts

• Dedicated Hosts là máy chủ vật lý riêng được dành riêng cho tài khoản của bạn, giúp đáp ứng các yêu cầu tuân thủ phần cứng (ví dụ: giấy phép phần mềm theo core).
• Đây không phải là mô hình giá tiết kiệm cho workload ngắn hạn; giá của Dedicated Hosts cao hơn và thường đòi hỏi cam kết thời gian (thường là 1 năm).
• Ngoài ra, không cần tính năng cách ly cho một dự án thử nghiệm ngắn hạn.

3. Buy Reserved Instances

• Reserved Instances (RIs) cung cấp giảm giá mạnh (tới 75 %) so với On‑Demand khi đặt trước một instance type trong 1 hoặc 3 năm.
• Đòi hỏi cam kết thời gian dài và kế hoạch tài nguyên ổn định. Nếu dự án chỉ kéo dài 3‑6 tháng, bạn sẽ bị khóa vào một khoản chi phí cố định cho thời gian còn lại và không tận dụng được mức giảm.
• Vì vậy RIs không phù hợp cho workload ngắn hạn.

4. Use On-Demand Instances

• Trả tiền theo giây (từ 2020, EC2 tính phí theo giây) cho mỗi instance đang chạy.
• Không có đặt cọc, cam kết hay phí trả trước.
• Linh hoạt cao: bạn có thể tăng, giảm, hoặc tắt tài nguyên ngay khi nhu cầu thay đổi, rất thích hợp cho thử nghiệm, proof‑of‑concept, hoặc môi trường dev/test.
• Khi dự án kết thúc, bạn đóng tài khoản mà không còn chi phí ẩn.

📌 Kết luận

Với thời gian chạy 3‑6 tháng và tính chất thử nghiệm, On‑Demand Instances là lựa chọn tối ưu nhất vì:

• Không cần cam kết dài hạn.
• Chi phí chỉ trả cho thời gian thực tế sử dụng.
• Linh hoạt trong việc thay đổi quy mô tài nguyên.

📚 Tham khảo (cập nhật tới 2026)

• AWS EC2 Pricing – On‑Demand, Savings Plans, Reserved Instances, Dedicated Hosts. https://aws.amazon.com/ec2/pricing/
• AWS Savings Plans – Overview & FAQs (2024‑2026 cập nhật). https://aws.amazon.com/savingsplans/
• AWS Documentation – Reserved Instances. https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-reserved-instances.html
• AWS Best Practices for Cost Optimization – 2025 Whitepaper. https://d1.awsstatic.com/whitepapers/aws-cost-optimization.pdf

🛠️ Mẹo thực tiễn

• Khi không chắc chắn về thời gian và khối lượng công việc, bắt đầu với On‑Demand, sau đó đánh giá mức sử dụng; nếu workload kéo dài hơn 6‑12 tháng và có xu hướng ổn định, bạn có thể chuyển sang Savings Plans hoặc Reserved Instances để tối ưu chi phí.

💡 Hy vọng phân tích trên giúp bạn nắm rõ lý do tại sao On‑Demand Instances là giải pháp phù hợp nhất cho yêu cầu ngắn hạn của công ty. Chúc bạn thành công trong quá trình migration! 🚀

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

Một công ty đã đăng ký AWS Enterprise Support và chuẩn bị ra mắt phiên bản mới của sản phẩm quan trọng trong vòng 2 tháng. Khi ra mắt, họ dự đoán lượng truy cập vào website (được chạy trên Amazon EC2) sẽ tăng mạnh.

Yêu cầu: đánh giá (assess) độ sẵn sàng mở rộng (readiness to scale) của hạ tầng trước sự kiện. Công ty cần một hành động/dịch vụ mà AWS Enterprise Support cung cấp để giúp họ lên kế hoạch, kiểm tra, và tối ưu hoá kiến trúc, capacity, và các quy trình vận hành trước ngày “tăng tải”.

✅ Đáp án đúng

Use AWS Infrastructure Event Management (IEM) support.

🔎 Tại sao lại là IEM?

• AWS Infrastructure Event Management (cũng được gọi là Event Management trong tài liệu Enterprise Support) là dịch vụ hỗ trợ đặc biệt dành cho khách hàng Enterprise, giúp lên kế hoạch, thiết kế, và kiểm thử khả năng chịu tải cho các sự kiện quan trọng (ra mắt sản phẩm, chiến dịch marketing, Black Friday, …).

• Khi đăng ký IEM, nhóm chuyên gia AWS sẽ:

  1. Đánh giá kiến trúc hiện tại (EC2, Auto Scaling, Load Balancer, RDS, …).
  2. Kiểm tra capacity (đánh giá giới hạn service quotas, dự báo nhu cầu tài nguyên).
  3. Thực hiện các bài load‑test hoặc “game‑day” mô phỏng lưu lượng đỉnh.
  4. Đưa ra khuyến nghị về Auto Scaling policies, caching, mạng, và các biện pháp dự phòng (fail‑over, multi‑AZ).
  5. Cung cấp “run‑book” và hỗ trợ kỹ thuật trực tiếp trong suốt sự kiện.

• Với thời gian còn lại là 2 tháng, IEM cho phép công ty đánh giá toàn diện và điều chỉnh trước khi traffic thực sự bùng nổ, giảm nguy cơ downtime hoặc chi phí không kiểm soát.

📚 Tham khảo:

• AWS Support – Infrastructure Event Management (trang chính thức AWS, cập nhật 2024‑2026).
• AWS Well‑Architected Framework – Performance Efficiency (AWS Whitepaper, 2025).

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

1. Replace the EC2 instances with AWS Lambda functions.

   • Lý do sai:
     • Việc chuyển đổi toàn bộ website từ EC2 sang Lambda không phải là cách “đánh giá” khả năng mở rộng, mà là một thay đổi kiến trúc lớn.
     • Lambda thích hợp cho các workload không trạng thái, thời gian thực ngắn và có giới hạn tài nguyên (max 15 phút execution). Nếu website hiện tại là một ứng dụng monolithic hoặc có yêu cầu stateful, chuyển toàn bộ sang Lambda sẽ gặp hạn chế về thời gian chạy, bộ nhớ, và quản lý môi trường.
     • Hơn nữa, việc thực hiện chuyển đổi trong vòng 2 tháng có thể gây rủi ro cao và không đáp ứng mục tiêu “đánh giá sẵn sàng”.

2. Submit a request on AWS Marketplace to monitor the event.

   • Lý do sai:
     • AWS Marketplace là nơi mua các giải pháp phần mềm bên thứ ba (ví dụ: công cụ monitoring, security). Không có “request” nào trên Marketplace để “monitor the event” như mô tả trong câu hỏi.
     • Để giám sát lưu lượng, công ty có thể sử dụng Amazon CloudWatch, AWS X‑Ray, hoặc các SaaS bên thứ ba, nhưng đây là công cụ giám sát, không phải dịch vụ đánh giá readiness trước sự kiện.
     • Ngoài ra, việc “submit a request” không phải là quy trình chuẩn của Enterprise Support.

3. Review the coverage reports in the AWS Cost Management console.

   • Lý do sai:
     • Các coverage reports (ví dụ: EC2 Instance Coverage, Savings Plans Coverage) chỉ cho biết mức độ sử dụng các loại chi phí tiết kiệm (Reserved Instances, Savings Plans) và không cung cấp thông tin về capacity, performance, hay khả năng mở rộng.
     • Khi chuẩn bị cho một đợt tăng tải, yếu tố quan trọng hơn là capacity planning và performance testing, chứ không phải chi phí (mặc dù chi phí cũng quan trọng, nhưng không phải mục tiêu của câu hỏi).
     • Do vậy, việc xem báo cáo chi phí không đáp ứng yêu cầu “assess readiness to scale”.

🛠️ Tổng hợp các bước thực tế khi sử dụng IEM (để công ty thực hiện)

• Bước 1: Mở ticket với AWS Enterprise Support, yêu cầu Infrastructure Event Management cho sự kiện “product launch”.
• Bước 2: Cung cấp thông tin chi tiết: ngày dự kiến, dự đoán traffic (requests/second), kiến trúc hiện tại (Auto Scaling groups, ELB, RDS, caches).
• Bước 3: AWS sẽ thực hiện capacity review (service quotas, instance types, ENI limits).
• Bước 4: Thực hiện load testing (có thể dùng AWS Distributed Load Testing, hoặc công cụ bên thứ ba) để mô phỏng traffic đỉnh.
• Bước 5: Nhận báo cáo khuyến nghị (tối ưu Auto Scaling policies, tăng limits, cân nhắc sử dụng Amazon CloudFront, Global Accelerator, DynamoDB Accelerator, …).
• Bước 6: Triển khai các thay đổi, chạy lại test, và chuẩn bị “run‑book” cho ngày ra mắt.

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

1. AWS Support – Infrastructure Event Management – https://aws.amazon.com/premiumsupport/enterprise/infrastructure-event-management/
2. AWS Well‑Architected Framework – Performance Efficiency Pillar – https://docs.aws.amazon.com/wellarchitected/latest/performance-efficiency-pillar/what-is-performance-efficiency.html
3. Amazon EC2 Auto Scaling – Best Practices – https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-best-practices.html
4. AWS CloudWatch – Monitoring Large-Scale Events – https://docs.aws.amazon.com/cloudwatch/latest/monitoring/large-scale-events.html

🟢 Kết luận:

• Đáp án đúng là “Use AWS Infrastructure Event Management (IEM) support.”
• Các phương án còn lại không đáp ứng yêu cầu đánh giá sẵn sàng mở rộng và/hoặc không phù hợp với ngữ cảnh Enterprise Support.

Chúc bạn ôn luyện hiệu quả cho kỳ thi AWS Certified DevOps Engineer – Professional! 🚀

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

• Mục tiêu của doanh nghiệp: triển khai nhiều workload trên AWS, mỗi workload thuộc một đơn vị kinh doanh (business unit) khác nhau.
• Yêu cầu chính: phân tách (isolation) và theo dõi chi phí cho từng đơn vị kinh doanh.
• Tiêu chí quan trọng: giảm thiểu overhead vận hành (ít công việc cấu hình, quản lý, duy trì).

Để đáp ứng cả hai yếu tố “phân tách môi trường” và “theo dõi chi phí” một cách tự động, AWS cung cấp AWS Organizations – cho phép tạo nhiều tài khoản con (member accounts) dưới một tổ chức duy nhất, đồng thời tích hợp Consolidated Billing và Cost Allocation Tags. Khi mỗi đơn vị kinh doanh có một tài khoản riêng, tài nguyên được tạo trong tài khoản đó sẽ tự động được gắn vào chi phí của tài khoản, không cần thực hiện bước gán thủ công hay duy trì bảng tính.

Vì vậy, giải pháp có operational overhead thấp nhất là sử dụng AWS Organizations và tạo một tài khoản cho mỗi đơn vị kinh doanh.

✅ Đáp án đúng

- Use AWS Organizations and create one account for each business unit.

Lý do chọn:

1. Isolation tự nhiên: Mỗi tài khoản là một ranh giới an ninh, IAM, networking, quota, và billing riêng – giúp ngăn chặn “rò rỉ” tài nguyên hoặc quyền truy cập giữa các đơn vị.
2. Theo dõi chi phí chính xác: Consolidated Billing tự động tổng hợp chi phí của toàn bộ tổ chức, trong khi mỗi tài khoản hiển thị chi phí riêng biệt. Không cần gán tag hoặc thực hiện tính toán thủ công.
3. Quản lý ít công sức: Tạo tài khoản mới chỉ một lần (hoặc thông qua AWS Control Tower – còn được cải tiến trong 2025/2026), sau đó áp dụng Service Control Policies (SCPs) để chuẩn hoá quyền.
4. Mở rộng dễ dàng: Thêm đơn vị kinh doanh mới chỉ cần tạo tài khoản mới trong tổ chức, không ảnh hưởng đến các workload hiện có.

❌ Giải thích các lựa chọn sai

• Use a spreadsheet to control the owners and cost of each resource.

  • ❌ Vấn đề: Spreadsheet là công cụ thủ công, không tự động cập nhật chi phí thực tế từ AWS. Khi tài nguyên thay đổi (tạo, xóa, thay đổi kích thước) chi phí sẽ không được cập nhật kịp thời → high operational overhead.
  • ❌ Không đáp ứng yêu cầu isolation: Tất cả tài nguyên vẫn nằm trong cùng một tài khoản, gây khó khăn trong việc áp dụng các chính sách bảo mật và quota riêng cho từng đơn vị.

• Use an Amazon DynamoDB table to record costs for each business unit.

  • ❌ Vấn đề: DynamoDB chỉ là một kho lưu trữ dữ liệu; bạn vẫn phải thu thập, xử lý và ghi nhận chi phí từ các báo cáo (Cost Explorer, CUR) vào bảng này. Đây là một quy trình ETL phức tạp, tốn thời gian và dễ lỗi.
  • ❌ Không giải quyết việc phân tách môi trường: Các workload vẫn chạy trong cùng một tài khoản, nên việc “phân tách” vẫn chưa được thực hiện.

• Use the AWS Billing console to assign owners to resources and track costs.

  • ❌ AWS Billing console không cho phép gán “owner” trực tiếp vào tài nguyên. Bạn chỉ có thể gắn tag (cost allocation tags) và sau đó dùng Cost Explorer để lọc, nhưng việc gán tag phải thực hiện trên mỗi tài nguyên – đòi hỏi thao tác thủ công hoặc automation.
  • ❌ Không tách biệt môi trường: Tất cả tài nguyên vẫn thuộc chung một tài khoản, nên việc áp dụng các policy bảo mật hoặc quota cho từng đơn vị kinh doanh vẫn phải thực hiện bằng cách khác (ví dụ: IAM policies) – làm tăng độ phức tạp.

🛠️ Các công cụ & tính năng liên quan (cập nhật tới 2026)

• AWS Organizations (v3 – ra mắt 2024, cập nhật liên tục): Tạo, quản lý và áp dụng Service Control Policies (SCPs), Tag Policies, và IAM Identity Center cho toàn tổ chức.
• AWS Control Tower (phiên bản 2025.2): Cung cấp “landing zone” tự động, giúp tạo tài khoản mới với guardrails đã được cấu hình sẵn – giảm đáng kể overhead khi triển khai nhiều tài khoản.
• Consolidated Billing + Cost Explorer + Cost and Usage Report (CUR): Thu thập chi phí chi tiết cho từng tài khoản, hỗ trợ cost allocation tags và resource IDs để phân tích sâu.
• AWS Identity Center (trước là AWS SSO): Quản lý người dùng và quyền truy cập vào từng tài khoản thành viên – giúp thực thi least‑privilege cho mỗi đơn vị kinh doanh.

📚 Tham khảo

1. AWS Organizations Documentation – https://docs.aws.amazon.com/organizations/latest/userguide/what-is-organizations.html (phiên bản cập nhật 2026)
2. AWS Control Tower User Guide – https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html
3. AWS Billing and Cost Management – Consolidated Billing – https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/consolidated-billing.html
4. AWS Cost Allocation Tags – https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html

🏁 Kết luận

Giải pháp AWS Organizations + một tài khoản cho mỗi business unit đáp ứng đầy đủ yêu cầu phân tách môi trường và theo dõi chi phí đồng thời giảm tối đa công việc vận hành. Các lựa chọn khác đều đòi hỏi thao tác thủ công, không cung cấp sự tách biệt tài khoản, hoặc cần xây dựng quy trình phức tạp để ghi nhận chi phí – do đó không phù hợp với tiêu chí “least operational overhead”.

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

Câu hỏi yêu cầu một dịch vụ cơ sở dữ liệu dạng time‑series (cơ sở dữ liệu lưu trữ dữ liệu theo thời gian) có khả năng đối phó với “trillions of events each day” – tức là khối lượng dữ liệu cực lớn, cần khả năng tự‑mở rộng, lưu trữ lâu dài và cung cấp các công cụ truy vấn/ phân tích thời gian thực.

Trong danh mục dịch vụ AWS, chỉ có Amazon Timestream được thiết kế đặc biệt cho mục đích này:

• ✅ Serverless – không cần quản lý cluster, tự động mở rộng theo tải.
• ✅ Tối ưu cho time‑series – lưu trữ dữ liệu “hot” (gần thời gian hiện tại) và “cold” (lưu trữ lâu dài) trên các tier riêng, giảm chi phí.
• ✅ Hỗ trợ ingestion hàng nghìn‑triệu điểm dữ liệu mỗi giây và có các hàm tích hợp (AVG, MIN, MAX, TIME_INTERVAL, etc.) cho việc phân tích nhanh.
• ✅ Tích hợp sẵn với Amazon Kinesis Data Firehose, IoT Core, và các SDK để đưa dữ liệu vào một cách liên tục.

Vì vậy đáp án đúng là Amazon Timestream.

✅ Đáp án đúng

Amazon Timestream

• Được ra mắt lần đầu vào năm 2018 và liên tục được cải tiến tới năm 2026 (hỗ trợ Query Engine v2, auto‑scaling read/write capacity, cross‑region replication, v.v.).
• Thiết kế để xử lý trillions sự kiện mỗi ngày, phù hợp cho IoT, monitoring, application telemetry, và analytics.
• Cung cấp SQL‑like query language (Timestream Query) và tích hợp với Amazon QuickSight cho visualisation.

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

• Amazon Neptune
  Neptune là đồ thị database (hỗ trợ các mô hình Gremlin và openCypher). Nó không được tối ưu cho lưu trữ và truy vấn dữ liệu thời gian, mà dùng để mô hình quan hệ phức tạp như mạng xã hội, recommendation engines, fraud detection. Do đó không đáp ứng yêu cầu time‑series và không được thiết kế để xử lý “trillions of events” theo kiểu đo lường thời gian.

• Amazon Forecast
  Forecast là dịch vụ dự báo máy học (Machine Learning) dựa trên dữ liệu thời gian, nhưng không phải là cơ sở dữ liệu. Nó chỉ tiêu thụ dữ liệu đầu vào (có thể lưu trữ trên S3, Redshift, hoặc Timestream) và tạo ra mô hình dự báo. Vì vậy không phù hợp với yêu cầu “cơ sở dữ liệu time‑series”.

• Amazon DocumentDB (with MongoDB compatibility)
  DocumentDB là cơ sở dữ liệu dạng tài liệu (document‑oriented) tương thích với API MongoDB. Nó thích hợp cho ứng dụng lưu trữ JSON‑like data, nhưng không tối ưu cho truy vấn thời gian series, không có tính năng tự động tiering dữ liệu hot/cold và không được thiết kế để xử lý hàng nghìn‑tỷ điểm dữ liệu mỗi ngày. Do đó không phù hợp.

🧩 Tóm tắt nhanh

• Yêu cầu: Time‑series DB, khả năng mở rộng lên “trillions of events per day”.
• Giải pháp AWS: Amazon Timestream – dịch vụ serverless, tối ưu cho time‑series, tự động tiering, tích hợp sẵn với các nguồn dữ liệu streaming.
• Các lựa chọn khác:
  • Neptune → đồ thị DB, không phải time‑series.
  • Forecast → dịch vụ dự báo ML, không phải DB.
  • DocumentDB → DB dạng tài liệu, không tối ưu cho time‑series.

📘 Tham khảo (cập nhật tới 2026)

1. Amazon Timestream – Developer Guide (AWS Documentation, phiên bản 2026).
   https://docs.aws.amazon.com/timestream/latest/developerguide/
2. Amazon Timestream – Service Overview (AWS Product Page, cập nhật 2026).
   https://aws.amazon.com/timestream/
3. AWS Well‑Architected Framework – Data Management Pillar (2025).
   https://docs.aws.amazon.com/wellarchitected/latest/data-management-pillar/overview.html

💡 Mẹo thi: Khi gặp câu hỏi “time‑series database”, hãy nhớ rằng AWS chỉ có Amazon Timestream (đã được cải tiến tới phiên bản serverless v2 trong 2026) – các dịch vụ khác (Neptune, DynamoDB, DocumentDB, etc.) không đáp ứng yêu cầu thời gian thực và tiering dữ liệu. ✅

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

Câu hỏi hỏi: “Which option is a shared control between AWS and the customer, according to the AWS shared responsibility model?”
Trong mô hình Shared Responsibility của AWS, trách nhiệm bảo mật được chia thành hai miền:

1. Security of the cloud – AWS chịu trách nhiệm bảo vệ hạ tầng vật lý, môi trường, mạng lưới và các thành phần nền tảng.
2. Security in the cloud – Khách hàng chịu trách nhiệm bảo mật dữ liệu, hệ điều hành, ứng dụng, quyền truy cập, cấu hình, v.v.

Một số control (biện pháp kiểm soát) nằm ở giữa hai bên – AWS cung cấp công cụ, dịch vụ; khách hàng phải cấu hình, vận hành chúng đúng cách. Đó là các shared controls.

✅ Đáp án đúng: Configuration management

Tại sao lại là đáp án đúng?

• AWS cung cấp các dịch vụ và công cụ giúp quản lý cấu hình (ví dụ: AWS Config, AWS Systems Manager, CloudFormation, OpsWorks).
• Customer phải định nghĩa, triển khai và duy trì các cấu hình bảo mật cho tài nguyên của mình (ví dụ: quy tắc Config, policy cho SSM, template CloudFormation).

Do đó, Configuration management là một shared control – cả AWS và khách hàng đều có vai trò trong việc đảm bảo cấu hình an toàn.

Tham khảo: AWS Documentation – “AWS Shared Responsibility Model” (cập nhật đến 2024‑2025) – phần “Configuration and Change Management” mô tả đây là trách nhiệm chung.

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

1. Physical and environmental controls

   • AWS chịu toàn bộ trách nhiệm: bảo trì trung tâm dữ liệu, hệ thống làm mát, điện dự phòng, kiểm soát truy cập vật lý, v.v.
   • Customer không có quyền truy cập hay quản lý các biện pháp này.
   • 👉 Vì vậy đây là control chỉ thuộc AWS, không phải shared.

2. Data integrity authentication

   • Đây là trách nhiệm của khách hàng: khách hàng phải triển khai các cơ chế xác thực, checksum, chữ ký số để bảo vệ tính toàn vẹn dữ liệu của mình.
   • AWS chỉ cung cấp dịch vụ lưu trữ, không can thiệp vào cách khách hàng xác thực dữ liệu.
   • 👉 Do đó là control thuộc Customer, không phải shared.

3. Identity and access management

   • Mặc dù AWS cung cấp dịch vụ IAM, quyền quản lý danh tính và quyền truy cập hoàn toàn do khách hàng quyết định (tạo user, policy, role, MFA, v.v.).
   • AWS chỉ cung cấp nền tảng, không quyết định quyền cụ thể.
   • 👉 Vì thế IAM là trách nhiệm khách hàng, không phải shared.

🧩 Tổng kết nhanh

• Shared control: Configuration management ✅
• AWS‑only control: Physical and environmental controls ❌
• Customer‑only controls: Data integrity authentication, Identity and access management ❌

📚 Tham khảo tài liệu

• AWS Documentation – “Shared Responsibility Model” (phiên bản 2024‑2025).
• AWS Well‑Architected Framework – Security Pillar, phần “Shared controls”.
• AWS Config User Guide, mô tả vai trò chung của AWS và khách hàng trong việc quản lý cấu hình.

Hy vọng giải thích trên giúp bạn nắm rõ tại sao Configuration management là biện pháp kiểm soát được chia sẻ giữa AWS và khách hàng trong mô hình Shared Responsibility. 🚀

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

Câu hỏi mô tả một công ty không sử dụng hết công suất EC2 hiện có để chạy các workload không trạng thái (stateless) và mong muốn tối ưu chi phí EC2.
Yêu cầu quan trọng:

1. Không cần sử dụng toàn bộ tài nguyên hiện có → công ty muốn “giảm thiểu” việc trả tiền cho tài nguyên không dùng.
2. Workload là stateless → có thể dừng, khởi động lại, hoặc di chuyển sang máy khác mà không mất dữ liệu trạng thái. Điều này cho phép chấp nhận gián đoạn (interruption) mà không ảnh hưởng tới tính toàn vẹn của ứng dụng.

Do đó, chúng ta cần một loại EC2 giảm giá mạnh, tận dụng sức chứa dư thừa và có khả năng chấm dứt khi AWS cần lại tài nguyên – chính xác là Spot Instances.

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

• Giá rẻ nhất: Spot Instances được bán dựa trên giá thị trường của năng lực dư thừa trong các vùng (availability zones). Từ khi ra mắt, mức giảm giá thường từ 70 % đến 90 % so với On‑Demand. (AWS “EC2 Spot Pricing” tài liệu cập nhật 2024‑2026)
• Phù hợp với workload không trạng thái: Vì Spot có thể bị interrupted khi giá Spot vượt ngưỡng hoặc khi AWS cần tài nguyên, nên các ứng dụng stateless (ví dụ: batch jobs, CI/CD runners, web servers có auto‑scale) có thể được tự động chuyển sang instance khác mà không mất dữ liệu.
• Công cụ hỗ trợ: Spot Fleet, EC2 Auto Scaling groups và Capacity‑Optimized allocation strategy giúp tự động lựa chọn các Spot pool có khả năng sẵn sàng cao nhất, giảm thiểu việc bị dừng.
• Không cần cam kết dài hạn: Không giống Reserved Instances hay Savings Plans, Spot không yêu cầu ký hợp đồng 1‑3 năm; bạn chỉ trả cho thời gian thực tế sử dụng.

Kết luận: Spot Instances đáp ứng đúng cả hai tiêu chí “tối ưu chi phí” và “có thể chấp nhận gián đoạn” cho workload không trạng thái.

❌ Các lựa chọn sai và lý do

1. Dedicated Instances

• Mô tả: EC2 instances chạy trên hạ tầng vật lý được tách riêng cho tài khoản của bạn (không chia sẻ với khách hàng khác).
• Vấn đề:
  • Chi phí cao: Được tính phí Premium (thường 10‑20 % so với On‑Demand) vì yêu cầu cách ly vật lý.
  • Không giải quyết vấn đề tài nguyên dư thừa: Dedicated Instances không “sử dụng” tài nguyên dư thừa mà chỉ đảm bảo cách ly; không mang lại giảm giá.
  • Không cần thiết cho workload không trạng thái: Nếu mục tiêu là giảm chi phí, Dedicated Instances ngược lại làm tăng chi phí.

2. Reserved Instances

• Mô tả: Cam kết mua một instance với định mức cố định (1 hoặc 3 năm), nhận mức giảm giá so với On‑Demand (tối đa ~75 %).
• Vấn đề:
  • Cam kết lâu dài: Cần dự báo chính xác nhu cầu tài nguyên; nếu công ty không sử dụng hết capacity, bạn vẫn phải trả tiền cho toàn bộ capacity đã đặt.
  • Không thích hợp cho tài nguyên dư thừa: Reserved Instances không tự động “điều chỉnh” theo mức độ sử dụng; chúng không tận dụng capacity spare của AWS.
  • Không phù hợp với workload có thể bị gián đoạn: Reserved Instances không cung cấp bất kỳ cơ chế nào để giảm chi phí khi có tài nguyên dư thừa.

3. On‑Demand Instances

• Mô tả: Trả tiền theo giờ/giây cho mỗi instance, không cam kết, không giảm giá.
• Vấn đề:
  • Giá cao nhất trong các mô hình tính phí (trừ Dedicated).
  • Không tối ưu chi phí cho công ty không sử dụng hết capacity; bạn vẫn phải trả đầy đủ cho mỗi instance đang chạy, dù không có tải.
  • Không tận dụng capacity spare: On‑Demand không khai thác “điểm mạnh” của AWS là khả năng cung cấp tài nguyên dư thừa với giá thấp hơn.

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

• AWS Documentation – Amazon EC2 Spot Instances (2024‑2026): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-spot-instances.html
• AWS Well‑Architected Framework – Cost Optimization Pillar (2025): Giải thích cách chọn Spot cho workload không trạng thái.
• AWS Compute Optimizer & Cost Explorer (2025): Công cụ giúp phát hiện tài nguyên dư thừa và đề xuất chuyển sang Spot.
• AWS Blog – “New Spot Instance features in 2025”: Giới thiệu chiến lược Capacity‑Optimized và Spot Blocks, tăng độ ổn định cho workload có tính chất không trạng thái.

🧩 Tóm tắt nhanh

• Công ty có tài nguyên EC2 dư thừa → muốn giảm chi phí.
• Workload không trạng thái → có thể chấp nhận interruption.
• Spot Instances: Giá rẻ, tận dụng capacity spare, phù hợp cho workload có thể bị dừng và khởi động lại → đáp án đúng.
• Dedicated, Reserved, On‑Demand: Không đáp ứng yêu cầu về tối ưu chi phí và/hoặc không phù hợp với tính chất không trạng thái → đều sai.