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

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

Đề mô tả một web application và một Amazon RDS DB instance cùng nằm trong private subnet của một VPC. Ứng dụng đã được cập nhật thông tin kết nối tới database, nhưng log của web server cho thấy kết nối tới database liên tục thất bại. Câu hỏi yêu cầu chọn HAI nguyên nhân có thể.

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

• "After ensuring the application and DB are fully deployed" — đề đã tự tay loại bỏ khả năng database còn đang được tạo. Đây là mệnh đề gài sẵn để chặn một phương án nghe rất hợp lý.
• "in private subnets within a VPC" — mọi phương án dựa trên địa chỉ public đều vô nghĩa, vì tài nguyên trong private subnet không có và không cần public IP.

Khi đề đã khoá hai hướng đó lại, chỉ còn hai lớp nguyên nhân kinh điển của lỗi "không kết nối được RDS": đường đi bị chặn ở tầng security group và thông tin kết nối (endpoint) sai.

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

A — Dùng sai DNS name hoặc database endpoint. RDS không cho bạn kết nối bằng tên tuỳ ý; mỗi DB instance có một endpoint riêng do AWS cấp, và ứng dụng phải dùng đúng chuỗi đó cùng đúng port. Đề nói quản trị viên vừa "updated the application with the connection information" — tức là bước cấu hình thủ công này vừa mới diễn ra, đúng chỗ dễ gõ nhầm nhất. Endpoint sai thì phân giải DNS thất bại hoặc trỏ tới nơi khác, và triệu chứng là kết nối hỏng lặp đi lặp lại y như mô tả.

E — Nguồn kết nối chưa được cho phép trong ingress rules của security group gắn với database. Đây là nguyên nhân phổ biến nhất. Security group của RDS phải có một inbound rule cho phép traffic từ security group của web server, trên đúng port của database engine. Thiếu rule này thì gói tin bị chặn ngay tại DB instance, ứng dụng chỉ thấy timeout hoặc refused — hoàn toàn khớp với "connection repeatedly failing" dù cả hai bên đều đã chạy.

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

B — Database vẫn đang được tạo nên chưa sẵn sàng nhận kết nối. Đây là nguyên nhân có thật trong đời thực: DB instance ở trạng thái khác available thì không nhận kết nối. Nhưng đề đã nói rõ quản trị viên kiểm tra và xác nhận application lẫn DB đều fully deployed trước khi xem log. Phương án này bị loại không phải vì sai về kỹ thuật, mà vì mâu thuẫn với dữ kiện đề cho. Đây chính là kiểu bẫy "đúng lý thuyết, sai ngữ cảnh".

C — Nguồn kết nối chưa được cho phép trong egress rules của security group database. Gần đúng nhất, và hỏng ở một chi tiết: security group là stateful. Khi một kết nối inbound đã được ingress rule cho phép, traffic phản hồi đi ra được tự động chấp nhận mà không cần egress rule tương ứng. Ngoài ra egress rule của database điều chỉnh traffic do database khởi tạo đi ra, chứ không phải traffic từ web server đi vào — nói "source used to connect" trong ngữ cảnh egress là đặt sai chiều. (Nếu đề nói về network ACL thì lại khác, vì NACL là stateless — nhưng đề không nhắc tới NACL.)

D — DB instance không có Elastic IP gắn kèm. Sai ở hai tầng. Thứ nhất, RDS không phải là thứ bạn gắn Elastic IP vào theo cách gắn cho EC2 instance. Thứ hai, và quan trọng hơn cho bài thi: cả web server lẫn database đều nằm trong private subnet cùng một VPC, nên chúng nói chuyện với nhau qua địa chỉ private. Địa chỉ public không đóng vai trò gì trong đường kết nối này, và việc thiếu nó không thể là nguyên nhân.

📌 Điểm cần nhớ

• Khi đề khẳng định tài nguyên đã fully deployed / available, mọi phương án đổ lỗi cho "còn đang khởi tạo" đều bị loại — đó là dữ kiện đề cho, không phải thứ để nghi ngờ.
• Security group là stateful: chỉ cần ingress rule cho chiều đi vào, traffic trả lời tự động được phép. Thấy phương án đổ lỗi cho egress rule trong tình huống client-tới-server thì gần như chắc chắn là bẫy. Network ACL mới là thứ stateless và cần rule cho cả hai chiều.
• Giao tiếp giữa các tài nguyên trong private subnet cùng VPC dùng địa chỉ private; phương án nhắc tới Elastic IP hay public IP trong bối cảnh này thường là nhiễu.
• Với lỗi "không kết nối được RDS", hai chỗ đáng ngờ đầu tiên luôn là security group ingress trên đúng port và endpoint/DNS name có gõ đúng không — nhất là khi thông tin kết nối vừa được cấu hình bằng tay.

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

Đề mô tả một CloudFront distribution có cache hit ratio dưới 20%, khiến quá nhiều request phải đi ngược về origin. Yêu cầu: chọn hai thay đổi cấu hình làm tăng cache hit ratio.

Cụm từ quyết định là "increase the cache hit ratio" — không phải "tăng bảo mật", không phải "giảm tải origin nói chung", cũng không phải "giảm thời gian chờ origin". Cache hit ratio chỉ phụ thuộc vào đúng hai nhóm yếu tố:

1. Object nằm trong cache được bao lâu (TTL) — nằm càng lâu, càng nhiều request sau đó bắt được bản đã cache.
2. Cache key rộng hay hẹp — CloudFront dựng khoá cache từ những cookie, query string và header mà cache behavior được cấu hình dùng. Khoá càng nhiều thành phần thì cùng một nội dung bị tách thành càng nhiều bản cache khác nhau, mỗi bản chỉ phục vụ được một phần nhỏ lưu lượng, và tỉ lệ trúng cache tụt xuống.

Cache hit ratio thấp bất thường như 20% gần như luôn là triệu chứng của một trong hai chuyện đó. Phương án nào không chạm vào TTL hay cache key thì dù nghe hợp lý đến đâu cũng không phải câu trả lời.

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

A — Dùng Cache-Control max-age để kéo dài thời gian object nằm trong cache. max-age do origin gửi kèm response là thứ CloudFront dựa vào để quyết định object còn "tươi" trong bao lâu trước khi phải hỏi lại origin. Đặt giá trị quá ngắn (hoặc để origin trả về giá trị mặc định rất nhỏ) nghĩa là object vừa vào cache đã hết hạn, và request kế tiếp lại đi ngược về origin. Kéo dài max-age là cách trực tiếp nhất để cùng một object phục vụ được nhiều viewer request hơn — đây chính là mục "specifying how long CloudFront caches your objects" trong tài liệu.

C — Chỉnh cache behavior để chỉ forward những cookie, query string và header thật sự cần. Mỗi cookie, query string hay header được đưa vào cache key sẽ nhân số lượng biến thể cache lên. Forward toàn bộ cookie là kiểu hỏng kinh điển: cookie phiên gần như là duy nhất với từng người dùng, nên mỗi viewer tự sinh ra một mục cache riêng và tỉ lệ trúng gần như bằng không. Thu hẹp danh sách xuống đúng phần ảnh hưởng tới nội dung trả về sẽ gộp lượng lớn request về chung một mục cache.

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

B — Giới hạn HTTP method chỉ còn GET và HEAD. Đây là phương án gần đúng nhất và dễ chọn nhầm, vì nó đúng là giảm số request đi tới origin. Nhưng CloudFront vốn chỉ cache response của GET và HEAD; POST, PUT, DELETE… luôn được chuyển thẳng về origin bất kể cấu hình. Chặn chúng đi không thêm được object nào vào cache, cũng không làm object có sẵn được dùng lại nhiều hơn — nó thay đổi tập method được phép, chứ không thay đổi nội dung trong cache. Cache hit ratio đứng yên.

D — Giảm origin response timeout để "nhiều object được trả về từ cache hơn". Vế nhân quả trong phương án này là bịa. Origin response timeout chỉ quy định CloudFront chờ origin trả lời bao lâu trước khi bỏ cuộc, tức là chuyện xảy ra sau khi đã cache miss. Nó ảnh hưởng tới hành vi lúc lỗi/chậm giữa CloudFront và origin, không hề đụng tới TTL hay cache key. Giảm timeout chỉ khiến các request chậm thất bại sớm hơn, chứ không biến chúng thành cache hit.

E — Đổi viewer protocol policy sang redirect HTTP về HTTPS. Đây là thay đổi về bảo mật kênh truyền giữa viewer và CloudFront, hoàn toàn không nằm trong yêu cầu của đề. Nó không kéo dài TTL, không thu hẹp cache key. Thậm chí redirect còn thêm một vòng request nữa cho viewer. Đề chỉ hỏi về cache hit ratio — "tăng bảo mật" là một mục tiêu khác bị gài vào để đánh lạc hướng.

📌 Điểm cần nhớ

• Cache hit ratio của CloudFront chỉ nhích lên khi bạn tác động vào một trong hai thứ: object sống trong cache bao lâu (TTL / Cache-Control max-age) hoặc cache key rộng bao nhiêu (cookie, query string, header được đưa vào khoá). Gặp câu hỏi dạng này, sàng phương án theo đúng hai trục đó.
• Forward càng ít càng trúng cache càng nhiều — mỗi thành phần thừa trong cache key là một phép nhân số biến thể. Cookie phiên forward tràn lan là nguyên nhân phổ biến nhất khiến tỉ lệ trúng cache tụt về gần 0.
• Cẩn thận với phương án giảm tải origin nhưng không tăng hit ratio: giới hạn HTTP method là ví dụ điển hình. CloudFront chỉ cache GET và HEAD, nên can thiệp vào các method khác không sinh thêm cache hit nào.
• Đọc kỹ yêu cầu thật của đề. Phương án đúng về kỹ thuật nhưng phục vụ mục tiêu khác (bảo mật, độ trễ khi origin lỗi) vẫn là phương án sai trong câu hỏi về hiệu năng cache.

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

Đề mô tả một ứng dụng gồm nhiều AWS Lambda function, mỗi function ghi log vào một CloudWatch Logs log group riêng. Người quản trị đang gỡ lỗi và cần đếm số lỗi ứng dụng, gom nhóm theo loại lỗi, trên toàn bộ các log group.

Có hai cụm từ quyết định đáp án, và phải thoả cả hai:

• "grouped by type" — đây không phải việc đọc log bằng mắt, mà là một phép thống kê gộp (aggregate): nhóm theo một trường rồi đếm. Phương án nào không có khả năng gom nhóm + đếm thì loại.
• "across all the log groups" — dữ liệu nằm rải ở nhiều log group, nên công cụ được chọn phải truy vấn nhiều log group trong cùng một lần. Đây chính là ràng buộc phân biệt các phương án nghe rất giống nhau, vì phương án B cũng có "count" và cũng nói tới CloudWatch Logs.

Nói cách khác: câu hỏi đang kiểm tra bạn có phân biệt được CloudWatch Logs search (tìm kiếm thường, phạm vi hẹp) với CloudWatch Logs Insights (ngôn ngữ truy vấn có lệnh thống kê, phạm vi nhiều log group) hay không.

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

Đáp án đúng theo tệp là C — Perform a CloudWatch Logs Insights query that uses the stats command and count function.

CloudWatch Logs Insights là công cụ được sinh ra đúng cho tình huống này: nó cho phép tìm kiếm và phân tích tương tác dữ liệu log đang nằm trong CloudWatch Logs, để nhanh chóng khoanh vùng nguyên nhân sự cố và kiểm chứng bản vá sau khi triển khai.

Hai đặc điểm khớp trực tiếp với hai ràng buộc của đề:

• Một truy vấn duy nhất chọn được nhiều log group cùng lúc (Logs Insights có giới hạn số log group mỗi request, nên với hệ thống rất nhiều Lambda thì cần chia mẻ — nhưng về nguyên tắc, đây là công cụ duy nhất trong danh sách truy vấn xuyên log group được). Điều này đáp ứng "across all the log groups".
• Lệnh stats kết hợp hàm count() thực hiện đúng phép gom nhóm và đếm, ví dụ stats count(*) by errorType. Đây chính là "grouped by type".

Ngoài ra, truy vấn có thời hạn chạy và kết quả được giữ lại một thời gian để xem lại — phù hợp với công việc troubleshooting tạm thời, không cần dựng thêm hạ tầng lưu trữ hay ETL nào.

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

A — Amazon RDS query dùng SELECT và GROUP BY. Sai về bản chất. Amazon RDS là dịch vụ cơ sở dữ liệu quan hệ được quản lý; nó không có bất kỳ đường nào đọc thẳng dữ liệu trong CloudWatch Logs. Cú pháp SELECT ... GROUP BY đúng là làm được phép gom nhóm, nhưng dữ liệu log không nằm trong RDS nên câu lệnh đó không có gì để chạy trên. Đây là phương án gây nhiễu bằng cú pháp quen thuộc.

B — CloudWatch Logs search dùng "groupby" và count. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó nhắc đúng tên dịch vụ CloudWatch Logs. Nó hỏng ở chỗ: chức năng search của CloudWatch Logs làm việc trong phạm vi một log group, tức là không thoả ràng buộc "across all the log groups" của đề. Muốn có số liệu tổng thì phải chạy tay từng log group rồi tự cộng lại — không phải cách làm mà câu hỏi đang tìm. Thêm nữa, groupby không phải cú pháp của tính năng search; lệnh gom nhóm và đếm thuộc về ngôn ngữ truy vấn của Logs Insights (stats ... by ...).

D — Amazon Athena query dùng SELECT và GROUP BY. Đây là phương án gần đúng thứ hai, vì Athena thật sự là công cụ truy vấn SQL và có thể kết nối tới CloudWatch Logs. Nó hỏng ở cách dữ liệu được ánh xạ: mỗi log group trở thành một schema và mỗi log stream trở thành một bảng riêng. Với một ứng dụng nhiều Lambda, mỗi Lambda một log group, mỗi log group lại nhiều stream, việc tính thống kê gộp xuyên suốt sẽ phải ghép rất nhiều bảng — phức tạp và vòng vo hẳn so với một truy vấn Logs Insights. Athena hợp với log đã được đưa vào Amazon S3 và phân vùng sẵn cho phân tích lâu dài, không hợp với việc gỡ lỗi tức thời trên log đang nằm trong CloudWatch.

📌 Điểm cần nhớ

• Thấy từ khoá "count", "aggregate", "grouped by", "top N" trên dữ liệu đang nằm trong CloudWatch Logs → nghĩ ngay tới CloudWatch Logs Insights với lệnh stats và hàm count().
• Phân biệt rõ hai thứ dễ lẫn: CloudWatch Logs search làm việc trong phạm vi một log group và chỉ tìm kiếm; CloudWatch Logs Insights truy vấn được nhiều log group trong một request và có ngôn ngữ thống kê thật sự.
• Athena đúng là truy vấn được bằng SQL, nhưng cách nó ánh xạ CloudWatch Logs (log group → schema, log stream → bảng) khiến việc tính gộp xuyên log group trở nên rườm rà. Athena là lựa chọn cho phân tích log đã đổ về S3, không phải cho troubleshooting tức thời.
• Amazon RDS không đọc được CloudWatch Logs. Trong đề trắc nghiệm, cú pháp SQL quen thuộc thường được dùng làm mồi nhử — luôn kiểm tra trước xem dữ liệu có thật sự nằm trong dịch vụ đó không rồi mới xét tới cú pháp.

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

Đề mô tả một nền tảng đang chạy ở Region us-east-1, sắp triển khai thêm bản sao ở eu-central-1, và dùng Amazon Route 53 để quản lý bản ghi DNS. Yêu cầu: người dùng châu Âu phải vào bản triển khai eu-central-1, còn mọi người dùng ở nơi khác thì vào us-east-1. Câu hỏi là chọn loại routing policy nào cho record set.

Cụm từ quyết định đáp án là "European users are directed to eu-central-1, while users from other regions..." — tức là tiêu chí phân luồng ở đây là vị trí địa lý của người dùng, được nêu theo đơn vị châu lục/khu vực, và là một quy tắc bắt buộc ("It's crucial"), không phải một kết quả mong đợi. Hai chi tiết đó loại luôn mọi policy phân luồng theo thứ khác (độ trễ mạng, xác suất) hoặc chỉ gần đúng về mặt địa lý.

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

Đáp án theo tệp là B — Geolocation routing policy.

Geolocation routing policy cho phép định tuyến traffic dựa trên vị trí địa lý của người dùng (nguồn truy vấn DNS). Ta khai báo một quy tắc gắn châu Âu với endpoint ở eu-central-1, và dùng bản ghi default để hứng toàn bộ phần còn lại của thế giới, trỏ về us-east-1.

Cách này khớp chính xác với phát biểu của đề: quy tắc "châu Âu → eu-central-1, còn lại → us-east-1" là một ánh xạ tường minh do người quản trị khai báo, kết quả xác định trước chứ không phụ thuộc điều kiện mạng tại thời điểm truy vấn. Đúng như phần giải thích gốc nêu: policy này cho phép đưa người dùng ở châu Âu về eu-central-1 và mọi người khác về us-east-1.

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

A — Latency routing policy. Đây là phương án gây nhầm nhiều nhất, vì trong thực tế nó thường cho ra cùng kết quả: người dùng châu Âu hay có độ trễ tới eu-central-1 thấp hơn. Nhưng nó hỏng ở chỗ tiêu chí phân luồng là độ trễ mạng đo được, không phải vị trí địa lý. Kết quả không được bảo đảm và thay đổi theo điều kiện mạng — một người dùng châu Âu vẫn có thể bị đẩy sang us-east-1 nếu đường mạng lúc đó cho độ trễ thấp hơn. Đề yêu cầu ràng buộc cứng ("crucial"), nên "thường đúng" là không đủ.

C — Geoproximity routing policy. Cũng dựa trên địa lý nên trông rất sát, nhưng nó định tuyến theo khoảng cách địa lý giữa người dùng và tài nguyên, kèm khả năng dùng bias để kéo giãn hoặc thu hẹp vùng phục vụ của từng endpoint. Nghĩa là ranh giới giữa hai vùng là kết quả của phép tính khoảng cách/bias, chứ không phải một danh sách khu vực do ta khai. Đúng như giải thích gốc: với yêu cầu nêu trong đề, nó không chính xác bằng Geolocation. Geoproximity hợp khi ta muốn dịch chuyển tải giữa các vị trí, còn ở đây ta muốn chỉ mặt đặt tên rằng châu Âu đi đâu.

D — Multivalue answer routing policy. Policy này trả về nhiều bản ghi và phân phối truy vấn gần như ngẫu nhiên giữa các tài nguyên (kèm health check để loại endpoint hỏng). Nó hoàn toàn không xét vị trí người dùng, nên người dùng châu Âu có thể bị đưa về us-east-1 và ngược lại. Đây là công cụ tăng tính sẵn sàng / chia tải đơn giản, không phải công cụ phân luồng theo khu vực.

📌 Điểm cần nhớ

• Đề nói "người dùng ở khu vực X" → Geolocation. Từ khóa là vị trí địa lý được nêu theo châu lục / quốc gia, và ánh xạ do người quản trị khai tường minh.
• Đề nói "nhanh nhất / độ trễ thấp nhất" → Latency. Đừng chọn Latency chỉ vì nó thường cho ra kết quả giống Geolocation — nó không bảo đảm, và đề dùng chữ như "must"/"crucial" là để loại đúng kiểu suy luận đó.
• Phân biệt Geolocation với Geoproximity: Geolocation là ánh xạ khu vực → endpoint; Geoproximity là khoảng cách + bias, dùng khi muốn dịch chuyển tỷ lệ traffic giữa các vị trí.
• Luôn khai bản ghi default khi dùng Geolocation. Không có nó thì truy vấn từ khu vực không khớp quy tắc nào sẽ không nhận được câu trả lời — đúng vế "users from other regions" trong đề.
• Multivalue answer là chuyện sẵn sàng và chia tải ngẫu nhiên, không bao giờ là đáp án cho yêu cầu phân luồng theo địa lý.

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

Đề mô tả một website chạy trên burstable performance Amazon EC2 instances (họ T) trong một Auto Scaling group. Khi gửi email khuyến mãi, lưu lượng tăng cao kéo dài vài giờ, và người dùng báo chậm sau khi sự kiện diễn ra được vài tiếng. Quan sát của SysOps administrator: CPU utilization dưới 30% trên toàn fleet, còn ASG được cấu hình chỉ scale khi CPU trên 60% — nên nó không scale.

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

• "burstable performance" — đây là điểm neo. Nó xác định loại instance là họ T, tức là loại có baseline CPU performance và CPU credit, chứ không phải instance cấp CPU cố định.
• "sustained spikes … for a few hours" và "a couple of hours into these events" — chậm không xảy ra ngay từ đầu mà xuất hiện sau một khoảng thời gian tải cao liên tục. Đó chính là hình dạng của việc CPU credit cạn dần rồi hết.
• "CPU utilization is <30%" trong khi người dùng kêu chậm — nghịch lý này chỉ hợp lý khi instance đã bị ghìm (throttle) về mức baseline: nó không thể dùng CPU cao hơn nữa, nên chỉ số CPU trông thấp, ASG không thấy ngưỡng 60% và đứng yên.

Nói cách khác, đây không phải bài toán "thiếu instance" hay "thiếu phân tải" — mà là bài toán hết CPU credit của burstable instance.

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

A. Configure unlimited mode for the EC2 instances.

Burstable instance có một mức baseline CPU và tích luỹ CPU credit khi chạy dưới baseline. Khi cần, nó tiêu credit để burst lên trên baseline. Nhưng credit là hữu hạn: tải cao liên tục nhiều giờ sẽ đốt hết số credit đã tích, và sau đó instance bị kéo về đúng baseline — hiệu năng tụt, phản hồi chậm, đúng như hiện tượng "vài tiếng sau mới thấy chậm".

Unlimited mode là chế độ cấu hình credit cho phép instance burst trên baseline bao lâu tuỳ ý, kể cả khi đã hết credit tích luỹ. Bật nó lên thì trong suốt đợt khuyến mãi, instance duy trì được mức CPU cao mà nó thực sự cần, thay vì bị ghìm lại.

Đáp án này cũng giải thích luôn cả triệu chứng phụ: khi instance được phép burst thật sự, CPU utilization mới phản ánh đúng tải và mới có cơ hội vượt ngưỡng 60% để ASG hoạt động như thiết kế. Bản giải thích gốc chỉ ra đúng logic đó: credit đã bị dùng hết do burst liên tục, unlimited mode cho phép duy trì mức CPU cao xuyên suốt sự kiện bán hàng.

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

B. Create an Amazon CloudFront distribution for the Auto Scaling group. Sai ngay ở mức kỹ thuật: không thể tạo CloudFront distribution trỏ thẳng vào một Auto Scaling group — ASG không phải origin được hỗ trợ. Muốn đặt CloudFront trước fleet EC2 thì phải có một ELB làm origin. Ngoài ra, kể cả khi dựng được, CloudFront giảm tải bằng cache nội dung ở edge — nó không sửa được nguyên nhân gốc là instance bị ghìm về baseline khi hết credit.

C. Add an Elastic Load Balancer and enable ELB health checks. Đây là phương án nghe "đúng bài" nhất vì ELB gắn liền với Auto Scaling group, nên dễ chọn nhầm. Nhưng nó hỏng ở chỗ giải quyết sai vấn đề: ELB health check chỉ giúp phát hiện và thay thế instance bị báo unhealthy. Instance hết CPU credit vẫn hoàn toàn healthy — nó vẫn trả lời health check, chỉ là chậm. Phân tải đều hơn giữa các instance cũng vô nghĩa khi cả fleet cùng cạn credit một lúc, vì tất cả đều chịu chung một đợt tải kéo dài.

D. Modify the Auto Scaling group to use EBS-optimized EC2 instances. EBS optimization dành riêng cho băng thông I/O giữa instance và EBS volume. Đề bài không có bất kỳ dấu hiệu nào của nghẽn disk I/O — triệu chứng được nêu rõ ràng là CPU và ngưỡng CPU của ASG. Đổi sang EBS-optimized không cấp thêm một chút CPU credit nào, nên instance vẫn bị ghìm về baseline đúng như cũ.

📌 Điểm cần nhớ

• Thấy "burstable performance" trong đề là phải nghĩ ngay tới CPU credit và baseline, không phải tới số lượng instance.
• Triệu chứng đặc trưng của cạn CPU credit: hiệu năng bình thường lúc đầu, tụt sau vài giờ tải cao liên tục, mà CPU utilization báo cáo lại thấp — vì instance đã bị ghìm về baseline nên không thể đẩy CPU lên cao hơn.
• Hệ quả trực tiếp: Auto Scaling dựa trên ngưỡng CPU sẽ không kích hoạt với burstable instance bị throttle, vì chỉ số CPU không bao giờ chạm ngưỡng. Đừng vội kết luận "cấu hình ASG sai".
• Unlimited mode là chế độ credit cho phép burst trên baseline liên tục bao lâu tuỳ nhu cầu — cách xử lý trực tiếp cho tải cao kéo dài trên họ T.
• Auto Scaling group không phải origin hợp lệ của CloudFront; muốn đặt CloudFront trước fleet EC2 thì cần một ELB đứng giữa.

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

Đề mô tả một kiến trúc rất gọn: nội dung media nằm trong Amazon S3, phân phối ra toàn cầu qua một CloudFront distribution. Vì ràng buộc pháp lý/hợp đồng ở một số quốc gia, nội dung không được xem tại những nước đó.

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

• "served through an Amazon CloudFront distribution" — mọi request của người dùng đều đi qua CloudFront. Điểm chặn hợp lý nhất phải nằm ngay tại lớp phân phối này, chứ không phải ở origin hay ở tầng DNS. Đây cũng là lý do loại được những phương án gắn với EC2/subnet: kiến trúc trong đề không có EC2, không có subnet nào để chặn.
• "MOST cost effective" — đề không hỏi "cách nào chặn được", mà hỏi cách rẻ nhất. Nhiều phương án về lý thuyết có thể chặn được phần nào, nhưng đòi thêm hạ tầng hoặc thêm công vận hành.
• "in certain countries" / "specific countries" — ràng buộc là theo quốc gia, không phải theo dải IP. Giải pháp nào bắt bạn tự dịch "quốc gia" thành "danh sách IP" là đã đi sai tầng trừu tượng.

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

C — Bật geo restriction trên CloudFront distribution và tạo blacklist các nước bị cấm.

CloudFront có sẵn tính năng geo restriction (còn gọi là geo blocking), sinh ra đúng cho nhu cầu này. Bình thường CloudFront phục vụ nội dung bất kể người dùng ở đâu; khi bật geo restriction, bạn chọn một trong hai kiểu danh sách:

• whitelist — chỉ cho phép truy cập từ các nước trong danh sách được duyệt;
• blacklist — chặn truy cập từ các nước nằm trong danh sách bị cấm.

Đề nói "một số nước" bị cấm, phần còn lại của thế giới vẫn xem bình thường → blacklist là đúng kiểu danh sách.

Về chi phí: đây là cấu hình sẵn có của distribution, không cần dựng thêm tài nguyên nào, không có instance phải trả tiền theo giờ, không phải tự duy trì bảng IP. Việc phân giải quốc gia do chính CloudFront lo, và việc chặn xảy ra ngay tại edge location, tức là trước cả khi request chạm tới S3. Đó chính là nghĩa "MOST cost effective" trong đề.

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

A — Tạo secondary origin access identity (OAI), cấu hình S3 bucket policy để chặn các nước không được phép.

Đây là phương án nghe "gần đúng" nhất vì nó có nhắc đúng hai thành phần trong đề (OAI và bucket policy), nhưng hỏng ở ba chỗ:

• Bạn không thể gắn nhiều OAI cho cùng một bucket theo kiểu này; "secondary OAI" không phải là cơ chế phân loại người dùng theo quốc gia.
• S3 bucket policy không hiểu khái niệm "quốc gia" — muốn chặn theo nước bạn phải liệt kê một danh sách IP khổng lồ và tự cập nhật khi các dải IP thay đổi. Đó là gánh nặng vận hành, ngược hẳn với yêu cầu rẻ nhất.
• Quan trọng hơn: OAI dùng để CloudFront truy cập S3. Người dùng cuối nói chuyện với CloudFront, và nội dung đã cache ở edge vẫn được phục vụ mà không cần quay về S3 — nên chặn ở bucket policy có thể không chặn được gì cả.

B — Cập nhật Network ACL với rule deny theo IP của các nước bị cấm.

Network ACL là lớp lọc gói tin ở biên của subnet trong VPC. Kiến trúc trong đề chỉ có S3 và CloudFront — không có EC2 instance nào nằm trong subnet, nên đơn giản là không có chỗ để áp Network ACL. Ngoài ra nó cũng vướng đúng vấn đề như A: NACL làm việc với dải IP, không làm việc với tên quốc gia.

D — Dùng Route 53 geolocation routing, đưa traffic từ các nước bị cấm sang một website EC2 trả về 403 Forbidden.

Đây là phương án hoạt động được nhưng thất bại ở tiêu chí chi phí. Bạn phải dựng và duy trì một EC2 instance chỉ để trả về mã 403 — trả tiền theo giờ, phải vá lỗi, phải giám sát, phải tính đến chuyện nó chết. So với việc tick một ô cấu hình trên distribution thì đây là lãng phí rõ ràng. Thêm nữa, geolocation routing của Route 53 chặn ở tầng DNS, vốn thô hơn: kết quả DNS có thể bị cache, và người dùng đổi DNS resolver là đã có thể lệch kết quả định tuyến.

📌 Điểm cần nhớ

• Chặn theo quốc gia cho nội dung sau CloudFront → nghĩ ngay tới CloudFront geo restriction; chọn whitelist khi chỉ vài nước được phép, blacklist khi chỉ vài nước bị cấm.
• Bất cứ phương án nào bắt bạn tự dịch quốc gia thành danh sách dải IP (bucket policy, Network ACL, security group) đều là dấu hiệu sai tầng: danh sách đó khổng lồ và luôn thay đổi.
• Network ACL chỉ tồn tại trong VPC/subnet. Kiến trúc chỉ gồm S3 + CloudFront thì mọi phương án nhắc tới NACL đều loại được ngay từ đầu.
• Với nội dung đã cache ở edge, chặn tại origin (S3) không đảm bảo chặn được người dùng — phải chặn tại lớp phân phối thì mới chắc.
• Đề hỏi "MOST cost effective" thì phương án đòi dựng thêm compute (EC2) gần như luôn thua phương án chỉ cần bật một tính năng có sẵn của dịch vụ managed.

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

Đề mô tả một công ty đang dùng AWS Organizations và muốn triển khai tag policies để chuẩn hoá thẻ (tag) trên các tài nguyên trong toàn bộ tài khoản của tổ chức. Một SysOps administrator đã đăng nhập vào management account và đã có đủ quyền cần thiết, nhưng vẫn không bật được tag policies.

Cụm từ quyết định nằm ở chính phần mô tả tình huống: "signs in to the organization's management account with the required permissions". Đây là kiểu câu loại trừ — đề cố tình gạch bỏ trước hai trong ba điều kiện tiên quyết để dùng tag policies:

• Đã đăng nhập đúng management account → loại nguyên nhân "sai tài khoản".
• Đã có quyền IAM cần thiết → loại nguyên nhân "thiếu permission".

Điều kiện tiên quyết còn lại chưa được đề nhắc tới chính là đáp án. Nói cách khác, câu hỏi không kiểm tra bạn biết tag policies làm gì, mà kiểm tra bạn có thuộc danh sách điều kiện tiên quyết của tag policies hay không.

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

B — Enable all features for the organization.

Tag policies yêu cầu ba điều kiện:

1. Tổ chức phải bật all features.
2. Phải đăng nhập vào management account của tổ chức.
3. Phải có quyền IAM phù hợp với AWS Organizations.

Đề đã xác nhận điều kiện 2 và 3 được thoả mãn. Vậy nguyên nhân khả dĩ nhất là tổ chức đang chạy ở chế độ consolidated billing only chứ chưa bật all features.

AWS Organizations có hai chế độ hoạt động (feature set). Chế độ mặc định hẹp hơn chỉ phục vụ gộp hoá đơn; toàn bộ nhóm tính năng quản trị dựa trên policy — trong đó có tag policies — chỉ khả dụng khi tổ chức đã chuyển sang all features. Chưa chuyển thì tuỳ chọn bật tag policies đơn giản là không dùng được, bất kể người dùng đứng ở tài khoản nào và có quyền gì. Bật all features là hành động thực hiện ở cấp tổ chức, từ management account, và chính nó mở khoá khả năng kích hoạt loại policy này.

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

A — Enable consolidated billing for the organization. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó cùng nói về "feature set" của Organizations. Nhưng consolidated billing là mức thấp hơn, không phải mức cần thiết: nó chỉ gom chi phí các tài khoản về một hoá đơn duy nhất, không mở ra bất kỳ cơ chế quản trị bằng policy nào. Thực tế, một tổ chức đang gặp đúng vấn đề trong đề rất có thể đã ở chế độ consolidated billing rồi — "bật" thêm nó không giải quyết được gì. Muốn dùng tag policies thì phải nâng lên all features.

C — Sign in to each member account and enable tag policies. Sai ở mô hình quản trị. Tag policies được tạo và bật tập trung tại management account, rồi gắn xuống root, OU hoặc từng tài khoản; member account không phải nơi kích hoạt loại policy này. Phương án này cũng mâu thuẫn trực tiếp với dữ kiện đề: administrator đã đứng đúng chỗ (management account) rồi, nên vấn đề không nằm ở việc đăng nhập nhầm tài khoản. Ngoài ra, nếu mỗi member account tự bật được thì tag policies mất luôn ý nghĩa "chuẩn hoá tập trung" mà công ty đang muốn.

D — Enable service control policies (SCPs) first. Sai vì SCPs và tag policies là hai loại policy độc lập trong AWS Organizations, không loại nào là điều kiện tiên quyết của loại nào. Bạn có thể bật tag policies mà không bật SCPs, và ngược lại. Điểm chung duy nhất giữa chúng là cả hai đều đòi tổ chức phải ở chế độ all features — nghĩa là nếu D "có vẻ giúp được", thì thứ thực sự giúp vẫn là all features, chứ không phải bản thân SCPs. Đây là kiểu bẫy nhầm lẫn giữa điều kiện chung và quan hệ phụ thuộc.

📌 Điểm cần nhớ

• Tag policies cần ba thứ: tổ chức bật all features, đứng ở management account, và có quyền IAM cho AWS Organizations. Đề bài loại bỏ hai thứ nào thì thứ còn lại là đáp án.
• Consolidated billing ≠ all features. Consolidated billing chỉ gom hoá đơn; mọi loại policy quản trị của Organizations (tag policies, SCPs, và các policy type khác) đều đòi all features.
• Các policy type trong Organizations độc lập với nhau. Không cần bật SCPs để dùng tag policies; đừng suy ra quan hệ phụ thuộc chỉ vì chúng cùng chung một điều kiện tiên quyết.
• Policy trong Organizations luôn quản lý tập trung từ management account, rồi gắn xuống root/OU/account. Phương án nào bảo "đăng nhập từng member account để bật" gần như luôn sai trong ngữ cảnh này.

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

Đề bài yêu cầu một giải pháp vừa caching content globally vừa delivering it only to authorized users — hai vế, và mỗi vế quyết định một nửa đáp án.

Cụm từ quyết định là "globally" đi kèm "only to authorized users". Chữ "globally" loại ngay ý tưởng phục vụ nội dung thẳng từ S3: bucket nằm ở một Region, muốn cache toàn cầu thì phải có CDN, tức CloudFront. Chữ "authorized users" nói rằng lớp kiểm soát truy cập phải nằm ở nơi người dùng thực sự gõ vào — mà nếu người dùng đi qua CloudFront thì nơi đó là CloudFront, không phải S3.

Cả bốn phương án đều nhắc tới S3 và ba trong bốn phương án đều có CloudFront + OAI, nên điểm phân biệt thật sự nằm ở loại signed/presigned URL và cách CloudFront lấy được nội dung từ bucket. Đó chính là hai chỗ cần soi.

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

Đáp án đúng theo tệp là A.

Phương án A ghép đúng ba mảnh, mỗi mảnh giải quyết một yêu cầu:

• S3 bucket với public access disabled — nội dung không thể bị lấy trực tiếp từ bucket, mọi đường vào đều bắt buộc đi qua CDN.
• CloudFront distribution dùng origin access identity (OAI) — OAI là một danh tính đặc biệt do CloudFront tạo ra, được cấp quyền đọc bucket qua bucket policy. Nhờ nó, CloudFront đọc được object trong khi thế giới bên ngoài thì không. Đây là cách chuẩn để "khoá cửa sau" của origin.
• CloudFront signed URLs — ứng dụng tự phát URL đã ký cho từng người dùng đã xác thực. CloudFront kiểm chữ ký ngay tại edge location; URL không hợp lệ hoặc hết hạn thì bị từ chối trước khi chạm tới origin.

Kết quả: nội dung được cache ở các edge location trên toàn cầu (vế "globally"), và chỉ ai cầm URL đã ký mới xem được (vế "authorized users").

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

B — S3 presigned URLs thay vì CloudFront signed URLs. Đây là phương án gần đúng nhất và là bẫy chính của câu này. Hai mảnh đầu (public access disabled + OAI) hoàn toàn đúng; chỗ hỏng nằm ở mảnh cuối. S3 presigned URL là cơ chế của S3, dùng để cấp quyền truy cập tạm thời vào chính endpoint S3. Nhưng ở kiến trúc này người dùng đâu có gọi vào S3 — họ gọi vào CloudFront. Hơn nữa, quyền vào bucket đã được siết bằng public access setting và OAI rồi, nên presigned URL của S3 vừa thừa vừa đặt sai chỗ: nó không hề kiểm soát ai được đi qua distribution. Muốn chặn ở edge thì phải dùng CloudFront signed URL.

C — dùng IAM role gán cho CloudFront distribution. Vế signed URL ở đây đúng, nhưng cách cho CloudFront đọc bucket thì sai về mặt cơ chế. Bạn không "gán một IAM role" cho một CloudFront distribution để nó đọc S3 — mô hình uỷ quyền giữa CloudFront và S3 origin được thiết lập qua origin access identity kết hợp với bucket policy, chứ không phải qua role như cách một EC2 instance hay một Lambda function nhận quyền. Phương án này mô tả một cấu hình không tồn tại theo cách nó viết, nên dù nửa sau nghe hợp lý thì tổng thể vẫn không dựng lên được.

D — public access enabled + field-level encryption + S3 presigned URLs. Phương án này sai ở cả ba mảnh. Bật public access trên bucket là tự tay mở đường đi thẳng vào nội dung, phá hỏng toàn bộ ý định "chỉ cho người được phép" — ai biết URL của object là lấy được, chẳng cần URL ký nào. Field-level encryption là tính năng bảo vệ dữ liệu nhạy cảm mà người dùng gửi lên trong form, mã hoá ở edge để chỉ ứng dụng phía sau mới giải được; nó không liên quan gì tới việc kiểm soát ai được tải nội dung xuống. Còn S3 presigned URL thì lặp lại đúng lỗi của phương án B: đặt lớp kiểm soát ở S3 trong khi lối vào thật là CloudFront.

📌 Điểm cần nhớ

• Chặn ở nơi người dùng gõ vào. Người dùng đi qua CloudFront thì dùng CloudFront signed URL/signed cookie; người dùng gọi thẳng S3 thì mới dùng S3 presigned URL. Đề nào có CloudFront đứng trước mà đáp án đưa presigned URL của S3 ra làm lớp kiểm soát truy cập thì gần như chắc chắn là bẫy.
• OAI là cầu nối giữa CloudFront và S3 origin, đi kèm bucket policy và public access bị tắt. Đó là cách chuẩn để nội dung chỉ ra ngoài qua CDN; "gán IAM role cho distribution" không phải là mô hình được dùng ở đây.
• Tách bạch hai lớp bảo vệ: khoá origin (OAI + tắt public access) và khoá người xem (signed URL). Một đáp án chỉ làm một trong hai là chưa đủ với đề đòi cả "cache toàn cầu" lẫn "chỉ người được phép".
• Field-level encryption bảo vệ dữ liệu người dùng gửi lên, không phải công cụ giới hạn ai được tải nội dung xuống — đừng để nó lôi kéo chỉ vì nghe có chữ "encryption".

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

Đề mô tả một EC2 instance chạy website và yêu cầu website đó "must be directly accessible from the internet" — truy cập trực tiếp từ Internet, tức là lưu lượng đi vào (inbound) khởi tạo từ phía ngoài. Đây là cụm từ quyết định toàn bộ câu trả lời.

Hai chi tiết còn lại của đề đóng vai trò loại trừ:

• "a subnet that is configured to auto assign public IP addresses" — instance đã có địa chỉ public IPv4. Vậy thứ còn thiếu không phải là địa chỉ, mà là đường đi.
• Route table hiện có đúng hai dòng: 10.0.0.0/16 → Local (lưu lượng trong VPC) và 172.31.0.0/16 → pcx-... (một VPC peering connection). Không có dòng nào cho 0.0.0.0/0, nghĩa là mọi đích ngoài hai dải trên đều không có tuyến — subnet này hiện là private subnet.

Chú ý thêm: cả địa chỉ VPC lẫn dải peering đều là IPv4, và public IP được auto-assign cũng là public IPv4. Chi tiết IPv4 là mấu chốt phân biệt phương án A với phương án B.

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

Đáp án đúng là B — thêm route 0.0.0.0/0 trỏ tới internet gateway.

Định nghĩa của AWS rất thẳng: subnet gắn với route table có route tới internet gateway thì gọi là public subnet; không có thì là private subnet. Ở đây subnet đang thiếu đúng route đó, nên dù instance có public IPv4 thì gói tin vẫn không có đường ra/vào Internet.

Internet gateway là thành phần duy nhất trong danh sách vừa làm hai việc cần cho một website public: nó thực hiện NAT một-một giữa private IP của instance và public IP của nó, và nó cho phép kết nối khởi tạo từ bên ngoài đi vào. Route 0.0.0.0/0 là "mọi đích chưa được biết tới trong route table", nên nó bắt trọn phần Internet mà không đụng tới hai dòng cụ thể hơn đã có — route table luôn khớp theo prefix dài nhất, nên lưu lượng nội bộ VPC vẫn đi qua Local và lưu lượng tới 172.31.0.0/16 vẫn đi qua peering.

Về nguyên tắc bạn có thể thu hẹp route thành một dải public hẹp hơn thay vì 0.0.0.0/0, nhưng với một website phục vụ Internet nói chung thì 0.0.0.0/0 là lựa chọn đúng.

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

A. 0.0.0.0/0 trỏ tới egress-only internet gateway. Sai hai lớp. Thứ nhất, egress-only internet gateway chỉ dành cho IPv6, trong khi đề đang nói về public IPv4 — với IPv6 thì route phải viết là ::/0, không phải 0.0.0.0/0. Thứ hai, ngay cả trong ngữ cảnh IPv6, chữ egress-only đã nói hết: nó chỉ cho lưu lượng đi ra, chặn mọi kết nối khởi tạo từ Internet vào. Mà đề yêu cầu website phải accessible from the internet — đúng chiều mà thành phần này chặn.

D. 0.0.0.0/0 trỏ tới NAT gateway. Đây là phương án gần đúng và hay bị chọn nhầm, vì NAT gateway cũng liên quan tới Internet và cũng dùng route 0.0.0.0/0. Nhưng NAT gateway phục vụ chiều ngược lại: nó cho instance trong private subnet đi ra Internet (tải bản vá, gọi API), và bản chất NAT nhiều-một của nó không có ánh xạ nào để chuyển một kết nối từ ngoài vào đúng instance bên trong. Dùng NAT gateway thì website sẽ ra được Internet nhưng không ai từ Internet vào được, đúng thứ đề đòi hỏi. Ngoài ra bản thân NAT gateway lại phải nằm trong một public subnet, tức vẫn cần một internet gateway ở đâu đó — nó không thay thế được internet gateway.

C. 0.0.0.0/0 trỏ tới một elastic network interface. Trỏ route tới một ENI là mẫu hợp lệ về mặt cú pháp, nhưng nó dùng khi bạn muốn đẩy lưu lượng qua một appliance tự vận hành (firewall, proxy, NAT instance) chạy trên EC2. Bản thân ENI không phải là cửa ra Internet — nó chỉ là card mạng của một instance khác, và instance đó lại cần chính một route tới internet gateway mới ra ngoài được. Đề không hề nhắc tới appliance nào, nên phương án này vừa không giải quyết được vấn đề, vừa thêm một thành phần không tồn tại trong kịch bản.

📌 Điểm cần nhớ

• Public IP không đủ, phải có route. Auto-assign public IPv4 chỉ cấp địa chỉ; subnet chỉ thành public subnet khi route table của nó có đường tới internet gateway.
• Phân biệt theo chiều lưu lượng: internet gateway = vào và ra; NAT gateway và egress-only internet gateway = chỉ ra. Thấy đề nói "accessible from the internet" / "inbound" thì loại ngay hai cái sau.
• Phân biệt theo họ địa chỉ: NAT gateway dành cho IPv4, egress-only internet gateway dành cho IPv6. Route 0.0.0.0/0 là IPv4, ::/0 là IPv6 — nhìn cú pháp route cũng đủ phát hiện phương án lệch họ địa chỉ.
• Route table khớp theo prefix dài nhất, nên thêm 0.0.0.0/0 không phá vỡ các dòng cụ thể hơn như Local hay VPC peering đang có sẵn.

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

Bối cảnh: một công ty có nhiều AWS account cho các bộ phận phát triển, cộng thêm một account riêng cho nhóm security admin. Nhóm security admin cần xem lại (review) cấu hình các tài nguyên Amazon EC2 trong những development account để kiểm tra xem có tuân thủ security best practices hay không.

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

• "review the configuration" — họ chỉ đọc cấu hình, không tạo, không sửa, không xoá gì. Nhu cầu thật sự là read-only đối với EC2.
• "in the MOST secure manner" — đề không hỏi "cách nào chạy được", mà hỏi cách an toàn nhất. Cả bốn phương án đều "chạy được" theo nghĩa security admin sẽ nhìn thấy EC2; điểm khác biệt nằm ở hai trục: (1) mức quyền cấp ra, (2) cơ chế xác thực giữa hai account.

Thêm một chi tiết nền: đây là bài toán truy cập cross-account. Security admin đăng nhập bằng danh tính trong account của chính họ, còn tài nguyên nằm ở account khác — nên câu hỏi thực chất là "IAM user với credentials chia sẻ" hay "IAM role cho phép assume từ account kia".

Bốn phương án là tổ hợp đầy đủ 2×2 của hai trục đó: {read-only, administrator} × {IAM user chia sẻ credentials, cross-account IAM role}. Chọn đúng nghĩa là chọn ô tốt nhất trên cả hai trục.

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

Đáp án đúng theo tệp là D: tạo IAM policy read-only cho EC2 trong từng development account, gán policy đó vào một cross-account IAM role, rồi để security admin assume role đó từ account của họ.

• Read-only khớp chính xác yêu cầu — nhóm security chỉ cần đọc cấu hình EC2. Đây là áp dụng nguyên tắc least privilege: cấp đúng mức quyền công việc đòi hỏi, không hơn.
• Cross-account IAM role là cơ chế chuẩn của AWS cho truy cập giữa các account. Role không có credentials dài hạn gắn kèm; khi assume role, người dùng nhận temporary credentials có thời hạn thông qua STS. Trust policy của role quy định rõ account nào (và principal nào trong account đó) được phép assume.
• Danh tính của security admin vẫn nằm nguyên trong account của họ. Muốn thêm/bớt người, chỉ cần sửa quyền trong account security — không phải đụng vào từng development account. Muốn cắt truy cập, chỉ cần sửa trust policy hoặc xoá role.
• Mọi lời gọi API đều gắn với danh tính gốc đã assume role, nên vẫn truy vết được ai đã làm gì — điều mà credentials dùng chung không cho phép.

D là phương án duy nhất tốt nhất trên cả hai trục: quyền tối thiểu + cơ chế xác thực tạm thời.

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

A. Read-only policy, gán cho IAM user, chia sẻ credentials. Đây là phương án gần đúng nhất — mức quyền đã chuẩn (read-only), nhưng hỏng ở khâu xác thực. Chia sẻ credentials của IAM user nghĩa là access key / mật khẩu dài hạn được truyền tay giữa nhiều người: không xoay vòng tự động, không hết hạn, và trong CloudTrail mọi hành động đều hiện ra dưới cùng một danh tính nên không biết ai thực sự thao tác. Người rời nhóm vẫn giữ được credentials cho tới khi có ai nhớ ra mà thu hồi. Ngoài ra còn phải nhân bản user này ở mỗi development account, quản lý càng phình ra.

B. Administrator access lên mọi EC2 action, gán cho IAM user, chia sẻ credentials. Hỏng ở cả hai trục cùng lúc — vừa vượt xa mức quyền cần thiết (được phép terminate instance, sửa security group... trong khi chỉ cần đọc), vừa dùng credentials dài hạn chia sẻ. Đây là phương án kém an toàn nhất trong bốn.

C. Administrator access lên EC2, gán cho cross-account IAM role. Cơ chế xác thực đã đúng — role + credentials tạm thời, đúng mô hình cross-account. Nhưng mức quyền sai: đề chỉ yêu cầu review configuration, mà C cấp quyền quản trị đầy đủ trên EC2. Vi phạm least privilege, và với câu hỏi hỏi "MOST secure" thì quyền dư luôn là lý do bị loại. Đây là cái bẫy dành cho người đọc lướt, thấy "cross-account role" là chọn ngay mà không kiểm lại mức quyền.

📌 Điểm cần nhớ

• Truy cập cross-account trong AWS: câu trả lời gần như luôn là IAM role + assume role, không bao giờ là tạo IAM user rồi chia sẻ access key. Thấy cụm "share the user credentials" trong phương án thì gạch trước, tính sau.
• Role cấp temporary credentials qua STS và giữ được truy vết danh tính gốc trong CloudTrail; credentials dài hạn dùng chung thì mất cả hai tính chất đó.
• Cụm động từ trong đề định ra mức quyền: "review", "audit", "view", "monitor" → read-only. Nếu một phương án cấp administrator cho một nhiệm vụ chỉ đọc, nó sai vì least privilege, kể cả khi phần còn lại của phương án hoàn toàn đúng.
• Với câu hỏi dạng "MOST secure", các phương án thường là tổ hợp 2×2 của hai trục độc lập (mức quyền × cơ chế xác thực). Chấm điểm từng trục riêng rồi tìm phương án thắng cả hai — đừng dừng lại ở phương án chỉ thắng một trục.