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

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

Bộ phận bảo mật yêu cầu bắt buộc (enforce) server-side encryption cho mọi object mới được upload lên bucket digitalcloud-encrypted. Câu hỏi hỏi cách để cưỡng chế điều này.

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

• "enforce" — không phải "khuyến khích" hay "mặc định giúp", mà là chặn hẳn: object không mang thông tin mã hoá thì phải bị từ chối. Cơ chế duy nhất trong danh sách phương án làm được việc từ chối là một policy có "Effect": "Deny".
• "all new objects uploaded" — chỉ áp cho object mới, không cần xử lý object đã có sẵn trong bucket. Đây là lý do không cần bất kỳ thao tác mã hoá lại dữ liệu cũ nào.
• "all objects uploaded to the bucket" — phạm vi là toàn bộ object trong bucket, bất kể ai upload. Ràng buộc này loại luôn những cách chỉ tác động lên một người dùng cụ thể hoặc một lần upload cụ thể, và nó cũng chính là chỗ phân biệt hai phương án B và C vốn có nội dung JSON gần như giống hệt nhau.

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

Đáp án đúng theo tệp là C — gắn policy vào bucket (bucket policy):

"Effect": "Deny",
"Action": "s3:PutObject",
"Resource": "arn:aws:s3:::digitalcloud-encrypted/*",
"Condition": { "Null": { "s3:x-amz-server-side-encryption": "true" } }

Cách đọc câu điều kiện: Null kiểm tra xem key s3:x-amz-server-side-encryption có vắng mặt trong request hay không. Giá trị "true" ở đây nghĩa là "key này null / không được gửi lên". Ghép lại: nếu request PutObject không kèm header server-side-encryption thì Deny. Kết quả là mọi lần upload thiếu chỉ dẫn mã hoá đều bị chặn — đúng nghĩa "enforce" mà đề đòi.

Hai chi tiết khiến C đúng còn B sai dù JSON gần như trùng nhau:

• Gắn vào bucket: bucket policy là resource-based policy, áp cho mọi principal chạm vào bucket đó ("Principal": "*"), nên phủ được yêu cầu "all objects uploaded to the bucket".
• Resource kết thúc bằng /*: ARN của bucket (.../digitalcloud-encrypted) và ARN của các object bên trong (.../digitalcloud-encrypted/*) là hai thứ khác nhau. s3:PutObject tác động lên object, nên statement phải trỏ tới /* mới khớp. Thiếu dấu này thì statement không bao giờ được kích hoạt.

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

A. Enable Amazon S3 default encryption on the objects. Ý tưởng default encryption đúng hướng — nó thật sự là một cách hợp lệ để mọi object mới được mã hoá. Nhưng phương án này sai ở chỗ cấp áp dụng: default encryption là thiết lập ở mức bucket, không có thứ gọi là "default encryption trên object". Object thì hoặc đã mã hoá hoặc chưa, chứ không có "mặc định" nào để bật. Đây là phương án gài bẫy bằng cách lấy một khái niệm đúng rồi đặt sai chỗ.

B. Thêm đúng policy đó vào IAM user permissions policy. Đây là phương án gần đúng nhất và hỏng ở hai điểm riêng biệt:

1. Sai loại policy: đề yêu cầu mọi object upload lên bucket đều bị ràng buộc. IAM user policy chỉ ràng buộc đúng (những) IAM identity được gắn policy đó. Người dùng khác, role khác, hay cross-account access đều lọt qua. Muốn phủ toàn bucket thì phải dùng bucket policy. Ngoài ra "Principal": "*" là phần tử của resource-based policy — identity-based policy không dùng phần tử này.
2. Sai Resource: ARN ở đây là arn:aws:s3:::digitalcloud-encrypted/ — kết thúc bằng dấu gạch chéo trần, không có *. Nó không khớp với các object được upload, nên ngay cả khi đặt đúng chỗ thì statement cũng không chặn được gì.

D. Tạo presigned URL cho thao tác PUT với cờ server-side encryption rồi gửi URL cho người dùng. Presigned URL chỉ là một lần cấp quyền tạm thời cho một thao tác cụ thể, gửi cho một người cụ thể. Nó không phải cơ chế cưỡng chế: nó không ngăn ai đó upload bằng đường khác (console, CLI, SDK với credential của chính họ) mà không mã hoá. Cách này cũng không mở rộng được — mỗi lần upload lại phải sinh và phát một URL mới. Việc "enforce" phải nằm ở policy bám vào bucket, không nằm ở cách phát quyền cho từng lượt.

📌 Điểm cần nhớ

• Thấy chữ "enforce" hoặc "prevent uploads of unencrypted objects" trong đề S3 → nghĩ ngay tới bucket policy có Deny kèm điều kiện Null trên s3:x-amz-server-side-encryption. Default encryption mã hoá giúp nhưng bản thân nó không từ chối request.
• arn:aws:s3:::bucket và arn:aws:s3:::bucket/* là hai resource khác nhau. Action tác động lên object (s3:PutObject, s3:GetObject) phải dùng dạng có /*. Trong đề thi, hai phương án chỉ khác nhau đúng dấu * này là chuyện rất thường gặp — đọc kỹ đuôi ARN trước khi chọn.
• Bucket policy (resource-based) phủ mọi principal; IAM policy (identity-based) chỉ phủ identity được gắn. Yêu cầu dạng "all objects / all users / toàn bucket" thì chọn bucket policy. Có "Principal" trong JSON cũng là dấu hiệu policy đó thuộc về resource, không thuộc về user.
• Presigned URL là cơ chế cấp quyền tạm thời, không phải cơ chế kiểm soát bắt buộc. Nó không bịt được các đường truy cập khác nên không bao giờ là đáp án cho câu hỏi "làm sao bắt buộc mọi upload phải tuân thủ".

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

Đề mô tả một tình huống rất cụ thể: một SysOps Administrator vẫn thường xuyên SSH vào EC2 instance từ mạng công ty, nay làm việc ở nhà và nhận connection timeout.

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

• "typically manages ... using SSH from the corporate network" — nghĩa là đường SSH này vốn hoạt động bình thường. Instance đang chạy, sshd đang lắng nghe, người dùng có key hợp lệ. Thứ duy nhất thay đổi là địa chỉ IP nguồn.
• "connection timeout error" — timeout khác hẳn với connection refused hay permission denied. Timeout nghĩa là gói tin đi ra mà không có phản hồi nào quay lại, tức là bị chặn ở tầng mạng chứ không phải bị từ chối ở tầng xác thực.

Ghép hai dữ kiện: có một bộ lọc mạng đang cho phép dải IP của văn phòng nhưng không cho phép dải IP nhà riêng. Đó chính là security group của EC2 instance.

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

B — Security group không cho phép inbound traffic từ mạng nhà trên cổng SSH.

Security group là stateful firewall gắn ở mức ENI của instance. Rule inbound của nó gồm protocol, port range và source — thường được khai bằng CIDR. Trong tình huống này, rule SSH gần như chắc chắn được khai với CIDR của mạng công ty.

Điểm mấu chốt: khi security group không có rule khớp, nó âm thầm loại bỏ gói tin (drop) chứ không gửi lại gói từ chối. Client không nhận được gì, phải chờ hết thời gian rồi báo timeout — đúng triệu chứng đề mô tả. Cách xử lý là sửa security group, thêm CIDR của mạng nhà (hoặc IP công cộng hiện tại của Administrator) vào rule inbound cổng SSH.

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

A — IAM role gắn với EC2 instance không cho phép SSH từ mạng nhà.

Sai vì nhầm tầng. IAM role gắn vào instance là để workload bên trong instance gọi AWS API, nó không tham gia vào việc quyết định ai được mở kết nối SSH tới instance. SSH được xác thực bằng key pair và cấu hình của sshd trong hệ điều hành, hoàn toàn nằm ngoài IAM. Chính sách IAM có thể ràng buộc theo điều kiện IP nguồn cho các lời gọi API, nhưng đó là chuyện khác — nó không lọc lưu lượng SSH đi vào instance.

C — Mạng nhà của Administrator không có route tới internet gateway trong route table.

Đây là phương án gần đúng nhất và cũng là cái bẫy chính, vì "internet gateway + route table" đúng là những khái niệm gây timeout thật. Nhưng nó đặt sai chỗ: internet gateway và route table là thành phần của VPC trên AWS, không phải của mạng gia đình. Mạng nhà chỉ cần có kết nối Internet thông thường; nó không hề có, và không thể có, route table trỏ tới một internet gateway của AWS. Về phía instance, việc kết nối được từ mạng công ty đã chứng minh đường ra Internet của VPC vốn đã hoạt động.

D — Key pair không cho phép kết nối từ mạng nhà.

Sai vì gán cho key pair một khả năng nó không có. Key pair chỉ là cặp khoá public/private dùng để xác thực danh tính, nó hoàn toàn không biết gì về vị trí địa lý hay địa chỉ IP của người kết nối. Ngoài ra, nếu vấn đề nằm ở key, triệu chứng sẽ là lỗi xác thực (Permission denied (publickey)) sau khi TCP đã bắt tay xong — chứ không phải timeout.

📌 Điểm cần nhớ

• Đọc kỹ loại lỗi để đoán tầng hỏng: timeout = gói tin bị drop ở tầng mạng (security group, network ACL, routing); connection refused = tới được đích nhưng không có dịch vụ nghe; permission denied = mạng thông rồi, hỏng ở tầng xác thực.
• "Trước đây chạy được, giờ đổi một thứ nên hỏng" là mẫu đề rất phổ biến. Hãy tìm đúng thứ đã đổi — ở đây là IP nguồn — rồi tìm thành phần nào lọc theo đúng thứ đó.
• Đừng lẫn tầng xác thực với tầng mạng: IAM role và key pair kiểm soát bạn là ai và được làm gì; security group kiểm soát gói tin nào được đi qua. Bài toán lọc theo địa chỉ IP luôn thuộc về security group hoặc network ACL.
• Internet gateway và route table là khái niệm bên trong VPC, không áp dụng cho mạng của người dùng cuối. Phương án nào gán thuật ngữ AWS cho hạ tầng phía client thường là phương án sai được dựng lên để đánh lừa.

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

Đội bảo mật yêu cầu mọi EBS volume phải được mã hoá bằng một KMS CMK cụ thể. Người quản trị không phải đi áp đặt chính sách đó, mà phải kiểm chứng (verify) rằng yêu cầu đã được thực hiện.

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

• "verifying that the request has been implemented" — đây là bài toán kiểm tra tuân thủ trên tài nguyên đang tồn tại, không phải bài toán ngăn chặn hành vi trong tương lai. Cụm này loại thẳng nhóm phương án mang tính phòng ngừa.
• "MOST efficient way" — không hỏi "cách nào chạy được", mà hỏi cách tốn ít công vận hành nhất. Nhiều phương án ở đây có thể cho ra danh sách volume, nhưng chúng đòi người hoặc code tự viết chạy định kỳ.
• Thêm một chi tiết nữa: yêu cầu không dừng ở "đã mã hoá hay chưa" mà là "encrypted with a specific CMK" — nên giải pháp phải phân biệt được volume mã hoá bằng đúng key với volume mã hoá bằng key khác.

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

C — Dùng AWS Config với managed rule encrypted-volumes và chỉ định key ID của CMK.

encrypted-volumes là một managed rule có sẵn của AWS Config: nó kiểm tra các EBS volume đang ở trạng thái attached xem đã được mã hoá chưa. Điểm mấu chốt khớp với đề bài là rule này có tham số kmsId — khi khai key ID của CMK vào đó, rule không chỉ hỏi "có mã hoá không" mà hỏi "có mã hoá bằng đúng key này không". Volume mã hoá bằng key khác sẽ bị đánh dấu NON_COMPLIANT.

Về mặt "MOST efficient": đây là rule dựng sẵn, chỉ cần bật và điền tham số — không viết code, không tự lên lịch, không ai phải đăng nhập console mỗi ngày. AWS Config tự đánh giá lại khi cấu hình tài nguyên thay đổi và giữ luôn lịch sử tuân thủ, đúng bản chất việc "verify" mà đề yêu cầu.

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

A — Đăng nhập Management Console hằng ngày, lọc theo trạng thái mã hoá rồi export danh sách. Đây là quy trình thủ công lặp lại mỗi ngày, ngược hẳn với tiêu chí "MOST efficient" — tốn công người, dễ bỏ sót, không có bản ghi tuân thủ tự động. Ngoài ra bộ lọc theo encryption status chỉ trả lời "đã mã hoá / chưa mã hoá", trong khi đề hỏi mã hoá bằng đúng CMK nào, nên tự nó còn chưa trả lời trọn câu hỏi.

B — Tạo SCP trong AWS Organizations chỉ cho phép các API action encrypt dùng đúng KMS CMK. Sai ở hai tầng. Thứ nhất, sai về mục đích: SCP là hàng rào phòng ngừa cho hành động tương lai, nó không kiểm tra và không báo cáo gì về các volume đã tồn tại — mà đề yêu cầu verify hiện trạng. Thứ hai, theo phần giải thích của nguồn, cách diễn đạt "hạn chế API action theo KMS key" như phương án mô tả là không thực hiện được. Đây là phương án dễ chọn nhầm vì nghe rất "bảo mật", nhưng nó giải sai bài toán ngay từ đầu.

D — Lambda chạy theo lịch hằng ngày, gọi aws ec2 describe-volumes --filters encrypted. Đây là phương án gần đúng nhất và cũng là bẫy chính. Về kỹ thuật nó có chạy được, nhưng hỏng ở chỗ: bạn phải tự viết hàm, tự cấp IAM role, tự đặt lịch, tự xử lý kết quả và tự bảo trì đoạn code đó — trong khi AWS Config đã có sẵn đúng rule cho việc này. So với C thì đây là tự dựng lại bánh xe, nên trượt tiêu chí "MOST efficient". Chưa kể bộ lọc encrypted chỉ phân loại theo cờ mã hoá; muốn đối chiếu tới đúng CMK thì còn phải viết thêm logic so KmsKeyId, càng làm khoảng cách với C rộng ra.

📌 Điểm cần nhớ

• "Verify / audit / check compliance" trên tài nguyên đang tồn tại → nghĩ AWS Config trước tiên. Ngược lại, "prevent / enforce / deny" hành động tương lai → nghĩ SCP hoặc IAM policy. Đọc đúng động từ trong đề là gần như xong câu hỏi.
• Managed rule luôn thắng script tự viết khi đề nhấn "MOST efficient / least operational overhead". Lambda + EventBridge là câu trả lời "chạy được nhưng tốn công", thường được đặt vào đề đúng để dụ người chọn.
• encrypted-volumes có tham số kmsId — nhớ chi tiết này vì nó là thứ phân biệt "đã mã hoá" với "mã hoá bằng đúng CMK mà bảo mật yêu cầu". Rule này xét volume ở trạng thái attached.
• SCP không sinh ra báo cáo tuân thủ. Dù SCP có chặn được điều gì đó đi nữa, nó vẫn không trả lời được câu hỏi "hiện tại có bao nhiêu volume sai key", nên trong các câu hỏi kiểu verify thì SCP hầu như luôn là phương án loại.

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

Đề mô tả một ứng dụng bán lẻ chạy trên nhóm EC2 instances do Auto Scaling group quản lý, đứng sau Elastic Load Balancer. Hiệu năng ổn định gần như cả ngày, chỉ trừ một khung 2 tiếng có lượng truy cập tăng vọt khiến thời gian phản hồi chậm đi.

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

• "a 2-hour window" — khung tăng tải là biết trước và lặp lại, không phải đột biến ngẫu nhiên. Tải có thể dự đoán theo lịch thì có thể chuẩn bị năng lực theo lịch.
• "MOST operationally efficient" — đề không hỏi cách nào chạy được, mà hỏi cách nào tốn ít công vận hành nhất. Ràng buộc này loại thẳng mọi phương án đòi con người thao tác lặp đi lặp lại mỗi ngày.

Ghép hai điều kiện lại: cần một cơ chế tự động, kích hoạt trước khung giờ cao điểm đã biết.

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

C — Cấu hình scheduled scaling policy cho Auto Scaling group để tự động tăng số EC2 instances trước khung 2 tiếng cao tải.

Scheduled scaling là tính năng của EC2 Auto Scaling cho phép khai báo thay đổi capacity (minimum, maximum, desired) theo thời điểm định sẵn, một lần hoặc lặp theo lịch. Nó khớp chính xác với bài toán:

• Tải tăng có quy luật thời gian, nên lịch là tín hiệu đáng tin cậy nhất — không cần chờ metric vượt ngưỡng rồi mới phản ứng.
• Instances được đưa vào trước thời điểm cao tải, nên chúng kịp khởi động, kịp qua health check của load balancer và kịp nhận traffic ngay từ phút đầu. Đây là điểm mấu chốt: nếu chỉ dựa vào scaling phản ứng theo metric, luôn có độ trễ giữa lúc tải tăng và lúc instance mới sẵn sàng phục vụ — chính khoảng trễ đó gây ra "slower response times" mà đề nói.
• Sau khung giờ, lịch có thể hạ capacity về mức thường, nên không phải trả tiền cho năng lực dư suốt 22 tiếng còn lại.
• Khai báo một lần, sau đó chạy tự động — đúng tinh thần "operationally efficient".

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

A — Thêm tay EC2 instances vào Auto Scaling group trước khung 2 tiếng.

Đây là phương án gần đúng nhất về mặt kỹ thuật: nó tăng đúng thứ cần tăng (số instances), đúng thời điểm (trước khung cao tải). Nó hỏng ở đúng chữ mà đề nhấn mạnh — operationally efficient. Việc này phải làm lại mỗi ngày, phụ thuộc vào một người nhớ và có mặt đúng giờ; quên một hôm, nghỉ phép, hoặc lệch múi giờ là hiệu năng lại tụt. Nó cũng đi ngược nguyên tắc tự động hoá hạ tầng trên cloud. So với C, hai phương án cho cùng một kết quả kỹ thuật, nhưng C thay công sức lặp lại của con người bằng một policy khai báo một lần — nên C thắng.

B — Giảm desired capacity của Auto Scaling group trong giờ thấp điểm để tiết kiệm tài nguyên.

Phương án này giải quyết sai vấn đề. Vấn đề đề nêu là chậm khi tải cao, còn B tối ưu chi phí khi tải thấp. Giảm capacity ngoài giờ cao điểm không thêm được một chút năng lực nào cho khung 2 tiếng đang nghẽn. Tệ hơn, nếu việc giảm này không được đảo ngược đúng lúc, hệ thống bước vào khung cao tải với capacity còn thấp hơn ban đầu, làm response time xấu đi chứ không tốt lên.

D — Nâng instance type trong Auto Scaling group lên loại lớn hơn.

Đây là scale up (vertical) thay vì scale out (horizontal). Nó có thể làm hệ thống chịu tải tốt hơn, nhưng phải trả giá cho instance lớn hơn suốt 24 tiếng, trong khi năng lực dư chỉ thật sự cần trong 2 tiếng. Đề đã nói rõ hiệu năng "remains steady for most parts of the day" — tức phần lớn thời gian instance hiện tại là đủ. Ngoài ra, đổi instance type thường kéo theo thay launch template và thay thế instance đang chạy, và năng lực vẫn cố định nên không co giãn theo nhu cầu — đúng thứ mà Auto Scaling group sinh ra để tránh.

📌 Điểm cần nhớ

• Tải tăng theo lịch biết trước → scheduled scaling. Thấy đề nói "every day", "each morning", "a 2-hour window", "end of month" là dấu hiệu chọn scheduled scaling thay vì scaling phản ứng theo metric.
• "MOST operationally efficient" luôn loại phương án có chữ "manually". Khi hai phương án cho cùng kết quả kỹ thuật, phương án tự động hoá thắng.
• Scale out trước, scale up sau. Với kiến trúc đã có Auto Scaling group + Elastic Load Balancer, tăng số lượng instances hợp với tải biến động hơn là tăng kích thước instance — kích thước lớn hơn thì trả tiền cả ngày cho nhu cầu chỉ có vài giờ.
• Đọc kỹ vấn đề đề đang than phiền. Phương án tiết kiệm chi phí (B) nghe hợp lý nhưng không chạm vào triệu chứng "slower response times"; giải đúng bài toán khác vẫn là sai.
• Tăng capacity phải đến trước thời điểm cao tải, vì instance cần thời gian khởi động và qua health check mới nhận được traffic từ load balancer.

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

Đề mô tả một tình huống rất cụ thể: nhân viên phòng IT đã có sẵn các AWS account riêng, và các account đó không nằm dưới quyền kiểm soát của công ty. Yêu cầu là gắn chúng vào organization trung tâm trong AWS Organizations.

Cụm từ quyết định đáp án là "individual AWS accounts that are not under the control of the company" — tức là các account đang tồn tại và do người khác làm chủ. Hai chi tiết này loại bỏ mọi phương án khác:

• Vì account đã tồn tại, không thể dùng luồng "tạo account mới trong organization" — luồng đó chỉ áp dụng cho account do management account tự tạo ra.
• Vì công ty không kiểm soát các account đó, organization trung tâm không thể tự ý kéo chúng vào. Chủ sở hữu account phải đồng ý. AWS thiết kế đúng như vậy: mang một account đang tồn tại vào organization luôn là một quy trình hai bên — bên mời và bên chấp nhận.

Câu hỏi thực chất kiểm tra: bạn có biết cơ chế duy nhất để gộp account có sẵn vào organization là invitation hay không.

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

Đáp án đúng theo tệp là A — "Send each existing account an invitation from the central organization."

AWS Organizations có sẵn cơ chế invitation cho đúng tình huống này. Management account của organization trung tâm gửi lời mời tới từng account (theo account ID hoặc email của account đó). AWS Organizations chuyển lời mời tới chủ sở hữu account, và người đó — với tư cách administrator của account — chọn accept hoặc decline.

Khi lời mời được chấp nhận, account trở thành member account của organization trung tâm. Từ thời điểm đó, account chịu sự chi phối của các quyền kiểm soát ở cấp organization — đúng thứ mà phòng security đang yêu cầu. Đây cũng là cách duy nhất đưa một account đã tồn tại vào organization, và nó tôn trọng nguyên tắc chủ sở hữu account phải chủ động đồng ý.

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

B — "Add each existing account to the central organization using AWS IAM." Sai vì nhầm dịch vụ. IAM quản lý danh tính và quyền bên trong một account (user, group, role, policy). Nó không có khái niệm thành viên organization và không có thao tác nào để đưa một account vào organization. Việc gộp account là chức năng của AWS Organizations, không phải IAM. Đây là phương án đánh vào việc thí sinh lẫn lộn ranh giới giữa hai dịch vụ quản lý quyền.

C — "Create a new organization in each account and join them to the central organization." Sai vì hiểu sai mô hình. Mục tiêu là các account đó trở thành member của organization trung tâm, chứ không phải mỗi account tự dựng một organization riêng. Tạo thêm organization là việc thừa và còn phản tác dụng: một account thuộc về nhiều nhất một organization, nên nếu nó đã tự tạo organization riêng thì trước khi gia nhập organization trung tâm còn phải gỡ bỏ organization vừa tạo. Phương án này làm phức tạp thêm một việc vốn chỉ cần một lời mời.

D — "Log in to each existing account and add them to the central organization." Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi — nó hỏng ở hướng của thao tác. Đúng là cuối cùng vẫn phải có người đăng nhập vào từng account để thao tác, nhưng thao tác đó là chấp nhận lời mời, không phải "tự thêm mình vào organization". Không có hành động nào cho phép một account đứng từ phía mình mà gia nhập một organization mà nó chọn — nếu có, bất kỳ ai cũng tự nhận mình vào organization của người khác. Quy trình bắt buộc phải bắt đầu bằng lời mời phát đi từ organization trung tâm; D bỏ mất bước đó nên mô tả một luồng không tồn tại.

📌 Điểm cần nhớ

• Account đã tồn tại → invitation; account cần mới → create. AWS Organizations có đúng hai cách để có member account: mời một account có sẵn, hoặc tạo account mới ngay trong organization. Đọc đề thấy chữ "existing" là nghĩ ngay tới invitation.
• Invitation luôn là quy trình hai bên: organization trung tâm gửi, administrator của account đích accept. Phương án nào mô tả việc gộp account chỉ bằng một phía đều sai.
• Đừng lẫn IAM với AWS Organizations. IAM làm việc trong phạm vi một account; Organizations làm việc ở phạm vi nhiều account (member account, OU, service control policy). Phương án đưa IAM ra để giải bài toán nhiều account gần như luôn là mồi nhử.
• Một account chỉ thuộc một organization tại một thời điểm. Vì vậy các phương án kiểu "tạo organization riêng rồi ghép vào" là sai về mô hình, không chỉ là dài dòng.

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

Đề mô tả một công ty đang triển khai AWS Single Sign-On (AWS SSO). SysOps Administrator đã làm xong hai việc: tạo AWS SSO directory trong master account của AWS Organizations, và bật full access. Câu hỏi là: bước tiếp theo để cấu hình chức năng đăng nhập một lần là gì.

Cụm từ quyết định đáp án là "the next step to configure the single sign-on functionality" đặt cạnh mốc "đã tạo directory". Nghĩa là ta đã có danh tính (users và groups nằm trong directory), nhưng chưa có gì mô tả những người đó được làm gì trong các AWS account. Mảnh ghép còn thiếu chính là phần quyền — và trong AWS SSO, thứ đảm nhiệm vai trò đó có tên riêng: permission set.

Cụm thứ hai đáng chú ý là "Directory Service users or groups" xuất hiện trong hai phương án A và B. Nó nhắc rằng danh tính đã nằm sẵn ở directory, nên đáp án đúng phải là thứ gắn (associate) vào chính users/groups đó, chứ không phải thứ tạo lại danh tính từ đầu.

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

B — Create permission sets in AWS SSO and associate the permission sets with Directory Service users or groups.

Permission set là đối tượng định nghĩa mức truy cập mà user hoặc group có trong một AWS account. Permission set được lưu trong AWS SSO, rồi AWS SSO tự provision nó xuống AWS account dưới dạng IAM role. Đây chính là cầu nối còn thiếu giữa danh tính trong directory và quyền hạn trong từng account.

Một user có thể được gán nhiều permission set. Khi đó, lúc đăng nhập vào user portal, người dùng phải chọn một trong số đó — và trên giao diện, các lựa chọn này hiện ra dưới dạng IAM role.

Vậy với kịch bản của đề, sau khi directory đã sẵn sàng, bước kế tiếp đúng là: tạo permission set, rồi gán permission set đó cho user account hoặc group.

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

A — Tạo SCP trong Organizations rồi gắn SCP vào Directory Service users hoặc groups. SCP dùng để giới hạn tập API action khả dụng trong một account — nó là hàng rào ở tầng Organizations, không phải công cụ cấp quyền cho SSO. SCP cũng không gắn được vào users hay groups của directory; đối tượng gắn SCP là account và OU. Phương án này lấy đúng chữ "Organizations" trong đề để trông có vẻ liên quan, nhưng nhầm hẳn loại công cụ.

C — Tạo IAM role thủ công ở từng account để AWS SSO dùng, rồi gán user vào các role đó qua AWS SSO. Đây là phương án gần đúng nhất và cũng dễ bẫy nhất, vì kết quả cuối cùng đúng là có IAM role trong các account. Chỗ hỏng nằm ở ai tạo role: administrator không đi tạo role trực tiếp, mà tạo permission set — thứ "hành xử như role". Chính AWS SSO mới là bên provision role xuống account. Làm theo C là bỏ qua đúng cái lớp trừu tượng mà AWS SSO sinh ra để tồn tại, và nó cũng không phải luồng cấu hình mà dịch vụ này hỗ trợ.

D — Tạo IAM user trong master account rồi dùng AWS SSO gán các user đó vào những account họ sẽ truy cập. Không cần tạo user trong master account chút nào. Danh tính đã có sẵn ở source directory. User ở source account sẽ assume một role thông qua permission set, và role đó mang các quyền trong policy đính kèm. Tạo thêm IAM user là dựng lại một tập danh tính song song — đi ngược hẳn mục đích của single sign-on, vốn là dùng một nguồn danh tính duy nhất.

📌 Điểm cần nhớ

• Permission set = đơn vị cấp quyền của AWS SSO. Nó được lưu trong AWS SSO và được provision xuống AWS account dưới dạng IAM role. Thấy câu hỏi hỏi "cấp quyền cho user SSO vào account", nghĩ tới permission set trước tiên.
• Đừng tự tay tạo IAM role cho luồng SSO. AWS SSO tạo role hộ bạn từ permission set; phương án bảo administrator tự tạo role ở từng account thường là bẫy.
• SCP không phải công cụ cấp quyền. SCP giới hạn API action ở phạm vi account/OU trong Organizations, và không gắn vào user hay group. Thấy SCP đứng cạnh "users or groups" là dấu hiệu phương án sai.
• SSO đúng nghĩa thì không tạo thêm IAM user. Mọi phương án đề xuất tạo IAM user để "phục vụ SSO" đều mâu thuẫn với chính khái niệm một nguồn danh tính duy nhất.
• Trình tự chuẩn: dựng directory → tạo permission set → gán permission set cho user/group (và cho account). Câu hỏi kiểu "bước tiếp theo là gì" chỉ cần bạn xác định đang đứng ở đâu trong chuỗi này.

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

Đề mô tả một kiến trúc đã khá chuẩn: hai EC2 instance nằm sau một Application Load Balancer trải trên hai Availability Zone, DynamoDB làm nơi lưu dữ liệu, và Route 53 chia đường đi — nội dung động về ALB, nội dung tĩnh về S3 bucket. Triệu chứng duy nhất được nêu là "poor performance with long loading times", và yêu cầu là chọn hai hành động cải thiện hiệu năng.

Cụm từ quyết định nằm ở chỗ đề tách bạch "dynamic content to the ALB" và "static content to an Amazon S3 bucket". Vì hai loại nội dung đi hai đường khác nhau, mỗi đường có một nút thắt riêng, nên đáp án đúng phải là một hành động cho mỗi đường, chứ không phải hai hành động cùng chữa một phía. Cụm thứ hai đáng chú ý là "two EC2 instances" — một con số cố định, không co giãn theo tải. Đề cũng không hề nhắc tới nhiều region hay nhiều bản triển khai, và chi tiết vắng mặt đó chính là thứ loại bỏ phương án về routing policy.

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

A — Add Amazon CloudFront caching for static content. Nội dung tĩnh đang được phục vụ trực tiếp từ S3 bucket, tức là mọi người dùng đều phải đi tới đúng một điểm để lấy ảnh, CSS, JavaScript. Đặt CloudFront trước bucket đó đưa bản sao nội dung ra các edge location gần người dùng hơn, nên thời gian tải nội dung tĩnh giảm xuống, đồng thời giảm luôn số request đánh thẳng vào S3. Đây là cách xử lý đúng cho nhánh nội dung tĩnh.

C — Implement Amazon EC2 Auto Scaling for the web servers. Nhánh nội dung động chỉ có đúng hai instance. Khi lượng truy cập tăng, ALB vẫn phân phối đều nhưng nó không tạo thêm được server nào — hai máy đó bão hoà thì thời gian phản hồi kéo dài ra. Auto Scaling gắn vào ALB cho phép số instance co giãn theo nhu cầu, giữ được hiệu năng trong giờ cao điểm. Đây là cách xử lý đúng cho nhánh nội dung động.

Hai hành động này bổ trợ nhau: một cái chữa đường tĩnh, một cái chữa đường động — khớp đúng với cấu trúc mà đề đã bày ra.

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

B — Move the static content from Amazon S3 to the web servers. Đây là đi lùi. Nội dung tĩnh đang nằm ở nơi phục vụ nó tốt; kéo về EC2 nghĩa là chính hai instance đang có nguy cơ quá tải phải gánh thêm việc phục vụ file tĩnh, càng làm nội dung động chậm hơn. Người dùng cũng không đến gần hơn chút nào, vì web server vẫn nằm ở một chỗ. CloudFront cho hiệu năng tốt hơn hẳn cách này.

D — Move the dynamic content from the web servers to Amazon S3. Phương án này sai ở mức khả thi chứ không chỉ ở mức tối ưu: S3 bucket cấu hình làm website chỉ phục vụ được nội dung tĩnh, nó không chạy được mã ứng dụng để sinh nội dung động. Chuyển như vậy là làm hỏng ứng dụng, không phải làm nó nhanh lên.

E — Enable Amazon Route 53 latency-based routing. Đây là phương án gần đúng nhất và cũng là cái dễ chọn nhầm nhất, vì nghe rất "hiệu năng". Nhưng latency-based routing hoạt động bằng cách hướng người dùng tới bản triển khai gần họ nhất trong số nhiều bản đã được đăng ký làm record. Ở đây ứng dụng chỉ có một bản triển khai và một S3 bucket, nên không có lựa chọn nào để routing policy cân nhắc — nó không có gì để so sánh, và kết quả vẫn là cùng một đích đến. Bật lên không cải thiện gì.

📌 Điểm cần nhớ

• Khi đề tách rõ static content và dynamic content, hãy soi từng nhánh riêng: nhánh tĩnh thường chữa bằng caching ở edge (CloudFront), nhánh động thường chữa bằng khả năng co giãn (Auto Scaling sau ALB).
• Một số instance cố định đứng sau load balancer là dấu hiệu kinh điển của thiếu Auto Scaling — ALB phân phối tải chứ không tạo thêm dung lượng.
• Các routing policy của Route 53 như latency-based chỉ có tác dụng khi thực sự có nhiều điểm đến để chọn. Một region, một bucket thì mọi policy đều dẫn về cùng một chỗ.
• S3 làm static website hosting không chạy được nội dung động; phương án nào đề nghị chuyển logic ứng dụng sang S3 thì loại thẳng, không cần cân nhắc hiệu năng.
• Cẩn thận với phương án gom nội dung tĩnh về lại web server: nó vừa bỏ phí ưu thế của object storage vừa chất thêm tải lên đúng thành phần đang là nút thắt.

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

Đề mô tả một công ty dùng AWS Organizations để quản lý nhiều AWS account. Một phòng ban cần account mới, và SysOps Administrator phải tạo account đó rồi cấu hình user-defined cost allocation tags.

Cụm từ quyết định đáp án là "uses AWS Organizations" kết hợp với "user-defined cost allocation tags". Hai cụm này ràng buộc hai chuyện khác nhau, và cả bốn phương án chỉ khác nhau ở đúng hai chuyện đó:

1. Tag được tạo ở đâu? — tag là thuộc tính gắn lên resource, nên nó phải được tạo và gắn ở chính account chứa resource, bằng Tag Editor (hoặc trực tiếp trên resource). Billing and Cost Management console không phải nơi tạo tag.
2. Tag được kích hoạt (activate) làm cost allocation tag ở đâu? — vì có AWS Organizations, phần billing được hợp nhất về payer account (management account). Đó là nơi duy nhất có Cost Allocation Tags manager để bật tag lên.

Nói cách khác, đề đang tách bạch hai động từ: create tag và mark as cost allocation tag. Phương án nào gộp hai việc vào một chỗ, hoặc đặt sai chỗ cho một trong hai, đều sai.

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

Đáp án đúng theo tệp là D: dùng Tag Editor trong account mới để tạo user-defined tags, sau đó dùng Billing and Cost Management console trong payer account để đánh dấu chúng là cost allocation tags.

Phương án này khớp đúng hai bước ở trên:

• Tag Editor ở account mới: user-defined tag là tag do bạn tự định nghĩa và gắn lên resource. Resource nằm trong account mới, nên việc tạo và gắn tag diễn ra ở account mới. Tag Editor là công cụ được thiết kế đúng cho việc gắn tag hàng loạt lên nhiều resource.
• Billing console ở payer account: sau khi tag đã tồn tại trên resource, nó chưa tự động xuất hiện trong báo cáo chi phí — phải được activate thủ công. Trong môi trường AWS Organizations, quyền quản lý cost allocation tags thuộc về payer account, vì đó là account nhận consolidated billing cho toàn tổ chức. Cost Allocation Tags manager trong Billing and Cost Management console của payer account là nơi thực hiện.

Một chi tiết bổ sung từ phần giải thích nguồn: cost allocation tags chỉ hiện ra trong console sau khi đã bật các công cụ chi phí như Cost Explorer, Budgets, hay AWS Cost and Usage Reports.

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

A — Tag Editor ở account mới, rồi Billing console ở account mới để mark tag. Đây là phương án gần đúng nhất, và cũng là cái bẫy chính của câu hỏi. Bước một hoàn toàn chính xác: dùng Tag Editor ở account mới để tạo tag. Chỗ hỏng nằm ở bước hai: nó đánh dấu cost allocation tag ở account mới thay vì payer account. Khi account là thành viên của một AWS Organizations có consolidated billing, dữ liệu chi phí được gộp lên payer account, và việc kích hoạt cost allocation tags được quản lý tập trung ở đó chứ không phải từng account con. Chỉ sai đúng một từ — "new account" thay vì "payer account" — nhưng đủ làm quy trình không chạy.

B — Dùng Billing and Cost Management console ở payer account để tạo user-defined cost allocation tags. Phương án này đúng về account (payer account) nhưng sai về công cụ và bước. Billing and Cost Management console không tạo ra tag; nó chỉ kích hoạt những tag đã tồn tại trên resource. Nếu chưa ai dùng Tag Editor (hoặc gắn tag trực tiếp) ở account mới, thì trong Cost Allocation Tags manager sẽ không có tag nào để bật lên cả. Phương án này bỏ mất hoàn toàn bước tạo tag.

C — Dùng Billing and Cost Management console ở account mới để tạo user-defined cost allocation tags. Phương án này sai cả hai chuyện cùng lúc: sai công cụ (Billing console không tạo tag, giống lỗi của B) và sai account (account mới thay vì payer account, giống lỗi của A). Đây là phương án xa đáp án đúng nhất trong bốn lựa chọn.

📌 Điểm cần nhớ

• Tách rõ hai bước: tạo/gắn tag là việc của Tag Editor ở account chứa resource; kích hoạt tag thành cost allocation tag là việc của Billing and Cost Management console. Đề nào trộn hai bước vào một công cụ thì đó là phương án sai.
• Thấy "AWS Organizations" trong đề thì nghĩ ngay tới payer account cho mọi thao tác liên quan tới billing: consolidated billing, cost allocation tags, Cost Explorer ở phạm vi tổ chức. Account thành viên không tự quyết được phần này.
• User-defined tag không tự động vào báo cáo chi phí — luôn có một bước activate thủ công. Đây là chi tiết hay bị bỏ qua và cũng là thứ đề thi thích hỏi.
• Cost allocation tags chỉ hiển thị sau khi đã bật ít nhất một công cụ chi phí (Cost Explorer, Budgets, hoặc AWS Cost and Usage Reports).

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

Đề mô tả một ứng dụng chứa dữ liệu cực kỳ nhạy cảm, tuyệt đối không được rò rỉ ra ngoài công ty. Câu hỏi cuối cùng mới là thứ phải trả lời, và nó rất hẹp:

"How can the Administrator ensure that the servers in the VPC cannot send traffic to the internet?"

Cụm từ quyết định là "cannot send traffic to the internet" — tức là chặn đường ra Internet (outbound) ở tầng mạng của VPC. Hai chữ đáng chú ý nữa là "ensure" (bảo đảm chắc chắn, không phải giảm bớt rủi ro) và "servers in the VPC" (phạm vi là cấu hình mạng của VPC, không phải cấu hình ổ đĩa hay dữ liệu).

Đây chính là ràng buộc tách bốn phương án ra: một phương án nói về subnet và route table (đúng trọng tâm), một nói về địa chỉ IP public (chỉ chặn được đường vào và một phần đường ra), một nói về NAT gateway (thiết bị vốn sinh ra để cho phép đi ra Internet), và một nói về lưu trữ (không dính gì tới mạng).

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

B — Launch the EC2 instances in private subnets.

Trong VPC, một subnet được gọi là public hay private hoàn toàn do route table gắn vào nó quyết định, chứ không do tên gọi. Subnet là public khi route table của nó có tuyến trỏ ra internet gateway; subnet là private khi route table không có tuyến đó.

Đặt EC2 instance vào private subnet — với route table không có internet gateway và cũng không có NAT gateway / NAT instance — nghĩa là ở tầng định tuyến, gói tin hướng ra Internet không có đường nào để đi. Đây là biện pháp ở đúng tầng mà câu hỏi nhắm tới, và nó chặn ngay tại nguồn: dù ứng dụng có bị lỗi hay bị chiếm quyền và cố gọi ra ngoài, gói tin vẫn không rời khỏi VPC được.

Đây cũng là điểm mạnh so với các cách "chắp vá": private subnet chặn cả lối vào lẫn lối ra bằng một quyết định cấu hình duy nhất trên route table, thay vì phải kiểm soát từng thuộc tính của từng instance.

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

A — Ensure that the servers do not have Elastic IP addresses. Đây là phương án gần đúng nhất và dễ mắc bẫy nhất. Elastic IP chỉ là một loại địa chỉ IP public. Gỡ EIP là cần, nhưng chưa đủ, vì:

• Instance vẫn có thể được cấp public IP tự động (auto-assign public IPv4) khi launch trong subnet có bật tuỳ chọn đó.
• Quan trọng hơn: instance không cần IP public nào vẫn ra Internet được nếu route table trỏ tới một NAT gateway/NAT instance.

Nói cách khác, A xử lý thuộc tính của instance trong khi vấn đề nằm ở đường định tuyến của subnet. Chưa đụng tới route table thì chưa "ensure" được gì.

C — Create a blackhole NAT gateway that prevents outbound access. Sai ngay từ khái niệm. NAT gateway sinh ra để cho phép instance trong private subnet đi ra Internet — nó là thứ mở đường, không phải thứ chặn đường. Còn "blackhole" không phải một loại NAT gateway mà bạn tạo ra được: đó là trạng thái hiển thị của một route khi đích mà route trỏ tới (NAT gateway, ENI, VPC endpoint…) đã bị xoá hoặc không còn dùng được. Nó là dấu vết của một cấu hình hỏng, không phải một lựa chọn thiết kế. Muốn không cho ra Internet thì đơn giản là đừng tạo NAT gateway, chứ không phải tạo rồi làm cho nó hỏng.

D — Use instance stores to ensure there is no persistent data. Nhầm hoàn toàn chủ đề. Instance store là ổ đĩa tạm gắn trực tiếp vào máy chủ vật lý, dữ liệu mất khi instance stop hoặc terminate. Nó nói về vòng đời của dữ liệu lưu trữ, không liên quan gì tới khả năng gửi gói tin ra Internet. Một instance dùng instance store vẫn kết nối ra ngoài bình thường nếu route table cho phép — thậm chí dữ liệu nhạy cảm nằm trong RAM hay ổ tạm vẫn có thể bị đẩy ra ngoài y như thường. Phương án này trả lời một câu hỏi mà đề không hỏi.

📌 Điểm cần nhớ

• Public hay private là do route table, không do tên subnet. Có tuyến tới internet gateway → public; không có → private. Muốn chặn đường ra Internet thì sửa ở tầng định tuyến, đó là chỗ có hiệu lực chắc chắn nhất.
• Không có IP public ≠ không ra được Internet. Instance không EIP, không public IP vẫn đi ra ngoài được qua NAT gateway. Ngược lại, có IP public mà không có tuyến tới internet gateway thì cũng vô dụng. Phải xét cả hai vế.
• NAT gateway là thứ mở đường ra Internet, không phải thứ chặn. Thấy phương án nào dùng NAT gateway để "ngăn outbound" thì gần như chắc chắn là mồi nhử.
• "Blackhole" là triệu chứng của route trỏ vào đích đã biến mất, không phải một cấu hình cố ý tạo ra để kiểm soát traffic.
• Khi đề hỏi về network isolation, hãy loại ngay những phương án bàn về lưu trữ, mã hoá dữ liệu hay vòng đời volume — chúng đúng về mặt bảo mật chung nhưng trả lời sai câu hỏi.

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

Đề mô tả một web application chạy song song ở hai nơi: on-premises data center và Amazon EC2 instances. Cả hai nơi đều bị crash, nghi ngờ memory leak, nên cần theo dõi memory utilization theo thời gian ở cả hai môi trường.

Có hai cụm từ quyết định đáp án:

• "both ... on-premises data center and ... EC2 instances" — lời giải phải phủ được cả hạ tầng ngoài AWS, không chỉ EC2.
• "the SIMPLEST way" — đây mới là cụm phân biệt thật sự. Nhiều phương án đều chạy được, nhưng đề hỏi cái đơn giản nhất, tức là ít thành phần phải tự dựng và tự bảo trì nhất, và tốt nhất là một công cụ duy nhất cho cả hai bên thay vì hai hệ thống giám sát riêng.

Thêm một điểm nền tảng cần nhớ: memory utilization không phải metric mặc định của EC2. CloudWatch thu metric ở tầng hypervisor (CPU, network, disk I/O của volume), còn RAM là thứ chỉ nhìn thấy được từ bên trong guest OS. Muốn có nó thì buộc phải cài agent trong máy — đó là lý do mọi phương án đều xoay quanh việc "cài cái gì đó vào máy".

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

Đáp án đúng: D — dùng Amazon CloudWatch agent cho cả EC2 instances lẫn on-premises servers để đẩy metric MemoryUtilization về CloudWatch.

Unified CloudWatch agent được thiết kế đúng cho tình huống này: nó cài được cả trên EC2 instances lẫn trên máy chủ on-premises, thu các system-level metrics từ bên trong guest OS (in-guest metrics) — trong đó có memory utilization — rồi gửi về CloudWatch. Cùng một agent, cùng một cách cấu hình, cùng một nơi lưu trữ và xem số liệu.

Vì thế nó thoả cả hai ràng buộc của đề cùng lúc:

• Phủ hết phạm vi: on-premises không bị bỏ rơi, không cần một hệ giám sát thứ hai.
• Đơn giản nhất: một công cụ do AWS cung cấp sẵn, không phải viết code, không phải tự dựng đường ống đẩy số liệu. Metric nằm chung một chỗ nên vẽ đồ thị theo thời gian và so sánh hai môi trường trực tiếp được — đúng thứ cần để nhìn ra đường memory đi lên đều đặn của một memory leak.

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

A. Tự viết script hoặc dùng third-party application cho cả hai bên — về mặt kỹ thuật thì làm được, và đây là cách người ta hay làm trước khi có unified agent. Nhưng nó thua ở đúng tiêu chí đề nêu: bạn phải tự viết code đọc RAM, tự lo lịch chạy, tự lo xác thực và đẩy số liệu, tự lo cập nhật khi OS đổi. Đã có sẵn một agent chính thức làm đúng việc đó thì tự dựng lại là giải pháp phức tạp hơn không có lý do.

B. CloudWatch agent cho EC2, third-party software cho on-premises — đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. Nó xuất phát từ hiểu lầm rất phổ biến rằng CloudWatch agent chỉ dùng được cho EC2. Thực tế agent hỗ trợ cả máy on-premises, nên việc chia đôi ở đây là tự tạo thêm việc: hai công cụ phải cài đặt, hai chỗ phải cấu hình, và số liệu memory nằm ở hai hệ thống khác nhau nên muốn so sánh chéo lúc chẩn đoán crash lại phải ghép tay. Hỏng ở chỗ "không đơn giản nhất", chứ không phải ở chỗ "không chạy được".

C. Tạo Auto Scaling group cho cả on-premises servers và EC2 instances rồi xem metric memory của ASG — sai ở hai tầng độc lập nhau. Thứ nhất, Auto Scaling group không quản lý được máy chủ on-premises, nên nửa phạm vi của đề bài không có cách nào đưa vào. Thứ hai, ASG không hề báo cáo memory utilization; nó là cơ chế co giãn số lượng instance, và metric nhóm mà nó phát ra nói về số lượng/tình trạng instance, còn RAM vẫn là thứ chỉ agent bên trong OS mới thấy. Ngoài ra, dựng ASG là thay đổi kiến trúc chỉ để phục vụ việc quan sát — vừa không giải quyết vấn đề, vừa đi ngược tiêu chí "simplest".

📌 Điểm cần nhớ

• Memory và disk space bên trong OS không có sẵn trong CloudWatch. Hypervisor không nhìn thấy chúng. Thấy đề hỏi memory utilization của EC2 thì gần như chắc chắn đáp án phải có CloudWatch agent.
• Unified CloudWatch agent chạy được cả trên EC2 lẫn on-premises servers. Phương án nào tách đôi "AWS dùng agent, on-premises dùng thứ khác" thường là bẫy dựng lên từ hiểu lầm này.
• Từ khoá SIMPLEST / LEAST operational overhead là tiêu chí chấm, không phải văn phong. Khi nhiều phương án đều khả thi, hãy loại theo số lượng thành phần phải tự viết và tự vận hành — dịch vụ có sẵn thắng script tự viết.
• Auto Scaling group là công cụ co giãn, không phải công cụ giám sát, và chỉ áp dụng cho tài nguyên trong AWS. Thấy nó xuất hiện trong một câu hỏi thuần về thu thập metric thì đó gần như luôn là phương án loại.