Ngân hàng đề — AWS Certified CloudOps Engineer Associate

🧩 Phân tích nội dung câu hỏi

Đề mô tả hạ tầng EC2 đặt sau Elastic Load Balancer, trải trên hai AZ, mỗi ELB có hai EC2 instance đăng ký. Tình huống: cả hai instance trong một AZ đều bị đánh dấu unhealthy. Câu hỏi là traffic đi tới ELB đang nối với các instance unhealthy đó sẽ ra sao.

Cụm từ quyết định là "Both the instances in one AZ have been recorded as unhealthy" — tức là target group phía đó không còn target healthy nào, nhưng vẫn có target đăng ký. Hai điều kiện này phải tách bạch, vì load balancer hành xử khác nhau ở ba trạng thái: (1) còn ít nhất một target healthy, (2) có target nhưng tất cả unhealthy, (3) không có target nào đăng ký. Đề rơi vào trường hợp (2), và đó chính là chỗ các phương án nhiễu đánh vào.

✅ Vì sao đáp án đúng là đúng

C — The Load Balancer routes requests to the unhealthy targets.

Quy tắc định tuyến của ELB: nếu trong target group còn ít nhất một target healthy, load balancer chỉ gửi request tới các target healthy. Nhưng nếu target group chỉ toàn target unhealthy, load balancer vẫn gửi request tới chính các target unhealthy đó — nó không tự "đóng cửa" hay ngừng nhận traffic.

Logic đằng sau: chọn giữa "gửi tới một target có thể vẫn còn phục vụ được phần nào" và "không gửi đi đâu cả", thì phương án đầu vẫn có cơ hội phản hồi. Health check có thể fail vì lý do hẹp (một endpoint check hỏng, ngưỡng quá nhạy) trong khi ứng dụng vẫn còn xử lý được. Vì vậy AWS khuyến nghị đặt các instance này trong Auto Scaling Group nếu ứng dụng là business-critical — để instance hỏng được thay thế thay vì tiếp tục nhận traffic.

❌ Vì sao các phương án còn lại sai

A — Load Balancer hiển thị trạng thái "unhealthy" và không nhận request nào. Đây là phương án bịa, dựng ra làm nhiễu. Bản thân load balancer không có trạng thái "unhealthy" theo kiểu đó; health check là khái niệm áp lên target, không áp lên load balancer. Và như đã nói, ELB không hề ngừng nhận request khi target hỏng.

B — HTTP 403: Forbidden. 403 là mã trả về khi bạn gắn một AWS WAF web ACL để giám sát request tới Application Load Balancer và web ACL đó chặn request. Đó là quyết định của lớp lọc bảo mật, hoàn toàn không liên quan tới sức khỏe của target. Đề không nhắc gì tới WAF.

D — HTTP 503: Service unavailable. Đây là phương án gần đúng nhất và cũng là bẫy chính. 503 đúng là do load balancer sinh ra, nhưng ở một điều kiện khác: khi target group không có target nào được đăng ký. Đề lại nói rõ mỗi ELB có hai EC2 instance registered — chúng vẫn nằm trong target group, chỉ là đang unhealthy. "Registered nhưng unhealthy" ≠ "không có target". Ai đọc lướt cụm "unhealthy" mà bỏ qua cụm "registered with it" sẽ chọn D.

📌 Điểm cần nhớ

• Ba trạng thái target group cho ra ba hành vi khác nhau: còn target healthy → chỉ định tuyến tới target healthy; toàn bộ unhealthy → vẫn định tuyến tới target unhealthy; không có target đăng ký → HTTP 503.
• Phân biệt "registered" với "healthy" — đề thi rất hay đặt hai từ này cạnh nhau để tách 503 khỏi hành vi định tuyến tới target unhealthy.
• HTTP 403 từ Application Load Balancer gắn với AWS WAF web ACL chặn request, không phải với health check.
• Load balancer không tự ngừng nhận traffic khi target hỏng — muốn instance hỏng được thay thế thì phải dùng Auto Scaling Group, đặc biệt với ứng dụng business-critical.

🧩 Phân tích nội dung câu hỏi

Đề đặt bạn vào vai SysOps Administrator phải xử lý vấn đề hiệu năng mạng cho một đội EC2 instances, rồi hỏi: use-case nào là chỗ dùng đúng của enhanced networking?

Cụm từ quyết định nằm ở chính chữ "the right fit for using enhanced networking" — đề không hỏi "cách nào làm mạng nhanh hơn" nói chung, mà hỏi triệu chứng nào là dấu hiệu nên bật enhanced networking. Đây là kiểu câu "nhận diện đúng công cụ cho đúng triệu chứng", nên phải soi xem mỗi phương án có thật sự nằm trong phạm vi mà enhanced networking giải quyết hay không.

Ràng buộc phân biệt thứ hai: enhanced networking là chuyện giữa các EC2 instances bên trong AWS, dựa trên SR-IOV ở tầng network interface của instance. Bất kỳ phương án nào nói về kết nối on-premises ↔ AWS, hay về storage, đều lệch hẳn khỏi phạm vi đó — kể cả khi nó có nhắc tới con số tốc độ nghe rất "mạng".

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A — "To support throughput near or exceeding 20K packets per second (PPS) on the VIF driver".

Enhanced networking dùng SR-IOV (single root I/O virtualization) để cấp năng lực mạng hiệu năng cao trên các instance type được hỗ trợ. SR-IOV là một cách ảo hoá thiết bị cho I/O cao hơn và tiêu tốn CPU thấp hơn so với network interface ảo hoá theo kiểu truyền thống. Kết quả là băng thông cao hơn, PPS cao hơn, và độ trễ giữa các instance ổn định và thấp hơn.

Điểm mấu chốt để nhận diện: khi tỷ lệ packets-per-second chạm trần, đó thường là dấu hiệu bạn đã đụng ngưỡng trên của VIF driver (virtual network interface driver) — tức là nút thắt nằm ở chính lớp network interface ảo, đúng chỗ mà SR-IOV thay thế. Best practice được nêu rõ: throughput ở mức gần hoặc vượt 20K PPS trên VIF driver thì nên chuyển sang enhanced networking. Phương án A mô tả đúng ngưỡng và đúng thành phần (VIF driver), nên nó là "the right fit".

Thêm hai chi tiết đáng nhớ: enhanced networking không tính thêm phí, và mọi instance type thế hệ hiện hành đều hỗ trợ, ngoại trừ T2.

❌ Vì sao các phương án còn lại sai

B — "To configure Direct Connect to reach speeds up to 25 Gbps between EC2 instances": sai vì lẫn lộn hai lớp hoàn toàn khác nhau. AWS Direct Connect là dịch vụ mạng cung cấp đường kết nối riêng thay cho Internet để nối tài nguyên on-premises với AWS Cloud — nó giúp giảm chi phí, tăng băng thông và cho trải nghiệm mạng ổn định hơn so với kết nối qua Internet. Enhanced networking không phải là thứ dùng để "cấu hình Direct Connect", và Direct Connect cũng không phải cơ chế nối giữa các EC2 instances với nhau. Phương án này ghép một tên dịch vụ thật với một mục đích không phải của nó.

C — "To configure multi-attach for an EBS volume that can be attached to a maximum of 16 EC2 instances in a single Availability Zone": bản thân mô tả kỹ thuật này đúng — EBS volume loại io1 hoặc io2 khi bật Multi-Attach có thể gắn vào tối đa 16 EC2 instances trong cùng một Availability Zone, và mỗi Nitro-based instance có thể gắn nhiều volume Multi-Attach. Multi-Attach giúp đạt tính sẵn sàng cao hơn cho ứng dụng tự quản lý thứ tự ghi để giữ nhất quán dữ liệu. Nhưng đây là chuyện storage, không phải networking: bạn không cần enhanced networking để cấu hình Multi-Attach. Đây là phương án gài bẫy kiểu "câu mô tả đúng nhưng trả lời sai câu hỏi" — đọc lướt thấy đúng nên rất dễ chọn.

D — "To reach speeds up to 2,500 Gbps between EC2 instances": đây là distractor dựng bằng cách thổi phồng một con số quen thuộc. Con số thực tế đáng nhớ là 25 Gbps: muốn đạt tới mức đó giữa các instance thì launch chúng trong cluster placement group cùng với instance hỗ trợ ENA; còn muốn đạt tới 10 Gbps thì launch vào cluster placement group với instance type có enhanced networking. Mức 2.500 Gbps giữa các EC2 instances là không tồn tại — nên dù phương án này nói đúng chủ đề (tốc độ giữa các instance), con số khiến nó sai dứt khoát. Bài học: khi hai phương án giống nhau chỉ ở con số, con số chính là chỗ ra đề.

📌 Điểm cần nhớ

• Enhanced networking = SR-IOV, giải quyết nút thắt ở VIF driver: cho PPS cao hơn, băng thông cao hơn, latency giữa instance thấp và ổn định hơn, đồng thời giảm tải CPU. Không mất thêm phí, và mọi instance thế hệ hiện hành đều hỗ trợ trừ T2.
• Triệu chứng kinh điển để chọn enhanced networking là PPS chạm trần — mốc best practice hay được hỏi là gần hoặc vượt 20K PPS trên VIF driver. Nếu đề mô tả nghẽn ở packets-per-second chứ không phải ở băng thông thô, gần như chắc chắn đáp án là enhanced networking.
• Phân biệt phạm vi từng dịch vụ trước khi so chi tiết: Direct Connect là on-premises ↔ AWS; EBS Multi-Attach là storage (io1/io2, tối đa 16 instances, cùng một AZ); enhanced networking / ENA + cluster placement group mới là hiệu năng mạng giữa các EC2 instances.
• Cẩn thận hai kiểu bẫy trong dạng câu này: phương án mô tả kỹ thuật hoàn toàn đúng nhưng không liên quan tới thứ đề hỏi (như C), và phương án đúng chủ đề nhưng sai con số (như D, 2.500 Gbps thay vì 25 Gbps).

🧩 Phân tích nội dung câu hỏi

Đề mô tả một sự cố vận hành rất cụ thể: một Auto Scaling group (ASG) thất bại khi launch instance có encrypted EBS volume, và lý do được nêu thẳng ra là service-linked role không có quyền dùng customer-managed CMK đã mã hoá volume đó.

Cụm từ quyết định nằm ngay câu đầu: "a company operating multiple AWS accounts", cộng với chi tiết ở phương án B nhắc tới "the instance account" tách biệt với "the ASG account". Nói cách khác, CMK và Auto Scaling group nằm ở hai AWS account khác nhau. Đây chính là ràng buộc phân biệt A với D — hai phương án này gần như đối xứng nhau, cùng nói về service-linked role và cùng nói về quyền dùng CMK, chỉ khác ở chỗ CMK nằm ở đâu và xử lý cross-account như thế nào.

Nếu bỏ qua chi tiết "multiple AWS accounts", câu này trông như có hai đáp án đúng. Đọc kỹ thì chỉ còn một.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là D: đưa CMK về cùng account với Auto Scaling group — copy snapshot và re-encrypt nó bằng một CMK thuộc chính account của ASG, rồi cho phép service-linked role dùng CMK mới.

Cách này xử lý tận gốc vấn đề cross-account. KMS không cho phép "chuyển" một CMK sang account khác, nhưng snapshot thì copy được, và thao tác copy snapshot cho phép chỉ định một KMS key khác để mã hoá lại bản sao. Sau bước đó, khoá mã hoá volume nằm cùng account với ASG, nên việc cấp quyền chỉ còn là bài toán trong nội bộ một account: sửa key policy để service-linked role của Auto Scaling được phép dùng khoá. Không cần grant, không cần bắc cầu quyền qua ranh giới account.

Tài liệu AWS về lỗi launch failure của Auto Scaling (Client.InternalError: Client error on launch) nêu đúng hai hướng khắc phục; D chính là hướng thứ nhất — hướng đơn giản hơn và không phải duy trì cấu hình quyền xuyên account về lâu dài.

❌ Vì sao các phương án còn lại sai

A — Sửa key policy trên CMK cho service-linked role, rồi cập nhật ASG dùng role đó. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Nội dung của nó hoàn toàn hợp lệ, nhưng chỉ khi CMK và Auto Scaling group ở cùng một AWS account. Trong tình huống cross-account, chỉnh key policy thôi là chưa đủ: hướng khắc phục cross-account theo tài liệu AWS còn đòi phải cho account của ASG quyền truy cập CMK, rồi định nghĩa một IAM user/role trong account đó để tạo grant lên CMK với grantee principal chính là service-linked role. A bỏ hẳn bước grant, nên áp dụng vào bài toán cross-account sẽ không giải quyết được lỗi.

B — Export CMK từ account chứa instance sang account của ASG. Sai ở một điểm nền tảng: không thể export một CMK ra khỏi KMS. Phần key material của KMS key không rời khỏi ranh giới dịch vụ; cách chia sẻ quyền dùng khoá là qua key policy và grant, chứ không phải mang bản thân khoá đi nơi khác. Phương án này mô tả một thao tác không tồn tại.

C — ASG không thể khởi tạo EC2 instance có encrypted volume. Sai hoàn toàn và chỉ đóng vai distractor. Auto Scaling launch instance với encrypted EBS volume là chuyện bình thường; chính đề bài cũng ngụ ý điều đó khi mô tả lỗi là vấn đề quyền truy cập khoá, không phải vấn đề khả năng hỗ trợ. Nếu ASG không làm được việc này thì lỗi đã không nói tới service-linked role và CMK.

📌 Điểm cần nhớ

• Với lỗi launch failure của Auto Scaling liên quan đến encrypted EBS volume, nguyên nhân điển hình là service-linked role không có quyền dùng CMK — luôn hỏi tiếp: CMK nằm cùng account hay khác account với ASG?
• Cùng account → sửa key policy cho service-linked role là đủ. Khác account → hoặc copy + re-encrypt snapshot bằng CMK trong account của ASG, hoặc giữ CMK ở account cũ nhưng phải tạo grant với service-linked role làm grantee principal.
• CMK không export được. Bất kỳ phương án nào nói "export/di chuyển khoá sang account khác" đều loại ngay; chia sẻ quyền dùng khoá chỉ qua key policy và grant.
• Copy snapshot là cơ chế chuẩn để đổi khoá mã hoá của dữ liệu EBS — nó cho phép chỉ định KMS key khác cho bản sao, và đây là cách đưa dữ liệu đã mã hoá về dưới quyền quản lý của một account khác.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống vận hành rất đời thường: một CloudWatch Alarm liên tục nằm ở trạng thái ALARM, và lập trình viên mới vào nghề không hiểu tại sao. Câu hỏi yêu cầu chọn cách xử lý phù hợp dưới góc nhìn SysOps Administrator.

Cụm từ quyết định là "constantly in the ALARM state" — nghĩa là alarm ở lì trong trạng thái ALARM, chứ không phải bắn một lần rồi kẹt. Kèm theo đó là chi tiết ngầm quan trọng: đề không hề nói metric đã hạ xuống dưới ngưỡng. Nếu metric vẫn đang vượt ngưỡng, thì việc alarm giữ nguyên trạng thái ALARM không phải là lỗi, mà là hành vi bình thường theo thiết kế.

Vì vậy câu này thực chất kiểm tra một hiểu lầm rất phổ biến: nhiều người tưởng CloudWatch Alarm là "sự kiện bắn một lần" cần được reset, trong khi nó là máy trạng thái phản ánh liên tục kết quả đánh giá metric so với threshold.

✅ Vì sao đáp án đúng là đúng

D — Alarms continue to evaluate metrics against the configured threshold, even after they have already triggered. You can adjust the alarm threshold if you do not want it to be in ALARM state.

CloudWatch Alarm không ngừng đánh giá sau khi đã kích hoạt. Nó tiếp tục so metric với threshold theo từng chu kỳ đánh giá, và trạng thái hiển thị (OK / ALARM / INSUFFICIENT_DATA) luôn là kết quả cập nhật mới nhất — đó chính là lý do bạn nhìn vào console lúc nào cũng thấy tình trạng thực tế tại thời điểm đó.

Hệ quả trực tiếp: chừng nào giá trị metric vẫn còn vi phạm ngưỡng, alarm sẽ vẫn ở ALARM và chỉ tự chuyển về OK khi metric thôi vi phạm. Không cần ai reset cả. Nếu mức tải mới này thực chất là bình thường đối với hệ thống — ví dụ ứng dụng đã tăng trưởng và CPU nền giờ cao hơn trước — thì cách xử lý đúng là chỉnh lại threshold cho khớp với định nghĩa "bình thường" mới, để CloudWatch coi mức đó là OK.

Nói cách khác, D vừa giải thích đúng cơ chế (đánh giá liên tục), vừa đưa ra hành động sửa đúng (điều chỉnh ngưỡng thay vì reset hay dựng lại alarm).

❌ Vì sao các phương án còn lại sai

A — Alarm bị cấu hình sai, phải xoá và tạo lại. Đây là phương án "gần đúng" nhất về mặt cảm tính, vì việc alarm kêu mãi khiến người ta nghi cấu hình hỏng. Nhưng nó hỏng ở chỗ chẩn đoán sai nguyên nhân: hiện tượng mô tả trong đề là hành vi thiết kế, không phải lỗi cấu hình. Xoá rồi tạo lại y hệt sẽ cho ra đúng kết quả cũ, vì metric vẫn đang vượt ngưỡng. Ngoài ra, ngay cả khi ngưỡng đặt chưa hợp lý thì cũng chỉ cần sửa threshold, không cần huỷ alarm — xoá và dựng lại còn làm mất lịch sử trạng thái của alarm.

B — Alarm tuỳ chỉnh khi đã kích hoạt sẽ ở nguyên trạng thái ALARM cho tới khi bị vô hiệu hoá thủ công qua Console hoặc bằng mã ứng dụng. Sai ở phần khẳng định "kẹt cho tới khi bị tắt thủ công". CloudWatch không phân biệt alarm tạo từ custom metric hay từ metric có sẵn ở điểm này: cả hai đều được đánh giá liên tục và tự động quay về OK khi metric hết vi phạm ngưỡng. Việc tắt (disable) alarm chỉ là ngừng hành động, không phải cơ chế để thoát khỏi ALARM. Phương án này biến một hành vi tự phục hồi thành thao tác thủ công.

C — Sau khi alarm kích hoạt và action được thực thi, logic ứng dụng phải tự reset alarm về trạng thái bình thường; đội phát triển phải viết đoạn mã đó. Đây là phương án dụ dỗ nhất vì nó mượn mô hình quen thuộc từ các hệ thống cảnh báo kiểu "ack rồi clear". CloudWatch không hoạt động như vậy: không có API nào bắt buộc ứng dụng phải gọi để "trả alarm về OK", và cũng không có yêu cầu viết mã reset. Chuyển trạng thái là việc của chính dịch vụ, dựa trên dữ liệu metric. Nếu tin theo C, đội phát triển sẽ tốn công xây một cơ chế reset thừa mà vẫn không giải quyết được gốc rễ — metric vẫn vượt ngưỡng.

📌 Điểm cần nhớ

• CloudWatch Alarm là máy trạng thái phản ánh liên tục, không phải sự kiện bắn một lần: nó vẫn đánh giá metric so với threshold sau khi đã vào ALARM, và tự quay về OK khi metric hết vi phạm.
• Alarm nằm lâu ở ALARM không mặc nhiên là lỗi — trước hết hãy kiểm tra metric có còn vượt ngưỡng hay không, thay vì nghi cấu hình hỏng.
• Không có khái niệm "reset alarm" bằng mã ứng dụng trong CloudWatch; đừng chọn những phương án đòi hỏi thao tác thủ công hay logic reset do đội phát triển viết.
• Khi mức "bình thường" của hệ thống đã thay đổi, cách sửa đúng là điều chỉnh threshold cho khớp thực tế, chứ không xoá và tạo lại alarm hay disable nó đi.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tổ chức có hai AWS account: Development account (chứa hai IAM group là Developers và Testers) và Production account (chứa S3 bucket đang chạy thật). Yêu cầu: thỉnh thoảng developer phải cập nhật được S3 bucket bên production.

Có hai cụm từ quyết định đáp án:

• "update the live S3 Bucket in the production account" — tài nguyên cần truy cập nằm ở production. Đây là điểm phân biệt giữa A và C: trong mô hình cross-account role, role luôn được tạo ở account chứa tài nguyên, còn account chứa người dùng mới là trusted entity.
• "two IAM groups: Developers and Testers" — đề cố tình nêu ra cả hai nhóm dù chỉ developer cần quyền. Chi tiết này phân biệt A với D: nếu không xử lý gì với Testers, cả hai nhóm đều có thể sts:AssumeRole sang production.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là A, và nó làm đủ ba việc trong quy trình cross-account access chuẩn của AWS:

1. Tạo IAM role trong Production account. Role này khai Development account là trusted entity trong trust policy, tức là cho phép principal thuộc account kia gọi AssumeRole. Kèm theo là permissions policy cho phép thao tác cập nhật lên bucket cần thiết. Vì role nằm cùng account với bucket, nó cấp được quyền lên tài nguyên đó một cách trực tiếp.
2. Sửa IAM group policy của Testers ở Development account để deny quyền assume role vừa tạo. Trust policy ở phía production mới chỉ nói "tôi tin account kia"; ai trong account đó thực sự dùng được role là do policy phía development quyết định. Deny tường minh cho nhóm Testers khoá chặt phần đó, và trong IAM thì deny luôn thắng allow.
3. Developer assume role đó để cập nhật bucket bên production.

Hai account, hai phía đều phải khai — đó chính là ý "cả trust policy lẫn identity policy cùng phải cho phép" mà câu này đang kiểm tra.

❌ Vì sao các phương án còn lại sai

B — dùng inline policy. Câu này mô tả đúng định nghĩa của inline policy: policy nhúng thẳng vào một identity, giữ quan hệ một-một, tránh gắn nhầm quyền sang identity khác. Nhưng đó chỉ là chuyện cách đóng gói policy, hoàn toàn không giải quyết bài toán cross-account. Dù có nhúng policy vào user bên development đi nữa, một identity policy ở account này không tự nó cấp quyền lên bucket của account khác — vẫn cần một role được account chứa tài nguyên tin tưởng. Phương án này trả lời lệch câu hỏi.

C — tạo role ở Development account, tin Production account. Đây là phương án gần đúng nhất và cũng dễ nhầm nhất, vì câu chữ gần như y hệt A, chỉ đảo ngược hai account. Nó hỏng ở chỗ: role được tạo bên development thì permissions policy của nó chỉ có nghĩa với tài nguyên trong phạm vi development, không cấp được quyền ghi lên bucket thuộc production. Đồng thời trust policy khai production là trusted entity nghĩa là cho người của production assume role — ngược đúng chiều di chuyển mà đề mô tả. Nhớ nguyên tắc: role sống ở nơi có tài nguyên, trust trỏ về nơi có người dùng.

D — tạo role đúng chỗ nhưng không deny Testers. Phần đầu của D giống hệt A và về mặt kỹ thuật là hoạt động được: developer vẫn assume role và cập nhật bucket. Nó thiếu đúng bước thứ hai. Vì trust policy khai cả Development account là trusted entity, Testers cũng nằm trong account đó, nên nếu identity policy của họ không bị chặn thì họ cũng có đường vào production. Với một câu thuộc Domain Security and Compliance, cấu hình rộng hơn mức cần thiết là cấu hình sai — least privilege bị vi phạm.

📌 Điểm cần nhớ

• Trong cross-account access, IAM role luôn được tạo ở account chứa tài nguyên; account chứa người dùng đóng vai trusted entity trong trust policy. Gặp hai phương án đảo account cho nhau thì cứ hỏi "bucket nằm ở đâu?".
• Truy cập cross-account cần hai phía cùng cho phép: trust policy ở phía tài nguyên (ai được assume) và identity policy ở phía người dùng (ai được gọi AssumeRole). Chỉ làm một phía là chưa đủ hoặc chưa an toàn.
• Khi đề cố tình nhắc tới một nhóm không cần quyền (ở đây là Testers), gần như chắc chắn đáp án đúng là phương án có xử lý giới hạn cho nhóm đó. Explicit deny thắng mọi allow trong IAM.
• Inline policy vs managed policy chỉ là cách gắn policy vào identity, không phải cơ chế cấp quyền xuyên account. Đừng chọn nó khi câu hỏi đang nói về hai account khác nhau.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một tình huống rất cụ thể: nhiều nhóm dùng chung một AWS CloudFormation template, mỗi nhóm tạo stack riêng, và tất cả đang chuẩn bị đợt cập nhật kế tiếp bằng cách thử nghiệm thay đổi qua change set. Đột nhiên toàn bộ change set biến mất, và câu hỏi yêu cầu chỉ ra nguyên nhân.

Cụm từ quyết định nằm ở chỗ: các change set bị mất chứ không phải stack bị hỏng, bị rollback hay resource bị xoá. Đề không hề nói stack gặp sự cố, không nói deployment thất bại, không nói có lỗi quyền hay lỗi hạn mức nào hiện ra. Chỉ có duy nhất một hiện tượng: change set không còn nữa, trong khi stack vẫn ở đó.

Chi tiết thứ hai cũng quan trọng: các nhóm đang ở giai đoạn chuẩn bị cho đợt deployment kế tiếp, nghĩa là có nhiều change set cùng tồn tại trên cùng một stack. Đó chính là điều kiện để hành vi mặc định của CloudFormation lộ ra.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng là C — một change set đã được execute thành công, và điều đó khiến CloudFormation xoá các change set còn lại.

Change set là bản xem trước: nó cho bạn thấy các thay đổi đề xuất sẽ tác động thế nào tới resource đang có — cái nào bị sửa, cái nào bị thay thế, cái nào bị xoá. CloudFormation chỉ thực sự đụng vào stack khi bạn execute change set. Nhờ vậy bạn có thể tạo nhiều change set song song trên cùng một stack để so sánh các phương án khác nhau trước khi chọn.

Điểm mấu chốt: mỗi change set được tính toán dựa trên trạng thái stack tại thời điểm nó được tạo. Khi một change set được execute thành công, stack chuyển sang trạng thái mới, và mọi change set khác gắn với stack đó lập tức không còn phù hợp — chúng mô tả delta so với một trạng thái không còn tồn tại. Vì vậy sau khi execute, CloudFormation tự động xoá toàn bộ change set gắn với stack đó. Đây là hành vi có chủ đích, không phải lỗi.

Áp vào tình huống: có nhóm nào đó đã bấm execute một change set. Stack cập nhật xong, và tất cả change set còn lại của stack đó bị dọn đi. Các nhóm khác mở console lên thì thấy "mất hết" — nhưng không có lỗi nào cả. Cách khắc phục cũng đơn giản: tạo lại change set trên trạng thái stack mới.

❌ Vì sao các phương án còn lại sai

A — Change set khi được validate đã vượt account limit của một resource nào đó, và vì stack không update được khi chạm limit nên CloudFormation xoá change set. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nó nghe rất "AWS". Nhưng nó sai ở tiền đề: change set không kiểm tra account limit. Change set chỉ so sánh template mới với stack hiện tại để suy ra danh sách thay đổi — nó không nói cho bạn biết stack có update thành công hay không. Vượt hạn mức tài khoản, sửa một resource không hỗ trợ update, hay thiếu quyền IAM đều là những thứ chỉ lộ ra lúc execute, và khi đó CloudFormation sẽ rollback stack về trạng thái cũ, chứ không phải âm thầm xoá change set.

B — CloudFormation đã rollback các change set trong lúc validate và xoá những set không hợp lệ. Sai vì change set không có khái niệm rollback. Rollback chỉ tồn tại ở nơi có thay đổi thật để hoàn tác. Change set chưa đụng vào một resource nào — nó thuần tuý là bản mô tả thay đổi dự kiến. Rollback chỉ xảy ra ở cấp stack, khi change set đã được execute và quá trình update thất bại giữa chừng; lúc đó stack quay về trạng thái trước đó. Phương án này ghép sai đối tượng: gán cơ chế của stack cho change set.

D — Một change set không hợp lệ đã được execute, khiến toàn bộ stack và change set bị xoá. Sai ở hai tầng. Thứ nhất, một change set không hợp lệ không đi tới bước provisioning — nó không tạo ra thay đổi resource nào, nên không thể là nguyên nhân. Thứ hai, đề bài chỉ nói change set bị mất, hoàn toàn không nói stack bị xoá. Phương án này thêm một hậu quả không có trong tình huống. Đây là distractor được dựng bằng cách phóng đại mức độ thiệt hại.

📌 Điểm cần nhớ

• Execute một change set thành công thì mọi change set còn lại của stack đó bị CloudFormation xoá tự động — vì chúng được tính trên trạng thái stack cũ, đã không còn áp dụng được. Đây là hành vi mặc định, không phải sự cố.
• Change set chỉ là bản xem trước, không phải bản kiểm tra tính khả thi. Nó không phát hiện việc vượt account limit, thiếu quyền IAM, hay resource không hỗ trợ update. Những lỗi đó chỉ xuất hiện lúc execute.
• Rollback thuộc về stack, không thuộc về change set. Change set chưa thay đổi gì nên không có gì để hoàn tác; khi update stack thất bại thì CloudFormation đưa stack về trạng thái trước đó.
• Khi đọc đề dạng tình huống, bám đúng hiện tượng được mô tả: ở đây là "change set biến mất" chứ không phải "stack bị xoá" hay "deployment thất bại". Phương án nào thêm hậu quả không có trong đề thường là distractor.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một EC2 Windows instance quan trọng, nằm sau một Auto Scaling Group (ASG), và có hai thuộc tính được đặt cùng lúc:

• DisableApiTermination — bật bảo vệ chống terminate.
• InstanceInitiatedShutdownBehavior — quyết định điều gì xảy ra khi lệnh shutdown phát ra từ bên trong hệ điều hành của instance.

Cụm từ quyết định đáp án là: "A developer has initiated shutdown from the instance using operating system commands" — tức lệnh shutdown đến từ trong OS, không phải từ console/CLI/API. Đi kèm với nó là chi tiết InstanceInitiatedShutdownBehavior đã được set cho instance này. Hai chi tiết đó gộp lại chính là ranh giới mà DisableApiTermination không vượt qua được.

Câu hỏi thực chất kiểm tra: bạn có biết DisableApiTermination bảo vệ được đường nào và không bảo vệ được đường nào hay không.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B — The instance will be terminated.

DisableApiTermination (termination protection) chỉ chặn việc terminate instance qua console, CLI hoặc API. Đây là hàng rào chống thao tác nhầm của con người/script gọi vào EC2 API, mặc định tắt, và có thể bật lúc launch, lúc instance đang chạy, hoặc lúc instance đang stopped (với instance dùng EBS làm gốc).

Điểm mấu chốt: thuộc tính này không ngăn việc terminate khi lệnh shutdown được phát từ chính hệ điều hành của instance, trong lúc InstanceInitiatedShutdownBehavior đang được đặt. Khi developer gõ lệnh shutdown trong Windows, EC2 xử lý theo hành vi đã cấu hình ở InstanceInitiatedShutdownBehavior chứ không hỏi tới DisableApiTermination — nên kết quả là instance bị terminate.

Nói gọn: lệnh đi qua "cửa API" thì bị chặn; lệnh đi qua "cửa OS" thì không.

❌ Vì sao các phương án còn lại sai

A — "Instance sẽ không shutdown vì DisableApiTermination đã được set". Đây là phương án gần đúng nhất và cũng là cái bẫy chính: nó đúng ở chỗ termination protection thật sự đang bật, nhưng sai ở phạm vi. Cờ này chỉ điều khiển việc terminate phát ra từ console/CLI/API; nó không có tác dụng gì với lệnh shutdown phát ra từ trong OS khi InstanceInitiatedShutdownBehavior đã được đặt. Hiểu nhầm ở đây là coi termination protection như một tấm khiên toàn diện, trong khi nó chỉ chắn đúng một hướng.

C — "ASG không thể terminate instance đang bật DisableApiTermination". Phát biểu này sai. DisableApiTermination không ngăn được EC2 Auto Scaling terminate instance. Chi tiết "instance nằm sau ASG" trong đề là thông tin gây nhiễu, dẫn dụ người làm bài đi tìm xung đột giữa ASG và termination protection, trong khi tình huống thực tế trong đề là lệnh shutdown từ OS chứ không phải ASG hành động.

D — "OS gửi thông báo Amazon SNS cho người phụ trách đã cấu hình khi bật DisableApiTermination, giữ shutdown vài phút rồi mới tiến hành". Phương án này hoàn toàn bịa. DisableApiTermination là một attribute boolean của instance, không có chỗ khai người nhận thông báo, không gắn với Amazon SNS, và cũng không có cơ chế "hoãn shutdown vài phút" nào. Hệ điều hành của instance cũng không phải nơi phát thông báo kiểu đó. Đây là distractor thuần tuý — dài, nghe có vẻ chi tiết, nhưng mô tả một tính năng không tồn tại.

📌 Điểm cần nhớ

• DisableApiTermination chỉ chặn terminate qua console, CLI, API. Lệnh shutdown phát từ bên trong OS nằm ngoài phạm vi của nó khi InstanceInitiatedShutdownBehavior đã được đặt.
• DisableApiTermination không ngăn EC2 Auto Scaling terminate instance — đừng coi nó là cách giữ instance khỏi vòng đời của ASG.
• Mặc định termination protection là tắt; có thể bật lúc launch, lúc đang chạy, hoặc lúc stopped (instance EBS-backed).
• Gặp phương án dài, mô tả một chuỗi hành vi lạ (tự gửi Amazon SNS, tự hoãn vài phút) gắn vào một attribute vốn chỉ là cờ bật/tắt — đó gần như luôn là distractor bịa ra.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một đội cần tạo AMI từ các Amazon EC2 instance đang chạy để dùng ở môi trường khác, rồi hỏi cách đúng để tạo ra một AMI application-consistent.

Cụm từ quyết định đáp án là "application-consistent". Đây không phải chữ trang trí — trong ngữ cảnh ảnh chụp EBS và AMI, AWS phân biệt rạch ròi hai mức nhất quán:

• Crash-consistent: mọi volume gắn vào instance được chụp tại cùng một thời điểm. Dữ liệu trên đĩa giống hệt như khi rút phích điện đột ngột — cấu trúc còn nguyên, nhưng phần đang nằm trong bộ đệm của hệ điều hành và của ứng dụng thì chưa kịp ghi xuống.
• Application-consistent: các buffer của operating system (và của ứng dụng) đã được flush xuống đĩa trước khi chụp, nên ảnh chụp phản ánh đúng trạng thái hoàn chỉnh của ứng dụng.

Khi tạo AMI trên trang Create image, EC2 có một cờ tên No reboot. Hành vi mặc định (tức là cờ này không được chọn) là: EC2 shut down instance, chụp snapshot các volume đang gắn, tạo và đăng ký AMI, rồi khởi động lại instance. Chính bước shut down đó là thứ ép hệ điều hành flush buffer xuống đĩa. Vậy câu hỏi thực chất là: muốn application-consistent thì bật hay tắt No reboot?

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là D — Create the AMI by disabling the No reboot option.

Tắt (không chọn) No reboot nghĩa là để EC2 chạy đúng quy trình mặc định: instance được shut down trước khi chụp snapshot. Trong lúc shut down, hệ điều hành flush toàn bộ buffer xuống đĩa và đưa hệ thống về trạng thái dừng sạch sẽ. Snapshot chụp sau thời điểm đó phản ánh dữ liệu đã hoàn tất ghi, nên AMI thu được là application-consistent — đúng thứ đề bài yêu cầu. Sau khi tạo và đăng ký AMI xong, EC2 tự khởi động lại instance.

Nói ngắn gọn: cái giá phải trả là một lần reboot ngắn (downtime), và đó chính là cái giá của tính nhất quán ở mức ứng dụng.

❌ Vì sao các phương án còn lại sai

A. Create the AMI with No reboot option enabled — Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó là lựa chọn nhiều người quen dùng trong thực tế để tránh downtime. Nhưng bật No reboot nghĩa là instance không bị shut down khi tạo AMI, nên buffer của operating system chưa được flush xuống đĩa trước lúc chụp. Kết quả là AMI crash-consistent (mọi volume được chụp cùng thời điểm) nhưng không application-consistent, và tính toàn vẹn dữ liệu có thể có vấn đề. Đây đúng là mặt trái mà đề bài đang loại trừ.

B. Create an EBS-backed AMI for application consistency — Sai vì nhầm lẫn hai chuyện khác nhau. EBS-backed AMI nói về kiểu lưu trữ gốc của AMI: instance tạo từ nó dùng persistent storage (volume EBS tồn tại độc lập với vòng đời instance). Điều đó hoàn toàn không quyết định buffer có được flush hay không. Ngay cả khi dùng EBS-backed AMI, bạn vẫn phải để No reboot ở trạng thái không chọn thì mọi thứ trên instance mới được dừng lại và ở trạng thái nhất quán trong quá trình tạo AMI. Chọn B là giải quyết đúng nửa vấn đề mà bỏ qua đúng cái nút quyết định.

C. Create the AMI with Delete on termination enabled — Hoàn toàn lạc đề, thuần tuý là distractor. Delete on termination chỉ quy định số phận của volume EBS khi bạn terminate instance được tạo ra từ AMI này: bật thì volume bị xoá cùng instance, tắt thì volume được giữ lại. Nó là thuộc tính về vòng đời và dọn dẹp tài nguyên, không liên quan gì tới thời điểm chụp snapshot hay việc flush buffer, nên không ảnh hưởng chút nào tới tính nhất quán của AMI.

📌 Điểm cần nhớ

• No reboot là công tắc nhất quán của AMI: không chọn (mặc định) → instance được shut down → application-consistent; chọn → không shut down → chỉ crash-consistent. Thấy chữ "application-consistent" trong đề là nghĩ ngay tới việc tắt No reboot.
• Đừng để chữ "enabled/disabled" đánh lừa: No reboot là cờ phủ định, nên "disable No reboot" = "có reboot" = có flush buffer. Đọc chậm hai lần trước khi chọn.
• Crash-consistent ≠ application-consistent. Crash-consistent chỉ bảo đảm các volume được chụp cùng thời điểm; nó không bảo đảm buffer của OS đã xuống đĩa.
• Phân biệt các thuộc tính theo đúng phạm vi của chúng: EBS-backed nói về kiểu lưu trữ và tính bền vững của volume, Delete on termination nói về việc dọn volume khi terminate — cả hai đều không phải cần gạt điều khiển tính nhất quán khi tạo AMI.

🧩 Phân tích nội dung câu hỏi

Đề mô tả một công ty dịch vụ CNTT chạy hạ tầng trên AWS, làm audit định kỳ và phát hiện phần lớn các nhóm không tuân thủ chuẩn về patch compliance. Câu hỏi yêu cầu chọn cách dễ và nhanh nhất để khắc phục.

Hai cụm từ trong đề quyết định đáp án:

• "patch compliance standards are not being followed" — vấn đề nằm đúng ở khâu vá lỗi (patching) và báo cáo mức độ tuân thủ vá lỗi, không phải quét lỗ hổng, không phải viết workflow vận hành chung.
• "The teams have however tagged all their AWS resources as per the guidelines" — chi tiết về tag không phải câu văn trang trí. Nó là gợi ý rằng dịch vụ được chọn phải biết nhóm instance theo tag để áp patch hàng loạt mà không phải liệt kê từng máy. Đó chính là cách patch group hoạt động.

Cả bốn phương án đều nói "automate the process of patching", nên phải phân biệt bằng tên dịch vụ có thật và đúng chức năng, chứ không bằng động từ trong câu.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B — Use AWS Systems Manager Patch Manager to automate the process of patching managed instances.

Patch Manager là thành phần của AWS Systems Manager sinh ra đúng cho bài toán này: tự động vá managed instances với cả bản vá bảo mật lẫn các loại cập nhật khác, cho cả hệ điều hành lẫn ứng dụng — cài Service Pack trên Windows, nâng minor version trên Linux, áp cho cả fleet EC2 lẫn máy chủ on-premises và VM, phân loại theo loại hệ điều hành.

Cơ chế của nó khớp trực tiếp với dữ kiện trong đề:

• Patch baseline chứa quy tắc tự duyệt bản vá sau một số ngày kể từ khi phát hành, kèm danh sách bản vá được duyệt và bị từ chối — tức là "chuẩn" mà audit đang đòi hỏi được mã hoá thành cấu hình.
• Có thể áp bản vá cho nhóm lớn instance bằng Amazon EC2 tag — đây là lý do đề nhấn mạnh mọi tài nguyên đã được gắn tag đúng hướng dẫn. Không phải làm gì thêm, dùng ngay tag sẵn có.
• Có thể lên lịch chạy như một maintenance window task, hoặc quét và vá theo yêu cầu bất cứ lúc nào.
• Patch Manager quét instance và báo cáo compliance theo lịch — đúng thứ audit cần để chứng minh đã tuân thủ.

Nó cũng tích hợp IAM, CloudTrail và EventBridge nên có thông báo sự kiện và dấu vết kiểm toán. Cộng lại: cấu hình sẵn có, không phải tự viết gì, đúng nghĩa "easy way, as quickly as possible".

❌ Vì sao các phương án còn lại sai

A — AWS Systems Manager Automation. Đây là phương án gần đúng nhất và là bẫy chính, vì nó cùng họ Systems Manager. Automation dùng để đơn giản hoá các tác vụ bảo trì và triển khai thường gặp trên EC2 và tài nguyên AWS khác: dựng workflow cấu hình và quản lý tài nguyên, dùng runbook do AWS duy trì hoặc tự viết, nhận thông báo qua EventBridge, theo dõi tiến trình trên console. Chỗ nó hỏng: Automation không phải dịch vụ quản lý bản vá — không có patch baseline, không có khái niệm patch compliance để báo cáo cho audit. Muốn dùng nó cho patching thì phải tự dựng workflow, tức là ngược lại với yêu cầu "dễ và nhanh nhất".

C — Amazon Patch Manager. Tên dịch vụ này không tồn tại; đây là distractor thuần tuý. Patch Manager là một capability bên trong AWS Systems Manager, nên tiền tố đúng phải là "AWS Systems Manager", không phải "Amazon". Đây là kiểu bẫy rất hay gặp: đổi tiền tố AWS/Amazon hoặc bỏ tên dịch vụ mẹ để tạo ra một cái tên nghe rất thật.

D — Amazon Inspector. Inspector là dịch vụ đánh giá bảo mật tự động, giúp cải thiện security và compliance cho ứng dụng chạy trên AWS bằng cách tự động rà soát exposure, lỗ hổng và những sai lệch so với best practice. Nó gần đúng ở chỗ có chữ "security and compliance" trong mô tả, nhưng chỗ hỏng rất rõ: Inspector chỉ phát hiện và báo cáo, không vá. Dùng Inspector thì công ty vẫn biết mình chưa tuân thủ — đúng thứ họ đã biết sau audit — mà lỗ hổng vẫn nguyên đó.

📌 Điểm cần nhớ

• Patching + compliance report = AWS Systems Manager Patch Manager. Đây là mapping cần thuộc lòng; thấy đề nói "patch compliance" thì gần như chắc chắn là nó.
• Phân biệt phát hiện và khắc phục. Amazon Inspector tìm ra vấn đề bảo mật; Patch Manager sửa vấn đề đó. Đề hỏi "fix the issue" thì loại ngay nhóm dịch vụ chỉ đánh giá.
• Trong họ Systems Manager, mỗi capability có phạm vi riêng. Automation lo workflow vận hành và triển khai chung, Patch Manager lo bản vá. Cùng tên mẹ không có nghĩa là thay thế được cho nhau.
• Đọc kỹ tiền tố tên dịch vụ. Amazon Patch Manager không tồn tại. Một cái tên nghe hợp lý nhưng sai tiền tố hoặc thiếu tên dịch vụ mẹ là dấu hiệu của distractor.
• Chi tiết "đã gắn tag đầy đủ" trong đề luôn có mục đích. Với Patch Manager, tag là cách gom instance thành nhóm để áp bản vá hàng loạt — dữ kiện đó đang xác nhận đáp án chứ không phải nhiễu.

🧩 Phân tích nội dung câu hỏi

Một ứng dụng streaming video dùng Amazon Kinesis Data Streams, và đội quản trị hệ thống cần được thông báo khi shard capacity sắp chạm giới hạn (service limit).

Cụm từ quyết định đáp án là "reaching its limits" — tức là chuyện ở đây không phải theo dõi lượng dữ liệu đang chảy qua stream, mà là theo dõi mức sử dụng so với hạn mức (service limit / quota) của tài khoản AWS, và cần báo trước khi chạm trần chứ không phải báo sau khi đã hỏng.

Hai chi tiết đó thu hẹp bài toán rất nhanh:

• Cần một nguồn dữ liệu biết hạn mức của dịch vụ là bao nhiêu và mình đang dùng bao nhiêu phần trăm của nó.
• Cần một cơ chế phản ứng theo sự kiện để khi trạng thái kiểm tra đó chuyển sang mức cảnh báo thì gửi thông báo đi.

Trong bốn phương án, chỉ một phương án ghép được đúng hai mảnh này.

✅ Vì sao đáp án đúng là đúng

Đáp án đúng theo tệp là B — Monitor Trusted Advisor service check results with Amazon CloudWatch Events.

AWS Trusted Advisor có nhóm kiểm tra service limits: nó đối chiếu mức sử dụng hiện tại của bạn với hạn mức của dịch vụ và chuyển trạng thái kiểm tra sang mức cảnh báo khi mức dùng vượt một ngưỡng cao so với hạn mức (tài liệu nguồn nêu ngưỡng 80% service limit). Kinesis Data Streams — cụ thể là số shard — nằm trong danh sách các hạn mức mà Trusted Advisor theo dõi. Đây chính là mảnh "biết hạn mức là bao nhiêu" mà đề cần.

Mảnh còn lại là Amazon CloudWatch Events: nó phát hiện và phản ứng với thay đổi trạng thái của các Trusted Advisor check. Bạn tạo rule bắt sự kiện khi status của check chuyển sang giá trị mình quan tâm (ví dụ chuyển sang trạng thái cảnh báo), rồi rule đó gọi một hoặc nhiều target — gửi thông báo, ghi lại thông tin trạng thái, hoặc kích hoạt hành động khắc phục.

Ghép lại: Trusted Advisor phát hiện shard capacity đang tiến sát hạn mức → status của check đổi → CloudWatch Events bắt sự kiện đó → thông báo cho đội quản trị hệ thống. Đúng nguyên văn yêu cầu của đề.

❌ Vì sao các phương án còn lại sai

A — CloudTrail sinh log cho service limits, rồi tích hợp CloudWatch để tạo alarm. Đây là phương án nghe hợp lý nhất trong ba cái sai, vì CloudTrail thật sự tích hợp với CloudWatch Logs và người ta thật sự hay dựng metric filter + alarm trên đó. Chỗ hỏng nằm ở nguồn dữ liệu: CloudTrail ghi lại hoạt động trên tài khoản — ai gọi API nào, lúc nào, từ đâu — phục vụ governance, compliance, kiểm toán vận hành và kiểm toán rủi ro. Nó không theo dõi service limit. CloudTrail có thể cho bạn biết ai đã gọi lệnh tạo thêm shard, nhưng không biết hạn mức shard của tài khoản là bao nhiêu, cũng không biết bạn đang dùng bao nhiêu phần trăm của hạn mức đó. Không có dữ liệu gốc thì alarm dựng trên nó cũng vô nghĩa.

C — Dùng CloudWatch ServiceLens để theo dõi service limits của các dịch vụ AWS. ServiceLens là công cụ observability: nó gom trace, metric, log và alarm về một chỗ để bạn nhìn ứng dụng của mình một cách xuyên suốt. Nó hiển thị alarm chứ không tự sinh ra dữ liệu về hạn mức — nói cách khác, ServiceLens chỉ dùng được sau khi đã có alarm định nghĩa trong CloudWatch, chứ không thay thế được bước đó. Phương án này lẫn giữa "nơi trình bày" và "nơi phát hiện".

D — Cấu hình CloudWatch Events lấy dữ liệu từ Amazon Inspector. Nửa đầu đúng (CloudWatch Events đúng là cơ chế phản ứng theo sự kiện), nhưng nguồn sự kiện sai hoàn toàn. Amazon Inspector là dịch vụ đánh giá bảo mật tự động: kiểm tra khả năng truy cập mạng tới các instance EC2 và tình trạng bảo mật của ứng dụng chạy trên đó. Nó thuộc lĩnh vực bảo mật, không liên quan gì tới hạn mức dịch vụ hay shard của Kinesis. Ghép đúng "động cơ" với sai "nhiên liệu" thì vẫn không chạy tới đích.

📌 Điểm cần nhớ

• Đề nhắc tới service limit / quota sắp chạm trần → nghĩ ngay tới Trusted Advisor, đó là dịch vụ duy nhất trong nhóm này biết hạn mức và mức sử dụng so với hạn mức.
• CloudWatch Events là lớp phản ứng theo sự kiện — nó bắt thay đổi trạng thái của Trusted Advisor check rồi kích hoạt thông báo hoặc hành động khắc phục. Mẫu "Trusted Advisor phát hiện + CloudWatch Events phản ứng" lặp lại rất nhiều trong các câu hỏi kiểu này.
• Phân biệt rạch ròi vai trò từng dịch vụ để loại nhanh: CloudTrail = kiểm toán hoạt động API; Inspector = đánh giá bảo mật; ServiceLens = trình bày và tương quan trace/metric/log/alarm đã có. Không cái nào là nguồn dữ liệu về hạn mức.
• Khi một phương án gồm hai vế, hãy soi từng vế: phương án D đúng vế cơ chế nhưng sai vế nguồn dữ liệu, và chỉ cần sai một vế là cả phương án hỏng.