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

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

Which AWS tool or feature acts as a VPC firewall at the subnet level?

Câu hỏi yêu cầu xác định công cụ/feature của AWS chịu trách nhiệm “đóng vai trò như tường lửa của VPC ở mức subnet”.

• “VPC firewall” ở đây không phải là AWS Firewall Manager hay AWS Network Firewall (đều hoạt động ở mức VPC hoặc toàn cầu).
• “At the subnet level” nghĩa là quy tắc được áp dụng cho tất cả các ENI (Elastic Network Interface) nằm trong một subnet, không phụ thuộc vào từng instance.

Vì vậy, chúng ta cần tìm công cụ có tính chất stateless, áp dụng cho đầu vào và đầu ra của subnet.

✅ Đáp án đúng

🔹 [ĐÚNG] Network ACL

Lý do:

• Network ACL (Access Control List) là một bộ quy tắc stateless được gắn vào một subnet trong VPC.
• Các rule cho phép hoặc chặn traffic đối với cả inbound và outbound của subnet, bất kể instance nào trong subnet.
• Khi một packet đi qua subnet, NACL sẽ được kiểm tra trước khi packet tới instance (đối với inbound) hoặc sau khi rời instance (đối với outbound).
• Điều này hoàn toàn phù hợp với mô tả “VPC firewall at the subnet level”.

🔗 Tài liệu tham khảo (2026):

• AWS Documentation – Amazon VPC Network ACLs (https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)
• AWS Well‑Architected Framework – Security Pillar (cập nhật 2025)

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

1. 🔹 [SAI] Security group

   • Mô tả: Security group là firewall ở mức instance (ENI), không phải ở mức subnet.
   • Tính chất: Stateful – các rule inbound và outbound được tự động liên kết.
   • Vì sao sai: Vì security group chỉ áp dụng cho các ENI được gán, không ảnh hưởng tới toàn bộ subnet. Do đó không đáp ứng yêu cầu “at the subnet level”.

2. 🔹 [SAI] Traffic Mirroring

   • Mô tả: Traffic Mirroring cho phép sao chép lưu lượng mạng từ một ENI nguồn tới một ENI đích để phân tích (ví dụ: IDS/IPS).
   • Tính chất: Không phải là công cụ firewall, mà là công cụ giám sát.
   • Vì sao sai: Nó không thực hiện việc cho phép hoặc chặn lưu lượng; chỉ sao chép lưu lượng để phân tích.

3. 🔹 [SAI] Internet gateway

   • Mô tả: Internet gateway (IGW) là cổng kết nối VPC với internet. Nó cung cấp định tuyến (route) và NAT cho các subnet public.
   • Tính chất: Không phải là firewall; không có rule cho phép/chặn traffic.
   • Vì sao sai: IGW không thực hiện kiểm soát truy cập mà chỉ cho phép lưu lượng ra/ vào VPC theo bảng route.

🧩 Tổng kết nhanh

• Network ACL → ✅ Firewall ở mức subnet, stateless, áp dụng cho toàn bộ lưu lượng inbound & outbound của subnet.
• Security group → ❌ Firewall ở mức instance, stateful.
• Traffic Mirroring → ❌ Công cụ giám sát, không chặn.
• Internet gateway → ❌ Cổng kết nối internet, không có chức năng firewall.

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

• AWS Blog – “New features in Amazon VPC – 2025 update” (giới thiệu cải tiến cho NACLs như rule‑priority và tagging).
• AWS re:Invent 2024 Session “Deep dive into VPC security – Network ACLs vs Security Groups” (link: https://reinvent.awsevents.com/2024/security).
• AWS Well‑Architected Tool – Security Pillar version 2.0 (cập nhật 2025, khuyến nghị sử dụng NACL cho kiểm soát subnet‑level).

Hy vọng phân tích trên đã giúp bạn nắm rõ lý do tại sao Network ACL là đáp án đúng và hiểu được sự khác nhau giữa các tùy chọn được đưa ra. Chúc bạn ôn tập hiệu quả! 🚀

📚 Phân tích câu hỏi
Công ty đang chạy một ứng dụng batch trên AWS. Ứng dụng fault‑tolerant (có khả năng chịu lỗi) và có thể chịu các gián đoạn – nghĩa là nếu một tài nguyên đột ngột bị dừng, ứng dụng vẫn có thể tiếp tục hoặc khởi động lại mà không gây lỗi nghiêm trọng. Mục tiêu của công ty là giảm chi phí tối đa cho việc chạy ứng dụng này.

Vì vậy, chúng ta cần một hình thức cung cấp tài nguyên tính toán (CPU, memory) có giá rẻ hơn so với mô hình On‑Demand, đồng thời cho phép các interruption (được chấm dứt bất ngờ) mà không làm gián đoạn hoạt động quan trọng. Đây là mô tả điển hình của Amazon EC2 Spot Instances.

✅ Đáp án đúng

✅ Amazon EC2 Spot Instances

• Spot Instances cho phép mua tài nguyên EC2 với giá chiết khấu lên tới 90 % so với On‑Demand.
• Chúng có thể bị dừng bất cứ lúc nào khi giá spot vượt mức giá bid hoặc khi AWS cần thu hồi tài nguyên.
• Do ứng dụng đã được thiết kế “fault‑tolerant” và “can handle interruptions”, việc chấp nhận các interruption này là không vấn đề và giúp cắt giảm chi phí đáng kể.
• AWS cung cấp các tính năng hỗ trợ tự động re‑balancing và capacity‑optimized allocation strategy (2026) để giảm thiểu tần suất interruption và tối ưu hiệu suất.

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

• ❌ Amazon Macie

  • Giải thích: Amazon Macie là dịch vụ phát hiện và bảo vệ dữ liệu nhạy cảm (PII, dữ liệu tài chính) dựa trên máy học. Nó không cung cấp tài nguyên tính toán để chạy batch jobs, do đó không liên quan tới việc tối ưu chi phí chạy ứng dụng.

• ❌ Amazon Neptune

  • Giải thích: Amazon Neptune là dịch vụ quản lý cơ sở dữ liệu đồ thị (graph DB) được tối ưu cho các truy vấn quan hệ phức tạp. Nó không phải là một loại instance tính toán và không giúp giảm chi phí cho workload batch.

• ❌ Amazon EC2 On‑Demand Instances

  • Giải thích: On‑Demand Instances cung cấp giá cố định và không có interruption. Mặc dù phù hợp cho các workload cần độ ổn định tuyệt đối, nhưng chi phí cao hơn rất nhiều so với Spot Instances. Vì câu hỏi nhấn mạnh “tối ưu chi phí” và “có thể chịu interruption”, On‑Demand không đáp ứng được yêu cầu.

🛠️ Lời khuyên thực tế cho kiến trúc batch fault‑tolerant

1. Sử dụng Spot Fleet / EC2 Auto Scaling với capacity‑optimized allocation strategy để tự động lựa chọn các AZ/Instance types có khả năng cung cấp Spot ổn định nhất.
2. Kết hợp Spot Instances với On‑Demand hoặc Savings Plans (mix) để có mức dự phòng khi Spot bị thu hồi.
3. Sử dụng AWS Batch – dịch vụ quản lý job queue có hỗ trợ tự động chạy job trên Spot Instances.
4. Áp dụng checkpointing trong code batch (ví dụ: lưu trạng thái vào S3, DynamoDB) để job có thể tiếp tục sau khi Spot bị dừng.
5. Giám sát bằng Amazon CloudWatch để theo dõi tỷ lệ interruption và tự động chuyển sang On‑Demand nếu cần.

📘 Tham khảo (2026)

• Amazon EC2 Spot Instances – https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/spot-instances.html
• EC2 Spot Instance pricing and allocation strategies – https://aws.amazon.com/ec2/spot/
• AWS Batch – Run batch computing workloads on Spot Instances – https://docs.aws.amazon.com/batch/latest/userguide/what-is-batch.html
• Best practices for using Spot Instances – AWS Well‑Architected Framework, Cost Optimization Pillar (2026 edition).

Kết luận: Với một ứng dụng batch có khả năng chịu interruption, Amazon EC2 Spot Instances là lựa chọn tối ưu nhất để giảm chi phí mà vẫn duy trì tính sẵn sàng của workload. 🚀

📖 Giải thích nội dung câu hỏi
Câu hỏi hỏi: “Which AWS service can be used to send alerts when a specific Amazon CloudWatch alarm is invoked?”
Nói một cách đơn giản: Khi một alarm của Amazon CloudWatch (ví dụ: CPU utilization vượt quá ngưỡng) được kích hoạt, chúng ta muốn tự động gửi thông báo (alert) tới người dùng hoặc hệ thống khác. AWS cung cấp một số dịch vụ có khả năng nhận và truyền tải thông báo, nhưng chỉ có một dịch vụ được thiết kế để phối hợp trực tiếp với CloudWatch Alarm và thực hiện việc gửi alert (email, SMS, HTTP endpoint, …) ngay lập tức.

✅ Đáp án đúng

🔹 Amazon Simple Notification Service (Amazon SNS)

Lý do chọn:

• SNS là dịch vụ “pub/sub” (publish/subscribe) của AWS, cho phép bạn tạo topic và đăng ký (subscribe) các endpoint như email, SMS, HTTP/HTTPS, Lambda, SQS, …
• Khi một CloudWatch alarm chuyển sang trạng thái ALARM, bạn có thể cấu hình Alarm actions để publish một tin nhắn tới một SNS topic.
• SNS chịu trách nhiệm gửi tin nhắn tới tất cả các subscription, vì vậy bạn sẽ nhận được alert ngay lập tức.
• Đây là cách AWS khuyến cáo trong tài liệu chính thức và vẫn là phương án chuẩn đến tháng 4/2026.

Tham khảo:

• Amazon CloudWatch User Guide – Using CloudWatch Alarms (phiên bản 2026)
• Amazon SNS Developer Guide – Using SNS with CloudWatch Alarms

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

❌ AWS CloudTrail

• Chức năng thực tế: CloudTrail ghi lại các API call và các sự kiện quản trị trong tài khoản AWS (ví dụ: tạo, sửa, xóa resources).
• Tại sao không phù hợp: CloudTrail không có khả năng gửi thông báo theo thời gian thực khi một alarm được kích hoạt. Nó chỉ lưu trữ log và có thể đưa vào CloudWatch Logs, nhưng việc “send alerts” không phải là mục đích của CloudTrail.

❌ Amazon Simple Queue Service (Amazon SQS)

• Chức năng thực tế: SQS là dịch vụ hàng đợi tin nhắn (message queue) giúp lưu trữ và truyền tải tin nhắn một cách asynchronous giữa các thành phần.
• Tại sao không phù hợp: Mặc dù CloudWatch alarm có thể gửi một hành động tới SQS (bằng cách cấu hình Alarm actions), SQS chỉ lưu trữ tin nhắn, không thực hiện việc gửi alert tới người dùng cuối (email, SMS, …). Bạn cần một dịch vụ khác (như SNS hoặc Lambda) để thực sự “notify”.

❌ Amazon EventBridge

• Chức năng thực tế: EventBridge (trước đây là CloudWatch Events) là dịch vụ event bus cho phép bạn lắng nghe và định tuyến các sự kiện từ AWS services, SaaS và custom applications tới các target như Lambda, Step Functions, SNS, SQS, …
• Tại sao không phải đáp án tốt nhất: EventBridge có thể nhận sự kiện khi một CloudWatch alarm thay đổi trạng thái và chuyển tiếp tới một target (ví dụ: SNS). Tuy nhiên, câu hỏi chỉ hỏi “service can be used to send alerts”. Trong trường hợp này, SNS là dịch vụ thực tế thực hiện việc gửi alert; EventBridge chỉ là trình trung gian. Do vậy, đáp án SNS vẫn là lựa chọn chính xác, còn EventBridge là một cách tiếp cận phụ trợ nhưng không phải là dịch vụ “gửi alert” trực tiếp.

🛠️ Cách cấu hình nhanh (2026)

1. Tạo SNS topic

   aws sns create-topic --name MyAlarmTopic
   

2. Đăng ký subscription (email ví dụ)

   aws sns subscribe --topic-arn arn:aws:sns:region:account-id:MyAlarmTopic \
                     --protocol email --notification-endpoint user@example.com
   

3. Tạo CloudWatch alarm và gán hành động SNS:

   aws cloudwatch put-metric-alarm \
       --alarm-name HighCPUUtilization \
       --metric-name CPUUtilization \
       --namespace AWS/EC2 \
       --statistic Average \
       --period 300 \
       --threshold 80 \
       --comparison-operator GreaterThanThreshold \
       --evaluation-periods 2 \
       --alarm-actions arn:aws:sns:region:account-id:MyAlarmTopic
   

4. Khi alarm chuyển sang trạng thái ALARM, SNS sẽ gửi email (hoặc các kênh khác) tới người đăng ký.

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

• Amazon CloudWatch User Guide – Alarms: https://docs.aws.amazon.com/cloudwatch/latest/monitoring/AlarmThatSendsEmail.html
• Amazon SNS Developer Guide – Using SNS with CloudWatch: https://docs.aws.amazon.com/sns/latest/dg/sns-cloudwatch.html
• Amazon EventBridge User Guide – Event Sources and Targets: https://docs.aws.amazon.com/eventbridge/latest/userguide/

🔚 Tóm tắt

• Đáp án đúng: Amazon Simple Notification Service (Amazon SNS) – dịch vụ chuyên gửi alert tới nhiều kênh khác nhau khi CloudWatch alarm được kích hoạt.
• Các lựa chọn còn lại (CloudTrail, SQS, EventBridge) không thực hiện chức năng “gửi alert” trực tiếp, vì vậy chúng là sai trong bối cảnh câu hỏi.

Hy vọng phân tích này giúp bạn nắm rõ lý do lựa chọn và cách áp dụng trong thực tế! 🚀

🧩 Câu hỏi:

A cloud practitioner wants to use a highly available and scalable DNS service for its AWS workload. Which AWS service will meet this requirement?

🔍 Giải thích nội dung câu hỏi:
Câu hỏi đang hỏi về dịch vụ DNS (Domain Name System) của AWS mà cung cấp độ sẵn sàng cao (highly available) và khả năng mở rộng (scalable) để phục vụ các workload trên AWS. DNS chịu trách nhiệm ánh xạ tên miền (ví dụ: www.example.com) sang địa chỉ IP của tài nguyên (EC2, ALB, CloudFront, …). Do DNS là một thành phần quan trọng cho việc truy cập và cân bằng tải, dịch vụ cần:

• Được triển khai trên nhiều vùng (multi‑AZ) để chịu lỗi khu vực.
• Tự động mở rộng để đáp ứng lưu lượng truy vấn lớn mà không cần quản lý hạ tầng.
• Hỗ trợ các tính năng nâng cao như health checks, routing policies (latency‑based, geolocation, weighted, fail‑over, …).

AWS cung cấp một dịch vụ chuyên dụng đáp ứng đầy đủ các yêu cầu trên – Amazon Route 53.

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

Lý do lựa chọn:

• High availability: Route 53 được triển khai trên toàn mạng lưới Edge Locations của AWS và có kiến trúc multi‑region, cho phép dịch vụ luôn sẵn sàng ngay cả khi một AZ hoặc một khu vực bị mất.
• Scalability: Hệ thống DNS của Route 53 tự động mở rộng để xử lý hàng tỷ truy vấn mỗi ngày mà không cần cấu hình thêm.
• Features: Hỗ trợ health checks, routing policies (latency, geolocation, weighted, fail‑over, multi‑value answer), DNSSEC, domain registration, và integration sâu với các dịch vụ AWS khác (ELB, CloudFront, S3, …).
• Managed service: Người dùng không phải lo về vận hành máy chủ DNS, cập nhật phần mềm, hay bảo trì.

Nguồn tham khảo:

• AWS Documentation – Amazon Route 53 – How it works (phiên bản 2026).
• AWS Well‑Architected Framework – Reliability Pillar – DNS considerations (2026).

❌ Phân tích các phương án sai

1. Amazon Lightsail

• Giải thích: Lightsail là một dịch vụ đơn giản hoá việc triển khai các máy ảo, cơ sở dữ liệu và các ứng dụng web, cung cấp gói giá cố định. Mặc dù Lightsail có khả năng đăng ký tên miền và tạo bản ghi DNS thông qua Lightsail DNS, nhưng dịch vụ này không được thiết kế để đáp ứng yêu cầu “highly available và scalable” ở cấp độ toàn cầu như Route 53.
• Điểm yếu:
  • Không cung cấp routing policies nâng cao, chỉ hỗ trợ các bản ghi DNS cơ bản.
  • Kiến trúc không đa vùng (multi‑AZ) như Route 53, vì Lightsail chủ yếu hướng tới các môi trường nhỏ, đơn giản.
  • Không hỗ trợ DNSSEC hay health checks tích hợp.
• Kết luận: Không phù hợp cho workload yêu cầu độ sẵn sàng và khả năng mở rộng mạnh mẽ.

2. AWS Amplify Hosting

• Giải thích: Amplify Hosting là một dịch vụ CI/CD và hosting tĩnh dành cho các ứng dụng web front‑end (React, Angular, Vue, …). Nó cung cấp công cụ triển khai, các môi trường staging/production, và tự động tạo CloudFront distribution kèm Domain Management (thông qua Amplify Console).
• Điểm yếu:
  • Amplify chỉ tự động tạo bản ghi CNAME trỏ tới CloudFront; nó không phải là dịch vụ DNS độc lập.
  • Không cung cấp các tính năng DNS chuyên sâu như routing policies, health checks, DNSSEC, hoặc độ sẵn sàng đa vùng.
  • Nếu muốn DNS mạnh mẽ, người dùng vẫn phải sử dụng Route 53 (hoặc DNS của bên thứ ba).
• Kết luận: Amplify Hosting không phải là dịch vụ DNS, vì vậy không đáp ứng yêu cầu.

3. Amazon S3

• Giải thích: S3 là dịch vụ object storage dùng để lưu trữ và phục vụ dữ liệu tĩnh (website hosting, backup, v.v.). Khi bật tính năng “Static website hosting”, S3 trả về endpoint dạng bucket-name.s3-website-<region>.amazonaws.com.
• Điểm yếu:
  • S3 không cung cấp dịch vụ DNS; nó chỉ cung cấp endpoint và có thể được ánh xạ bằng các bản ghi DNS trên Route 53 hoặc các DNS bên thứ ba.
  • Không có khả năng health checks, routing policies, hay DNSSEC.
  • Không được thiết kế để quản lý tên miền hoặc cung cấp độ sẵn sàng DNS.
• Kết luận: S3 là dịch vụ lưu trữ, không phải DNS, do đó không thỏa mãn yêu cầu.

🛠️ Tổng kết

• Đúng: Amazon Route 53 – đáp ứng mọi yêu cầu “highly available” và “scalable” cho DNS, đồng thời cung cấp tính năng nâng cao cần thiết cho các workload hiện đại trên AWS.
• Sai: Amazon Lightsail, AWS Amplify Hosting, Amazon S3 – không phải dịch vụ DNS chuyên dụng, hoặc thiếu các tính năng quan trọng (độ sẵn sàng đa vùng, khả năng mở rộng tự động, routing policies, DNSSEC, health checks).

💡 Mẹo thi: Khi câu hỏi đề cập đến “highly available and scalable DNS service”, luôn suy nghĩ đến Route 53 – dịch vụ DNS được quản lý toàn diện của AWS. Các dịch vụ khác chỉ cung cấp một phần chức năng DNS (Lightsail) hoặc không liên quan (Amplify, S3).

📘 Tham khảo thêm:

1. Amazon Route 53 Developer Guide – “Getting started with Amazon Route 53”, phiên bản cập nhật 2026.
2. AWS Well‑Architected Framework – Reliability Pillar, mục “Domain Name System (DNS) considerations”.
3. AWS Blogs – New features in Route 53 2025‑2026, mô tả các cải tiến về DNSSEC, health checks và routing policies.

📖 Giải thích nội dung câu hỏi
Câu hỏi yêu cầu bạn xác định công việc nào thuộc trách nhiệm của khách hàng (customer) trong mô hình AWS Shared Responsibility Model.
Mô hình này chia trách nhiệm bảo mật thành hai phần:

• AWS chịu trách nhiệm “Security of the Cloud” – hạ tầng vật lý, mạng, máy chủ, hypervisor, các dịch vụ được quản lý (Lambda, DynamoDB, S3, …).
• Khách hàng chịu trách nhiệm “Security in the Cloud” – hệ điều hành khách, ứng dụng, dữ liệu, cấu hình bảo mật, patching, quản lý khóa, v.v.

Với mỗi dịch vụ, mức độ “được quản lý” (managed) khác nhau, do đó trách nhiệm của khách hàng cũng khác.

✅ Đáp án đúng

🔹 [ĐÚNG] Updating the guest operating system on Amazon EC2 instances

Lý do:

• EC2 là một dịch vụ Infrastructure‑as‑a‑Service (IaaS). Khi bạn khởi tạo một instance, bạn tự lựa chọn AMI (Amazon Machine Image) và chịu trách nhiệm cập nhật, vá lỗi, và bảo trì hệ điều hành (guest OS) cũng như các phần mềm chạy trên instance.
• Đây là ví dụ điển hình của “Security in the Cloud” – khách hàng phải bảo vệ, patch và harden hệ điều hành, quản lý firewall nội bộ, và cập nhật các package.
• Nguồn tham khảo: AWS Documentation – Shared Responsibility Model (được cập nhật liên tục, phiên bản 2026) và Amazon EC2 Security Best Practices.

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

• 🔹 [SAI] Maintaining the infrastructure needed to run AWS Lambda

  • Lambda là một dịch vụ Function‑as‑a‑Service (FaaS), hoàn toàn được quản lý bởi AWS. Khách hàng không cần (và không thể) duy trì hay cập nhật hạ tầng máy chủ, mạng, hoặc runtime môi trường. Bạn chỉ quản lý mã nguồn hàm và các cấu hình cấp quyền.
  • Vì vậy, việc “maintaining the infrastructure” không phải trách nhiệm của khách hàng.

• 🔹 [SAI] Updating the operating system of Amazon DynamoDB instances

  • DynamoDB là dịch vụ NoSQL Database‑as‑a‑Service. Các instance, hệ điều hành, và phần mềm cơ sở dữ liệu được AWS quản lý và cập nhật tự động. Khách hàng chỉ quản lý dữ liệu, bảng, và các thiết lập bảo mật (IAM, encryption).
  • Do đó, việc cập nhật OS của DynamoDB không thuộc trách nhiệm khách hàng.

• 🔹 [SAI] Maintaining Amazon S3 infrastructure

  • Amazon S3 là dịch vụ Object Storage‑as‑a‑Service. Hạ tầng lưu trữ, máy chủ, và phần mềm S3 được AWS duy trì hoàn toàn. Khách hàng chịu trách nhiệm quản lý dữ liệu, bucket policies, versioning, encryption, và lifecycle rules.
  • Vì vậy, “maintaining S3 infrastructure” là công việc của AWS, không phải khách hàng.

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

• AWS (Security of the Cloud)

  • Phần cứng, mạng, trung tâm dữ liệu, hypervisor, các dịch vụ fully‑managed (Lambda, DynamoDB, S3, RDS, Aurora, …).

• Khách hàng (Security in the Cloud)

  • EC2: guest OS, patching, cấu hình firewall, phần mềm ứng dụng.
  • EKS/ECS (container): images, runtime, cấu hình pod, IAM roles.
  • RDS/Aurora (managed DB): cấu hình DB parameter, backup retention, encryption keys.
  • IAM, KMS, VPC, security groups, ACLs, dữ liệu, logging, monitoring.

📚 Tham khảo (2026)

1. AWS Documentation – Shared Responsibility Model (https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response/shared-responsibility.html) – cập nhật lần cuối tháng 03/2026.
2. Amazon EC2 Security Best Practices (https://docs.aws.amazon.com/ec2/latest/userguide/ec2-security.html) – phiên bản 2026.
3. AWS Well‑Architected Framework – Security Pillar (https://aws.amazon.com/architecture/well-architected/security-pillar/) – cập nhật 2025, vẫn áp dụng 2026.
4. AWS Lambda Developer Guide – phần “Runtime and execution environment” (https://docs.aws.amazon.com/lambda/latest/dg/welcome.html).
5. Amazon DynamoDB Developer Guide – phần “Security and access control” (https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/).

Kết luận:
Trong mô hình chia sẻ trách nhiệm của AWS, việc cập nhật hệ điều hành khách (guest OS) trên Amazon EC2 instances là trách nhiệm duy nhất của khách hàng trong các lựa chọn đã cho. Các dịch vụ khác (Lambda, DynamoDB, S3) là các dịch vụ được AWS quản lý toàn bộ hạ tầng, nên khách hàng không phải thực hiện các nhiệm vụ bảo trì hạ tầng hay cập nhật hệ điều hành cho chúng. ✅

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

Công ty đang muốn hiểu rõ trách nhiệm của mình trong mô hình Shared Responsibility Model (mô hình trách nhiệm chia sẻ) của AWS khi vận hành các Amazon EC2 instances.
Mô hình này chia trách nhiệm thành 2 phần:

• AWS – chịu trách nhiệm “Security of the cloud”: hạ tầng vật lý, máy chủ, mạng lõi, hypervisor, phần cứng, …
• Khách hàng – chịu trách nhiệm “Security in the cloud”: hệ điều hành khách, phần mềm, cấu hình bảo mật, dữ liệu, mã hoá, vá lỗi, …

Câu hỏi yêu cầu chọn 2 công việc mà công ty (customer) phải thực hiện.

✅ Các đáp án đúng

1. Patch the guest operating system.
   Giải thích:

   • Đây là nhiệm vụ của customer. Khi một instance EC2 được khởi chạy, AWS chỉ cung cấp hypervisor và hardware; hệ điều hành (guest OS) chạy trên đó do khách hàng quản lý. Do vậy, công ty phải cập nhật, vá và bảo trì hệ điều hành để khắc phục lỗ hổng bảo mật và duy trì tính ổn định.
   • Tham khảo: AWS Documentation – “AWS Shared Responsibility Model” (điều khoản “Security in the Cloud”).

2. Encrypt data at rest on associated storage.
   Giải thích:

   • Việc mã hoá dữ liệu khi lưu trữ (EBS volumes, Instance Store, S3…) là trách nhiệm của customer (trừ khi khách hàng chọn tính năng “default encryption” do AWS cung cấp, nhưng việc bật/tùy chỉnh vẫn do khách hàng quyết định).
   • Customer quyết định sử dụng KMS keys, tạo và quản lý key rotation, và đảm bảo dữ liệu luôn được mã hoá khi nằm trên đĩa.
   • Tham khảo: “Amazon EBS Encryption” và “AWS KMS – Customer Responsibility”.

❌ Các đáp án sai (vì là trách nhiệm của AWS)

• Install and patch the machine hypervisor.
  Giải thích:

  • Hypervisor là lớp phần mềm chạy trực tiếp trên phần cứng, thuộc AWS. AWS chịu trách nhiệm cài đặt, bảo trì và vá hypervisor (ví dụ: Nitro hypervisor). Khách hàng không có quyền truy cập hay thao tác trên lớp này.

• Install the physical hardware and cabling.
  Giải thích:

  • Việc lắp đặt, bảo trì phần cứng vật lý (máy chủ, switch, cabling) là công việc của AWS trong trung tâm dữ liệu. Khách hàng chỉ thuê tài nguyên ảo hoá (EC2) và không can thiệp vào phần cứng.

• Provide physical security for the EC2 instances.
  Giải thích:

  • Physical security (kiểm soát truy cập vào phòng máy, camera, hệ thống phòng cháy chữa cháy…) là trách nhiệm AWS. Customer không cần (và không thể) cung cấp bảo mật vật lý cho các instance EC2 mà họ đang chạy.

📋 Tổng hợp đáp án

• ✅ Patch the guest operating system – Trách nhiệm của công ty.
• ✅ Encrypt data at rest on associated storage – Trách nhiệm của công ty.
• ❌ Install and patch the machine hypervisor – Trách nhiệm của AWS.
• ❌ Install the physical hardware and cabling – Trách nhiệm của AWS.
• ❌ Provide physical security for the EC2 instances – Trách nhiệm của AWS.

📚 Tham khảo

1. AWS Documentation – Shared Responsibility Model (phiên bản cập nhật 2026).
   https://docs.aws.amazon.com/whitepapers/latest/aws-security-best-practices/shared-responsibility-model.html
2. Amazon EC2 User Guide – Managing Your Instances (điều khoản “Operating System Patching”).
   https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/patching.html
3. Amazon EBS Encryption – AWS Key Management Service (KMS) guide.
   https://docs.aws.amazon.com/ebs/latest/userguide/ebs-encryption.html
4. AWS Nitro System – Security Overview (đối với hypervisor).
   https://aws.amazon.com/ec2/nitro/

💡 Lưu ý quan trọng: Khi chuẩn bị cho kỳ thi AWS Certified DevOps Engineer – Professional, luôn nhớ phân biệt rõ ràng “Security of the Cloud” (AWS) và “Security in the Cloud” (Customer). Đối với EC2, các tác vụ liên quan tới hệ điều hành, phần mềm, dữ liệu và cấu hình bảo mật thuộc về khách hàng, còn hạ tầng vật lý, hypervisor, và bảo mật vật lý thuộc về AWS. ✅

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

Công ty hiện đang chạy MySQL trên các máy chủ tự quản lý tại trung tâm dữ liệu on‑premises và muốn chuyển sang dịch vụ quản lý của AWS.
Yêu cầu “migrate the database workloads to an AWS managed service” đồng nghĩa với việc:

• Không cần tự bảo trì hệ điều hành, bản vá, backup, HA…
• Muốn tận dụng các tính năng sẵn có của Amazon RDS (hoặc Amazon Aurora) cho MySQL.

Vì vậy, chiến lược di chuyển cần giữ nguyên logic và mã nguồn SQL, nhưng thay đổi nền tảng vận hành từ tự‑quản lý sang dịch vụ quản lý của AWS.

✅ Chiến lược phù hợp → Replatform (còn gọi là “lift‑and‑shape”).

✅ Đáp án đúng: Replatform

• Replatform: Di chuyển ứng dụng/DB sang một dịch vụ quản lý trên AWS mà không cần viết lại mã nguồn.
  • Ví dụ: chuyển MySQL on‑premises → Amazon RDS for MySQL hoặc Amazon Aurora MySQL‑compatible.
  • Thay đổi chính: từ việc tự quản lý hệ thống (OS, patch, backup) sang việc AWS chịu trách nhiệm quản lý.
  • Không cần thay đổi kiến trúc dữ liệu, chỉ cần cấu hình kết nối và thực hiện migration (có thể dùng AWS Database Migration Service (DMS) hoặc mysqldump).

Với yêu cầu “migrate to an AWS managed service”, Replatform là lựa chọn tối ưu vì nó cho phép chuyển sang RDS/Aurora mà không thay đổi ứng dụng.

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

- [SAI] Rehost

• Giải thích: Rehost (còn gọi “lift‑and‑shift”) là việc di chuyển toàn bộ máy ảo/instance lên AWS mà không thay đổi gì, ví dụ: chuyển MySQL chạy trên EC2.
• Tại sao sai: Đây vẫn là môi trường tự quản lý (EC2), không phải dịch vụ quản lý. Câu hỏi yêu cầu “AWS managed service”, nên Rehost không đáp ứng yêu cầu giảm gánh nặng quản trị.

- [SAI] Repurchase

• Giải thích: Repurchase (hoặc “re‑license”) là mua lại một sản phẩm SaaS mới thay thế hoàn toàn, ví dụ: chuyển từ MySQL on‑premises sang Amazon Aurora Serverless hay một SaaS database khác và viết lại ứng dụng để tương thích.
• Tại sao sai: Repurchase thường yêu cầu thay đổi đáng kể hoặc viết lại phần lớn mã, không phải là chỉ chuyển sang dịch vụ quản lý mà vẫn giữ MySQL. Ngoài ra, MySQL hiện đã có sẵn dịch vụ quản lý (RDS), không cần “mua lại” phần mềm khác.

- [SAI] Refactor

• Giải thích: Refactor (cũng gọi là “re‑architect”) là thay đổi sâu rộng về kiến trúc, mã nguồn để tận dụng các dịch vụ cloud native (ví dụ: chuyển MySQL sang Amazon DynamoDB hoặc Amazon Aurora Serverless v2 với thay đổi schema).
• Tại sao sai: Yêu cầu thay đổi đáng kể về code, schema, và thường được dùng khi muốn tận dụng tính năng serverless, micro‑services… Nhưng câu hỏi chỉ muốn chuyển sang dịch vụ quản lý mà không cần thay đổi logic, vì vậy Refactor quá “nặng” cho nhu cầu này.

- [ĐÚNG] Replatform

• Giải thích: Như đã nêu ở trên, Replatform cho phép di chuyển MySQL sang RDS/Aurora mà không cần viết lại ứng dụng.
• Lý do chọn: Đáp ứng đầy đủ yêu cầu “AWS managed service”, giảm gánh nặng vận hành, đồng thời giữ nguyên tính năng và dữ liệu hiện có.

🛠️ Các bước thực hiện “Replatform” thực tiễn (2026)

1. Đánh giá môi trường hiện tại
   • Kiểm tra phiên bản MySQL, kích thước DB, tính năng (replication, stored procedures…).
2. Lựa chọn dịch vụ mục tiêu
   • Amazon RDS for MySQL (đối với tương thích 100%).
   • Amazon Aurora MySQL‑compatible (nếu muốn hiệu năng và tính sẵn sàng cao hơn).
3. Sử dụng AWS Database Migration Service (DMS)
   • Thiết lập source endpoint (on‑prem MySQL) và target endpoint (RDS/Aurora).
   • Chạy migration “full load + CDC” để giảm downtime.
4. Cập nhật chuỗi kết nối (connection strings) trong ứng dụng.
5. Kiểm thử và chuyển đổi
   • Kiểm tra tính toàn vẹn dữ liệu, hiệu năng, và failover.
6. Tắt hệ thống on‑prem sau khi xác nhận ổn định.

Nguồn tham khảo

• AWS Migration Strategies – “6 Rs of Cloud Migration”, AWS Well‑Architected Framework (cập nhật 2025).
• Amazon RDS for MySQL và Amazon Aurora MySQL‑compatible Documentation (phiên bản 2026).
• AWS Database Migration Service User Guide (2026).

🎯 Kết luận

Với mục tiêu di chuyển MySQL on‑premises sang dịch vụ quản lý của AWS, chiến lược Replatform là lựa chọn chính xác nhất. Các lựa chọn khác (Rehost, Repurchase, Refactor) không đáp ứng đầy đủ yêu cầu về việc sử dụng dịch vụ quản lý mà không thay đổi lớn về kiến trúc hoặc mã nguồn. ✅

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

Câu hỏi mô tả một doanh nghiệp muốn di chuyển một ứng dụng monolithic lên AWS và đồng thời hiện đại hoá bằng cách chia nhỏ thành các microservice.
Yêu cầu quan trọng:

1. Di chuyển (migration) – phải đưa ứng dụng hiện tại lên môi trường AWS.
2. Biến đổi (modernization) – không chỉ “đưa lên” mà còn đổi kiến trúc từ monolith sang microservices.

Do vậy, chiến lược di chuyển cần bao gồm cả việc di chuyển và cải tổ lại ứng dụng.

✅ Đáp án đúng: Refactor

Lý do chọn “Refactor” (còn được gọi là “Re‑architect”):

• Refactor nghĩa là điều chỉnh mã nguồn và kiến trúc để tận dụng các dịch vụ đám mây bản địa (ví dụ: Amazon ECS, EKS, AWS Lambda, Amazon API Gateway, Amazon SQS, …).
• Khi muốn tách monolith thành microservice, chúng ta phải đổi thiết kế, cắt các thành phần, định nghĩa giao diện API, và triển khai từng service độc lập. Đây chính là mục tiêu của Refactor.
• AWS khuyến nghị dùng Refactor khi cần tối ưu hoá chi phí, hiệu năng, khả năng mở rộng, hoặc muốn tận dụng các dịch vụ quản lý (serverless, container).
• Từ AWS Migration Hub và AWS Well‑Architected Framework (2026), Refactor được mô tả là “cải tiến sâu rộng để chuyển đổi sang kiến trúc cloud‑native”.

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

1. Rehost

• Giải thích: Di chuyển “lift‑and‑shift” – chuyển máy ảo, máy chủ, hoặc môi trường hiện tại lên EC2 mà không thay đổi gì.
• Tại sao sai: Rehost không thay đổi kiến trúc; nó giữ nguyên monolith và không đáp ứng yêu cầu “split into microservices”. Khi chỉ lift‑and‑shift, bạn vẫn sẽ có một ứng dụng monolithic chạy trên EC2, không đạt được hiện đại hoá.

2. Repurchase

• Giải thích: Mua lại (hoặc thuê) một giải pháp SaaS thay thế hoàn toàn ứng dụng hiện tại.
• Tại sao sai: Repurchase không chuyển mã nguồn hiện có sang microservices; nó thay thế toàn bộ ứng dụng bằng một sản phẩm thứ ba. Nếu công ty muốn giữ lại logic nghiệp vụ và chỉ chia nhỏ, Repurchase không phù hợp.

3. Replatform

• Giải thích: “Lift‑and‑shift” có một số tinh chỉnh nhẹ (ví dụ: chạy trên Amazon RDS thay vì DB on‑prem, hoặc chuyển sang container mà không thay đổi code).
• Tại sao sai: Replatform chỉ cải thiện hạ tầng mà không thay đổi kiến trúc ứng dụng. Việc tách thành microservice đòi hỏi điều chỉnh logic, tách code, tạo API, điều này vượt ra ngoài mức độ “light‑touch” của Replatform.

4. Refactor (ĐÚNG)

• Giải thích: Thay đổi đáng kể mã nguồn và/hoặc kiến trúc để tận dụng các dịch vụ cloud‑native.
• Tại sao đúng: Đúng với mục tiêu “split the monolithic application into microservices”. Bạn sẽ cắt các thành phần, đóng gói từng service (ECS/EKS, Lambda), sử dụng managed database, định nghĩa API Gateway, … Tất cả đều là những hành động thuộc Refactor.

🛠️ Khi nào nên dùng Refactor (đến năm 2026)

• Cần hiện đại hoá: chuyển sang cloud‑native (serverless, containers).
• Muốn cải thiện độ độ chịu lỗi, khả năng mở rộng, thời gian đưa sản phẩm ra thị trường.
• Khi kiến trúc hiện tại không phù hợp với môi trường cloud (ví dụ: phụ thuộc vào hệ thống tệp cục bộ, cấu hình mạng phức tạp).
• Khi doanh nghiệp có đội ngũ phát triển sẵn sàng viết lại hoặc tái cấu trúc code.

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

1. AWS Migration Strategies – The 6 R’s (AWS Migration Hub Documentation, phiên bản cập nhật 2025‑2026).
2. AWS Well‑Architected Framework – Serverless and Containers (2026).
3. AWS re:Invent 2025 – “Modernizing Monolithic Applications with Microservices on AWS” (bài thuyết trình).
4. AWS Whitepaper: “Choosing the Right Migration Strategy” (cập nhật lần cuối 2026).

Tóm lại: Để đáp ứng cả yêu cầu di chuyển lên AWS và hiện đại hoá bằng cách chia nhỏ thành microservices, chiến lược phù hợp nhất là Refactor. Các chiến lược khác (Rehost, Repurchase, Replatform) không đáp ứng nhu cầu thay đổi kiến trúc sâu rộng. ✅

🔎 Phân tích câu hỏi
Công ty muốn theo dõi chi tiết chi phí đám mây và muốn phân bổ chi phí theo từng bộ phận (department) và dự án (project). Điều này đòi hỏi một cơ chế “gắn nhãn” (tag) hoặc “phân bổ” (allocation) để mỗi chi phí dịch vụ AWS có thể được gắn với một hoặc nhiều thuộc tính (tag) mà sau này có thể dùng trong báo cáo chi phí.

✅ Đáp án đúng: Cost allocation tags

👉 Vì sao “Cost allocation tags” là lựa chọn đúng?

• Tagging: AWS cho phép người dùng gắn tag (cặp key‑value) lên hầu hết các tài nguyên (EC2, S3, RDS, Lambda, …).
• Cost allocation tags là một loại tag đặc biệt được đánh dấu (activated) trong AWS Billing console để AWS tính toán chi phí dựa trên chúng.
• Khi một tag được kích hoạt, báo cáo chi phí (Cost Explorer, CUR – Cost and Usage Report) sẽ phân bổ chi phí cho từng giá trị của tag (ví dụ: Department=Finance, Project=Alpha).
• Các tag này cho phép lập báo cáo chi tiết, tạo budget, và tự động hóa quy trình phân bổ chi phí bằng các công cụ như AWS Lambda + Cost Explorer API.
• Từ 2024‑2026, AWS đã mở rộng hỗ trợ tag cho hầu hết các dịch vụ, và các tag có thể được áp dụng động thông qua AWS Resource Groups Tagging API hoặc AWS CloudFormation để đảm bảo tính nhất quán.

Kết luận: Đối với yêu cầu “detailed tracking of cloud costs by department and project”, Cost allocation tags là công cụ chuẩn nhất và được thiết kế riêng cho mục đích này.

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

1. Consolidated billing

• Mô tả: Cho phép kết hợp nhiều tài khoản AWS dưới một “payer account” để nhận một hoá đơn duy nhất.
• Lý do sai: Consolidated billing đồng nhất hoá đơn, nhưng không cung cấp khả năng phân loại chi phí theo bộ phận hoặc dự án. Nó chỉ giúp quản lý thanh toán tổng thể và chia sẻ lợi ích Reserved Instances/ Savings Plans, không đáp ứng nhu cầu “đánh dấu chi phí”.

2. AWS Marketplace

• Mô tả: Nơi cung cấp các phần mềm, dịch vụ của bên thứ ba mà khách hàng có thể mua và triển khai trên AWS.
• Lý do sai: Marketplace chỉ liên quan đến việc mua và cấp phép phần mềm, không cung cấp bất kỳ cơ chế nào để gắn nhãn chi phí hay theo dõi chi phí theo bộ phận/dự án.

3. AWS Budgets

• Mô tả: Cho phép đặt ngân sách cho tổng chi phí, chi phí dựa trên tag, hoặc dựa trên dịch vụ; có thể cảnh báo khi vượt ngưỡng.
• Lý do sai: Mặc dù AWS Budgets có thể sử dụng tag làm tiêu chí, nó không phải là công cụ gắn tag. Để Budgets hoạt động dựa trên tag, các Cost allocation tags phải được kích hoạt trước. Do vậy, Budgets phụ thuộc vào Cost allocation tags, chứ không thể thay thế chúng.

🛠️ Các bước thực hành (theo AWS 2026)

1. Tạo tag:

   aws resourcegroupstaggingapi tag-resources \
       --resource-arn-list arn:aws:ec2:region:account-id:instance/i-1234567890abcdef0 \
       --tags Department=Finance Project=Alpha
   

2. Kích hoạt tag cho chi phí:

   • Vào Billing > Cost Management > Cost Allocation Tags.
   • Chọn các tag muốn activate (ví dụ: Department, Project).

3. Kiểm tra báo cáo:

   • Sử dụng Cost Explorer → Group by Tag → chọn Department và/hoặc Project.
   • Hoặc tải Cost and Usage Report (CUR) và phân tích bằng Amazon Athena hoặc QuickSight.

4. Tự động hoá:

   • Thiết lập AWS Lambda để đánh dấu tài nguyên mới bằng tag dựa trên quy tắc (ví dụ: khi một EC2 instance được tạo trong VPC của bộ phận Finance, tự động gán Department=Finance).

📚 Tham khảo

• AWS Documentation – Cost allocation tags (phiên bản cập nhật 2026): https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-alloc-tags.html
• AWS Billing and Cost Management User Guide – Using Cost Explorer: https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/cost-explorer.html
• AWS Blog – New tagging capabilities for Cost Management (2025 update): https://aws.amazon.com/blogs/aws/new-tagging-capabilities-cost-management/

Tóm lại, để “implement detailed tracking of its cloud costs by department and project”, Cost allocation tags là công cụ chính xác và phù hợp nhất. Các lựa chọn còn lại dù có ích trong các ngữ cảnh khác nhưng không đáp ứng yêu cầu gắn nhãn chi phí chi tiết. ✅

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

A user wants to invoke an AWS Lambda function when an Amazon EC2 instance enters the “stopping” state. Which AWS service is appropriate for this use case?

Câu hỏi yêu cầu chúng ta tự động kích hoạt (invoke) một hàm Lambda dựa trên sự kiện trạng thái “stopping” của một EC2 instance. Vì vậy chúng ta cần một dịch vụ có khả năng:

1. Thu thập, lọc và phát (publish) các sự kiện hệ thống (ví dụ: thay đổi trạng thái của tài nguyên AWS).
2. Kết nối (target) tới Lambda để thực thi hành động khi sự kiện khớp.

Trong AWS, dịch vụ chịu trách nhiệm chính cho việc này là Amazon EventBridge (trước đây là CloudWatch Events). EventBridge nhận các sự kiện từ các dịch vụ AWS (trong đó có EC2) và cho phép định nghĩa rule để chuyển tiếp (forward) chúng tới các target như Lambda, Step Functions, SNS, SQS, …

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

• Vì sao?

  • EventBridge cung cấp event source cho EC2 và có event pattern cho các trạng thái lifecycle (pending, running, stopping, stopped, shutting-down, terminated).
  • Khi một instance chuyển sang trạng thái stopping, EventBridge sẽ sinh ra một sự kiện dạng JSON, và rule của chúng ta có thể match vào trường detail.state = "stopping" và target là Lambda function.
  • Kiến trúc này server‑less, không cần quản lý polling hoặc viết script trên instance.

• Cập nhật 2026:

  • EventBridge đã mở rộng khả năng event archive và event replay, cho phép lưu lại lịch sử các sự kiện EC2 và chạy lại chúng nếu cần.
  • Các event schema của EC2 được tự động cập nhật, bao gồm trường stateTransitionReason, giúp lọc chi tiết hơn.

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

❌ AWS Config

• Mô tả: AWS Config là dịch vụ đánh giá và ghi lại cấu hình tài nguyên AWS, cung cấp lịch sử cấu hình và rule để kiểm tra tuân thủ.
• Tại sao sai: Config không phát sinh sự kiện thời gian thực khi một instance chuyển trạng thái; nó chỉ ghi lại thay đổi cấu hình và cho phép rule (Config Rules) để kiểm tra trạng thái, nhưng không có khả năng trigger Lambda ngay lập tức. Đối với yêu cầu “khi EC2 bắt đầu dừng”, Config không đáp ứng được thời gian thực và không cung cấp cơ chế target Lambda.

❌ Amazon Simple Notification Service (Amazon SNS)

• Mô tả: SNS là dịch vụ pub/sub để gửi thông báo tới các endpoint (email, SMS, SQS, Lambda, …).
• Tại sao sai: SNS không tự sinh ra các sự kiện EC2. Để dùng SNS, bạn cần một nguồn phát (ví dụ EventBridge) để gửi tin nhắn tới SNS, sau đó SNS lại forward tới Lambda. Vì câu hỏi yêu cầu dịch vụ trực tiếp để “khi EC2 chuyển trạng thái thì gọi Lambda”, SNS không phải là lựa chọn chính.

❌ AWS CloudFormation

• Mô tả: CloudFormation là công cụ Infrastructure as Code (IaC) để tạo, cập nhật và xóa tài nguyên AWS thông qua template.
• Tại sao sai: CloudFormation không phải là dịch vụ xử lý sự kiện. Nó chỉ dùng để provision tài nguyên và không có cơ chế “listen” tới trạng thái lifecycle của EC2 để kích hoạt Lambda.

📘 Tham khảo (2026)

1. Amazon EventBridge – User Guide, phần “EC2 Event Types”.
   https://docs.aws.amazon.com/eventbridge/latest/userguide/event-types.html#ec2-event-types
2. AWS Lambda – Invoking Lambda Functions with EventBridge (bản cập nhật 2025).
   https://docs.aws.amazon.com/lambda/latest/dg/services-eventbridge.html
3. AWS Config – What Is AWS Config? (đọc vào tháng 3/2026).
   https://docs.aws.amazon.com/config/latest/developerguide/what-is-config.html

🛠️ Kết luận nhanh

• Amazon EventBridge là dịch vụ duy nhất trong các lựa chọn có khả năng lắng nghe sự kiện trạng thái “stopping” của EC2 và tự động gọi Lambda ngay lập tức.
• Các dịch vụ còn lại (AWS Config, SNS, CloudFormation) không đáp ứng được yêu cầu về phát hiện thời gian thực + trigger Lambda.

✅ Vì vậy, đáp án đúng là: Amazon EventBridge.