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

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

Tình huống: một ứng dụng chạy sau Application Load Balancer (ALB), và quản trị viên thấy rất nhiều request HTTP đáng ngờ đổ vào ALB. Điểm mấu chốt là "originate from various IP addresses" — lưu lượng đến từ nhiều địa chỉ IP khác nhau, không phải từ một IP cố định để mà chặn thủ công.

Cụm từ quyết định đáp án là "with the LEAST effort" (ít công sức nhất). Cả bốn phương án đều mô tả một cách nào đó để cản lưu lượng xấu, nên câu hỏi không hỏi "cách nào chặn được" mà hỏi "cách nào chặn được mà không phải tự viết code, tự dựng logic phát hiện". Ghép hai ràng buộc lại — nhiều IP thay đổi + ít công sức nhất — ta cần một cơ chế tự động nhận diện theo tốc độ request và tự chặn, đặt sẵn ngay trước ALB, không cần lập trình.

Chi tiết "HTTP requests" cũng có ý: đây là lưu lượng tầng ứng dụng (layer 7), nên công cụ đúng phải hiểu được HTTP chứ không chỉ nhìn gói tin ở tầng mạng.

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

Đáp án C — Tạo một AWS WAF rate-based rule để chặn lưu lượng khi vượt ngưỡng định trước.

AWS WAF là web application firewall cho tầng ứng dụng, gắn trực tiếp được vào ALB. Nó cho phép khai báo các rule để allow / block / count request dựa trên điều kiện do bạn định nghĩa: địa chỉ IP, HTTP header, HTTP body, chuỗi URI, dấu hiệu SQL injection, cross-site scripting…

Rate-based rule là loại rule chuyên cho đúng tình huống này: bạn khai báo số request tối đa mà một client IP được phép gửi trong một khoảng thời gian trượt (trailing window) được cập nhật liên tục. IP nào vượt ngưỡng thì các request mới bị chặn cho tới khi tốc độ của nó tụt xuống dưới ngưỡng.

Vì sao nó là "least effort": bạn chỉ cấu hình một con số ngưỡng rồi gắn web ACL vào ALB. Không viết code, không dựng pipeline phân tích log, không tự quản lý danh sách IP — WAF tự theo dõi từng IP nguồn và tự chặn/tự bỏ chặn. Đúng với ràng buộc "nhiều IP khác nhau", vì rule áp cho mọi IP chứ không phải một danh sách liệt kê tay.

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

A. Tạo CloudFront distribution để cache nội dung và tự động chặn các IP nguồn đáng ngờ. Sai ở chỗ "automatically block": CloudFront không có khả năng tự phát hiện lưu lượng độc hại rồi tự chặn IP nguồn. Nó là CDN — cache và phân phối nội dung. Việc chặn theo điều kiện vẫn phải do WAF đảm nhiệm; CloudFront tự nó không sinh ra logic nhận diện "đáng ngờ". Đây là phương án nghe hợp lý nhất trong ba cái sai, nhưng nó gán cho CloudFront một tính năng mà dịch vụ này không có.

B. Dùng Amazon GuardDuty phân tích hoạt động mạng, phát hiện bất thường, kích hoạt Lambda để ngăn truy cập. Về mặt kỹ thuật thì làm được: GuardDuty phân tích log và luồng mạng, phát hiện bất thường, và finding của nó có thể kích hoạt một Lambda function để khắc phục. Nhưng nó hỏng ở tiêu chí "LEAST effort" — bạn phải tự viết Lambda function, tự thiết kế logic khắc phục và duy trì nó về sau. So với việc bật một rate-based rule thì đây là nhiều công sức hơn hẳn. Đây là bẫy kinh điển: phương án đúng về chức năng nhưng thua về tiêu chí lựa chọn.

D. Dùng Lambda phân tích VPC Flow Log, phát hiện lưu lượng đáng ngờ, chặn IP trong security group. Sai hai lần. Thứ nhất, cũng như B, phải tự viết Lambda function nên không phải cách ít công sức nhất. Thứ hai — và đây là lỗi nặng hơn — security group không hỗ trợ deny rule: nó chỉ có luật cho phép (allow), nên về nguyên tắc bạn không thể "chặn một IP" trong security group. Muốn chặn tường minh theo IP ở tầng mạng thì phải dùng cơ chế khác, không phải security group. Phương án này mô tả một thao tác không thực hiện được.

📌 Điểm cần nhớ

• Rate-based rule của AWS WAF là câu trả lời mặc định cho tình huống "nhiều request HTTP đáng ngờ, từ nhiều IP khác nhau, cần chặn nhanh": chỉ khai một ngưỡng, WAF tự theo dõi từng IP nguồn trong cửa sổ thời gian trượt và tự chặn/tự bỏ chặn.
• Security group chỉ có allow, không có deny. Bất kỳ phương án nào nói "block IP address in the security group" đều sai về nguyên lý — đây là điểm loại trừ dùng được cho rất nhiều câu khác.
• Gặp cụm "LEAST effort" / "LEAST operational overhead", hãy loại các phương án bắt bạn tự viết Lambda function hay tự dựng pipeline phân tích log, dù chúng vẫn giải quyết được vấn đề. GuardDuty + Lambda là giải pháp hợp lệ nhưng không bao giờ là giải pháp "ít công sức nhất" khi có sẵn một managed rule làm đúng việc đó.
• Phân biệt vai trò: WAF lọc và chặn ở tầng ứng dụng (layer 7), CloudFront cache và phân phối nội dung, GuardDuty phát hiện mối đe dọa và sinh finding chứ tự nó không chặn. Đừng gán khả năng "tự động chặn IP độc hại" cho CloudFront.

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

Đề mô tả một web application chạy trên hai EC2 instance đứng sau Application Load Balancer (ALB). Triệu chứng gồm ba mảnh ghép cần đọc cùng nhau:

• Người dùng báo performance kém;
• Xuất hiện lỗi HTTP 503 (service unavailable — ALB không tìm được target khỏe mạnh để chuyển tiếp) và 504 (gateway timeout — target nhận request nhưng không trả lời kịp);
• CloudWatch cho thấy CPU utilization trên các instance cực cao.

Cụm từ quyết định đáp án là "CPU utilization on the instances is extremely high". Đây là chỉ dấu rằng vấn đề nằm ở năng lực xử lý (capacity) của tầng compute, chứ không phải ở cách ALB phân phối hay ở giao thức listener. 503/504 ở đây là hệ quả của việc backend quá tải: instance bận tới mức không trả lời health check hoặc không kịp trả response.

Khi đề đã chỉ thẳng vào capacity, phương án đúng phải là phương án tăng thêm khả năng xử lý theo tải thực tế. Mọi phương án chỉ chỉnh cấu hình load balancer đều thất bại ở cùng một điểm: chúng chia lại cùng một lượng tài nguyên đang thiếu, chứ không thêm tài nguyên nào.

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

B. Place the EC2 instances into an Amazon EC2 Auto Scaling group.

Đặt các instance vào một EC2 Auto Scaling group cho phép số lượng instance phục vụ ứng dụng tự động thay đổi theo tải thực tế mà người dùng đặt lên hệ thống. Khi CPU tăng cao, scaling policy thêm instance mới; tải được trải mỏng ra nhiều instance hơn nên CPU mỗi máy giảm xuống, response time trở lại bình thường và các lỗi 503/504 sinh ra do quá tải cũng hết theo.

Điểm thực hành đáng chú ý: không cần dựng lại hạ tầng từ đầu. Các EC2 instance đang chạy có thể được attach vào một Auto Scaling group sẵn có; sau khi attach, chúng trở thành thành viên của group đó. Đây là lý do phương án này được xem là cách xử lý đơn giản nhất cho tình huống trong đề — và cũng là phương án duy nhất trong bốn phương án thực sự thêm compute capacity.

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

A. Configure the load balancer to use a TCP listener instead of HTTPS. Sai ở hai tầng. Thứ nhất, Application Load Balancer không hỗ trợ TCP listener — ALB hoạt động ở tầng ứng dụng với listener HTTP/HTTPS; muốn TCP thì phải là loại load balancer khác. Thứ hai, kể cả bỏ qua chuyện đó, đổi giao thức listener cũng không cải thiện performance: CPU cao đến từ khối lượng công việc mà ứng dụng phải xử lý, không phải từ việc listener nói HTTPS hay TCP.

C. Enable sticky sessions on the Application Load Balancer. Đây là phương án dễ nhầm nhất vì sticky sessions nghe như một tối ưu hiệu năng. Thực chất nó khiến các kết nối của cùng một session luôn được gửi tới cùng một back-end instance trong suốt vòng đời session. Nó giải quyết bài toán giữ trạng thái phiên, không giải quyết bài toán thiếu năng lực xử lý: tổng tải không đổi, và CPU utilization của instance không hề giảm. Tệ hơn, ghim session vào một máy có xu hướng làm phân bố tải kém đều hơn chứ không tốt hơn.

D. Enable cross-zone load balancing on the Application Load Balancer. Cross-zone load balancing giúp trải traffic đều giữa các instance nằm ở những Availability Zone khác nhau, đặc biệt hữu ích khi số instance lệch nhau giữa các AZ (ví dụ chạy số lượng instance lẻ). Trong tình huống này nó không giúp gì: đề nói rõ có hai instance — một số chẵn, phân bố vốn đã cân. Và giống hai phương án trên, nó chỉ phân phối lại lượng tải hiện có giữa đúng hai máy đang quá tải, chứ không thêm một đơn vị compute nào.

📌 Điểm cần nhớ

• CPU utilization cao trên target = bài toán capacity. Câu trả lời phải thêm compute, không phải chỉnh cách phân phối. Auto Scaling là công cụ tiêu chuẩn cho việc này.
• 503/504 sau load balancer thường là triệu chứng, không phải nguyên nhân. Hãy truy ngược về metric của target (CPU, memory, health check) để tìm nguyên nhân gốc trước khi động vào cấu hình load balancer.
• ALB là load balancer tầng ứng dụng, làm việc với listener HTTP/HTTPS — thấy phương án nào gán TCP listener cho ALB thì loại ngay.
• Phân biệt rõ mục đích từng tính năng ALB: sticky sessions dùng để giữ tính liên tục của session; cross-zone load balancing dùng để cân traffic giữa các AZ có số instance không đều. Cả hai đều không làm giảm tổng tải đặt lên backend.
• EC2 instance đang chạy có thể attach vào Auto Scaling group — không cần rebuild hạ tầng, nên đây thường là lựa chọn ít gây xáo trộn nhất trong các câu hỏi kiểu này.

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

Đề mô tả một ứng dụng có Application Load Balancer (ALB) đứng trước sáu EC2 instance nằm trong cùng MỘT security group, và metric CloudWatch HealthyHostCount tụt từ 6 xuống 2. Câu hỏi là: nguyên nhân MOST likely (khả dĩ nhất) là gì?

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

• "a single security group" — cả sáu instance dùng chung đúng một security group. Bất kỳ lỗi cấu hình nào ở tầng dùng chung này đều tác động giống hệt nhau lên cả sáu máy.
• "has dropped from 6 to 2" — đây là một sự cố cục bộ: 4 máy rớt, 2 máy vẫn phục vụ bình thường. Không phải sự cố toàn cụm.

Ghép hai điều đó lại: nguyên nhân đúng phải là thứ có thể tác động lên một phần số instance chứ không phải toàn bộ. Đây chính là bộ lọc loại phương án của câu này. Ngoài ra cần nhớ HealthyHostCount là metric của ALB, phản ánh kết quả ALB health check, chứ không phản ánh bất kỳ cơ chế health check nào khác.

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

Đáp án C — ALB health check thất bại và ALB đã đưa các instance đó ra khỏi vòng phục vụ.

HealthyHostCount được ALB tính bằng chính health check mà ALB gửi tới từng target trong target group. Khi một target trả lời không đạt đủ số lần liên tiếp theo ngưỡng cấu hình, ALB đánh dấu target đó unhealthy, ngừng định tuyến request tới nó, và metric giảm đi tương ứng. Đây là con đường duy nhất trong bốn phương án khiến con số này thay đổi.

Quan trọng hơn: health check chạy độc lập trên từng target. Bốn instance có thể fail vì lỗi riêng của chúng — tiến trình ứng dụng chết, cạn bộ nhớ, đường dẫn health check trả về mã lỗi, phản hồi chậm quá ngưỡng timeout — trong khi hai instance còn lại vẫn khoẻ. Đúng bằng hình dạng "6 → 2" mà đề mô tả.

Bản giải thích gốc nói thẳng điều này: không rõ vì sao đúng bốn máy fail, nhưng đây là nguyên nhân khả dĩ nhất, vì mọi phương án còn lại đều dẫn tới kết quả "tất cả cùng hỏng" hoặc "chẳng máy nào hỏng".

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

A. Route 53 health check thất bại và ALB đã gỡ instance ra khỏi vòng phục vụ. Sai ở chỗ nhầm lẫn hai cơ chế hoàn toàn tách biệt. Route 53 health check phục vụ việc định tuyến DNS — nó quyết định Route 53 có trả về một record hay không (ví dụ trong failover routing). Nó không điều khiển việc ALB đưa target vào hay ra khỏi vòng phục vụ. ALB chỉ hành động dựa trên health check của chính nó. Vì vậy dù Route 53 health check có fail đi nữa, HealthyHostCount của ALB cũng không vì thế mà giảm.

B. Security group của các instance không cho ALB health check đi qua. Đây là phương án gần đúng nhất và là bẫy chính của câu này — nếu security group chặn cổng health check thì health check quả thật sẽ fail. Nhưng nó hỏng ở phần số lượng: đề nói rõ cả sáu instance nằm trong cùng một security group. Rule của security group áp dụng đồng loạt cho mọi thành viên, không có ngoại lệ theo từng instance. Cấu hình sai thì cả sáu cùng fail, HealthyHostCount phải rơi về 0, không thể dừng ở 2. Con số 2 chính là bằng chứng loại phương án này.

C là đáp án đúng (đã giải thích ở trên).

D. Route table chưa được cập nhật để lưu lượng đi được giữa ALB và EC2 instance. Sai theo cùng logic "được ăn cả ngã về không". Route table gắn với subnet, không gắn với từng instance. Nếu đường đi giữa ALB và các instance không thông, thì không target nào nhận được health check và không máy nào healthy — lại là 0 chứ không phải 2. Thêm nữa, đây là hệ thống đang chạy với sáu host khoẻ trước đó; route table là cấu hình nền tảng, nếu nó sai thì hệ thống đã không bao giờ hoạt động ngay từ đầu, chứ không phải tự nhiên hỏng một phần.

📌 Điểm cần nhớ

• HealthyHostCount là metric của ALB và chỉ phản ánh kết quả ALB health check trên target group. Route 53 health check là cơ chế riêng, phục vụ định tuyến DNS, không tác động tới metric này.
• Với dạng câu "chỉ một phần host bị ảnh hưởng", hãy tìm nguyên nhân ở mức từng instance. Mọi nguyên nhân ở tầng dùng chung — security group chung, route table, NACL, cấu hình target group — đều gây hỏng đồng loạt, tức là con số phải về 0.
• Ngược lại, thấy HealthyHostCount rơi thẳng về 0 thì nên nghi tầng dùng chung trước: security group chặn cổng health check, route table/subnet sai, hoặc đường dẫn health check cấu hình sai trong target group.
• Chi tiết "single security group" trong đề không phải màu mè — đề thi cố tình đặt nó vào để bạn loại được phương án security group. Đọc kỹ những mệnh đề mô tả cấu hình dùng chung, chúng thường chính là chìa khoá.

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

Đề mô tả một Site-to-Site VPN kiểu IPsec nối data center tại chỗ với AWS. Cụm từ quyết định nằm ở chỗ "The VPN connection is showing as active" — đường hầm đã lên, tức là phần đàm phán IKE/IPsec, pre-shared key, customer gateway và thiết bị phía on-premises đều đã đúng. Cụm thứ hai bổ trợ: "cannot communicate with any resources" — hỏng toàn bộ, không phải hỏng một cổng hay một giao thức.

Hai chi tiết đó cùng chỉ về một lớp duy nhất: routing trong VPC. Tunnel sống nhưng subnet của EC2 không có đường đi tới CIDR của on-premises, nên gói tin không bao giờ được đẩy vào virtual private gateway. Đây chính là ràng buộc phân biệt các phương án nghe đều "liên quan tới VPN".

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

Đáp án đúng theo tệp là B — bật route propagation cho virtual private gateway trên route table của subnet chứa EC2.

Site-to-Site VPN gắn vào VPC qua một virtual private gateway. Khi VPN lên, các prefix của mạng on-premises được học về (qua BGP với dynamic routing, hoặc khai báo tĩnh với static routing) — nhưng chúng chỉ nằm ở virtual private gateway, không tự chảy vào route table của subnet. Bật route propagation là thao tác cho phép route table đó nhận các prefix ấy tự động, trỏ next hop về virtual private gateway.

Chưa bật thì route table của subnet chỉ có route nội bộ VPC (local) và có thể là route ra internet. Gói tin EC2 gửi tới địa chỉ on-premises không khớp route nào cụ thể nên bị bỏ hoặc đi sai hướng — đúng triệu chứng "tunnel active mà không nói chuyện được với bất cứ thứ gì".

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

A — Sửa DHCP options set của VPC, thêm VPN connection vào đó. DHCP options set chỉ điều khiển những thứ cấp phát cho instance khi khởi động: domain name, DNS server, NTP server. Nó không có khái niệm "VPN connection" để mà thêm vào — mô tả trong phương án này không tương ứng với bất kỳ trường cấu hình nào có thật. Sai cả về lớp (name resolution chứ không phải routing) lẫn về cú pháp cấu hình.

C — Mở security group cho ICMP từ CIDR của data center. Đây là phương án gần đúng nhất và cũng là bẫy chính. Đúng là muốn ping được thì security group phải cho ICMP vào — nhưng nó hỏng ở hai chỗ. Thứ nhất, đề nói không giao tiếp được với bất kỳ tài nguyên nào, chứ không nói riêng ping thất bại; nếu chỉ thiếu rule ICMP thì SSH, HTTP, database vẫn phải chạy được. Thứ hai, security group là stateful và mặc định cho phép mọi traffic đi ra, nên nó không giải thích được vì sao chiều EC2 → on-premises cũng im lặng. Nói cách khác: sửa C có thể cần làm sau, nhưng không phải nguyên nhân gốc, và sửa mỗi C thì vẫn không thông.

D — Đặt một transit gateway ở giữa VPN và subnet của EC2. Transit gateway là hub để nối nhiều VPC và nhiều kết nối on-premises lại với nhau. Ở đây chỉ có đúng một VPC nối một data center — kiến trúc đã đủ với virtual private gateway. Quan trọng hơn: transit gateway không sửa được lỗi thiếu route; dùng nó thì vẫn phải cấu hình route table trỏ về transit gateway. Đây là giải pháp nặng tay, tốn kém, đòi dựng lại attachment, mà vẫn không chạm tới nguyên nhân thật.

📌 Điểm cần nhớ

• "VPN tunnel is UP nhưng không thông" gần như luôn là bài toán routing, không phải bài toán IPsec. Tunnel state chỉ chứng minh lớp bắt tay đã xong.
• Route propagation là cầu nối giữa virtual private gateway và route table của subnet. Học được prefix chưa có nghĩa là subnet dùng được prefix đó — phải bật propagation, hoặc thêm route tĩnh bằng tay.
• Phân biệt triệu chứng theo phạm vi: hỏng toàn bộ giao thức → nghi routing; hỏng đúng một cổng hay một giao thức (ví dụ chỉ ping không được) → nghi security group hoặc network ACL.
• Transit gateway giải bài toán quy mô và topology nhiều-nhiều, không giải bài toán một VPC nối một data center; đừng chọn nó chỉ vì tên nghe "mạnh hơn".
• DHCP options set thuộc lớp name resolution (DNS, NTP, domain name), tuyệt đối không dính tới đường đi của gói tin.

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

Đề mô tả một website chạy on-premises (không nằm trên AWS), gồm một server active và một server passive. Yêu cầu là dùng Amazon Route 53 để làm high availability theo kiểu failover: traffic đi về server active chính khi health check trả về status code 2xx, còn lại thì đẩy sang server passive. Câu hỏi hỏi hai thứ: chọn record type nào và health check loại nào.

Có đúng hai cụm từ quyết định đáp án, và mỗi cụm loại đi một nửa danh sách:

• "running on-premises" — quyết định record type. Alias record trong Route 53 chỉ trỏ tới tài nguyên AWS (ELB, CloudFront distribution, S3 website endpoint, API Gateway, một record khác trong cùng hosted zone…). Server nằm ngoài AWS thì không có target hợp lệ cho alias, chỉ còn cách khai địa chỉ IP bằng A record.
• "returns a 2xx status code" — quyết định loại health check. Status code là khái niệm của HTTP, chỉ health check ở tầng ứng dụng mới đọc được nó.

Ghép lại: A record cho mỗi server + HTTP health check.

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

Đáp án đúng theo tệp là B — "An A record for each server with an Amazon Route 53 HTTP health check".

• A record cho mỗi server: server on-premises được Route 53 nhìn thấy như một địa chỉ IP công khai bình thường, nên mỗi server (active và passive) có một A record trỏ tới IP của nó. Đây là điều kiện để dựng cấu hình failover: một record giữ vai trò primary, một record giữ vai trò secondary, cùng tên miền.
• HTTP health check: Route 53 tự gửi request HTTP tới endpoint và coi là healthy khi nhận về status code thuộc dải 2xx (hoặc 3xx). Đây đúng là điều kiện mà đề nêu. Khi primary fail health check, Route 53 ngừng trả record đó và trả record của server passive — chính là hành vi "all other traffic should be directed to the secondary passive server".

Cặp A record + HTTP health check là cấu hình duy nhất trong danh sách vừa dùng được với hạ tầng ngoài AWS, vừa đánh giá được đúng tiêu chí status code mà đề đặt ra.

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

• A — Alias record, evaluate target health = yes, kèm HTTP health check. Vế health check thì đúng, nhưng vế record type hỏng: alias record không tạo được cho website on-premises. Alias là kiểu record riêng của Route 53 dùng để trỏ tới tài nguyên AWS được hỗ trợ; một máy chủ ở trung tâm dữ liệu riêng không phải target hợp lệ. Ngoài ra, evaluate target health là cơ chế để Route 53 kế thừa tình trạng sức khoẻ từ chính tài nguyên AWS đích — với endpoint ngoài AWS thì không có gì để kế thừa. Đây là phương án gần đúng nhất, và nó rơi đúng vào cái bẫy "chọn health check đúng nhưng quên mất hạ tầng nằm ở đâu".

• C — A record cho mỗi server, kèm TCP health check. Vế record type thì đúng, nhưng health check sai: TCP health check chỉ kiểm tra Route 53 có thiết lập được kết nối TCP tới IP và port hay không. Nó không gửi request HTTP nên không bao giờ đọc được status code. Hậu quả thực tế rất đáng nhớ: web server còn sống, cổng vẫn mở, nhưng ứng dụng trả về 5xx — TCP health check vẫn báo healthy và Route 53 vẫn đẩy người dùng vào server hỏng. Đề nói rõ tiêu chí là 2xx, nên TCP không đáp ứng được.

• D — Alias record, evaluate health = yes, kèm TCP health check. Sai cả hai vế cùng lúc: alias record không dùng được cho endpoint on-premises (như phân tích ở A), và TCP health check không đánh giá được status code (như ở C). Đây là phương án xa yêu cầu nhất.

📌 Điểm cần nhớ

• Alias record chỉ dành cho tài nguyên AWS. Thấy đề nhắc "on-premises", "external endpoint", "data center riêng" thì loại ngay mọi phương án có alias, và chỉ còn A record (hoặc CNAME nếu trỏ tới tên miền thay vì IP).
• Loại health check chọn theo tiêu chí mà đề nêu: nói tới HTTP status code, đường dẫn kiểm tra, hay nội dung phản hồi → HTTP/HTTPS health check; chỉ nói "cổng còn mở", "kết nối được" → TCP health check là đủ.
• TCP health check không phát hiện được lỗi ở tầng ứng dụng. Cổng mở mà ứng dụng trả lỗi thì vẫn bị chấm là healthy — đây là lý do đề thi hay dùng nó làm phương án nhiễu.
• Failover trong Route 53 cần hai record cùng tên, một primary một secondary, và bản thân health check gắn vào record là thứ quyết định khi nào traffic chuyển sang bên passive.

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

Đội bảo mật lo về tính toàn vẹn của log CloudTrail, và yêu cầu được viết rất cụ thể: "keep a record of any deletions or modifications to the log files" — tức là phải phát hiện và chứng minh được rằng file log đã bị sửa hay bị xoá sau khi CloudTrail giao nó vào S3.

Cụm từ quyết định là "deletions or modifications to the log files". Nó chia bài toán làm hai vế:

• Phát hiện thay đổi sau khi log đã được giao → cần cơ chế băm/ký số trên chính file log.
• Ngăn việc xoá vĩnh viễn một cách dễ dàng → cần thêm rào chắn trên bucket S3 chứa log.

Đề hỏi (Select TWO), nên đáp án phải phủ được cả hai vế đó chứ không phải hai cách làm cùng một việc. Một chi tiết nữa cần bám: đối tượng cần bảo vệ là CloudTrail log files nằm trong S3 bucket, không phải log stream trong CloudWatch Logs — đây chính là chỗ đề gài bẫy.

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

D — Enable CloudTrail log file integrity validation. Đây là tính năng có sẵn của CloudTrail, bật lên thì CloudTrail sẽ tạo thêm các digest file định kỳ, chứa giá trị băm SHA-256 của từng file log đã giao trong khoảng thời gian đó, và ký số các digest file bằng SHA-256 with RSA. Nhờ vậy, muốn biết một file log có bị sửa, bị xoá hay còn nguyên vẹn kể từ lúc CloudTrail giao nó, bạn dùng AWS CLI để validate tại chính vị trí lưu log. Sửa hoặc giả mạo mà không bị phát hiện là điều không khả thi về mặt tính toán. Đúng chính xác vế "keep a record of modifications".

B — Enable Amazon S3 MFA Delete for the CloudTrail S3 bucket. MFA Delete bắt buộc phải có yếu tố xác thực thứ hai khi ai đó muốn đổi trạng thái versioning của bucket hoặc xoá vĩnh viễn một object version. Kể cả khi kẻ tấn công đã chiếm được mật khẩu của một IAM user có quyền xoá object trong S3, họ vẫn không xoá sạch được log nếu không có mã MFA. Đây là lớp bảo vệ trực tiếp cho vế "deletions".

Hai phương án bổ sung cho nhau: D cho bạn bằng chứng log bị đụng vào, B dựng rào trước hành vi xoá vĩnh viễn.

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

A — Enable the CloudTrail log file integrity check in AWS Config Rules. Đây là phương án gần đúng nhất và cũng dễ mắc nhất, vì nội dung tính năng thì đúng — chỉ sai chỗ bật nó. Log file integrity validation là một thiết lập của chính CloudTrail (bật trên trail), không phải một rule bạn cấu hình trong AWS Config. AWS Config theo dõi cấu hình tài nguyên và đánh giá tuân thủ, nó không phải nơi sinh ra digest file hay chữ ký số cho log. So sánh A với D là kiểu bẫy "đúng tính năng, sai dịch vụ".

C — Add an SNS notification to CloudWatch Logs for any delete actions. Sai đối tượng. CloudWatch Logs là dịch vụ khác với CloudTrail; thứ cần bảo vệ ở đây là các file log CloudTrail giao vào S3. Ngoài ra, một thông báo SNS chỉ báo cho bạn biết có chuyện gì đó xảy ra, nó không tạo ra bằng chứng mật mã học để chứng minh file cụ thể nào đã bị sửa, cũng không ngăn được hành vi xoá.

E — Restrict all access to the CloudTrail S3 bucket. Nghe rất "bảo mật" nhưng không đáp ứng yêu cầu. Chặn toàn bộ truy cập là quá tay: nó cắt luôn cả các truy cập hợp lệ (đội bảo mật đọc log, công cụ phân tích, quy trình audit), trong khi vẫn không hề tạo ra bản ghi nào về việc file bị sửa hay bị xoá. Yêu cầu của đề là "keep a record", còn E chỉ là siết quyền — sai mục tiêu, lại gây thiệt hại vận hành.

📌 Điểm cần nhớ

• Hễ đề nói tới "log file integrity", "chứng minh log không bị sửa", "phát hiện log bị xoá/thay đổi" đối với CloudTrail → nghĩ ngay tới CloudTrail log file integrity validation (digest file + băm SHA-256 + chữ ký số), và nhớ nó được bật trong CloudTrail, không phải trong AWS Config.
• Hễ đề nói tới ngăn xoá vĩnh viễn object trong S3 kể cả khi credential bị lộ → MFA Delete (đi kèm versioning trên bucket).
• Phân biệt rõ CloudTrail (ghi lại lời gọi API, giao log ra S3) và CloudWatch Logs (nơi chứa và theo dõi log stream). Phương án đổi tên dịch vụ trong khi giữ nguyên mô tả tính năng là bẫy rất phổ biến.
• Thông báo (SNS) không thay thế được bằng chứng toàn vẹn, và chặn hết quyền truy cập không phải là kiểm soát tốt — với câu hỏi dạng "keep a record", hãy chọn phương án tạo ra bản ghi/bằng chứng, chứ không chọn phương án chỉ siết chặt hoặc chỉ cảnh báo.

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

Đề mô tả các EC2 instance nằm trong private subnet, và đặt ra hai ràng buộc kéo ngược chiều nhau:

• "must be restricted from the internet for security and compliance reasons" — không được có đường ra/vào Internet.
• "The SysOps team must be able to manage the instances from the corporate office using the SSH protocol" — vẫn phải SSH được vào từ văn phòng công ty.

Cụm từ quyết định là "from the corporate office" đi kèm "restricted from the internet". Nó nói rằng nguồn truy cập là một mạng riêng đã biết trước (mạng văn phòng), chứ không phải "từ bất kỳ đâu trên Internet". Khi nguồn truy cập là một site cố định và đường đi không được đi qua Internet ở dạng công khai, thì thứ cần dựng là một site-to-site VPN nối mạng văn phòng với VPC — chứ không phải mở thêm lối vào từ Internet.

Chữ (Select TWO) cũng là gợi ý về cấu trúc câu trả lời: một site-to-site VPN cần hai nửa — phía AWS (gắn gateway vào VPC và sửa route table) và phía kết nối (thiết lập đường VPN về customer gateway ở văn phòng). Hai phương án đúng chính là hai nửa đó.

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

Đáp án theo tệp là B và C.

• B — Attach a virtual private gateway to the VPC and configure routing. Virtual private gateway là điểm đầu cuối phía AWS của một AWS Site-to-Site VPN. Gắn nó vào VPC mới có chỗ để terminate đường VPN, và phải sửa route table của private subnet để lưu lượng hướng về dải mạng văn phòng đi qua gateway này. Thiếu bước routing thì đường hầm có dựng lên cũng không có gói tin nào đi đúng hướng.
• C — Configure a VPN connection back to the corporate office. Đây là nửa còn lại: khai báo customer gateway đại diện cho thiết bị VPN ở văn phòng và tạo VPN connection giữa nó với virtual private gateway. Sau khi đường hầm hoạt động, SysOps team SSH tới private IP của EC2 instance như thể đang ở trong cùng một mạng — instance không cần public IP, VPC không cần lối ra Internet, nên cả yêu cầu quản trị lẫn yêu cầu compliance đều được thoả.

Hai phương án này không thay thế nhau mà bổ sung cho nhau, đúng với yêu cầu "combination of actions".

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

• A — Configure a Network Load Balancer in front of the EC2 instances. NLB hoạt động ở tầng 4 nên về lý thuyết có thể chuyển tiếp cổng 22, và đây là phương án dễ bị chọn nhầm nhất. Chỗ nó hỏng: NLB chỉ giải quyết việc phân phối kết nối, không tạo ra đường kết nối riêng giữa văn phòng và VPC. Muốn văn phòng chạm được tới NLB từ bên ngoài thì phải dùng internet-facing NLB — tức là mở đúng thứ mà đề cấm. Còn nếu là internal NLB thì vẫn cần một đường riêng để tới được, và đường đó chính là VPN — nghĩa là NLB không đóng góp gì cho việc thoả yêu cầu.
• D — Attach an internet gateway to the VPC and configure routing. Internet gateway tồn tại để cho lưu lượng đi vào/ra Internet — mâu thuẫn trực tiếp với "restricted from the internet". Thêm nữa, Site-to-Site VPN không cần internet gateway trong VPC: đường hầm terminate ở virtual private gateway, phía Internet công cộng chỉ nằm giữa customer gateway và endpoint của AWS, không cần IGW gắn vào VPC.
• E — Attach a NAT gateway to the VPC and configure routing. NAT gateway cho phép instance trong private subnet khởi tạo kết nối ra Internet (tải bản vá, gọi API công khai) nhưng không cho phép kết nối từ ngoài đi vào. Vậy nó vừa không mở được đường SSH từ văn phòng vào, vừa cấp cho instance đúng lối ra Internet mà đề yêu cầu chặn — sai ở cả hai vế.

📌 Điểm cần nhớ

• Đề nói "restricted from the internet" là gạch ngay internet gateway và NAT gateway, bất kể phần còn lại của kịch bản là gì; NAT gateway chỉ mở chiều đi ra, không bao giờ mở chiều đi vào.
• Truy cập private subnet từ một site cố định (corporate office, data center) là mô hình của Site-to-Site VPN, gồm hai mảnh bắt buộc: virtual private gateway + routing ở phía VPC, và VPN connection tới customer gateway ở phía văn phòng. Câu hỏi kiểu (Select TWO) thường chấm đúng hai mảnh này.
• Site-to-Site VPN không đòi hỏi internet gateway gắn vào VPC — đây là bẫy hay gặp.
• Load balancer giải quyết bài toán phân phối kết nối, không giải quyết bài toán đường kết nối riêng. Thấy yêu cầu "không qua Internet" thì đừng chọn load balancer làm cơ chế truy cập.

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

Đề mô tả một SysOps engineer dùng AWS CloudFormation StackSets để triển khai tài nguyên ra nhiều Region trong cùng một AWS account. Ở một Region, thao tác stack thất bại (unsuccessful) và stack instance mang trạng thái OUTDATED. Câu hỏi: nguyên nhân chính là gì?

Cụm từ quyết định đáp án là "a stack operation is unsuccessful" đi kèm "reflecting an OUTDATED status". Hai vế này phải đọc chung với nhau. Đề không hỏi "OUTDATED nghĩa là gì" — đề hỏi vì sao thao tác thất bại, còn OUTDATED chỉ là hệ quả được ghi nhận trên stack instance đó. Chi tiết thứ hai cũng quan trọng: "across multiple AWS Regions within a single AWS account" — chỉ có một account, nhiều Region. Điều này loại bỏ ngay nhóm nguyên nhân liên quan tới nhiều account (sai số hiệu target account, thiếu trust relationship giữa administrator account và target account), và đẩy trọng tâm về nhóm nguyên nhân nội tại của template.

Khi cùng một template được deploy song song ra nhiều Region trong cùng một account, thứ dễ vỡ nhất chính là global resource — tài nguyên có không gian tên toàn cục chứ không giới hạn theo Region. Đó là mấu chốt.

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

Đáp án đúng theo tệp là A — "The CloudFormation template is trying to create a global resource that is not unique".

Tài liệu AWS liệt kê nhiều nguyên nhân phổ biến khiến một stack operation của StackSets thất bại, và một trong số đó là: template cố tạo global resource bắt buộc phải duy nhất nhưng lại không duy nhất, ví dụ S3 bucket. Tên S3 bucket là global — duy nhất trên toàn bộ AWS, không phải duy nhất theo từng Region. Cũng vậy với các tài nguyên IAM (IAM role, IAM user), vốn là tài nguyên global của account.

Ghép với ngữ cảnh đề: cùng một template chạy ra nhiều Region trong một account duy nhất. Region đầu tiên tạo bucket (hoặc IAM role) với tên hard-code thành công; Region kế tiếp chạy đúng template đó, cố tạo lại tài nguyên cùng tên trong cùng không gian tên global → xung đột tên → stack operation ở Region đó thất bại. Đây chính là kịch bản mà đề vẽ ra: chỉ một Region hỏng, các Region khác thì không. Các nguyên nhân khác trong danh sách của AWS (thiếu quyền, template sai cú pháp, chạm hạn mức) thường hỏng ở mọi Region hoặc không phụ thuộc vào việc deploy đa Region, nên không giải thích được cái "one specific Region" của đề bằng A.

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

B — "The AWS CLI version being used by the SysOps administrator is deprecated." Sai. Phiên bản AWS CLI ở phía client không quyết định kết quả của một stack operation chạy phía dịch vụ CloudFormation. CLI cũ nhiều lắm là thiếu tham số mới hoặc báo lỗi ngay lúc gọi lệnh; nó không khiến một stack instance mang trạng thái OUTDATED. Đây là phương án đánh lạc hướng bằng chữ "outdated/deprecated" — chơi chữ giữa "CLI lỗi thời" và trạng thái "OUTDATED", chứ không có quan hệ nhân quả nào.

C — "The stack instance in the affected Region has not yet been brought up to date with the latest modifications in the StackSets template." Đây là phương án gần đúng nhất và bẫy nặng nhất, vì nó đọc rất giống nghĩa đen của từ "OUTDATED". Nhưng nó hỏng ở chỗ định nghĩa: trong StackSets, OUTDATED không có nghĩa là "chưa kịp cập nhật template mới nhất". Theo tài liệu AWS, trạng thái này phản ánh việc stack đang được StackSets quản lý nhưng đã không còn đồng bộ với stack set — điển hình là do có thao tác tác động trực tiếp lên stack thay vì đi qua stack set, hoặc do thao tác trên stack instance đó thất bại. Nói cách khác, C mô tả lại triệu chứng bằng cách suy diễn từ tên trạng thái, chứ không nêu nguyên nhân làm thao tác thất bại — trong khi đề hỏi đúng phần nguyên nhân. Ngoài ra C còn tự mâu thuẫn: nếu chỉ đơn thuần là "chưa cập nhật", thì đã không có chuyện "a stack operation is unsuccessful".

D — "The CloudFormation template, which is stored locally, has been altered but not yet uploaded to AWS CloudFormation." Sai. Sửa bản sao template nằm trên máy cá nhân không hề tác động tới stack set đang tồn tại. CloudFormation chỉ làm việc với template đã được nộp lên dịch vụ; chừng nào bản sửa chưa được push lên và chưa chạy update stack set, mọi thứ vẫn chạy theo template cũ. Trạng thái này không sinh ra lỗi, cũng không sinh ra OUTDATED — nó chỉ đơn giản là chưa có gì xảy ra cả.

📌 Điểm cần nhớ

• Global resource là điểm vỡ kinh điển khi StackSets deploy ra nhiều Region trong cùng một account. S3 bucket name và các tài nguyên IAM không có không gian tên riêng theo Region, nên hard-code tên trong template là bảo đảm xung đột từ Region thứ hai trở đi. Cách né là để CloudFormation tự sinh tên, hoặc ghép thêm biến phân biệt theo Region vào tên.
• Đừng suy nghĩa của status code StackSets từ nghĩa tiếng Anh thông thường. OUTDATED trong StackSets nói về việc stack lệch khỏi stack set (thường do bị đụng trực tiếp, hoặc do thao tác thất bại), không phải "chưa cài bản template mới nhất". Đây là chỗ đề thi hay gài.
• Đọc kỹ phạm vi deploy: multi-Region trong một account, hay multi-account. Cùng danh sách nguyên nhân của AWS, nhưng nhóm nguyên nhân về trust relationship và target account number chỉ áp dụng cho kịch bản nhiều account; nêu chúng ra khi đề chỉ có một account là lạc đề.
• Phân biệt "nguyên nhân" với "mô tả lại triệu chứng". Khi đề hỏi why, phương án chỉ diễn giải lại chính trạng thái đang được nêu trong đề gần như luôn là bẫy — hãy tìm phương án nói được điều gì đó mới về gốc rễ.

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

Đề mô tả một yêu cầu kiểm toán: quản lý cần báo cáo chi tiết toàn bộ hoạt động API của một người dùng cụ thể trong vài tháng qua, và tài khoản đã bật AWS CloudTrail. Câu hỏi kết lại bằng "What is the MOST efficient method".

Có hai cụm từ quyết định đáp án, phải đọc cùng nhau:

• "over the last several months" — khoảng thời gian nhiều tháng. Đây là ràng buộc quan trọng nhất, vì phần Event history xem trực tiếp trên console của CloudTrail chỉ giữ lịch sử sự kiện trong một cửa sổ thời gian gần đây (tính bằng ngày, không phải tháng). Dữ liệu cũ hơn cửa sổ đó chỉ còn tồn tại ở nơi trail ghi ra, tức là bucket S3.
• "MOST efficient" — không hỏi "cách nào làm được", mà hỏi cách nào hiệu quả nhất. Với dữ liệu nhiều tháng nằm rải trong hàng nghìn tệp log nén trên S3, cách hiệu quả là truy vấn tại chỗ chứ không tải về xử lý thủ công.

Ghép hai ràng buộc: nguồn dữ liệu phải là CloudTrail logs trong S3, và công cụ phải là thứ truy vấn trực tiếp trên S3.

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

B — Tìm CloudTrail logs trong S3 bucket tương ứng, dùng Amazon Athena để trích xuất thông tin lập báo cáo.

Khi một trail được bật, CloudTrail ghi log sự kiện dạng JSON (nén) vào S3 bucket và giữ ở đó theo vòng đời do chính bạn đặt — nên dữ liệu vài tháng trước vẫn còn nguyên, khác với event history trên console.

Amazon Athena là dịch vụ truy vấn serverless đọc thẳng dữ liệu nằm trong S3 bằng SQL, không cần nạp dữ liệu vào kho nào khác, không cần dựng hạ tầng. Với CloudTrail, đây là cách dùng chuẩn: tạo bảng trỏ vào tiền tố S3 chứa log, rồi lọc theo trường định danh người gọi (useridentity) và mốc thời gian, GROUP BY theo eventname để ra bảng thống kê. Giải thích gốc minh hoạ đúng mô hình này bằng một truy vấn liệt kê các sự kiện hàng đầu do root khởi tạo từ đầu năm, và nói rõ: với tình huống này chỉ cần thay root bằng tên người dùng cần audit.

Một câu SQL cho ra đúng báo cáo cần thiết trên toàn bộ dải nhiều tháng — đó là định nghĩa của "most efficient" ở đây.

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

A — Console, tìm theo user name trong CloudTrail history rồi lọc theo API, tải CSV. Đây là phương án gần đúng nhất và cũng là bẫy chính: thao tác này có thật, làm được, và xuất được CSV. Nó hỏng ở hai chỗ. Thứ nhất, Event history trên console chỉ soi được cửa sổ sự kiện gần đây, không phủ hết "vài tháng qua" như đề yêu cầu — phần dữ liệu cũ đơn giản là không có ở đó. Thứ hai, kể cả trong phạm vi xem được, console chỉ cho lọc theo một thuộc tính tại một thời điểm và phải bấm/tải nhiều lần rồi ghép tay, nên không thể là cách hiệu quả nhất.

C — Dùng CloudTrail digest files trong S3 rồi đẩy sang Amazon QuickSight. Sai ngay ở nguồn dữ liệu. Digest file không chứa nội dung sự kiện API; nó là tệp phục vụ tính năng log file validation, ghi lại danh sách tệp log của một khoảng thời gian kèm giá trị băm để chứng minh log không bị sửa đổi sau khi giao. Lấy digest ra dựng báo cáo hoạt động của người dùng là lấy nhầm tệp — bạn sẽ có bằng chứng toàn vẹn chứ không có một dòng nào về việc user đó gọi API gì. QuickSight ở đây không cứu được, vì đầu vào đã sai.

D — Console, tìm theo API activity rồi lọc theo user name, tải CSV. Đây chính là A với thứ tự thao tác đảo ngược. Cùng một công cụ, cùng một giới hạn cửa sổ thời gian, cùng cách làm thủ công nhiều bước — nên hỏng y hệt A. Việc lọc theo API trước hay theo user name trước không thay đổi bản chất: dữ liệu nhiều tháng không nằm trong event history, và console không phải cách hiệu quả nhất.

📌 Điểm cần nhớ

• Phân biệt hai nguồn dữ liệu của CloudTrail: Event history trên console dùng để tra cứu nhanh sự kiện gần đây; log files trong S3 bucket mới là nơi lưu trữ dài hạn. Đề nhắc "vài tháng", "cả năm", "lịch sử dài" → nguồn phải là S3.
• CloudTrail logs trong S3 + Athena là cặp đôi kinh điển cho phân tích/kiểm toán: truy vấn SQL trực tiếp trên S3, serverless, không cần di chuyển dữ liệu — thường là đáp án khi đề nhấn "efficient", "detailed report", "analyze", "query".
• Digest file ≠ log file: digest chỉ để xác minh tính toàn vẹn (log file validation) của các tệp log đã giao, không dùng để phân tích hoạt động.
• Khi hai phương án chỉ khác nhau ở thứ tự thao tác (như A và D ở đây), gần như chắc chắn cả hai đều sai — người ra đề tách chúng ra để chia phiếu, còn điểm hỏng thật nằm ở công cụ hoặc nguồn dữ liệu chung của cả hai.

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

Đề mô tả một web bán hàng dùng Amazon ElastiCache for Memcached để lưu dữ liệu hay được truy cập. Hiệu năng kém suốt vài tuần, người dùng phàn nàn. Hai cụm từ trong đề quyết định đáp án:

• "the metric data for the Amazon EC2 instances and the Amazon RDS instance appear normal" — đề đã tự tay loại lớp compute và lớp database ra khỏi diện nghi vấn. Bất kỳ phương án nào đụng tới RDS đều bị chính câu này bác bỏ.
• "the eviction count metrics are high" — đây mới là ràng buộc chính. Eviction trong Memcached xảy ra khi cache đã đầy bộ nhớ mà vẫn cần chỗ cho item mới, nên engine phải đẩy (evict) item cũ ra theo chính sách thay thế. Eviction cao = thiếu memory, không phải thiếu CPU, không phải thiếu throughput đọc.

Vậy câu hỏi thực chất là: "Làm sao tăng dung lượng bộ nhớ cho một Memcached cluster?" Cả bốn phương án đều là "scale" một thứ gì đó — cái phân biệt chúng là scale đúng tài nguyên đang thiếu, trên đúng lớp đang có vấn đề.

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

C — Scale the Memcached cluster by adding additional nodes.

Memcached trong ElastiCache là kiến trúc phân mảnh (sharded): dữ liệu được rải qua các node bằng thuật toán hashing ở phía client, và tổng bộ nhớ của cluster bằng tổng bộ nhớ các node cộng lại. Thêm node vào cluster (horizontal scaling) làm tăng trực tiếp tổng dung lượng cache khả dụng.

Khi tổng memory tăng, tập dữ liệu nóng (working set) có chỗ nằm trọn trong cache, engine không còn phải liên tục đẩy item cũ ra để nhường chỗ → eviction count giảm, tỷ lệ cache hit tăng, số request phải rơi xuống RDS giảm, và độ trễ mà người dùng cảm nhận trở lại bình thường. Đây đúng là cách xử lý nguyên nhân gốc mà chỉ số eviction đang chỉ ra.

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

A — Adding read replicas. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi, nhưng nó hỏng ở chỗ căn bản: Memcached không có khái niệm read replica. Replica là đặc trưng của engine Redis trong ElastiCache (primary + replica, có replication, có failover). Memcached chỉ có các node độc lập, không nhân bản dữ liệu cho nhau. Phương án này mô tả một thao tác không tồn tại trên engine mà đề đang dùng. Ngay cả khi giả sử có, replica là để tăng khả năng đọc, không tăng dung lượng lưu trữ cho dữ liệu duy nhất — vẫn không chạm tới nguyên nhân eviction.

B — Increasing CPU capacity. Đúng lớp (Memcached) nhưng sai tài nguyên. Tăng CPU giúp khi node bị nghẽn xử lý — biểu hiện qua chỉ số CPU utilization cao. Ở đây đề không hề nói CPU cao; nó nói eviction cao. Eviction là hệ quả của giới hạn bộ nhớ, thêm bao nhiêu CPU cũng không tạo ra thêm một byte nào để chứa dữ liệu, nên eviction vẫn tiếp diễn y nguyên. (Lưu ý sắc thái: chuyển sang node type lớn hơn thì thường tăng cả CPU lẫn memory, nhưng phương án này cố ý chỉ nêu CPU — đó là điểm nó bị loại.)

D — Changing the RDS instance type. Bị chính đề bài bác bỏ trực tiếp: metric của RDS đang bình thường. Scale một thành phần không có dấu hiệu quá tải là tốn tiền mà không giải quyết được gì, và vấn đề ở lớp cache vẫn còn nguyên. Đây là kiểu phương án "chữa triệu chứng ở sai tầng" — nhìn thấy chậm là nghĩ ngay tới database, trong khi dữ liệu quan trắc đã chỉ đúng vào lớp cache.

📌 Điểm cần nhớ

• Ánh xạ metric → tài nguyên: Evictions cao ⇒ thiếu memory. CPUUtilization cao ⇒ thiếu CPU. CacheMisses cao mà không có eviction ⇒ vấn đề ở chiến lược caching / TTL. Đề thi thường cho sẵn đúng một metric bất thường — đó chính là chỉ dẫn chọn đáp án.
• Phân biệt Memcached và Redis trong ElastiCache: Memcached scale ngang bằng cách thêm node, dữ liệu phân mảnh, tổng memory là tổng các node, không có replica, không có persistence, không có failover. Read replica / replication group là chuyện của Redis. Phương án nào gán tính năng Redis cho Memcached là sai ngay lập tức.
• Khi đề nói rõ metric của một lớp là "normal", hãy loại hết phương án động vào lớp đó. Câu chữ đó không phải nền cảnh — nó là bộ lọc mà người ra đề đặt vào để thu hẹp lựa chọn.
• Scale phải đúng chiều: thêm node (horizontal) để tăng tổng dung lượng cache, đổi sang node type lớn hơn (vertical) khi từng node thiếu tài nguyên. Nhận diện đúng nút thắt trước khi quyết định scale theo chiều nào.