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

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

Đề mô tả một tình huống rất cụ thể: EC2 instance vừa được khởi chạy đã đi thẳng từ trạng thái pending sang terminated, gần như ngay lập tức. Cụm từ quyết định là "went from the pending state to the terminated state immediately after starting it" — tức là instance đã được nhận yêu cầu và bắt đầu vòng đời, rồi mới chết.

Đây là ranh giới phân biệt cả bốn phương án. Có hai nhóm sự cố hoàn toàn khác nhau khi chạy EC2:

1. Lỗi lúc gọi API RunInstances — yêu cầu bị từ chối ngay, instance không bao giờ tồn tại, người dùng nhận về một mã lỗi (InstanceLimitExceeded, InsufficientInstanceCapacity, access denied). Không có trạng thái pending, không có gì để nhìn trong console.
2. Lỗi sau khi instance đã được tạo — instance vào pending, EC2 cố dựng root volume rồi thất bại và tự chuyển sang terminated.

Tình huống trong đề thuộc nhóm 2, nên phải tìm nguyên nhân xảy ra trong lúc dựng instance, không phải nguyên nhân chặn ở cổng API.

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

Đáp án C: root EBS volume được mã hoá và Administrator không có quyền truy cập KMS key để giải mã.

Đây là một trong những nguyên nhân được AWS liệt kê chính thức cho hiện tượng "instance terminates immediately". Trình tự như sau: lời gọi RunInstances hợp lệ về mặt quyền EC2, nên yêu cầu được chấp nhận và instance chuyển sang pending. Nhưng để gắn được root EBS volume đã mã hoá, EC2 phải dùng KMS key tương ứng để giải mã. Khi principal thực hiện không có quyền trên key đó (key policy hoặc IAM policy không cho phép các thao tác giải mã), bước gắn volume thất bại — instance không có ổ đĩa gốc để boot, và EC2 chấm dứt nó ngay.

Điểm mấu chốt: quyền EC2 và quyền KMS là hai lớp kiểm tra tách rời, ở hai thời điểm khác nhau. Qua được lớp thứ nhất mới thấy được lớp thứ hai, và đó chính là lý do tạo ra vòng pending → terminated mà đề mô tả.

Cùng họ với nguyên nhân này còn có các trường hợp khác được AWS ghi nhận: chạm giới hạn EBS volume, EBS snapshot bị hỏng, hoặc AMI kiểu instance store thiếu một phần (image.part.xx). Tất cả đều có chung đặc điểm — hỏng ở khâu dựng ổ đĩa, không phải khâu xin phép.

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

A. AWS không còn đủ On-Demand capacity để phục vụ yêu cầu. Đây là tình huống có thật, nhưng nó xảy ra trước khi instance được tạo. Yêu cầu bị từ chối ngay tại API với lỗi InsufficientInstanceCapacity. Không có instance nào vào pending, nên không khớp với hiện tượng đề mô tả.

B. API action khởi chạy loại instance đó bị hạn chế trong tài khoản. Đây là phương án gần đúng nhất và dễ gây nhầm, vì nó cũng là chuyện về quyền — nhưng là quyền sai lớp. Hạn chế trên ec2:RunInstances (qua IAM policy hoặc SCP) chặn ngay tại lời gọi API, trả về access denied. Instance không được tạo ra, không có pending. Khác biệt với C nằm ở chỗ: quyền EC2 kiểm ở cổng vào, quyền KMS kiểm khi đã vào trong.

D. Vượt giới hạn số instance chạy được trong Region. Cũng là lỗi ở tầng API: trả về InstanceLimitExceeded và yêu cầu bị từ chối thẳng. Ngoài ra, nếu vượt hạn mức thì instance sẽ không được cấp phát chứ không phải được cấp rồi mới bị huỷ — lại một lần nữa không có giai đoạn pending.

Tóm lại: A, B, D đều là lỗi chặn trước, còn C là lỗi thất bại giữa chừng. Chỉ C tạo ra đúng chuỗi trạng thái mà đề nêu.

📌 Điểm cần nhớ

• Đọc kỹ trạng thái được mô tả trong đề. "Không khởi chạy được" và "khởi chạy rồi bị terminate ngay" là hai lớp sự cố khác nhau; trạng thái pending xuất hiện là dấu hiệu yêu cầu API đã thành công.
• Lỗi ở tầng API RunInstances (capacity, quota, IAM/SCP) luôn kèm một mã lỗi trả về ngay và không sinh ra instance nào.
• Instance terminate ngay lập tức thường là vấn đề của root volume: hết hạn mức EBS volume, snapshot hỏng, thiếu quyền trên KMS key của volume mã hoá, hoặc AMI instance store thiếu phần.
• Quyền EC2 không bao hàm quyền KMS. Khi dùng EBS mã hoá, principal khởi chạy phải được cấp quyền giải mã trên chính KMS key đó, nếu không mọi thứ trông ổn cho đến lúc instance chết.

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

Một SysOps Administrator đang có một S3 bucket mà users in other AWS accounts đang truy cập được, và yêu cầu là chỉ users trong cùng account mới được vào. Câu hỏi là làm thế nào để đạt điều đó.

Cụm từ quyết định nằm ở chỗ quyền cross-account đang tồn tại sẵn và việc cần làm là thu hồi nó, chứ không phải dựng thêm một cơ chế cấp quyền mới. Đây là bài toán gỡ một mục cấp quyền đang có, chứ không phải thêm một lớp bảo vệ. Ngoài ra, đề nói tới phạm vi bucket — nghĩa là thứ cần chỉnh phải là cấu hình ở cấp bucket.

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

Đáp án là A — Change the bucket access control list (ACL) to restrict access to the bucket owner.

Bucket ACL là một trong những cơ chế cấp quyền của S3, và nó chính là cơ chế thường dùng để cấp quyền cross-account: trong ACL có thể liệt kê các AWS account khác kèm quyền đọc/ghi. Khi quyền cross-account đã được cấp theo cách này, việc thu hồi đơn giản là xoá mục của account kia khỏi ACL, để lại duy nhất bucket owner.

Đúng như phần giải thích gốc mô tả: ACL của bucket sau khi sửa chỉ còn một dòng duy nhất là chủ sở hữu bucket, và từ đó không account ngoài nào còn quyền truy cập nữa. Đây là hành động trực tiếp nhắm đúng vào nguồn gốc của quyền đang bị thừa.

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

B — Create Amazon S3 presigned URLs for accessing objects in the bucket. Đây là phương án gần đúng nhất về mặt "nghe có vẻ liên quan tới kiểm soát truy cập", nhưng nó hỏng ở chỗ presigned URL là công cụ cấp quyền truy cập tạm thời cho người chưa có quyền, chứ không phải công cụ thu hồi quyền của người đã có. Tạo presigned URL không hề đụng tới các mục cross-account đang nằm trong ACL — users ở account khác vẫn vào được như cũ. Thêm nữa, mô hình này còn buộc phải phân phát URL cho từng người dùng, tức là thay vì siết lại, ta lại đẻ ra thêm một kênh truy cập cần quản lý.

C — Move the S3 bucket to the S3 One Zone-IA storage class and disable versioning. Đây là phương án lạc đề rõ nhất. Storage class quyết định chi phí lưu trữ và mức độ dư thừa dữ liệu, còn versioning quyết định việc giữ lại các phiên bản cũ của object. Cả hai đều không phải cơ chế phân quyền — đổi storage class hay tắt versioning không thay đổi một dòng nào trong ACL hay policy, nên users ở account khác vẫn truy cập bình thường. Tệ hơn, tắt versioning còn làm mất khả năng khôi phục object bị ghi đè hoặc xoá, tức là đánh đổi lấy rủi ro mà chẳng giải quyết được vấn đề nào.

D — Create an object policy that restricts access to only users in the same account. Đây là bẫy chữ nghĩa, và là phương án dễ chọn nhầm nhất vì ý tưởng "dùng policy để giới hạn về cùng account" nghe rất hợp lý. Vấn đề là không tồn tại thứ gọi là "object policy" trong S3. Các resource-based policy của S3 được gắn ở cấp bucket (bucket policy), còn phía identity thì có IAM policy gắn vào user/role. Không có cơ chế nào cho phép gắn một policy riêng lên từng object. Vì cái mà phương án đề xuất không tồn tại nên nó không thể là câu trả lời, dù ý định của nó đúng hướng.

📌 Điểm cần nhớ

• Khi đề nói quyền cross-account đã được cấp sẵn và cần thu hồi, hãy tìm đúng cơ chế đã cấp quyền đó mà sửa — bucket ACL là nơi liệt kê các AWS account khác được phép truy cập.
• Phân biệt rõ ba cơ chế phân quyền của S3: bucket ACL, bucket policy (resource-based, gắn ở cấp bucket) và IAM policy (identity-based). "Object policy" là khái niệm không có thật — thấy nó trong đề thi thì loại ngay.
• Presigned URL là để cấp quyền tạm thời cho người chưa có quyền, không phải để chặn người đang có quyền. Đừng chọn nó cho các câu hỏi mang nghĩa "hạn chế/thu hồi truy cập".
• Storage class và versioning không liên quan gì tới access control. Bất kỳ phương án nào chữa vấn đề phân quyền bằng cách đổi storage class đều là phương án gây nhiễu.

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

Đề mô tả một web application vừa chuyển từ on-premises lên một Amazon EC2 instance duy nhất, và đặt ra ba ràng buộc:

• "a single static public IP address" — cần đúng một địa chỉ IP public cố định, không đổi.
• "accessible to end-users via the example.com domain" — người dùng phải vào được bằng tên miền gốc (zone apex), không phải subdomain kiểu www.example.com.
• "minimizes the management effort" — chọn cách vận hành ít việc nhất.

Cụm quyết định là "single static public IP address" kết hợp với "example.com" (tên miền gốc). Vế thứ nhất loại ngay những phương án làm IP thay đổi hoặc không có IP cố định; vế thứ hai loại phương án dùng loại bản ghi DNS không đặt được ở zone apex. Chú ý mặc định: EC2 instance nhận public IP tự động, nhưng IP đó bị thu hồi và thường đổi mỗi lần stop rồi start lại — nên "để nguyên như hiện tại" không đáp ứng yêu cầu.

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

D — Tạo Elastic IP và gắn vào EC2 instance. Elastic IP là địa chỉ IPv4 public tĩnh dành riêng cho môi trường cloud. Khi đã associate với instance, instance giữ nguyên địa chỉ đó qua các lần stop/start. Đây chính là "single static public IP address" mà đề đòi, và chỉ là một thao tác gắn kết một lần — đúng tinh thần "minimize management effort".

B — Tạo bản ghi A trên Amazon Route 53 trỏ tới IP của EC2 instance. Có IP tĩnh rồi thì vẫn cần cách để người dùng gõ example.com mà tới được. Route 53 là dịch vụ DNS, và bản ghi A ("Address") là loại bản ghi ánh xạ một tên miền sang một địa chỉ IPv4. Bản ghi A đặt được ngay tại zone apex example.com. Khi người dùng truy cập example.com, Route 53 trả về Elastic IP, request đi thẳng tới instance.

Hai hành động này bổ trợ nhau: D lo phần "IP không đổi", B lo phần "tên miền dẫn tới IP đó".

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

A — Auto Scaling group với min 1, max 2. Sai theo đúng yêu cầu cốt lõi. Đề nói rõ ứng dụng chạy trên một instance và cần một IP tĩnh; Auto Scaling sinh ra để tự động thay đổi số lượng instance, không giải quyết chuyện IP tĩnh cũng không giải quyết chuyện tên miền. Tệ hơn, instance do Auto Scaling launch ra nhận public IP mới mỗi lần, tức là đi ngược yêu cầu "static public IP". Nó cũng làm tăng công quản lý chứ không giảm.

C — Application Load Balancer, đưa EC2 instance vào target group. Đây là phương án "gần đúng" dễ mắc bẫy nhất, vì ALB thường là câu trả lời quen tay cho bài toán đưa web app ra Internet. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: ALB không có địa chỉ IP tĩnh — nó phân giải ra nhiều IP và các IP này có thể thay đổi theo thời gian. Ngoài ra ALB sinh ra để phân phối tải qua nhiều target; với một instance duy nhất thì nó không mang lại giá trị mà chỉ thêm một thành phần phải quản lý, ngược với "minimize management effort".

E — Bản ghi CNAME trên Route 53 trỏ tới IP của EC2 instance. Sai vì hai lý do độc lập, mỗi lý do đủ để loại:

1. CNAME ánh xạ một tên miền sang một tên miền khác, không sang địa chỉ IP. Bản thân cách diễn đạt "CNAME trỏ tới IP" đã không hợp lệ về mặt DNS.
2. Theo thứ bậc DNS, không đặt được CNAME tại zone apex (tên miền gốc) — mà đề yêu cầu chính example.com, đúng là zone apex. Nếu đề hỏi về www.example.com trỏ tới một tên DNS khác thì CNAME mới có chỗ đứng.

📌 Điểm cần nhớ

• "Static public IP" cho một EC2 instance ⇒ Elastic IP. Public IP mặc định của EC2 bị trả lại và đổi sau stop/start; chỉ Elastic IP mới giữ nguyên.
• A record trỏ tên miền → địa chỉ IPv4; CNAME trỏ tên miền → tên miền. Thấy phương án nào nói "CNAME tới IP" thì loại ngay, không cần đọc tiếp.
• CNAME không đặt được ở zone apex. Đề nhắc tên miền trần (example.com, không có www.) là tín hiệu để loại CNAME và giữ A record.
• ALB không cho IP tĩnh, và không có ý nghĩa với một target duy nhất. Khi đề nhấn mạnh "single instance" + "static IP" + "minimize management effort", load balancer và Auto Scaling thường là bẫy chứ không phải lời giải.

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

Đề đặt ra một tình huống rất hẹp: SysOps Administrator cần kiểm soát quyền truy cập vào một nhóm nhỏ EC2 instances, và các tag cụ thể đã được gắn sẵn lên những instance đó. Câu hỏi yêu cầu chọn hai hành động bổ sung để hoàn tất việc kiểm soát truy cập.

Cụm từ quyết định là "Specific tags have been added to the EC2 instances" kết hợp với "additional actions". Việc gắn tag đã xong rồi — nên mọi phương án đề nghị gắn thêm tag hay tạo thêm hạ tầng để sinh tag đều là làm lại việc đã có. Cụm thứ hai là "control access" hiểu theo nghĩa ai được phép thao tác lên instance, chứ không phải instance được phép gọi dịch vụ nào. Phân biệt được hai chiều này là chìa khoá loại bỏ các phương án gần giống nhau.

Với tag đã có sẵn, bài toán còn lại chỉ gồm hai mảnh ghép: viết một IAM policy biết đọc tag đó, và gắn policy ấy vào đúng identity cần cấp quyền.

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

A — Attach an IAM policy to the users or groups that require access. IAM policy chỉ có hiệu lực khi được gắn vào một identity. Viết policy mà không attach thì không ai nhận được quyền cả. Vì đây là identity-based policy, đối tượng gắn phải là chính những user (hoặc group chứa họ) cần thao tác lên EC2. Thực hành tốt là đưa user vào group rồi attach policy lên group, để về sau thêm/bớt người chỉ là việc sửa thành viên group chứ không phải sửa policy.

D — Create an IAM policy that grants access to the instances with the specific tag using the Condition element. Đây là mảnh ghép biến "tag đã gắn" thành "quyền thực sự". Trong IAM policy, Condition là nơi so khớp thuộc tính của tài nguyên — với EC2, các khoá điều kiện dạng tag cho phép giới hạn hành động chỉ áp dụng lên những instance mang đúng tag đó. Nhờ vậy policy không cần liệt kê từng instance ID; instance mới gắn đúng tag sẽ tự động nằm trong phạm vi, còn instance gỡ tag thì tự động ra ngoài.

Hai phương án này bổ trợ nhau: D định nghĩa được làm gì, trên tài nguyên nào; A quyết định ai được hưởng. Thiếu một trong hai thì cơ chế không chạy.

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

B — Create an IAM policy that grants access to the instances based on the Principal element. Đây là phương án gần đúng nhất và cũng là bẫy chính. Principal là phần tử dùng để chỉ ra ai được phép — nhưng nó chỉ tồn tại trong resource-based policy (và trust policy), nơi policy gắn vào tài nguyên nên phải tự khai người dùng. Ở đây ta đang gắn policy vào user/group (phương án A), tức là identity-based policy: identity đã được xác định bằng chính chỗ attach, nên không cần và cũng không dùng Principal. Quan trọng hơn: Principal chỉ ra người, không chỉ ra instance mang tag — nó không giải quyết được mảnh việc mà Condition đảm nhiệm.

C — Attach an IAM role to the Amazon EC2 instances. Đúng cơ chế nhưng sai chiều. Role gắn lên EC2 cấp quyền cho ứng dụng chạy bên trong instance đi gọi các dịch vụ AWS khác (ví dụ đọc S3). Nó hoàn toàn không nói gì về việc user nào được phép start, stop hay terminate chính instance đó. Đề hỏi kiểm soát truy cập tới instance, còn phương án này cấp quyền từ instance đi ra.

E — Create an Auto Scaling group for the EC2 instances and add a specific tag. Auto Scaling group là công cụ về khả năng co giãn và tính sẵn sàng, không phải cơ chế uỷ quyền — nó không cấp hay chặn quyền cho bất kỳ ai. Phần "add a specific tag" còn thừa trực tiếp: đề đã nói rõ tag đã được gắn lên instance rồi. Dựng ASG chỉ để có tag là thêm một lớp hạ tầng không liên quan tới yêu cầu.

📌 Điểm cần nhớ

• Tag-based access control trong IAM luôn đi qua Condition. Tag chỉ là nhãn dán trơ; chỉ khi policy so khớp tag trong Condition thì nhãn ấy mới có hiệu lực về quyền.
• Phân biệt hai chiều quyền của EC2: IAM role gắn lên instance là quyền để instance gọi dịch vụ khác; IAM policy gắn lên user/group mới là quyền để người dùng thao tác lên instance.
• Principal thuộc về resource-based policy, không thuộc identity-based policy. Khi policy đã được attach vào user/group thì chủ thể đã xác định, thấy phương án nào nhắc Principal trong ngữ cảnh này là nghi ngờ ngay.
• Attach policy vào group thay vì từng user. Quản lý quyền theo group giúp việc thêm/bớt người không phải động vào nội dung policy.
• Đọc kỹ những gì đề nói "đã làm rồi". Phương án đề nghị làm lại việc đã hoàn tất (ở đây là gắn tag) gần như luôn là phương án loại.

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

Đề mô tả một ứng dụng được nhiều front-end server ở các region khác nhau gọi tới, phía trước có AWS WAF bảo vệ. Yêu cầu của SysOps Administrator là nhận diện và đếm request đến từ từng front-end server, rồi hỏi phải thêm condition nào vào web ACL.

Cụm từ quyết định nằm ở câu: "Each request contains a header that includes the ID of the front-end server making the request."

Hai chi tiết trong cụm này khoá chặt đáp án:

• Thông tin phân biệt các server nằm trong một header của HTTP request, tức là một thành phần của request mà WAF có thể trỏ tới để kiểm tra.
• Giá trị cần tìm là một ID dạng chuỗi ký tự, không phải kích thước, không phải địa chỉ mạng.

Nói cách khác, đề đang hỏi: loại điều kiện nào của WAF cho phép soi nội dung văn bản ở một vị trí cụ thể trong request? Đó chính là tiêu chí lọc ra đáp án đúng giữa bốn phương án.

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

B — String match là đáp án đúng.

Một string match statement khai báo ba thứ: chuỗi cần tìm, tìm ở đâu trong request (query string, URI, body, hoặc một header cụ thể), và tìm theo kiểu nào (khớp chính xác, bắt đầu bằng, chứa…). Ví dụ trong tài liệu AWS chính là dạng "khớp chính xác header User-Agent" — cùng đúng khuôn với tình huống ở đây: header chứa ID server.

Vì ID của front-end server là một chuỗi nằm trong header, string match là công cụ duy nhất trong danh sách có thể trỏ đúng vào header đó và so khớp giá trị. Khi rule đã nhận diện được từng ID, web ACL dùng action Count để ghi nhận số lượt mà không chặn traffic — nhờ đó administrator đếm được request từ mỗi server. Mỗi front-end server tương ứng một rule string match với chuỗi ID riêng.

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

A — Size constraint. Đây là điều kiện so sánh độ dài (số byte) của một phần trong request — ví dụ chặn body vượt quá một ngưỡng nào đó. Nó chỉ áp đặt giới hạn kích thước chứ không đọc được nội dung bên trong. Dù có trỏ vào đúng header chứa ID, size constraint cũng chỉ biết header đó dài bao nhiêu byte, không biết ID là gì — mà các ID khác nhau hoàn toàn có thể dài bằng nhau. Không phân biệt được server nào với server nào.

C — IP match. Đây là phương án gần đúng nhất và dễ mắc bẫy: nó đúng là dùng để phân biệt nguồn gửi request, và nếu đề bài nói "mỗi front-end server có một địa chỉ IP cố định" thì IP match sẽ hợp lý. Nhưng đề đã nêu rõ căn cứ phân biệt là ID nằm trong header, chứ không phải địa chỉ IP nguồn. IP match set chỉ nhận vào địa chỉ và dải IP — nó không đọc header, và ID ở đây là chuỗi ký tự chứ không phải IP address. Chỗ nó hỏng: nó khớp sai thứ mà đề chỉ định.

D — ID match. Nghe rất khớp với từ "ID" trong đề nên trông thuyết phục, nhưng đây không phải là một loại condition/match statement có thật trong AWS WAF. Đây là kiểu phương án bịa tên dựa trên từ khoá của đề bài — chỉ cần nhớ danh sách các loại statement mà WAF thực sự hỗ trợ là loại được ngay.

📌 Điểm cần nhớ

• Trong AWS WAF, string match là loại statement dùng để tìm một chuỗi ở một vị trí xác định của request (header, URI, query string, body) — bất cứ khi nào đề nói "header chứa giá trị X", hãy nghĩ tới string match.
• Size constraint chỉ đo độ dài, không đọc nội dung; IP match chỉ làm việc với địa chỉ/dải IP nguồn. Đọc kỹ xem đề chỉ định phân biệt theo nội dung hay theo địa chỉ mạng.
• Muốn đếm mà không chặn, dùng action Count trong web ACL — đây là cách chuẩn để quan sát và đo lường traffic trước khi quyết định chặn.
• Cảnh giác với phương án lặp lại nguyên từ khoá của đề (ở đây là "ID match"): tên nghe khớp nhưng không tồn tại trong danh mục thật của dịch vụ.

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

Đề mô tả Program X chạy trên EC2 instances phía sau một Network Load Balancer, cùng nằm trong một subnet. Hệ thống ở data center nội bộ không kết nối được tới ứng dụng qua port 8081, và SysOps administrator phải đọc VPC Flow Logs để tìm nguyên nhân.

Cụm từ quyết định nằm ngay trong hai dòng log, đọc theo cặp:

• Dòng 1: 10.0.1.23 → 172.32.17.148, source port 60004, destination port 8081, kết quả ACCEPT.
• Dòng 2: 172.32.17.148 → 10.0.1.23, source port 8081, destination port 60004, kết quả REJECT.

Đây là cùng một phiên kết nối, chỉ khác chiều. Chiều đi vào (inbound tới port 8081) được chấp nhận; chiều trả lời (outbound từ 8081 về ephemeral port 60004) bị chặn. Ràng buộc phân biệt các phương án chính là chỗ này: gói tin đã tới được instance rồi, cái hỏng là đường về. Bất kỳ phương án nào giải thích lỗi ở chiều đi vào đều mâu thuẫn với dòng ACCEPT đầu tiên.

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

Đáp án đúng theo tệp là B — network ACL gắn với subnet không cho phép outbound traffic ở dải ephemeral port.

Network ACL là stateless: nó xét từng gói tin độc lập, chiều vào và chiều ra phải được cho phép riêng biệt. Một kết nối TCP tới port 8081 sẽ có gói trả lời đi ngược lại tới ephemeral port mà client đã chọn — ở đây là 60004. Nếu outbound rule của network ACL không phủ dải ephemeral port, gói trả lời bị REJECT đúng như dòng log thứ hai, dù gói đến đã ACCEPT.

Triệu chứng mà người dùng nhìn thấy khớp hoàn toàn: từ phía data center, kết nối "không vào được ứng dụng" — thực chất là bắt tay không hoàn tất vì không có phản hồi quay về. Chữ REJECT trong flow log là dấu hiệu đặc trưng của việc bị chặn bởi rule ở tầng mạng chứ không phải do ứng dụng từ chối.

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

A — Security group gắn với NLB thiếu rule cho phép traffic từ data center. Sai ngay ở tiền đề kỹ thuật: Network Load Balancer không gắn được security group theo mô hình mà câu hỏi này dựa vào (khác với Application Load Balancer). Không có đối tượng nào để cấu hình rule như phương án mô tả, nên đây không thể là nguyên nhân.

C — Firewall ở data center nội bộ không cho traffic đi tới VPC. Đây là phương án gần đúng nhất về mặt trực giác, vì triệu chứng ban đầu đúng là "từ data center không kết nối được". Nhưng nó hỏng ở chỗ bằng chứng: dòng log đầu tiên cho thấy gói tin đã đi từ 10.0.1.23 tới instance và được ACCEPT. Nếu firewall on-premises chặn chiều đi ra thì gói tin sẽ không bao giờ tới VPC để xuất hiện trong flow log. Ngoài ra, flow log chỉ ghi lại lưu lượng ở phía ENI trong VPC, không nói được gì về chính sách firewall bên trong data center — kết luận về nó là suy diễn không có dữ liệu.

D — Security group của EC2 instances thiếu rule cho traffic đến từ NLB. Cũng gần đúng, nhưng mâu thuẫn với dòng ACCEPT. Security group là stateful: nếu nó đã cho gói tin vào tới port 8081 thì gói trả lời của đúng kết nối đó tự động được phép đi ra, không cần rule outbound riêng. Vậy nên một security group thiếu rule inbound sẽ khiến gói đầu tiên bị chặn — trái với log — còn tính stateful của nó lại loại trừ khả năng gây ra REJECT ở chiều về. Chính điểm stateful/stateless là thứ tách D khỏi B.

📌 Điểm cần nhớ

• Security group stateful, network ACL stateless. Thấy chiều đi ACCEPT mà chiều về REJECT thì nghi network ACL trước, vì security group đã tự cho phép lưu lượng trả về của kết nối nó đã chấp nhận.
• Đọc flow log theo cặp hai chiều, đối chiếu source/destination port đảo nhau. Cặp ACCEPT + REJECT xác định chính xác chiều nào hỏng, và điều đó gạt bỏ mọi phương án nói về chiều còn lại.
• Dải ephemeral port phải được mở ở outbound rule của network ACL để lưu lượng phản hồi quay về client. Đây là lỗi cấu hình kinh điển khi ai đó siết network ACL bằng rule tường minh.
• Network Load Balancer không nhận security group theo cách Application Load Balancer nhận — phương án nào nói "security group của NLB" thường là bẫy loại được ngay không cần đọc log.

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

Đề mô tả một tình huống rất gọn: CloudWatch agent đã được cài trên vài EC2 instance, đã được cấu hình để gửi custom metrics lên CloudWatch. Việc còn lại duy nhất là tạo một CloudWatch dashboard để hiển thị chúng.

Cụm từ quyết định đáp án là "custom metrics" — và đi kèm với nó là khái niệm namespace. Trong CloudWatch, mọi metric đều nằm trong một namespace. Metric do AWS tự sinh ra nằm trong các namespace có tiền tố AWS/ (AWS/EC2, AWS/RDS...), còn metric do agent hay ứng dụng tự đẩy lên nằm trong custom namespace do người cấu hình đặt tên (ví dụ CWAgent). Vì vậy câu hỏi thực chất kiểm tra: bạn có biết tìm custom metrics ở đâu trong màn hình chọn metric của dashboard không.

Cụm từ thứ hai đáng chú ý là "The agent has been configured to send" — nghĩa là phần thu thập dữ liệu đã xong. Đề không hỏi cách tạo ra metric, nên mọi phương án nói về việc sinh metric (metric filter, event) đều lệch đề ngay từ tiền đề.

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

Đáp án đúng theo tệp là B — "Select the appropriate widget and metrics from the custom namespace, then add to the dashboard".

Đây đúng là quy trình chuẩn tạo dashboard trong CloudWatch: mở CloudWatch console → tạo dashboard → thêm widget (line, stacked area, number, gauge...) → ở màn hình chọn metric, chọn namespace tương ứng, ở đây là custom namespace mà CloudWatch agent đang ghi vào → chọn metric cần vẽ → thêm vào dashboard và lưu.

Hai chi tiết khớp chính xác với đề bài:

• Widget là đơn vị cấu thành dashboard — không có widget thì dashboard chỉ là một trang trống.
• Custom namespace là nơi metric của agent thực sự nằm, đúng như bản giải thích tiếng Anh nhấn mạnh: "choose the metrics from the custom namespace".

Metric đã được agent đẩy lên rồi, nên không cần thao tác xử lý dữ liệu nào thêm — chỉ cần chọn và hiển thị.

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

A — "Open the CloudWatch console, then from CloudWatch Events, add all custom metrics" Sai vì nhầm hẳn thành phần. CloudWatch Events (nay là EventBridge) là dịch vụ xử lý sự kiện — bắt các thay đổi trạng thái trong tài khoản rồi kích hoạt hành động (chạy Lambda, gửi thông báo, chạy theo lịch). Nó không phải nơi duyệt hay hiển thị metric, và cũng không có thao tác "add custom metrics to a dashboard" trong đó. Muốn xem metric thì phải qua dashboard, đúng như bản giải thích tiếng Anh nói.

C — "Open the CloudWatch Logs console, create metric filters, and select the custom metrics" Đây là phương án gần đúng nhất và cũng là bẫy hay ăn điểm nhất, vì metric filter thật sự là một cách tạo ra custom metric. Nhưng nó hỏng ở tiền đề của đề bài: metric filter dùng để trích số liệu từ log đẩy vào CloudWatch Logs rồi biến chúng thành metric. Ở đây agent đã gửi custom metrics trực tiếp rồi — dữ liệu đã ở dạng metric, không phải log cần bóc tách. Làm thêm metric filter là giải một bài toán không tồn tại, và cũng không tạo ra dashboard nào cả. Câu hỏi này không liên quan tới CloudWatch Logs.

D — "Select the AWS Namespace, filter by metric name, then add to the dashboard" Đây là phương án sát nhất với đáp án đúng, và chỉ khác đúng một chữ: nó chọn AWS namespace thay vì custom namespace. Quy trình còn lại (chọn metric, thêm vào dashboard) thì đúng — nhưng namespace sai thì sẽ không bao giờ tìm thấy metric của agent ở đó. Namespace AWS/EC2 chỉ chứa metric do chính EC2 phát ra (CPUUtilization, NetworkIn...), không chứa metric mà agent tự định nghĩa. Lọc theo tên metric trong một namespace không chứa nó thì kết quả là rỗng. Đây chính là điểm phân biệt mà đề cài vào.

📌 Điểm cần nhớ

• Namespace là thứ phân biệt metric của AWS với metric của bạn. Metric do AWS sinh ra nằm trong namespace có tiền tố AWS/; metric do CloudWatch agent hoặc ứng dụng tự đẩy lên nằm trong custom namespace. Gặp chữ "custom metrics" trong đề, loại ngay mọi phương án bảo chọn AWS namespace.
• Đọc kỹ tiền đề đã hoàn thành. Nếu đề nói dữ liệu "đã được gửi lên" rồi, thì phương án nói về cách tạo ra dữ liệu (metric filter, cấu hình lại agent) là lệch đề, dù bản thân kỹ thuật đó có thật.
• Phân biệt ba thành phần cùng mang tên CloudWatch: CloudWatch metrics/dashboards để đo và hiển thị số liệu; CloudWatch Logs để chứa và truy vấn log (metric filter sống ở đây); CloudWatch Events/EventBridge để phản ứng với sự kiện. Nhiều câu hỏi chỉ đơn giản kiểm tra bạn có nhầm ba thứ này với nhau không.
• Dashboard được dựng từ widget. Quy trình luôn là: tạo dashboard → thêm widget → chọn namespace → chọn metric → lưu. Phương án nào mô tả đúng chuỗi này thường là đáp án.

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

Đề bài nói về một công ty cần theo dõi việc phân bổ (allocation) khoản giảm giá Reserved Instance trong hoá đơn hợp nhất (consolidated bill), và hỏi công cụ AWS nào cho ra được thông tin đó.

Cụm từ quyết định là "track the allocation of Reserved Instance discounts" — tức là truy ra từng dòng sử dụng nào đang hưởng giảm giá, và khoản giảm giá đó đến từ reservation nào. Đây không phải câu hỏi "làm sao gộp hoá đơn nhiều tài khoản" và cũng không phải "làm sao cảnh báo khi chi vượt ngưỡng". Nó đòi hỏi dữ liệu chi tiết ở mức line item kèm thông tin về reservation.

Cụm "consolidated bill" là chi tiết gây nhiễu có chủ đích: nó khiến người đọc lập tức nghĩ tới công cụ tạo ra hoá đơn hợp nhất, trong khi câu hỏi thật sự là phân tích nội dung hoá đơn đó chứ không phải tạo ra nó.

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

D. AWS Cost and Usage report là đáp án đúng.

Cost and Usage Report (CUR) là bộ dữ liệu chi phí chi tiết nhất mà AWS cung cấp, bao gồm cả thông tin về dịch vụ, giá, và reservation. Với chủ đề của câu hỏi, hai đặc điểm sau là điểm mấu chốt:

• Truy vết phân bổ giảm giá Reserved Instance: mỗi dòng sử dụng được hưởng giảm giá đều mang thông tin cho biết khoản giảm giá đến từ đâu, nên có thể lần ra instance nào đang được hưởng lợi từ reservation cụ thể nào. Đây chính xác là điều đề bài yêu cầu.
• Tính được phần tiết kiệm: mỗi dòng sử dụng theo giờ ghi cả mức giá đã được chiết khấu lẫn mức giá On-Demand công khai tại thời điểm đó, nên lấy hiệu hai con số là ra số tiền tiết kiệm được.

CUR còn kèm những trường như ARN của reservation, số lượng reservation, số đơn vị mỗi reservation — đúng mức chi tiết cần để đối chiếu trong một hoá đơn hợp nhất gồm nhiều tài khoản.

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

A. AWS Organizations — Đây là phương án gần đúng nhất, và cũng là cái bẫy chính của câu hỏi. Organizations đúng là thứ tạo ra consolidated billing cho nhiều tài khoản, và cũng chính nó cho phép các tài khoản trong tổ chức dùng chung lợi ích Reserved Instance. Nhưng vai trò của nó dừng ở chỗ thiết lập cấu trúc tài khoản và gộp hoá đơn; nó không phải công cụ báo cáo, không đưa ra dữ liệu ở mức line item để bạn xem dòng nào hưởng giảm giá từ reservation nào. Muốn phân tích thông tin trong hoá đơn hợp nhất đó thì vẫn phải dùng Cost and Usage report. Đề hỏi công cụ để tìm thông tin, không hỏi công cụ để tạo ra hoá đơn hợp nhất.

C. AWS Budgets — Cũng thuộc nhóm cost management nên nghe hợp lý. Nhưng Budgets là công cụ đặt ngưỡng chi tiêu và cảnh báo khi chi phí hoặc mức sử dụng chạm/vượt ngưỡng đã định. Nó trả lời câu hỏi "tôi có đang tiêu quá dự kiến không", chứ không cung cấp mức báo cáo chi tiết để truy vết từng khoản giảm giá về từng reservation. Sai vì sai mục đích công cụ: cảnh báo ≠ báo cáo phân tích.

B. Amazon Inspector — Sai rõ ràng nhất vì lệch hẳn nhóm dịch vụ. Inspector đưa ra khuyến nghị theo best practice (đánh giá, rà soát workload), hoàn toàn không liên quan tới báo cáo chi phí hay dữ liệu billing. Nó không hề chạm tới dữ liệu Reserved Instance hay hoá đơn. Loại được ngay từ vòng đọc đầu tiên.

📌 Điểm cần nhớ

• Thấy từ khoá đòi chi tiết mức line item — truy vết giảm giá RI/Savings Plans, tính chính xác phần tiết kiệm, đối chiếu từng dòng sử dụng — thì đáp án gần như luôn là AWS Cost and Usage Report, vì đó là bộ dữ liệu chi phí chi tiết nhất của AWS.
• Phân biệt rõ vai trò trong nhóm cost management: Organizations dựng cấu trúc tài khoản và gộp hoá đơn; Budgets đặt ngưỡng và cảnh báo; Cost and Usage report là nơi phân tích sâu. Đề nhắc "consolidated bill" không có nghĩa đáp án là Organizations — hãy đọc kỹ động từ trong câu hỏi (track, find this information = phân tích, không phải thiết lập).
• Với câu hỏi về chi phí, hãy loại ngay các dịch vụ không thuộc nhóm billing/cost. Amazon Inspector nằm ở nhóm đánh giá/khuyến nghị, xuất hiện ở đây chỉ để làm nhiễu.
• Mẹo đọc đề: động từ quyết định công cụ. Alert / notify khi vượt ngưỡng → Budgets. Track / trace / analyze chi tiết từng dòng → Cost and Usage report.

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

Đề mô tả một ứng dụng chạy trên các EC2 instance nằm trong Auto Scaling group, đứng sau một Application Load Balancer (ALB). Yêu cầu: đặt một CloudWatch alarm kêu khi tất cả target instance phía sau ALB đều unhealthy.

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

1. "behind the ALB" — sức khoẻ ở đây là sức khoẻ do ALB đánh giá qua health check của target group, chứ không phải sức khoẻ phần cứng/hệ điều hành của EC2. Cụm này quyết định namespace: phải là AWS/ApplicationELB, không phải AWS/EC2.
2. "all target instances ... are unhealthy" — tất cả, tức là số instance khoẻ mạnh còn lại bằng 0. Cụm này quyết định ngưỡng và chiều so sánh: HealthyHostCount <= 0.

Bốn phương án được dựng thành lưới 2×2 quanh đúng hai trục đó: hai phương án sai namespace, hai phương án đúng namespace nhưng một trong hai đảo ngược chiều so sánh. Đọc lướt chỉ bắt được một trục là dễ chọn nhầm.

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

C — trong namespace AWS/ApplicationELB, alarm khi metric HealthyHostCount <= 0.

HealthyHostCount là metric do chính Application Load Balancer phát ra, đếm số target đang được ALB coi là healthy trong một target group. Đây đúng là góc nhìn mà đề bài hỏi: "target instances behind the ALB" — trạng thái theo đánh giá của load balancer.

Chiều so sánh cũng khớp với chữ "all": nếu mọi target đều unhealthy thì số host khoẻ mạnh còn lại là 0, nên điều kiện HealthyHostCount <= 0 chuyển alarm sang trạng thái ALARM đúng vào thời điểm ứng dụng không còn chỗ nào nhận được request. Không cần thiết lập ngưỡng theo số instance cụ thể — dùng 0 nên alarm vẫn đúng khi Auto Scaling group co giãn thay đổi số lượng instance.

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

A — AWS/EC2, StatusCheckFailed_System <= 0. Sai cả hai trục. Namespace AWS/EC2 phản ánh status check của hạ tầng EC2, hoàn toàn không biết gì về kết quả health check của target group; một instance có thể pass status check nhưng ứng dụng bên trong trả lỗi và bị ALB đánh dấu unhealthy. Ngoài ra StatusCheckFailed_System <= 0 nghĩa là không có lỗi hạ tầng — tức là alarm kêu lúc mọi thứ đang bình thường, ngược hẳn ý định.

B — AWS/EC2, StatusCheckFailed_Instance >= 1. Đây là phương án gần đúng nhất trong hai phương án AWS/EC2, vì ít nhất chiều so sánh có nghĩa: nó kêu khi có từ một instance trở lên hỏng status check mức instance. Nhưng nó hỏng ở hai chỗ. Thứ nhất, sai namespace nên vẫn không đo được thứ đề hỏi — status check của EC2 khác với health check của ALB. Thứ hai, >= 1 nghĩa là có ít nhất một instance hỏng, trong khi đề hỏi trạng thái tất cả đều unhealthy; alarm này sẽ kêu ngay cả khi phần lớn instance vẫn phục vụ tốt.

D — AWS/ApplicationELB, HealthyHostCount >= 1. Đúng namespace, đúng metric, chỉ đảo chiều so sánh — và chính vì thế mà nguy hiểm, nó là phương án dễ chọn nhầm nhất. HealthyHostCount >= 1 nghĩa là alarm ở trạng thái ALARM khi còn ít nhất một target khoẻ mạnh, tức là kêu liên tục trong suốt thời gian hệ thống chạy tốt và im lặng đúng lúc mọi target chết. Hoàn toàn ngược với yêu cầu.

📌 Điểm cần nhớ

• Chọn metric phải bắt đầu từ namespace: AWS/ApplicationELB cho những gì load balancer đánh giá (HealthyHostCount, UnHealthyHostCount), AWS/EC2 cho status check hạ tầng (StatusCheckFailed_Instance, StatusCheckFailed_System). Instance pass status check vẫn có thể unhealthy dưới mắt ALB.
• Dịch chữ trong đề sang ngưỡng số: "tất cả unhealthy" → số healthy bằng 0 → HealthyHostCount <= 0; "có ít nhất một hỏng" mới là ngưỡng >= 1 trên metric đếm lỗi.
• Đề thi rất hay dựng cặp phương án chỉ khác nhau chiều so sánh (<= và >=) trên cùng một metric. Đọc kỹ chiều so sánh trước khi chọn, vì chọn nhầm cho ra alarm kêu đúng lúc hệ thống khoẻ.
• Đặt ngưỡng 0 trên HealthyHostCount giữ được tính đúng khi Auto Scaling group thay đổi số instance, không phải chỉnh alarm mỗi lần quy mô đổi.

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

Đề mô tả một fleet EC2 nằm trong VPC, công ty muốn gỡ bỏ public IP của các instance để chúng không còn phơi ra Internet, nhưng vài ứng dụng vẫn cần truy cập được S3 bucket. Câu hỏi yêu cầu chọn HAI giải pháp.

Cụm từ quyết định là "remove their public IP addresses" kết hợp với "still require access to Amazon S3". Hai vế này đặt ra đúng một ràng buộc kỹ thuật: instance chỉ còn private IP, trong khi S3 là dịch vụ công cộng (public service) — endpoint của nó nằm ngoài VPC và được phân giải ra IP công cộng, chứ không phải một tài nguyên nằm trong subnet của bạn.

Vế thứ hai cũng đáng chú ý: đề nói "protect them from internet-based threats", tức là mối lo là kết nối đi vào từ Internet, chứ không cấm hoàn toàn kết nối đi ra. Đây là chỗ nhiều người loại nhầm NAT gateway. Instance không có public IP thì không ai từ Internet khởi tạo kết nối tới nó được — kể cả khi nó vẫn ra ngoài được qua NAT.

Vậy bài toán rút gọn thành: làm sao cho traffic từ private IP tới một public service đi được, và đó là câu hỏi về routing, không phải về security group hay Direct Connect.

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

Theo tệp, đáp án đúng là A và C — hai con đường hợp lệ cho traffic từ instance chỉ có private IP tới S3.

A — VPC endpoint + sửa route table. Với S3, đây là gateway endpoint. Nó hoạt động bằng cách thêm một prefix list của S3 vào route table của subnet, trỏ tới endpoint. Traffic tới S3 do đó không rời khỏi mạng AWS và đi hoàn toàn bằng địa chỉ nội bộ — instance không cần public IP, cũng không cần NAT gateway hay internet gateway. Chi tiết "configure the route tables appropriately" trong phương án chính là phần bắt buộc: tạo gateway endpoint mà quên gắn nó vào route table thì không có gì thay đổi cả.

C — NAT gateway ở public subnet + sửa route table. NAT gateway đặt trong public subnet, có elastic IP của riêng nó. Các private subnet trỏ default route qua NAT gateway; instance giữ nguyên private IP nhưng traffic đi ra được dịch địa chỉ nguồn sang IP của NAT gateway. NAT là một chiều: nó cho phép kết nối khởi tạo từ trong ra, và không cho phép chiều ngược lại. Nhờ vậy yêu cầu "gỡ public IP để tránh mối đe doạ từ Internet" vẫn được giữ, mà S3 vẫn gọi tới được.

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

B — Direct Connect + virtual interface giữa EC2 và S3. Đây là phương án gần đúng nhất về mặt "nghe có lý", vì Direct Connect có khái niệm public VIF dùng để tới các public service của AWS. Nhưng nó hỏng ở hai chỗ: Direct Connect là đường nối từ hạ tầng on-premises vào AWS, không phải đường nối giữa hai thứ vốn đã nằm sẵn trong AWS; và bạn không tạo được VIF giữa một VPC và một public service như cách phương án mô tả. Ở đây không có datacenter nào cả, EC2 và S3 đều ở trong AWS — dựng Direct Connect không giải quyết vấn đề routing nội bộ này.

D — Thêm outbound rule trong security group cho S3 bằng private IP. Sai vì nhầm vai trò của security group. Security group là bộ lọc cho phép hoặc chặn, nó không định tuyến và không quyết định traffic đi bằng địa chỉ nào. Bạn không thể "ép" traffic dùng private IP bằng một rule. Hơn nữa outbound của security group vốn mặc định đã mở — nếu đường đi không tồn tại thì mở thêm rule cũng chẳng có tác dụng gì.

E — Cấu hình internet gateway để định tuyến tới S3 bằng private IP. Sai ở cả hai vế. Internet gateway không phải thứ cấu hình được — nó không có bảng luật, bạn chỉ gắn nó vào VPC rồi trỏ route tới. Và bản thân ý tưởng "đi qua internet gateway bằng private IP" là mâu thuẫn: internet gateway cần instance có public IP hoặc elastic IP mới thực hiện dịch địa chỉ được, mà đề bài lại vừa gỡ đúng thứ đó đi. Cách duy nhất để tới S3 bằng địa chỉ nội bộ là VPC endpoint, tức phương án A.

📌 Điểm cần nhớ

• S3 là public service, không nằm trong VPC. Instance chỉ có private IP muốn tới S3 thì phải qua VPC endpoint (đi trong mạng AWS) hoặc NAT gateway (đi ra Internet nhưng dịch địa chỉ). Đó là hai lối đi kinh điển và thường xuất hiện cùng nhau trong câu chọn hai đáp án.
• Gateway endpoint cho S3 sống bằng route table. Phương án nào nhắc tới VPC endpoint mà kèm "configure the route tables" là dấu hiệu đúng; tạo endpoint mà không sửa route là chưa xong việc.
• Phân biệt rõ ba tầng: route table quyết định đi đường nào, security group / NACL quyết định được phép hay không, internet gateway và NAT gateway quyết định dịch địa chỉ ra sao. Phương án nào bắt security group làm việc định tuyến thì sai.
• "Gỡ public IP" không đồng nghĩa với "cấm ra Internet". NAT gateway vẫn hợp lệ vì nó chỉ cho kết nối khởi tạo từ trong ra, đúng tinh thần chống mối đe doạ đến từ phía Internet.
• Direct Connect là cầu nối on-premises ↔ AWS. Thấy nó trong một đề mà cả nguồn lẫn đích đều đã nằm trong AWS thì gần như chắc chắn là mồi nhử.