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

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

Đề mô tả một công ty đang dùng AWS Storage Gateway ở chế độ volume gateway, và máy ảo (VM) chạy gateway đó cần được reboot — ví dụ để vá hypervisor hoặc bảo trì phần cứng bên dưới. Câu hỏi là: quy trình reboot đúng gồm những bước nào, theo thứ tự nào?

Cụm từ quyết định đáp án là "volume gateway" kết hợp với "the virtual machine ... must be rebooted". Đây là câu hỏi về thứ tự thao tác, không phải về kiến trúc: cả bốn phương án đều nhắc tới gateway và VM, chỉ khác nhau ở chỗ cái nào dừng trước, cái nào khởi động sau. Loại gateway là chi tiết quan trọng vì quy trình bảo trì khác nhau giữa file gateway và volume/tape gateway — với file gateway thì tắt thẳng VM là đủ, còn với volume gateway thì phải dừng gateway trước đã. Đề nói rõ là volume gateway, nên nhánh "dừng gateway trước" là nhánh phải chọn.

Lý do đằng sau: volume gateway giữ dữ liệu trong bộ nhớ đệm cục bộ (cache và upload buffer) và đang có các thao tác ghi/đồng bộ dở dang lên AWS. Dừng gateway trước cho phép nó kết thúc gọn các thao tác đó và đưa volume về trạng thái an toàn, thay vì bị cắt điện giữa chừng.

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

B — "Stop the gateway, reboot the virtual machine, then restart the gateway" là đáp án đúng theo tệp và cũng khớp với hướng dẫn bảo trì của AWS Storage Gateway.

Trình tự ba bước này đúng vì mỗi bước phục vụ đúng một mục đích:

1. Stop the gateway — thao tác này thực hiện từ phía Storage Gateway (console hoặc API), báo cho gateway ngừng nhận I/O mới và đưa volume về trạng thái dừng có kiểm soát trước khi lớp máy ảo bên dưới biến mất.
2. Reboot the VM — lúc này việc khởi động lại máy ảo chỉ còn là thao tác hạ tầng thuần tuý; không có ghi dở dang nào bị cắt ngang.
3. Restart the gateway — sau khi VM lên lại, khởi động gateway để nó nối lại với dịch vụ AWS và đưa volume trở về trạng thái phục vụ.

Điểm mấu chốt: trạng thái của gateway và trạng thái của VM là hai thứ tách rời nhau. VM lên không có nghĩa gateway đã sẵn sàng, nên bước khởi động gateway ở cuối là bắt buộc chứ không phải tuỳ chọn.

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

A — "Synchronize the gateway, then reboot the virtual machine." Đây là phương án nghe hợp lý nhất trong ba phương án sai, vì ý "đồng bộ trước khi tắt" đúng về tinh thần. Nhưng nó hỏng ở hai chỗ: Storage Gateway không có thao tác bảo trì tên là "synchronize" để người vận hành gọi trước khi tắt máy; và quan trọng hơn, nó bỏ hẳn bước dừng gateway — reboot VM khi gateway vẫn đang ở trạng thái hoạt động chính là điều quy trình bảo trì muốn tránh. Đúng một nửa ý tưởng nhưng sai tên thao tác và thiếu bước bắt buộc.

C — "Stop the virtual machine, restart the gateway, then turn on the virtual machine." Thứ tự này tự mâu thuẫn về mặt logic. Gateway chạy bên trong VM, nên khi VM đã bị tắt thì không có gì để "restart the gateway" tác động lên cả — không tồn tại tiến trình gateway nào đang chạy để khởi động lại. Phương án đảo ngược quan hệ phụ thuộc giữa hai lớp: VM là nền, gateway là phần mềm nằm trên nền đó, không thể khởi động phần mềm khi nền đã tắt.

D — "Reboot the gateway, then reboot the virtual machine." Phương án này thiếu bước dừng gateway đúng cách và cũng thừa một thao tác vô nghĩa. Reboot gateway rồi lại reboot VM ngay sau đó nghĩa là gateway vừa khởi động xong đã bị cắt ngang bởi lần reboot VM — đúng vào tình huống mà quy trình bảo trì muốn tránh. Ngoài ra nó không có bước khởi động lại gateway sau khi VM lên, nên kết thúc quy trình gateway không ở trạng thái được chủ động đưa về phục vụ.

📌 Điểm cần nhớ

• Volume gateway và tape gateway: quy trình bảo trì VM là stop gateway → reboot VM → start gateway. File gateway: chỉ cần tắt VM, không có bước dừng gateway riêng. Đề nhắc loại gateway nào là để bạn chọn đúng nhánh này.
• Trạng thái gateway ≠ trạng thái VM. Gateway là phần mềm chạy trong VM và có vòng đời riêng quản lý từ phía AWS Storage Gateway; VM khởi động lại không tự đưa gateway về trạng thái phục vụ, nên bước start gateway ở cuối luôn phải có.
• Dừng gateway trước là để bảo vệ dữ liệu đang nằm trong cache và upload buffer cục bộ, chưa kịp đẩy lên AWS. Cắt VM khi gateway đang hoạt động là cắt ngang các thao tác này.
• Với dạng câu hỏi hỏi thứ tự thao tác, hãy loại trước những phương án tự mâu thuẫn về mặt phụ thuộc (thao tác lên phần mềm sau khi đã tắt nền chạy nó) — như phương án C — rồi mới so những phương án còn lại theo tài liệu.

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

Đề mô tả một SysOps Administrator cần kiểm tra xem tài khoản root của AWS account có đang tuân theo các security best practice hay không.

Cụm từ quyết định đáp án là "verify that security best practices are being followed" và "How can the Administrator check?". Đây là câu hỏi về kiểm tra / rà soát trạng thái cấu hình, chứ không phải về thực hiện một biện pháp bảo mật nào đó. Ràng buộc thứ hai nằm ở "with the AWS account root user" — phạm vi là tài khoản của khách hàng, không phải nền tảng AWS.

Hai cụm này tách các phương án làm hai nhóm rõ rệt: nhóm làm gì đó (xoay access key, đổi mật khẩu) và nhóm đọc báo cáo (Trusted Advisor, Artifact). Vì đề hỏi "check", nhóm thứ nhất bị loại ngay; và trong nhóm thứ hai, cụm "root user" của chính account mình quyết định nốt phần còn lại.

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

C — Use AWS Trusted Advisor security checks to review the configuration of the root user.

AWS Trusted Advisor là công cụ rà soát tài khoản của bạn theo các khuyến nghị best practice của AWS và đưa ra khuyến cáo gần như theo thời gian thực. Trong nhóm kiểm tra Security của Trusted Advisor có sẵn những mục nhắm thẳng vào tài khoản root — ví dụ kiểm tra xem root user đã bật MFA hay chưa. Đúng bản chất việc mà đề yêu cầu: xem lại cấu hình hiện tại của root user và đối chiếu với best practice, không cần Administrator tự viết script hay tự đi dò từng thiết lập.

Đây cũng là dịch vụ duy nhất trong bốn phương án vừa (1) hoạt động theo hướng đọc và đánh giá thay vì thay đổi, vừa (2) soi vào chính AWS account của khách hàng.

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

A — Periodically use the AWS CLI to rotate access keys and secret keys for the root user. Đây là phương án gần đúng nhất và dễ gây phân vân, vì xoay vòng access key đúng là một best practice thật. Nhưng nó hỏng ở hai chỗ. Thứ nhất, nó là hành động thực thi một biện pháp, không phải kiểm tra xem best practice có được tuân thủ hay không — lệch hẳn với chữ "check" trong đề. Thứ hai, best practice của AWS đối với root user là không tạo và không dùng access key cho root ngay từ đầu; xoay vòng khoá root bằng CLI không phải cách triển khai được khuyến nghị.

B — Change the root user password by using the AWS CLI regularly. Cũng là hành động thay đổi cấu hình chứ không phải kiểm tra, nên trượt ngay ở tiêu chí của đề. Ngoài ra việc đổi mật khẩu root định kỳ qua CLI không phải là biện pháp bảo mật được AWS khuyến nghị cho root user — trọng tâm với root là bật MFA, khoá kỹ thông tin đăng nhập và hạn chế tối đa việc dùng đến nó.

D — Periodically run reports using AWS Artifact that verify that security standards are being met. Đây là bẫy "đúng động từ, sai phạm vi": Artifact đúng là nơi lấy báo cáo tuân thủ, nhưng những báo cáo đó nói về sự tuân thủ của chính nền tảng AWS (các chứng nhận, kiểm toán của hạ tầng AWS mà bạn tải về để cung cấp cho bên kiểm toán của mình). Artifact không rà soát cấu hình bên trong AWS account của khách hàng, nên không thể cho biết root user của bạn đã bật MFA hay chưa.

📌 Điểm cần nhớ

• Đọc kỹ động từ của đề: "check / verify / review" → hướng tới công cụ đánh giá cấu hình (Trusted Advisor); "enforce / implement / rotate" → hướng tới hành động cấu hình. Nhiều phương án đúng về mặt bảo mật vẫn sai vì trả lời nhầm loại câu hỏi.
• Trusted Advisor soi tài khoản của bạn; AWS Artifact soi nền tảng AWS. Đây là cặp dễ lẫn nhất trong các câu về compliance — cứ hỏi "báo cáo này nói về ai?" là tách được.
• Với root user, best practice là bật MFA và tránh dùng root cho công việc hằng ngày, chứ không phải chăm chỉ xoay vòng access key của root — root lý tưởng là không có access key.
• Trusted Advisor có nhiều nhóm kiểm tra (trong đó có Security); trong đề thi, cứ thấy "review configuration against AWS best practices" là nghĩ ngay tới nó.

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

Đề mô tả một ứng dụng được triển khai bằng AWS CloudFormation: EC2 instances nằm trong Auto Scaling group, phía trước là Application Load Balancer (ALB). Cần đưa phiên bản mới của ứng dụng lên.

Hai ràng buộc trong câu cuối là thứ quyết định đáp án:

• "must avoid DNS changes" — không được đổi bản ghi DNS. Tức là endpoint mà người dùng truy cập phải giữ nguyên, không được dựng một ALB mới rồi trỏ Route 53 sang.
• "support rollback" — phải quay lui được nếu bản mới hỏng.

Và có một ràng buộc ngầm nhưng rất quan trọng, nằm ngay câu đầu: ứng dụng được quản lý bởi CloudFormation stack. Khi hạ tầng do CloudFormation quản lý, mọi thay đổi phải đi qua stack update. Sửa thẳng tài nguyên bằng console hay API là tạo ra stack drift — trạng thái thực tế lệch khỏi template, và lần update sau CloudFormation có thể ghi đè hoặc xử lý sai vì nó tin vào template chứ không tin vào thực tế.

Ba chữ khoá cần soi qua từng phương án: đi qua CloudFormation, không đổi DNS, rollback được.

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

D — Sửa template để dùng AutoScalingReplacingUpdate policy, cập nhật stack, rồi cập nhật lần hai với bản phát hành mới.

AutoScalingReplacingUpdate là một UpdatePolicy attribute của CloudFormation, khai ngay trên tài nguyên Auto Scaling group. Nó quy định cách CloudFormation xử lý update kiểu thay thế: tạo hẳn một Auto Scaling group mới với cấu hình mới, chờ nhóm mới đạt trạng thái tốt, rồi mới xoá nhóm cũ. Điều này thoả cả ba ràng buộc:

• Đi qua CloudFormation: thay đổi nằm trong template, stack luôn phản ánh đúng thực tế, không có drift.
• Không đổi DNS: ALB không bị thay — Auto Scaling group mới gắn vào chính target group của ALB đang có. Tên miền, Alias record của Route 53, endpoint của ALB đều giữ nguyên.
• Rollback được: nếu nhóm mới không đạt tín hiệu thành công, CloudFormation giữ lại nhóm cũ và trả stack về trạng thái trước đó. Đây là cơ chế rollback có sẵn của chính stack update, không phải quy trình thủ công.

Chi tiết "perform a second update" phản ánh trình tự thực tế: lần update thứ nhất chỉ đưa update policy vào template (bản thân việc thêm attribute này không thay đổi tài nguyên), lần update thứ hai mới mang code mới lên và lúc đó policy đã sẵn sàng để điều khiển quá trình thay thế.

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

A — Lifecycle hooks trên Auto Scaling group. Lifecycle hooks là điểm dừng để chạy việc gì đó lúc instance đang vào hoặc rời nhóm (cài phần mềm, rút log, đăng ký dịch vụ). Chúng không phải là cơ chế triển khai phiên bản mới, và ở đây bạn đang thao tác trực tiếp lên Auto Scaling group thay vì cập nhật stack. Kết quả là drift, và cũng không có cơ chế rollback tự động nào của CloudFormation áp dụng cho thay đổi làm ngoài stack. Đây là phương án nghe hợp lý về mặt vận hành nhưng bỏ qua đúng cái ràng buộc "ứng dụng do CloudFormation quản lý".

B — Tạo AMI mới, tạo launch configuration mới, cập nhật Auto Scaling group dùng launch configuration đó. Về mặt kỹ thuật thuần tuý thì đây là cách phát hành phổ biến, và nó cũng không đổi DNS. Nhưng nó hỏng ở đúng chỗ giống A: launch configuration và Auto Scaling group là tài nguyên trong stack, sửa chúng trực tiếp gây stack drift. Ngoài ra chỉ đổi launch configuration thôi thì các instance đang chạy vẫn giữ code cũ cho tới khi bị thay, và không có cơ chế rollback do stack quản lý. Đây là phương án gần đúng nhất — nó thua D chỉ vì đi vòng qua lưng CloudFormation.

C — Dựng stack CloudFormation thứ hai, chờ ứng dụng sẵn sàng, chuyển sang ALB mới. Đây là kiểu blue/green ở mức stack. Nó rollback rất tốt (stack cũ còn nguyên), nhưng vi phạm thẳng ràng buộc lớn nhất: stack mới có ALB mới, mà mỗi ALB có DNS name riêng. Muốn người dùng đi sang stack mới thì phải cập nhật bản ghi Route 53 (hoặc Alias record tương đương) đang trỏ tới ALB cũ. Đề đã nói rõ "must avoid DNS changes", nên phương án này bị loại ngay từ câu đó.

📌 Điểm cần nhớ

• Tài nguyên do CloudFormation tạo thì phải sửa qua CloudFormation. Bất kỳ phương án nào mô tả việc thao tác trực tiếp lên Auto Scaling group, launch configuration hay EC2 đều là bẫy drift trong đề thi CloudOps.
• Cụm "avoid DNS changes" loại thẳng mọi phương án tạo load balancer mới. ALB mới ⇒ DNS name mới ⇒ phải sửa Route 53. Blue/green ở mức stack chỉ đúng khi đề cho phép đổi DNS.
• UpdatePolicy là nơi CloudFormation điều khiển cách thay thế instance: AutoScalingReplacingUpdate thay cả Auto Scaling group (nhóm mới song song, xoá nhóm cũ khi thành công), còn AutoScalingRollingUpdate thay dần instance ngay trong nhóm hiện có. Cả hai đều dùng cơ chế rollback sẵn có của stack update.
• Lifecycle hooks phục vụ vòng đời instance, không phải chiến lược phát hành. Thấy nó xuất hiện như "cách deploy phiên bản mới" thì gần như chắc là phương án nhiễu.

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

Đề mô tả một SysOps Administrator được giao việc tìm cơ hội tiết kiệm chi phí bằng cách thu nhỏ (downsizing) các EC2 instance đang bị dùng dưới công suất. Cụm từ quyết định đáp án nằm ở câu hỏi cuối: "with MINIMAL effort" — nghĩa là bài toán không hỏi "cách nào làm được", mà hỏi cách nào tốn ít công sức quản trị nhất.

Đây là điểm mấu chốt, vì cả bốn phương án đều xoay quanh dữ liệu sử dụng tài nguyên và ít nhiều đều có thể dẫn tới kết quả. Khác biệt duy nhất là ai làm phần việc phân tích: bạn tự dựng lấy quy trình đo đạc và diễn giải số liệu, hay dùng một tính năng AWS đã đóng gói sẵn để nó trả ra khuyến nghị hoàn chỉnh. Thêm một ràng buộc phụ nữa: kết quả mong muốn là khuyến nghị downsizing cụ thể, chứ không phải một biểu đồ số liệu thô hay một cảnh báo.

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

C — Use AWS Cost Explorer to generate resource optimization recommendations.

AWS Cost Explorer có chức năng sinh EC2 resource optimization recommendations: nó chỉ ra các instance đang idle hoặc underutilized trên phạm vi nhiều account và nhiều region. Để làm việc đó, AWS tự phân tích lịch sử sử dụng tài nguyên EC2, các metric CloudWatch tương ứng và cả tình trạng reservation hiện có, rồi đưa ra hướng xử lý — chấm dứt instance đang nằm không, hoặc hạ instance đang chạy xuống loại rẻ hơn.

Nói cách khác, Cost Explorer đã làm sẵn toàn bộ phần khó: thu thập metric, đối chiếu theo thời gian, quy đổi ra tiền và đề xuất size thay thế. Người quản trị chỉ việc bật báo cáo lên và đọc danh sách. Đúng tinh thần "MINIMAL effort" mà đề yêu cầu.

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

A — Use Amazon CloudWatch metrics to identify EC2 instances with low utilization. Đây là phương án gần đúng nhất, và cũng là cái bẫy chính. CloudWatch đúng là nguồn dữ liệu để biết instance nào ít được dùng — bản thân Cost Explorer cũng dựa trên chính metric đó. Nhưng nếu tự làm theo hướng này, bạn phải tự chọn metric, tự đặt ngưỡng thế nào là "thấp", tự soi từng instance qua từng region, rồi tự quy đổi sang loại instance nhỏ hơn nên dùng. Đó là dữ liệu thô, chưa phải khuyến nghị — nhiều công sức hơn hẳn phương án C, nên trượt ở tiêu chí "MINIMAL effort".

B — Use AWS Budgets to generate alerts for underutilized EC2 instances. Phương án này sai về bản chất chức năng, không chỉ sai về công sức. AWS Budgets theo dõi chi tiêu và mức sử dụng so với ngưỡng ngân sách bạn đặt ra, rồi cảnh báo khi chạm ngưỡng đó. Nó nói cho bạn biết "tháng này tiêu quá số tiền dự kiến", chứ không báo cáo về việc tài nguyên bị dùng dưới công suất. Một EC2 instance chạy không tải suốt tháng vẫn hoàn toàn nằm trong ngân sách và Budgets sẽ im lặng.

D — Run an AWS Lambda function that checks for utilization of EC2 instances. Về lý thuyết thì làm được: viết code gọi API lấy metric, so ngưỡng, xuất báo cáo. Nhưng đây là phương án tốn công nhất trong cả bốn: phải viết hàm, cấp IAM permission, đặt lịch chạy, xử lý phân trang qua nhiều account/region, rồi bảo trì đoạn code đó về sau. Nó dựng lại bằng tay đúng thứ Cost Explorer đã cung cấp sẵn — mâu thuẫn trực diện với chữ "MINIMAL effort" trong đề.

📌 Điểm cần nhớ

• Khi đề có "MINIMAL effort", "least operational overhead" hay "least administrative effort", hãy ưu tiên tính năng dựng sẵn (managed feature) thay vì tự viết Lambda/script — kể cả khi giải pháp tự viết cũng ra đúng kết quả.
• Phân biệt vai trò: CloudWatch cung cấp metric thô, còn Cost Explorer biến metric đó thành khuyến nghị tối ưu kèm quy đổi chi phí. Đề hỏi "recommendations" thì chọn cái thứ hai.
• AWS Budgets là công cụ cảnh báo theo ngưỡng chi tiêu/sử dụng, không phải công cụ phát hiện tài nguyên nhàn rỗi. Gặp phương án dùng Budgets để "tìm underutilized resources" thì gần như chắc chắn là mồi nhử.
• Phương án viết Lambda tự kiểm tra hầu như luôn sai trong nhóm câu hỏi so sánh công sức vận hành, trừ khi đề nêu rõ một yêu cầu tuỳ biến mà dịch vụ có sẵn không đáp ứng được.

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

Đề mô tả tình huống: AWS gửi thông báo rằng một Amazon EC2 instance đang nằm trên một host bị suy giảm (degraded host) và host đó đã được lên lịch retirement, đúng vào giờ làm việc trọng yếu. Câu hỏi: làm gì để MINIMIZE disruption — giảm gián đoạn tới mức thấp nhất.

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

• "scheduled for retirement" — đây là một sự kiện đã được báo trước, có mốc thời gian cụ thể. Người vận hành có toàn quyền hành động trước mốc đó, không bị ép phải làm ngay lập tức.
• "during business-critical hours" — nghĩa là nếu để AWS tự retire host, instance sẽ bị dừng đúng lúc không được phép dừng. Vậy việc cần làm là chủ động chọn thời điểm downtime, dời nó ra ngoài giờ làm việc.
• "MINIMIZE disruption" — không phải "loại bỏ hoàn toàn downtime". Đề chấp nhận có gián đoạn; điều cần tối ưu là khi nào nó xảy ra.

Ghép lại: cần một thao tác vừa đưa instance sang host vật lý khác, vừa chạy được vào khung giờ do mình chọn.

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

D — Stop/start the instance outside business hours to move to a new host before the scheduled retirement.

Với EC2 instance dùng EBS-backed root volume, thao tác stop rồi start khiến instance được đặt lại lên một underlying host mới khi khởi động. Đây chính là cơ chế tiêu chuẩn để "thoát" khỏi một host đang có vấn đề hoặc sắp bị retire — chỉ có stop/start mới kích hoạt việc chọn lại chỗ đặt (placement) trên phần cứng vật lý.

Vì thông báo retirement được gửi trước, người quản trị chủ động thực hiện stop/start ngoài giờ làm việc. Kết quả: instance rời khỏi host suy giảm trước hạn, và khoảng downtime duy nhất là vài phút stop/start do chính mình sắp xếp — không rơi vào business-critical hours. Đó đúng là "minimize disruption" trong ngữ cảnh đề.

Lưu ý kèm theo khi làm thật: instance dùng instance store sẽ mất dữ liệu ephemeral, và public IPv4 không phải Elastic IP sẽ đổi sau khi stop/start.

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

A — Restart the instance outside business hours to perform the system maintenance before the scheduled retirement.

Phương án này đúng ở phần chọn thời điểm (ngoài giờ làm việc) nên trông rất gần đáp án, nhưng hỏng ở chính hành động. Restart (reboot) không đưa instance sang host khác — nó chỉ khởi động lại hệ điều hành, còn instance vẫn nằm nguyên trên đúng cái host suy giảm đó. Khi tới giờ retirement, instance vẫn bị dừng giữa giờ làm việc. Chọn đúng thời điểm cho một thao tác không giải quyết được vấn đề thì vẫn không giúp gì.

B — Write an AWS Lambda function to migrate the EC2 instance between hosts.

Không tồn tại API action nào cho phép "di chuyển instance giữa các host" để Lambda gọi. Việc đặt instance lên host vật lý nào là do AWS quyết định, người dùng không điều khiển trực tiếp được; cách duy nhất tác động là stop/start. Vậy hàm Lambda này viết ra cũng không có gì để gọi. Ngoài ra, đây còn là hướng phức tạp hóa một việc chỉ cần hai thao tác console.

C — Restart the EC2 instance as immediately to ensure the application is not taken offline when the host is retired.

Sai kép. Thứ nhất, restart vẫn không đổi host — giống lỗi của phương án A. Thứ hai, làm ngay lập tức nghĩa là gây gián đoạn ngay trong giờ làm việc trọng yếu, đi ngược hẳn yêu cầu "minimize disruption". AWS đã báo trước có deadline, nên không có lý do gì phải hành động khẩn cấp; sự vội vàng ở đây chỉ tạo thêm downtime chứ không tránh được downtime nào.

📌 Điểm cần nhớ

• Reboot/restart ≠ stop/start. Reboot giữ nguyên underlying host; chỉ stop rồi start mới khiến EBS-backed instance được đặt lên host mới. Đề thi rất hay dựng cặp phương án chỉ khác nhau ở chỗ này.
• Khi nhận scheduled event của EC2 (retirement, maintenance, reboot), đó là thông báo có deadline — việc cần làm là chủ động chọn thời điểm xử lý trước hạn, không phải hành động tức thì.
• Với từ khóa MINIMIZE disruption kèm mốc thời gian trong đề, hãy tìm phương án dịch downtime ra khỏi khung giờ nhạy cảm, chứ đừng tìm phương án hứa hẹn không downtime.
• Không có API để chỉ định hay đổi host vật lý của một EC2 instance thông thường, nên mọi phương án kiểu "viết code tự động migrate giữa host" đều là bẫy.
• Trước khi stop/start, nhớ hai hệ quả: dữ liệu trên instance store bị mất, và public IPv4 không phải Elastic IP sẽ thay đổi.

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

Đề mô tả một tình huống rất cụ thể: cần tạo record set trong Amazon Route 53 để trỏ về một Application Load Balancer (ALB), nhưng hosted zone và ALB nằm ở hai account khác nhau. Câu hỏi kết bằng "MOST cost-effective and efficient solution".

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

• "in different accounts" — cụm này tồn tại để dụ người học nghĩ rằng phải làm thêm một việc gì đó để bắc cầu giữa hai account (sao chép hosted zone, dựng thêm ALB, thêm một lớp CNAME). Thực tế đây là bẫy: ranh giới account không cản trở việc trỏ DNS.
• "MOST cost-effective and efficient" — đề không hỏi "cái nào chạy được" mà hỏi "cái nào rẻ nhất và ít việc nhất". Nhiều phương án dưới đây về mặt kỹ thuật vẫn cho ra kết quả, nhưng đắt hơn hoặc phức tạp hơn. Ràng buộc này là thứ loại bỏ phương án C và D.

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

B — Create an alias record in the hosted zone pointing to the Application Load Balancer.

Alias record của Route 53 trỏ được tới tài nguyên nằm ở account khác. Việc cần làm chỉ là lấy tên miền đầy đủ (fully qualified domain name) của ALB ở account kia rồi điền vào khi tạo record set trong hosted zone. Không cần thiết lập quan hệ tin cậy nào giữa hai account cho riêng chuyện DNS này, cũng không cần sao chép hay dựng thêm hạ tầng.

Hai lý do khiến nó khớp với cả "cost-effective" lẫn "efficient":

• Route 53 không tính phí cho truy vấn giải tới alias record trỏ vào tài nguyên AWS như ALB — trong khi record thường (ví dụ CNAME) thì có tính phí truy vấn.
• Cấu hình tối thiểu: đúng một record, không thêm thành phần nào phải vận hành và theo dõi về sau.

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

A — Create an asynchronous replica of the hosted zone in the account with the ALB. Route 53 không có khái niệm "asynchronous replica" của hosted zone. Đây là phương án bịa ra một tính năng không tồn tại, nên không cần bàn tới chuyện rẻ hay hiệu quả. Kiểu mồi này khá phổ biến trong đề: nghe rất hợp lý với người quen từ "replica" ở các dịch vụ database, nhưng đem sang DNS thì vô nghĩa.

C — Create a CNAME record in the hosted zone pointing to an alias record to the ALB. Đây là phương án gần đúng nhất, và cũng là nơi dễ mất điểm nhất, vì về mặt kỹ thuật nó có thể phân giải được. Nó hỏng ở hai chỗ, đúng theo hai tiêu chí đề nêu:

• Chi phí: CNAME record phát sinh phí truy vấn, còn alias thì không. Đã thêm CNAME là mất đi đúng lợi thế giá của alias.
• Hiệu quả: nó dựng hai lớp record chồng lên nhau (CNAME → alias → ALB) trong khi một alias là đủ. Thêm một mắt xích nghĩa là thêm một chỗ có thể cấu hình sai và thêm một chỗ phải bảo trì, mà chẳng đổi lại được gì.

D — Create an ALB in the same account as the hosted zone and forward connections cross-account to the other ALB. Đây là phương án tốn kém nhất trong cả bốn: dựng thêm hẳn một Application Load Balancer chỉ để làm nhiệm vụ chuyển tiếp. ALB thứ hai này phải trả phí chạy thường trực cộng phí xử lý lưu lượng, chưa kể thêm một chặng mạng trên đường đi của mọi request và thêm một thành phần phải cấu hình, giám sát, vá lỗi. Nó vi phạm cả "cost-effective" lẫn "efficient", trong khi vấn đề gốc chỉ là một bản ghi DNS.

📌 Điểm cần nhớ

• Alias record trỏ được sang tài nguyên ở account khác — chỉ cần DNS name của tài nguyên đó. Thấy đề nói "different accounts" đừng vội kết luận là phải dựng thêm hạ tầng bắc cầu.
• Alias vs CNAME: alias tới tài nguyên AWS thì truy vấn không tính phí, còn CNAME thì có. Khi đề nhấn "cost-effective" mà cả hai cùng xuất hiện trong danh sách phương án, alias gần như luôn là đáp án.
• Alias record còn đặt được ở zone apex (tên miền gốc), chỗ mà CNAME theo chuẩn DNS không dùng được — một lý do nữa để mặc định nghĩ tới alias khi trỏ về ALB, CloudFront hay S3 static website.
• Phương án dựng thêm một load balancer chỉ để chuyển tiếp hầu như luôn sai trong các câu hỏi tối ưu chi phí: nó thêm tài nguyên tính tiền theo giờ và thêm một chặng mạng để giải một bài toán vốn thuộc tầng DNS.

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

Đề mô tả một kiến trúc ba tầng chạy trong một Amazon VPC: một Application Load Balancer (ALB), hai EC2 instance làm web server, và hai EC2 instance làm database. Câu hỏi chỉ hỏi đúng một chuyện: mỗi tầng nên đặt vào public subnet hay private subnet.

Cụm từ quyết định nằm ở cuối câu mô tả yêu cầu: "public access must be limited as much as possible" — hạn chế truy cập công khai tới mức tối đa có thể. Chữ "as much as possible" mới là ràng buộc phân biệt, vì cả bốn phương án đều đặt ALB ở public subnet trong mỗi AZ, tức là phần high availability và phần ALB không phân biệt được gì. Điểm khác nhau duy nhất giữa A, B, C, D là web server và database nằm ở loại subnet nào. Khi đề đã yêu cầu giảm bề mặt công khai tối đa, đáp án phải là phương án đẩy được nhiều tầng nhất vào private subnet mà vẫn chạy được.

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

Đáp án là C: public subnet trong mỗi AZ cho ALB, private subnet trong mỗi AZ cho web server, private subnet trong mỗi AZ cho database.

• ALB là internet-facing, nó phải nhận request từ Internet nên bắt buộc nằm trong public subnet. Đây là tầng duy nhất thực sự cần lộ ra ngoài.
• Web server không cần địa chỉ công khai. Một internet-facing ALB hoàn toàn có thể có target group là các EC2 instance nằm trong private subnet — ALB chuyển tiếp lưu lượng tới target qua mạng nội bộ của VPC. Điều kiện là các public subnet của ALB phải nằm cùng những AZ với các private subnet chứa instance, và đây chính là lý do đề nhắc "public subnet in each AZ".
• Database lại càng không có lý do gì để lộ ra Internet; nó chỉ nhận kết nối từ tầng web bên trong VPC.

Kết quả: chỉ ALB ở public, hai tầng còn lại ở private — đúng nghĩa "limited as much as possible". Việc mỗi loại subnet đều được tạo ở từng AZ đáp ứng yêu cầu high availability across Availability Zones.

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

A — ALB public, web server public, database private. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì kiến trúc này chạy được và là mô hình hai tầng cổ điển. Chỗ hỏng nằm ở chữ "as much as possible": đặt web server ở public subnet là để lộ chúng ra Internet trong khi hoàn toàn không cần — ALB đã đứng trước làm điểm vào duy nhất, và ALB gọi tới target ở private subnet được. Phương án C giảm được bề mặt công khai nhiều hơn A mà không mất chức năng nào, nên A thua.

B — ALB public, web server private, database public. Phương án này đảo ngược đúng chỗ nguy hiểm nhất. Web server thì đã đặt private (tốt), nhưng lại đẩy tầng database — tầng chứa dữ liệu, tầng đáng bảo vệ nhất — ra public subnet. Database chỉ nhận kết nối từ tầng web bên trong VPC, đặt nó ở public subnet là lộ ra ngoài mà chẳng đổi lấy lợi ích gì. Đây là lựa chọn tệ hơn cả A xét theo yêu cầu của đề.

D — cả ba tầng đều public. Phương án cực đoan ngược hẳn với yêu cầu: mọi tầng đều nằm ở public subnet, tức bề mặt công khai lớn nhất trong bốn lựa chọn. Nó vẫn thoả điều kiện high availability (subnet trải qua các AZ) nhưng vi phạm trực diện ràng buộc "limited as much as possible". Đây là phương án loại đầu tiên.

📌 Điểm cần nhớ

• Trong một câu hỏi thiết kế VPC nhiều tầng, hãy tìm cụm ràng buộc kiểu "limit public access" / "as much as possible" — nó thường là thứ duy nhất phân biệt các phương án chỉ khác nhau ở nhãn public/private.
• Chỉ tầng thực sự nhận lưu lượng từ Internet mới cần public subnet. Với kiến trúc web ba tầng dùng ALB, tầng đó là ALB, không phải web server.
• Internet-facing ALB hoàn toàn đăng ký được target nằm trong private subnet — đây là điểm hay bị hiểu sai. Yêu cầu kèm theo là public subnet của ALB phải nằm cùng các AZ với private subnet chứa instance.
• Tầng database mặc định luôn thuộc private subnet. Bất kỳ phương án nào đặt database ở public subnet đều có thể loại ngay mà không cần đọc tiếp phần còn lại.
• Yêu cầu high availability across AZs được thoả bằng cách tạo subnet ở mỗi AZ cho từng tầng — điều này thường giống nhau ở mọi phương án nên hiếm khi là chỗ để phân biệt.

🧩 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 cụ thể: người ta phát hiện lỗ hổng bảo mật trong một phiên bản Linux đang chạy trên một số EC2 instance trong VPC. Câu hỏi là SysOps Administrator xử lý thế nào để giảm rủi ro phơi nhiễm.

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

• "a version of Linux that is running on" — lỗ hổng nằm ở hệ điều hành bên trong instance, không phải ở hạ tầng AWS, không phải ở cấu hình mạng. Cái cần sửa là phần mềm trong OS, tức là phải vá (patch) nó.
• "with the LEAST disruption" — không hỏi "cách nào an toàn nhất" mà hỏi cách ít gián đoạn nhất. Đây là ràng buộc phân biệt hai phương án đều thực sự khắc phục được lỗ hổng: vá tại chỗ và dựng lại instance từ AMI mới.

Bỏ qua một trong hai cụm từ này là chọn nhầm: bỏ qua cụm đầu thì đi vào phương án chỉ báo cáo hoặc chỉ đổi máy chủ vật lý; bỏ qua cụm sau thì chọn cách dựng lại toàn bộ.

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

Đáp án theo tệp là D — Use AWS Systems Manager to patch the Linux operating systems.

AWS Systems Manager, cụ thể là Patch Manager, được tạo ra đúng cho việc này: tự động hoá quá trình vá các managed instance với bản vá bảo mật và các loại cập nhật khác, cho cả hệ điều hành lẫn ứng dụng cài trên đó. Vì lỗ hổng nằm trong OS, vá OS là hành động trực tiếp loại bỏ nguyên nhân.

Về mặt "ít gián đoạn nhất": instance giữ nguyên — vẫn là instance ID cũ, IP cũ, volume cũ, dữ liệu và cấu hình cục bộ cũ. Việc vá diễn ra ngay trên máy đang chạy thông qua SSM Agent, và Patch Manager cho phép đặt lịch bảo trì cùng nhóm bản vá để kiểm soát thời điểm tác động. Không cần thay thế hạ tầng, không cần đăng ký lại vào load balancer, không cần lo state nằm trên đĩa.

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

A. Use Amazon Inspector to produce a report with best practice recommendations. Amazon Inspector là công cụ đánh giá và phát hiện — nó quét, tìm CVE, xếp hạng mức nghiêm trọng và xuất ra danh sách phát hiện. Nhưng ở đây lỗ hổng đã được phát hiện rồi ("has been discovered"), nên thêm một bản báo cáo nữa không thay đổi gì cả. Inspector không tự vá bất cứ thứ gì; sau khi đọc báo cáo bạn vẫn phải làm đúng việc mà phương án D nói. Đây là bẫy "chọn công cụ bảo mật nghe hợp lý nhất" thay vì công cụ thực sự khắc phục.

B. Redeploy the EC2 instances using an updated AMI through AWS CloudFormation. Đây là phương án gần đúng nhất và cũng là phương án gây nhầm nhiều nhất — nó thực sự khắc phục được lỗ hổng, và với môi trường immutable thì đây còn là cách làm được khuyến khích. Nó hỏng ở đúng chữ LEAST disruption: dựng lại instance nghĩa là thay thế hoàn toàn máy đang chạy — instance mới, ID mới, phải đợi khởi động và cấu hình lại, phải xử lý mọi dữ liệu hay trạng thái còn nằm trên máy cũ, và ứng dụng ngừng phục vụ trong khoảng chuyển giao. So với việc chỉ chạy một chiến dịch vá trên chính những máy đó, mức gián đoạn cao hơn hẳn. Đúng về kỹ thuật, sai về tiêu chí đề bài đưa ra.

C. Shut down and then restart the instances so they change underlying hosts. Tắt rồi bật lại instance thường khiến nó được đặt lên một host vật lý khác — nhưng root volume vẫn là root volume cũ, tức là vẫn đúng phiên bản Linux có lỗ hổng đó. Đổi host chỉ giải quyết vấn đề của phần cứng nằm dưới (host lỗi, host cần bảo trì), hoàn toàn không đụng tới phần mềm bên trong. Ngoài việc không khắc phục gì, nó còn gây gián đoạn thật vì instance phải dừng hẳn rồi khởi động lại. Sai cả hai vế.

📌 Điểm cần nhớ

• Phân biệt công cụ phát hiện với công cụ khắc phục. Amazon Inspector tìm ra lỗ hổng; AWS Systems Manager Patch Manager là thứ sửa nó. Đề đã nói "đã phát hiện" thì đáp án nằm ở nhóm khắc phục.
• Lỗ hổng nằm trong OS thì phải sửa trong OS. Đổi host, đổi instance type, hay khởi động lại đều không chạm tới root volume — dữ liệu và phần mềm bên trong giữ nguyên.
• Chữ in hoa trong đề là tiêu chí chấm điểm. LEAST disruption, MOST cost-effective, LEAST operational overhead — khi có nhiều phương án cùng giải quyết được vấn đề, chính từ này chọn ra đáp án. Vá tại chỗ luôn ít gián đoạn hơn thay thế instance.
• Systems Manager là câu trả lời mặc định cho quản trị OS ở quy mô nhiều instance: vá bản, chạy lệnh từ xa, quản lý cấu hình — không cần SSH vào từng máy và không cần mở cổng vào instance.

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

Đề mô tả một nhóm systems administrators dùng IAM access key để quản lý Amazon EC2 instance qua AWS CLI, và chính sách công ty bắt buộc access key phải tự động bị vô hiệu hoá sau 60 ngày.

Cụm từ quyết định là "automatically disabled after 60 days" — tức là cần hai thứ ghép lại:

1. Một cơ chế liên tục đánh giá tuổi của access key so với một ngưỡng cấu hình được (60 ngày). Đây là bài toán kiểm tra trạng thái cấu hình của tài nguyên IAM, không phải bài toán theo dõi một chỉ số đo được theo thời gian.
2. Một cơ chế tự khắc phục (remediation) chạy sau khi phát hiện vi phạm, và làm được việc gọi API để disable key.

"Tuổi của access key" là một thuộc tính cấu hình, chứ không phải metric. Nắm được điều này là loại được ngay các phương án dựa trên metric.

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

D — Dùng AWS Config rule để phát hiện key không tuân thủ, rồi tạo custom AWS Systems Manager Automation document để remediation.

AWS Config sinh ra chính để trả lời câu hỏi "tài nguyên của tôi có đang tuân thủ chính sách hay không". Nó có managed rule access-keys-rotated, kiểm tra xem access key đang hoạt động có được xoay vòng trong số ngày khai ở tham số maxAccessKeyAge hay không; quá ngưỡng thì tài nguyên bị đánh dấu NON_COMPLIANT. Đặt maxAccessKeyAge bằng 60 là dịch thẳng chính sách công ty thành cấu hình, không phải viết logic tính tuổi bằng tay.

Phần còn lại là automatic remediation của AWS Config: gắn vào rule một Systems Manager Automation document. Khi rule báo NON_COMPLIANT, Config kích hoạt document đó; document phân giải ra IAM user name tương ứng rồi gọi API để disable key (và tạo key mới nếu muốn). Toàn bộ chuỗi phát hiện → xử lý chạy tự động, không có máy chủ nào phải nuôi.

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

A — Amazon Inspector đưa ra khuyến nghị security best practice và tự động disable key. Sai ở vế thứ hai: Inspector không disable access key. Nó là dịch vụ đánh giá lỗ hổng và rủi ro trên workload, kết quả của nó là findings để người vận hành đọc và xử lý, chứ bản thân nó không phải công cụ remediation cho IAM credential. Chọn A là giao cho một dịch vụ việc mà nó không làm.

B — Script kiểm tra tuổi key, chạy bằng cron job trên một EC2 instance. Đây là phương án gần đúng nhất về mặt chức năng — script hoàn toàn có thể liệt kê key, tính tuổi và gọi API disable. Chỗ nó hỏng là vận hành và chi phí: phải nuôi một EC2 instance chạy liên tục chỉ để mỗi ngày thức dậy vài giây, tức là trả tiền 24/7 cho một tác vụ định kỳ rất nhẹ. Kèm theo đó là gánh nặng quản lý instance: patch OS, gắn IAM role, giám sát xem cron còn sống không, và nếu instance chết thì chính sách bảo mật lặng lẽ ngừng được thực thi mà không ai biết. So với D — không có hạ tầng nào để bảo trì và trạng thái tuân thủ hiển thị sẵn trong AWS Config — thì B thua rõ.

C — CloudWatch alarm kích hoạt Lambda function để disable key quá 60 ngày. Phần Lambda thì hợp lý, nhưng CloudWatch alarm không kích hoạt được trong tình huống này: alarm phải dựa trên một metric bị vượt ngưỡng, mà ở đây không có metric nào biểu diễn "tuổi của access key". Tuổi key là thuộc tính cấu hình trong IAM, không phải chuỗi số liệu đẩy vào CloudWatch. Không có metric thì không có alarm, và cả chuỗi đứng im. Đây là bẫy kinh điển: nhìn thấy "tự động" liền nghĩ tới alarm → Lambda mà quên kiểm tra xem thứ cần theo dõi có thật sự là metric hay không.

📌 Điểm cần nhớ

• Cấu hình dùng AWS Config, số liệu dùng CloudWatch. Câu hỏi nào nói về "tài nguyên có tuân thủ chính sách không" (tuổi key, bucket có mã hoá không, security group có mở cổng không) thì nghĩ tới AWS Config rule; CloudWatch alarm chỉ dùng khi có metric thật vượt ngưỡng.
• AWS Config + Systems Manager Automation là cặp remediation chuẩn: Config phát hiện NON_COMPLIANT, Automation document thực thi việc sửa. Thấy "identify noncompliant … then remediate" là gần như chắc chắn cặp này.
• Managed rule access-keys-rotated với tham số maxAccessKeyAge là câu trả lời sẵn có cho yêu cầu xoay vòng/hết hạn access key — không cần tự viết logic.
• Cron trên EC2 hầu như luôn là phương án sai trong đề thi: nó chạy được nhưng bắt trả tiền cho instance chạy liên tục và thêm một hệ thống phải bảo trì, trong khi AWS đã có dịch vụ quản lý làm đúng việc đó.

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

Đề mô tả tình huống: đội bảo mật phát hiện một địa chỉ IP gửi các kết nối độc hại, và yêu cầu chặn tường minh (explicitly denied) địa chỉ IP đó cho cả ingress lẫn egress, áp dụng cho tất cả các service trong một Amazon VPC, và phải làm ngay lập tức (immediately / quickly).

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

• "explicitly denied" — phải là một luật từ chối, không phải luật cho phép. Đây là ràng buộc sắc nhất, vì trong VPC chỉ có một lớp phòng thủ hỗ trợ deny rule.
• "both ingress and egress" — luật phải áp được cả hai chiều một cách độc lập.
• "all services in a VPC" — phạm vi là toàn VPC, không phải từng instance hay từng nhóm instance.
• "immediately / quickly" — ưu tiên thao tác một chỗ, có hiệu lực ngay, không phải đi cấu hình từng máy.

Ghép lại: cần một cơ chế stateless, hỗ trợ deny, gắn ở mức subnet, bao trùm toàn VPC.

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

B — Add a rule to the Network Access Control Lists for all subnets in the VPC.

Network ACL là lớp bảo mật tuỳ chọn của VPC, hoạt động như một firewall kiểm soát traffic ra vào subnet. Khác với security group, network ACL hỗ trợ cả allow rule lẫn deny rule, nên yêu cầu "explicitly denied" một địa chỉ IP được đáp ứng trực tiếp: tạo một deny rule với source/destination là IP đó.

Network ACL cũng có hai bảng luật tách biệt cho inbound và outbound, nên chặn được đúng cả hai chiều mà đề yêu cầu. Vì luật gắn ở mức subnet, mọi tài nguyên nằm trong subnet đó — EC2 instance, endpoint, bất kỳ ENI nào — đều chịu ảnh hưởng ngay mà không cần đụng tới từng máy. Thêm luật vào network ACL của tất cả các subnet trong VPC là bao phủ trọn phạm vi đề nêu, và đây là thao tác cấu hình có hiệu lực nhanh.

Một điểm nữa hợp với tình huống: network ACL là stateless, nghĩa là chiều đi và chiều về được đánh giá độc lập — rất phù hợp khi mục tiêu là cắt đứt hoàn toàn mọi liên lạc với một IP.

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

A — Add a rule to the Security Groups attached to the instances in the affected subnets. Đây là phương án gần đúng nhất và cũng là bẫy chính. Security group chỉ hỗ trợ allow rule, không có deny rule. Không có cách nào diễn đạt "chặn IP này" bằng security group — thứ duy nhất làm được là không cho phép IP đó, mà nếu luật hiện tại đang mở rộng (ví dụ cho phép cả dải lớn) thì bạn phải đi thu hẹp luật allow, chứ không thể chèn một dòng deny. Yêu cầu "explicitly denied" loại phương án này ngay. Ngoài ra security group gắn theo ENI/instance chứ không theo subnet, nên phạm vi cũng không phải "all services in the VPC".

C — Install a host-based firewall on each Amazon EC2 instance and block the IP address. Về mặt kỹ thuật thì chặn được cả hai chiều và đúng là deny, nhưng vi phạm chữ "quickly": phải cài đặt và cấu hình phần mềm trên từng instance, tốn công và phức tạp hơn hẳn việc chặn một lần ở mức subnet. Nó cũng chỉ bảo vệ các EC2 instance, không bao trùm "all services" trong VPC. Đây là giải pháp đúng hướng nhưng sai về chi phí vận hành và phạm vi.

D — Remove the Internet Gateway from the VPC and use a NAT gateway instead. Sai cả về mục tiêu lẫn về khả thi. Gỡ internet gateway sẽ cắt đứt toàn bộ liên lạc Internet của VPC chứ không chỉ chặn một IP — dùng dao mổ trâu giết gà, và làm hỏng dịch vụ hợp lệ. Hơn nữa NAT gateway không thay thế được internet gateway: NAT gateway vẫn phụ thuộc vào internet gateway để ra Internet, hai thứ này đóng vai trò khác nhau chứ không phải hai lựa chọn thay phiên. Và NAT gateway cũng không có khái niệm luật deny theo IP.

📌 Điểm cần nhớ

• Thấy chữ "deny", "block", "explicitly denied" một địa chỉ IP trong đề → nghĩ ngay tới network ACL, không phải security group. Security group chỉ có allow rule; network ACL có cả allow lẫn deny. Đây là cặp phân biệt được hỏi đi hỏi lại.
• Phạm vi quyết định lớp phòng thủ: cần chặn cho toàn subnet / toàn VPC thì dùng network ACL (gắn theo subnet); cần luật riêng cho từng nhóm instance thì dùng security group (gắn theo ENI).
• Network ACL là stateless, security group là stateful. Vì stateless nên network ACL có bảng inbound và outbound riêng — đúng thứ cần khi đề đòi chặn "cả ingress lẫn egress".
• Cảnh giác với phương án "đúng nhưng chậm". Host-based firewall thường xuất hiện làm mồi nhử khi đề nhấn mạnh "immediately"/"quickly": phải triển khai lên từng máy nên luôn thua giải pháp cấu hình một chỗ ở tầng mạng.