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

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

Đề mô tả ứng dụng chạy trên Amazon EC2 instances đứng sau một Elastic Load Balancer (ELB), và đội phát triển muốn phân tích lưu lượng mạng đi qua ELB.

Cụm từ quyết định đáp án nằm ở phần liệt kê chi tiết mà họ cần: "client's IP addresses, latencies, request paths, server responses". Bốn thứ này không đứng cùng cấp với nhau:

• Client IP address thì nhiều nguồn log đều có.
• Nhưng latencies (độ trễ xử lý), request paths (đường dẫn HTTP như /api/orders) và server responses (mã trạng thái HTTP mà backend trả về) là dữ liệu tầng ứng dụng (Layer 7) của từng request đi qua load balancer.

Hễ đề bài đòi tới mức đường dẫn URL và mã phản hồi HTTP, thì nguồn log phải là thứ chính load balancer ghi lại cho từng request nó xử lý, chứ không phải log tầng mạng hay log hoạt động quản trị.

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

Đáp án đúng theo tệp là B — Elastic Load Balancing Access Logs.

Elastic Load Balancing cung cấp access logs ghi lại thông tin chi tiết về các request gửi tới load balancer. Mỗi bản ghi chứa đúng những trường mà đề bài liệt kê: thời điểm nhận request, địa chỉ IP của client, latency, request path, và phản hồi của server. Đây chính là nguồn dữ liệu dùng để phân tích mẫu lưu lượng (traffic patterns) và gỡ lỗi ứng dụng.

Vài đặc điểm vận hành cần nhớ:

• Access logging là tính năng tuỳ chọn và mặc định bị tắt — phải bật lên mới có log. Đây là chi tiết hay bị hỏi ngược lại trong đề thi.
• Sau khi bật, ELB tự thu thập log và lưu vào Amazon S3 bucket do bạn chỉ định, dưới dạng file nén. Bạn có thể tắt lại bất cứ lúc nào.
• Bản thân access logs không tính phí thêm. Bạn chỉ trả tiền lưu trữ S3, còn băng thông ELB dùng để đẩy file log sang S3 thì không bị tính.

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

A — CloudTrail Logs. Đây là phương án gần đúng nhất về mặt "có tích hợp thật". Elastic Load Balancing có tích hợp với AWS CloudTrail, và CloudTrail có ghi lại các sự kiện liên quan tới ELB. Nhưng thứ nó ghi là các lời gọi API — hành động của user, role hay dịch vụ AWS tác động lên Elastic Load Balancing, dù từ Management Console hay từ code gọi vào ELB API. Nói cách khác, CloudTrail trả lời câu hỏi "ai đã tạo/sửa/xoá cái load balancer này", chứ không trả lời "những request nào đã đi qua load balancer này". Không có request path, không có latency của từng request người dùng cuối. Đây là nhầm lẫn kinh điển giữa control plane (quản trị tài nguyên) và data plane (lưu lượng thật).

C — VPC Flow Logs. Đây là phương án gần đúng thứ hai và cũng nguy hiểm nhất, vì nó thật sự dùng được cho load balancer: bạn có thể dùng VPC Flow Logs để nắm thông tin về lưu lượng đi vào và đi ra Network Load Balancer, bằng cách tạo flow log cho từng network interface của load balancer (mỗi subnet của load balancer có một network interface). Chỗ nó hỏng là mức chi tiết: VPC Flow Logs làm việc ở tầng mạng, ghi các cặp IP/port, protocol, số byte, số packet, accept/reject. Nó không cung cấp latency và server responses, cũng không thấy được request path — vì những thứ đó nằm trong nội dung HTTP mà flow log không đọc tới. Đề bài đòi đúng ba trường mà VPC Flow Logs không có, nên nó bị loại.

D — VPC Network Logs. Không tồn tại dịch vụ nào tên là VPC Network Logs. Đây là phương án bịa ra làm nhiễu, dựa vào việc nó nghe rất giống "VPC Flow Logs". Gặp một cái tên nghe hợp lý mà bạn chưa từng thấy trong tài liệu, khả năng cao đó là distractor.

📌 Điểm cần nhớ

• Phân biệt theo tầng dữ liệu: đề hỏi tới request path, HTTP status, latency → đó là Layer 7, phải dùng ELB Access Logs. Đề chỉ hỏi tới IP, port, protocol, byte, accept/reject → đó là Layer 3/4, dùng VPC Flow Logs.
• CloudTrail = ai làm gì với tài nguyên, không phải lưu lượng chạy qua tài nguyên. Hễ câu hỏi nói về traffic của người dùng cuối, CloudTrail gần như luôn sai.
• ELB Access Logs mặc định tắt, bật lên thì log được nén và đẩy vào S3 bucket bạn chỉ định; không mất phí cho bản thân log, chỉ mất phí lưu trữ S3.
• Cảnh giác với tên dịch vụ bịa nghe na ná tên thật (VPC Network Logs ↔ VPC Flow Logs) — loại ngay để thu hẹp lựa chọn.

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

Đề mô tả một chính sách bảo mật đòi end-to-end encryption xuyên suốt vòng đời workload: traffic không chỉ được mã hoá tới Application Load Balancer mà còn phải mã hoá tiếp từ load balancer xuống các EC2 instance phía sau. Đó là mô hình mà cả ALB lẫn EC2 instance đều cần một certificate để kết thúc/khởi tạo TLS.

Cụm từ quyết định nằm ở chỗ nhóm kỹ thuật muốn "use the same SSL certificate for the Application Load Balancer and the Amazon EC2 instances behind it", và câu hỏi chốt lại: cách đúng để cấu hình Amazon-issued certificate trên chính EC2 instance là gì. Trọng tâm không phải "làm sao mã hoá đầu-cuối", mà là certificate do AWS Certificate Manager cấp (Amazon-issued) có cài được lên EC2 instance hay không. Nắm được ràng buộc này thì ba phương án còn lại rụng ngay, vì cả ba đều giả định certificate của ACM có thể đưa xuống instance bằng cách này hay cách khác.

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

Đáp án đúng là A — "Amazon-issued certificates can't be installed on an EC2 instance. To enable end-to-end encryption, you must use a third-party SSL certificate".

Certificate do ACM tự cấp (Amazon-issued, public certificate) không cho phép xuất private key ra ngoài. Không có private key thì không có cách nào cài certificate đó lên web server chạy trên EC2 instance. ACM chỉ tích hợp certificate của nó với một tập dịch vụ được hỗ trợ — Elastic Load Balancing, Amazon CloudFront, AWS Elastic Beanstalk, AWS App Runner, Amazon API Gateway, AWS Nitro Enclaves và AWS CloudFormation — còn EC2 instance không nằm trong danh sách đó.

Vì vậy để đạt end-to-end encryption trong tình huống này, hướng đi đúng là mua/xin một third-party SSL certificate, cài nó lên các EC2 instance, rồi import chính certificate đó vào ACM để gán cho Application Load Balancer. Cách này thoả mãn đúng yêu cầu của đề: cùng một certificate dùng cho cả ALB lẫn instance, và cả hai chặng đều được mã hoá.

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

B — Use a self-signed certificate on Amazon EC2 instance to secure data. Đây là phương án gần đúng nhất về mặt kỹ thuật: self-signed certificate vẫn mã hoá được traffic, và trên chặng nội bộ ALB → EC2 nó thường được chấp nhận. Nhưng nó hỏng ở hai chỗ so với đề. Thứ nhất, đề đòi cùng một certificate cho ALB và EC2 — self-signed certificate trên instance là một certificate khác, không phải certificate của load balancer. Thứ hai, self-signed certificate không được trình duyệt tin cậy nên chỉ hợp cho môi trường thử nghiệm; đưa ra phục vụ người dùng thật là khách truy cập nhận cảnh báo bảo mật. Nó không phải câu trả lời cho "cách đúng để cấu hình Amazon-issued certificate".

C — Use AWS Certificate Manager service to expose the existing certificate of Load Balancer to Amazon EC2 instances. Phương án này bịa ra một tính năng không tồn tại. ACM không có cơ chế "expose" certificate đang gắn trên load balancer xuống EC2 instance, và như đã nêu, EC2 không nằm trong danh sách dịch vụ được ACM hỗ trợ tích hợp. Nghe hợp lý vì có nhắc đúng tên dịch vụ quản lý certificate, nhưng hành vi mô tả thì không có thật.

D — Import the Amazon-issued SSL certificate for the Load Balancer to the Amazon EC2 instances via the CLI. Đây là bẫy trực diện nhất: người học dễ nghĩ rằng cái gì làm được trên console mà bị chặn thì CLI sẽ làm được. Nhưng giới hạn ở đây không phải giới hạn giao diện — private key của Amazon-issued certificate vốn không xuất ra được, nên dù dùng CLI, SDK hay công cụ nào cũng không lấy được thứ cần thiết để cài lên instance. Lưu ý chiều import là ngược lại với thực tế: ta import certificate của bên thứ ba vào ACM, chứ không export certificate của ACM ra.

📌 Điểm cần nhớ

• Amazon-issued certificate của ACM không export private key được, nên không cài được lên EC2 instance — giới hạn này không phụ thuộc console hay CLI.
• ACM tích hợp certificate với một tập dịch vụ nhất định (ELB, CloudFront, Elastic Beanstalk, App Runner, API Gateway, Nitro Enclaves, CloudFormation); EC2 instance không thuộc tập đó.
• Muốn end-to-end encryption với cùng một certificate cho ALB và EC2: dùng third-party certificate, cài lên instance, rồi import vào ACM để gán cho load balancer — chiều đi là vào ACM, không phải ra khỏi ACM.
• Self-signed certificate mã hoá được nhưng không được tin cậy công khai, chỉ hợp môi trường thử nghiệm — và nó không thoả yêu cầu "cùng một certificate" khi đề nêu rõ ràng buộc đó.

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

Đề đặt bạn vào vai SysOps Administrator, cần tạo một custom rule trong AWS Config để kiểm tra xem các CloudTrail trail trong tài khoản có đang bật và ghi log cho toàn bộ region hay không.

Nội dung của phép kiểm tra không phải là điểm mấu chốt. Điểm quyết định nằm ở hai yêu cầu về thời điểm chạy đánh giá, được nêu tách rời thành hai câu liền nhau:

• "AWS Config should run the evaluations for the rule every time a trail is created" — chạy khi có thay đổi cấu hình tài nguyên.
• "Also, AWS Config should run the rule every 8 hours" — chạy định kỳ theo tần suất cố định.

Chữ "Also" là cụm phân biệt: nó nói rõ đây là hai yêu cầu cộng dồn, không phải chọn một. Thêm vào đó, từ "most optimal" loại bỏ những cách làm tuy đáp ứng đủ nhưng cồng kềnh hơn mức cần thiết.

Trong AWS Config, thời điểm chạy đánh giá gọi là trigger, và có hai loại: configuration change (chạy khi tài nguyên thuộc phạm vi được tạo, sửa, xoá) và periodic (chạy theo chu kỳ bạn chọn). Một custom rule được phép khai báo cả hai loại trigger cùng lúc.

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

B — Create the rule with configuration change and periodic triggers.

Khi cấu hình custom rule với cả hai loại trigger, AWS Config sẽ gọi hàm đánh giá của rule trong hai tình huống: mỗi lần phát hiện thay đổi cấu hình của loại tài nguyên nằm trong phạm vi rule (ở đây là việc tạo một CloudTrail trail), và theo đúng tần suất định kỳ mà bạn khai báo (8 giờ một lần).

Điều này khớp chính xác cả hai vế của đề, mà chỉ cần một rule duy nhất — một nơi định nghĩa logic, một nơi quản lý, một nơi xem kết quả đánh giá. Đó là lý do nó là phương án "most optimal".

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

A — Create the rule with configuration change Đáp ứng đúng vế thứ nhất: rule sẽ chạy mỗi khi một trail được tạo. Nhưng nó bỏ hẳn vế "every 8 hours". Nếu không ai đụng vào trail nào, rule sẽ không bao giờ chạy lại — trong khi mục đích của đánh giá định kỳ chính là bắt được trạng thái lệch chuẩn kể cả khi không có sự kiện thay đổi cấu hình nào. Thiếu một nửa yêu cầu.

D — Create the rule with periodic triggers Ngược lại với A: rule chạy đều đặn theo chu kỳ, nhưng không phản ứng tức thì khi trail được tạo. Đề nói rõ "every time a trail is created", tức là muốn đánh giá ngay tại thời điểm đó. Với trigger periodic, một trail mới tạo sai cấu hình có thể nằm im cho tới lần chạy định kỳ kế tiếp. Cũng thiếu một nửa yêu cầu.

C — Create two rules, one with configuration change and the other with periodic triggers Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Về mặt chức năng, hai rule tách rời có phủ được cả hai yêu cầu. Chỗ hỏng của nó không nằm ở chức năng mà nằm ở chữ "most optimal" trong đề: bạn phải duy trì hai rule chứa cùng một logic đánh giá, kết quả compliance bị chẻ làm hai chỗ, và mỗi lần sửa logic là phải sửa hai nơi — sai lệch giữa hai bản là chuyện sớm muộn. Vì AWS Config đã cho phép khai cả hai trigger trên một rule, việc tách đôi chỉ tạo thêm gánh nặng quản trị mà không đem lại gì thêm.

📌 Điểm cần nhớ

• AWS Config có hai loại trigger: configuration change (theo sự kiện tạo/sửa/xoá tài nguyên) và periodic (theo chu kỳ định sẵn). Một custom rule khai được cả hai cùng lúc — đây là điểm nhiều người tưởng nhầm là loại trừ nhau.
• Khi đề liệt kê yêu cầu bằng "Also", "and", "in addition" — đó là dấu hiệu cộng dồn, không phải chọn một. Phương án chỉ đáp ứng một vế là loại ngay.
• Cụm "most optimal" thường dùng để loại phương án đúng-về-chức-năng-nhưng-thừa. Gặp hai phương án cùng chạy được, chọn cái ít thành phần phải quản lý hơn.
• Trigger dạng sự kiện cho phản ứng tức thì nhưng im lặng khi không có thay đổi; trigger định kỳ bắt được drift nhưng có độ trễ. Kết hợp cả hai là cách phủ kín cả hai khoảng trống đó.

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

Đội kiểm thử không kết nối được tới dịch vụ đang chạy trên một EC2 instance. Đề bài đã chốt sẵn hai điều kiện để loại bớt nghi ngờ: "Inbound traffic to the necessary ports is configured for the Security Group as well as the Network ACL" — nghĩa là chiều vào đã mở ở cả hai lớp lọc.

Cụm từ quyết định chính là chỗ đó: cả Security Group lẫn Network ACL đều đã cho phép inbound đúng cổng dịch vụ, mà kết nối vẫn hỏng. Khi chiều vào đã đúng thì phần còn lại chỉ có thể là chiều ra, và câu hỏi trở thành: trong hai lớp lọc này, lớp nào không tự nhớ kết nối đã cho vào để mở đường cho gói tin trả về?

Chi tiết thứ hai cũng đáng chú ý: đề không hề nhắc tới Internet hay truy cập từ bên ngoài VPC. Đó là ràng buộc loại thẳng phương án nói về Internet Gateway.

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

Đáp án đúng là B — Network ACLs are stateless, so you must allow both inbound and outbound traffic. Enable outbound traffic to fix the connectivity issue.

Điểm mấu chốt là sự khác biệt stateful và stateless giữa hai lớp lọc trong VPC:

• Security Group là stateful: đã cho một kết nối đi vào thì lưu lượng trả về của chính kết nối đó được phép đi ra, bất kể rule outbound viết thế nào. Vì vậy chỉ cần mở inbound đúng cổng là xong — đúng như đề bài đã làm.
• Network ACL là stateless: nó xét từng gói tin một cách độc lập, không nhớ gì về kết nối trước đó. Gói tin vào được duyệt theo rule inbound, còn gói tin trả về phải được duyệt lại theo rule outbound.

Muốn kết nối tới một dịch vụ trên instance hoạt động, Network ACL phải cho phép đủ hai chiều:

1. Inbound trên cổng mà dịch vụ đang lắng nghe.
2. Outbound tới dải ephemeral port.

Lý do có yêu cầu thứ hai: khi client mở kết nối tới server, hệ điều hành của client chọn một cổng ngẫu nhiên trong dải ephemeral (1024–65535) làm source port. Khi server trả lời, chính cổng ngẫu nhiên đó trở thành destination port của lưu lượng đi ra. Nếu Network ACL không mở outbound tới dải ephemeral, phản hồi bị chặn ngay tại biên subnet — client thấy y hệt như "không kết nối được", dù dịch vụ vẫn chạy bình thường và inbound đã mở đúng.

Mặc định, Network ACL cho phép toàn bộ lưu lượng cả hai chiều. Nhưng nếu ACL đã được siết chặt hơn mặc định, thì phải khai báo tường minh rule cho dải ephemeral port. Đây chính là kịch bản mà câu hỏi mô tả.

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

D — "Security Groups are stateless, so you must allow both inbound and outbound traffic." Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: nó có cấu trúc câu giống hệt đáp án đúng, chỉ đổi tên đối tượng. Nhưng phát biểu này sai về bản chất: Security Group là stateful, không phải stateless. Vì vậy việc chỉ mở inbound đúng cổng đã đủ để lưu lượng trả về đi ra được, và "enable outbound traffic" trên Security Group không sửa được gì cả. Người học đọc lướt rất dễ nhầm hai phương án B và D — điểm phân biệt duy nhất nằm ở việc nhớ đúng lớp nào stateful, lớp nào stateless.

A — "Internet Gateway should be configured to access Amazon EC2 instance from the internet." Đúng là nếu muốn nhận lưu lượng từ Internet thì phải có route đi qua Internet Gateway. Nhưng đề bài không nói gì về việc truy cập qua Internet — chỉ nói một đội kiểm thử không kết nối được. Phương án này thêm một giả định không có trong đề, và nếu đội kiểm thử vốn nằm trong cùng VPC thì Internet Gateway hoàn toàn không liên quan. Đây là lỗi "sửa một vấn đề khác với vấn đề được hỏi".

C — "Use multiple Availability Zone deployments so you have high availability." Triển khai nhiều Availability Zone đúng là khuyến nghị của AWS, nhưng nó giải quyết bài toán khả dụng cao, không liên quan gì tới việc gói tin bị lọc. Khả năng kết nối tới dịch vụ trên EC2 instance phải hoạt động bất kể chọn kiểu triển khai nào; thêm AZ không mở thêm rule nào trên Network ACL cả. Phương án này là câu trả lời đúng về mặt best practice nhưng lạc đề hoàn toàn.

📌 Điểm cần nhớ

• Security Group là stateful, Network ACL là stateless. Đây là khác biệt bị hỏi đi hỏi lại; ghi nhớ nó giải quyết được phần lớn câu hỏi về lọc lưu lượng trong VPC.
• Triệu chứng kinh điển của ACL thiếu rule outbound: inbound đã mở đúng cổng mà vẫn không kết nối được. Khi gặp mô tả này, nghĩ ngay tới dải ephemeral port (1024–65535) ở chiều ra của Network ACL.
• Với Network ACL, luôn kiểm cả hai chiều cho mỗi luồng: chiều vào theo cổng dịch vụ, chiều ra theo ephemeral port của client. Với Security Group thì chỉ cần lo chiều khởi tạo kết nối.
• Network ACL mặc định mở hết cả hai chiều — nên sự cố kiểu này gần như luôn xuất hiện sau khi ai đó siết ACL chặt hơn mặc định mà quên rule ephemeral port.
• Đọc kỹ phạm vi đề: đề không nhắc tới Internet thì đừng chọn phương án về Internet Gateway; đề hỏi về lỗi kết nối thì đừng chọn phương án về high availability, dù nó đúng như một best practice.

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

Đề mô tả một startup chuyển hạ tầng lên AWS Cloud và hỏi bạn — với vai trò SysOps Administrator — về cơ chế cấp phát địa chỉ IP cho EC2 instance trong một Amazon VPC. Yêu cầu là chọn ba phát biểu đúng (Select three).

Cụm từ quyết định nằm ở chính chủ đề: đây là câu về public IPv4 address — loại địa chỉ do AWS cấp từ pool công cộng của Amazon — chứ không phải về Elastic IP address, là địa chỉ thuộc về tài khoản AWS của bạn. Toàn bộ sáu phương án đều xoay quanh đúng một ranh giới đó: cái gì bạn điều khiển được (Elastic IP) và cái gì AWS tự quản lý (public IP). Thêm một chi tiết phân biệt nữa: default VPC so với non-default VPC — hai môi trường này có hành vi gán public IP mặc định khác nhau.

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

Theo tệp, đáp án đúng là A, B, C.

A — EC2 và VPC mặc định dùng IPv4, không tắt được. Amazon EC2 và Amazon VPC hỗ trợ cả IPv4 lẫn IPv6, nhưng IPv4 là bắt buộc: khi tạo VPC bạn phải khai một IPv4 CIDR block. IPv6 chỉ là tuỳ chọn thêm — bạn có thể gán IPv6 CIDR block cho VPC và subnet rồi cấp IPv6 cho instance, nhưng không có cách nào bỏ hẳn IPv4.

B — Public IP đã bị thu hồi sẽ không được cấp lại nếu instance có nhiều hơn một network interface. Cơ chế tự động cấp public IP chỉ hoạt động trong trường hợp đơn giản: instance có đúng một network interface. Khi có nhiều ENI gắn vào, AWS không tự cấp public IP mới. Tương tự, nếu instance có secondary private IP đang được liên kết với một Elastic IP, nó cũng không nhận public IP mới.

C — Không thể tự tay associate/disassociate public IP. Public IP được cấp cho instance từ pool IPv4 công cộng của Amazon và không thuộc về tài khoản AWS của bạn. Vì không sở hữu nó, bạn không có thao tác gắn vào hay gỡ ra thủ công. Muốn kiểm soát địa chỉ theo ý mình thì đó chính là lý do Elastic IP tồn tại.

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

D — "Instance có thể có đồng thời cả public IP và Elastic IP". Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì nghe hợp lý theo kiểu "nhiều địa chỉ thì càng tốt". Nhưng hai loại địa chỉ này loại trừ nhau trên cùng một interface: khi bạn associate một Elastic IP vào instance, AWS thu hồi luôn public IP đang có. Khi bạn disassociate Elastic IP đó, instance mới nhận lại một public IP mới. Tại một thời điểm chỉ có một trong hai.

E — "Mặc định AWS gán public IP cho instance ở cả default và non-default VPC". Vế đầu đúng, vế sau sai — và cái sai nằm đúng ở chỗ đề muốn kiểm tra. Trong default VPC, instance được gán public IP mặc định. Trong non-default VPC, việc có nhận public IP hay không do một thuộc tính của subnet quyết định, và mặc định thuộc tính đó là không gán. Vì phương án gộp cả hai trường hợp vào một khẳng định nên nó sai.

F — "AWS thu hồi public IP khi stop hoặc terminate, nhưng giữ lại nếu hibernate". Vế ngoại lệ về hibernate là bịa. AWS thu hồi public IP khi instance bị stopped, hibernated, hoặc terminated — hibernate không được ưu ái gì cả. Instance đã stop hoặc hibernate khi khởi động lại sẽ nhận một public IP mới, khác địa chỉ cũ.

📌 Điểm cần nhớ

• Public IP là của Amazon, Elastic IP là của bạn. Mọi phát biểu kiểu "tự gắn/gỡ public IP" đều sai; mọi nhu cầu cần địa chỉ cố định, kiểm soát được đều dẫn về Elastic IP.
• Public IP và Elastic IP không cùng tồn tại trên một interface: associate EIP thì public IP bị thu hồi, disassociate thì nhận public IP mới.
• Default VPC gán public IP mặc định, non-default VPC thì không — quyết định nằm ở thuộc tính của subnet. Thấy phương án gộp chung hai loại VPC là dấu hiệu sai.
• Stop, hibernate và terminate đều làm mất public IP. Đừng tin các phương án dựng ra "ngoại lệ" cho hibernate hay cho một trạng thái riêng lẻ nào.
• Việc tự động cấp public IP chỉ áp dụng cho instance có một network interface duy nhất; nhiều ENI, hoặc secondary private IP đã gắn Elastic IP, đều làm mất cơ chế này.

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

Đề đặt bối cảnh một SysOps Administrator quản lý nhiều IAM user nằm rải rác trên nhiều AWS account, và muốn gom chúng vào IAM Group để quản trị permission cho gọn. Nhưng bối cảnh đó chỉ là lớp vỏ — câu hỏi thật nằm ở dòng cuối: "Which of the following statements are valid about IAM Groups? (Select two)".

Cụm từ quyết định là "valid about IAM Groups" cộng với "(Select two)". Đây không phải câu tình huống cần chọn kiến trúc, mà là câu kiểm tra định nghĩa: bạn phải biết chính xác IAM Group là gì và không phải là gì. Toàn bộ năm phương án xoay quanh đúng ba tính chất của IAM Group:

1. Group có credential riêng để tự gọi web service không?
2. Group có thể gắn permission bằng policy không?
3. Group có lồng vào nhau (nested group) được không?

Cứ trả lời rành mạch ba câu này là loại được ba phương án sai ngay lập tức.

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

C — "Groups can be granted permissions using access control policies"

Đây chính là lý do IAM Group tồn tại. Bạn gắn policy vào group, mọi user là thành viên của group đó thừa hưởng permission trong policy. Nhờ vậy khi cần đổi quyền cho cả một nhóm người, bạn sửa một policy ở một chỗ thay vì phải sửa từng IAM user một. Đúng với nhu cầu mà đề bài mô tả: đội ngũ phình to, quản permission theo từng user không còn khả thi.

D — "An IAM user can belong to multiple IAM groups. But, Groups cannot belong to other groups"

Phương án này gộp hai sự thật, và cả hai đều đúng. Một IAM user có thể đồng thời là thành viên của nhiều group (ví dụ vừa thuộc group Developers vừa thuộc group OnCall), khi đó quyền của user là hợp của các policy áp lên. Vế thứ hai: IAM Group không lồng được — một group chỉ chứa user, không chứa group khác. Đây là điểm AWS nói rõ trong tài liệu IAM và cũng là chi tiết kỳ thi hay hỏi đi hỏi lại.

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

A — "Groups can be given security credentials to be able to access web services directly"

Sai ở chỗ căn bản nhất: IAM Group không có security credential. Nó không có access key, không có secret key, không có password. Group không phải là một identity có thể xác thực và gọi API; nó thuần tuý là một cái nhãn để gom user lại cho dễ gắn policy. Chỉ IAM user (và role, thông qua temporary credentials) mới truy cập được service.

B — "Groups cannot be given security credentials directly, however, these can take up an IAM Role to access web services directly"

Đây là phương án gần đúng nhất, và cũng là cái bẫy chính của câu. Nửa đầu hoàn toàn chính xác — group đúng là không có credential trực tiếp. Nhưng nửa sau thì hỏng: bạn không thể cho một IAM Group assume một IAM Role. Role được assume bởi một principal — IAM user, một service như EC2/Lambda, hay một identity liên kết — chứ group không nằm trong danh sách đó. Group không phải principal nên nó không thể là chủ thể của hành động sts:AssumeRole. Đọc lướt thấy nửa đầu đúng là rất dễ chọn nhầm.

E — "An IAM user can belong to multiple IAM groups and an IAM group can be part of another IAM group"

Đây là phương án D bị bẻ ngược ở vế sau. Vế đầu ("user thuộc nhiều group") đúng, nhưng vế sau khẳng định group lồng được vào group — sai. IAM không hỗ trợ nested group. D và E cố ý được viết gần như y hệt nhau để buộc bạn phải đọc kỹ đúng mệnh đề cuối; chọn E là hiểu ngược hẳn tính chất quan trọng nhất mà câu hỏi đang kiểm tra.

📌 Điểm cần nhớ

• IAM Group không phải là identity. Nó không có credential, không tự gọi được web service, và không assume role được. Gặp phương án nào gán cho group khả năng "tự truy cập" hay "nhận role" thì loại ngay.
• Group không lồng nhau. Một group chỉ chứa user. Ngược lại, một user thì thuộc được nhiều group cùng lúc và nhận hợp các quyền.
• Công dụng duy nhất của group là gắn policy cho một tập user. Đó là toàn bộ giá trị của nó — quản permission theo nhóm thay vì theo từng người.
• Với câu "Select two" mà các phương án viết gần giống nhau, hãy so từng mệnh đề trong phương án. Kiểu bẫy hay gặp là một phương án đúng nửa đầu rồi sai ở vế sau (như B và E ở đây) — một mệnh đề sai là cả phương án sai.

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

Đề mô tả một tình huống rất cụ thể: đã mở port 80 inbound ở cả Network ACL lẫn Security Group cho load balancer và các EC2 instance, nhưng người dùng vẫn không vào được website.

Cụm từ quyết định nằm ở chỗ đề nói load balancer đứng trước các instance, và chỉ mới cấu hình inbound. Đây là câu kiểm tra một điểm duy nhất: Network ACL là stateless, còn Security Group là stateful. Với NACL, chiều đi ra của gói phản hồi không được tự động cho phép chỉ vì chiều đi vào đã cho phép — phải có rule outbound riêng. Và vì phía khởi tạo kết nối chọn ephemeral port, rule outbound phải phủ đúng dải ephemeral port của bên gửi request. Đề nêu rõ traffic đi qua Elastic Load Balancing, nên dải cần mở là dải mà ELB dùng, chứ không phải dải của một hệ điều hành cụ thể.

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

D — Add a rule to the Network ACLs to allow outbound traffic on ports 1024 - 65535.

Network ACL là lớp firewall tuỳ chọn ở mức subnet, có rule inbound và outbound tách biệt, và stateless: phản hồi cho traffic inbound được phép vẫn phải qua rule outbound (và ngược lại). Custom NACL mới tạo mặc định từ chối toàn bộ cả hai chiều cho đến khi bạn thêm rule.

Khi client mở kết nối HTTP tới port 80, gói trả về đi ngược lại tới ephemeral port mà bên khởi tạo đã chọn. Trong kiến trúc của đề, request đến instance xuất phát từ Elastic Load Balancing, và ELB dùng dải ephemeral 1024–65535. Mở outbound đúng dải này trên NACL thì phản hồi mới rời được subnet, và website mới truy cập được. Đây chính là mảnh còn thiếu so với những gì đề đã cấu hình.

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

A — Add a rule to the Security Group allowing outbound traffic on port 80. Sai vì nhầm bản chất của Security Group. SG hoạt động ở mức instance và là stateful: đã cho phép inbound trên port 80 thì traffic phản hồi tự động được đi ra, bất kể rule outbound. Thêm rule outbound ở SG không sửa được gì cả — vấn đề nằm ở tầng NACL, không phải tầng SG. Hơn nữa phản hồi cũng không đi ra trên port 80 mà đi về ephemeral port của bên gọi.

B — Outbound ports 32768 - 61000. Đây là phương án gần đúng nhất và là bẫy chính. Dải này có thật — nhiều nhân Linux, gồm cả Amazon Linux kernel, dùng đúng 32768–61000 làm ephemeral port. Nếu client kết nối thẳng tới instance từ một máy Linux thì nó hợp lý. Nhưng trong đề, bên khởi tạo kết nối tới instance là ELB, và ELB dùng 1024–65535. Chọn B là mở đúng dải nhưng cho sai bên khởi tạo, nên phần lớn phản hồi vẫn bị NACL chặn.

C — Outbound ports 1025 - 5000. Cũng là một dải có thật: các hệ điều hành Windows tới Windows Server 2003 dùng 1025–5000. Ngoài chuyện lại đoán theo hệ điều hành client thay vì theo ELB, dải này còn hẹp hơn hẳn — nó không phủ nổi 1024–65535 mà ELB cần. Từ Windows Server 2008 trở đi Microsoft đã chuyển sang dải khác, nên đây gần như là lựa chọn lỗi thời ở mọi góc nhìn.

📌 Điểm cần nhớ

• Security Group stateful, Network ACL stateless. Đây là câu hỏi kiểm tra sự khác biệt đó. Triệu chứng kinh điển: inbound đã mở đủ mà kết nối vẫn không thành → nghi ngay rule outbound của NACL.
• Custom NACL mặc định deny cả hai chiều; NACL mặc định của VPC thì cho phép hết. Tự tạo NACL mà quên rule outbound là lỗi rất hay gặp.
• Ephemeral port do bên khởi tạo kết nối chọn, nên phải hỏi "ai gọi ai" trước khi chọn dải: ELB và NAT gateway dùng 1024–65535; nhiều nhân Linux dùng 32768–61000; Windows tới Server 2003 dùng 1025–5000; Windows Server 2008 trở lên dùng 49152–65535.
• Khi đề nhắc tới load balancer đứng trước instance, dải ephemeral cần mở trên NACL của subnet chứa instance là dải của ELB, không phải của hệ điều hành người dùng cuối.

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

Đề bài hỏi: theo shared responsibility model, trong Amazon S3 thì bạn KHÔNG chịu trách nhiệm về thứ gì.

Cụm từ quyết định đáp án là chữ "NOT responsible for" — đây là câu hỏi phủ định. Ba trong bốn phương án là những thứ khách hàng phải tự bật, tự cấu hình; chỉ một phương án là thứ AWS lo phần lõi. Đọc lướt qua chữ "NOT" là chọn ngay một phương án nghe có vẻ "AWS-ish" nhất và trượt.

Ràng buộc thứ hai, tinh tế hơn: model này chia đôi theo ranh giới "security OF the cloud" (AWS lo) và "security IN the cloud" (khách hàng lo). Với một dịch vụ quản lý (managed service) như S3, AWS chịu trách nhiệm về hạ tầng, phần mềm của dịch vụ, lớp ảo hoá và an ninh vật lý; còn khách hàng chịu trách nhiệm về cấu hình mình đặt ra trên dịch vụ đó. Vậy câu hỏi thực chất là: trong bốn thứ được liệt kê, cái nào thuộc phần cài đặt của dịch vụ chứ không phải lựa chọn cấu hình của người dùng.

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

D — S3 Server Side encryption.

Server-side encryption là phần AWS thực hiện thay bạn: dữ liệu được mã hoá khi ghi xuống đĩa và giải mã khi đọc ra, do chính S3 làm ở phía máy chủ. Bạn không viết mã mã hoá, không quản lý thư viện crypto, không lo việc dữ liệu nằm trên đĩa vật lý được bảo vệ ra sao — toàn bộ cơ chế đó nằm bên trong dịch vụ do AWS vận hành và bảo trì.

Đây chính là ý mà phần giải thích gốc nhấn mạnh: AWS operates, manages, and controls các thành phần từ host operating system và lớp virtualization xuống tới an ninh vật lý của trung tâm dữ liệu. Trong nhóm shared controls — ví dụ Configuration Management — AWS lo cấu hình thiết bị hạ tầng, còn khách hàng lo cấu hình guest OS, database và ứng dụng của mình. Với tình huống đã cho, phần quản lý server-side encryption của S3 thuộc về AWS.

Nói cách khác: bạn có thể chọn bật server-side encryption, nhưng bản thân việc mã hoá được thực thi và bảo vệ đúng cách là trách nhiệm của AWS — không phải việc bạn phải tự cài đặt và duy trì.

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

A — S3 versioning. Sai, vì versioning là lựa chọn của khách hàng. Bucket mặc định không bật versioning; bạn quyết định có bật hay không, và bạn cũng là người gánh hậu quả: nếu không bật mà object bị ghi đè hay xoá nhầm thì không có bản cũ để lấy lại. AWS chỉ cung cấp sẵn khả năng đó, việc dùng hay không là ở bạn. Đây là "security in the cloud".

B — S3 ACLs. Sai, và đây là phương án dễ nhầm nhất với D vì nghe cũng rất "bảo mật". Nhưng ACL là cơ chế phân quyền do bạn thiết lập — bạn là người quyết định object hay bucket được cấp quyền đọc/ghi cho ai. Một ACL cấu hình lỏng lẻo làm lộ dữ liệu ra ngoài là lỗi của khách hàng, không phải lỗi của AWS. AWS đưa ra công cụ; nội dung của quy tắc là do bạn viết.

C — S3 bucket policies. Sai, cùng lý do với B nhưng ở phạm vi bucket. Bucket policy là tài liệu chính sách bạn soạn ra để cho phép hay từ chối truy cập. AWS đảm bảo engine đánh giá chính sách hoạt động đúng như đã định nghĩa; còn việc chính sách đó có mở toang bucket ra Internet hay không thì hoàn toàn nằm trong tay bạn.

Điểm chung của A, B, C: cả ba đều là cấu hình — thứ bạn bật/tắt hoặc viết ra. Phần giải thích gốc gộp cả ba lại trong một câu: đây là trách nhiệm của khách hàng.

📌 Điểm cần nhớ

• Nguyên tắc phân định: AWS lo "security OF the cloud" (hạ tầng, host OS, virtualization, an ninh vật lý, phần lõi của dịch vụ), khách hàng lo "security IN the cloud" (cấu hình, phân quyền, dữ liệu đưa vào).
• Với S3, mọi thứ có dạng "bạn phải bật/bạn phải viết ra" — versioning, ACL, bucket policy — đều thuộc phía khách hàng. Cơ chế do dịch vụ tự thực thi bên trong, như server-side encryption, thuộc phía AWS.
• Đọc kỹ chữ NOT trong đề. Câu hỏi phủ định về shared responsibility model rất hay xuất hiện, và cách chắc ăn là phân loại từng phương án thành "AWS lo" / "khách hàng lo" rồi mới chọn, thay vì tìm phương án nghe hợp lý nhất.
• Shared controls là vùng xám cần nhớ riêng: cùng một hạng mục (ví dụ Configuration Management) nhưng ở hai ngữ cảnh khác nhau — AWS cấu hình thiết bị hạ tầng, khách hàng cấu hình guest OS, database và ứng dụng của mình.

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

Đề mô tả một workload throughput intensive (nặng về băng thông đọc/ghi tuần tự) và yêu cầu một volume low-cost gắn được vào EC2 instance. Cả bốn phương án đều là EBS, nên câu hỏi thực chất là: chọn loại EBS volume nào.

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

• "throughput intensive" — hiệu năng đo bằng MB/s chứ không phải IOPS. Cụm này loại ngay nhóm SSD, vì SSD (gp2, io1) sinh ra cho workload giao dịch, đo bằng IOPS và độ trễ thấp.
• "low-cost" — trong nhóm HDD còn lại, phải cân giữa st1 và sc1.

Và một cụm ẩn nhưng quan trọng: workload throughput intensive kiểu MapReduce, log processing, ETL là dữ liệu được truy cập thường xuyên — đây chính là điểm tách st1 khỏi sc1.

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

A. EBS HDD volume - st1 (Throughput Optimized HDD) là loại volume HDD dành đúng cho dữ liệu truy cập thường xuyên, dataset lớn, kích thước I/O lớn — các ca điển hình AWS liệt kê là MapReduce, Kafka, log processing, data warehouse và ETL. Hiệu năng của nó được công bố theo MB/s, có baseline throughput theo dung lượng volume và khả năng burst lên cao hơn, đúng với thứ workload này cần.

Về giá, st1 nằm ở nhóm HDD nên rẻ hơn đáng kể so với các volume SSD như gp2 hay io1 tính trên mỗi GB-tháng. Vì vậy st1 thoả cả hai ràng buộc cùng lúc: throughput cao và chi phí thấp.

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

B. EBS HDD volume - sc1 (Cold HDD) — đây là phương án gần đúng nhất và là cái bẫy chính. Nó cũng là HDD, cũng đo hiệu năng theo MB/s, và thậm chí còn rẻ hơn st1 trên mỗi GB. Nhưng sc1 được thiết kế cho dữ liệu ít được truy cập (cold data), với baseline và burst throughput thấp hơn st1 rõ rệt. Workload trong đề là throughput intensive với dữ liệu truy cập thường xuyên, nên sc1 sẽ không đáp ứng nổi mức băng thông cần thiết. Rẻ nhất không đồng nghĩa đúng nhất — yêu cầu "low-cost" chỉ có hiệu lực trong phạm vi những lựa chọn đáp ứng được nhu cầu hiệu năng.

C. EBS SSD volume - io1 (Provisioned IOPS SSD) — sai ở cả hai vế. io1 được thiết kế để đạt độ trễ ở mức mili-giây một chữ số và cung cấp mức IOPS đã provisioned một cách ổn định; đề bài không hề nhắc tới yêu cầu độ trễ hay IOPS. Ngoài ra io1 là loại EBS đắt nhất trong bốn phương án, đi ngược hẳn ràng buộc "low-cost". Chọn io1 là trả tiền cho một đặc tính workload không cần.

D. EBS SSD volume - gp2 (General Purpose SSD) — gp2 là volume đa dụng cho workload giao dịch, virtual desktop, database cỡ vừa một instance, ứng dụng tương tác nhạy cảm độ trễ và boot volume. Nó chạy được nhưng không tối ưu: hiệu năng của gp2 được định nghĩa quanh IOPS chứ không phải throughput, và giá mỗi GB-tháng của gp2 cao hơn st1 khá nhiều. Với dataset lớn của workload throughput intensive, chênh lệch đơn giá đó nhân lên thành khoản tiền lớn mà không đổi lại lợi ích gì. Đây là lựa chọn "an toàn nhưng lãng phí".

📌 Điểm cần nhớ

• Từ khoá phân nhóm EBS: thấy "throughput", "MB/s", "MapReduce", "log processing", "ETL", "data warehouse" → nhóm HDD (st1, sc1). Thấy "IOPS", "latency", "transactional", "database", "boot volume" → nhóm SSD (gp2/gp3, io1/io2).
• st1 vs sc1 tách nhau ở tần suất truy cập, không phải ở giá: dữ liệu truy cập thường xuyên → st1; dữ liệu cold, ít đụng tới → sc1. sc1 là loại rẻ nhất mỗi GB trong các loại EBS, nên nó luôn là mồi nhử cho câu hỏi có chữ "low-cost".
• "Low-cost" trong đề thi luôn là ràng buộc thứ cấp: trước hết lọc những phương án đáp ứng được yêu cầu kỹ thuật, rồi mới chọn cái rẻ nhất trong số đó. Chọn thẳng cái rẻ nhất là cách sai điển hình.
• io1 chỉ đúng khi đề nói rõ về IOPS cao hoặc độ trễ mili-giây một chữ số. Không có tín hiệu đó mà chọn io1 là vừa sai kỹ thuật vừa sai chi phí.

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

Đề mô tả AWS Secrets Manager có khả năng tự động xoay vòng (rotate) bí mật theo lịch, rồi hỏi: Secrets Manager có built-in rotation support cho những dịch vụ nào?

Cụm từ quyết định là "built-in rotation support" — hỗ trợ xoay vòng dựng sẵn. Đây là điểm phân biệt duy nhất giữa bốn phương án, bởi vì cả bốn dịch vụ được nhắc tới (CloudFormation, ECS, EMR, RDS, Redshift, DocumentDB) đều có tích hợp với Secrets Manager theo cách nào đó. Đề không hỏi "dịch vụ nào tích hợp với Secrets Manager", mà hỏi hẹp hơn: dịch vụ nào Secrets Manager có sẵn Lambda rotation function để tự thay credential ở cả hai đầu — trong secret và trong chính dịch vụ đó.

Từ đó suy ra một tiêu chí lọc rất gọn: chỉ những dịch vụ có credential đăng nhập kiểu database/cluster mới nằm trong danh sách rotation dựng sẵn. Dịch vụ nào chỉ đọc secret (CloudFormation, ECS) hoặc chỉ lưu nhờ secret (EMR) thì không thuộc nhóm này.

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

Đáp án đúng theo tệp là B — Amazon RDS databases, Amazon Redshift clusters.

Secrets Manager có built-in rotation cho ba nhóm: Amazon RDS databases, Amazon DocumentDB databases và Amazon Redshift clusters. Phương án B nêu hai trong ba nhóm đó, và cả hai đều nằm trong danh sách — nên B đúng hoàn toàn.

Cơ chế: khi tới hạn xoay vòng, Secrets Manager gọi một Lambda rotation function. Hàm này vừa nói chuyện với Secrets Manager vừa nói chuyện với database/cluster, sinh credential mới, ghi credential mới vào database và cập nhật luôn giá trị trong secret. Nhờ vậy người vận hành không phải đổi mật khẩu bằng tay, và ứng dụng đang đọc secret vẫn lấy được credential còn hiệu lực. Chính vì cần "ghi credential mới vào dịch vụ", built-in rotation chỉ có nghĩa với những dịch vụ quản lý người dùng và mật khẩu của riêng nó — đúng đặc điểm của RDS, Redshift và DocumentDB.

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

• A — AWS CloudFormation, Amazon RDS databases: nửa sau đúng (RDS có built-in rotation), nhưng nửa đầu hỏng. CloudFormation có tích hợp Secrets Manager: bạn tạo secret trong template rồi tham chiếu nó ở phần khác của cùng stack. Nhưng đó là tạo và tham chiếu secret, không phải xoay vòng — CloudFormation không có tài khoản đăng nhập để Secrets Manager đổi mật khẩu vào. Đây là phương án bẫy điển hình: đúng một nửa nên trông rất thuyết phục nếu chỉ nhìn thấy chữ "RDS".

• C — Amazon ECS, Amazon DocumentDB databases: cũng đúng một nửa. DocumentDB thật sự nằm trong danh sách built-in rotation, nhưng ECS thì không. ECS tích hợp Secrets Manager theo hướng tiêu thụ: bạn tham chiếu secret trong container definition, và dữ liệu nhạy cảm được đưa vào container dưới dạng biến môi trường hoặc trong cấu hình log. ECS chỉ đọc giá trị, không sở hữu credential nào để Secrets Manager xoay vòng.

• D — Amazon EMR, Amazon Redshift clusters: lặp lại đúng khuôn bẫy đó. Redshift nằm trong danh sách, EMR thì không. EMR là nền tảng cluster quản lý cho Hadoop/Spark; nó tích hợp Secrets Manager ở chỗ bạn có thể lưu credential của private Git-based registry trong Secrets Manager rồi cho EMR dùng. Lại là quan hệ đọc secret, không phải rotation dựng sẵn.

Tóm lại, cả A, C và D đều ghép một dịch vụ đúng với một dịch vụ chỉ tích hợp mà không được rotation. CloudFormation, ECS và EMR đều không thuộc nhóm built-in rotation, nên ba phương án này sai.

📌 Điểm cần nhớ

• Built-in rotation của Secrets Manager áp dụng cho ba nhóm: RDS, Redshift, DocumentDB — đều là dịch vụ có credential đăng nhập do chính nó quản lý. Nhớ đúng bộ ba này là giải được mọi biến thể của câu hỏi.
• Phân biệt rõ hai mức quan hệ: "tích hợp với Secrets Manager" (rất nhiều dịch vụ, gồm CloudFormation, ECS, EMR — chủ yếu là đọc/tham chiếu secret) và "được Secrets Manager xoay vòng sẵn" (danh sách hẹp). Đề thi rất hay đánh vào chỗ lẫn lộn này.
• Với dịch vụ không nằm trong danh sách, vẫn xoay vòng được nhưng phải tự viết Lambda rotation function — "không có built-in" khác với "không xoay vòng được".
• Chiến thuật làm bài: khi phương án là cặp dịch vụ, kiểm tra từng vế một; chỉ cần một vế sai là loại cả phương án. Ở câu này ba phương án sai đều có một vế đúng để dụ người đọc lướt.