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

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

Đề mô tả một cuộc tấn công nhắm vào web application chạy trên Amazon EC2, và điểm mấu chốt nằm ở cách tấn công: "malformed HTTP headers" — header HTTP dị dạng, không đúng đặc tả HTTP. Câu hỏi yêu cầu tìm dịch vụ hoặc tính năng AWS ngăn loại tấn công này chạm tới EC2 instance.

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

• "malformed HTTP headers" — đây là vấn đề ở tầng ứng dụng (Layer 7). Muốn phát hiện một header sai đặc tả thì phải đọc và phân tích được nội dung HTTP, chứ không chỉ nhìn IP, port hay protocol.
• "running on Amazon EC2" — thứ cần bảo vệ là EC2 instance trực tiếp, không phải CloudFront hay API Gateway. Ràng buộc này chính là thứ loại bỏ phương án WAF, và đây là chỗ đa số người học chọn nhầm.

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

C — Application Load Balancer (ALB) là đáp án đúng.

ALB là load balancer hoạt động ở Layer 7: nó terminate kết nối HTTP/HTTPS và tự phân tích request trước khi chuyển tiếp xuống target. Vì phải hiểu request mới định tuyến được, ALB bắt buộc kiểm tra request có đúng đặc tả HTTP hay không. Request có header dị dạng sẽ bị ALB từ chối ngay bằng lỗi HTTP 400 Bad Request và không bao giờ được chuyển tiếp xuống EC2 instance phía sau.

Đặt ALB trước nhóm EC2 web application, ta có một điểm chặn đứng trước: cuộc tấn công dừng lại ở load balancer đúng như đề yêu cầu ("prevent this type of attack from reaching the EC2 instances").

Ngoài ra ALB còn có thuộc tính "Drop Invalid Header Fields" cho phép điều khiển việc load balancer loại bỏ các trường header không hợp lệ trước khi gửi tiếp về target — đây chính là nút chỉnh trực tiếp dành cho tình huống trong đề.

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

A — Network Access Control List (NACL) NACL là bộ lọc stateless ở tầng subnet, ra quyết định dựa trên IP nguồn/đích, protocol và dải port. Nó hoàn toàn không nhìn vào nội dung HTTP nên không có cách nào phân biệt một request hợp lệ với một request có header dị dạng đến từ cùng địa chỉ và cùng port 80/443. Muốn chặn bằng NACL thì chỉ còn cách chặn toàn bộ lưu lượng web — tức là chặn luôn cả người dùng thật.

B — Amazon Security Group rules Cùng một lỗ hổng lập luận như NACL, chỉ khác là security group stateful và gắn ở mức ENI/instance. Nó vẫn chỉ lọc theo nguồn, protocol và port. Với security group, một request HTTP dị dạng và một request HTTP bình thường trông giống hệt nhau — đều là TCP tới port 443. Không thể chặn cái này mà giữ cái kia nếu không đóng hẳn cổng web.

D — AWS Web Application Firewall (WAF) — đây là phương án gần đúng nhất và là bẫy chính của câu. Xét về khả năng, WAF đúng là thứ chuyên lọc lưu lượng Layer 7 theo nội dung request. Nhưng nó hỏng ở chỗ điểm gắn kết: WAF không gắn trực tiếp lên EC2 instance được. Web ACL của WAF chỉ associate được với các resource được hỗ trợ như CloudFront distribution, Application Load Balancer và API Gateway. Nghĩa là để dùng WAF bảo vệ nhóm EC2 trong đề, bạn vẫn phải dựng một ALB trước đã — nên bản thân WAF không phải câu trả lời độc lập cho tình huống này, còn ALB thì đã tự nó giải quyết xong vấn đề header dị dạng.

📌 Điểm cần nhớ

• Malformed / invalid HTTP là dấu hiệu của bài toán Layer 7. Mọi phương án chỉ lọc theo IP–protocol–port (security group, NACL) đều tự động bị loại, vì chúng không đọc được nội dung request.
• ALB terminate và phân tích HTTP, nên tự động trả HTTP 400 cho request sai đặc tả và không chuyển tiếp xuống target. Nhớ thêm thuộc tính "Drop Invalid Header Fields" — nó xuất hiện khá thường xuyên trong đề thi.
• AWS WAF cần một điểm gắn kết: CloudFront, ALB hoặc API Gateway — không gắn thẳng vào EC2. Khi đề nói "bảo vệ EC2" mà không nhắc tới các resource này, WAF thường là bẫy chứ không phải đáp án.
• Phân biệt vai trò: security group / NACL = kiểm soát ai được kết nối; ALB / WAF = kiểm soát nội dung request trông như thế nào. Đề hỏi về hình dạng của request thì phải chọn nhóm sau.

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

Đề đưa ra một Service Control Policy (SCP) đã được gắn vào một Organizational Unit (OU) chứa một member account của AWS Organizations, rồi hỏi: chính sách này gây ra hiệu ứng gì?

Ảnh chính sách trong đề không hiển thị được ở đây, nhưng phần giải thích của nguồn nêu rõ hai chi tiết quyết định đáp án:

• Khối "Action": ["ec2:*"] — phạm vi tác động trải rộng lên toàn bộ API action của EC2, chứ không phải một vài action lẻ.
• Điều kiện dựa trên aws:PrincipalArn — đây chính là cụm từ quyết định. Nó thu hẹp đối tượng bị chặn xuống đúng root user của account, thay vì áp lên mọi principal trong account.

Nói cách khác, đề bài kiểm tra hai kiến thức đi kèm nhau: (1) SCP đặt trần quyền cho member account, kể cả root user, và (2) khoá điều kiện aws:PrincipalArn lọc principal nào bị điều khoản đó chạm tới. Bỏ qua điều kiện này là chọn ngay phương án "tất cả user", bỏ qua chữ ec2:* là chọn phương án nói về việc đăng nhập vào instance.

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

A. The root user will not be able to perform any ec2 actions.

SCP là permissions boundary ở cấp tổ chức: nó không cấp quyền, mà giới hạn trần quyền tối đa mà mọi identity trong member account có thể sử dụng. Điểm đặc biệt so với IAM policy thông thường là SCP áp được lên cả root user của member account — root ở member account không nằm ngoài tầm với của SCP.

Chính sách trong đề từ chối ec2:* với điều kiện aws:PrincipalArn trỏ tới root user, nên kết quả đúng như phương án A mô tả: root user của account đó gọi bất kỳ API action nào thuộc namespace ec2 cũng bị chặn, còn các IAM user/role khác không bị điều khoản này chạm tới.

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

B. All users will be restricted from performing any ec2 actions.

Đây là phương án gần đúng nhất và là bẫy chính. Nếu chính sách chỉ có "Effect": "Deny" + "Action": ["ec2:*"] + "Resource": "*" mà không có khối Condition, thì B mới là câu trả lời. Nhưng điều kiện aws:PrincipalArn đã lọc principal xuống đúng root user, nên các principal khác không khớp điều kiện và điều khoản Deny không áp lên họ. B hỏng ở chỗ đọc thiếu khối Condition.

C. The root user will not be able to login to EC2 instances.

Nhầm lẫn giữa control plane và hệ điều hành bên trong instance. Các action ec2:* là những lời gọi API tới dịch vụ EC2 (RunInstances, DescribeInstances, TerminateInstances…). Việc đăng nhập vào một instance đang chạy — qua SSH hay RDP — là chuyện của tài khoản hệ điều hành và key pair, không đi qua API action nào của EC2, nên SCP không can thiệp được. Ngoài ra "root user" trong ngữ cảnh AWS Organizations là root account của AWS, khác hẳn user root của Linux — phương án C đánh tráo hai khái niệm này.

D. Nothing, it is not possible to restrict root user actions.

Sai vì đúng ngược lại: SCP hạn chế được hành động của root user trong member account. Điểm khiến phương án này nghe có lý là trường hợp riêng của management account (master account) — SCP không có hiệu lực lên nó, kể cả khi gắn vào root của tổ chức. Nhưng đề đã nói rõ đây là OU chứa một member account, nên ngoại lệ đó không áp dụng và chính sách vẫn có hiệu lực.

📌 Điểm cần nhớ

• SCP không cấp quyền, chỉ đặt trần quyền tối đa cho member account; quyền thực tế là phần giao giữa SCP và IAM policy.
• SCP có hiệu lực lên root user của member account, nhưng không có hiệu lực lên management account của tổ chức — đây là ranh giới hay bị hỏi.
• Gặp SCP có khối Condition với aws:PrincipalArn, phải đọc kỹ: nó quyết định điều khoản áp lên ai, và thường là điểm phân biệt giữa "chỉ root user" và "mọi user".
• Phân biệt control plane với trong instance: ec2:* chặn lời gọi API tới dịch vụ EC2, không đụng tới việc SSH/RDP vào hệ điều hành của instance.

🧩 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 sau một Application Load Balancer (ALB). Một instance trong target group đã vượt quá UnhealthyThresholdCount — tức là nó trượt health check liên tiếp đủ số lần cấu hình. Câu hỏi: điều gì xảy ra tiếp theo? (chọn HAI).

Cụm từ quyết định đáp án nằm ở chỗ đề bài chỉ nhắc tới ALB và target group, không hề nhắc tới Auto Scaling group. Đây chính là ràng buộc phân biệt các phương án gần giống nhau: ba trong năm phương án mô tả hành vi của Auto Scaling (terminate, reboot, thay thế bằng instance mới), còn hai phương án còn lại mô tả hành vi của chính load balancer. Khi đề không nêu Auto Scaling group, ta chỉ được suy luận trong phạm vi những gì ELB tự làm.

Ràng buộc thứ hai: UnhealthyThresholdCount là ngưỡng của target group, không phải ngưỡng của hạ tầng compute. Nó chỉ điều khiển việc một target được coi là healthy hay unhealthy trong bảng định tuyến của load balancer.

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

Theo tệp, đáp án đúng là A và D.

D — "The load balancer will take the EC2 instance out of service." Đây là tác dụng trực tiếp của việc vượt UnhealthyThresholdCount: target chuyển trạng thái sang unhealthy và load balancer ngừng định tuyến request mới tới nó. Instance vẫn đang chạy, vẫn nằm trong target group, chỉ là không nhận traffic nữa.

A — "The load balancer will continue to perform the health check on the EC2 instance." ELB không bỏ rơi target đã bị đánh dấu unhealthy. Nó tiếp tục gửi health check theo đúng chu kỳ. Nhờ vậy mới có đường quay lại: khi target đạt đủ số lần thành công liên tiếp theo HealthyThresholdCount, load balancer đưa nó trở lại phục vụ một cách tự động. Nếu ELB ngừng kiểm tra thì cơ chế tự phục hồi này không tồn tại — và đó là lý do A là một nửa không thể thiếu của câu trả lời.

Hai vế A và D ghép lại mô tả trọn vòng đời trạng thái của một target: out of service → vẫn bị kiểm tra → có thể được đưa lại vào service.

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

B — "The EC2 instance will be terminated based on the health check failure." Sai, và đây là bẫy phổ biến nhất. ELB không bao giờ terminate instance. Nó không có quyền và cũng không phải vai trò của nó — ELB chỉ định tuyến traffic và đánh giá sức khoẻ target. Việc terminate là hành động của Auto Scaling group, và trong đề không có Auto Scaling group nào.

C — "The EC2 instance will be rebooted by Amazon EC2 Auto Scaling." Sai vì hai lý do chồng lên nhau, cần thấy cả hai. Thứ nhất, đề không nhắc tới EC2 Auto Scaling nên không thể giả định nó tồn tại. Thứ hai, kể cả khi có Auto Scaling group, nó cũng không reboot instance bị lỗi — hành vi của Auto Scaling là terminate rồi launch instance mới, không phải khởi động lại instance cũ. Đây là phương án sai theo cả hai tầng.

E — "A new EC2 instance will be deployed to replace the unhealthy instance." Đây là phương án gần đúng nhất và dễ chọn nhầm nhất, vì nó mô tả đúng một hành vi có thật trong AWS: khi Auto Scaling group được cấu hình dùng ELB health check làm nguồn đánh giá sức khoẻ, một target bị ELB đánh dấu unhealthy sẽ khiến Auto Scaling thay thế instance đó. Nó hỏng ở đúng một chỗ: kịch bản trong đề không hề nói có Auto Scaling group, cũng không nói health check type đã được đổi sang ELB. Không có tiền đề đó thì việc thay thế đơn giản không xảy ra — instance unhealthy cứ nằm im ở trạng thái out of service. Chọn E là mang một giả định của mình vào đề bài.

📌 Điểm cần nhớ

• ELB chỉ có hai quyền với một target unhealthy: ngừng gửi traffic, và tiếp tục health check. Nó không reboot, không terminate, không tạo mới. Mọi phương án nói tới vòng đời của instance đều thuộc về Auto Scaling, không thuộc về load balancer.
• UnhealthyThresholdCount đưa target ra khỏi service; HealthyThresholdCount đưa nó trở lại. Hai ngưỡng này đối xứng nhau, và chính vì health check không dừng lại nên vế "trở lại" mới thực hiện được.
• Đọc đề để tìm cái KHÔNG được nhắc tới. Với dạng câu này, sự vắng mặt của cụm "Auto Scaling group" là dữ kiện quyết định, ngang tầm quan trọng với những gì đề có viết ra. Đừng bổ sung thành phần kiến trúc mà đề không cho.
• Auto Scaling terminate rồi thay mới, chứ không reboot. Bất kỳ phương án nào nói Auto Scaling "khởi động lại" instance đều sai về nguyên lý, kể cả khi kịch bản thực sự có Auto Scaling group.
• Việc thay thế instance tự động chỉ xảy ra khi có Auto Scaling group và group đó được cấu hình lấy ELB health check làm căn cứ — thiếu một trong hai điều kiện thì không có gì thay thế cả.

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

Đề mô tả một Auto Scaling group được cấu hình scale-out khi CPU utilization chạm 80%. CPU đã lên 90% — nghĩa là chính sách scaling đã kích hoạt đúng như thiết kế — nhưng việc khởi tạo instance thất bại.

Cụm từ quyết định đáp án nằm gọn trong thông báo lỗi:

"8 instance(s) are already running. Launching EC2 instance failed"

Hai chi tiết cần đọc kỹ:

• "are already running" — vấn đề không phải Auto Scaling không chịu scale, mà là nó đã cố và bị chặn lại ở một trần số lượng instance.
• Con số instance đang chạy được nêu ra kèm lời từ chối, đây là dấu hiệu đặc trưng của việc chạm service quota (limit) cho EC2 tại Region đó, chứ không phải lỗi cấu hình scaling policy.

Vậy câu hỏi thực chất là: khi Auto Scaling bị chặn bởi trần số lượng instance ở cấp tài khoản/Region thì phải làm gì? Điểm mấu chốt là quota EC2 được áp theo từng Region, và có thể yêu cầu tăng cũng theo từng Region.

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

B — Request an EC2 service quota increase for the Region.

Khi tạo tài khoản AWS, mặc định đã có giới hạn về số lượng instance được phép chạy, đặt riêng cho từng Region. Thông báo lỗi trong đề chính là cách Auto Scaling báo rằng nó đã chạm trần đó: nó liệt kê số instance đang chạy rồi tuyên bố việc launch thất bại.

Vì nguyên nhân gốc là quota, cách sửa duy nhất hợp lệ là xin nâng quota EC2 cho đúng Region đang bị chặn. Sau khi quota được nâng, chính sách scaling hiện có sẽ tự hoạt động trở lại ở lần đánh giá tiếp theo — không cần sửa gì thêm trong Auto Scaling group, vì bản thân nó đã hoạt động đúng.

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

A — Increase the account limits for EBS General Purpose (SSD) storage. Đây là phương án đánh vào phản xạ "cứ chạm giới hạn thì nâng giới hạn", và đúng là EBS cũng có quota riêng. Nhưng nó hỏng ở chỗ sai loại quota: thông báo lỗi nói rõ về số lượng instance đang chạy, không hề nhắc tới dung lượng hay số lượng volume. Nâng quota EBS gp2/gp3 sẽ không làm thay đổi trần số instance, và lần scale-out sau vẫn thất bại với đúng thông báo cũ.

C — Configure a scheduled scaling policy with the current date and time. Phương án này nhầm lẫn giữa thời điểm kích hoạt và khả năng khởi tạo. Scheduled scaling chỉ giúp khi bạn muốn thay đổi capacity theo lịch biết trước, ví dụ tăng trước giờ cao điểm. Ở đây chính sách hiện tại đã kích hoạt rồi — vấn đề không nằm ở việc "khi nào" mà ở việc lệnh launch bị từ chối. Đặt thêm một lịch trỏ vào thời điểm hiện tại chỉ tạo ra thêm một yêu cầu launch nữa, và nó cũng sẽ bị chặn y hệt bởi cùng một quota.

D — Disable the scaling policies and manually launch EC2 instances. Đây là phương án gần đúng nhất về mặt "làm gì đó để có thêm instance", nhưng nó hỏng ở giả định nền tảng: quota EC2 áp cho cả Region, không phân biệt instance do Auto Scaling tạo hay do người vận hành bấm tay tạo. Đã chạm trần thì launch thủ công cũng thất bại đúng như vậy. Ngoài ra, tắt scaling policy còn làm mất luôn khả năng tự co giãn — biến một sự cố tạm thời thành vận hành thủ công lâu dài, đi ngược mục đích dùng Auto Scaling.

📌 Điểm cần nhớ

• Thông báo dạng "N instance(s) are already running. Launching EC2 instance failed" là chỉ dấu chuẩn của việc chạm EC2 service quota, không phải lỗi scaling policy, không phải lỗi CPU metric.
• Service quota của EC2 được áp theo từng Region; hết quota ở Region này không nói gì về Region khác, và yêu cầu nâng cũng phải nộp theo từng Region.
• Quota chặn ở tầng tài khoản/Region, nên launch thủ công không phải đường vòng — mọi cách khởi tạo instance đều bị chặn như nhau.
• Đọc kỹ loại tài nguyên trong thông báo lỗi trước khi chọn quota để nâng: lỗi về số lượng instance thì nâng quota EC2, không phải quota EBS hay bất kỳ quota nào khác chỉ vì chúng cũng liên quan tới EC2.

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

Đề mô tả một SysOps Administrator muốn bật SSL/TLS cho website chạy sau một internet-facing Application Load Balancer (ALB). Người này vào AWS Certificate Manager (ACM) xin chứng chỉ, nhưng lại nhập chính FQDN của ALB làm domain name, và nhận lỗi "Domain Not Allowed".

Cụm từ quyết định đáp án nằm ở đúng chỗ này: "the request was submitted using the ALB fully qualified domain name (FQDN)". Đó không phải chi tiết trang trí — nó chỉ thẳng nguyên nhân lỗi. FQDN của ALB có dạng ten-alb-123456.ap-southeast-1.elb.amazonaws.com, tức là nằm dưới tên miền amazonaws.com — tên miền của AWS, không phải của khách hàng. ACM chỉ cấp chứng chỉ public cho tên miền mà người xin sở hữu và chứng minh được quyền sở hữu. Vì không ai ngoài AWS sở hữu amazonaws.com, ACM chặn ngay từ khâu nhận yêu cầu bằng thông báo "Domain Not Allowed" — chưa kịp bước sang giai đoạn validation.

Chi tiết thứ hai đáng để ý: lỗi xảy ra lúc submit request, chứ không phải lúc validate. Điều này loại luôn mọi phương án bàn về cách validate, vì yêu cầu còn chưa được tạo ra để mà validate.

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

B — Submit a new request in ACM with the correct domain name rather than the ALB FQDN.

Cách sửa duy nhất đúng bản chất: gửi lại yêu cầu ACM với tên miền thật của website (tên miền mà quản trị viên sở hữu), thay vì FQDN của ALB. Có hai lý do củng cố lẫn nhau:

• Về quyền sở hữu: bạn phải sở hữu tên miền mình xin chứng chỉ. Với tên miền của chính mình thì mới validate được — qua email hoặc qua DNS, cả hai cách đều hợp lệ.
• Về mặt sử dụng thực tế: người dùng cuối gõ tên miền website vào trình duyệt, không ai gõ FQDN của ALB. Chứng chỉ phải khớp với tên miền trên thanh địa chỉ, nếu không trình duyệt vẫn báo lỗi tên miền không khớp dù chứng chỉ hợp lệ.

Sau khi có chứng chỉ cho tên miền đúng, gắn nó vào HTTPS listener của ALB, rồi trong Route 53 tạo một Alias record trỏ tên miền website sang ALB. Lúc đó tên miền, chứng chỉ và load balancer khớp nhau trọn vẹn.

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

A — DNS validation, thêm CNAME record vào hosted zone Route 53. Đây là phương án gần đúng nhất và dễ chọn nhầm nhất, vì DNS validation bằng CNAME đúng là cách chuẩn để chứng minh quyền sở hữu tên miền với ACM. Nhưng nó hỏng ở chỗ: yêu cầu ở đây xin chứng chỉ cho FQDN của ALB, thuộc amazonaws.com. Bạn không có hosted zone cho tên miền đó và không thể tạo bản ghi CNAME trong đó — vùng DNS ấy do AWS quản lý. Hơn nữa, request đã bị từ chối ngay từ bước submit, nên chưa hề có bản ghi CNAME nào để mà thêm. Sửa cách validate không cứu được một yêu cầu sai tên miền ngay từ đầu.

C — Liên hệ AWS Support và trả lời câu hỏi bảo mật để xác minh. Không có quy trình nào như vậy. ACM xác minh quyền sở hữu tên miền bằng cơ chế tự động (email hoặc DNS), không phải bằng câu hỏi bảo mật qua Support. Và kể cả AWS Support có muốn giúp thì cũng không thể cấp cho khách hàng chứng chỉ trên tên miền amazonaws.com của chính AWS. Vấn đề là dữ liệu nhập vào sai, không phải là bị kẹt thủ tục.

D — Email validation, xác nhận quyền sở hữu qua email của root account. Sai vì cùng một lý do gốc với A: không thể xác nhận quyền sở hữu FQDN của ALB, vì tên miền đó thuộc AWS. Email validation gửi thư tới các địa chỉ liên hệ đăng ký trong WHOIS của tên miền và các địa chỉ quy ước như admin@<domain> — với amazonaws.com thì những địa chỉ đó không thuộc về quản trị viên. Email của root account trong AWS account là chuyện hoàn toàn khác, nó không đóng vai trò gì trong việc chứng minh sở hữu tên miền.

📌 Điểm cần nhớ

• ACM chỉ cấp chứng chỉ public cho tên miền bạn sở hữu; FQDN do AWS sinh ra cho ALB/NLB/CloudFront nằm dưới amazonaws.com nên không bao giờ xin chứng chỉ cho chúng được — đó chính là ý nghĩa của lỗi "Domain Not Allowed".
• Đọc kỹ lỗi xảy ra ở giai đoạn nào: lỗi lúc submit request là lỗi dữ liệu đầu vào; lỗi lúc validation mới là lúc bàn tới email hay DNS. Nhầm giai đoạn là chọn ngay phương án "gần đúng".
• Chứng chỉ phải khớp tên miền mà người dùng gõ vào trình duyệt, không phải tên nội bộ của hạ tầng phía sau.
• Mô hình chuẩn cho website sau ALB: chứng chỉ ACM cấp cho tên miền của bạn → gắn vào HTTPS listener của ALB → Route 53 Alias record trỏ tên miền sang ALB. ACM cho phép validate bằng email hoặc DNS, cả hai đều được, miễn là tên miền thuộc về bạn.