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

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

Đề mô tả một doanh nghiệp dùng AWS Organizations với nhiều member account, và phát hiện các quản trị viên đang thao tác bằng root user credentials. Yêu cầu: chặn những người này thực hiện bất kỳ tác vụ nào trên Amazon EC2 instances khi dùng root user credentials.

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

• "under AWS Organizations" — bài toán nằm ở tầng tổ chức, tức là có sẵn công cụ kiểm soát tập trung áp xuống các member account.
• "restrict ... from performing any tasks" — đây là yêu cầu cấm (ngăn hành động xảy ra), không phải phát hiện, cảnh báo hay tăng độ khó khi đăng nhập.
• "with root user credentials" — đối tượng bị chặn là root user, chứ không phải IAM user hay IAM role.

Cụm cuối cùng là mấu chốt phân biệt. Root user là chủ tài khoản: nó không bị giới hạn bởi IAM policy trong chính account đó. Mọi giải pháp dựa trên IAM (gán policy, siết quyền tối thiểu) đều bất lực trước root. Thứ duy nhất trong danh sách có thể đặt trần quyền lên root của một member account là service control policy (SCP) của AWS Organizations.

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

A — Apply a service control policy (SCP) that denies all actions on EC2 instances when performed with root user credentials.

SCP là cơ chế AWS Organizations dùng để giữ quyền kiểm soát tập trung đối với những dịch vụ mà user và role trong từng member account được phép truy cập. Nó hoạt động như một trần quyền (permission boundary) áp lên toàn bộ account: một hành động chỉ thực hiện được khi vừa được identity policy cho phép, vừa không bị SCP chặn.

Điểm quan trọng cho câu này: SCP áp lên các principal trong member account bao gồm cả root user của account đó (SCP không áp cho management account). Đó chính xác là lỗ hổng mà các phương án còn lại không bịt được — root không đọc IAM policy, nhưng vẫn nằm dưới SCP.

Vì vậy, một SCP với Effect: Deny cho các action EC2, kèm điều kiện nhận diện caller là root user, sẽ chặn đúng phạm vi đề yêu cầu: mọi tác vụ trên EC2, khi và chỉ khi thực hiện bằng root credentials, mà không đụng tới công việc bình thường của các IAM user/role.

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

B — Implement a multi-factor authentication (MFA) requirement for root user credentials.

Đây là phương án gần đúng nhất và là best practice thật sự nên làm, nên rất dễ chọn nhầm. Nhưng MFA giải quyết bài toán khác: nó xác minh rằng người đăng nhập đúng là chủ tài khoản, tức là chống bị chiếm dụng credentials. Ở đây các administrator chính là người hợp pháp đang cầm root credentials — họ vượt qua MFA hoàn toàn bình thường, rồi vẫn thao tác EC2 như cũ. MFA làm tăng độ an toàn khi đăng nhập, chứ không hạn chế root được làm gì sau khi đã đăng nhập.

C — Enable IAM Access Analyzer in all the member accounts.

IAM Access Analyzer là công cụ phân tích và phát hiện: nó chỉ ra các tài nguyên trong tổ chức và trong account — ví dụ S3 bucket hay IAM role — đang được chia sẻ với thực thể bên ngoài phạm vi tin cậy. Nó tạo ra finding để con người xem xét, chứ bản thân nó không từ chối request nào. Đề yêu cầu "restrict", nghĩa là ngăn chặn — một công cụ báo cáo không đáp ứng được. Ngoài ra trọng tâm của nó là truy cập ngoài tổ chức, không phải hành vi của root user trên EC2.

D — Enforce least privilege policy for all IAM users and groups.

Phương án này nghe rất đúng nguyên tắc bảo mật, nhưng sai đúng ở chỗ đề nhấn mạnh. Least privilege được thực thi qua IAM policy gắn cho IAM user và group — mà root user không phải IAM user và không bị IAM policy ràng buộc. Dù siết chặt mọi IAM user tới mức tối thiểu, các administrator vẫn đăng nhập bằng root và tiếp tục làm mọi thứ trên EC2. Nói cách khác, phương án này bịt đúng cánh cửa mà đề không hỏi, và bỏ ngỏ đúng cánh cửa đề đang chỉ vào.

📌 Điểm cần nhớ

• Root user không bị IAM policy chặn. Thấy đề nhắc tới "root user credentials" thì loại ngay mọi phương án dựa trên IAM policy, IAM group hay least privilege.
• SCP của AWS Organizations là công cụ duy nhất đặt trần quyền lên member account, kể cả root user của account đó. Đề có bối cảnh "multiple member accounts under AWS Organizations" + "restrict/prevent" thường là tín hiệu SCP.
• Phân biệt phát hiện với ngăn chặn. IAM Access Analyzer, CloudTrail, Config sinh ra finding để con người xử lý; SCP và IAM Deny thì thực sự từ chối API call. Động từ trong đề ("restrict", "prevent", "block" ↔ "identify", "detect", "audit") quyết định nhóm nào là đáp án.
• MFA là xác thực, không phải phân quyền. Nó trả lời "bạn có đúng là chủ credentials không", không trả lời "bạn được phép làm gì". Đề hỏi giới hạn hành động thì MFA luôn là bẫy.

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

Đề mô tả một ứng dụng chạy trên EC2 instances đứng sau một Application Load Balancer (ALB), khách hàng truy cập bằng tên miền tuỳ chỉnh và đang gặp lỗi kết nối. Điểm mấu chốt nằm ở chỗ đề đã liệt kê sẵn những thứ đã được xác nhận là đúng rồi mới hỏi — đây là kiểu câu "loại trừ giúp bạn trước, chỉ chừa lại một manh mối".

Ba dữ kiện được nêu:

• Security groups và network ACLs đã cấu hình đúng → loại bỏ hướng nghi ngờ tầng mạng.
• Route 53 Alias record trỏ đúng vào ALB → loại bỏ hướng nghi ngờ DNS.
• "The load balancer target group shows no healthy instances" → đây chính là cụm từ quyết định.

Cộng thêm chữ "first step" trong câu hỏi: đề không hỏi "nguyên nhân gốc là gì", mà hỏi bước đầu tiên nên làm. Khi đã có một triệu chứng cụ thể được chỉ tận tay — không có target nào healthy — thì bước đầu tiên phải là đi thẳng vào triệu chứng đó, chứ không phải mở rộng phạm vi điều tra sang chỗ khác.

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

D — Review the load balancer target group health check configuration.

ALB chỉ chuyển tiếp request tới các target đang ở trạng thái healthy. Khi target group không có instance nào healthy, ALB không còn đích nào để gửi request, nên client truy cập qua tên miền sẽ nhận lỗi — đúng với triệu chứng người dùng báo cáo. Đây là mắt xích đang đứt trong chuỗi DNS → ALB → target, và nó đã được đề chỉ rõ.

Health check của target group có nhiều tham số có thể khiến instance bị đánh là unhealthy dù ứng dụng vẫn chạy: protocol, port, đường dẫn health check path, mã HTTP được coi là thành công, ngưỡng số lần thất bại, khoảng thời gian và timeout. Chỉ cần path trỏ sai chỗ hoặc port health check không khớp port ứng dụng đang lắng nghe là toàn bộ target group chuyển sang unhealthy. Vì vậy xem lại cấu hình health check là bước đầu tiên hợp lý để hiểu tại sao không có instance nào healthy — và chừng nào chưa có target healthy thì ứng dụng không thể hoạt động, mọi việc điều tra khác đều là thứ yếu.

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

A — Review the load balancer listener configuration.

Đây là phương án gần đúng nhất, vì listener đúng là một thành phần có thể gây lỗi kết nối thật (sai port, sai protocol, sai rule chuyển tiếp). Nhưng nó hỏng ở chỗ không có dữ kiện nào trong đề chỉ về listener. Ngược lại, đề đã đưa ra một triệu chứng rõ ràng và khác hẳn: no healthy instances. Chọn A là bỏ qua manh mối đã có sẵn để đi kiểm tra một thứ chỉ mới ở mức nghi ngờ. Kể cả khi listener có vấn đề thật, việc target group không có instance healthy vẫn phải xử lý trước thì ứng dụng mới chạy được.

B — Review the VPC Flow Logs, looking for any API errors.

Sai ngay ở phần mô tả công dụng của dịch vụ. VPC Flow Logs ghi lại thông tin về lưu lượng IP đi qua network interface — kiểu ACCEPT/REJECT, địa chỉ nguồn/đích, port, giao thức. Nó không ghi API errors; các lời gọi API tới AWS được ghi bởi CloudTrail. Ngoài ra đề đã xác nhận security groups và network ACLs đúng, tức là hướng điều tra lưu lượng bị chặn ở tầng mạng cũng đã được loại trừ sẵn.

C — Review the load balancer access logs, looking for any issues or errors.

Access logs của load balancer ghi lại các request mà client gửi tới ALB và cách ALB xử lý chúng. Vấn đề là ở đây ALB không có target healthy nào để chuyển request tới, nên access logs cùng lắm chỉ phản ánh lại đúng triệu chứng đã biết chứ không giải thích được nguyên nhân instance bị unhealthy. Lý do một instance trượt health check nằm ở cấu hình health check và ở bản thân instance/ứng dụng, không nằm trong log ghi request của phía client.

📌 Điểm cần nhớ

• Khi câu hỏi hỏi "first step" và đề đã nêu một triệu chứng cụ thể, bước đầu tiên gần như luôn là điều tra thẳng triệu chứng đó, không mở rộng sang thành phần chưa có dấu hiệu bất thường.
• Danh sách "đã xác nhận đúng" trong đề là công cụ loại trừ do người ra đề đặt sẵn: mọi phương án nhắm vào những mục đã được xác nhận (security group, NACL, DNS) đều bị vô hiệu.
• Phân biệt rạch ròi các nguồn log của AWS: VPC Flow Logs = lưu lượng IP (accept/reject); CloudTrail = API calls; ALB access logs = request từ client tới load balancer. Phương án sai thường gán nhầm công dụng giữa chúng.
• ALB chỉ gửi request tới target ở trạng thái healthy. "No healthy instances" là điểm đứt gãy nghiêm trọng nhất trong chuỗi DNS → ALB → target, và phải được xử lý trước mọi thứ khác — bắt đầu bằng cấu hình health check của target group (path, port, protocol, success codes, ngưỡng và timeout).

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

Đề mô tả một file system Amazon EFS đã tồn tại và đang được nhiều EC2 instance mount, dữ liệu nhạy cảm, và yêu cầu của quản lý là encrypted at rest (mã hoá dữ liệu lúc nằm yên trên đĩa).

Có hai cụm từ quyết định đáp án, và phải đọc cả hai mới loại hết được các phương án gần giống nhau:

• "is used by several Amazon EC2 instances" → file system này đã được tạo rồi, không phải đang thiết kế mới. Đây là ràng buộc quan trọng nhất, vì nó biến câu hỏi từ "bật encryption thế nào" thành "làm gì với một file system đã lỡ tạo mà không bật encryption".
• "encrypted at rest" → phân biệt với encryption in transit. EFS có cả hai loại và chúng bật ở hai thời điểm hoàn toàn khác nhau: at rest bật lúc tạo file system, còn in transit bật lúc mount (dùng TLS qua EFS mount helper).

Ai đọc lướt chỉ thấy "encryption" rồi đi tìm phương án nào có chữ TLS/certificate, hoặc tìm công cụ nào (CLI hay PowerShell) để "bật" nó lên. Cả hai hướng đó đều sai.

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

C. Create a new EFS volume with encryption enabled and copy the data from the original volume.

Encryption at rest của EFS là một thuộc tính được đặt tại thời điểm tạo file system và không thay đổi được về sau. Không có thao tác nào — bằng console, API, CLI hay SDK — biến một EFS file system chưa mã hoá thành đã mã hoá tại chỗ.

Vì vậy quy trình duy nhất khả dĩ là: tạo một file system EFS mới với encryption at rest bật sẵn, rồi copy dữ liệu từ file system cũ sang, sau đó trỏ các EC2 instance mount sang file system mới. Đây chính xác là những gì phương án C mô tả, và cũng là điều tài liệu EFS nói: bật mã hoá at rest khi tạo file system, bật mã hoá in transit khi mount.

Điểm cần chấp nhận: đáp án này không phải là thao tác một dòng lệnh — nó là một cuộc di chuyển dữ liệu. Đó là cái giá của việc quên bật encryption từ đầu, và đề đang kiểm tra đúng chỗ đó.

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

A. Create an SSL/TLS certificate using ACM and attach it to the EFS volume. Sai ở hai tầng. Thứ nhất, EFS không có khái niệm gắn certificate vào file system — ACM cấp certificate cho các dịch vụ như load balancer hay CloudFront, không phải cho EFS volume. Thứ hai, kể cả nếu làm được thì SSL/TLS phục vụ encryption in transit, tức bảo vệ dữ liệu trên đường truyền giữa EC2 và EFS, hoàn toàn không phải thứ mà đề hỏi (at rest). Đây là phương án đánh vào người chỉ nhớ "encryption = TLS".

B. Enable encryption on the existing EFS volume by using the AWS CLI. Đâ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 ở chỗ giả định rằng vấn đề nằm ở công cụ — rằng console không làm được thì CLI sẽ làm được. Không phải vậy: đây là giới hạn ở tầng dịch vụ, không phải tầng giao diện. CLI, console, SDK đều gọi cùng một API, và API đó không có tham số nào để bật encryption at rest cho file system đã tồn tại.

D. Enable encryption on the existing EFS volume using the AWS tools for Windows PowerShell. Sai vì đúng một lý do với B, chỉ đổi tên công cụ. Việc đề đưa ra hai phương án B và D chỉ khác nhau ở công cụ là một tín hiệu đáng chú ý khi làm bài: khi hai phương án khác nhau chỉ ở cách gọi API mà cùng khẳng định một hành động, thì hoặc cả hai cùng đúng (bất khả thi trong câu chọn một đáp án), hoặc cả hai cùng sai. Ở đây là vế thứ hai.

📌 Điểm cần nhớ

• EFS encryption at rest chỉ bật được lúc tạo file system. Đã tạo rồi thì cách duy nhất là tạo file system mới có mã hoá và copy dữ liệu sang.
• Phân biệt at rest và in transit ngay từ khi đọc đề. Với EFS: at rest quyết định lúc tạo file system; in transit bật lúc mount bằng TLS. Certificate và ACM thuộc về in transit, và cũng không gắn được vào EFS.
• Đổi công cụ không đổi được giới hạn của dịch vụ. CLI, PowerShell, SDK, console đều gọi cùng API — nếu API không hỗ trợ thì không công cụ nào cứu được. Phương án nào bán ý "console không làm được nhưng CLI làm được" thường là bẫy.
• Hai phương án chỉ khác nhau ở công cụ thì gần như chắc chắn cùng sai trong câu hỏi chọn một đáp án — dùng mẹo này để loại nhanh và tập trung vào hai phương án còn lại.

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

Đề mô tả một công ty muốn tối ưu chi phí AWS, và yêu cầu cụ thể của SysOps administrator là: "ensure that certain custom-defined tags attached to resources appear in the billing report".

Cụm từ quyết định nằm ở đây, gồm ba mảnh ghép lại:

• "custom-defined tags" — tag do người dùng tự đặt (user-defined tags), không phải tag hệ thống AWS tự sinh.
• "appear in the billing report" — mục tiêu là làm cho tag hiện ra trong báo cáo chi phí, tức là biến tag thành một chiều (dimension) để bóc tách chi phí.
• "For better tracking and managing expenses" — chỉ là bối cảnh, không phải yêu cầu kỹ thuật.

Đây không phải câu hỏi "công cụ nào giúp phân tích chi phí" mà là câu hỏi "làm thế nào để tag xuất hiện được trong dữ liệu billing". Điểm mấu chốt: trong AWS, tag gắn lên resource không tự động đi vào báo cáo chi phí. Chúng phải được kích hoạt (activate) thành cost allocation tag thì AWS mới bắt đầu đưa thông tin chi phí theo tag đó vào dữ liệu billing. Ai nắm được chi tiết "phải activate trước" sẽ loại được ngay ba phương án còn lại, vì cả ba đều là công cụ tiêu thụ dữ liệu chi phí chứ không phải nơi bật chiều dữ liệu mới.

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

A. Configure cost allocation tags in the billing console.

Đúng theo đúng nghĩa đen của yêu cầu. Trong AWS Billing and Cost Management console có mục Cost Allocation Tags, nơi liệt kê các tag key đang tồn tại trên tài nguyên và cho phép kích hoạt chúng. Sau khi một user-defined tag được kích hoạt làm cost allocation tag, AWS sẽ đưa thông tin chi phí gắn với tag đó vào cost allocation report — nghĩa là tag xuất hiện thành cột/chiều riêng trong báo cáo, và chi phí có thể được nhóm theo giá trị tag.

Đây là hành động duy nhất trong danh sách thực sự thay đổi nội dung của billing report. Ba phương án còn lại chỉ thay đổi cách bạn nhìn dữ liệu đã có.

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

B. Activate AWS Cost Explorer. — Đây là phương án gần đúng nhất và dễ chọn nhầm, vì Cost Explorer đúng là nơi bạn lọc và nhóm chi phí theo tag. Nhưng nó hỏng ở thứ tự nhân quả: Cost Explorer là công cụ trực quan hoá và phân tích chi phí theo thời gian, nó chỉ hiển thị được những chiều dữ liệu đã sẵn có. Nếu tag chưa được kích hoạt làm cost allocation tag, bật Cost Explorer lên cũng không thấy tag đó đâu để mà lọc. Nó là bước sau, không phải bước làm tag xuất hiện.

C. Enable AWS Trusted Advisor cost optimization checks. — Trusted Advisor đưa ra khuyến nghị tối ưu chi phí bằng cách phát hiện tài nguyên nhàn rỗi hoặc dùng dưới công suất. Nó gắn với vế "optimize its AWS costs" trong câu mở đầu nên nghe có vẻ liên quan, nhưng đó chỉ là bối cảnh của đề. Trusted Advisor không can thiệp gì vào cấu trúc của billing report và không có cơ chế nào để đưa một tag tuỳ biến vào đó.

D. Enable detailed billing for the AWS account. — Phương án gây nhiễu mạnh vì nó cũng nằm trong khu vực billing và cũng làm báo cáo "chi tiết hơn". Điểm hỏng: detailed billing cho bạn hoá đơn bóc tách theo từng dòng sử dụng dịch vụ, nhưng mức chi tiết đó là theo dịch vụ/loại sử dụng, không tự động kèm theo các tag tuỳ biến. Muốn cột tag xuất hiện trong dữ liệu đó thì vẫn phải quay lại bước kích hoạt cost allocation tag. Nói cách khác, D làm báo cáo dài hơn chứ không làm nó có thêm chiều tag.

📌 Điểm cần nhớ

• Tag gắn lên resource không tự động đi vào billing — phải được kích hoạt thành cost allocation tag trong Billing console thì mới xuất hiện trong báo cáo chi phí.
• Phân biệt rõ hai nhóm: nơi bật dữ liệu (cost allocation tags, cấu hình billing) và nơi tiêu thụ dữ liệu (Cost Explorer, Trusted Advisor). Đề hỏi "làm sao tag xuất hiện" thì phải chọn nhóm thứ nhất.
• Cost allocation tag có hai loại: tag do AWS sinh và user-defined tag; đề nhấn "custom-defined" là đang trỏ thẳng vào loại phải tự kích hoạt.
• Dữ liệu chi phí theo tag chỉ có từ thời điểm kích hoạt trở đi, nên đây là việc nên làm sớm chứ không phải khi cần báo cáo mới làm.
• Bẫy quen thuộc trong đề AWS billing: câu mở đầu nói "tối ưu chi phí" để kéo bạn về phía Trusted Advisor hoặc Cost Explorer, trong khi yêu cầu thật nằm ở câu sau. Luôn đọc kỹ vế "which action... to fulfill this requirement".

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

Đề mô tả một EC2 instance xử lý các tệp dữ liệu lớn, gắn một EBS volume loại General Purpose SSD (gp2) dung lượng 1 TB. CloudWatch cho thấy VolumeReadOps giữ nguyên ở mức 3.000 một cách consistent. Yêu cầu: cải thiện hiệu năng I/O đồng thời bảo đảm data integrity (dữ liệu không được mất).

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

• "a consistent 3,000 VolumeReadOps" — con số này không phải ngẫu nhiên. Với gp2, baseline IOPS tính theo dung lượng volume (tỉ lệ tuyến tính theo GiB), và một volume 1 TB có baseline rơi đúng vào vùng 3.000 IOPS. Việc chỉ số đứng phẳng ở đúng ngưỡng đó liên tục là dấu hiệu kinh điển của đụng trần baseline, chứ không phải ứng dụng chỉ cần đúng chừng ấy. Đây là ràng buộc phân biệt các phương án: vấn đề nằm ở tầng storage, không nằm ở CPU hay ở loại instance.
• "while ensuring data integrity" — mệnh đề này tồn tại để loại thẳng một phương án cụ thể trong danh sách, chứ không phải câu chữ trang trí.

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

Đáp án đúng theo tệp là B — Increase the EBS volume to a 2 TB General Purpose SSD (gp2) volume.

Đặc tính cốt lõi của gp2: baseline performance tỉ lệ tuyến tính với dung lượng volume (3 IOPS trên mỗi GiB), nằm giữa một mức sàn tối thiểu và một mức trần tối đa. Kèm theo đó là cơ chế I/O credit: volume tích luỹ credit ở đúng nhịp baseline của nó, và tiêu credit khi cần burst vượt baseline.

Hệ quả trực tiếp: với gp2, cách để nâng cả baseline IOPS lẫn tốc độ tích luỹ credit chính là tăng dung lượng volume. Đưa volume từ 1 TB lên 2 TB làm baseline tăng theo tỉ lệ, nên workload không còn bị ghim ở trần cũ.

Về data integrity: EBS là block storage bền vững (persistent), tách rời vòng đời của instance. Thao tác tăng dung lượng volume không phá huỷ dữ liệu đang có — đây là thay đổi tại chỗ trên chính volume đó, nên vừa giải quyết được hiệu năng vừa thoả mãn ràng buộc thứ hai của đề. Đó là lý do B là phương án duy nhất đánh trúng cả hai yêu cầu.

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

A. Change the instance type to a bare metal instance — Bare metal cho phép workload truy cập trực tiếp bộ xử lý và bộ nhớ của máy chủ vật lý, phục vụ các nhu cầu như chạy hypervisor riêng hoặc phần mềm cần truy cập phần cứng trần. Nhưng nút thắt ở đây là trần IOPS của chính EBS volume, do dung lượng gp2 quy định. Đổi sang bare metal không làm thay đổi baseline của volume, nên VolumeReadOps vẫn ghim ở đúng chỗ cũ. Đây là kiểu phương án "nghe có vẻ mạnh hơn" nhưng tác động vào sai tầng.

C. Change the instance type to a Burstable Performance instance — Đây là bẫy từ vựng đáng chú ý nhất trong câu, vì từ burst xuất hiện ở cả hai thế giới. Burstable Performance instance dùng CPU credit để burst hiệu năng CPU vượt mức baseline. Trong khi đó thứ đang cạn ở đây là I/O credit của EBS volume. Hai cơ chế credit hoàn toàn tách biệt, không bù cho nhau. Tệ hơn, họ instance này thường được chọn cho workload nhẹ và không đều — hoàn toàn ngược với "processes large data files" trong đề, nên phương án này còn có nguy cơ làm xấu đi tình hình.

D. Move the data that resides on the EBS volume to the instance store — Đây là phương án gần đúng nhất và cũng nguy hiểm nhất. Về thuần hiệu năng, instance store là ổ đĩa gắn cục bộ vào máy chủ vật lý đang chạy instance, nên hoàn toàn có thể cho throughput/IOPS tốt cho dữ liệu tạm. Nhưng nó hỏng ở đúng nửa sau của đề: instance store là non-persistent — dữ liệu biến mất khi instance stop, terminate, hoặc khi phần cứng bên dưới gặp sự cố. Đề yêu cầu ensuring data integrity, nên dù có nhanh đến đâu thì phương án này vẫn bị loại bởi ràng buộc thứ hai. Đây là ví dụ mẫu mực của việc đề cài sẵn một mệnh đề để loại một phương án tối ưu về một chiều nhưng thất bại ở chiều còn lại.

📌 Điểm cần nhớ

• Một metric CloudWatch đứng phẳng ở đúng một con số tròn = dấu hiệu chạm trần cấu hình, không phải nhu cầu thật của ứng dụng. Gặp "consistent X IOPS/throughput" trong đề, phản xạ đầu tiên là đi tìm giới hạn nào đang tạo ra con số X đó.
• Với gp2, dung lượng volume là núm vặn hiệu năng. Baseline IOPS và tốc độ tích luỹ I/O credit đều tỉ lệ theo GiB, nên tăng size là cách trực tiếp nhất để nâng baseline mà không đổi loại volume.
• Phân biệt CPU credit (Burstable Performance instance) với I/O credit (gp2 volume). Cùng chữ "burst" nhưng khác tầng hoàn toàn; đề thi rất hay dùng sự trùng từ này làm bẫy.
• EBS là persistent, instance store thì không. Bất kỳ khi nào đề có cụm "data integrity", "durability", "must not lose data", instance store bị loại ngay bất kể nó nhanh đến mức nào.
• Đọc kỹ mệnh đề phụ dạng "while ensuring…" / "without…". Nó gần như luôn là ràng buộc dùng để tách phương án nhanh-nhưng-mất-an-toàn khỏi phương án đúng.

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

Đề nói: một SysOps Administrator được yêu cầu thêm high availability vào một Amazon RDS instance đang có sẵn (add high availability to an existing Amazon RDS instance).

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

• "high availability" — đây là yêu cầu về khả năng chịu lỗi hạ tầng và tự động failover, không phải yêu cầu về hiệu năng đọc hay disaster recovery liên vùng. Trong RDS, cơ chế đáp ứng đúng nghĩa này là Multi-AZ deployment.
• "existing" — instance đã tồn tại và đang chạy. Ràng buộc này loại ngay những phương án đòi dựng instance mới rồi di chuyển dữ liệu, vì Multi-AZ là một thuộc tính có thể bật trên instance đang chạy chứ không phải lựa chọn cố định lúc tạo.

Ai bỏ qua chữ existing sẽ thấy A và C "cũng đều ra Multi-AZ" và phân vân; chính chữ đó phân biệt chúng.

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

A — Modify the RDS instance using the console and enable Multi-AZ.

Amazon RDS cung cấp high availability và hỗ trợ failover cho DB instance thông qua Multi-AZ deployment. Khi bật Multi-AZ, RDS duy trì một standby ở Availability Zone khác và tự chuyển sang standby khi AZ chính hoặc instance chính gặp sự cố, ứng dụng vẫn dùng nguyên endpoint cũ nên không phải sửa chuỗi kết nối.

Về cơ chế bên dưới, RDS dùng công nghệ failover khác nhau tuỳ engine: MariaDB, MySQL, Oracle và PostgreSQL dùng công nghệ failover của chính Amazon, còn SQL Server dùng Database Mirroring (DBM) hoặc Always On Availability Groups.

Điểm mấu chốt cho câu này: Multi-AZ bật được bất cứ lúc nào bằng thao tác modify trên console (hoặc API/CLI tương ứng) đối với instance đang chạy. Đó đúng là "thêm HA vào instance có sẵn" mà đề yêu cầu — đơn giản nhất, không mất dữ liệu, không đổi endpoint.

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

B — Create a Read Replica and use DNS failover. Read Replica là bản sao chỉ phục vụ truy vấn đọc, không nhận ghi. Nó sinh ra để giảm tải đọc, không phải để chịu lỗi tự động. Muốn nó thành primary thì phải promote thủ công, và ghép thêm DNS failover ở ngoài là tự dựng lấy một cơ chế mà RDS đã có sẵn dạng managed. Đây là phương án nghe hợp lý nhất trong ba cái sai — nó thật sự có tạo ra một bản sao dữ liệu — nhưng hỏng ở chỗ không tự động failover cho luồng ghi, nên không thoả nghĩa high availability mà đề hỏi.

C — Create a new DB instance with Multi-AZ enabled and migrate data. Kết quả cuối cùng thì đúng là có Multi-AZ, nhưng cách làm thừa. Không cần tạo instance mới vì Multi-AZ bật được trên instance hiện có bất cứ lúc nào. Chọn C nghĩa là tự chuốc lấy việc di chuyển dữ liệu, thời gian ngừng dịch vụ và endpoint mới phải cập nhật ở phía ứng dụng — trong khi đề chỉ hỏi "how can this requirement be achieved" cho một instance đang có sẵn.

D — Use the ModifyDBInstance API action with the ReplicaMode value. Đúng là gọi ModifyDBInstance, nhưng sai tham số. ReplicaMode chỉ liên quan tới Oracle Enterprise Edition, dùng để đặt replica ở chế độ mounted phục vụ disaster recovery liên Region — nó không bật Multi-AZ và không tạo standby failover trong Region. Đây là bẫy kiểu "đúng API, sai thuộc tính": tham số cần cho Multi-AZ là thuộc tính Multi-AZ, không phải ReplicaMode.

📌 Điểm cần nhớ

• Trong RDS, Multi-AZ = high availability / failover tự động, còn Read Replica = mở rộng khả năng đọc. Đề hỏi HA thì chọn Multi-AZ; đề than "database chậm vì quá nhiều truy vấn đọc" thì mới chọn Read Replica.
• Multi-AZ bật được trên instance đang chạy bằng thao tác modify. Thấy phương án nào đòi tạo DB instance mới rồi migrate dữ liệu chỉ để có HA thì gần như chắc chắn là mồi nhử.
• Multi-AZ giữ nguyên endpoint, nên ứng dụng không phải sửa chuỗi kết nối khi failover — khác hẳn phương án tự dựng DNS failover trước Read Replica.
• ReplicaMode trong ModifyDBInstance gắn với Oracle Enterprise Edition và mounted replica cho DR liên Region, không liên quan gì tới Multi-AZ. Cẩn thận với phương án nêu đúng tên API nhưng gắn sai tham số.

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

Đề cho một bucket policy đã được gắn vào bucket S3 chứa dữ liệu nhạy cảm, rồi hỏi hiệu lực thực tế của policy đó là gì. Nội dung policy nằm trong ảnh chụp, nhưng phần giải thích của nguồn cho biết rõ nó là mẫu policy quen thuộc: Effect: Deny toàn bộ hành động trên examplebucket1, kèm điều kiện StringNotEquals trên khoá aws:SourceVpce với giá trị là một VPC endpoint ID dạng vpce-2bd1s1209.

Cụm từ quyết định đáp án chính là khoá điều kiện aws:SourceVpce và giá trị vpce-.... Toàn bộ bốn phương án đều mô tả "hạn chế truy cập theo đường mạng", khác nhau ở chỗ đường mạng nào: VPC endpoint, Direct Connect, EC2 trong một VPC, hay VPC thuộc tài khoản khác. Chỉ cần đọc đúng tiền tố của ID là phân biệt được — vpce- là VPC endpoint, không phải vpc-, cũng không phải dxcon-. Đây là kiểu câu mà đề cố tình đặt bốn phương án gần nhau để xem thí sinh có phân biệt được các loại định danh trong VPC hay không.

Thêm một chi tiết đáng chú ý mà giải thích gốc nhấn mạnh: aws:SourceVpce chỉ nhận VPC endpoint ID, không cần ARN đầy đủ của endpoint — nên nhìn thấy chuỗi vpce-... trần trong policy là đúng cú pháp, không phải policy viết thiếu.

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

Đáp án đúng theo tệp là A — Access is restricted to connections coming from a specific VPC endpoint.

Cơ chế của policy: nó Deny mọi thao tác lên bucket trừ khi request đi qua đúng VPC endpoint có ID được liệt kê. Khi request tới S3 không đi qua endpoint đó, khoá aws:SourceVpce sẽ không khớp giá trị trong policy, điều kiện StringNotEquals thành true, và câu Deny có hiệu lực. Vì trong IAM một câu Deny tường minh luôn thắng mọi Allow, kết quả là không con đường nào khác chạm được vào bucket — kể cả người dùng có đầy đủ quyền qua IAM policy.

Đây chính xác là mẫu "khoá bucket vào một VPC endpoint" mà tài liệu S3 đưa ra cho dữ liệu nhạy cảm: dữ liệu chỉ đi qua đường riêng trong mạng AWS, không chấp nhận truy cập từ Internet công cộng.

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

B — hạn chế cho server kết nối qua AWS Direct Connect. Sai vì trong policy không có bất kỳ khoá điều kiện nào nói về Direct Connect, và ID vpce- không phải định danh của một Direct Connect connection (định danh đó có dạng khác hẳn). Đây là phương án dễ gây nhầm với người quen tư duy "kết nối riêng, không qua Internet" — về cảm giác thì giống, nhưng bucket policy không hề nhìn thấy khái niệm Direct Connect. Trên thực tế lưu lượng từ Direct Connect vẫn có thể đi qua VPC endpoint đó, nhưng cái policy kiểm tra vẫn là endpoint chứ không phải đường vật lý.

C — hạn chế cho các EC2 instance trong một VPC cụ thể. Đây là phương án gần đúng nhất và cũng bẫy nhất. Nó hỏng ở hai điểm. Thứ nhất, ID trong policy là VPC endpoint ID (vpce-) chứ không phải VPC ID (vpc-) — muốn giới hạn theo VPC thì phải dùng khoá aws:SourceVpc, một khoá khác. Thứ hai, điều kiện này lọc theo đường đi của request, không lọc theo loại principal: bất cứ thứ gì gửi request qua endpoint ấy đều qua được, không riêng gì EC2. Nói "EC2 instance" là thu hẹp sai đối tượng.

D — hạn chế cho kết nối đến từ một VPC ở tài khoản khác. Sai cùng lý do gốc với C: ID là endpoint chứ không phải VPC. Ngoài ra policy không chứa yếu tố nào liên quan tới tài khoản (không có aws:PrincipalAccount, không có aws:PrincipalOrgID), nên chuyện "cùng tài khoản hay khác tài khoản" hoàn toàn không phải điều policy này quan tâm.

📌 Điểm cần nhớ

• Đọc tiền tố của ID trước khi đọc phương án: vpce- là VPC endpoint, vpc- là VPC. Rất nhiều câu S3/VPC được phân biệt đúng bằng chi tiết này.
• aws:SourceVpce và aws:SourceVpc là hai khoá điều kiện khác nhau: một cái khoá theo endpoint, một cái khoá theo VPC. aws:SourceVpce chỉ cần endpoint ID, không cần ARN.
• Deny kèm StringNotEquals là mẫu chuẩn để ép một đường truy cập duy nhất: mọi request không thoả điều kiện đều bị chặn, và Deny tường minh ghi đè mọi Allow từ IAM policy.
• Điều kiện dạng này lọc theo đường đi của request, không lọc theo loại tài nguyên gửi request — đừng suy diễn thành "chỉ EC2" hay "chỉ tài khoản X" khi policy không nói tới principal.

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

Đề đặt ra tình huống: một SysOps Administrator được giao việc theo dõi chi phí phát sinh bởi từng người dùng (each user) trong một AWS account, và hỏi cách thu thập thông tin đó. Câu này chọn hai phương án.

Cụm từ quyết định là "costs incurred by each user" — chi phí quy về từng người dùng, chứ không phải tổng chi phí của account. AWS mặc định gom chi phí theo service, theo region, theo resource — không có sẵn chiều "ai đã tạo ra khoản chi này". Muốn có chiều đó thì phải có hai mảnh ghép:

1. Một cơ chế gắn nhãn người tạo lên resource, để dữ liệu billing có trường phân loại theo người dùng.
2. Một công cụ đọc và phân tích dữ liệu billing theo nhãn đó.

Cụm từ thứ hai đáng chú ý là "collect this information" — đề hỏi cách thu thập và xem thông tin, không phải cách cảnh báo khi chi phí vượt ngưỡng. Ràng buộc này chính là thứ loại bỏ phương án về alarm/budget, vốn trông rất hợp lý với chủ đề cost management.

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

Đáp án đúng theo tệp là A và E.

E — Activate the createdBy tag in the account. createdBy là một AWS generated tag: AWS tự định nghĩa và tự gắn lên các resource được hỗ trợ, phục vụ đúng mục đích cost allocation. Sau khi kích hoạt, AWS bắt đầu áp tag này lên những resource được tạo sau thời điểm kích hoạt — nghĩa là nó cung cấp chính xác chiều dữ liệu mà đề cần: resource này do ai tạo ra. Đây là mảnh ghép thứ nhất.

Vài đặc tính đáng nhớ của tag này: nó chỉ xuất hiện trong Billing and Cost Management console và các báo cáo billing, không hiện ở nơi nào khác trong AWS console, kể cả Tag Editor; và nó không tính vào giới hạn số tag trên mỗi resource.

A — Analyze the usage with Cost Explorer. Đây là mảnh ghép thứ hai: công cụ để thực sự xem và phân tích dữ liệu. Cost Explorer cho phép lọc và nhóm chi phí theo cost allocation tag, nên khi createdBy đã được kích hoạt, quản trị viên dùng Cost Explorer để tách chi phí theo từng giá trị của tag đó — tức là theo từng người dùng.

Hai phương án này bổ trợ nhau và phải đi cùng nhau: chỉ bật tag mà không có công cụ phân tích thì dữ liệu nằm im; chỉ mở Cost Explorer mà không có tag createdBy thì không có chiều "người dùng" nào để nhóm theo.

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

B — Use Amazon Inspector to advise on resource costs. Sai về bản chất dịch vụ. Amazon Inspector là dịch vụ đánh giá bảo mật tự động, quét lỗ hổng và vấn đề cấu hình trên workload. Nó không tư vấn hay báo cáo gì về chi phí. Đây là phương án nhiễu dễ loại nhất — chỉ cần nhớ Inspector thuộc nhóm security, không thuộc nhóm billing.

C — Create a billing alarm in AWS Budgets. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất, vì AWS Budgets đúng là dịch vụ trong mảng cost management. Nhưng nó hỏng ở chỗ sai chức năng so với yêu cầu đề: một billing alarm chỉ cảnh báo khi chi phí chạm ngưỡng đã đặt, nó không báo cáo phân rã chi phí theo từng người dùng. Đề hỏi "collect this information" — thu thập thông tin để theo dõi, chứ không hỏi cách được thông báo khi vượt ngân sách. Alarm cho bạn biết "đã tiêu quá nhiều", không cho biết "ai đã tiêu".

D — Create user metrics in Amazon CloudWatch. Sai vì hiểu nhầm mô hình dữ liệu của CloudWatch. Người dùng (IAM user) không phát ra metric; chỉ có AWS resource mới báo metric về CloudWatch. Không tồn tại khái niệm "user metrics" theo nghĩa đo chi phí của từng người dùng ở đây. Ngoài ra CloudWatch là công cụ giám sát vận hành (monitoring), dữ liệu billing chi tiết theo tag không nằm ở đó mà nằm ở Billing and Cost Management.

📌 Điểm cần nhớ

• Quy chi phí về từng người dùng luôn cần hai bước: gắn nhãn (cost allocation tag như createdBy) rồi mới phân tích (Cost Explorer). Gặp câu hỏi kiểu "chi phí theo từng user/team/project", hãy tìm cặp tag + công cụ phân tích, đừng chọn một phương án đơn lẻ.
• Phân biệt "báo cáo/phân tích" với "cảnh báo": Cost Explorer trả lời chi phí đi đâu; AWS Budgets và billing alarm trả lời đã vượt ngưỡng chưa. Đọc kỹ động từ trong đề — "collect", "analyze", "report" khác hẳn "notify", "alert", "prevent".
• createdBy là AWS generated tag đặc biệt: chỉ thấy được trong Billing and Cost Management console và báo cáo billing, không hiện trong Tag Editor, không tính vào giới hạn tag trên mỗi resource, và chỉ áp cho resource tạo sau khi kích hoạt — nên nó không hồi tố cho tài nguyên cũ.
• Nhớ đúng nhóm dịch vụ để loại nhiễu nhanh: Amazon Inspector = security assessment, Amazon CloudWatch = metric của resource phục vụ giám sát vận hành. Cả hai đều không phải nguồn dữ liệu chi phí theo người dùng.

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

Đề mô tả một công ty muốn triển khai cụm Amazon Elasticsearch Service (Amazon ES) để phân tích dữ liệu từ đội EC2 instances, và hỏi cấu hình nào đáp ứng yêu cầu.

Cụm từ quyết định đáp án là "highly available production-grade deployment" — triển khai mức production, có tính sẵn sàng cao. Đây không phải câu hỏi về hiệu năng hay chi phí, mà là câu hỏi về best practice cấu hình cụm. Với Amazon ES, "production-grade + highly available" quy về hai ràng buộc rất cụ thể:

1. Dedicated master nodes phải là số lẻ — và con số AWS khuyến nghị là ba.
2. Cụm Amazon ES là một domain nằm trong một Region, phân tán qua các Availability Zone, chứ không trải qua nhiều Region.

Chỉ cần hai ràng buộc này là bốn phương án tự loại nhau. Điểm phân biệt tinh vi nhất nằm ở A và C: cả hai giống hệt nhau về data nodes (sáu node, ba AZ), chỉ khác số master node. Đề cố tình dựng ra cặp này để kiểm tra bạn có nhớ luật số lẻ hay không.

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

A. Sáu data node trải trên ba Availability Zone, cùng ba dedicated master node.

• Ba dedicated master node là con số AWS khuyến nghị cho cụm production. Ba node cho phép một node giữ vai master và hai node còn lại làm dự phòng; khi master hỏng, số node còn lại vẫn đủ quorum để bầu master mới. Tách riêng master khỏi data node cũng có nghĩa là công việc quản lý cluster state không tranh giành tài nguyên với việc lập chỉ mục và truy vấn — đó chính là điều làm nên chữ "production-grade".
• Sáu data node trên ba AZ chia đều hai node mỗi AZ. Số data node chia hết cho số AZ giúp phân bố shard đều; mất trọn một AZ vẫn còn hai AZ hoạt động, cụm không mất quorum và bản sao shard vẫn còn.
• Ba AZ cũng là bố cục để ba dedicated master node nằm ở ba vùng lỗi khác nhau — mất một AZ chỉ mất một master.

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

B. Bốn data node trải trên hai AWS Region, mỗi Region bốn dedicated master node. Sai hai lần. Thứ nhất, bốn dedicated master node là số chẵn — AWS nói rõ bốn master không tốt hơn ba, và số chẵn còn gây rắc rối khi dùng nhiều AZ vì việc bầu chọn dễ rơi vào thế chia đôi. Thứ hai, một Amazon ES domain không trải data node qua nhiều Region theo kiểu này; tính sẵn sàng của Amazon ES được xây trên Availability Zone trong cùng một Region.

C. Sáu data node trải trên ba Availability Zone, cùng sáu dedicated master node. Đây là phương án gần đúng nhất và cũng là bẫy chính. Phần data node hoàn toàn ổn — giống hệt A. Chỗ hỏng nằm đúng ở master: sáu là số chẵn, vi phạm khuyến nghị không dùng số chẵn dedicated master node. Ngoài ra, nhiều master hơn không đồng nghĩa sẵn sàng hơn: thêm master chỉ thêm node phải đồng thuận với nhau, còn khả năng chịu lỗi thì không tăng tương ứng. Nhớ rằng "nhiều hơn = tốt hơn" không áp dụng cho master node.

D. Tám data node trải trên hai Availability Zone, bốn master node đặt ở một failover Region. Sai ở cả ba khía cạnh. Bốn master node lại là số chẵn. Đặt master ở Region khác thì sai hẳn về kiến trúc: dedicated master node phải nằm cùng Region với chính domain đó, không có kiểu master ở Region dự phòng điều khiển data node ở Region chính. Và hai AZ kém hơn ba AZ về khả năng chịu lỗi cho một triển khai được mô tả là production-grade.

📌 Điểm cần nhớ

• Dedicated master node: luôn là số lẻ, và ba là con số khuyến nghị cho production. Thấy phương án ghi bốn, sáu hay bất kỳ số chẵn nào thì loại ngay, kể cả khi phần còn lại của phương án trông rất hợp lý.
• Thêm master node không làm cụm sẵn sàng hơn. Master chỉ lo cluster state; muốn tăng năng lực xử lý thì thêm data node, không phải thêm master.
• Tính sẵn sàng của Amazon ES là chuyện của Availability Zone trong một Region, không phải chuyện của nhiều Region. Phương án nào rải data node hay master node qua nhiều Region trong cùng một domain thì đáng nghi ngay từ đầu.
• Chọn số data node chia hết cho số AZ (sáu node / ba AZ) để shard và bản sao phân bố đều; ba AZ chịu được mất trọn một AZ mà vẫn giữ được quorum.

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

Đề mô tả một web application chạy HTTP trong Amazon VPC, đặt sau Application Load Balancer trải trên nhiều Availability Zone. Người quản trị đã tạo cả security group lẫn network ACL cho load balancer, và cả hai đều mở inbound port 80. Vậy mà từ Internet vẫn không truy cập được. Câu hỏi: cần làm thêm gì nữa?

Cụm từ quyết định nằm ở chỗ đề nói rõ đã cấu hình hai lớp lọc khác nhau — security group và network ACL — nhưng chỉ mở chiều inbound. Đó chính là cái bẫy: hai lớp này xử lý chiều về (return traffic) theo hai cách hoàn toàn khác nhau. Security group là stateful, network ACL là stateless. Chỉ cần nhận ra điều đó là loại được ngay hai phương án nói về security group, và chỉ còn việc chọn đúng dải port cho chiều outbound của network ACL.

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

Đáp án đúng là B — thêm rule vào network ACL cho phép outbound traffic trên các port 1024 đến 65535.

Network ACL là tường lửa stateless: nó không ghi nhớ rằng có một kết nối đã được cho phép đi vào, nên mỗi chiều phải có rule riêng. Request từ Internet đi vào khớp rule inbound port 80 — không sao. Nhưng gói tin phản hồi đi ra lại bị đánh giá bằng bộ rule outbound, và nếu không có rule nào khớp thì nó bị chặn. Kết quả đúng như triệu chứng đề mô tả: cấu hình trông có vẻ đủ, nhưng người dùng ngoài Internet không nhận được gì.

Điểm mấu chốt là port đích của gói tin phản hồi. Khi client mở kết nối TCP, nó tự chọn một source port ngẫu nhiên trong dải ephemeral port cao (thường 1024–65535), rồi gửi tới port 80 của server. Khi server trả lời, gói tin đi ngược lại: đích chính là cái ephemeral port đó, chứ không phải port 80. Vì vậy rule outbound phải mở đúng dải port cao này thì lưu lượng trả về mới ra được.

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

A — thêm rule vào security group cho phép outbound trên port 1024–65535. Đây là phương án gần đúng nhất, vì dải port thì hoàn toàn chính xác. Nó hỏng ở chỗ đặt rule nhầm lớp. Security group là stateful: khi một kết nối inbound đã được cho phép, lưu lượng phản hồi của chính kết nối đó tự động được đi ra, bất kể rule outbound có gì. Thêm rule outbound ở đây không sửa được vấn đề vì vấn đề không nằm ở security group.

C — thêm rule vào security group cho phép toàn bộ outbound tới 0.0.0.0/0. Sai vì cùng lý do với A, chỉ khác là mở rộng hơn. Ngoài ra, security group mặc định vốn đã cho phép toàn bộ outbound, nên phương án này thường chẳng thay đổi gì cả — vừa không đúng lớp, vừa có khả năng chỉ lặp lại cấu hình đã tồn tại.

D — thêm rule vào network ACL cho phép outbound trên port 80 tới mọi đích. Phương án này đúng lớp (network ACL) nhưng sai port, nên là cái bẫy tinh vi nhất. Người ta dễ nghĩ "web chạy trên port 80 thì chiều ra cũng phải mở port 80". Thực tế rule outbound của network ACL đánh giá theo port đích của gói tin đi ra, mà đích của gói phản hồi là ephemeral port cao phía client, không phải port 80. Mở port 80 outbound chỉ giúp chính instance đó khởi tạo kết nối HTTP ra ngoài — không liên quan gì tới việc trả lời request của người dùng.

📌 Điểm cần nhớ

• Security group stateful, network ACL stateless. Gặp triệu chứng "inbound đã mở mà vẫn không truy cập được", hãy nghi ngay network ACL thiếu rule chiều còn lại; security group hầu như không bao giờ là nguyên nhân của lỗi kiểu này.
• Return traffic đi về ephemeral port, không đi về port dịch vụ. Với network ACL, rule outbound phục vụ chiều phản hồi phải mở dải port cao (1024–65535), chứ không phải port 80/443.
• Rule outbound port 80 của network ACL chỉ có nghĩa cho kết nối do chính resource trong VPC khởi tạo ra Internet — đừng lẫn hai tình huống này.
• Trong đề thi, khi hai phương án chỉ khác nhau ở chỗ "security group" hay "network ACL", tiêu chí phân biệt gần như luôn là tính stateful/stateless; khi hai phương án cùng lớp mà khác port, tiêu chí là chiều nào của kết nối đang được nói tới.