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

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

Đề mô tả: bạn đã tạo một AMI trong một AWS account, và muốn chia sẻ AMI đó với các AWS account khác trong cùng organization. Câu hỏi thuần tuý là: thao tác nào thực sự cho phép account kia dùng được AMI của bạn?

Cụm từ quyết định là "share that AMI with other AWS accounts" — tức đối tượng cần cấp quyền là chính AMI, một tài nguyên có sẵn cơ chế phân quyền riêng gọi là image permissions (danh sách các AWS account ID được phép nhìn thấy và khởi chạy image đó). Cụm thứ hai đáng chú ý là "other AWS accounts" — chia sẻ giữa các account, không phải cấp quyền cho một principal bên trong account của bạn.

Hai chi tiết đó loại ngay hướng suy nghĩ "phải làm gì đó với IAM/STS": các phương án nhắc tới IAM role và STS đang giải quyết bài toán cho người ở account khác đóng vai vào account của bạn, chứ không phải bài toán mở quyền trên chính AMI.

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

Đáp án đúng là B — sửa danh sách account được phép nhìn thấy AMI ngay trong AMI Console, và các account kia dùng được luôn.

AMI là thứ chứa toàn bộ thông tin cần để khởi chạy một EC2 instance. Một shared AMI là AMI do người này tạo ra rồi mở cho người khác dùng. AWS cho phép chia sẻ AMI với những AWS account cụ thể mà không cần biến AMI thành public — thứ duy nhất bạn cần là AWS account ID của bên nhận.

Thao tác cụ thể: mở AMI đó, chỉnh image permissions, thêm số hiệu account của bên bạn muốn chia sẻ. Xong bước này, account kia thấy được AMI và khởi chạy instance từ nó — không cần thêm role, không cần STS.

Một ràng buộc kèm theo cần nhớ: chỉ chia sẻ được AMI có volume không mã hoá, hoặc volume mã hoá bằng customer-managed CMK. Nếu AMI có volume mã hoá thì phải chia sẻ luôn cả CMK đã dùng để mã hoá, nếu không bên nhận có AMI mà vẫn không khởi chạy nổi.

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

A — Tạo IAM role cho account kia assume qua STS rồi họ truy cập AMI. Đây là mô hình cross-account access dùng cho việc để người ở account khác hành động bên trong account của bạn. Nhưng bài toán ở đây là để họ khởi chạy instance trong account của chính họ từ AMI của bạn — cái đó do image permissions quyết định, không do IAM role. Assume role không tự động khiến AMI xuất hiện trong account đích.

C — Không cần làm gì cả, chỉ cần đưa AMI id "bí mật" là dùng được. Sai ở chỗ coi AMI id như một bí mật đóng vai trò kiểm soát truy cập. AMI id chỉ là định danh, không phải thông tin xác thực. Một AMI riêng tư không lộ ra cho account khác chỉ vì họ biết id của nó; thiếu bước cấp quyền, account kia gọi tới sẽ không thấy image. Đây cũng là lỗi tư duy kinh điển "security by obscurity" mà đề thi hay giăng ra.

D — Sửa danh sách account và tạo thêm IAM role assume qua STS. Đây là phương án gần đúng nhất, vì nó có chứa bước đúng (sửa image permissions). Nó hỏng ở vế thứ hai: phần IAM role + STS là thừa. Bài chỉ hỏi cách chia sẻ AMI, mà vế đầu đã đủ để account kia dùng được. Thêm một bước không cần thiết vào quy trình vừa sai về mặt kỹ thuật (nó không phải điều kiện để chia sẻ AMI), vừa sai với nguyên tắc least privilege — bạn mở một cánh cửa vào account mình mà bài toán không hề đòi. Khi hai phương án cùng chứa bước đúng, phương án không kèm bước thừa mới là đáp án.

📌 Điểm cần nhớ

• Chia sẻ AMI giữa các account = sửa image permissions và thêm AWS account ID. Không cần IAM role, không cần STS, không cần biến AMI thành public.
• AMI id không phải là bí mật. Biết id mà không được cấp quyền thì vẫn không dùng được — đừng chọn phương án dựa vào "chỉ cần đưa id".
• AMI mã hoá cần chia sẻ kèm CMK. Chỉ chia sẻ được AMI có volume không mã hoá hoặc mã hoá bằng customer-managed CMK, và phải chia sẻ luôn CMK đó.
• Cẩn thận với phương án "đúng + thừa". Trong bộ đề AWS, một lựa chọn chứa đúng bước cần làm nhưng ghép thêm một bước không liên quan (thường là IAM role/STS) là bẫy phổ biến; chọn phương án gọn nhất mà vẫn giải quyết được yêu cầu.

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

Đề mô tả một tình huống gỡ lỗi quen thuộc: đoạn cfn-init phức tạp chạy hỏng, log nằm trong /var/cfn/cfn-init-output.log trên chính EC2 instance, nhưng khi stack tạo thất bại thì CloudFormation dọn dẹp và xoá luôn instance đó — file log biến mất cùng với instance.

Ba ràng buộc trong đề quyết định đáp án, và cần đọc cả ba cùng lúc:

• "while not changing the way your EC2 instance works" — không được cài thêm phần mềm, không được gắn thêm agent, không sửa cấu hình instance. Đây là cụm từ loại thẳng những phương án dựa vào agent.
• "ensuring you can debug your instance over 24 hours" — instance phải còn sống đủ lâu, chứ không phải "kéo dài thêm một chút".
• "cfn-init" (chứ không phải cfn-signal) — lỗi nằm ở đoạn code cấu hình đang chạy, không phải ở chuyện tín hiệu về muộn.

Vấn đề gốc không phải là "log ở đâu" mà là "làm sao giữ được instance để vào đọc log". Ai giải quyết được chuyện giữ instance mà không đụng vào instance thì đó là đáp án.

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

D — Set OnFailure=DO_NOTHING

OnFailure là thuộc tính của lời gọi CreateStack trong CloudFormation, quyết định CloudFormation làm gì khi tạo stack thất bại. Nó nhận một trong ba giá trị: DO_NOTHING, ROLLBACK hoặc DELETE. Đặt DO_NOTHING nghĩa là khi stack tạo hỏng, CloudFormation dừng lại và giữ nguyên hiện trạng thay vì rollback hay xoá tài nguyên đã tạo — EC2 instance vẫn còn đó, và bạn SSH/Session Manager vào đọc /var/cfn/cfn-init-output.log bao lâu tuỳ ý, thoải mái quá 24 giờ.

Điểm mấu chốt: đây là thay đổi ở tầng CloudFormation, không phải ở tầng instance. Template không đổi, userdata không đổi, không cài thêm gì lên máy — đúng yêu cầu "not changing the way your EC2 instance works". Lưu ý là bạn chỉ được chỉ định OnFailure hoặc DisableRollback, không dùng cả hai cùng lúc.

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

A — Increase the Wait Timeout to 2 hours

Đây là phương án gài bẫy theo hướng "thời gian". Wait timeout gắn với cơ chế cfn-signal / wait condition: CloudFormation chờ tín hiệu báo hoàn tất trong khoảng thời gian đó rồi mới quyết định thành công hay thất bại. Nhưng đề nói rõ lỗi nằm ở cfn-init — code cấu hình chạy hỏng, không phải tín hiệu về trễ. Kéo dài thời gian chờ không chữa được một đoạn code hỏng: hết giờ thì stack vẫn thất bại và instance vẫn bị xoá. Nó cũng không đáp ứng nổi yêu cầu 24 giờ.

B — Enable VPC Flow Logs and intercept the cfn-init log file

Sai ngay ở bản chất công cụ. VPC Flow Logs ghi metadata của lưu lượng mạng đi qua network interface — địa chỉ nguồn/đích, cổng, giao thức, accept/reject. Nó không đọc file trong hệ thống tệp của instance và cũng không nhìn thấy nội dung tải trọng. Không có cách nào "chặn bắt" một file log cục bộ bằng Flow Logs. Ngoài ra, bật Flow Logs cũng là thêm cấu hình so với hiện trạng, trong khi đề yêu cầu giữ nguyên cách instance vận hành.

C — Install the CloudWatch logs agent, create a new IAM role and assign it to the EC2 instance, and send the logs directly to CloudWatch Logs

Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì về mặt kỹ thuật nó thực sự chạy được: đẩy log ra CloudWatch Logs thì log tồn tại độc lập với vòng đời instance, instance bị xoá thì log vẫn còn để đọc. Nó hỏng ở chỗ vi phạm ràng buộc của đề: phải cài agent lên instance và gắn thêm IAM role — đúng là "changing the way your EC2 instance works". Còn một điểm yếu thực tế nữa: nếu cfn-init hỏng ở giai đoạn sớm, bản thân bước cài agent cũng có thể chưa kịp hoàn tất, và bạn mất luôn đoạn log cần nhất. Đây là ví dụ điển hình của "giải pháp tốt trong đời thật nhưng sai trong bài thi" — vì đề đã cắm sẵn một ràng buộc loại nó ra.

📌 Điểm cần nhớ

• Khi đề nói "without changing the instance" hoặc "no changes to the EC2 instance", mọi phương án có chữ install agent, add IAM role, modify userdata đều bị loại, dù nó hợp lý đến đâu về mặt kiến trúc. Hãy tìm phương án nằm ở tầng control plane (CloudFormation, API call) thay vì tầng OS.
• Phân biệt rõ cfn-init (chạy metadata cấu hình: cài gói, ghi file, khởi động service) với cfn-signal (gửi tín hiệu hoàn tất cho wait condition / creation policy). Phương án nói về wait timeout chỉ đúng khi đề nói về tín hiệu, không đúng khi đề nói về code cấu hình hỏng.
• OnFailure của CreateStack có ba lựa chọn DO_NOTHING / ROLLBACK / DELETE, và không dùng chung với DisableRollback. DO_NOTHING là công cụ chuẩn để giữ lại tài nguyên hỏng phục vụ điều tra.
• VPC Flow Logs = metadata mạng, không phải log ứng dụng và không phải log hệ điều hành. Bất cứ phương án nào dùng Flow Logs để lấy nội dung file hay nội dung request đều sai về bản chất.

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

Tình huống: bạn viết một script kiểm tra xem mọi EC2 instance đang chạy có dùng AMI ID nằm trong danh sách được công ty phê duyệt hay không. Script chạy đúng ở eu-west-1, nhưng khi đồng nghiệp ở New York (tức là một region khác, ví dụ us-east-1) chạy thì toàn bộ instance bị báo non-compliant, trong khi auditor kiểm tra tay lại thấy chúng hoàn toàn hợp lệ.

Cụm từ quyết định đáp án nằm ở chỗ đối lập giữa hai vế: script so khớp theo AMI ID, và nó chạy ở một region khác với region nơi danh sách AMI được lập. Thêm một chi tiết nữa rất quan trọng: tất cả instance đều bị đánh dấu sai, chứ không phải một vài cái — và auditor xác nhận chúng thực sự tuân thủ. Nghĩa là script vẫn chạy được, vẫn đọc được dữ liệu, vẫn so sánh được, chỉ là nó so sánh với một danh sách vô nghĩa ở region đó. Đây là dấu hiệu của lỗi dữ liệu tham chiếu, không phải lỗi quyền hay lỗi kỹ thuật.

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

D — AMI ID mang tính region-specific, phải cung cấp danh sách AMI hợp lệ riêng theo từng region.

AMI là thứ chứa thông tin cần thiết để khởi tạo một instance, và mỗi AMI gắn với đúng một AWS Region. Muốn dùng cùng một image ở region khác thì phải copy AMI sang region đó (bằng Console, AWS CLI, SDK hoặc EC2 API — thao tác CopyImage, hỗ trợ cả EBS-backed lẫn instance-store-backed AMI).

Điểm mấu chốt: bản copy là một AMI giống hệt về nội dung nhưng khác về danh tính — nó có AMI ID riêng, hoàn toàn mới. Với AMI kiểu EBS-backed, các snapshot nền cũng được copy thành snapshot mới tương ứng. AMI nguồn và AMI đích độc lập nhau tới mức bạn có thể sửa hoặc deregister cái nguồn mà cái đích không hề bị ảnh hưởng.

Vậy nên danh sách AMI ID "được phê duyệt" mà bạn lập ở eu-west-1 khi đem sang New York sẽ không khớp với bất kỳ instance nào — instance ở đó chạy trên các AMI đã copy, mang ID khác. Script so chuỗi ID, không tìm thấy cái nào trùng, nên tuyên bố tất cả là non-compliant. Đúng như hành vi quan sát được: sai đồng loạt 100%, chứ không sai lác đác.

Cách sửa: cung cấp cho script định danh của các AMI đã tạo/copy ở từng region, rồi chọn danh sách theo region nơi script đang chạy.

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

A — Đã chạm giới hạn API call và script không xử lý trường hợp lỗi đó. Đây là phương án gần đúng nhất về mặt "có thể xảy ra thật", nhưng nó hỏng ở chỗ triệu chứng không khớp. Bị throttling thì lời gọi API sẽ ném lỗi, và script hoặc là dừng giữa chừng, hoặc là bỏ sót một phần instance — kết quả sẽ không đều, phụ thuộc thời điểm chạy, và chạy lại sẽ cho kết quả khác. Ở đây kết quả lại rất nhất quán: mọi instance non-compliant. Ngoài ra, nếu API call thất bại thì script cũng không lấy được thông tin AMI của instance để mà kết luận "compliant hay không" — vấn đề sẽ là "không có dữ liệu", chứ không phải "có dữ liệu và kết luận sai".

B — Đồng nghiệp chạy sai cách, cần viết tài liệu chi tiết hơn. Phương án này đổ lỗi cho người dùng trong khi bằng chứng chỉ thẳng vào script. Chi tiết "auditor kiểm tra tay và xác nhận instance đúng là compliant" chính là để loại bỏ khả năng này: kết quả kiểm tra tay và kết quả script mâu thuẫn nhau, nghĩa là logic của script sai, không phải thao tác chạy sai. Viết thêm tài liệu cũng không làm danh sách AMI ID của eu-west-1 khớp được với AMI ID ở New York.

C — Script thiếu IAM permission, hãy nhúng IAM policy vào trong script rồi chạy lại. Sai ở cả chẩn đoán lẫn cách chữa. Về chẩn đoán: thiếu quyền thì lời gọi API bị từ chối với lỗi truy cập, script không đọc nổi danh sách instance — lại rơi vào tình huống "không có dữ liệu", chứ không phải đọc được rồi so sánh ra kết quả sai đồng loạt. Về cách chữa: không tồn tại chuyện "nhúng IAM policy từ bên trong script". Quyền được cấp cho principal đang chạy script (IAM role của instance, IAM user, hay role được assume), thông qua policy gắn vào identity đó — chứ không phải bằng cách viết policy vào mã nguồn. Một script tự cấp quyền cho chính mình sẽ phá vỡ toàn bộ mô hình phân quyền của IAM.

📌 Điểm cần nhớ

• AMI ID là tài nguyên theo region. Cùng một image logic, sau khi copy sang region khác sẽ mang một AMI ID hoàn toàn khác. Mọi script/automation hard-code AMI ID đều phải tra danh sách theo region đang chạy.
• Copy AMI tạo ra tài nguyên độc lập: bản đích có ID riêng, snapshot riêng; sửa hoặc deregister bản nguồn không ảnh hưởng bản đích. Đừng giả định hai bên "là một".
• Đọc triệu chứng để loại phương án: sai đồng loạt và nhất quán → lỗi dữ liệu tham chiếu / logic. Sai lác đác, thay đổi theo lần chạy → mới nghĩ tới throttling. Không có kết quả nào cả → mới nghĩ tới IAM permission.
• IAM permission cấp cho identity, không nhúng vào code. Bất kỳ phương án nào nói "thêm policy vào trong script" đều là mồi nhử, kể cả khi phần chẩn đoán nghe có vẻ hợp lý.

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

Đề mô tả một công ty khởi đầu với 5 nhân viên cùng làm việc trên một AWS account duy nhất, mỗi người tự dựng VPC riêng cho mục đích riêng (billing, operations, finance). Khi quy mô lên hơn 200 người, nhân viên ở các phòng ban khác nhau đã tự tạo VPC peering và giẫm chân lên công việc của nhau. Yêu cầu: "properly separate the environment your employees work in based on the department they belong to".

Cụm từ quyết định là "properly separate the environment ... based on the department" — kết hợp với bối cảnh tất cả đang nằm trong cùng một account. Đề không hỏi "làm sao giới hạn quyền của từng người", mà hỏi làm sao tách hẳn môi trường làm việc theo phòng ban. Trong AWS, ranh giới cô lập mạnh nhất và tự nhiên nhất là ranh giới account, chứ không phải ranh giới quyền bên trong một account. Chi tiết "VPC peering giữa các nhóm" càng nhấn mạnh điều đó: mọi thứ đang chung một account nên các VPC nhìn thấy và nối được vào nhau quá dễ dàng.

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

D — AWS Organizations with OU.

AWS Organizations cho phép quản lý tập trung nhiều AWS account: tạo account mới tự động, gom account thành nhóm phản ánh cơ cấu tổ chức, áp policy quản trị lên các nhóm đó, và gộp hoá đơn về một phương thức thanh toán chung.

Organizational Unit (OU) là một container chứa các account bên trong root. Một OU có thể chứa OU khác, tạo thành cấu trúc cây: root ở trên, các nhánh OU đi xuống, và account là lá. Khi gắn policy vào một node bất kỳ trong cây, policy đó chảy xuống toàn bộ nhánh OU và account bên dưới. Mỗi OU có đúng một OU cha, và mỗi account thuộc đúng một OU.

Đúng là thứ đề bài cần: mỗi phòng ban (billing, operations, finance...) được cấp account riêng, đặt vào OU tương ứng của phòng ban đó. Từ lúc này, môi trường của các phòng ban tách nhau ở mức account — không còn chuyện một nhân viên vô tình dựng VPC peering sang tài nguyên của nhóm khác trong cùng account, và policy quản trị áp cho từng OU sẽ điều tiết được phòng ban đó làm gì. Đây chính là mô hình "segregate environment theo phòng ban" mà AWS khuyến nghị khi tổ chức phình to. Bản thân AWS Organizations không tính thêm phí.

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

A — AWS IAM Groups with restrictive policies. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì IAM Group đúng là công cụ gom người dùng theo phòng ban rồi gắn policy chung. Nhưng nó chỉ phân quyền, không tách môi trường: mọi user vẫn nằm trong cùng một account, cùng nhìn vào một không gian tài nguyên. Chỗ hỏng của nó là ranh giới sai cấp — group giới hạn ai được gọi API nào, chứ không tạo ra ranh giới cô lập giữa các bộ tài nguyên. Muốn ngăn chuyện VPC peering chéo bằng IAM policy thì phải viết và duy trì bằng tay một mớ điều kiện cho hơn 200 người, và một sai sót nhỏ là thủng lại. IAM group (kể cả với policy chặt) không tạo được môi trường tách biệt trên AWS.

B — AWS IAM Roles with restrictive policies. Cùng một vấn đề như A, chỉ khác ở cơ chế cấp quyền: role là danh tính tạm thời để assume thay vì gắn cứng vào user. Nó giải bài toán "cấp quyền tạm thời, không dùng long-term credentials", không giải bài toán "tách môi trường theo phòng ban". Vẫn là một account, vẫn chung một mặt bằng tài nguyên — role có chặt đến đâu cũng không sinh ra ranh giới cô lập mà đề đang cần.

C — AWS GuardDuty. Sai hẳn về loại dịch vụ. GuardDuty là dịch vụ phát hiện mối đe doạ: nó phân tích sự kiện từ AWS CloudTrail (hoạt động của user và API), VPC Flow Logs (dữ liệu lưu lượng mạng) và DNS Logs (mẫu truy vấn tên miền) để phát hiện hành vi độc hại hoặc truy cập trái phép. Nó quan sát và cảnh báo, không phân chia hay cô lập môi trường làm việc. Nếu chọn C, tình huống trong đề vẫn nguyên vẹn — nhân viên vẫn peering chéo được, chỉ khác là có thêm bản ghi về việc đó.

📌 Điểm cần nhớ

• Đề nói "separate / segregate / isolate environment" giữa các nhóm, phòng ban hoặc môi trường (dev/test/prod) → nghĩ ngay tới nhiều AWS account gom trong AWS Organizations, sắp theo OU. Ranh giới account là ranh giới cô lập mạnh nhất trong AWS.
• Phân biệt hai tầng: IAM (Group/Role/Policy) quản lý ai được làm gì bên trong một account; Organizations + OU quản lý ranh giới giữa các account. Đề hỏi tách môi trường thì IAM không phải câu trả lời, dù policy có chặt tới đâu.
• Policy gắn vào một node trong cây Organizations kế thừa xuống toàn bộ OU con và account bên dưới. Mỗi account thuộc đúng một OU, mỗi OU có đúng một cha — nhớ đặc điểm cây này khi gặp câu về quản trị tập trung.
• GuardDuty là detection, không phải prevention hay isolation. Gặp phương án GuardDuty trong câu hỏi về phân tách, phân quyền hay kiểm soát truy cập thì gần như chắc chắn là mồi nhử; nó chỉ đúng khi đề hỏi về phát hiện hành vi bất thường dựa trên CloudTrail, VPC Flow Logs và DNS Logs.

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

Đề mô tả một ứng dụng chạy trên Elastic Beanstalk với hai đặc điểm: complex runtime và multiple OS dependencies, khiến mỗi lần nâng cấp mất rất nhiều thời gian. Câu hỏi yêu cầu chọn hai cách để rút ngắn thời gian nâng cấp.

Cụm từ quyết định nằm ở hai chỗ, và phải thoả cả hai thì phương án mới đúng:

• "multiple OS dependencies... takes a long time" — thời gian nâng cấp bị đốt ở khâu cài đặt runtime và các gói phụ thuộc trên từng instance, chứ không phải ở khâu chạy code. Muốn nhanh thì phải loại bỏ khâu cài đặt đó khỏi lúc deploy.
• "You cannot sacrifice application availability" — mọi phương án làm gián đoạn hoặc giảm năng lực phục vụ đều bị loại ngay, kể cả khi nó nhanh.

Nói cách khác: đề đang tìm cách nhanh mà không được downtime, chứ không phải chỉ nhanh.

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

D — Create a Golden AMI with your application. Golden AMI là ảnh máy đã được chuẩn hoá sẵn: runtime phức tạp, các OS dependencies, bản vá bảo mật và các agent giám sát đều đã nằm sẵn trong AMI. Khi Elastic Beanstalk dựng instance từ AMI này, nó không phải lặp lại toàn bộ quá trình cài đặt cho từng máy nữa — chính khâu bị đề chỉ đích danh là nguyên nhân chậm. Đây là cách tấn công thẳng vào nguyên nhân của thời gian nâng cấp.

A — Create a new beanstalk environment... và áp dụng blue/green deployment. Elastic Beanstalk mặc định cập nhật phiên bản theo kiểu in-place trên chính environment đang chạy, nên ứng dụng có thể không phục vụ được trong một khoảng thời gian. Với blue/green, phiên bản mới được triển khai sang một environment riêng biệt, chạy xong xuôi rồi mới swap CNAME giữa hai environment để chuyển traffic. Nhờ vậy, thời gian nâng cấp mà người dùng thật sự cảm nhận chỉ còn là thời gian CNAME mới có hiệu lực — phần dựng dựng lâu la diễn ra ở environment kia, không ảnh hưởng gì tới môi trường đang phục vụ. Đây cũng là cách bắt buộc khi cần chuyển sang một platform version không tương thích.

Hai phương án bổ trợ nhau đúng theo hai vế của đề: D làm việc dựng nhanh hơn, A làm việc dựng không đụng tới availability.

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

B — Upgrade the EC2 instance type. Đây là phương án gần đúng theo kiểu "cứ mạnh hơn thì nhanh hơn". Máy khoẻ hơn có thể giúp bước cài đặt dependencies nhanh lên đôi chút, nhưng phần lớn thời gian ở đây là tải gói, giải nén và cấu hình — phụ thuộc vào số lượng công việc phải làm chứ không chỉ vào CPU. Cải thiện có được là rất nhỏ, và quan trọng hơn: nó không giải quyết được ràng buộc về availability chút nào, vì bản chất deploy vẫn là in-place.

C — Use rolling with additional batch. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì nó thật sự bảo toàn availability: một batch instance phụ được dựng thêm trước, nên năng lực phục vụ được giữ nguyên trong suốt quá trình. Nhưng nó hỏng ở vế còn lại — rolling triển khai lần lượt từng batch trên chính environment cũ, nên tổng thời gian deploy còn dài hơn so với deploy một lượt. Đề yêu cầu rút ngắn thời gian nâng cấp, mà phương án này lại kéo dài nó ra.

E — Use all at once deployment pattern. Đây là phương án gần đúng theo hướng ngược lại với C: nó nhanh nhất, vì phiên bản mới được đẩy xuống mọi instance cùng lúc. Nhưng sau đó web proxy hoặc application server cần khởi động lại, khiến ứng dụng không phục vụ được hoặc phục vụ kém trong một khoảng thời gian. Nó vi phạm trực tiếp câu "cannot sacrifice application availability". Ngoài ra, deploy vẫn là in-place nên vẫn phải cài lại toàn bộ OS dependencies — cái chậm không hề mất đi.

📌 Điểm cần nhớ

• Câu hỏi kiểu "deploy chậm vì phải cài nhiều thứ" gần như luôn dẫn tới Golden AMI / pre-baked image: chuyển công sức cài đặt từ lúc deploy sang lúc build image.
• Với Elastic Beanstalk, chỉ blue/green (swap CNAME giữa hai environment) mới tách hẳn việc dựng ra khỏi môi trường đang phục vụ. Mọi policy còn lại đều là in-place trên environment cũ.
• Xếp các deployment policy theo hai trục tốc độ và availability: all at once nhanh nhưng có gián đoạn; rolling / rolling with additional batch giữ availability nhưng chậm hơn. Đề nào đòi cả hai thì đáp án nằm ngoài nhóm policy in-place.
• Khi đề bắt chọn hai phương án và nêu hai ràng buộc riêng biệt, hãy kiểm tra xem mỗi đáp án có giải quyết một ràng buộc khác nhau không — thường chúng bổ trợ chứ không trùng lặp.

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

Đề mô tả một EC2 instance nằm trong Auto Scaling Group (ASG) và đã bị đánh dấu là unhealthy vì một health check. Câu hỏi: điều gì xảy ra sau đó?

Cụm từ quyết định là "has been marked as unhealthy" — thì hiện tại hoàn thành. Việc đánh dấu đã xong rồi, không phải đang chờ xem instance có hỏng hay không. Ba phương án sai đều cố kéo câu chuyện quay ngược về trước thời điểm đó: chờ thêm grace period, đòi thêm một nguồn health check thứ hai, hoặc phân biệt nguồn nào đánh dấu. Khi trạng thái unhealthy đã được ghi nhận, ASG chỉ có đúng một hành động: thay thế.

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

C — ASG sẽ thay instance unhealthy bằng một instance khoẻ mạnh.

Sau khi một instance bị đánh dấu unhealthy, Amazon EC2 Auto Scaling gần như lập tức lên lịch thay thế nó. Quy trình gồm hai scaling activity: một activity terminate instance hỏng, sau đó một activity khác launch instance mới thế chỗ. Instance không bao giờ tự phục hồi trạng thái health — cờ unhealthy là một chiều, không có đường quay lại "healthy" cho chính instance đó.

Một hệ quả vận hành đáng nhớ: khi instance bị terminate, mọi Elastic IP gắn với nó sẽ bị dissociate và không tự động gắn sang instance mới. Muốn giữ địa chỉ đó thì phải associate lại bằng tay.

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

A — Phải cả EC2 health check lẫn Elastic Load Balancer cùng báo unhealthy thì ASG mới thay. Sai về cách ASG đánh giá health. Cấu hình health check của ASG lấy trạng thái từ EC2 status checks hoặc từ ELB health checks — đây không phải phép AND giữa hai nguồn. Chỉ cần một nguồn đang được cấu hình báo unhealthy là đủ để instance bị xếp vào diện thay thế. Phương án này nghe hợp lý vì gợi ý "chống báo động giả", nhưng nó mô tả một cơ chế mà ASG không có.

B — Instance có thể tự phục hồi trong grace period, nên ASG chờ hết grace period rồi mới thay. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì HealthCheckGracePeriod là thật. Nhưng nó bị đặt sai thời điểm: grace period áp dụng lúc instance vừa launch, để ASG biết phải đợi bao lâu trước khi bắt đầu kiểm tra health status — cho ứng dụng thời gian khởi động, tránh bị giết oan khi chưa kịp bind cổng hay warm-up. Nó không phải khoảng ân hạn sau khi đã bị đánh dấu unhealthy. Và mệnh đề "instance có thể tự phục hồi health" thì sai hẳn: một khi đã unhealthy, nó không tự trở lại healthy. (Giá trị mặc định của grace period còn khác nhau tuỳ cách tạo ASG — qua Console khác với qua CLI/SDK — nên đừng học thuộc một con số duy nhất.)

D — Nếu custom health check đánh dấu unhealthy thì ASG sẽ không tự thay. Ngược hoàn toàn. Custom health check tồn tại chính là để bạn đẩy thông tin health của riêng mình vào EC2 Auto Scaling: khi bạn xác định instance không hoạt động đúng, bạn set health status của nó thành Unhealthy. Ở lần kiểm tra health tiếp theo, ASG thấy trạng thái đó và launch instance thay thế — y hệt như với EC2 hay ELB health check. Nguồn thông tin khác nhau, hành động sau đó thì như nhau.

📌 Điểm cần nhớ

• Unhealthy trong ASG là một chiều. Instance không tự phục hồi health; đã bị đánh dấu là bị lên lịch terminate rồi launch bản thay thế.
• HealthCheckGracePeriod thuộc về giai đoạn launch, không phải giai đoạn sau khi đánh dấu unhealthy. Gặp phương án nào dùng grace period để "hoãn thay thế" thì đó là bẫy.
• EC2 status check, ELB health check và custom health check là ba nguồn tín hiệu, không phải ba điều kiện phải cùng thoả. ASG dùng nguồn đang được cấu hình, và mọi nguồn đều dẫn tới cùng một hành động thay thế.
• Terminate là terminate thật: Elastic IP gắn với instance cũ bị dissociate và phải gắn tay sang instance mới. Bất cứ trạng thái nào nằm trên instance đều coi như mất — thiết kế ứng dụng trong ASG phải stateless.

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

Bối cảnh: đội Big Data chạy một job ETL hằng đêm trực tiếp trên RDS production, tính ra một view rồi đẩy sang data lake trên S3. Hồi trang web còn ít khách thì không sao, nhưng nay lưu lượng tăng, câu truy vấn ETL chạy rất lâu và làm hỏng trải nghiệm người dùng đang duyệt web.

Câu hỏi yêu cầu cách cải thiện cả ngắn hạn lẫn dài hạn.

Cụm từ quyết định đáp án: "nightly ETL on top of your production RDS database" kết hợp với "affects the user experience". Vấn đề không phải là database yếu, mà là workload đọc nặng của ETL đang tranh giành tài nguyên với workload phục vụ người dùng trên cùng một DB instance. Thêm chữ "in the short and long term" loại bỏ những cách chỉ mua thêm thời gian mà không tách được hai loại tải này ra khỏi nhau. Đúng ra thì đây là bài toán tách read workload, và trong AWS RDS công cụ dành riêng cho việc đó chỉ có một.

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

B — Create an RDS Read Replica for the ETL team.

Read Replica là bản sao chỉ đọc của DB instance gốc: RDS tạo instance thứ hai từ snapshot của source, rồi dùng cơ chế replication bất đồng bộ native của chính database engine (MySQL, MariaDB, PostgreSQL, Oracle, SQL Server) để cập nhật replica mỗi khi source có thay đổi.

Điểm mấu chốt là read replica có endpoint riêng và truy vấn được. Cho đội ETL trỏ job hằng đêm vào endpoint đó, toàn bộ chi phí CPU, I/O và bộ nhớ của câu query nặng rơi lên replica chứ không rơi lên instance đang phục vụ website. Người dùng duyệt web không còn thấy chậm.

Nó giải quyết được cả hai vế mà đề hỏi: ngắn hạn vì tạo replica là thao tác cấu hình, không phải viết lại kiến trúc ETL; dài hạn vì đây là cách scale out cho workload đọc nặng — lưu lượng tăng nữa thì thêm replica nữa, và tải ETL vẫn nằm tách biệt vĩnh viễn khỏi tải production.

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

A — Enable RDS Multi-AZ. Đây là phương án gây nhầm nhiều nhất vì Multi-AZ cũng tạo ra một instance thứ hai. Nhưng instance đó là standby, sinh ra cho mục đích availability và durability: dữ liệu được replicate đồng bộ sang AZ khác, và standby chỉ ngồi chờ để failover. Bạn không đọc được từ standby — nó không phải endpoint phục vụ truy vấn. Bật Multi-AZ xong, job ETL vẫn phải chạy trên chính instance chính, và website vẫn chậm y như cũ. Đây là khác biệt kinh điển Read Replica (scale đọc, async) vs Multi-AZ (HA, sync) mà đề thi hỏi đi hỏi lại.

C — Use Athena to query RDS. Về mặt kỹ thuật thì không phải là bịa: Athena có federated query, đọc được dữ liệu từ RDS. Nhưng nó hỏng ở chỗ căn bản — federated query vẫn đẩy toàn bộ tải đọc xuống database gốc. Athena chỉ đổi nơi phát lệnh, không đổi nơi gánh việc. Instance production vẫn phải quét dữ liệu, vẫn tốn I/O, và người dùng vẫn chịu đúng triệu chứng cũ. Đổi công cụ query mà không đổi nguồn đọc thì không giải quyết được gì.

D — Upgrade the RDS instance type. Phương án này có giúp — instance to hơn thì CPU và I/O nhiều hơn, query ETL chạy nhanh hơn, đỡ ảnh hưởng hơn. Nhưng nó chỉ là ngắn hạn: ETL và web vẫn dùng chung một instance, nên khi lượng truy cập tiếp tục tăng thì vấn đề tái diễn nguyên vẹn, và lần sau lại phải nâng cấp nữa. Đề hỏi rõ "short and long term" — phương án này trượt vế thứ hai vì nó không hề tách hai workload ra.

📌 Điểm cần nhớ

• Read Replica ≠ Multi-AZ. Read Replica: replication bất đồng bộ, có endpoint đọc riêng, dùng để scale workload đọc. Multi-AZ: replication đồng bộ, standby không đọc được, dùng cho high availability / failover. Đề nào nói "báo cáo/analytics/ETL làm chậm production" thì gần như chắc là Read Replica.
• Khi một workload đọc nặng (reporting, ETL, BI) làm phiền workload giao dịch, hướng xử lý đúng là tách nó sang endpoint khác, chứ không phải làm cho instance chung to lên.
• Nâng cấp instance type là giải pháp mua thời gian: nó dịch chuyển ngưỡng chịu tải chứ không sửa nguyên nhân. Đề nhấn "long term" là dấu hiệu loại phương án kiểu này.
• Athena federated query đọc được RDS, nhưng tải đọc vẫn nằm trên RDS. Đừng nhầm "đổi công cụ truy vấn" với "giảm tải cho database".

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

Đề mô tả một website nấu ăn lưu công thức và bình luận trong RDS Multi-AZ đặt ở private subnet. Từ hôm qua, người dùng gặp lỗi "Cannot connect to the database" — nghĩa là trước đó mọi thứ chạy bình thường, và có thứ gì đó vừa bị thay đổi.

Cụm từ quyết định là "As of yesterday" kết hợp với "anymore": đây không phải lỗi cấu hình sai từ đầu, mà là một thay đổi mới làm đứt đường mạng đang chạy tốt. Ràng buộc thứ hai là "(Select three)" — phải chọn đúng ba nguyên nhân có khả năng chặn kết nối. Vì hệ thống nằm trong VPC với database ở private subnet, đường đi từ web server tới RDS chỉ bị lọc bởi hai lớp: Security Group (mức instance) và Network ACL (mức subnet). Câu hỏi thực chất kiểm tra bạn có nắm được lớp nào stateful, lớp nào stateless.

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

B. DB Security Group inbound rules have changed — Security Group là firewall ảo ở mức instance/RDS. Kết nối từ web server tới database là traffic đi vào database, nên nó bị chặn hay cho qua bởi inbound rules của DB Security Group. Sửa rule inbound (ví dụ gỡ rule cho phép cổng database từ Security Group của web tier) là lập tức mất kết nối. Rule mới áp dụng ngay cho mọi tài nguyên gắn với Security Group đó, nên hậu quả xuất hiện tức thì như mô tả trong đề.

D. Network ACL inbound rules have changed — Network ACL là lớp lọc ở mức subnet, tuỳ chọn nhưng luôn tồn tại (subnet không gắn tường minh thì dùng NACL mặc định). Traffic từ web server đi vào subnet chứa database phải qua inbound rules của NACL gắn với subnet đó. Sửa hoặc thêm rule DENY là chặn kết nối.

A. Network ACL outbound rules have changed — Đây là điểm mấu chốt của câu hỏi. NACL là stateless: gói tin phản hồi cho một kết nối inbound đã được cho phép vẫn phải được outbound rules cho qua. Database trả kết quả về web server là traffic outbound khỏi subnet, thường trên dải ephemeral port. Nếu ai đó siết outbound rules mà quên dải cổng đó, request đi tới được database nhưng phản hồi không về nổi — ứng dụng thấy đúng như lỗi trong đề.

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

E. Security Group outbound rules have changed — Đây là bẫy đối xứng với đáp án A, và là phương án gần đúng nhất. Nó sai vì Security Group là stateful: khi một kết nối inbound đã được cho phép, phản hồi của kết nối đó tự động được đi ra, bất kể outbound rules là gì. Đúng lớp tài nguyên, đúng hướng traffic, nhưng sai đặc tính stateful/stateless — nên sửa outbound rules của Security Group không làm đứt kết nối đang có. Đây chính là chỗ NACL và Security Group hành xử khác nhau.

F. The primary database's private IP has changed — Private IP của RDS có thể đổi thật, chẳng hạn sau một lần Multi-AZ failover. Nhưng ứng dụng đúng chuẩn kết nối qua DNS endpoint của RDS, và endpoint đó không tự đổi khi IP thay đổi — AWS cập nhật bản ghi DNS trỏ sang instance mới. Đây là lý do tồn tại của endpoint. Nên bản thân việc IP đổi không phải nguyên nhân hợp lệ trong bối cảnh Multi-AZ.

C. A read replica has been created recently — Tạo read replica là thêm một tài nguyên đọc riêng, có endpoint riêng của nó. Thao tác này không sửa tên DNS của primary, không sửa Security Group hay NACL, và không cắt đường kết nối hiện hữu. Nó hoàn toàn không liên quan tới lỗi kết nối được mô tả.

📌 Điểm cần nhớ

• Security Group stateful, Network ACL stateless. Đây là ranh giới phân biệt gần như mọi câu hỏi dạng "traffic đi được mà không về được" trong VPC.
• Vì Security Group stateful nên outbound rules của nó gần như không bao giờ là nguyên nhân khiến một kết nối inbound đang chạy bị đứt — thấy phương án kiểu này thì nghi ngờ ngay.
• Vì NACL stateless nên cả inbound lẫn outbound rules của NACL đều là nghi phạm hợp lệ, kể cả với traffic chỉ đi một chiều về mặt logic; phản hồi thường dùng ephemeral port và rất hay bị quên.
• Luôn kết nối RDS bằng DNS endpoint, không bằng private IP. Multi-AZ failover đổi IP nhưng giữ nguyên endpoint; đây cũng là lý do "IP đã đổi" thường là phương án sai.
• Đề nói "hôm qua vẫn chạy, hôm nay hỏng" là tín hiệu tìm thay đổi cấu hình, không phải tìm lỗi thiết kế; tài nguyên mới được thêm vào (như read replica) thường chỉ là nhiễu.

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

Đề cho một yêu cầu rất gọn: tạo một subnet trong VPC chứa được ít nhất 28 EC2 instance, và hỏi kích thước nhỏ nhất (prefix dài nhất) đáp ứng được.

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

• "at least capacity for 28 EC2 instances" — đây là số địa chỉ IP dùng được thật sự, không phải tổng số địa chỉ trong dải CIDR. Trong mỗi subnet của AWS VPC, năm địa chỉ bị AWS giữ lại: bốn địa chỉ đầu (địa chỉ mạng, VPC router, DNS của Amazon, một địa chỉ dự phòng cho tương lai) và địa chỉ cuối (broadcast, AWS không dùng broadcast nhưng vẫn giữ chỗ). Năm địa chỉ này không gán được cho instance.
• "minimum size" — phải chọn dải nhỏ nhất còn đủ dùng, nên chỉ "đủ chỗ" thôi chưa thắng; phương án nào rộng hơn mức cần thiết sẽ bị loại vì không phải nhỏ nhất.

Với subnet /x, số IP gán được cho instance = 2^(32−x) − 5. Bài toán trở thành: tìm x lớn nhất sao cho 2^(32−x) − 5 ≥ 28.

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

Đáp án đúng theo tệp là B — /26.

Áp công thức:

• /26 → 2^(32−26) − 5 = 2^6 − 5 = 64 − 5 = 59 IP dùng được

59 ≥ 28, nên /26 thoả yêu cầu "ít nhất 28 instance". Và như phần dưới cho thấy, mọi prefix dài hơn /26 (tức subnet nhỏ hơn) đều tụt xuống dưới 28, nên /26 chính là kích thước nhỏ nhất còn dùng được — đúng cả hai vế của đề bài.

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

A — /28: 2^4 − 5 = 16 − 5 = 11 IP dùng được. Thiếu rất xa so với 28. Đây là subnet nhỏ nhất mà AWS cho phép tạo trong VPC, nhưng nhỏ nhất được phép không có nghĩa là đủ chỗ cho yêu cầu này.

D — /27: đây là phương án gần đúng và là cái bẫy chính. 2^5 = 32 địa chỉ — nhìn qua thì 32 > 28 nên rất dễ chọn. Nhưng trừ 5 địa chỉ AWS giữ lại: 32 − 5 = 27 IP dùng được, thiếu đúng một so với yêu cầu 28. Ai quên khoản 5 địa chỉ dành riêng, hoặc chỉ trừ 2 như thói quen tính subnet on-premises (network + broadcast), sẽ chọn nhầm ô này. Đề cố tình đặt con số 28 sát ngay ranh giới để phân biệt người có nhớ quy tắc 5 địa chỉ của AWS hay không.

C — /25: 2^7 − 5 = 128 − 5 = 123 IP dùng được. Về mặt kỹ thuật thì hoàn toàn chứa được 28 instance, nhưng đề hỏi minimum size. /25 rộng gấp đôi /26, mà /26 đã đủ — nên nó thoả yêu cầu dung lượng nhưng trượt ở yêu cầu "nhỏ nhất". Chọn nó còn lãng phí không gian địa chỉ của VPC, khiến sau này khó chia thêm subnet.

📌 Điểm cần nhớ

• Trong subnet của AWS VPC, luôn trừ 5 địa chỉ khỏi tổng số IP: bốn địa chỉ đầu và một địa chỉ cuối. Công thức dùng được cho mọi câu dạng này: IP gán được = 2^(32 − prefix) − 5.
• Đừng mang thói quen "trừ 2" của mạng truyền thống sang AWS — chênh lệch 3 địa chỉ đủ để làm sai một câu hỏi đặt số liệu sát ranh giới, như /27 ở đây chỉ thiếu đúng 1 IP.
• Đọc kỹ đề hỏi "minimum/smallest" hay chỉ "which can hold": nếu hỏi nhỏ nhất thì các dải rộng hơn (như /25) vẫn sai dù về dung lượng thì thừa sức.
• Prefix càng lớn thì subnet càng nhỏ; /28 là subnet nhỏ nhất AWS cho phép trong VPC, tương ứng chỉ 11 IP gán được cho instance.

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

Đề mô tả một bastion host với security group được cho là "chỉ cho SSH từ IP của tôi", nhưng VPC Flow Logs (truy vấn bằng Athena) lại cho thấy rất nhiều instance có IP dạng 172.XXX.XXX.XXX cũng SSH được vào máy này. Câu hỏi là: tại sao?

Cụm từ quyết định nằm ở chính ảnh chụp security group — đề nói rõ "the second rule", tức là security group này không chỉ có một rule. Cụm thứ hai là dải IP 172.XXX.XXX.XXX: đây là dải private, tức lưu lượng đến từ bên trong VPC, không phải từ Internet. Ghép hai chi tiết đó lại: có một inbound rule thứ hai cho phép SSH, và nguồn của nó là thứ nằm trong VPC — cụ thể là một security group khác, chứ không phải một CIDR công cộng.

Ràng buộc ngầm cần nhớ: security group cộng dồn (aggregate) mọi rule của nó, và mọi rule đều là allow, không có rule deny. Vì vậy "tôi đã giới hạn theo IP" không bao giờ đồng nghĩa với "chỉ IP đó vào được" nếu còn rule khác.

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

A — The second rule allows EC2 instances from an entire security group to SSH into your bastion host.

Trong AWS, nguồn (source) của một inbound rule không nhất thiết phải là CIDR; nó có thể là id của một security group khác. Khi đặt như vậy, mọi EC2 instance được gắn security group đó đều được phép mở kết nối tới port tương ứng — bất kể instance ấy có bao nhiêu cái và IP private là gì. Đó chính xác là những địa chỉ 172.x.x.x xuất hiện trong Flow Logs.

Cơ chế đánh giá của security group giải thích phần còn lại: khi quyết định có cho gói tin đi vào hay không, AWS gộp toàn bộ rule của tất cả security group gắn vào instance rồi cho qua nếu bất kỳ rule nào khớp. Security group là permissive-only — bạn không viết được rule từ chối để "trừ bớt" rule kia. Nên rule số một (SSH từ IP cá nhân, /32) vẫn đúng và vẫn có hiệu lực, nhưng nó không hề thu hẹp rule số hai. Kết quả: hai đường vào song song, và đường thứ hai mở cho cả một security group.

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

B — The IP rule should be 109.190.217.138/0. Đây là phương án gần đúng về mặt "sửa rule IP", nhưng hỏng ở chỗ hiểu ngược ý nghĩa của prefix. /32 là dạng hẹp nhất, khớp đúng một địa chỉ duy nhất — tức rule hiện tại đã đúng như ý định "chỉ IP của tôi". Ngược lại /0 bỏ qua toàn bộ 32 bit, khớp mọi địa chỉ từ 0.0.0.0 đến 255.255.255.255. Làm theo phương án này là mở SSH cho cả thế giới, đúng cái ngược lại điều cần. Ngoài ra rule IP cũng không phải nơi phát sinh lưu lượng 172.x.x.x — nguồn đó đến từ rule thứ hai.

C — The NACL rules are too open. Đây là distractor có vẻ hợp lý vì NACL cũng lọc traffic. Nhưng NACL và security group là hai lớp nối tiếp nhau: gói tin phải qua cả hai mới tới được instance. NACL mở rộng không tự sinh ra quyền — security group vẫn là chốt chặn cuối cùng và vẫn từ chối được. Nói cách khác, nếu security group thật sự chỉ cho một IP, thì NACL dù mở toang cũng không có instance 172.x.x.x nào SSH vào được. Hiện tượng đang thấy chỉ giải thích được bằng một rule allow trong chính security group.

D — Someone is attacking your EC2 instance, use AWS Inspector to verify that. Sai ở cả chẩn đoán lẫn công cụ. Về chẩn đoán: lưu lượng đến từ dải private nội bộ VPC và được cho qua bởi một rule hợp lệ — đó là cấu hình đúng như đã khai, không phải dấu hiệu bị tấn công. Về công cụ: Amazon Inspector là dịch vụ đánh giá bảo mật tự động (kiểm tra khả năng tiếp cận qua mạng và tình trạng bảo mật của phần mềm trên instance), không phải công cụ điều tra ai đang SSH vào máy bạn ngay lúc này — thứ đang cho thấy điều đó chính là VPC Flow Logs mà đề đã dùng.

📌 Điểm cần nhớ

• Security group chỉ có rule allow và cộng dồn tất cả rule; thêm một rule chặt hơn không bao giờ làm hẹp rule lỏng hơn. Muốn siết thì phải xoá rule kia.
• Source của inbound rule có thể là CIDR hoặc id của security group khác. Dạng thứ hai cấp quyền cho toàn bộ instance mang security group đó — hãy đọc kỹ cột Source, đừng chỉ nhìn port.
• Thấy IP nguồn thuộc dải private (10.x, 172.16–31.x, 192.168.x) trong Flow Logs nghĩa là traffic phát sinh trong VPC, hướng điều tra là rule tham chiếu security group, không phải rule CIDR công cộng.
• Prefix CIDR: /32 = đúng một địa chỉ, /0 = mọi địa chỉ. Đề thi rất hay đánh tráo hai giá trị này.
• NACL là lớp bổ sung ở mức subnet, stateless; security group ở mức instance, stateful. NACL lỏng không phá được một security group chặt.