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

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

Đề mô tả một ứng dụng chạy trong hybrid environment — tức là một phần nằm ở on-premises data center, một phần nằm trên AWS — và đòi hai thứ cùng lúc:

• encryption in-transit across shared networks
• encryption at rest

Cụm từ quyết định đáp án là "across shared networks". Nó không nói "giữa client và web server", cũng không nói "trên đường HTTPS công khai" — nó nói đường truyền dùng chung nối data center với AWS. Đó chính là mô tả của đường Internet công cộng giữa hai đầu hybrid, và cách xử lý ở tầng hạ tầng cho đúng bối cảnh này là dựng một đường hầm mã hoá cho toàn bộ lưu lượng đi qua, chứ không phải mã hoá ở tầng ứng dụng cho từng kết nối riêng lẻ.

Cụm thứ hai là "encryption at rest" — dữ liệu nằm yên trên đĩa. Yêu cầu này quy về việc quản lý khoá mã hoá, và câu hỏi cần một dịch vụ đảm nhận đúng vai trò đó.

Đề cũng là dạng (Select TWO), nên phải chọn đúng hai phương án, mỗi phương án phủ một vế yêu cầu.

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

B — Configure an AWS VPN between the on-premises data center and AWS. AWS VPN dựng đường hầm mã hoá qua chính đường mạng dùng chung nối hai đầu, nên mọi thứ ứng dụng gửi qua lại giữa on-premises và AWS đều được mã hoá trên đường đi. Đây là câu trả lời trực tiếp cho vế in-transit across shared networks. Một điểm thực dụng nữa: nếu chưa có certificate thì vẫn dựng được đường hầm bằng pre-shared key — nghĩa là giải pháp này không phụ thuộc vào việc ứng dụng đã sẵn sàng dùng TLS hay chưa.

D — Use AWS KMS to manage the encryption keys used for data encryption. KMS là dịch vụ quản lý khoá: tạo, lưu giữ, phân quyền và xoay vòng khoá mã hoá. Khoá do KMS quản lý sau đó được dùng để mã hoá dữ liệu lúc lưu trữ, phủ đúng vế encryption at rest. Chú ý cách phương án này được diễn đạt — "manage the encryption keys used for data encryption" — nó mô tả đúng vai trò thật của KMS: quản lý khoá, còn thao tác mã hoá khối dữ liệu lớn diễn ra bên ngoài KMS bằng khoá đó.

Hai phương án B và D ghép lại phủ trọn hai yêu cầu của đề mà không chồng lấn nhau.

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

A — Use AWS Certificate Manager to create TLS/SSL certificates. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. ACM đúng là dịch vụ tạo và quản lý TLS/SSL certificate, và TLS đúng là một dạng encryption in-transit — nên riêng câu chữ thì không sai. Vấn đề là phương án dừng lại ở việc tạo certificate mà không nói certificate đó được dùng ở đâu và như thế nào. Certificate chỉ bảo vệ được đường truyền khi ứng dụng thực sự terminate TLS bằng nó; điều đó phụ thuộc hoàn toàn vào cách ứng dụng được thiết kế, mà đề không cho biết gì. So với B — vốn bảo vệ toàn bộ lưu lượng hybrid ở tầng mạng, không cần ứng dụng phải làm gì thêm — thì A là một mảnh ghép chưa hoàn chỉnh.

C — Use AWS KMS to create TLS/SSL certificates. Sai ở chỗ gán nhầm chức năng. KMS không phải nơi tạo TLS/SSL certificate; việc đó thuộc về ACM. Phương án này trộn tên đúng của một dịch vụ (KMS) với công việc của một dịch vụ khác (ACM) — đây là kiểu bẫy hay gặp, và cách hoá giải là luôn tự hỏi "dịch vụ này thực sự sinh ra sản phẩm gì".

E — Use AWS CloudHSM to encrypt the data using a CMK. Sai ở động từ "encrypt the data". CloudHSM cũng là dịch vụ về khoá — nó cung cấp hardware security module dành riêng cho bạn để quản lý và bảo vệ khoá — nhưng bạn không đưa khối dữ liệu vào CloudHSM để nó mã hoá hộ; dữ liệu vẫn được mã hoá bên ngoài bằng khoá lấy từ đó. Đối chiếu với D sẽ thấy khác biệt rất rõ: D dùng đúng từ "manage the keys", còn E dùng "encrypt the data". Cùng một họ dịch vụ, nhưng chỉ một phương án mô tả đúng vai trò.

📌 Điểm cần nhớ

• "Hybrid" + "shared network" + "in-transit" → nghĩ tới AWS VPN. Khi hai đầu là on-premises và AWS, mã hoá đường truyền được giải quyết ở tầng mạng bằng đường hầm, không phải bằng cách bàn tới TLS của từng ứng dụng.
• Đọc kỹ động từ trong phương án, không chỉ tên dịch vụ. "Manage the keys" và "encrypt the data" là hai việc khác nhau. Cả KMS lẫn CloudHSM đều là dịch vụ quản lý khoá; dữ liệu được mã hoá bên ngoài chúng bằng khoá lấy từ đó.
• Đừng ghép nhầm dịch vụ với sản phẩm nó tạo ra. TLS/SSL certificate là của ACM, không phải của KMS. Đây là bẫy tái sử dụng ở rất nhiều câu về Security & Identity.
• Phương án đúng phải nói rõ nó giải quyết yêu cầu bằng cách nào. Một phương án chỉ tạo ra thứ gì đó (certificate) mà không nêu cách dùng thì yếu hơn phương án mô tả trọn vẹn cơ chế bảo vệ — trong dạng "Select TWO", hãy ưu tiên cặp phương án phủ đủ cả hai vế yêu cầu, mỗi vế một phương án.

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

Đề mô tả một tình huống rất cụ thể: bucket S3 đã bật static website hosting, nội dung đã được upload xong, nhưng khi truy cập thử thì nhận "HTTP 403 Forbidden". Câu hỏi: cần làm gì để hết lỗi?

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

• "static website" — nghĩa là người truy cập là người dùng ẩn danh (anonymous), không gửi kèm chữ ký AWS. Trình duyệt chỉ phát ra một request GET trần.
• "HTTP 403 Forbidden", chứ không phải 404 — S3 tìm thấy thứ được yêu cầu nhưng từ chối cho đọc. Đây là lỗi quyền, không phải lỗi cấu hình thiếu file hay thiếu index document.

Ghép hai điều này lại: request ẩn danh đang cần quyền đọc object, mà bucket chưa cấp quyền đó. Ràng buộc tinh vi thứ ba nằm ở chính các phương án — hai lựa chọn A và C khác nhau đúng một chữ: "read access to the bucket objects" so với "read access to the bucket". Đó mới là chỗ phân biệt thật sự của câu này.

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

A. Add a bucket policy that grants everyone read access to the bucket objects.

Khi trình duyệt tải một trang của website tĩnh, nó thực hiện API action s3:GetObject trên từng object (file HTML, CSS, ảnh…). Muốn dùng được GET, người gọi phải có quyền READ trên chính object. Nếu quyền READ được cấp cho anonymous user, S3 sẽ trả object về mà không cần authorization header — đúng kiểu request mà trình duyệt gửi ra.

Vì vậy cách xử lý là gắn một bucket policy cấp s3:GetObject cho mọi người (principal *), áp lên các object bên trong bucket — tức resource ở dạng đường dẫn tới object chứ không phải chỉ bản thân bucket. Thiếu đúng chính sách này là nguyên nhân phổ biến nhất của 403 trên một website tĩnh S3 vừa dựng xong.

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

C. Add a bucket policy that grants everyone read access to the bucket. — Đây là phương án gần đúng nhất và là bẫy chính của câu. Nó đúng về công cụ (bucket policy) và đúng về đối tượng (everyone), nhưng sai phạm vi tài nguyên. Quyền đọc ở mức bucket liên quan tới hành động liệt kê nội dung bucket, không phải hành động lấy nội dung từng file. Người truy cập website cần thực hiện được s3:GetObject để lấy về từng object — nên object-level permission mới là thứ có liên quan ở đây. Cấp quyền ở mức bucket mà bỏ mức object thì trang vẫn tiếp tục trả 403.

D. Remove the default bucket policy that denies read access to the bucket. — Sai vì tiền đề không tồn tại: không có bucket policy mặc định nào deny read cả. Bucket mới tạo đơn giản là không có bucket policy nào; truy cập bị chặn do không có quyền nào được cấp, chứ không phải do có một lệnh cấm nằm sẵn. Đây là kiểu phương án nghe rất hợp lý ("có cái gì đó đang chặn, gỡ nó ra") nhưng mô tả sai cơ chế: vấn đề là thiếu allow, không phải thừa deny. Và về thao tác, cũng chẳng có gì để mà xoá.

B. Configure cross-region replication (CRR) on the bucket. — Hoàn toàn lạc đề. CRR chỉ sao chép object sang một bucket ở region khác, phục vụ mục tiêu về độ bền dữ liệu, độ trễ theo vùng địa lý hoặc yêu cầu lưu trữ ở nhiều nơi. Nó không đụng gì tới quyền truy cập, nên không giúp gì cho việc xử lý thông báo access denied. Bật CRR xong thì website vẫn trả đúng 403 như cũ, chỉ khác là bây giờ có thêm một bản sao cũng không ai đọc được.

📌 Điểm cần nhớ

• 403 Forbidden trên S3 là câu chuyện của quyền, không phải của cấu hình hosting. Gặp 403 với website tĩnh, phản xạ đầu tiên nên là kiểm tra bucket policy có cấp s3:GetObject cho anonymous hay không — phân biệt rõ với 404 (thiếu object / sai index document).
• Phân biệt quyền mức bucket và quyền mức object. Hành động lấy nội dung file là s3:GetObject, cần quyền áp lên object. Đề thi rất hay đặt cạnh nhau hai phương án chỉ khác chữ "bucket" và "bucket objects" — đọc kỹ phần resource trước khi chọn.
• Người truy cập website tĩnh là anonymous user. Không có authorization header, nên chỉ được phục vụ khi quyền đọc đã được cấp công khai; mọi cơ chế xác thực bằng chữ ký đều không áp dụng ở luồng này.
• Không có bucket policy mặc định deny. Bucket mới là "trắng chính sách"; truy cập thất bại do thiếu allow. Cẩn thận với các phương án dựng lên một cấu hình mặc định không tồn tại rồi bảo bạn đi gỡ nó.

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

Đề mô tả một ứng dụng ghi dữ liệu khách hàng nhạy cảm vào nhiều S3 bucket, các bucket đã được bảo vệ bằng bucket policy, và đang có các nỗ lực truy cập trái phép. Nhiệm vụ của Sysops Administrator là thu thập thông tin về bucket nào đang bị nhắm tới và ai là người thực hiện.

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

• "attempts at unauthorized access" — nỗ lực truy cập trái phép, tức là các request bị từ chối. Trong S3, request bị bucket policy hoặc IAM chặn trả về mã HTTP 403 Access Denied. Cụm này loại thẳng phương án nói về mã lỗi khác.
• "which buckets are being targeted and by whom" — cần biết bucket đích và danh tính người gọi. Đây là dữ liệu theo từng request, chỉ có trong log truy cập, không có trong báo cáo phân tích mẫu hình lưu trữ.

Ngoài ra, câu hỏi yêu cầu Select TWO, và hai bước phải ghép thành một quy trình hoàn chỉnh: sinh ra dữ liệu rồi truy vấn dữ liệu đó. Chọn hai phương án cùng làm một việc là hỏng.

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

D — Bật S3 Server Access Logging trên toàn bộ bucket bị ảnh hưởng, lưu log vào một bucket riêng biệt. Đây là bước sinh dữ liệu. Server access log ghi chi tiết từng request tới bucket, trong đó có requester (IAM user/role thực hiện), remote IP của người gọi, bucket được truy cập và mã trạng thái trả về. Đúng ba thứ đề hỏi. Việc lưu log sang một bucket riêng, chuyên dụng là bắt buộc về mặt thực hành: ghi log vào chính bucket đang được theo dõi sẽ tạo vòng lặp log-ghi-đè-log và trộn lẫn dữ liệu nhạy cảm với dữ liệu kiểm toán.

C — Dùng Amazon Athena truy vấn S3 Server Access Logs tìm lỗi HTTP 403, từ đó xác định IAM user hoặc role gửi request. Đây là bước phân tích. Athena là dịch vụ truy vấn serverless chạy SQL tiêu chuẩn trực tiếp trên dữ liệu nằm trong S3 — không cần dựng cụm máy hay nạp dữ liệu đi đâu khác, rất hợp với việc soi một khối log lớn. Lọc theo 403 khoanh đúng vào các request bị từ chối, tức chính là các nỗ lực truy cập trái phép, rồi đọc cột requester để biết ai đứng sau.

Hai bước này khớp nhau: D tạo ra nguồn log, C khai thác đúng nguồn log đó.

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

A — Athena truy vấn S3 Server Access Logs tìm lỗi HTTP 503. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi: nguồn dữ liệu (Server Access Logs) và công cụ (Athena) đều chuẩn, chỉ mã lỗi sai. 503 là Service Unavailable — vấn đề về tình trạng phục vụ của dịch vụ, không liên quan gì tới quyền. Lọc 503 sẽ bỏ sót toàn bộ các request bị chặn mà administrator đang cần tìm. Mã đúng cho truy cập bị từ chối là 403.

B — Athena truy vấn các báo cáo S3 Analytics tìm lỗi HTTP 403. Cũng là bẫy ghép nửa đúng nửa sai: mã lỗi 403 đúng, nhưng nguồn dữ liệu sai. S3 Analytics không phải là log request và không chứa mã trạng thái HTTP hay danh tính người gọi, nên có chỉ Athena vào đó cũng không có gì để lọc. Athena phải trỏ vào bucket chứa server access log.

E — Bật S3 Analytics trên các bucket bị ảnh hưởng và sinh báo cáo về các nỗ lực truy cập trái phép. Sai ngay ở mục đích của dịch vụ: S3 Analytics phân tích mẫu hình sử dụng dữ liệu để gợi ý storage class phù hợp (ví dụ dữ liệu ít truy cập nên chuyển sang lớp lưu trữ rẻ hơn). Nó hoàn toàn không ghi nhận thông tin truy cập ở mức từng request, nên không thể sinh ra báo cáo mà phương án này hứa hẹn. Đây là phương án bịa ra một khả năng dịch vụ không có.

📌 Điểm cần nhớ

• 403 = Access Denied, 503 = Service Unavailable. Đề nói tới truy cập trái phép hoặc bị từ chối thì lọc 403; đề nói tới dịch vụ không phục vụ được thì mới là 5xx. Đây là điểm phân biệt rẻ tiền nhưng xuất hiện rất thường xuyên trong đề thi.
• S3 Server Access Logging là nguồn duy nhất trong danh sách cho biết "ai truy cập bucket nào". Nó ghi requester, remote IP, bucket đích và mã trạng thái — cứ thấy đề hỏi danh tính người gọi ở mức từng request S3 thì nghĩ tới nó, và luôn lưu log sang bucket riêng.
• S3 Analytics là công cụ tối ưu chi phí lưu trữ, không phải công cụ bảo mật. Nó gợi ý storage class dựa trên mẫu hình sử dụng, không ghi log truy cập.
• Athena là lớp truy vấn, không phải lớp thu thập. Athena chỉ đọc được thứ đã nằm sẵn trong S3, nên câu "Select TWO" kiểu này thường ghép một bước bật logging với một bước truy vấn log; nếu chọn hai phương án đều là truy vấn thì thiếu mất nguồn dữ liệu.

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

Đề mô tả một CloudWatch alarm bị kích hoạt liên tục và "appears to remain in the ALARM state persistently" — nằm lì ở trạng thái ALARM. Câu hỏi là: điều gì giải thích được hành vi đó?

Cụm từ quyết định là "remain in the ALARM state persistently". Nó buộc ta phải trả lời đúng một câu: cái gì quyết định trạng thái của một CloudWatch alarm? Mọi phương án nhiễu đều đánh vào những thứ xung quanh alarm — SNS topic, IAM role, tình trạng của EC2 instance — chứ không phải cái đang thực sự điều khiển trạng thái. Một CloudWatch alarm theo dõi một metric trong một khoảng thời gian xác định, so giá trị metric đó với threshold đã đặt, rồi từ kết quả so sánh mà chuyển giữa OK, ALARM và INSUFFICIENT_DATA. Chỉ có dữ liệu metric so với threshold mới đổi được trạng thái.

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

Đáp án đúng là B — "The evaluated metrics persistently exceed the defined thresholds, keeping the alarm active".

Đây chính là mô tả nguyên lý hoạt động của CloudWatch alarm. Alarm đánh giá metric theo từng chu kỳ; khi giá trị vượt ngưỡng đủ số chu kỳ theo cấu hình, alarm chuyển sang ALARM. Và quan trọng: alarm không tự trở về OK theo thời gian — nó chỉ đổi trạng thái khi lần đánh giá tiếp theo cho kết quả khác. Nếu metric cứ tiếp tục vượt threshold ở mọi chu kỳ, alarm nằm nguyên ở ALARM.

Nói cách khác, "alarm kẹt ở ALARM" không phải là một lỗi cấu hình — đó là hệ thống đang báo đúng: điều kiện bất thường vẫn còn đó. Việc cần làm là xử lý nguyên nhân gây ra metric cao, hoặc xem lại threshold đặt đã hợp lý chưa.

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

A — SNS topic chưa được verify làm "khoá" trạng thái alarm. Đây là phương án dễ mắc bẫy nhất vì SNS thật sự có liên quan tới alarm. Nhưng nó nhầm vai trò: SNS chỉ là đích đến của hành động khi alarm đổi trạng thái, không phải đầu vào quyết định trạng thái. Nếu subscription chưa được xác nhận, hậu quả là không ai nhận được thông báo — còn bản thân alarm vẫn chuyển trạng thái bình thường theo metric. Không có cơ chế nào trong CloudWatch cho phép khâu notification "khoá" trạng thái alarm lại cả.

C — Thiếu IAM role cho phép alarm đổi trạng thái. Sai ở tiền đề. Việc đánh giá metric và chuyển trạng thái là do chính dịch vụ CloudWatch làm, không cần một IAM role gắn vào alarm để "được phép" đổi state. IAM chỉ xuất hiện ở những chỗ khác: quyền của người dùng để tạo/sửa/xoá alarm hay gọi SetAlarmState, hoặc role cho một số alarm action như EC2 Auto Scaling. Không có role nào là điều kiện để alarm tự chuyển OK ⇄ ALARM.

D — EC2 instance đang stopped nên alarm buộc phải ở ALARM. Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì instance dừng đúng là có ảnh hưởng tới metric. Nhưng suy luận bị lệch hướng: khi instance dừng, nó ngừng gửi dữ liệu metric, và alarm thiếu dữ liệu thường rơi vào INSUFFICIENT_DATA chứ không phải bị "ép" ở ALARM (hành vi cụ thể còn tuỳ cách cấu hình xử lý missing data). Quan trọng hơn: từ "forcing" trong phương án là sai bản chất — không có trạng thái nào của tài nguyên được giám sát mà buộc alarm phải đứng yên; alarm luôn đánh giá lại ở chu kỳ kế tiếp và sẽ đổi trạng thái ngay khi điều kiện không còn được thoả.

📌 Điểm cần nhớ

• Trạng thái CloudWatch alarm chỉ do kết quả so sánh metric với threshold quyết định. Mọi thứ khác — SNS, IAM, tình trạng tài nguyên — không trực tiếp đặt state.
• SNS là kết quả của việc alarm đổi trạng thái, không phải nguyên nhân. Lỗi SNS/subscription chưa xác nhận biểu hiện thành "không nhận được thông báo", chứ không thành "alarm sai trạng thái".
• Alarm không tự hết hạn hay tự reset; nó ở ALARM chừng nào lần đánh giá tiếp theo còn cho kết quả vượt ngưỡng. "Alarm kêu mãi" thường nghĩa là sự cố còn đó hoặc threshold đặt quá nhạy.
• Ba trạng thái cần phân biệt: OK, ALARM, và INSUFFICIENT_DATA — thiếu dữ liệu (ví dụ nguồn metric ngừng phát) thuộc về trạng thái thứ ba, đừng nhầm sang ALARM.

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

Đề mô tả một ứng dụng mã hoá dữ liệu bằng AWS KMS customer master key (CMK) và hỏi quy trình xoay vòng key mỗi 6 tháng theo chính sách công ty.

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

• "with imported key material" — CMK này dùng key material do khách hàng tự nhập vào (BYOK), không phải key material do KMS sinh ra. Đây là ràng buộc phân biệt: mọi cơ chế xoay vòng tự động của KMS đều không áp dụng được cho loại CMK này.
• "The CMK is referenced by an alias in the application code" — ứng dụng gọi key qua alias chứ không gọi thẳng key ID. Chi tiết này không phải để trang trí: nó chính là thứ cho phép thay CMK mà không phải sửa và triển khai lại mã ứng dụng.

Ghép hai ràng buộc lại: không xoay vòng tự động được → phải xoay vòng thủ công; mà xoay vòng thủ công trong KMS nghĩa là tạo CMK mới rồi trỏ alias sang CMK mới.

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

B. Import new key material into a new CMK, update the key alias to point to the new CMK.

Khi bạn import key material vào một CMK, CMK đó bị gắn vĩnh viễn với đúng phần key material ấy. Bạn có thể reimport lại chính key material cũ (chẳng hạn sau khi nó hết hạn hoặc bị xoá), nhưng không thể import một key material khác vào cùng CMK đó. Ngoài ra, CMK có imported key material không bật được automatic key rotation.

Vì vậy con đường duy nhất còn lại là xoay vòng thủ công: tạo một CMK mới, import key material mới vào CMK mới đó, rồi cập nhật alias để trỏ sang CMK mới. Từ thời điểm đó, mọi lời gọi mã hoá của ứng dụng — vốn tham chiếu qua alias — tự động dùng key mới mà không cần chạm vào code. CMK cũ vẫn giữ lại để giải mã các dữ liệu đã mã hoá trước đó, vì ciphertext của KMS ghi kèm ID của key đã dùng.

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

A. Delete the current key material and import new material into the existing CMK. — Đây là phương án gần đúng nhất và cũng là bẫy chính. Việc delete key material là thao tác có thật trong KMS, nên nghe rất hợp lý. Chỗ hỏng nằm ở vế sau: sau khi xoá, CMK đó chỉ chấp nhận đúng key material cũ được import lại, chứ không nhận key material khác. Import material mới sẽ bị từ chối, và như vậy không tạo ra được key mới nào cả — không đạt yêu cầu rotate.

C. Enable automatic key rotation for the CMK and specify a period of 6 months. — Sai ở cả hai vế. Thứ nhất, automatic key rotation không bật được cho CMK có imported key material — đây chính là ràng buộc mà cụm từ trong đề nhắm tới. Thứ hai, ngay cả với CMK do KMS sinh key material, chu kỳ xoay vòng tự động là một giá trị do KMS định nghĩa chứ không phải con số tuỳ ý người dùng gõ vào là "6 months".

D. Use an AWS managed CMK with automatic rotation every 6 months. Update the alias. — Sai vì bạn không điều khiển được chu kỳ rotation của AWS managed CMK; lịch xoay vòng do AWS quy định, không phải tham số bạn đặt để khớp chính sách 6 tháng của công ty. Ngoài ra phương án này còn đi ngược yêu cầu ngầm của đề: đề nói rõ tổ chức đang dùng imported key material, tức là chủ động giữ quyền kiểm soát nguồn gốc key; chuyển sang AWS managed CMK là vứt bỏ chính quyền kiểm soát đó.

📌 Điểm cần nhớ

• Imported key material = không có automatic rotation. Thấy cụm "imported key material" trong đề thì loại ngay mọi phương án nói tới automatic key rotation.
• Một CMK gắn vĩnh viễn với một key material. Reimport lại đúng material cũ thì được; import material khác vào CMK cũ thì không. Muốn key mới thì phải có CMK mới.
• Alias là cơ chế xoay vòng thủ công của KMS. Ứng dụng tham chiếu alias → thay key chỉ là cập nhật alias, không phải sửa và deploy lại code. Nếu code hardcode key ID thì bài toán rotation sẽ khó hơn hẳn.
• AWS managed CMK không cho bạn đặt chu kỳ rotation. Chính sách nội bộ đòi một chu kỳ cụ thể (6 tháng, 3 tháng…) thì phải dùng customer managed CMK và tự xoay vòng.

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

Đề mô tả một công ty dựng bản sao lưu VPC ở Region thứ hai, dữ liệu được replicate từ primary region sang secondary region. Câu hỏi là: nối hai VPC đó bằng cách nào để vẫn đáp ứng yêu cầu tuân thủ?

Hai cụm từ trong đề quyết định đáp án, và phải đọc cả hai cùng lúc:

• "in another Region" — đây là kết nối cross-region, không phải hai VPC trong cùng một Region. Nó loại ngay mọi phương án chỉ hoạt động trong phạm vi một Region.
• "must be encrypted and must not traverse the public internet" — hai ràng buộc đi kèm nhau: đường truyền phải được mã hoá và không được đi qua Internet công cộng.

Vế thứ hai là chốt chặn thật sự. Một giải pháp có thể mã hoá dữ liệu mà vẫn đẩy gói tin ra Internet công cộng — như vậy là trượt một nửa yêu cầu. Phải tìm phương án thoả cả hai, tức là traffic nằm trên hạ tầng nội bộ của AWS.

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

B — Inter-region VPC peering giữa hai VPC, rồi cấu hình route table.

VPC peering tạo một liên kết mạng trực tiếp giữa hai VPC, cho phép chúng định tuyến tới nhau bằng địa chỉ private như thể nằm chung một mạng. Bản inter-region cho phép hai VPC ở hai Region khác nhau peering với nhau — đúng kịch bản trong đề.

Điểm mấu chốt khớp với yêu cầu tuân thủ: traffic đi qua inter-region VPC peering luôn nằm trên AWS global backbone và không bao giờ đi ra public internet, đồng thời được AWS mã hoá ở tầng hạ tầng. Người quản trị không phải tự dựng thêm lớp mã hoá nào. Nhờ vậy nó cắt bớt bề mặt tấn công — các dạng khai thác phổ biến hay DDoS nhắm vào endpoint công khai không chạm tới được đường truyền này.

Ngoài ra peering không có single point of failure và không bị nghẽn ở một thiết bị trung gian nào, nên nó là cách gọn và tiết kiệm để replicate dữ liệu phục vụ dự phòng theo vùng địa lý — đúng mục đích "backup của VPC ở Region khác" mà đề nêu. Sau khi thiết lập peering connection, việc còn lại chỉ là thêm route trỏ dải CIDR của VPC bên kia vào peering connection trong route table hai phía.

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

A — Internet gateway ở mỗi VPC, dùng làm target cho route table. Internet gateway sinh ra để đưa traffic ra ngoài Internet. Dùng nó làm cầu nối giữa hai VPC nghĩa là dữ liệu replicate sẽ đi qua đúng thứ mà đề cấm — public internet. Không thể dựng một kết nối private, được mã hoá giữa hai VPC bằng internet gateway. Phương án này vi phạm thẳng cả hai vế của yêu cầu.

C — AWS Managed VPN giữa hai VPC. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì VPN có mã hoá đường truyền (IPsec), nên nó thoả được vế "encrypted". Chỗ hỏng nằm ở vế còn lại và ở tính phù hợp: AWS Managed VPN được thiết kế để nối mạng on-premises của khách hàng với VPC, chứ không phải để nối hai VPC với nhau — dùng nó cho tình huống VPC-với-VPC không phải best practice. So với peering, nó thêm một lớp thiết bị VPN phải quản lý, phải chịu giới hạn thông lượng của đường hầm, và người quản trị lãnh thêm phần vận hành mà peering đã lo sẵn. Với yêu cầu chỉ đơn giản là nối hai VPC của cùng một tài khoản/tổ chức qua hai Region, peering là lựa chọn được chỉ định.

D — NAT gateway ở cả hai VPC. NAT gateway làm đúng một việc: cho tài nguyên trong subnet private khởi tạo kết nối đi ra ngoài mà không lộ IP public vào chiều ngược lại. Nó là thành phần một chiều phục vụ outbound, không phải cơ chế kết nối hai mạng lại với nhau. Không tạo được kết nối private, được mã hoá giữa hai VPC bằng NAT gateway. Hơn nữa NAT gateway vẫn cần internet gateway đứng sau nó, nên hướng này rốt cuộc lại quay về vấn đề của phương án A.

📌 Điểm cần nhớ

• Đề nêu "không được đi qua public internet" giữa hai VPC ở hai Region → nghĩ ngay tới inter-region VPC peering: traffic ở lại trên AWS global backbone và được mã hoá sẵn.
• Phân biệt vai trò từng thành phần: internet gateway = ra Internet hai chiều, NAT gateway = ra Internet một chiều cho subnet private. Cả hai đều là lối ra Internet, không phải công cụ nối hai VPC.
• AWS Managed VPN dành cho kết nối on-premises ↔ VPC. Có mã hoá không có nghĩa là đúng — khi cả hai đầu đều là VPC, peering mới là cách được khuyến nghị.
• Đọc kỹ "another Region": nó quyết định phải dùng bản inter-region của giải pháp, và loại bỏ những lựa chọn chỉ có nghĩa trong phạm vi một Region.

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

Đề mô tả một môi trường production đang chạy trên đúng một EC2 instance, và instance đó ôm cả hai vai trò: web interface của ứng dụng và MySQL database. Yêu cầu là làm cho môi trường này đạt high availability theo chính sách công ty.

Cụm từ quyết định là "a single Amazon EC2 instance which hosts both the application's web interface and a MySQL database" cộng với "high availability". Hai chi tiết này ghép lại cho biết:

• Có hai single point of failure chứ không phải một — tầng web và tầng database. Phương án nào chỉ chữa một tầng, hoặc chữa nửa vời một tầng, là trượt.
• "High availability" trong ngữ cảnh AWS nghĩa là chịu được sự cố ở mức Availability Zone và chuyển đổi dự phòng tự động, không phải "có bản sao ở đâu đó rồi khi hỏng thì dựng lại". Khôi phục thủ công hay tự viết cơ chế failover là disaster recovery, không phải HA.

Đó chính là cây thước để loại A, B, D.

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

Đáp án đúng theo tệp là C: chuyển database sang Amazon RDS for MySQL Multi-AZ DB instance, chạy ứng dụng trên EC2 instances trong một Auto Scaling group trải qua nhiều Availability Zone, và đặt một load balancer phía trước.

Phương án này xử lý trọn cả hai tầng:

• Tầng database: với Multi-AZ deployment, RDS tự tạo và duy trì một standby replica đồng bộ (synchronous) ở một Availability Zone khác. Khi primary DB instance hỏng, standby tiếp quản, ứng dụng chạy tiếp mà không phải dựng lại gì. Việc failover là do dịch vụ quản lý lo, không phải do quản trị viên tự viết.
• Tầng ứng dụng: Auto Scaling group trải trên nhiều AZ giữ đúng số lượng instance mong muốn — instance nào hỏng thì nó tự khởi chạy cái mới, và mất nguyên một AZ thì các AZ còn lại vẫn phục vụ.
• Load balancer (Application Load Balancer hoặc Network Load Balancer) phân phối lưu lượng đến các instance đang khoẻ, cho người dùng một điểm vào duy nhất và không dồn traffic vào instance đã chết.

Điểm mạnh chung: toàn bộ dựa trên dịch vụ được quản lý (Amazon RDS, EC2 Auto Scaling, Elastic Load Balancing), gánh nặng vận hành và độ phức tạp đổ về phía AWS chứ không nằm trên vai SysOps administrator.

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

A — nhân bản database sang EC2 khác + AMI qua AWS Backup + Lambda health check mỗi phút. Đây là phương án cố mô phỏng lại bằng tay đúng thứ mà RDS Multi-AZ và Auto Scaling đã làm sẵn. Ba chỗ hỏng: sao chép database thủ công sang EC2 khác không bảo đảm tính nhất quán dữ liệu; khôi phục từ AMI nghĩa là quay về ảnh chụp tại thời điểm sao lưu, dữ liệu ghi sau đó có nguy cơ mất; và tự viết Lambda làm health check + điều phối khôi phục là một khối logic tự chế phải tự bảo trì, dễ sai. Nó có thể tạo ra chút dư thừa, nhưng không phải HA với failover tự động đáng tin cậy.

B — RDS for MySQL Multi-AZ + refactor ứng dụng thành AWS Lambda bằng AWS Application Migration Service. Nửa đầu đúng — chuyển database sang RDS Multi-AZ là thực hành tốt. Nửa sau mới là chỗ chết: AWS Lambda không phải là vật thay thế trực tiếp cho một web application đang chạy trên EC2, việc "refactor" như vậy không phải một thao tác cấu hình mà là viết lại ứng dụng. Quan trọng hơn, Lambda không có "Multi-AZ option" để bật — function là stateless, tự scale và không gắn với một Availability Zone cụ thể, nên câu chữ trong phương án mô tả một nút bấm không tồn tại. Đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi: đúng tầng database, sai hoàn toàn ở tầng ứng dụng.

D — chuyển database sang EC2 khác + Auto Scaling cho ứng dụng + EC2 database thứ hai dựng từ AMI, để ở trạng thái stopped làm standby. Phần ứng dụng (Auto Scaling group qua nhiều AZ) là hợp lý, nhưng phần database phá hỏng tất cả. Một database instance đang ở trạng thái stopped không phải là standby: nó không nhận dữ liệu mới, nên khoảng cách giữa lần đồng bộ cuối và thời điểm sự cố là dữ liệu mất trắng; khởi động một EC2 instance còn tốn thời gian, nghĩa là có gián đoạn dịch vụ; và không có cơ chế failover tự động nào ở đây — phải có người vào bấm. Tự quản lý replication và failover cho database là việc phức tạp, dễ sai, đúng thứ mà RDS Multi-AZ sinh ra để thay thế. Ngoài ra phương án này còn thiếu load balancer phía trước Auto Scaling group.

📌 Điểm cần nhớ

• Đề nêu một instance ôm nhiều vai trò thì lời giải phải tách vai trò ra và làm HA cho từng tầng; phương án chỉ chữa một tầng luôn là phương án sai, dù tầng đó chữa rất đúng (xem B).
• High availability = failover tự động + trải qua nhiều Availability Zone. Bản sao lưu, AMI, hay máy dự phòng đang tắt thuộc về disaster recovery — chúng chấp nhận mất dữ liệu và có thời gian chờ, nên không đáp ứng yêu cầu HA.
• Với database quan hệ trên AWS, mẫu chuẩn là RDS Multi-AZ với standby replica đồng bộ ở AZ khác; tự dựng replication trên EC2 là đánh đổi lấy rủi ro nhất quán dữ liệu mà không được gì thêm.
• Với tầng web, mẫu chuẩn là Auto Scaling group qua nhiều AZ + load balancer phía trước — ASG lo thay thế instance hỏng, load balancer lo không gửi traffic tới instance đã chết. Thiếu load balancer thì các instance dư thừa cũng vô nghĩa với người dùng.
• Khi hai phương án cùng đúng ở một nửa, hãy soi phần còn lại xem nó có mô tả một tính năng thật sự tồn tại hay không: "Multi-AZ option" cho Lambda là ví dụ điển hình của lựa chọn nghe hợp lý nhưng không có thật.

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

Đề mô tả một tổ chức AWS Organizations gồm nhiều member account, và điểm mấu chốt nằm ở câu: "Various team administrators have access to the root user credentials of the member accounts" — các đội đang nắm được thông tin đăng nhập root của chính account họ. Yêu cầu là chặn mọi người, kể cả account administrator, dùng Amazon Redshift, đồng thời "should not interfere with the teams' ability to use other AWS services" — không được làm ảnh hưởng các dịch vụ khác.

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

• root user credentials → mọi giải pháp dựa trên IAM policy trong từng account đều vô hiệu, vì root user không bị IAM policy trong account ràng buộc, và người có root còn sửa hoặc gỡ được chính policy đó.
• all member accounts trong AWS Organizations → cần một cơ chế điều khiển tập trung từ management account, áp xuống toàn tổ chức.
• không ảnh hưởng dịch vụ khác → phải là một guardrail chỉ chặn đúng Redshift, không đụng tới quyền hiện có của các dịch vụ còn lại.

Cơ chế duy nhất trong danh sách phương án đáp ứng cả ba là Service Control Policy (SCP) của AWS Organizations.

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

Đáp án D — tạo SCP trong management account với nội dung Deny toàn bộ action của Redshift, rồi gắn vào root of the organization.

• SCP là ranh giới quyền tối đa (permission boundary) áp lên toàn bộ account thành viên. Gắn ở root của organization nghĩa là mọi account trong tổ chức, hiện tại lẫn thêm về sau, đều nằm dưới ranh giới đó.
• SCP có hiệu lực với cả root user của member account — đây chính là điểm mà mọi phương án IAM không làm được. Root user của member account không thể vượt qua SCP do management account đặt.
• SCP không cấp quyền, nó chỉ giới hạn. Một SCP chỉ chứa Deny cho Redshift sẽ để nguyên các quyền còn lại đang được cấp qua IAM, nên các dịch vụ khác vẫn dùng bình thường — đúng ràng buộc "không được ảnh hưởng dịch vụ khác".
• Quản lý ở một chỗ duy nhất (management account), không phải đi sửa từng account.

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

A. Xoá SCP mặc định rồi thay bằng một SCP chỉ có một statement deny Redshift. Đây là phương án gần đúng nhất vì nó cũng dùng SCP — nhưng nó hỏng ở chỗ xoá SCP mặc định. SCP mặc định (FullAWSAccess) là thứ cho phép mọi action đi qua ranh giới của Organizations. Gỡ nó ra và thay bằng một policy chỉ có duy nhất một statement Deny Redshift, thì không còn statement Allow nào ở tầng SCP nữa — ranh giới quyền co lại thành gần như không cho phép gì cả, và mọi dịch vụ khác cũng chết theo, vi phạm thẳng yêu cầu "không ảnh hưởng dịch vụ khác". Cách làm đúng là giữ SCP mặc định và thêm một SCP deny, chứ không thay thế.

B. Dùng policy AmazonRedshiftFullAccess trong từng member account để chặn mọi người kể cả root. Sai từ bản chất của policy: AmazonRedshiftFullAccess là một AWS managed policy cấp quyền (Allow) đầy đủ trên Redshift. Không gắn nó thì cũng không có nghĩa là cấm; còn gắn nó thì lại đang mở quyền chứ không đóng. Ngoài ra vẫn dính đúng vấn đề cốt lõi của đề: đây là IAM trong từng account, root user không bị nó ràng buộc và người nắm root có thể tự gỡ.

C. Tạo IAM policy deny Redshift trong từng member account cho mọi user kể cả root. Về mặt cú pháp thì một Deny trong IAM có thắng Allow thật, nhưng phương án này hỏng ở hai chỗ:

• Root user của account không chịu ràng buộc của IAM identity policy trong chính account đó. Đề đã nói rõ các team administrator có root credentials, nên đây chính là kịch bản mà phương án này thất bại.
• Kể cả nếu chặn được người dùng thường, người có root vẫn sửa hoặc xoá được policy vừa tạo — một biện pháp mà đối tượng bị chặn có quyền tháo ra thì không phải là biện pháp.
• Thêm nữa, làm thủ công ở "every member account" là cách vận hành không tập trung, dễ sót account mới và khó duy trì — trái với tinh thần của một tổ chức dùng AWS Organizations.

📌 Điểm cần nhớ

• Hễ đề nhắc tới AWS Organizations + chặn một dịch vụ trên nhiều account + người dùng có root credentials, đáp án gần như luôn là SCP, không phải IAM policy. IAM không kiểm soát được root user của chính account đó; SCP thì có.
• SCP không cấp quyền, chỉ giới hạn quyền. Vì vậy thêm một SCP Deny cho đúng một dịch vụ là cách sạch nhất để chặn dịch vụ đó mà không đụng tới các dịch vụ còn lại.
• Đừng xoá SCP FullAWSAccess mặc định. Cách đúng là thêm SCP deny bên cạnh nó. Thay thế bằng một policy chỉ có Deny sẽ khiến ranh giới quyền không còn Allow nào và làm gãy toàn bộ tổ chức.
• Gắn SCP ở root of the organization khi muốn phủ toàn tổ chức; gắn vào một OU khi chỉ muốn phủ nhóm account trong OU đó. Chọn điểm gắn theo đúng phạm vi đề yêu cầu.
• Cảnh giác với các phương án nêu tên AWS managed policy có chữ FullAccess rồi bảo là dùng để "deny" — những policy đó là policy Allow, đọc kỹ tên là loại được ngay.

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

Một web application chạy trên nhiều EC2 instance trong một Auto Scaling group (ASG) trải khắp tất cả các Availability Zone của Region. Vấn đề: vào giờ cao điểm, ASG không launch thêm instance mới, trong khi maximum capacity của ASG chưa đạt tới. Câu hỏi yêu cầu chọn HAI việc để tìm ra nguyên nhân (identify the cause).

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

• "The maximum capacity of the ASG has not been reached" — câu này gạt bỏ ngay lời giải thích hiển nhiên nhất. Nếu ASG đã chạm max thì chuyện không scale out là hành vi bình thường. Vì max chưa chạm, nguyên nhân phải nằm ngoài cấu hình ASG: hoặc là giới hạn ở tầng account (service limit / quota của EC2), hoặc là lời gọi launch bị từ chối vì lý do khác (permissions, cấu hình launch sai).
• "across all Availability Zones" — ASG đã dàn trải khắp AZ, nên một sự cố cục bộ ở một AZ khó mà chặn đứng toàn bộ việc launch. Cụm này chính là thứ để loại phương án C.
• "identify the cause" — đề hỏi cách chẩn đoán, không hỏi cách khắc phục. Nên câu trả lời phải là những công cụ cho ta nhìn thấy dấu vết, chứ không phải công cụ vận hành chung chung.

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

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

A — Use AWS Trusted Advisor to check if service limits have been reached. Trusted Advisor có mục kiểm tra service limit, trong đó có giới hạn liên quan tới EC2 ở cấp account/Region. Khi account chạm giới hạn số instance được phép chạy, EC2 sẽ từ chối yêu cầu launch mới — ASG vẫn cố scale out nhưng không tạo được instance nào, đúng với triệu chứng "max capacity chưa chạm mà vẫn không có instance mới". Đây là một trong những nguyên nhân khả dĩ, và Trusted Advisor là nơi kiểm tra nhanh nhất.

E — Use AWS CloudTrail to check the result of RunInstances requests. ASG launch instance bằng cách gọi API RunInstances. CloudTrail ghi lại các lời gọi API kèm kết quả của chúng, nên đọc log CloudTrail sẽ thấy RunInstances có được gọi hay không, và nếu bị từ chối thì mã lỗi là gì. Bản giải thích gốc nêu rõ: nếu có vấn đề về permissions thì cách này sẽ chỉ ra. Đây là bằng chứng trực tiếp nhất về việc "vì sao instance không ra đời".

Hai phương án bổ trợ cho nhau: A kiểm tra giả thuyết "chạm quota", E kiểm tra mọi giả thuyết còn lại bằng chính thông báo lỗi mà EC2 trả về.

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

B — Monitor limits in AWS Systems Manager. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nó nhắc đúng từ khoá "limits" giống phương án A. Nhưng Systems Manager là bộ công cụ quản lý vận hành trên chính các instance — chạy lệnh, quản lý patch, giữ tham số cấu hình, lưu trữ inventory. Nó không phải là nơi theo dõi service limit của AWS account. Chọn B là bám vào từ khoá thay vì bám vào chức năng thật của dịch vụ.

C — Check the AWS Personal Health Dashboard for outage events. Personal Health Dashboard đúng là nơi xem sự cố ảnh hưởng tới tài nguyên của mình, nên nghe rất hợp lý với "ứng dụng không hoạt động như mong đợi". Chỗ nó hỏng nằm ở chi tiết đã nêu trong đề: ASG được cấu hình dùng toàn bộ AZ trong Region. Một sự cố hạ tầng đủ sức chặn launch ở mọi AZ cùng lúc là tình huống rất khó xảy ra, nên đây không phải hướng chẩn đoán hợp lý cho triệu chứng này.

D — Use Amazon Inspector to view performance information. Sai ngay ở mô tả dịch vụ. Amazon Inspector phục vụ đánh giá bảo mật và tuân thủ — dò lỗ hổng, kiểm tra cấu hình rủi ro. Nó không phải công cụ xem thông tin hiệu năng, và cũng chẳng liên quan gì tới việc ASG có launch được instance hay không. Phương án này sai cả về mục đích lẫn về chủ đề.

📌 Điểm cần nhớ

• ASG không scale out mà chưa chạm max capacity → nghi ngờ hai thứ trước tiên: service limit của account và quyền/lỗi khi gọi API launch. Cấu hình ASG lúc này không phải thủ phạm.
• CloudTrail là nơi xem kết quả lời gọi API. Mọi câu hỏi dạng "tại sao hành động X không xảy ra / ai đã làm X / X bị từ chối vì sao" đều dẫn về CloudTrail. Với ASG, API cần soi là RunInstances.
• Trusted Advisor là câu trả lời quen thuộc cho việc kiểm tra service limit; Systems Manager thì không — đừng để từ khoá "limits" trong phương án đánh lừa.
• Nhớ đúng phạm vi từng dịch vụ để loại nhanh: Inspector = bảo mật/tuân thủ (không phải hiệu năng), Personal Health Dashboard = sự cố phía AWS ảnh hưởng tới tài nguyên của bạn. Chi tiết "trải khắp mọi AZ" trong đề chính là thứ làm phương án Health Dashboard mất sức thuyết phục.

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

Đề mô tả một công ty muốn kiểm kê (inventory) các ứng dụng đang chạy trên nhiều EC2 instance bằng AWS Systems Manager. Khi bật thu thập inventory, SysOps administrator phát hiện Systems Manager không quản lý được toàn bộ instance nằm trong một subnet. Câu hỏi là: phải làm gì để khắc phục?

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

• "Users and roles with appropriate permissions for AWS Systems Manager have been set up" — quyền đã cấp cho người dùng và role của con người, tức là phần quyền để gọi API Systems Manager từ phía quản trị đã ổn. Đề cố tình không nói gì tới quyền của bản thân instance.
• "An updated Systems Manager Agent version is installed and operational on every instance" — loại bỏ hướng nghi ngờ SSM Agent thiếu hoặc lỗi thời.

Khi một instance đã có SSM Agent chạy tốt mà vẫn không xuất hiện trong danh sách managed instance, mảnh ghép còn lại theo cách đề dựng lên chính là instance profile — IAM role gắn vào EC2 để agent có quyền đăng ký và gọi ngược về Systems Manager.

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

B — Ensure that all the EC2 instances are configured with an instance profile with Systems Manager access.

Systems Manager cần quyền để thao tác thay mặt bạn trên chính instance đó. Quyền này không đến từ user hay role của quản trị viên, mà đến từ IAM role gắn trực tiếp vào EC2 instance — gọi là instance profile. SSM Agent chạy trong instance lấy thông tin xác thực tạm thời từ instance profile để đăng ký với dịch vụ và gửi dữ liệu inventory về.

Vì vậy, khi một instance không được Systems Manager quản lý, nguyên nhân nhiều khả năng nhất là instance đó không có instance profile, hoặc có nhưng instance profile thiếu quyền cần thiết cho Systems Manager. Việc cần làm là kiểm tra và cập nhật instance profile cho những instance đang thiếu.

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

A — Cấu hình interface VPC endpoint cho VPC và subnet tương ứng. Đây là phương án gần đúng nhất và đáng phân tích kỹ. Interface VPC endpoint cho phép instance nối tới Systems Manager qua đường riêng, không cần internet gateway, VPN hay Direct Connect — hữu ích về bảo mật và đôi khi cả hiệu năng. Nhưng nó chỉ giải quyết bài toán đường mạng, không giải quyết bài toán quyền. Ngay cả khi endpoint đã có, instance vẫn phải mang IAM role với quyền Systems Manager thì mới đăng ký được. Nói cách khác, A xử lý một điều kiện khác, và trong bối cảnh đề bài thì thứ còn thiếu là quyền chứ không phải kết nối.

C — Kiểm tra instance đã gắn tag phù hợp để Systems Manager truy cập. Tag là metadata để phân loại và tổ chức tài nguyên AWS. Tag có thể được dùng kèm IAM policy làm điều kiện cho phép hay từ chối, nhưng bản thân tag không cấp quyền cho bất cứ thứ gì. Không có cơ chế nào mà chỉ cần dán tag lên EC2 là instance đó tự trở thành managed instance. Tag không tác động tới mặt vận hành của Systems Manager.

D — Dùng IAM Access Analyzer để phát hiện và tự động sửa lỗi. IAM Access Analyzer phục vụ mục đích khác hẳn: nó giúp phát hiện các tài nguyên trong tổ chức hoặc tài khoản (ví dụ S3 bucket, IAM role) đang được chia sẻ với thực thể bên ngoài tài khoản của bạn. Đây là công cụ phân tích phạm vi truy cập, không phải công cụ chẩn đoán sự cố Systems Manager. Quan trọng hơn, nó không tự động sửa vấn đề — vế "automatically rectify" trong phương án là chỗ sai rõ nhất.

📌 Điểm cần nhớ

• Instance profile là điều kiện nền tảng để EC2 trở thành managed instance của Systems Manager. Đề nói "user và role đã có quyền" không đồng nghĩa với "instance đã có quyền" — hai chủ thể hoàn toàn khác nhau, và đây là bẫy phân biệt kinh điển.
• Khi gỡ lỗi instance không xuất hiện trong Systems Manager, hai thứ cần soát trước tiên là SSM Agent và IAM instance profile. Đề bài loại bỏ manh mối nào thì đáp án nằm ở manh mối còn lại.
• VPC endpoint giải quyết kết nối, IAM giải quyết quyền. Đừng dùng endpoint để trả lời một câu hỏi về quyền hạn, và ngược lại.
• Tag không phải cơ chế cấp quyền độc lập — nó chỉ có ý nghĩa khi được IAM policy tham chiếu tới như một điều kiện.
• Cảnh giác với các phương án hứa "tự động khắc phục". IAM Access Analyzer chỉ phát hiện phạm vi chia sẻ ra ngoài tài khoản, không sửa gì cả.