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

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

Đề mô tả một AWS Storage Gateway kiểu volume gateway chạy trên máy ảo, phục vụ ổ đĩa qua iSCSI, và người dùng than phiền hiệu năng giảm. Câu hỏi chốt bằng "What steps are MOST likely to resolve the performance issues?" — tức là phải chọn hành động nhắm đúng nguyên nhân mà dữ liệu đo được đang chỉ ra, chứ không phải một cách tối ưu chung chung nào đó.

Cụm từ quyết định đáp án nằm ở hai chỉ số CloudWatch:

• CacheHitPercent dưới 55% — hơn một nửa số yêu cầu đọc không tìm thấy dữ liệu trong cache cục bộ, phải đi lấy từ Amazon S3, mà đi qua Internet/WAN thì độ trễ cao hơn đọc đĩa cục bộ rất nhiều.
• CachePercentUsed trên 95% — cache cục bộ gần như đầy.

Hai con số đi cùng nhau kể một câu chuyện duy nhất: đây là cached volume configuration (dữ liệu chính nằm trên S3, đĩa cục bộ chỉ giữ bản sao dữ liệu hay dùng), và dung lượng cache không đủ so với khối lượng dữ liệu đang được truy cập. Cache đầy nên phải liên tục đẩy dữ liệu cũ ra để nhường chỗ, dẫn tới tỷ lệ trúng cache thấp. Đây không phải triệu chứng của lỗi mạng, lỗi đĩa hay lỗi cấu hình iSCSI.

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

Đáp án đúng theo tệp là D — tạo một đĩa lớn hơn cho cached volume, rồi vào AWS Management Console chỉnh phần local disks và chọn đĩa mới làm cache.

Chỉ số đo được nói rằng cache thiếu dung lượng để phục vụ lượng yêu cầu đang nhận. Cách chữa đúng bản chất là làm cache to hơn: khi cache rộng ra, CachePercentUsed giảm xuống (có chỗ trống), nhiều dữ liệu nóng được giữ lại lâu hơn nên CacheHitPercent tăng lên. Càng nhiều yêu cầu được phục vụ ngay từ đĩa cục bộ qua iSCSI thì càng ít lần phải kéo dữ liệu về từ S3 — đúng thứ đang làm người dùng thấy chậm.

Về mặt thao tác, Storage Gateway cho phép gán thêm đĩa cục bộ của máy ảo làm cache và cấu hình lại vai trò của các local disk từ console. Đây là điều chỉnh cấu hình đúng tầng nơi vấn đề xảy ra, không cần dựng lại gateway hay đụng tới dữ liệu trên S3.

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

A — Tối ưu cấu hình iSCSI trên initiator để đạt I/O cao hơn. Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì triệu chứng người dùng thấy đúng là "ổ iSCSI chậm". Nhưng tinh chỉnh initiator chỉ giúp khi nghẽn nằm ở chính lớp giao thức iSCSI. Ở đây CloudWatch đã chỉ đích danh thủ phạm: cache đầy và tỷ lệ trúng cache thấp. Có chỉnh initiator tối ưu đến đâu thì mỗi lần cache miss vẫn phải chờ dữ liệu về từ S3 — nút thắt không nằm ở chỗ được tối ưu, nên hiệu năng gần như không cải thiện.

B — Tạo recovery snapshot từ volume rồi triển khai, kích hoạt một volume gateway mới từ snapshot đó. Recovery snapshot là quy trình dành cho tình huống gateway hỏng hoặc dữ liệu cần khôi phục. Trong đề không có dấu hiệu nào của hỏng hóc: volume vẫn hoạt động, vẫn phục vụ được yêu cầu, chỉ là chậm. Dựng lại một gateway mới với cùng kích thước cache sẽ tái lập y nguyên vấn đề, đổi lại là công sức và thời gian gián đoạn hoàn toàn vô ích.

C — Đảm bảo đĩa vật lý của Storage Gateway ở cấu hình RAID 1 để có throughput cao hơn. Sai ở ngay tiền đề kỹ thuật: RAID 1 là mirroring — ghi cùng dữ liệu lên hai đĩa để chịu lỗi, chứ không phải để tăng hiệu năng. Nó cũng không làm cache lớn thêm: hai đĩa mirror nhau thì dung lượng khả dụng vẫn bằng một đĩa. Vậy nên phương án này vừa không nhắm đúng nguyên nhân (dung lượng cache), vừa hiểu sai tác dụng của chính cấu hình mà nó đề xuất.

📌 Điểm cần nhớ

• Với volume gateway ở chế độ cached volume, dữ liệu chính nằm trên S3 còn đĩa cục bộ chỉ là cache — mọi cache miss đều biến thành một chuyến đi lấy dữ liệu từ S3, và đó là nguồn gốc phổ biến nhất của "iSCSI chậm".
• Cặp chỉ số CacheHitPercent thấp + CachePercentUsed cao là chữ ký kinh điển của cache quá nhỏ. Thấy cặp này thì hướng xử lý là tăng dung lượng cache, không phải đi tinh chỉnh giao thức hay dựng lại hệ thống.
• Khi đề đã cung cấp số liệu CloudWatch cụ thể, hãy để số liệu đó dẫn đường: phương án đúng phải tác động trực tiếp lên chỉ số đang bất thường. Các phương án "tối ưu chung chung" nghe hợp lý nhưng không chạm tới nút thắt đã được chỉ ra thì loại.
• Phân biệt rõ mục đích của từng cơ chế: RAID 1 dùng cho dự phòng, không phải tăng tốc; recovery snapshot dùng cho khôi phục sau sự cố, không phải để chữa hiệu năng. Đề nào gán sai mục đích cho một cơ chế thì phương án đó loại được ngay mà không cần đọc tiếp.

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

Đề mô tả một công ty có security and compliance policy quy định chỉ một số AMI nhất định được phép dùng trong các AWS account. SysOps Administrator cần review existing Amazon EC2 instances để biết chúng có tuân thủ chính sách đó không.

Cụm từ quyết định nằm ở hai chỗ:

• "compliance policy" / "in compliance with this policy" — đây là bài toán đánh giá tuân thủ cấu hình tài nguyên, tức là so trạng thái thực tế của resource với một quy tắc do mình định nghĩa.
• "existing EC2 instances" — phải kiểm tra các instance đang chạy, liên tục, chứ không phải chặn lúc tạo mới hay xem một báo cáo tĩnh.

Ghép hai cụm này lại thì câu hỏi đang mô tả gần như đúng định nghĩa của một AWS Config rule: định nghĩa quy tắc → Config đánh giá resource → đánh dấu COMPLIANT / NON_COMPLIANT.

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

B — Create an AWS Config rule to check that approved AMI IDs have been used.

AWS Config làm hai việc: ghi lại inventory và thay đổi cấu hình của tài nguyên AWS, và chạy Config rules để xác nhận tài nguyên có được cấu hình đúng với chính sách bạn định nghĩa hay không.

Với đúng tình huống này, Config có rule kiểm tra running EC2 instances có đang dùng AMI được duyệt hay không. Danh sách AMI được duyệt khai báo theo AMI ID, hoặc khai báo bằng tag để chỉ ra nhóm AMI ID hợp lệ. Kết quả là mỗi instance được đánh dấu tuân thủ hoặc không tuân thủ, đúng thứ mà một compliance review cần — có sẵn, không phải viết code, và là công cụ chuyên trách cho báo cáo tuân thủ.

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

A — Custom report bằng AWS Systems Manager Inventory. Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất. Systems Manager Inventory đúng là thu thập metadata từ các managed instance, nên về lý thuyết bạn có dữ liệu để đối chiếu. Nhưng nó hỏng ở chỗ: Inventory chỉ thu thập và liệt kê, phần "so với danh sách AMI được duyệt và kết luận tuân thủ hay không" vẫn phải bạn tự làm bằng report tùy biến. Trong khi đó AWS Config đã cung cấp sẵn chính thông tin đó dưới dạng kết quả tuân thủ — đây là công cụ nên dùng cho compliance reporting. Chọn A là tự dựng lại thứ đã có.

C — Viết AWS Lambda function tự kiểm tra AMI. Về mặt kỹ thuật thì làm được: gọi API mô tả instance, đọc AMI ID, so với danh sách. Nhưng nó phức tạp hơn và không cần thiết khi AWS Config đã trả về đúng dữ liệu này. Bạn phải tự lo trigger, tự lo phân trang, tự lo lưu kết quả và báo cáo — toàn bộ là code phải bảo trì để thay cho một rule khai báo sẵn. Trong đề thi, khi một managed service đã giải quyết trọn vẹn yêu cầu thì phương án "tự viết Lambda" gần như luôn là phương án sai.

D — Dùng AWS Trusted Advisor để tìm EC2 workload dùng AMI chưa được duyệt. Sai vì đây không phải chức năng của Trusted Advisor. Trusted Advisor đưa ra khuyến nghị theo các hạng mục chung của nó, chứ không cho phép bạn nạp vào một danh sách AMI được duyệt của riêng công ty rồi đánh giá theo danh sách đó. Chính sách ở đây là chính sách nội bộ, do công ty tự định nghĩa — Trusted Advisor không có chỗ để khai báo thứ như vậy.

📌 Điểm cần nhớ

• Thấy "compliance policy" + kiểm tra cấu hình của tài nguyên đang tồn tại → nghĩ ngay tới AWS Config rule. Đó là dịch vụ chuyên đánh giá tài nguyên so với quy tắc do người dùng định nghĩa.
• Phân biệt Systems Manager Inventory (thu thập metadata của instance) với AWS Config (đánh giá tuân thủ và theo dõi thay đổi cấu hình). Cả hai đều "biết" thông tin, nhưng chỉ Config kết luận được COMPLIANT / NON_COMPLIANT.
• Rule kiểm tra AMI được duyệt nhận danh sách theo AMI ID hoặc theo tag — nhớ chi tiết này vì nó hay xuất hiện trong các câu hỏi biến thể.
• Phương án "viết Lambda tự kiểm tra" thường sai khi đề không nêu yêu cầu đặc biệt nào mà managed service không đáp ứng được: nó thêm code, thêm bảo trì, không thêm giá trị.
• Trusted Advisor đưa khuyến nghị theo bộ kiểm tra có sẵn của nó, không nhận chính sách tùy biến của khách hàng — gặp "chính sách riêng của công ty" thì loại nó ra.

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

Đề mô tả một tình huống rất cụ thể: static website đã được cấu hình trên Amazon S3, bucket tên là “mystaticsite”, và Route 53 có một A record cho www.mystaticsite.com. Kết quả là trình duyệt không vào được website.

Cụm từ quyết định nằm ngay ở phần dữ kiện chứ không phải ở câu hỏi: tên bucket là “mystaticsite” trong khi bản ghi DNS là “www.mystaticsite.com”. Hai chuỗi này không giống nhau. Đề cố tình đặt hai giá trị cạnh nhau để người đọc so sánh — đó là toàn bộ manh mối. Mọi phương án còn lại đều nói về những thứ mà đề không hề đề cập (region, CloudFront, certificate), nên chúng chỉ là nhiễu nếu ta bám vào dữ kiện thật sự được cho.

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

B — The S3 bucket name must match the record set name in Route 53.

Khi dùng tính năng static website hosting của S3 với một custom domain, tên bucket phải trùng khớp với tên DNS của website. Đây là ràng buộc bắt buộc của S3 website endpoint: endpoint định tuyến request dựa trên phần host trong request, nên nếu người dùng gõ www.mystaticsite.com thì bucket phục vụ nội dung đó phải có tên đúng là www.mystaticsite.com.

Muốn phục vụ cả root domain lẫn subdomain thì tạo hai bucket:

• Domain bucket — mystaticsite.com
• Subdomain bucket — www.mystaticsite.com

Trong tình huống của đề, administrator mới chỉ có bucket tên mystaticsite — không khớp với bất kỳ tên nào ở trên. Bản ghi A trong Route 53 trỏ đúng, nhưng đầu bên kia không có bucket nào mang đúng tên host đó, nên cấu hình không thể hoạt động.

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

A — The Route 53 record set must be in the same region as the S3 bucket. Đây là phương án nghe hợp lý nhất với người quen tư duy "mọi thứ trong AWS đều gắn với region", nhưng nó sai ngay ở tiền đề: Route 53 là dịch vụ global, ta không tạo record set bên trong một Region nào cả. Hosted zone và các record trong đó không có thuộc tính region để mà "khớp" với bucket. Bucket S3 thì đúng là thuộc một Region, nhưng ràng buộc region ở đây chỉ ảnh hưởng tới việc chọn đúng website endpoint khi tạo alias, chứ không phải "record set phải nằm cùng region".

C — An Amazon CloudFront distribution must be configured for the S3 bucket. CloudFront là tuỳ chọn, không bắt buộc. Bạn hoàn toàn có thể trỏ Route 53 thẳng vào S3 website endpoint và website chạy bình thường. CloudFront chỉ được thêm vào khi muốn caching ở edge, HTTPS cho custom domain, hoặc các tính năng phân phối nội dung khác. Vì nó không bắt buộc nên nó không thể là nguyên nhân khiến website không truy cập được — mà đề đang hỏi nguyên nhân.

D — The Route 53 record set requires a certificate to be configured. Sai vì certificate không gắn vào record set. Record set trong Route 53 chỉ là ánh xạ tên → đích (địa chỉ IP, alias tới tài nguyên AWS…), nó không có chỗ nào để đính kèm chứng chỉ. Chứng chỉ TLS được gắn ở tầng phục vụ nội dung — ví dụ CloudFront distribution hay load balancer — chứ không phải ở tầng DNS. Ngoài ra, đề không nói gì về HTTPS hay lỗi chứng chỉ, nên đây cũng không phải hướng mà dữ kiện chỉ tới.

📌 Điểm cần nhớ

• Với S3 static website hosting + custom domain, tên bucket phải trùng đúng tên DNS mà người dùng gõ. Phục vụ cả example.com và www.example.com thì cần hai bucket với đúng hai tên đó.
• Route 53 là dịch vụ global. Bất kỳ phương án nào nói record set "phải cùng region" với tài nguyên khác đều đáng nghi ngay từ đầu.
• Certificate không thuộc về DNS record. Nó được gắn ở tầng phục vụ nội dung (CloudFront, load balancer), nên "record set cần certificate" luôn là phương án nhiễu.
• CloudFront trước S3 website là tuỳ chọn, không phải điều kiện để website hoạt động — đừng nhầm "nên có" với "bắt buộc phải có" khi đề hỏi về nguyên nhân sự cố.
• Kỹ thuật làm bài: khi đề cho một giá trị cấu hình cụ thể (ở đây là tên bucket) cạnh một giá trị khác (tên bản ghi DNS), hãy so sánh chúng trước — thường chính chỗ lệch đó là đáp án.

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

Đề mô tả một ứng dụng phân tán chạy trên nhiều EC2 instance, xử lý khối lượng dữ liệu lớn, và hỏi mô hình giá (pricing model) nào là tiết kiệm nhất — MOST cost-effective.

Cụm từ quyết định đáp án nằm ở câu thứ hai của đề: "designed to handle processing interruptions without causing issues" — ứng dụng được thiết kế để chịu được việc bị ngắt giữa chừng mà không gây sự cố. Đây chính là điều kiện tiên quyết duy nhất để dùng Spot Instances.

Cụm phụ trợ thứ hai là "distributed application runs across many EC2 instances": công việc được chia nhỏ trên nhiều máy, nên mất một vài instance chỉ làm chậm chứ không làm hỏng cả mẻ xử lý. Còn MOST cost-effective loại bỏ mọi phương án chỉ "chấp nhận được về giá" — đề đòi mức rẻ nhất, không phải mức hợp lý.

Nói gọn: đề đã tự tay tháo bỏ nhược điểm lớn nhất của Spot (bị thu hồi capacity) rồi mới hỏi cái gì rẻ nhất. Khi đề bài chủ động khẳng định "chịu được gián đoạn", đó gần như luôn là tín hiệu chỉ thẳng vào Spot.

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

A — Spot Instances.

Spot Instances bán cho bạn phần capacity EC2 đang dư với mức giá thấp hơn hẳn On-Demand. Cái giá phải trả là AWS có quyền thu hồi instance khi cần capacity lại, và instance của bạn bị terminate (hoặc stop/hibernate tuỳ cấu hình) sau một khoảng cảnh báo ngắn.

Vì thế Spot chỉ phù hợp với workload chịu được việc bị ngắt — đúng y nguyên mô tả trong đề. Ứng dụng phân tán, xử lý dữ liệu theo lô, mất một node thì phần việc đó được giao lại cho node khác: đây là khuôn mẫu kinh điển của Spot. Trong bốn mô hình giá của EC2 được liệt kê, Spot là mô hình có đơn giá thấp nhất, nên khi ràng buộc "chịu được gián đoạn" đã được thoả mãn thì nó cũng là câu trả lời cho "MOST cost-effective".

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

B — Reserved Instances. Đây là phương án gần đúng nhất và cũng là bẫy chính. Reserved Instances thật sự giảm giá đáng kể so với On-Demand, nên nếu chỉ đọc lướt chữ "cost-effective" thì rất dễ chọn. Nhưng nó hỏng ở hai chỗ: (1) RI là cam kết dài hạn (theo kỳ hạn 1 hoặc 3 năm), hợp với workload chạy đều, ổn định, liên tục — trong khi đề chẳng nói gì về việc tải chạy đều hay kéo dài bao lâu; (2) kể cả khi cam kết, mức giảm giá của RI vẫn không sâu bằng Spot. Đề đòi MOST cost-effective chứ không phải "rẻ hơn On-Demand", nên RI thua.

C — On-Demand Instances. Đây là mức giá cơ sở, trả theo lượng dùng, không cam kết và cũng không được giảm gì. Nó là mô hình linh hoạt nhất nhưng đắt nhất trong nhóm trả-theo-dùng. Chọn nó nghĩa là bỏ phí hoàn toàn thông tin "ứng dụng chịu được gián đoạn" mà đề đã cố tình đưa vào — thông tin đó chỉ có giá trị khi bạn dùng nó để đổi lấy giá rẻ hơn.

D — Dedicated Hosts. Đây là máy chủ vật lý dành riêng cho một khách hàng. Nó tồn tại để giải quyết các nhu cầu về tuân thủ, cách ly phần cứng, hoặc mang license phần mềm theo socket/core (BYOL) — không có nhu cầu nào trong số đó xuất hiện trong đề. Đổi lại, đây là lựa chọn đắt nhất trong bốn phương án. Chọn Dedicated Hosts cho bài toán "rẻ nhất" là đi ngược hẳn yêu cầu.

📌 Điểm cần nhớ

• Đề nhắc tới "can tolerate/handle interruptions", "fault-tolerant", "batch processing", "flexible start and end time" → gần như chắc chắn là Spot Instances. Đây là cặp từ khoá ↔ đáp án đáng thuộc lòng.
• Reserved Instances gắn với workload ổn định, chạy liên tục, dự đoán được, cam kết dài hạn — không phải với "rẻ nhất trong mọi hoàn cảnh".
• On-Demand là mốc giá tham chiếu: chọn khi tải không đoán trước được và không chấp nhận bị ngắt.
• Dedicated Hosts trả lời cho câu hỏi về tuân thủ / cách ly phần cứng / license mang theo, không bao giờ là câu trả lời cho "tiết kiệm chi phí nhất".
• Khi đề dùng chữ in hoa MOST cost-effective, hãy xếp hạng các phương án theo giá chứ đừng dừng lại ở phương án đầu tiên "cũng rẻ hơn mặc định".

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

Đề mô tả một tình huống rất cụ thể: các EC2 instance nằm trong private subnet cần ra được internet, và quản trị viên đã dựng một NAT instance từ AMI amzn-ami-vpc-nat. Câu quyết định nằm ở phần liệt kê những việc đã làm rồi: "has deployed a NAT instance using an amzn-ami-vpc-nat AMI, updated security groups, and configured the appropriate route within the route table".

Cụm đó loại bỏ trước hai nghi phạm thường gặp nhất khi NAT instance không hoạt động — security group chặn traffic, và route table của private subnet chưa trỏ về NAT instance. Đề cố tình đóng hai cửa này lại để chỉ còn đúng một bước thiết lập NAT instance mà người ta hay quên: source/destination check.

Chi tiết amzn-ami-vpc-nat cũng đáng chú ý — đây là AMI dựng sẵn cho vai trò NAT, nghĩa là phần cấu hình bên trong hệ điều hành (IP forwarding, iptables masquerade) đã có sẵn. Vậy vấn đề không nằm trong OS mà nằm ở thuộc tính của chính EC2 instance ở tầng VPC.

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

C — Disable source/destination checks on the NAT instance.

Mặc định mỗi EC2 instance bật kiểm tra source/destination: instance chỉ được phép gửi và nhận những gói tin mà chính nó là nguồn hoặc là đích. Gói nào có địa chỉ nguồn/đích không phải của nó thì bị VPC loại bỏ.

Nhưng đó lại chính xác là công việc của một NAT instance: nó nhận gói tin do instance khác trong private subnet gửi (source là IP của instance kia, destination là một địa chỉ trên internet), rồi chuyển tiếp ra ngoài. Trong cả hai chiều, NAT instance đều không phải nguồn cũng không phải đích ở tầng IP gốc. Chừng nào thuộc tính SourceDestCheck còn bật, VPC còn âm thầm vứt bỏ những gói đó — không có log lỗi, không có gói trả về, biểu hiện đúng như đề mô tả: "instances still cannot access the internet".

Vì vậy mọi hướng dẫn dựng NAT instance đều có bước tắt SourceDestCheck. Đây là thuộc tính của instance, sửa được qua console hoặc CLI, và không đòi hỏi phải tạo lại instance.

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

A — Configure a VPN and route via the company proxy server. Không phải hoàn toàn vô lý về mặt kỹ thuật: định tuyến traffic qua proxy của công ty đúng là một cách cho private instance ra internet. Nhưng nó né vấn đề thay vì sửa vấn đề. NAT instance đã dựng xong, chỉ thiếu một thuộc tính; vứt nó đi để kéo traffic vòng qua mạng doanh nghiệp là thêm hạ tầng, thêm điểm hỏng, thêm độ trễ, trong khi internet gateway của VPC vẫn nằm đó sẵn sàng phục vụ. Đề hỏi "resolve the issue", tức là sửa cái đang hỏng.

B — Start/stop the NAT instance so it is launched on a different host. Đây là thao tác chẩn đoán cho sự cố phần cứng vật lý bên dưới — stop rồi start sẽ đưa instance sang host khác. Nhưng triệu chứng ở đây không giống lỗi phần cứng: instance vẫn chạy, vẫn tới được, chỉ riêng việc chuyển tiếp traffic là không hoạt động. Lỗi phần cứng thường biểu hiện thành instance mất hẳn khả năng phản hồi hoặc status check fail, chứ không phải "hoạt động bình thường trừ đúng chức năng NAT". Đây là phương án "tắt đi bật lại" — không dựa trên nguyên nhân nào cả.

D — Delete the NAT instance and replace it with an internet gateway. Đây là phương án gần đúng nguy hiểm nhất, vì internet gateway đúng là thứ cuối cùng đưa traffic ra internet. Nhưng nó không thay thế được NAT cho private subnet. Internet gateway chỉ định tuyến được cho instance có public IP hoặc Elastic IP; instance trong private subnet theo định nghĩa không có địa chỉ công khai, nên dù route table có trỏ thẳng vào internet gateway thì gói tin vẫn không có đường về. Chính vì thế mới cần một thành phần NAT đứng giữa, dịch địa chỉ nguồn thành địa chỉ công khai của nó. Ngoài ra, VPC đã sẵn có internet gateway rồi — NAT instance phải nằm ở public subnet mới ra được internet — nên "thay thế" ở đây là hiểu sai vai trò của hai thành phần. Chọn D là phá vỡ mô hình private subnet chứ không phải sửa lỗi.

📌 Điểm cần nhớ

• Bất kỳ EC2 instance nào đóng vai trò chuyển tiếp gói tin (NAT instance, software router, firewall appliance tự dựng) đều phải tắt source/destination check. Đây là bước dễ quên nhất và triệu chứng của nó là traffic biến mất im lặng, không lỗi.
• Đọc kỹ danh sách "những việc đã làm" trong đề — đó là cách ra đề loại bỏ các nguyên nhân hiển nhiên (security group, route table) để ép bạn chỉ ra đúng bước còn thiếu.
• Internet gateway và NAT phục vụ hai loại subnet khác nhau: internet gateway cho instance có public/Elastic IP ở public subnet; NAT (instance hoặc NAT gateway) cho instance không có địa chỉ công khai ở private subnet. Chúng bổ sung cho nhau, không thay thế nhau — NAT vẫn cần internet gateway ở phía sau.
• Khi gỡ lỗi mạng, ưu tiên sửa đúng nguyên nhân gốc thay vì thay cả kiến trúc (VPN/proxy) hay thao tác vô định hướng (stop/start). Phương án nào cũng "làm cho nó chạy" nhưng chỉ một phương án giải thích được vì sao nó đang không chạy.

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

Đề mô tả một công ty đang dùng NAT instance (một EC2 instance tự dựng làm cổng NAT) để các EC2 trong private subnet tải phần mềm và bản cập nhật từ Internet. Khi số lượng EC2 trong private subnet tăng lên, độ trễ trên NAT instance tăng theo. Câu hỏi yêu cầu chọn hành động giảm độ trễ.

Cụm từ quyết định đáp án nằm ở vế cuối: "cost-efficiently and ensure the solution can scale with increasing demand" — vừa tiết kiệm chi phí, vừa tự co giãn theo nhu cầu tăng dần. Đây chính là ràng buộc phân biệt các phương án. Nếu đề chỉ nói "giảm độ trễ ngay bây giờ" thì việc đổi sang instance type lớn hơn cũng tạm chấp nhận được. Nhưng khi đề đòi scale với nhu cầu tăng trong tương lai, mọi giải pháp còn phải tự quản lý dung lượng đều bị loại.

Cụm thứ hai đáng chú ý là "download software and updates from the internet" — đây là mô tả kinh điển của lưu lượng outbound từ private subnet ra Internet, tức đúng bài toán mà NAT sinh ra để giải. Nhận ra điều này giúp loại ngay những dịch vụ không làm việc NAT.

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

Đáp án đúng theo tệp là B — Replace the NAT instance with a NAT gateway.

NAT gateway là dịch vụ NAT do AWS quản lý (managed). Điểm mấu chốt so với NAT instance: AWS tự lo phần mở rộng băng thông, không cần người vận hành theo dõi và can thiệp. Theo phần giải thích gốc, NAT gateway tự động scale lên tới hàng chục Gbps, thừa dư địa cho nhu cầu đang tăng của công ty này. Nghĩa là khi thêm EC2 vào private subnet, thông lượng NAT tự lớn theo chứ không nghẽn cổ chai như một instance đơn lẻ.

Về chi phí, NAT gateway tính tiền theo giờ sử dụng cộng với lượng dữ liệu xử lý, kèm phí data transfer thông thường của EC2. Nhưng "cost-efficient" ở đây phải hiểu theo nghĩa tổng chi phí vận hành: SysOps Administrator không còn phải vá hệ điều hành, không phải theo dõi sức khoẻ instance, không phải dựng kiến trúc dự phòng thủ công cho NAT instance. Đó là lý do NAT gateway là lựa chọn mặc định của AWS cho nhu cầu NAT outbound, còn NAT instance chỉ còn là phương án cũ.

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

A — Replace the NAT instance with a virtual private gateway. Sai vì virtual private gateway (VGW) không làm chức năng NAT. VGW là đầu cuối phía AWS của kết nối AWS Site-to-Site VPN (và trước đây là Direct Connect), dùng để nối VPC với mạng on-premises. Nó không cấp cho private subnet đường ra Internet để tải phần mềm. Thay NAT instance bằng VGW thì các EC2 trong private subnet mất luôn khả năng ra Internet, tức là không những không giảm độ trễ mà còn làm hỏng hẳn chức năng đang có.

C — Add Auto Scaling for the NAT instance. Đây là phương án nghe có vẻ hợp lý nhất nên cần nói rõ nó hỏng ở đâu. Auto Scaling nhân bản được instance, nhưng NAT instance không tự chia tải theo cách đó. Đường ra Internet của một private subnet được quyết định bởi route table: route 0.0.0.0/0 trỏ tới đúng một ENI/instance NAT. Thêm instance thứ hai vào Auto Scaling group không tự động khiến lưu lượng được chia đều — muốn vậy phải tự viết logic sửa route table, chia subnet theo từng NAT riêng, xử lý chuyện phiên kết nối đang mở bị đứt khi route đổi. Như giải thích gốc nói, đây không phải giải pháp được hỗ trợ và hoạt động không tốt. Nó biến một vấn đề vận hành đơn giản thành một hệ thống tự chế dễ hỏng, đi ngược cả tiêu chí "cost-efficiently".

D — Change the instance type to use a larger instance type. Phương án này thực sự có giảm độ trễ trong ngắn hạn, vì instance lớn hơn thường có băng thông mạng cao hơn — nên nó gần đúng. Nhưng nó hỏng ở đúng chỗ đề nhấn mạnh: "scale with increasing demand". Đây là scale up thủ công, mỗi lần nhu cầu tăng lại phải đo, chọn instance type mới, và dừng instance để đổi type — tức có gián đoạn. Ngoài ra instance type luôn có trần băng thông cố định, cứ tăng mãi sẽ chạm mức lớn nhất. Nó cũng không giải quyết được chuyện NAT instance là điểm hỏng đơn lẻ. Đúng như giải thích gốc: không phải giải pháp tốt nhất vì không scale tốt cho nhu cầu tương lai.

📌 Điểm cần nhớ

• NAT gateway là lựa chọn mặc định, NAT instance là di sản. Hễ đề nói tới NAT instance kèm các từ khoá scalability, availability, managed, reduce operational overhead thì đáp án gần như luôn là chuyển sang NAT gateway.
• Phân biệt rõ ba loại gateway trong VPC: NAT gateway cho private subnet ra Internet (outbound), internet gateway cho public subnet đi hai chiều, virtual private gateway cho kết nối VPN tới on-premises. Đề thi rất hay trộn chúng làm mồi nhử như phương án A.
• Route table quyết định đường ra, không phải số lượng instance. Vì 0.0.0.0/0 chỉ trỏ được tới một target, nhân bản NAT instance bằng Auto Scaling không tự chia tải — đây là lý do phương án "Auto Scaling cho NAT instance" luôn sai.
• Đọc kỹ vế điều kiện cuối đề bài. "Scale with increasing demand" loại bỏ mọi giải pháp phải can thiệp thủ công (đổi instance type), còn "cost-efficiently" trong ngữ cảnh SysOps thường bao gồm cả chi phí vận hành, không chỉ hoá đơn dịch vụ.

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

Đề mô tả một tình huống rất cụ thể: chia sẻ Amazon RDS snapshot của một database đã được mã hoá, sang nhiều AWS account khác cùng một tổ chức, và database ở account đích vẫn phải được mã hoá at rest.

Cụm từ quyết định đáp án nằm ở hai chỗ:

• "of an encrypted database" — nguồn đã mã hoá. Đây không phải chuyện tuỳ chọn: trạng thái mã hoá của RDS instance là thuộc tính cố định, snapshot chụp từ nó thừa hưởng đúng trạng thái đó. Mọi phương án nào bắt đầu bằng "take an unencrypted snapshot" hoặc "create a new unencrypted RDS instance" đều đã sai ngay từ động từ đầu tiên.
• "across different AWS accounts" — chia sẻ qua ranh giới account. Snapshot mã hoá không tự đi qua ranh giới đó được: dữ liệu được bọc bằng một KMS key, và account đích chỉ đọc được nếu nó có quyền dùng chính key ấy.

Ghép hai ràng buộc lại, câu hỏi thực chất không hỏi về RDS mà hỏi về KMS: ai được phép dùng key, và key nào thì cho phép cấp quyền đó.

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

Đáp án đúng theo tệp là C — cập nhật key policy để cấp quyền cho các target account, copy snapshot bằng CMK, rồi mới share snapshot.

Trình tự này khớp đúng với cơ chế của KMS và RDS:

1. Update key policy. Quyền dùng một KMS key qua ranh giới account được quyết định bởi key policy gắn trên chính key đó. Không cấp quyền ở đây thì account đích nhận được snapshot cũng không giải mã nổi.
2. Phải là CMK (customer managed key), không phải default key. Đây là điểm mấu chốt mà phần giải thích tiếng Anh nhấn mạnh: key policy của default/AWS-managed key cho RDS không sửa được, nên snapshot mã hoá bằng key mặc định không share qua account khác được. Cách xử lý là copy snapshot và chỉ định CMK trong lúc copy — bản copy khi đó được bọc bằng key mà bạn kiểm soát policy.
3. Share bản copy. Snapshot đã nằm dưới CMK có policy mở cho target account, nên account đích restore được và instance mới tiếp tục ở trạng thái encrypted at rest — thoả yêu cầu cuối của đề.

Nói ngắn: C là phương án duy nhất chạm tới quyền trên KMS key, mà đó chính là thứ chặn việc share snapshot mã hoá.

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

A — "Take an unencrypted snapshot ... rồi launch encrypted database từ snapshot đó." Sai ở cả hai vế. Không thể chụp snapshot không mã hoá từ một database đã mã hoá — snapshot kế thừa trạng thái mã hoá của nguồn, không có nút tắt. Và chiều ngược lại cũng không được: restore trực tiếp từ một snapshot không mã hoá thì ra một instance không mã hoá, chứ không "bật mã hoá lên" trong bước restore.

B — "Take an encrypted snapshot ... share ... rồi launch encrypted database." Đây là phương án gần đúng nhất và là bẫy chính của câu này. Về mục tiêu thì đúng: snapshot mã hoá, restore ra database mã hoá. Nó hỏng ở chỗ bỏ mất bước quyền: không cập nhật key policy và không copy sang CMK thì thao tác share sẽ không đi tới đâu — hoặc bị từ chối, hoặc account đích cầm snapshot mà không giải mã được. B mô tả kết quả mong muốn chứ không mô tả các bước làm cho nó xảy ra. Khi đề đã nói rõ "encrypted" và "across accounts", phương án không nhắc gì tới KMS gần như chắc chắn là phương án thiếu.

D — "Create a new unencrypted RDS instance từ encrypted snapshot, dump ra file rồi share file." Sai ngay ở bước đầu: không tạo được instance không mã hoá từ snapshot đã mã hoá. Ngoài ra hướng tiếp cận này còn đi ngược yêu cầu của đề — nó cố tình gỡ mã hoá và chuyển dữ liệu ra ngoài dưới dạng file, trong khi đề đòi dữ liệu encrypted at rest ở account đích. Đây là kiểu "giải pháp thủ công" thường xuất hiện trong đề thi để đối chiếu với cách làm native của dịch vụ.

📌 Điểm cần nhớ

• Trạng thái mã hoá của RDS đi theo dữ liệu: encrypted instance → encrypted snapshot → encrypted restore. Không có bước nào trong chuỗi snapshot/restore cho phép bật hoặc tắt mã hoá, nên mọi phương án đề xuất chuyển đổi encrypted ↔ unencrypted bằng snapshot đều loại được ngay.
• Share snapshot mã hoá qua account = bài toán của KMS, không phải của RDS. Thứ chặn bạn là quyền dùng key, nên đáp án đúng gần như luôn có chữ "key policy".
• Default/AWS-managed key không share được vì policy của nó không sửa được. Cách vòng qua chuẩn mực là copy snapshot và chỉ định CMK — nhớ thứ tự: sửa key policy → copy bằng CMK → share.
• Khi hai phương án cùng dẫn tới đúng kết quả, hãy chọn phương án liệt kê đủ bước cấp quyền. Phương án chỉ nêu mục tiêu (như B) thường là bẫy bỏ sót điều kiện tiên quyết.

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

Đề mô tả một SysOps Administrator muốn chỉ cho phép truy cập bucket S3 từ dải IP của công ty 51.210.100.0/24. Policy đã được viết ra (nằm trong ảnh chụp), nhưng khi kiểm thử thì người dùng ở ngoài dải IP đó vẫn kết nối được.

Cụm từ quyết định đáp án nằm ở chính nội dung policy được mô tả trong phần giải thích: statement thứ hai có "Effect": "Allow" đi kèm điều kiện NotIpAddress với aws:SourceIp là dải công ty. Ghép hai thứ đó lại, ý nghĩa thật của policy là: "cho phép mọi principal (*) làm mọi hành động (s3:*) trên bucket — miễn là IP nguồn KHÔNG thuộc dải công ty". Nghĩa là policy đang làm đúng ngược lại điều quản trị viên muốn.

Điểm mấu chốt cần nhận ra: NotIpAddress là condition operator dạng phủ định, còn Effect là thứ quyết định cho hay chặn. Hai yếu tố phủ định/khẳng định này phải được ghép đúng cặp với nhau. Sai cặp thì policy vẫn hợp lệ về cú pháp, không báo lỗi gì, chỉ là hành vi lộn ngược — đúng như triệu chứng đề mô tả.

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

A — Đổi Effect từ Allow sang Deny trong statement thứ hai.

Sau khi đổi, statement đọc thành: "Từ chối mọi hành động s3:* trên bucket và trên các object bên trong (arn:aws:s3:::examples3bucket và arn:aws:s3:::examples3bucket/*), nếu IP nguồn KHÔNG nằm trong 51.210.100.0/24".

Đây chính xác là điều đề bài cần: người dùng ngoài dải công ty rơi vào NotIpAddress → điều kiện khớp → bị Deny. Người dùng trong dải công ty thì điều kiện NotIpAddress không khớp → statement không áp dụng → họ vẫn truy cập được qua các quyền hợp lệ khác. Ngoài ra, Deny trong bucket policy có sức mạnh cao hơn Allow, nên nó chặn triệt để chứ không chỉ "không cấp thêm quyền".

Chỉ cần sửa một từ, không đụng gì tới Condition, Action, Resource hay Principal.

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

B — Đổi condition element sang aws:StringEquals thay vì aws:SourceIp. Phương án này nhầm lẫn hai loại khác nhau: aws:SourceIp là condition key (thứ được đem ra so sánh), còn StringEquals là condition operator (cách so sánh). Không thể "thay aws:SourceIp bằng aws:StringEquals" — chúng không cùng vai trò. Quan trọng hơn, vấn đề ở đây không phải so sánh sai kiểu dữ liệu, mà là logic Allow + NotIpAddress bị lộn ngược. Đổi cách so sánh không sửa được chuyện đó, và so sánh dải CIDR bằng phép so chuỗi cũng không cho ra kết quả mong muốn.

C — Dùng IAM policy thay vì bucket policy. Đây là phương án nghe hợp lý nhất trong ba phương án sai, nên phải nói rõ nó hỏng ở đâu. Về nguyên tắc, điều kiện aws:SourceIp dùng được ở cả IAM policy lẫn bucket policy — nên vấn đề không phải là "IAM policy không làm được". Nó hỏng ở hai chỗ: (1) nó không sửa lỗi thật — logic lộn ngược vẫn còn nguyên trong bucket policy, chuyển sang IAM policy mà giữ nguyên cặp Allow + NotIpAddress thì vẫn sai y như cũ; (2) IAM policy chỉ áp dụng cho các identity trong tài khoản mà nó được gắn vào, còn yêu cầu ở đây là bảo vệ chính bucket trước mọi người gọi tới. Ràng buộc gắn với tài nguyên thì thuộc về bucket policy.

D — Đưa cả NotIpAddress và IpAddress vào Condition. Phương án này thừa và tự mâu thuẫn. Nhiều condition operator trong cùng một Condition block được ghép bằng AND, nên yêu cầu "IP vừa thuộc dải vừa không thuộc dải" không bao giờ khớp — statement trở thành vô hiệu, và mọi người vẫn truy cập được như trước. Nó cũng phức tạp hóa vấn đề: chỉ cần đổi Allow thành Deny là đã có kết quả mong muốn, không cần chồng thêm operator nào.

📌 Điểm cần nhớ

• Trong policy của AWS, phải đọc cặp Effect + condition operator cùng lúc. Deny đi với NotIpAddress là "chỉ cho phép trong dải"; Allow đi với NotIpAddress là "cho phép mọi nơi trừ dải" — hai câu hoàn toàn trái ngược, mà cú pháp thì đều hợp lệ nên không có thông báo lỗi nào.
• Muốn giới hạn theo IP nguồn cho một bucket, dùng Deny kèm NotIpAddress trên aws:SourceIp — vì Deny thắng Allow, cách này chặn được cả những quyền cấp từ nơi khác.
• Phân biệt condition key (aws:SourceIp, thứ được so sánh) với condition operator (IpAddress, NotIpAddress, StringEquals, cách so sánh). Đề thi hay đánh tráo hai khái niệm này trong các phương án nhiễu.
• Ràng buộc gắn với tài nguyên và áp cho mọi người gọi → bucket policy. Ràng buộc gắn với identity cụ thể trong tài khoản → IAM policy.
• Nhiều điều kiện trong cùng một Condition block được ghép bằng AND. Đưa hai operator đối nghịch vào cùng một chỗ thì statement không bao giờ khớp, tức là vô hiệu chứ không phải "chặt chẽ hơn".

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

Đề mô tả một kiến trúc VPC khá điển hình: hai public subnet và hai private subnet trải trên hai Availability Zone, một internet gateway duy nhất, một NAT gateway duy nhất, và CloudFront đứng trước để cache nội dung tĩnh lẫn động.

Câu hỏi: thành phần nào có thể khiến ứng dụng trong VPC hỏng khi một AZ bị sự cố ngắn?

Cụm từ quyết định đáp án là "a single NAT gateway" đặt cạnh "during a brief AZ outage". Đề cố tình liệt kê hai thứ đều "single" — internet gateway và NAT gateway — để buộc người học phân biệt: thành phần nào của AWS là VPC-level (tự phân tán trên mọi AZ), thành phần nào là AZ-level (bạn tự chọn AZ khi tạo, và nó chết theo AZ đó). Đây chính là ranh giới cần nhớ, chứ không phải chuyện "có mấy subnet".

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

D — A single NAT gateway, because it is not redundant across multiple AZs.

Mỗi NAT gateway được tạo trong một Availability Zone cụ thể — khi tạo bạn phải chỉ định một subnet, và subnet đó nằm gọn trong một AZ. AWS có triển khai dự phòng cho NAT gateway, nhưng phần dự phòng đó chỉ nằm bên trong AZ ấy, không trải sang AZ khác.

Hệ quả trực tiếp: kiến trúc trong đề có hai private subnet ở hai AZ nhưng cả hai đều phải định tuyến lưu lượng ra Internet qua đúng một NAT gateway. AZ chứa NAT gateway đó gặp sự cố thì:

• Instance ở private subnet cùng AZ mất đường ra Internet.
• Instance ở private subnet AZ còn lại — dù bản thân AZ đó vẫn khoẻ — cũng mất đường ra, vì route table của chúng vẫn trỏ tới NAT gateway đã chết.

Nói cách khác, một NAT gateway duy nhất biến một sự cố cục bộ ở một AZ thành sự cố của toàn bộ lưu lượng outbound trong VPC. Cách làm đúng theo thiết kế nhiều AZ là đặt một NAT gateway trong mỗi AZ và cho private subnet của mỗi AZ trỏ về NAT gateway cùng AZ với nó.

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

A — The main route table, as it cannot be associated with multiple subnets. Sai ngay ở phần lý do. Một route table (kể cả main route table) hoàn toàn có thể được gắn với nhiều subnet, và các subnet đó được phép nằm ở những AZ khác nhau. Route table là cấu hình logic ở tầng VPC, không phải tài nguyên chạy trong một AZ, nên nó không "chết" theo AZ. Phương án này dựng lên một giới hạn không tồn tại.

B — A single internet gateway, because it is not redundant across multiple AZs. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì nó dùng đúng khuôn chữ với đáp án D. Chỗ hỏng: internet gateway gắn ở cấp VPC, được AWS thiết kế sẵn tính sẵn sàng cao và dự phòng theo chiều ngang cho toàn VPC — bạn không chọn AZ cho nó, không đặt nó vào subnet nào. Vì vậy một internet gateway duy nhất là chuyện bình thường và đúng chuẩn (mỗi VPC cũng chỉ gắn được một), không phải điểm chết theo AZ. Chỉ cần nhớ: "single NAT gateway" là vấn đề, "single internet gateway" thì không.

C — Amazon CloudFront, as it cannot use origins in multiple subnets. Sai ở cả tiền đề lẫn mức liên quan. CloudFront cấu hình được nhiều origin, và origin điển hình là một ELB đang phân phối tới target ở nhiều AZ — nên chuyện "không dùng được origin ở nhiều subnet" là không đúng. Ngoài ra CloudFront là dịch vụ edge toàn cầu, không nằm trong VPC và không phụ thuộc vào một AZ; đề còn nói rõ nó đang cache cả nội dung tĩnh lẫn động, nên trong một sự cố AZ ngắn, phần lớn yêu cầu vẫn được phục vụ từ cache. CloudFront ở đây làm giảm ảnh hưởng chứ không phải nguyên nhân gây hỏng.

📌 Điểm cần nhớ

• Phân loại tài nguyên theo phạm vi trước khi chọn: internet gateway và route table là VPC-level; NAT gateway là AZ-level vì được tạo trong một subnet cụ thể. Câu hỏi kiểu "cái nào chết khi mất một AZ" thực chất là câu hỏi về phạm vi này.
• "Redundant" của NAT gateway chỉ có nghĩa trong nội bộ một AZ — nó không tự trải sang AZ khác. Muốn chịu được sự cố AZ thì phải tự tạo mỗi AZ một NAT gateway và trỏ route table của private subnet về NAT gateway cùng AZ.
• Khi đề đưa ra hai phương án có chung khuôn chữ ("single X, because it is not redundant across multiple AZs"), điểm phân biệt nằm ở X được đặt ở đâu, không nằm ở chữ "single".
• Dịch vụ edge như CloudFront nằm ngoài VPC và có cache, nên hiếm khi là nguyên nhân gây hỏng trong một sự cố AZ ngắn — thường nó là thứ che bớt ảnh hưởng.

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

Đề mô tả một ứng dụng tính toán phân tán chạy trên EC2, và hỏi mô hình giá MOST cost-effective — chọn HAI phương án. Điểm mấu chốt là đề chia rõ fleet thành hai nhóm node có đặc tính chạy hoàn toàn khác nhau, và mỗi nhóm cần một mô hình giá riêng:

• 2 control nodes: run continuously — chạy liên tục, và at least 1 year — kéo dài tối thiểu một năm. Số lượng cố định, thời lượng cố định, không được gián đoạn.
• 8 đến 24 worker nodes: between 8 and 24 worker nodes as required, run for 8 hours a day and are launched when required — số lượng thay đổi, chỉ chạy một phần trong ngày, khởi chạy theo nhu cầu.

Cụm từ quyết định là cặp "run continuously" + "at least 1 year" (cho control node) đối lập với "between 8 and 24" + "8 hours a day" + "when required" (cho worker node). Hai đặc tính này ánh xạ thẳng sang hai mô hình giá: cam kết dài hạn cho phần tải cố định, và giá theo dung lượng dư cho phần tải co giãn, chịu được gián đoạn. Ứng dụng còn là distributed computing — mất một worker thì phần việc chạy lại được trên worker khác, nên worker chấp nhận bị thu hồi.

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

A — Reserved Instances cho control nodes. Reserved Instances là cam kết dùng một cấu hình EC2 trong một kỳ hạn (thường 1 hoặc 3 năm) để đổi lấy mức giá thấp hơn đáng kể so với On-Demand. Control node hội đủ mọi điều kiện để cam kết có lợi: số lượng cố định (2 node), chạy 24/7, và đề đã nói trước là sẽ chạy tối thiểu 1 năm. Vì đã chắc chắn dùng hết kỳ hạn nên không có rủi ro trả tiền cho phần công suất không dùng. Quan trọng không kém: RI không bị thu hồi — instance chạy ổn định, đúng yêu cầu của node điều phối.

B — Spot Instances cho worker nodes, dự phòng bằng On-Demand. Spot dùng dung lượng dư của AWS với mức giảm giá rất lớn, đổi lại instance có thể bị thu hồi khi AWS cần lại dung lượng. Worker node trong bài chịu được điều đó: chúng là các node tính toán thay thế được nhau, được launched when required, nên mất một node không làm sập hệ thống. Phần "and On-Demand Instances if there is no Spot availability" xử lý đúng nhược điểm còn lại của Spot — Spot không đảm bảo luôn có dung lượng, nên khi hết Spot thì rơi về On-Demand để công việc vẫn chạy. Đây là mô hình rẻ nhất mà vẫn giữ được tính sẵn sàng cho phần tải biến động.

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

C — Spot cho control nodes, dự phòng On-Demand. Đây là phương án gần đúng nhất và là bẫy chính: nó dùng đúng kỹ thuật của B nhưng gắn nhầm nhóm node. Control node chạy liên tục suốt năm và là thành phần điều phối cả cụm; Spot có thể bị thu hồi bất cứ lúc nào, nên cụm sẽ mất control node theo chu kỳ ngẫu nhiên. Ngoài ra, một khối tải chạy 24/7 suốt một năm chính là trường hợp mà cam kết dài hạn cho giá tốt nhất — dùng Spot ở đây vừa kém ổn định vừa bỏ phí khoản chiết khấu chắc chắn.

D — Dedicated Hosts cho control nodes. Dedicated Host là máy chủ vật lý dành riêng cho một khách hàng, giá cao hơn hẳn instance chia sẻ. Nó tồn tại để phục vụ các nhu cầu về tuân thủ, cách ly phần cứng, hoặc mang license phần mềm gắn theo socket/core sang AWS. Đề không nêu bất kỳ yêu cầu nào thuộc nhóm đó — chỉ hỏi chi phí thấp nhất. Chọn Dedicated Hosts là trả thêm tiền cho một đặc tính bài toán không cần.

E — Reserved Instances cho worker nodes. Sai vì hai chỗ, và cả hai đều nằm ngay trong đề. Thứ nhất, worker chỉ chạy 8 hours a day, trong khi RI tính phí theo cam kết cho toàn bộ kỳ hạn chứ không chỉ giờ có dùng — phần lớn thời gian bạn trả tiền cho công suất đang nằm không. Thứ hai, số worker dao động between 8 and 24: muốn cam kết thì chỉ cam kết an toàn được ở mức đáy (8), phần dao động phía trên vẫn phải mua kiểu khác, nên RI không phủ được đặc tính co giãn của nhóm này. Đây đúng là nhóm tải mà Spot sinh ra để phục vụ.

📌 Điểm cần nhớ

• Ánh xạ chuẩn của dạng câu "MOST cost-effective pricing model": tải ổn định, chạy liên tục, biết trước thời hạn → Reserved Instances; tải biến động, chịu được gián đoạn → Spot; phần còn lại hoặc lúc hết dung lượng Spot → On-Demand.
• Đọc kỹ để tách fleet thành các nhóm có đặc tính chạy khác nhau, rồi gán mô hình giá cho từng nhóm. Câu "Select TWO" kiểu này thường là hai nhóm — hai mô hình, và bẫy nằm ở phương án dùng đúng mô hình nhưng gắn nhầm nhóm.
• Spot phù hợp khi khối lượng công việc chịu được việc instance bị thu hồi; không dùng cho node điều phối, node trạng thái, hay bất cứ thứ gì phải sống liên tục.
• Reserved Instances chỉ có lợi khi thực sự dùng hết cam kết. Tải chạy vài giờ mỗi ngày hoặc số lượng dao động thì cam kết trở thành tiền trả cho công suất nhàn rỗi.
• Dedicated Hosts trong đề thi hầu như luôn gắn với tuân thủ, cách ly phần cứng, hoặc license theo socket/core — không có mấy từ khoá đó mà đề hỏi chi phí thì đây là phương án loại.