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

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

Một AWS Lambda viết bằng Python chạy hằng đêm để tắt tất cả EC2 instance nhằm tiết kiệm chi phí. Nhưng có một số instance "critical" không được phép tắt, vì ứng dụng bên trong rơi vào trạng thái không ổn định sau đó. Câu hỏi: làm sao ngăn việc tắt các instance quan trọng đó một cách hiệu quả.

Cụm từ quyết định là "efficiently" (hiệu quả) — chứ không phải "làm sao chặn được". Cả bốn phương án đều chặn được theo nghĩa nào đó; điều phân biệt chúng là chi phí vận hành mỗi khi danh sách instance thay đổi. Vế thứ hai cần chú ý là bối cảnh động ngầm định: instance mới sẽ được tạo ra trong tương lai. Lời giải đúng phải là thứ không bắt bạn quay lại sửa Lambda, sửa cấu hình, hay sửa danh sách mỗi lần thêm/xoá một máy.

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

C — Gắn tag cho EC2 instance và để script Lambda bỏ qua instance nào có tag đó.

Tag là nhãn gắn trực tiếp lên tài nguyên AWS, gồm một key và một value tuỳ chọn do bạn tự định nghĩa. Tag sinh ra đúng để phân loại tài nguyên theo mục đích, chủ sở hữu, môi trường — và ở đây là theo "được phép tắt hay không".

Điểm mấu chốt: thông tin nằm ngay trên instance, không nằm ở chỗ khác. Lambda chỉ cần một logic cố định — liệt kê instance, đọc tag, thấy tag "không tắt" thì continue. Logic đó viết một lần và không bao giờ phải sửa nữa. Khi ai đó tạo instance critical mới, họ gắn tag ngay lúc tạo (thường là tự động qua launch template, CloudFormation hoặc Terraform), và Lambda tự động tôn trọng nó ở lần chạy kế tiếp. Không có bước "nhớ đi cập nhật danh sách" — mà chính bước bị quên đó mới là thứ làm instance quan trọng bị tắt nhầm.

Đó là ý nghĩa của "efficiently" trong đề: quyền quyết định được đặt cạnh tài nguyên, nên nó tự bảo trì.

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

A — Dùng environment variable của Lambda chứa danh sách instance không được tắt. Đây là phương án gần đúng nhất và về mặt kỹ thuật thì chạy được. Nó hỏng ở chỗ: environment variable thuộc cấu hình phiên bản của function. Mỗi lần thêm, xoá hay thay instance, bạn phải sửa cấu hình Lambda và triển khai lại — tức là mỗi thay đổi hạ tầng lại kéo theo một thay đổi trên function. Danh sách instance ID cũng là thứ dễ mục nát: instance bị thay thế thì ID cũ vẫn nằm đó, còn ID mới thì chưa ai thêm vào.

D — Lưu các instance ID không được tắt trong SSM Parameter Store. Khá hơn A ở chỗ tách dữ liệu ra khỏi code, nên đổi danh sách không cần deploy lại Lambda. Nhưng lỗi cốt lõi vẫn nguyên vẹn: vẫn là một danh sách phải bảo trì tay ở nơi tách rời khỏi instance. Người tạo instance mới phải nhớ mở Parameter Store ra sửa; quên là instance bị tắt. Bạn chỉ đổi chỗ chứa danh sách chứ không xoá bỏ được bước thủ công.

B — Đổi shutdown behavior của EC2 instance và bật termination protection. Sai cả về cơ chế lẫn về vận hành. Termination protection chống terminate (huỷ hẳn instance), trong khi Lambda ở đây làm việc stop/shutdown — hai thao tác khác nhau, nên biện pháp này không nhắm đúng thứ cần chặn. Ngoài ra nó cũng là thiết lập phải bật/tắt tay trên từng instance mỗi lần đội hình máy thay đổi, nên kể cả bỏ qua nhầm lẫn về cơ chế thì vẫn thua tag về mặt "efficiently".

📌 Điểm cần nhớ

• Khi đề hỏi cách "efficiently" loại trừ một nhóm tài nguyên khỏi automation, tag gần như luôn là đáp án: metadata đi cùng tài nguyên, automation đọc metadata, không ai phải bảo trì danh sách.
• Danh sách instance ID viết tay là một anti-pattern trong câu hỏi thi, dù cất ở environment variable hay Parameter Store — cả hai đều đòi một bước thủ công mà con người sẽ quên.
• Phân biệt rõ stop và terminate: termination protection không ngăn được việc stop instance.
• Environment variable của Lambda gắn với version cấu hình của function, nên sửa nó nghĩa là đụng vào chính function — kém hơn hẳn dữ liệu cấu hình đọc lúc runtime, và kém hơn nữa so với metadata gắn thẳng lên tài nguyên.

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

Đề mô tả một VPC đã dựng sẵn cả bốn thành phần mạng: Internet Gateway, NAT Gateway, Egress Only Internet Gateway và Virtual Private Gateway. Việc phải làm chỉ là sửa route table cho đúng, chứ không phải tạo thêm thứ gì.

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

• "private subnet instances" — instance nằm trong subnet riêng tư, tức là nó không có public IP và không được phép để Internet chủ động mở kết nối vào. Đây là chỗ loại Internet Gateway: gắn IGW vào route table của một subnet chính là biến subnet đó thành public subnet.
• "IPv4 access to the internet" — chữ IPv4 là ràng buộc phân biệt còn lại. Nó tách NAT Gateway ra khỏi Egress Only Internet Gateway, vì hai thứ này có vai trò logic giống hệt nhau (cho ra Internet, chặn chiều vào) nhưng khác nhau ở họ địa chỉ.

Ghép hai ràng buộc đó lại thì chỉ còn đúng một lựa chọn.

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

Đáp án đúng là A — thêm route 0.0.0.0/0 trỏ tới NAT Gateway.

NAT Gateway sinh ra đúng để phục vụ tình huống này: cho phép instance trong private subnet đi ra Internet hoặc gọi các dịch vụ AWS khác, nhưng ngăn Internet khởi tạo kết nối ngược vào instance đó. Bản thân NAT Gateway đặt trong public subnet và mang một Elastic IP; instance ở private subnet gửi gói tin ra ngoài, NAT Gateway thay địa chỉ nguồn bằng địa chỉ công khai của nó rồi chuyển tiếp đi.

Để dòng chảy đó xảy ra, route table của private subnet phải có một entry mặc định 0.0.0.0/0 trỏ tới NAT Gateway — 0.0.0.0/0 nghĩa là "mọi đích IPv4 không khớp route nào cụ thể hơn thì đi lối này". Đúng như phần giải thích gốc nêu: phải dùng NAT Gateway đặt ở public subnet, và phải đặt entry tương ứng trong route table của private subnet.

Vài đặc điểm của NAT Gateway đáng ghi nhớ kèm theo: nó hỗ trợ TCP, UDP và ICMP; gắn được đúng một Elastic IP; không gắn được security group (muốn lọc thì dùng network ACL của subnet chứa nó); băng thông tự co giãn theo tải; và có tính phí cả theo giờ lẫn theo lượng dữ liệu xử lý.

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

B — 0.0.0.0/0 tới Egress Only Internet Gateway. Đây là phương án gần đúng nhất về mặt ý niệm: egress-only internet gateway cũng cho ra Internet mà chặn chiều vào, đúng tinh thần "private subnet". Nhưng nó chỉ dùng cho traffic IPv6, trong khi đề hỏi thẳng về IPv4. Ngoài ra bản thân prefix 0.0.0.0/0 là ký hiệu của IPv4 — với IPv6 thì route mặc định phải viết là ::/0. Vậy phương án này sai cả ở thiết bị lẫn ở dạng địa chỉ.

C — 10.0.0.0/12 tới Virtual Private Gateway. Sai ở cả hai vế. Virtual Private Gateway là đầu phía Amazon VPC của một kết nối VPN — nó dẫn traffic về mạng on-premises, không liên quan gì tới việc ra Internet. Còn đích 10.0.0.0/12 là dải địa chỉ private (RFC 1918), tức là route này chỉ định tuyến cho traffic nội bộ chứ không phải cho "the internet". Chọn nó thì instance vẫn không ra được Internet.

D — 0.0.0.0/0 tới Internet Gateway. Đây là cái bẫy chính, vì Internet Gateway đúng là cổng ra Internet cho IPv4 và đề cũng nói đã dựng sẵn nó. Vấn đề là đặt route đó ở đâu: entry 0.0.0.0/0 → IGW thuộc về route table của public subnet. Gắn nó vào route table của private subnet là tự tay biến subnet đó thành public — mà instance ở đó lại không có public IP nên vẫn không đi ra được, đồng thời phá luôn ý nghĩa "riêng tư" mà đề đang muốn giữ. Đường ra IPv4 hợp lệ cho private subnet phải đi qua NAT Gateway, chứ không trỏ thẳng IGW.

📌 Điểm cần nhớ

• Định nghĩa public/private subnet nằm ở route table, không nằm ở tên gọi: subnet có route 0.0.0.0/0 trỏ tới Internet Gateway là public, còn trỏ tới NAT Gateway là private.
• NAT Gateway = IPv4, Egress Only Internet Gateway = IPv6. Hai thứ cùng một mục đích (ra được, vào không được), chỉ khác họ địa chỉ — nên hễ đề nhắc IPv4 hay IPv6 thì đó chính là từ khoá chọn đáp án.
• Nhìn cả target lẫn destination của route. 0.0.0.0/0 là route mặc định IPv4, ::/0 là route mặc định IPv6, còn các dải như 10.0.0.0/12 là địa chỉ private — chúng không bao giờ mô tả "đi ra Internet".
• Virtual Private Gateway thuộc về VPN/on-premises, xuất hiện trong đề mạng chủ yếu như phương án nhiễu khi câu hỏi nói về Internet.
• NAT Gateway không gắn được security group; muốn kiểm soát traffic quanh nó thì dùng network ACL của subnet chứa nó.

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

Một công ty y tế có máy chủ ở hai nơi: trung tâm dữ liệu riêng (giữ lại vì lý do tuân thủ HIPAA) và các instance trên AWS để chạy big data analysis. Yêu cầu của CTO là tất cả máy — cả on-premises lẫn trên cloud — phải được quản lý bằng cùng một bộ Puppet module.

Cụm từ quyết định đáp án là "managed using the same Puppet modules", đi kèm với bối cảnh hai môi trường (on-premises + AWS). Đề không hỏi về bảo mật, không hỏi về tài liệu tuân thủ, mà hỏi đúng một chuyện: dịch vụ AWS nào cho phép dùng Puppet để cấu hình máy ở cả hai nơi. Chú ý là đề hỏi "Which AWS service" — đây là ràng buộc thứ hai, loại thẳng những thứ không phải dịch vụ của AWS. Riêng chữ HIPAA ở đây chỉ để giải thích vì sao vẫn còn máy tại chỗ, nó là chi tiết dựng cảnh chứ không phải điều kiện chọn đáp án — đọc lướt rất dễ bị nó kéo sang hướng compliance.

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

C – OpsWorks.

AWS OpsWorks là dịch vụ configuration management cung cấp bản managed của Chef và Puppet. Cụ thể, AWS OpsWorks for Puppet Enterprise dựng sẵn một Puppet Enterprise server được quản lý, kèm bộ công cụ tự động hoá cho orchestration, provisioning tự động và khả năng theo dõi truy vết.

Điểm khớp chính xác với đề: OpsWorks cho phép dùng Chef/Puppet để tự động hoá việc cấu hình, triển khai và quản lý máy trên Amazon EC2 instance lẫn môi trường tính toán on-premises. Puppet Master lưu tập trung các configuration task và phân phát chúng xuống từng node trong hệ thống, quy mô từ vài node tới hàng nghìn node. Nhờ vậy công ty giữ nguyên bộ Puppet module đang có và áp cùng một bộ đó cho cả data center riêng lẫn AWS — đúng yêu cầu của CTO. Puppet Enterprise server ở đây lo được cả các việc vận hành như cài đặt phần mềm, cấu hình hệ điều hành, cài package, thiết lập database.

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

A – Ansible. Đây là phương án gần đúng nhất và cũng là cái bẫy chính. Ansible đúng là công cụ provisioning, configuration management và application deployment mã nguồn mở theo hướng infrastructure as code — cùng hạng mục với Puppet. Nhưng nó hỏng ở hai chỗ: thứ nhất, Ansible không phải một AWS service, trong khi đề hỏi rõ dịch vụ AWS; thứ hai và quan trọng hơn, Ansible không chạy được Puppet module. Đề không nói "quản lý cấu hình tập trung" chung chung mà nói đích danh "cùng bộ Puppet module", nên một công cụ dùng playbook riêng của nó không đáp ứng được ràng buộc đó.

B – Artifact. AWS Artifact là cổng self-service để tải về tài liệu tuân thủ của AWS và các thoả thuận (agreement) với AWS. Nó thuần tuý là nơi lấy giấy tờ audit. Không dùng Artifact để triển khai patch lên instance được, càng không dùng nó để quản lý instance bằng Puppet module. Phương án này ăn theo chữ "HIPAA compliance" trong đề — ai đọc thấy chữ compliance rồi chọn luôn là trúng bẫy, vì compliance ở đây chỉ giải thích lý do tồn tại của data center riêng.

D – GuardDuty. Amazon GuardDuty là dịch vụ threat detection: giám sát liên tục để bảo vệ tài khoản, workload và dữ liệu lưu trên Amazon S3. Nó phân tích luồng metadata sinh ra từ hoạt động tài khoản và mạng trong AWS CloudTrail Events, Amazon VPC Flow Logs và DNS Logs, kết hợp threat intelligence, phát hiện bất thường và machine learning để nhận diện mối đe doạ. Đây là công cụ phát hiện, hoàn toàn không có chức năng cấu hình máy, nên không thể dùng để quản lý instance bằng Puppet module.

📌 Điểm cần nhớ

• Thấy Chef hoặc Puppet trong đề thi AWS thì nghĩ ngay tới OpsWorks — đó là dịch vụ AWS duy nhất cung cấp bản managed của hai nền tảng này.
• OpsWorks quản lý được cả EC2 lẫn máy on-premises, nên nó là câu trả lời chuẩn cho các tình huống hybrid đòi "cùng một bộ công cụ cấu hình cho hai môi trường".
• Đọc kỹ chữ "AWS service" trong đề: những công cụ mã nguồn mở nổi tiếng (Ansible, Terraform, Jenkins…) hay được cài vào làm mồi nhử, và chúng bị loại ngay từ tiêu chí này.
• Chi tiết compliance (HIPAA, PCI, GDPR) trong phần dựng cảnh thường không phải điều kiện chọn đáp án — nó chỉ giải thích bối cảnh. Đừng vì thấy chữ compliance mà chọn Artifact, dịch vụ này chỉ để tải tài liệu audit chứ không tác động gì lên instance.

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

Đề mô tả một công ty đang chạy tape backup (sao lưu ra băng từ) tại chỗ và muốn chuyển dần lên cloud để tận dụng dung lượng của S3, nhưng kèm hai ràng buộc rất cứng:

• "while keeping the same processes" — giữ nguyên quy trình sao lưu đang có, không viết lại luồng vận hành;
• "iSCSI-compatible backup software you purchased a 10-year license for" — phần mềm sao lưu đã mua bản quyền 10 năm, nói chuyện qua giao thức iSCSI.

Cụm quyết định là "tape backup processes" đi cùng với "iSCSI-compatible backup software". Nó không hỏi "làm sao đưa dữ liệu lên S3" một cách chung chung — nếu vậy thì nhiều phương án đều đúng. Nó hỏi: cái gì cho phép phần mềm sao lưu vẫn tưởng mình đang ghi ra băng từ, trong khi thực tế dữ liệu nằm trên S3. Thấy "tape" trong đề mà lại có một phương án mang đúng chữ "Tape" thì đó chính là ràng buộc phân biệt.

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

Đáp án đúng theo tệp là C — Tape Gateway.

Tape Gateway là cấu hình của AWS Storage Gateway chuyên để thay băng từ vật lý tại chỗ bằng băng ảo (virtual tape) trên AWS mà không phải đổi luồng sao lưu hiện có. Nó trình ra một thư viện băng ảo (virtual tape library) qua iSCSI, đúng giao thức mà phần mềm sao lưu trong đề đang dùng — nên bản quyền 10 năm kia không bị phí, quy trình vận hành giữ nguyên, chỉ có "băng" là ảo.

Ba điểm nữa khớp thẳng với yêu cầu của đề:

• Nó hỗ trợ các phần mềm sao lưu phổ biến, tức là không đòi công ty đổi công cụ.
• Nó cache băng ảo tại chỗ để truy cập dữ liệu có độ trễ thấp.
• Nó mã hoá dữ liệu trên đường truyền giữa gateway và AWS, nén dữ liệu, và chuyển băng ảo giữa Amazon S3 và S3 Glacier / S3 Glacier Deep Archive để giảm chi phí lưu trữ — đúng mục tiêu "leverage the S3 storage capacity".

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

A — File Gateway. Đây cũng là Storage Gateway và cũng đưa dữ liệu vào S3, nên trông rất gần đúng. Nhưng nó xuất ra giao diện file qua SMB hoặc NFS, không phải iSCSI và không phải băng ảo. Phần mềm sao lưu trong đề nói chuyện bằng iSCSI với một thư viện băng — nó không tự chuyển sang ghi file lên một share SMB/NFS được. File Gateway hợp cho ứng dụng cần truy cập file trên S3 (kể cả ứng dụng chạy trên EC2), chứ không dùng để phục vụ quy trình tape backup.

B — Volume Gateway. Đây là phương án gây nhầm nhiều nhất, vì nó đúng nửa yêu cầu: Volume Gateway trình ra block storage volume qua iSCSI cho ứng dụng tại chỗ, giữ cache hoặc nguyên volume tại chỗ và lưu bản đầy đủ trên cloud, kèm EBS Snapshot để backup / disaster recovery / migration. Đúng giao thức iSCSI — nhưng sai đối tượng: cái nó xuất ra là ổ đĩa, không phải băng. Phần mềm sao lưu chuyên tape điều khiển thư viện băng (nạp băng, tháo băng, ghi tuần tự), nó không nhìn một block volume như một con băng. Giữ được giao thức mà mất nguyên mô hình tape thì "same processes" trong đề vẫn gãy.

D — Snowball. Sai cả về bản chất lẫn về thời gian. Snowball thuộc AWS Snow Family, là thiết bị di chuyển dữ liệu và tính toán biên, dùng để chuyển một khối lượng lớn dữ liệu lên AWS một cách an toàn và nhanh — bản Storage Optimized còn có cả block storage và object storage tương thích S3, vCPU, dùng tốt cho lưu trữ tại chỗ và truyền dữ liệu quy mô lớn. Nhưng đó là hoạt động một lần, gửi thiết bị đi rồi nhận về, chứ không phải một đường sao lưu chạy đều đặn hằng ngày. Nó cũng không trình ra thư viện băng qua iSCSI cho phần mềm sao lưu, nên không phục vụ được quy trình tape backup.

📌 Điểm cần nhớ

• Bốn cấu hình của Storage Gateway phân biệt nhau ở giao diện xuất ra tại chỗ, không phải ở "có lên S3 hay không": File Gateway → SMB/NFS; Volume Gateway → block qua iSCSI; Tape Gateway → virtual tape library qua iSCSI. Đọc đề, tìm xem ứng dụng đang nói chuyện bằng giao thức nào.
• Chữ "tape" trong đề kèm yêu cầu giữ nguyên phần mềm/quy trình sao lưu gần như luôn dẫn thẳng tới Tape Gateway — vì đó chính là lý do dịch vụ này tồn tại.
• Riêng "iSCSI" chưa đủ để chọn: cả Volume Gateway lẫn Tape Gateway đều dùng iSCSI. Phải ghép thêm chi tiết ổ đĩa hay băng từ mới tách được hai phương án.
• Snow Family là di chuyển dữ liệu một lần, không phải kênh sao lưu định kỳ. Đề nào nhấn "quy trình đang chạy", "hằng ngày", "giữ nguyên luồng" thì Snowball thường là mồi nhử.
• Tape Gateway còn tự chuyển băng ảo xuống S3 Glacier / Glacier Deep Archive, nên nó là câu trả lời cho cả nhóm đề gộp tape backup + lưu trữ dài hạn giá rẻ.

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

Đề mô tả một tình huống vận hành khẩn: có lỗ hổng trong Windows OS bị khai thác, bản vá (patch) vừa được phát hành và cần áp dụng càng sớm càng tốt lên tất cả các instance.

Cụm từ quyết định đáp án là "a new Windows patch... needs to be applied" — động từ ở đây là apply/deploy, tức thực thi một hành động cài đặt lên hệ điều hành bên trong instance. Kèm theo là "to all your instances": phải làm hàng loạt, không phải RDP vào từng máy.

Hai yêu cầu đó gộp lại loại bỏ mọi dịch vụ chỉ biết quan sát, đánh giá hay cung cấp tài liệu. Trong bốn phương án, chỉ có đúng một dịch vụ thực sự chạy được lệnh bên trong hệ điều hành của instance. Đây chính là cái bẫy cổ điển của nhóm câu này: các phương án sai đều là dịch vụ liên quan tới bảo mật/tuân thủ, nghe rất hợp ngữ cảnh "bị hacker tấn công", nhưng không có phương án nào trong số đó tác động lên instance được.

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

A — Deploy the patch using Systems Manager.

AWS Systems Manager cho bạn khả năng nhìn thấy và điều khiển hạ tầng của mình. Nó gom dữ liệu vận hành từ nhiều dịch vụ AWS về một giao diện thống nhất, và quan trọng hơn là cho phép tự động hoá các tác vụ vận hành: chạy lệnh, quản lý bản vá, cấu hình máy chủ — trên cả hạ tầng trong AWS lẫn hạ tầng on-premises.

Thành phần trực tiếp giải quyết câu hỏi này là Patch Manager: nó giúp chọn và triển khai bản vá hệ điều hành cùng bản vá phần mềm tự động trên các nhóm lớn instance EC2 hoặc on-premises. Thông qua patch baseline, bạn đặt quy tắc tự động phê duyệt theo nhóm bản vá (ví dụ bản vá hệ điều hành, hoặc bản vá mức nghiêm trọng cao), đồng thời chỉ định danh sách bản vá cụ thể để ghi đè các quy tắc đó — chấp thuận hoặc từ chối thẳng.

Với tình huống trong đề, Systems Manager đáp ứng đủ cả hai vế: nó triển khai được bản vá, và nó làm việc đó theo nhóm resource thay vì từng máy một. Systems Manager hỗ trợ vá cho cả instance chạy Windows lẫn Linux, nên việc đề nói rõ là Windows không hề làm hẹp lựa chọn này.

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

B — Patch the instances directly from the AWS Config interface. AWS Config là dịch vụ để đánh giá, kiểm toán (audit) và thẩm định cấu hình của các resource AWS. Với Config bạn xem được thay đổi cấu hình theo thời gian, xem quan hệ giữa các resource, đào vào lịch sử cấu hình chi tiết, và xác định mức tuân thủ so với chuẩn nội bộ của mình. Đây là phương án gần đúng nhất về mặt cảm giác, vì Config phát hiện được instance nào lệch chuẩn — nhưng nó dừng lại ở đó. Config trả lời câu hỏi "resource của tôi trông như thế nào tại thời điểm xyz", chứ không dùng để triển khai bản vá lên instance. Chỗ hỏng nằm ở chữ "directly from the AWS Config interface": không có giao diện nào như vậy.

C — Use Artifact. AWS Artifact là cổng tự phục vụ để tải tài liệu kiểm toán — nơi khách hàng lấy theo yêu cầu các tài liệu tuân thủ của AWS và các thoả thuận với AWS. Nó thuộc phạm trù giấy tờ pháp lý/tuân thủ, không đụng gì tới hệ điều hành. Bạn không thể dùng Artifact để triển khai bản vá lên instance. Phương án này chỉ có mặt vì chữ "compliance" hay đi chung ngữ cảnh bảo mật.

D — Deploy it using Amazon Inspector. Amazon Inspector là dịch vụ đánh giá bảo mật tự động, giúp kiểm tra khả năng tiếp cận qua mạng (network accessibility) của các instance EC2 và trạng thái bảo mật của ứng dụng chạy trên đó. Đây là phương án dễ chọn nhầm nhất: nó đúng là dịch vụ tìm ra lỗ hổng — tức là thứ đã cảnh báo bạn về đúng lỗ hổng Windows trong đề. Nhưng nó hỏng ở chính động từ của câu hỏi: Inspector báo cáo vấn đề, chứ không thể dùng để triển khai bản vá lên instance. Phát hiện và khắc phục là hai việc do hai dịch vụ khác nhau đảm nhiệm.

📌 Điểm cần nhớ

• Đọc kỹ động từ của đề: deploy / apply / remediate / run đòi một dịch vụ tác động được vào bên trong instance; assess / audit / evaluate / detect thì chỉ cần dịch vụ quan sát. Đây thường là ràng buộc duy nhất phân biệt các phương án.
• Systems Manager là công cụ vận hành hành động: chạy lệnh, quản lý bản vá qua Patch Manager và patch baseline, cấu hình máy chủ — theo nhóm, cho cả Windows lẫn Linux, cả trên AWS lẫn on-premises.
• Amazon Inspector tìm lỗ hổng, AWS Config kiểm toán cấu hình — cả hai đều là bên phát hiện, không phải bên khắc phục. Thấy đề yêu cầu sửa chữa mà phương án là hai dịch vụ này thì loại.
• AWS Artifact chỉ là nơi lấy tài liệu tuân thủ và thoả thuận với AWS; hễ đề nói về thao tác kỹ thuật lên resource thì Artifact luôn sai.

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

Đề mô tả một Application Load Balancer (ALB) đang định tuyến từng request một cách độc lập tới các registered target theo thuật toán load-balancing đã chọn. Nhóm phát triển muốn các server giữ được state information để mang lại trải nghiệm liên tục cho người dùng cuối.

Cụm từ quyết định nằm ngay trong câu hỏi cuối: "the correct way to configure the required session affinity". Đây chính là tên gọi khác của sticky sessions trên ALB. Cụm thứ hai cũng rất then chốt: "routes each request independently" — đó là mô tả hành vi mặc định của ALB, và bài toán đặt ra là làm sao phá vỡ hành vi mặc định đó để mọi request trong một phiên đều đi về cùng một target.

Khi đề bài đã dùng đúng thuật ngữ session affinity, việc còn lại chỉ là biết tính năng tương ứng của ALB tên là gì — chứ không phải chọn giải pháp lưu state ở tầng ứng dụng.

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

A — Enable Stickiness on the Application Load Balancer.

Theo mặc định, ALB gửi mỗi request tới một target được chọn độc lập. Tính năng sticky session (session affinity) cho phép load balancer ràng buộc phiên của một user vào một target cụ thể, đảm bảo toàn bộ request trong phiên đó đều được gửi tới đúng target đã chọn. Đây chính xác là kịch bản mà đề mô tả: server cần giữ state để trải nghiệm không bị đứt quãng.

Vài điểm cần lưu ý về cách tính năng này hoạt động:

• Client phải hỗ trợ cookie thì stickiness mới dùng được — cơ chế bám phiên dựa trên cookie do load balancer quản lý.
• ALB hỗ trợ cả duration-based cookies và application-based cookies.
• Stickiness được bật ở mức target group, không phải ở mức listener hay mức load balancer nói chung. Bạn có thể phối hợp duration-based, application-based và không stickiness trên các target group khác nhau.
• Điều cần quyết định khi cấu hình là giữ phiên bám vào một target trong bao lâu.

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

B — Enable X-Forwarded-For header which can be used to store cookies on the server.

X-Forwarded-For là request header được ALB tự động thêm vào, và mục đích của nó hoàn toàn khác: vì load balancer đứng chắn giữa client và server nên access log của server chỉ thấy IP của load balancer; X-Forwarded-For giúp bạn nhìn ra IP thật của client. Nó là header dùng để nhận diện nguồn gốc request, không phải cơ chế lưu cookie và không tạo ra bất kỳ ràng buộc phiên nào. Vế "can be used to store cookies on the server" trong phương án này là mô tả sai về chức năng của header.

C — Enable Connection Draining on the Application Load Balancer.

Đây là phương án gần đúng nhất về mặt "nghe có vẻ liên quan tới việc giữ kết nối", nên rất dễ bẫy. Nhưng connection draining giải quyết một bài toán khác hẳn: khi một instance đang de-register hoặc bị đánh giá unhealthy, connection draining khiến load balancer ngừng gửi request mới tới instance đó nhưng vẫn giữ các kết nối đang có để những request đang dở dang được hoàn tất; bạn khai báo thời gian tối đa giữ kết nối trước khi instance được báo là đã de-register.

Nói cách khác, nó lo cho thời điểm target rời khỏi đội hình, chứ không hề buộc các request của cùng một user đi về cùng một target trong lúc hệ thống chạy bình thường. Bật connection draining thì ALB vẫn tiếp tục phân phối từng request độc lập, và state trên server vẫn bị mất.

D — Enable Cookies on all the Application Load Balancer targets.

Phương án này lật ngược đúng chỗ cần bật. Cookie được bật ở phía client, không phải phía server. Bạn không "enable cookies" trên các target đứng sau ALB được. Đúng là sticky session có dùng cookie, nhưng cookie đó do load balancer quản lý và do trình duyệt client lưu giữ — nên cấu hình phải nằm ở tính năng stickiness của ALB, chứ không phải một thao tác nào đó trên từng target.

📌 Điểm cần nhớ

• "Session affinity" = "sticky sessions" — thấy đề nhắc tới việc giữ state cho user hoặc "cùng một user phải về cùng một server", nghĩ ngay tới Stickiness của ALB.
• Stickiness bật ở mức target group, và yêu cầu client hỗ trợ cookie; ALB có cả duration-based lẫn application-based cookie.
• Connection draining ≠ stickiness. Draining lo cho request đang dở khi target de-register hoặc unhealthy; stickiness lo cho việc gắn phiên vào một target trong lúc vận hành bình thường.
• X-Forwarded-For chỉ để lấy IP thật của client khi request đi qua load balancer — không liên quan gì tới lưu state hay bám phiên.
• Hành vi mặc định của ALB luôn là định tuyến từng request độc lập; muốn khác đi thì phải bật tính năng tương ứng, chứ không có cấu hình nào ở phía target làm thay được.

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

Đề mô tả một hệ thống EC2 nằm trong Auto Scaling Group (ASG) đứng sau một AWS load balancer, và cho biết request của người dùng đang bị mất hoàn toàn vì metric SpilloverCount lớn hơn 0, ngày nào cũng xảy ra. Câu hỏi là làm gì để ngăn chuyện này tái diễn.

Cụm từ quyết định đáp án là chính cái tên metric: SpilloverCount. Đây là metric của Classic Load Balancer, đếm số request bị từ chối vì surge queue đã đầy. Nói cách khác, load balancer vẫn nhận được request nhưng không còn chỗ xếp hàng để chuyển xuống backend, nên nó vứt luôn — đúng với mô tả "requests are completely being lost".

Chi tiết thứ hai cũng quan trọng: "This is now happening daily" — đây là tải thường xuyên, lặp lại, chứ không phải một đợt traffic đột biến một lần. Điều đó loại bỏ hướng xử lý mang tính sự kiện đơn lẻ.

Ghép hai chi tiết lại: hàng đợi đầy vì backend xử lý không kịp tốc độ request đến, và tình trạng này diễn ra hằng ngày. Vậy giải pháp phải là tự động tăng số instance backend dựa trên chính chỉ số phản ánh độ dài hàng đợi.

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

Đáp án đúng theo tệp là C — Monitor for SurgeQueueLength and scale the ASG based on that metric.

SurgeQueueLength là metric của Classic Load Balancer đo tổng số request đang bị xếp hàng chờ ở load balancer. SpilloverCount chỉ tăng khi surge queue đã đầy — nghĩa là SurgeQueueLength chính là chỉ báo sớm của đúng vấn đề mà đề nêu. Giá trị maximum của SurgeQueueLength tăng cao có nghĩa backend không tiêu thụ request kịp tốc độ nhận vào, thường do:

• EC2 instance phía sau bị quá tải, không xử lý hết request đến
• Ứng dụng phụ thuộc vào tài nguyên bên ngoài đang chậm
• Chạm giới hạn số kết nối cho phép trên instance

Với nguyên nhân là thiếu năng lực xử lý ở backend, cách chữa đúng là cho ASG scale out theo SurgeQueueLength: hàng đợi bắt đầu dài ra thì thêm instance, backend tiêu thụ nhanh hơn, hàng đợi rút xuống và SpilloverCount không bao giờ chạm tới ngưỡng phải vứt request. Ta xử lý ngay tại nguyên nhân gốc, và xử lý trước khi request bị mất chứ không phải đếm sau khi đã mất.

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

A — Monitor for BackendConnectionErrors and scale the ASG based on that metric

Đây là phương án gần đúng nhất vì nó cũng scale ASG, chỉ sai ở metric được chọn. BackendConnectionErrors đếm số kết nối không thiết lập được giữa load balancer và các instance đã đăng ký. Vì load balancer có retry khi gặp lỗi nên con số này thậm chí có thể vượt cả request rate, và nó còn gộp cả lỗi kết nối phát sinh từ health check. Đó là chỉ báo của instance hỏng/không kết nối được, không phải của hàng đợi đầy vì backend chậm. Trong tình huống của đề, instance vẫn sống và vẫn nhận kết nối — chúng chỉ xử lý không kịp. Scale theo metric này thì tín hiệu có thể không bao giờ kích hoạt, hoặc kích hoạt vì lý do hoàn toàn khác.

B — Pre-warm your load balancer

Pre-warming là việc liên hệ AWS để cấu hình sẵn năng lực cho load balancer theo mức traffic dự kiến. Nó chỉ hợp lý trong các kịch bản đặc thù: có flash traffic biết trước, hoặc chạy load test mà không thể tăng tải từ từ. Khi yêu cầu, bạn phải cung cấp ngày bắt đầu – kết thúc, request rate dự kiến và kích thước request/response điển hình. Hai lý do khiến nó sai ở đây: thứ nhất, vấn đề nằm ở backend không xử lý kịp, không phải ở năng lực của load balancer, nên mở rộng load balancer không cứu được gì. Thứ hai, đề nói sự cố diễn ra hằng ngày — pre-warming là biện pháp cho một sự kiện có thời điểm xác định, không phải cơ chế chạy thường trực.

D — Enable ALB access logs and scale based on CloudWatch Logs

Phương án này là distractor. Bạn không thể scale ASG dựa trên CloudWatch Logs — chính sách scaling của Auto Scaling hoạt động trên CloudWatch metric, không nhận log làm nguồn kích hoạt trực tiếp. Access log là công cụ để điều tra sau sự việc: xem request nào, đến từ đâu, độ trễ bao nhiêu. Nó giúp bạn hiểu chuyện đã xảy ra, nhưng bản thân việc bật log không thêm một instance nào và không ngăn được request tiếp theo bị vứt.

📌 Điểm cần nhớ

• SpilloverCount và SurgeQueueLength là một cặp: SurgeQueueLength đo hàng đợi đang dài bao nhiêu, SpilloverCount đếm số request bị vứt khi hàng đợi đó đã đầy. Thấy SpilloverCount > 0 thì hành động phải nhắm vào SurgeQueueLength — chữa nguyên nhân, và chữa sớm hơn một bước.
• Cả hai đều là metric của Classic Load Balancer. Chúng xuất hiện trong đề là dấu hiệu tình huống đang nói về CLB, không phải ALB — hữu ích để loại nhanh những phương án nói về ALB.
• Scaling policy chạy trên CloudWatch metric, không chạy trên CloudWatch Logs. Bất kỳ phương án nào đề nghị "scale dựa trên log" đều loại được ngay mà không cần đọc tiếp.
• Phân biệt metric "backend chậm" với metric "backend hỏng". SurgeQueueLength thuộc nhóm đầu (không đủ năng lực xử lý), còn BackendConnectionErrors thuộc nhóm sau (không kết nối được, gồm cả health check). Chọn nhầm nhóm thì auto scaling sẽ không kích hoạt đúng lúc cần.
• Pre-warming là biện pháp một lần cho sự kiện biết trước. Vấn đề lặp lại hằng ngày cần một cơ chế tự động thường trực, tức là auto scaling.

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

Đề bài mô tả một distributed in-memory database chạy trên EC2 trong một Auto Scaling Group, và muốn ASG tự co giãn theo mức sử dụng RAM trung bình của các instance.

Cụm từ quyết định đáp án là "average RAM usage" — không phải CPU, không phải network, mà là RAM. Toàn bộ câu hỏi xoay quanh một sự thật nền tảng của EC2: hypervisor nhìn thấy được CPU, disk I/O và network của instance, nhưng không nhìn thấy được bên trong hệ điều hành khách. Bộ nhớ (RAM) là tài nguyên do OS quản lý, nên EC2 không tự báo cáo nó cho CloudWatch.

Vế thứ hai của đề — "auto-scale your Auto Scaling Group" — cũng quan trọng: scaling policy của ASG hoạt động trên CloudWatch metric. Vậy bài toán rút gọn thành: làm sao đưa được con số RAM từ trong OS ra thành một CloudWatch metric?

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

Đáp án đúng là D — Push the RAMUtilization as a custom metric using custom scripts in EC2 and setup scaling policies using this metric.

Vì CloudWatch không có sẵn metric RAM cho EC2, cách làm chuẩn là tự sinh ra metric đó từ bên trong instance: một script (hoặc agent) chạy trên EC2 đọc mức dùng bộ nhớ của OS rồi đẩy lên CloudWatch dưới dạng custom metric, bằng AWS CLI hoặc API — ví dụ aws cloudwatch put-metric-data với --metric-name, --namespace, --unit, --value và các --dimensions như InstanceId.

Khi metric đã nằm trong CloudWatch, nó trở thành công dân hạng nhất giống mọi metric khác: vẽ được đồ thị, đặt alarm được, và ASG scaling policy trỏ vào được. Đó chính là mắt xích mà đề bài cần.

Custom metric có hai độ phân giải: standard resolution (dữ liệu ở mức từng phút) và high resolution (mức từng giây), do người dùng khai báo lúc publish. Metric do các dịch vụ AWS tự sinh mặc định là standard resolution.

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

A — Enable EC2 detailed monitoring and use the CloudWatch metric RAMUtilization

Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Nó hỏng ở một chỗ: RAMUtilization không tồn tại như một metric EC2 sẵn có. Detailed monitoring là thật, nhưng nó chỉ tăng tần suất báo cáo của những metric EC2 vốn đã có (từ 5 phút xuống 1 phút) — nó không thêm metric mới. Bật detailed monitoring bao nhiêu lần cũng không làm RAM xuất hiện, vì vấn đề không nằm ở tần suất mà nằm ở chỗ dữ liệu đó chưa từng rời khỏi OS.

B — Auto Scale your ASG based on the CPUUtilization metric

CPUUtilization là metric EC2 có thật, dùng cho scaling policy hoàn toàn hợp lệ, nên về mặt kỹ thuật phương án này chạy được. Nhưng nó trả lời sai câu hỏi: đề yêu cầu co giãn theo RAM. Với một in-memory database, CPU và RAM là hai đại lượng tách rời — instance có thể gần đầy bộ nhớ trong khi CPU vẫn nhàn rỗi, và ngược lại. Lấy CPU thay cho RAM là đổi tín hiệu, không phải giải pháp cho tín hiệu được hỏi.

C — Place the instances behind a load balancer with the "smart balancing feature" monitoring RAM

Đây là phương án bịa hoàn toàn, đưa vào làm distractor. Không có tính năng nào tên "smart balancing", và load balancer về bản chất không có khả năng nhìn vào RAM của EC2 instance phía sau. Load balancer làm việc ở tầng kết nối/request — nó biết health check pass hay fail, biết số request và độ trễ, nhưng nó không có đường nào để đọc tình trạng bộ nhớ bên trong hệ điều hành của instance.

📌 Điểm cần nhớ

• CloudWatch không có metric RAM (và disk space) sẵn cho EC2. Đây là ranh giới hypervisor: những gì nằm bên trong guest OS thì EC2 không tự nhìn thấy. Thấy phương án nào nhắc tới RAMUtilization như metric có sẵn thì gần như chắc chắn là bẫy.
• Detailed monitoring = dày hơn, không phải nhiều hơn. Nó rút ngắn chu kỳ báo cáo của các metric hiện có, không bổ sung metric mới.
• Muốn scale theo thứ CloudWatch không tự đo, phải publish custom metric từ trong instance (script/agent + put-metric-data). Khi đã thành CloudWatch metric thì alarm và ASG scaling policy dùng được như bình thường.
• Đọc kỹ metric mà đề chỉ định. Một phương án đúng về kỹ thuật nhưng dùng sai metric (CPU thay cho RAM) vẫn là đáp án sai — nhất là với workload in-memory, nơi RAM mới là tài nguyên tới hạn.
• Cảnh giác với tên tính năng nghe hay mà không tồn tại ("smart balancing"). Nếu chưa từng gặp tên đó trong tài liệu, khả năng cao nó được bịa ra để làm nhiễu.

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

Đề bài mô tả một tình huống vận hành rất cụ thể: bạn launch một EC2 instance và nhận về lỗi InsufficientInstanceCapacity. Câu hỏi là: nên làm gì tiếp theo?

Cụm từ quyết định đáp án chính là tên của mã lỗi: InsufficientInstanceCapacity. Đây không phải một mô tả mơ hồ kiểu "không tạo được máy ảo" — nó là một mã lỗi có nghĩa xác định trong tài liệu troubleshooting của EC2. Nó nói rằng AWS không còn đủ capacity vật lý cho loại instance đó, trong Availability Zone đó, tại thời điểm đó. Nghĩa là giới hạn nằm ở phía AWS, không phải ở phía tài khoản của bạn.

Đây chính là chỗ đề muốn bạn phân biệt với một mã lỗi trông rất giống: InstanceLimitExceeded. Cùng là "không launch được", nhưng InstanceLimitExceeded nghĩa là tài khoản của bạn đã chạm quota — còn InsufficientInstanceCapacity thì quota của bạn vẫn còn, chỉ là AWS hết hàng. Hai nguyên nhân khác nhau dẫn tới hai cách xử lý hoàn toàn khác nhau, và bộ phương án ở đây được dựng đúng quanh sự nhầm lẫn đó.

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

Đáp án đúng là D — Try to launch the instance in another AZ.

Vì InsufficientInstanceCapacity là chuyện thiếu capacity ở phía AWS trong một Availability Zone cụ thể, cách xử lý hợp lý là thử ở một AZ khác. Capacity của EC2 được quản lý theo từng AZ, nên một AZ hết chỗ cho instance type bạn cần hoàn toàn không có nghĩa là các AZ còn lại trong cùng Region cũng hết. Đổi AZ là thao tác nằm trong tay bạn, làm được ngay, và trực tiếp nhắm vào đúng nguyên nhân của lỗi.

Đây cũng là hướng xử lý mà tài liệu troubleshooting launch issues của EC2 chỉ ra: lỗi này xuất hiện khi bạn launch instance mới hoặc khởi động lại một instance đang stopped, và nó hàm ý AWS không đủ capacity để phục vụ yêu cầu của bạn.

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

A — Request for a service limit increase in AWS support console. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Xin tăng service limit là cách xử lý cho InstanceLimitExceeded — khi tài khoản bạn đã dùng hết số instance được phép. Ở đây quota của bạn không phải vấn đề: bạn vẫn còn quyền tạo instance, chỉ là AWS không còn máy để cấp. Nâng limit lên cao hơn cũng không sinh ra thêm capacity vật lý trong AZ đó, nên lỗi vẫn nguyên. Chưa kể việc mở ticket support còn tốn thời gian chờ, trong khi lỗi này có thể xử lý ngay.

B — Run Amazon Inspector on your EC2 instances to find out what's consuming the capacity. Sai cả về công cụ lẫn về giả định. Amazon Inspector là dịch vụ đánh giá bảo mật tự động: nó kiểm tra network accessibility của EC2 instance và tình trạng bảo mật của ứng dụng chạy trên đó. Nó không đo capacity và không có khái niệm "cái gì đang chiếm capacity". Giả định ẩn trong phương án này cũng sai nốt: capacity ở đây là capacity của hạ tầng AWS, không phải tài nguyên bên trong các instance của bạn — nên dù có công cụ nhìn vào instance đi nữa cũng không thấy được nguyên nhân.

C — Use AWS Trusted Advisor to understand the root cause of this issue. Trusted Advisor là công cụ đưa khuyến nghị theo best practice của AWS: tối ưu chi phí, hiệu năng, bảo mật, fault tolerance, và theo dõi mức sử dụng so với service limit. Nó là công cụ tư vấn định kỳ, không phải công cụ chẩn đoán một lần launch thất bại. Root cause của lỗi này vốn đã nằm ngay trong tên mã lỗi rồi — không cần công cụ nào phân tích thêm, và Trusted Advisor cũng không giải quyết được nó.

📌 Điểm cần nhớ

• InsufficientInstanceCapacity = AWS hết capacity trong AZ đó → đổi AZ (hoặc đổi instance type / thử lại sau). Không phải lỗi của tài khoản bạn.
• InstanceLimitExceeded = tài khoản bạn chạm quota → xin tăng service limit. Đề thi rất hay đặt hai mã lỗi này cạnh nhau, hãy đọc kỹ tên lỗi trước khi chọn.
• Capacity của EC2 là chuyện theo từng Availability Zone, không phải theo Region — một AZ hết chỗ không kéo theo cả Region hết chỗ.
• Amazon Inspector là công cụ đánh giá bảo mật, Trusted Advisor là công cụ khuyến nghị best practice. Cả hai đều hay được dùng làm distractor cho những câu hỏi troubleshooting mà thực chất chỉ cần đọc đúng mã lỗi.

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

Đề mô tả một công ty có 90% server instance nằm trên AWS, phần còn lại nằm trong data center on-premises. Họ cần một tool/service làm đúng ba việc:

1. collect metadata của các instance đó,
2. validate the software running on the instances — kiểm tra phần mềm nào đang chạy,
3. đối chiếu configurations against their software policy — so cấu hình với chính sách phần mềm nội bộ.

Cụm từ quyết định ở đây là "collect metadata … to validate the software running on the instances along with the configurations". Nó nói rõ nhiệm vụ là thu thập và kiểm kê thông tin để đối chiếu, chứ không phải cài đặt bản vá, không phải đo hiệu năng, cũng không phải chạy job tính toán. Cụm thứ hai cần chú ý là "on-premises" — công cụ được chọn bắt buộc phải làm việc được với cả máy ngoài AWS, chứ không chỉ EC2.

Hai ràng buộc này ghép lại chỉ khớp với một phương án duy nhất trong danh sách.

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

D — AWS Systems Manager Inventory.

Inventory là capability của AWS Systems Manager sinh ra đúng cho bài toán này: nó cho khả năng nhìn xuyên suốt cả môi trường Amazon EC2 lẫn môi trường on-premises, thu thập metadata từ các managed instance — danh sách ứng dụng đã cài, phiên bản, network configuration, Windows updates, service, file… Metadata thu được có thể lưu tập trung vào một Amazon S3 bucket, rồi dùng các công cụ có sẵn để truy vấn và trả lời chính xác câu hỏi mà đề đặt ra: instance nào đang chạy phần mềm và cấu hình đúng theo software policy, instance nào cần cập nhật.

Inventory bật được cho toàn bộ managed instance bằng một thao tác, và xem được dữ liệu inventory từ nhiều Region cũng như nhiều AWS account. Nếu các loại metadata dựng sẵn chưa đủ, có thể tạo custom inventory: một file JSON do bạn cung cấp, đặt vào thư mục quy định trên managed instance, và Inventory sẽ thu thập luôn phần dữ liệu đó khi chạy.

Một điểm đáng nhớ: Inventory chỉ thu thập metadata, không truy cập dữ liệu hay thông tin độc quyền bên trong instance — đúng tinh thần "collect metadata" của đề.

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

A — AWS Batch. Đây là dịch vụ chạy batch computing job: nhận job, xếp hàng, tự cấp phát compute resource để chạy rồi thu dọn. Nó hoàn toàn không liên quan tới việc kiểm kê phần mềm hay đối chiếu cấu hình của server. Đây là phương án lạc đề rõ nhất trong bốn phương án.

B — Unified CloudWatch Agent. Phương án này có điểm gần đúng đáng chú ý: Unified CloudWatch Agent cũng cài lên máy, cũng chạy được trên cả EC2 lẫn on-premises server, nên nó thoả ràng buộc "hybrid" của đề. Nhưng nó hỏng ở loại dữ liệu thu thập: agent này thu system-level metrics (CPU, memory, disk…), custom metrics do ứng dụng phát ra, và logs. Đó là dữ liệu quan trắc theo thời gian, không phải bản kê khai phần mềm đã cài và cấu hình để so với software policy. Nhìn vào CloudWatch bạn biết máy đang bận hay rảnh, chứ không biết máy đang cài phiên bản gói nào.

C — AWS Systems Manager Patch Manager. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó cùng nằm trong Systems Manager và cũng phủ được cả EC2 lẫn on-premises server/VM. Nhưng vai trò của Patch Manager là tự động hoá việc vá: áp patch bảo mật và các bản cập nhật khác cho operating system và application, cài Service Pack trên Windows, nâng minor version trên Linux. Tức là nó hành động thay đổi máy, còn đề chỉ yêu cầu thu thập metadata để validate. Patch Manager cũng chỉ nhìn ở góc độ "đã vá hay chưa vá", hẹp hơn nhiều so với yêu cầu kiểm kê phần mềm và cấu hình tổng quát mà đề nêu.

📌 Điểm cần nhớ

• Đề nhắc "collect metadata" + "validate software và configurations" → nghĩ ngay tới Systems Manager Inventory; đề nhắc "apply patches / update" → mới là Patch Manager. Hai capability này cùng nhà nhưng khác hẳn nhiệm vụ: một bên đọc và báo cáo, một bên thay đổi máy.
• CloudWatch Agent = metrics và logs, không phải bản kê phần mềm. Khi câu hỏi hỏi "máy đang cài gì" thì CloudWatch không phải câu trả lời, dù nó cũng chạy được trên on-premises.
• Ràng buộc hybrid (AWS + on-premises) không đủ để loại phương án trong câu này, vì cả Inventory, Patch Manager lẫn CloudWatch Agent đều hỗ trợ managed instance ngoài AWS. Phải dùng ràng buộc thứ hai — loại dữ liệu / loại hành động — mới tách được đáp án.
• Inventory mở rộng được bằng custom inventory (file JSON đặt trên máy), nên khi đề nói "metadata theo chính sách riêng của công ty" mà các loại dựng sẵn có vẻ không đủ, đó vẫn là Inventory chứ không phải một dịch vụ khác.