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

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

Đề mô tả một công ty bán lẻ muốn thôi tự vận hành hạ tầng IT, và cần archive khoảng 5PB dữ liệu từ data center on-premises lên kho lưu trữ dài hạn, bền bỉ. Câu hỏi yêu cầu cách migrate dữ liệu này theo hướng MOST cost-optimal.

Có ba cụm từ quyết định:

• "about 5PB" — khối lượng ở mức petabyte. Đây là ngưỡng mà truyền qua đường mạng trở nên phi thực tế về thời gian và chi phí; đó là lý do tồn tại của họ thiết bị Snowball.
• "durable long term storage" + "MOST cost-optimal" — đích đến phải là Glacier, không phải S3 lớp tiêu chuẩn.
• "migrate this data" (one-time) — đây là một lần chuyển dữ liệu, không phải nhu cầu kết nối lâu dài. Ràng buộc này loại thẳng các phương án dựng đường mạng thường trực.

Cụm phân biệt tinh vi nhất nằm ở chỗ khác: sự khác nhau giữa A và C không phải ở cách vận chuyển (cả hai đều dùng Snowball Edge Storage Optimized) mà ở điểm đổ dữ liệu xuống.

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

Đáp án đúng là C: chuyển dữ liệu on-premises vào nhiều thiết bị Snowball Edge Storage Optimized, copy dữ liệu từ Snowball Edge vào Amazon S3, rồi tạo lifecycle policy để chuyển tiếp dữ liệu sang Glacier.

Hai vế đều cần thiết:

• Snowball Edge Storage Optimized là lựa chọn đúng khi cần chuyển an toàn và nhanh khối dữ liệu từ hàng chục TB đến hàng PB lên AWS. Mỗi thiết bị mang dung lượng HDD lớn cùng vCPU, SSD và kết nối mạng tốc độ cao để phục vụ nạp dữ liệu quy mô lớn — với 5PB thì dùng nhiều thiết bị song song.
• Snowball Edge không đổ dữ liệu thẳng vào Glacier được. Điểm đến của một job Snowball là một S3 bucket. Muốn dữ liệu nằm ở Glacier thì phải đi qua S3 trước, sau đó dùng lifecycle policy để transition sang lớp Glacier. Đây chính là bước mà phương án A thiếu, và là lý do C tồn tại như một phương án riêng.

Kết quả cuối cùng vẫn là dữ liệu nằm ở Glacier đúng như yêu cầu "durable long term storage", nhưng đi bằng con đường thực sự làm được.

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

A — Snowball Edge rồi copy thẳng vào Glacier. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Phần vận chuyển vật lý hoàn toàn chuẩn; cái sai nằm ở nửa sau: không có cách copy trực tiếp dữ liệu từ thiết bị Snowball Edge vào Glacier. Đích của job import là S3. Thiếu bước trung gian qua S3 + lifecycle policy thì quy trình mô tả trong A không thực hiện được.

B — AWS Direct Connect rồi truyền dữ liệu vào Glacier. Direct Connect thiết lập một kết nối mạng chuyên dụng giữa mạng của khách hàng và một Direct Connect location, và có thể chia thành nhiều virtual interface bằng VLAN chuẩn 802.1q. Vấn đề là Direct Connect đòi hỏi đầu tư tiền bạc đáng kể và thời gian thiết lập kéo dài (thường phải tính bằng tháng, vì liên quan tới nhà cung cấp mạng và cáp vật lý). Với một nhu cầu chuyển dữ liệu một lần duy nhất, dựng hẳn một đường truyền chuyên dụng là không tối ưu về chi phí — trái thẳng với từ khóa "MOST cost-optimal".

D — Site-to-Site VPN rồi truyền dữ liệu vào Glacier. Site-to-Site VPN cho phép kết nối an toàn mạng on-premises hoặc chi nhánh vào Amazon VPC. Nó là giải pháp tốt khi có nhu cầu gấp và băng thông ở mức thấp đến trung bình. Nhưng VPN chạy trên đường Internet công cộng, băng thông bị giới hạn ở mức khiêm tốn — đẩy 5PB qua đó là không khả thi về thời gian. Khối lượng dữ liệu quá lớn khiến Site-to-Site VPN không phải lựa chọn đúng ở đây.

📌 Điểm cần nhớ

• Khối lượng dữ liệu là tín hiệu chọn phương thức migrate: hàng chục TB đến hàng PB → họ thiết bị Snowball; dữ liệu nhỏ hoặc đồng bộ liên tục → đường mạng.
• Snowball import vào S3, không import thẳng vào Glacier. Muốn dữ liệu kết thúc ở Glacier thì mẫu chuẩn luôn là Snowball → S3 → lifecycle policy → Glacier. Gặp phương án ghi "copy Snowball data into Glacier" thì gần như chắc chắn là bẫy.
• Phân biệt nhu cầu một lần với nhu cầu thường trực: Direct Connect và Site-to-Site VPN là kết nối lâu dài, chi phí và công sức thiết lập của chúng chỉ đáng khi có luồng dữ liệu liên tục — không hợp cho một cú migrate duy nhất.
• Direct Connect sai vì chi phí và thời gian thiết lập, Site-to-Site VPN sai vì băng thông. Hai lý do loại khác nhau, đừng gộp chung thành "kết nối mạng thì chậm".
• Khi đề dùng chữ in hoa MOST/LEAST, hãy tìm ràng buộc nào bị vi phạm ở từng phương án thay vì tìm phương án "chạy được" — nhiều phương án chạy được, chỉ một cái tối ưu.

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

Một startup tài chính nhỏ dùng Amazon EC2 cho hạ tầng máy chủ và Amazon S3 để lưu trữ. Tệp trên S3 là tài sản quan trọng, và công ty muốn theo dõi việc truy cập vào bucket phục vụ mục đích audit và bảo mật.

Cụm từ quyết định đáp án nằm ở câu tiếp theo: "a cost-effective way of doing this without incurring extra costs" — tức là không chỉ "rẻ", mà là không phát sinh thêm chi phí cho bản thân cơ chế ghi nhận. Đây là ràng buộc phân biệt, bởi vì xét riêng về mặt kỹ thuật thì có hơn một dịch vụ trong danh sách ghi lại được truy cập tới S3. Khi đề đã nêu rõ "không tốn thêm tiền", ta phải chọn cơ chế mà chính việc bật nó lên là miễn phí.

Ràng buộc phụ thứ hai: đối tượng cần theo dõi là truy cập vào tệp trong bucket (audit + security), chứ không phải hiệu năng ứng dụng hay lỗ hổng của EC2.

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

A — Enable Amazon S3 Server Access Logging là đáp án đúng theo tệp.

Server Access Logging là tính năng có sẵn của chính S3, mặc định tắt, bật lên cho từng bucket mà công ty thấy quan trọng. Mỗi bản ghi log mô tả một request truy cập, gồm những trường đúng thứ audit cần: ai gọi (requester), tên bucket, thời điểm request, hành động được thực hiện, mã trạng thái phản hồi, và mã lỗi nếu có. Log được ghi sang một bucket khác để phân tích — đúng như phương án mô tả.

Về mặt chi phí: không có phí phụ thu cho việc bật server access logging, và cũng không bị tính tiền cho các thao tác PUT khi hệ thống đẩy log vào bucket đích. Thứ duy nhất bị tính là chi phí lưu trữ thông thường của các tệp log đó như mọi object khác (và chi phí đọc/truyền dữ liệu nếu về sau có truy xuất chúng) — mà những tệp này có thể xoá bất cứ lúc nào. Đây chính là lý do nó khớp với vế "without incurring extra costs" của đề.

Một chi tiết vận hành đáng nhớ: khi bật logging, log được lưu vào bucket cùng AWS Region với bucket nguồn.

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

B — AWS X-Ray tracing S3 requests end-to-end. X-Ray thu thập dữ liệu về các request mà ứng dụng của bạn phục vụ, để xem và lọc nhằm tìm ra vấn đề hiệu năng và lỗi trong kiến trúc phân tán, micro-services. Với một request được trace, nó cho thấy chi tiết request, response, và các lời gọi mà ứng dụng thực hiện xuống tài nguyên AWS, micro-services, database, HTTP web API. Sai ở hai điểm: nó là công cụ chẩn đoán hiệu năng/lỗi, không phải bản ghi audit truy cập bucket; và X-Ray là dịch vụ có tính phí, vi phạm thẳng ràng buộc của đề. Dùng nó ở đây là dao mổ trâu giết gà.

C — Amazon Inspector. Mô tả trong phương án ("theo dõi các lời gọi tới dịch vụ AWS được cấu hình với nó") là mô tả sai về Inspector. Inspector là dịch vụ security assessment: nó kiểm tra khả năng truy cập mạng ngoài ý muốn tới các EC2 instance và các lỗ hổng (vulnerabilities) trên chính những instance đó. Nó không phải công cụ trace request truy cập S3. Phương án này bẫy người đọc bằng cách gắn nhãn "security" cho một câu hỏi có chữ "security purposes" trong đề.

D — AWS CloudTrail. Đây là phương án gần đúng nhất, và cần nói rõ nó hỏng ở đâu. S3 có cho phép nhận diện request bằng CloudTrail event log, và AWS cũng khuyến nghị dùng CloudTrail để lấy thông tin về bucket. Nhưng có hai vướng mắc:

• Về phạm vi: mặc định CloudTrail ghi các lời gọi API ở mức bucket (bucket-level), không ghi request tới từng object. Muốn có dữ liệu mức object phải cấu hình thêm.
• Về chi phí: dữ liệu mà yêu cầu này cần cũng đã được S3 server access logging cung cấp — mà cái đó thì miễn phí. Khi đề nhấn mạnh "không phát sinh thêm chi phí", CloudTrail thua ở đúng tiêu chí phân biệt này.

Nói cách khác, D không phải "sai về kỹ thuật", mà là không tối ưu theo ràng buộc mà đề đưa ra.

📌 Điểm cần nhớ

• Khi đề S3 nhấn mạnh "no extra cost" / "cost-effective" cùng với "track access to buckets", đáp án nghiêng về S3 Server Access Logging — bật miễn phí, chỉ trả tiền lưu trữ tệp log.
• CloudTrail vs. Server Access Logging là cặp bẫy kinh điển của S3: CloudTrail mạnh về API audit nhưng mặc định ở mức bucket và là dịch vụ tính phí; câu nào không có ràng buộc chi phí thì CloudTrail lại thường là lựa chọn đúng. Đọc kỹ vế ràng buộc trước khi chọn.
• X-Ray = hiệu năng và troubleshooting ứng dụng phân tán, không phải audit truy cập lưu trữ — và nó tính phí.
• Amazon Inspector = đánh giá lỗ hổng và khả năng truy cập mạng của EC2, không liên quan tới việc ghi nhận ai đã đọc object trên S3. Đừng chọn nó chỉ vì đề có chữ "security".
• Bản ghi access log trả lời được các câu hỏi audit cơ bản: ai, bucket nào, lúc nào, làm gì, kết quả ra sao — nếu đề chỉ cần bấy nhiêu thì không cần công cụ nặng hơn.

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

Đề mô tả một công ty đã dùng AWS CloudFormation cho phần tài nguyên quan trọng, còn phần còn lại thì tạo và quản lý thủ công bên ngoài CloudFormation. Nay họ muốn đưa nốt số tài nguyên đang tồn tại đó vào CloudFormation quản lý.

Cụm từ quyết định đáp án là "move rest of the resources to CloudFormation" kết hợp với chi tiết những tài nguyên đó đã tồn tại rồi (được tạo thủ công, đang chạy). Đây không phải bài toán "tạo mới tài nguyên bằng template", cũng không phải "truyền tham số đầu vào cho template" — mà là bài toán đưa tài nguyên có sẵn vào dưới quyền quản lý của một stack, và quan trọng là không được xoá đi tạo lại (công ty đang vận hành thật).

Khi đề bài nói tới tài nguyên đã tồn tại ngoài stack, hãy nghĩ ngay tới cơ chế import chứ không phải các section trong template.

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

C — resource import đúng chính xác cho tình huống này. CloudFormation cho phép đưa một tài nguyên được tạo ngoài CloudFormation vào quản lý bởi stack, mà không cần xoá và tạo lại tài nguyên đó — đúng nhu cầu của một công ty đang chạy production.

Cách hoạt động của thao tác import:

• Bạn tạo một change set kiểu import, để import tài nguyên vào một stack đang có hoặc tạo stack mới từ chính các tài nguyên sẵn có.
• Bạn cung cấp template mô tả toàn bộ stack — gồm cả tài nguyên gốc của stack lẫn tài nguyên sắp import. Mỗi tài nguyên được import phải khai thuộc tính DeletionPolicy.
• Bạn cung cấp định danh cho từng tài nguyên cần import, gồm hai phần: một identifier property (thuộc tính dùng để nhận diện loại tài nguyên đó — ví dụ AWS::S3::Bucket nhận diện bằng BucketName) và một identifier value (giá trị thật của thuộc tính đó, ví dụ MyS3Bucket).

Sau khi import xong, tài nguyên nằm trong stack và được cập nhật, theo dõi, quản lý như mọi tài nguyên khác do CloudFormation tạo ra.

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

A — Drift detection là cơ chế thêm tài nguyên vào stack đã tạo. Đây là phương án gần đúng nhất về mặt "cảm giác", vì drift detection đúng là làm việc với tài nguyên đã tồn tại và với stack đã tạo. Nhưng nó hỏng ở chỗ định nghĩa sai chức năng: drift detection chỉ phát hiện sai lệch — nó so trạng thái thực tế của các tài nguyên trong stack với cấu hình mong đợi trong template, rồi báo cáo tình trạng drift của từng tài nguyên (với những loại tài nguyên có hỗ trợ drift detection). Nó là công cụ đọc và báo cáo, không thêm được tài nguyên nào vào stack.

B — Dùng section Mappings để đưa tài nguyên cần thiết vào. Mappings là các biến cố định trong template, dạng bảng tra cứu key–value. Nó rất tiện để phân biệt giữa các môi trường (dev vs prod), giữa các region, hay chọn AMI theo region. Nhưng Mappings chỉ chứa giá trị, không hề khai báo hay tiếp nhận tài nguyên — nó không có vai trò gì trong việc đưa tài nguyên có sẵn vào quản lý.

D — Dùng section Parameters để đưa tài nguyên cần thiết vào. Parameters là cách truyền đầu vào cho template, giúp tái sử dụng template khi có những giá trị không thể xác định trước lúc viết. Đúng là khi import bạn có cung cấp "giá trị định danh" của tài nguyên, nên phương án này nghe hợp lý — nhưng bản thân section Parameters chỉ nhận vào chuỗi/giá trị cấu hình, nó không phải là cơ chế đưa tài nguyên đang tồn tại vào stack. Cơ chế đó là resource import.

📌 Điểm cần nhớ

• Tài nguyên đã tồn tại ngoài CloudFormation → dùng resource import; điểm mạnh là không phải xoá đi tạo lại.
• Import cần ba thứ: template mô tả toàn bộ stack sau khi import, thuộc tính DeletionPolicy trên mỗi tài nguyên được import, và cặp identifier property + identifier value để chỉ đích danh tài nguyên.
• Drift detection chỉ trả lời câu hỏi "tài nguyên trong stack có còn khớp template không" — chuyên để phát hiện thay đổi ngoài luồng, không dùng để thêm tài nguyên.
• Phân biệt hai section hay bị lẫn: Parameters = đầu vào động lúc chạy stack, Mappings = bảng tra cứu giá trị cố định. Cả hai đều là giá trị, không phải tài nguyên — thấy phương án nào nói "dùng Parameters/Mappings để đưa tài nguyên vào" thì gần như chắc chắn là sai.

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

Đề mô tả một công ty chạy ứng dụng chính trên Amazon EC2, nay muốn mở rộng hạ tầng và đội phát triển cần chia sẻ AMI qua nhiều AZ, nhiều AWS account và nhiều Region. Câu hỏi yêu cầu chọn hai điểm cần lưu ý trước khi lên kế hoạch.

Cụm từ quyết định nằm ở chỗ đề gộp chung ba phạm vi: "across AZs, AWS accounts and Regions". Đây chính là cái bẫy — nó khiến người đọc mặc định rằng AMI có thể chia sẻ thẳng qua Region giống như chia sẻ qua account. Thực tế AMI là tài nguyên cấp Region, nên "qua AZ" và "qua account" là chuyện làm được trực tiếp, còn "qua Region" thì không phải một thao tác chia sẻ.

Cụm từ quyết định thứ hai là loại CMK dùng để mã hoá volume trong các phương án: "AWS-managed CMK" so với "customer-managed CMK". Hai phương án A và B chỉ khác nhau đúng một chữ, và đó chính là điểm phân biệt.

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

Theo tệp, đáp án đúng là B và D.

B — "You can only share AMIs that have unencrypted volumes and volumes that are encrypted with a customer-managed CMK". Bạn chỉ chia sẻ được AMI khi volume của nó hoặc không mã hoá, hoặc được mã hoá bằng customer-managed CMK. Lý do là quyền dùng khoá: với customer-managed CMK bạn kiểm soát được key policy nên cấp được quyền cho account nhận. Ngoài ra, nếu AMI có volume mã hoá thì bạn còn phải chia sẻ luôn CMK đã dùng để mã hoá chúng — thiếu bước này, bên nhận thấy AMI nhưng không giải mã được để launch.

D — "You do not need to share the Amazon EBS snapshots that an AMI references in order to share the AMI". Bạn chỉ cần chia sẻ chính AMI. Hệ thống tự cấp quyền truy cập tới các EBS snapshot mà AMI tham chiếu để phục vụ việc launch instance, nên không phải đi chia sẻ từng snapshot một cách thủ công.

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

A — "…volumes that are encrypted with an AWS-managed CMK". Đây là phương án gần đúng nhất, chỉ lệch đúng một từ so với B. Nó hỏng ở chỗ: bạn không chia sẻ được AMI có volume mã hoá bằng AWS-managed CMK. Khoá loại này không cho bạn sửa key policy để cấp quyền cho account khác, nên không có cách nào để bên nhận giải mã. Chỉ customer-managed CMK mới dùng được trong tình huống chia sẻ.

C — "AMIs are regional resources and can be shared across Regions". Vế đầu đúng, vế sau sai — đúng kiểu câu nửa đúng nửa sai nên rất dễ chọn nhầm. AMI đúng là tài nguyên cấp Region, và chính vì vậy chia sẻ một AMI chỉ làm nó khả dụng trong Region đó. Muốn dùng ở Region khác thì phải copy AMI sang Region đích trước, rồi mới chia sẻ. Không tồn tại thao tác chia sẻ trực tiếp xuyên Region.

E — "You need to share any CMKs used to encrypt snapshots and any Amazon EBS snapshots that the AMI references". Phương án này cũng gần đúng và là cái dễ tranh cãi nhất, vì vế CMK thì đúng (có mã hoá thì phải chia sẻ CMK). Nó hỏng ở vế thứ hai: yêu cầu chia sẻ cả các EBS snapshot mà AMI tham chiếu. Việc đó là không cần thiết — mâu thuẫn trực tiếp với D, và trong một câu chỉ một trong hai tồn tại được. Bài học ở đây: một phương án ghép hai mệnh đề bằng "and" chỉ đúng khi cả hai mệnh đề đều đúng.

📌 Điểm cần nhớ

• AMI là tài nguyên cấp Region. Chia sẻ chỉ có tác dụng trong Region hiện tại; sang Region khác thì quy trình luôn là copy trước, share sau. Gặp phương án nào nói "share AMI across Regions" trực tiếp thì loại.
• Chia sẻ AMI mã hoá đòi customer-managed CMK. Volume mã hoá bằng AWS-managed CMK thì không chia sẻ được, vì bạn không sửa được key policy của khoá đó.
• Chia sẻ AMI ≠ chia sẻ snapshot. Chỉ cần chia sẻ AMI, quyền truy cập snapshot mà nó tham chiếu được cấp tự động. Nhưng nếu có mã hoá thì CMK vẫn phải chia sẻ — hai chuyện này tách bạch, đừng gộp.
• Cảnh giác với phương án "nửa đúng" kiểu C (định nghĩa đúng, kết luận sai) và kiểu E (một mệnh đề đúng, một mệnh đề sai nối bằng "and"). Đọc hết cả câu trước khi chọn.

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

Một team lỡ tay xoá AMI của các EC2 instance thuộc môi trường test. Họ đã có backup bằng EBS snapshot. Câu hỏi: làm cách nào để recover/rebuild cái AMI đã xoá? (Chọn hai)

Cụm từ quyết định nằm ngay ở động từ: đề viết "recover/rebuild", tức là mở cửa cho phương án dựng lại chứ không chỉ phục hồi. Và khác biệt duy nhất giữa bốn phương án A–B và D–E chính là động từ đầu câu: "Recover the AMI from…" so với "Create a new AMI from…". Nội dung nguồn (EC2 instance cũ / EBS snapshot) thì trùng nhau từng chữ.

Nguyên lý cần nắm: một AMI đã bị delete hoặc deregister thì không khôi phục lại được — không có nút undelete, không có thùng rác cho AMI. Cái duy nhất làm được là tạo một AMI mới, giống hệt, từ những thứ còn sót lại. Nên câu này thực chất kiểm tra bạn có phân biệt được "recover" và "create new" hay không, chứ không kiểm tra bạn biết nguồn dữ liệu nào dùng được.

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

D. Create a new AMI from Amazon EC2 instances that were launched before the deletion of AMI

Những EC2 instance đã được launch từ AMI đó vẫn đang chạy và vẫn mang nguyên nội dung root volume của AMI. Từ một instance đang sống, bạn tạo image mới và ra được một AMI giống hệt bản đã mất. Lưu ý vận hành: trừ khi chọn tuỳ chọn No reboot, thao tác tạo image sẽ khởi động lại instance — đây là lý do đường này thường là phương án dự phòng, dùng khi snapshot cũng đã mất.

E. Create a new AMI from Amazon EBS snapshots that were created as backups

Với AMI kiểu EBS-backed, khi bạn xoá hoặc deregister AMI thì các snapshot của volume vẫn được giữ lại — xoá AMI không tự động xoá snapshot. Team trong đề lại đúng là có cấu hình backup bằng EBS snapshot. Từ snapshot đó, bạn đăng ký một AMI mới (snapshot làm root device) và có lại image tương đương. Đây là đường sạch hơn D vì không phải đụng vào instance đang chạy.

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

A. Recover the AMI from the current Amazon EC2 instances that were launched before the deletion of AMI — Đây là bẫy chính, và nó gần đúng đến mức chỉ sai đúng một từ. Nguồn dữ liệu (instance đã launch trước khi xoá) hoàn toàn hợp lệ, nhưng động từ "recover" thì không: bạn không lấy lại được cái AMI cũ với đúng AMI ID cũ. Kết quả thu về là một AMI mới, ID mới. Nếu có launch template, Auto Scaling group hay script nào đang trỏ cứng vào AMI ID cũ, chúng vẫn hỏng và phải cập nhật tay — đó là khác biệt thật chứ không phải chơi chữ.

B. Recover the AMI from Amazon EBS snapshots that were created as backups before the deletion of AMI — Sai y hệt A và cùng một lý do. Snapshot vẫn còn, vẫn dùng được, nhưng dùng để tạo mới chứ không phải "recover". Snapshot là ảnh chụp của volume, bản thân nó không phải AMI và không mang theo metadata đăng ký của AMI cũ; phải qua bước đăng ký image mới thì mới thành AMI.

C. AWS Support retains backups of AMIs. Write to the support team to get help for recovering the lost AMI — Sai ở tiền đề. Vì lý do bảo mật và quyền riêng tư, AWS Support không có quyền nhìn hay truy cập dữ liệu của khách hàng. Họ không giữ bản sao AMI của bạn ở đâu cả. Không có backup thì Support cũng không dựng lại được. Đây là mô-típ lặp lại trong nhiều câu thi: mọi phương án dạng "gọi AWS Support để lấy lại dữ liệu đã xoá" đều sai.

📌 Điểm cần nhớ

• AMI đã delete/deregister là mất hẳn — không có thao tác recover. Chỉ có thể tạo một AMI mới giống hệt từ EBS snapshot còn lại hoặc từ EC2 instance đã launch bằng AMI đó.
• Xoá AMI không xoá các EBS snapshot đi kèm; snapshot được giữ lại và chính là đường phục hồi ưu tiên.
• Tạo AMI từ instance đang chạy sẽ reboot instance, trừ khi bật No reboot. Cân nhắc điều này trước khi làm trên môi trường production.
• Trong đề trắc nghiệm, khi hai phương án chỉ khác nhau ở động từ ("recover" và "create new") thì chính động từ là chỗ chấm điểm — đọc kỹ trước khi so nội dung phía sau.
• AWS Support không giữ bản sao dữ liệu khách hàng. Phương án "nhờ Support khôi phục" gần như luôn là phương án sai.

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

Đề mô tả một kiến trúc Elastic Beanstalk khá chuẩn: Application Load Balancer nằm ở public subnet, Auto Scaling Group trải trên 3 private subnet, RDS Multi-AZ ở private subnet. Đề khẳng định rõ hai đường mạng đã chạy được: load balancer tới được ứng dụng, và ứng dụng tới được database. Nghĩa là security group và routing nội bộ VPC không có vấn đề gì.

Cụm từ quyết định nằm ở câu cuối: "these instances cannot access the internet" khi vá lỗi bằng SSM. SSM Agent hoạt động theo kiểu outbound: instance chủ động mở kết nối ra tới endpoint của Systems Manager rồi giữ đó nhận lệnh. Vậy thứ đang thiếu là đường đi ra Internet cho instance ở private subnet, chứ không phải đường đi vào. Thêm một chi tiết quan trọng nữa: đề nói instance nằm ở private subnet và không hề nói muốn đổi mô hình bảo mật — nên lời giải phải giữ nguyên tính "private" đó.

Hai ràng buộc gộp lại — cần ra Internet + phải vẫn là private — chính là định nghĩa của NAT Gateway.

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

C — Deploy a NAT Gateway in the public subnet and add entries to your route table.

NAT Gateway đúng là thành phần AWS sinh ra để cho instance trong private subnet gọi ra Internet hoặc gọi tới các dịch vụ AWS, trong khi vẫn chặn mọi kết nối do phía Internet khởi tạo vào instance. Đó chính xác là thứ SSM cần: agent trên EC2 mở kết nối ra ngoài, còn không ai từ Internet chạm được vào instance.

Hai vế của phương án đều cần thiết:

• NAT Gateway đặt ở public subnet — bản thân nó phải nằm ở subnet có đường ra Internet Gateway thì mới chuyển tiếp lưu lượng đi được.
• Thêm entry vào route table — route table của các private subnet phải có tuyến mặc định (0.0.0.0/0) trỏ vào NAT Gateway. Dựng NAT Gateway mà quên bước này thì lưu lượng vẫn không biết đi đâu và triệu chứng không đổi.

Vài đặc điểm của NAT Gateway đáng nhớ theo bản giải thích gốc: gắn được đúng một Elastic IP, hỗ trợ TCP/UDP/ICMP, không gắn security group vào nó được (muốn lọc thì dùng network ACL của subnet chứa nó), băng thông tự co giãn, và có tính phí theo giờ chạy cộng phí xử lý dữ liệu.

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

A — Deploy the instances in the public subnet instead. Private subnets cannot access the internet. Phương án này sai ở cả mệnh đề lẫn hệ quả. Private subnet hoàn toàn ra Internet được nếu có NAT Gateway và tuyến tương ứng — câu "private subnets cannot access the internet" là một khẳng định sai. Còn về hệ quả: chuyển instance ứng dụng ra public subnet là hạ cấp bảo mật, phơi tầng ứng dụng ra ngoài trong khi kiến trúc ba lớp cố tình giấu nó sau load balancer. Đây là kiểu "chữa được triệu chứng bằng cách phá mất mục tiêu ban đầu".

B — Open up security groups on the EC2 instances. Đây là phương án gần đúng nhất về mặt trực giác, nhưng hỏng ở chỗ security group không tạo ra đường đi. Security group chỉ là tường lửa ảo cho phép hoặc chặn traffic trên đường đã tồn tại; nó không thay thế được routing. Hơn nữa security group là stateful: kết nối outbound do instance khởi tạo vốn đã được phép trả lời về, nên vấn đề ở đây không nằm ở inbound rule. Bằng chứng ngay trong đề: load balancer gọi được ứng dụng và ứng dụng gọi được database — chứng tỏ security group đang cấu hình đúng. Mở toang security group vừa không sửa được lỗi, vừa làm yếu bảo mật.

D — Deploy an Internet Gateway in the public subnet and add entries to your route table. Đây là distractor đắt giá nhất vì nghe rất giống C. Internet Gateway đúng là thành phần cho phép VPC nói chuyện với Internet, có tính sẵn sàng cao và không giới hạn băng thông. Nhưng nó là điều kiện để một subnet trở thành public — và trong đề, VPC này đã có Internet Gateway rồi: ALB ở public subnet đang phục vụ được người dùng, điều đó không xảy ra nếu thiếu IGW. Quan trọng hơn, trỏ route table của private subnet thẳng vào Internet Gateway thì subnet đó hết là private, quay về đúng vấn đề của phương án A. Instance ở private subnet không có public IP nên cũng không dùng trực tiếp IGW được. Phương án này chỉ mô tả điều kiện cần cho một public subnet, không giải quyết bài toán được hỏi.

📌 Điểm cần nhớ

• Private subnet cần ra Internet → NAT Gateway; subnet cần là public → Internet Gateway. Hai thành phần này không thay thế nhau, và câu hỏi thi rất hay đặt cạnh nhau làm distractor.
• Dựng NAT Gateway chưa đủ, phải sửa route table của private subnet trỏ 0.0.0.0/0 vào nó. Đề bài nào nhắc "add entries to your route table" thường là đề bài đúng.
• Security group không tạo đường đi, chỉ lọc trên đường đã có — và nó stateful, nên lỗi outbound hiếm khi nằm ở inbound rule. Khi đề đã nói các luồng khác chạy tốt, security group gần như chắc chắn không phải thủ phạm.
• SSM cần kết nối outbound từ instance, nên triệu chứng "không patch được bằng SSM" ở private subnet gần như luôn quy về thiếu đường ra Internet.
• Cảnh giác với phương án nào sửa lỗi bằng cách vứt bỏ mục tiêu bảo mật của kiến trúc (đưa instance ra public, mở toang firewall) — trong đề thi AWS đó gần như luôn là đáp án sai.

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

Đề mô tả một công ty đang tốn nhiều tiền cho Elastic IP (EIP) vì phần lớn EIP không được gán cho instance nào. Nhưng cụm từ quyết định đáp án không nằm ở chỗ tốn tiền — nó nằm ở câu: "Management would like to see a report showing the allocation of costs for these EIPs by department".

Đọc kỹ thì đề không hỏi cách giảm chi phí, cũng không hỏi cách phát hiện EIP bị bỏ không, mà hỏi cách báo cáo chi phí, bóc tách theo phòng ban. Đây là bài toán thuần về cost reporting / cost attribution, không phải về compliance hay automation. Hai chữ "by department" là ràng buộc phân biệt: muốn chia chi phí theo một chiều nghiệp vụ (phòng ban, dự án, chủ sở hữu) thì cơ chế duy nhất trong AWS là gắn nhãn cho resource rồi kích hoạt nhãn đó ở tầng billing.

Bối cảnh kỹ thuật cần nắm: EIP là địa chỉ IPv4 public tĩnh cấp cho tài khoản, giữ nguyên cho tới khi bạn giải phóng nó. AWS tính một khoản phí theo giờ khi EIP không gắn với instance đang chạy (hoặc gắn với instance đã stop, hoặc gắn với network interface không attach) — chính là tình cảnh mà đề mô tả.

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

A — Define Cost Allocation Tags and generate a report using Cost Explorer.

Tag là cặp key–value gắn lên resource AWS; mỗi resource thì mỗi tag key là duy nhất và mang đúng một giá trị. Tag vốn dùng để tổ chức resource, nhưng khi bạn kích hoạt chúng làm cost allocation tags trong Billing and Cost Management console thì AWS bắt đầu dùng chính các tag đó để nhóm chi phí trong cost allocation report.

Áp vào đề: gắn tag kiểu Department=Marketing, Department=Engineering… lên các resource liên quan tới EIP, kích hoạt tag Department làm cost allocation tag, rồi dùng Cost Explorer để lọc và nhóm chi phí theo tag đó. Kết quả đúng là thứ management yêu cầu: một báo cáo chi phí EIP tách theo phòng ban. AWS cũng sinh được cost allocation report dạng CSV với usage và cost đã nhóm sẵn theo các tag đang active.

Điểm mấu chốt: đây là con đường duy nhất trong bốn phương án chạm được tới dữ liệu billing.

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

B — Use AWS Artifact to forbid people from leaving Elastic IPs unassigned for more than 20 minutes. Sai ở cả dịch vụ lẫn mục tiêu. AWS Artifact là cổng self-service để tải tài liệu tuân thủ (compliance) và các thoả thuận hợp đồng của AWS — báo cáo audit, agreement. Nó không điều khiển resource, không đặt ra luật cấm, và tuyệt nhiên không theo dõi usage hay cost của EIP. Ngoài ra "cấm để EIP rảnh quá 20 phút" là hành động ngăn chặn, trong khi đề hỏi báo cáo.

C — Lambda kiểm tra EIP hằng giờ và dùng CloudTrail truy ra người truy cập cuối cùng. Đây là phương án gần đúng nhất và cũng là distractor nguy hiểm nhất, vì nó nghe rất "kỹ thuật" và có vẻ giải quyết được vấn đề. Chỗ nó hỏng: Lambda + CloudTrail cho bạn biết ai đã thao tác và EIP nào đang rảnh, tức là dữ liệu về hành vi API và trạng thái resource. Nó không hề cho ra con số chi phí. Muốn có báo cáo cost theo phòng ban, bạn vẫn phải tự dựng logic quy đổi giờ rảnh ra tiền — công việc mà cost allocation tag + Cost Explorer đã làm sẵn. Chưa kể "người truy cập cuối cùng" không đồng nghĩa với "phòng ban chịu chi phí".

D — Define an AWS Config Rule per department and track cost. AWS Config dùng để đánh giá, audit và kiểm tra cấu hình của resource: xem lịch sử thay đổi cấu hình, quan hệ giữa các resource, và mức độ tuân thủ so với quy định nội bộ. Nó trả lời được câu hỏi "resource này trông như thế nào tại thời điểm xyz", nhưng không theo dõi chi phí. Config Rule có thể phát hiện "EIP này chưa gán vào đâu" — một tín hiệu hữu ích, nhưng vẫn dừng ở tầng cấu hình chứ không ra được báo cáo tiền theo phòng ban.

📌 Điểm cần nhớ

• Hễ đề hỏi chia/bóc tách chi phí theo phòng ban, dự án, chủ sở hữu, cost center → phản xạ là cost allocation tags, xem báo cáo bằng Cost Explorer hoặc cost allocation report. Không có cơ chế nào khác trong AWS làm việc này.
• Tag chỉ trở thành cost allocation tag sau khi được kích hoạt trong Billing and Cost Management console. Gắn tag thôi chưa đủ để chi phí hiện ra theo chiều đó — đây là bẫy hay gặp.
• Phân biệt rạch ròi ba nhóm dịch vụ: AWS Config = cấu hình và compliance; CloudTrail = ai gọi API nào; Cost Explorer / Billing = tiền. Câu hỏi nói về tiền thì hai cái đầu gần như luôn là distractor.
• AWS Artifact chỉ là kho tài liệu compliance và agreement, không có khả năng thực thi chính sách hay theo dõi resource. Thấy Artifact trong phương án mang nghĩa "ngăn chặn / bắt buộc / giám sát" thì gần như chắc chắn là sai.
• Đọc kỹ động từ của đề: report (báo cáo) khác prevent (ngăn chặn) khác detect (phát hiện). Nhiều phương án sai không sai vì dịch vụ vô lý, mà vì trả lời nhầm câu hỏi.

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

Đề mô tả một database RDS for PostgreSQL chạy production, và một custom rule trong AWS Config phát hiện có những connection tới database không được mã hoá. Câu hỏi: làm sao để bảo đảm mọi connection tới RDS đều được mã hoá.

Cụm từ quyết định là "ensure ALL connections are encrypted" — tức là bắt buộc (enforce) chứ không phải cho phép (allow). RDS for PostgreSQL vốn đã hỗ trợ SSL/TLS sẵn, client nào muốn dùng thì dùng; vấn đề ở đây là vẫn còn client kết nối bằng kênh không mã hoá và ta cần chặn hẳn phía server. Cụm thứ hai cũng quan trọng: RDS là dịch vụ managed — điều này loại thẳng mọi phương án đòi can thiệp vào bên trong máy chủ database.

Vậy câu hỏi thực chất là: nút bấm nào trong RDS dùng để ép buộc SSL?

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

B — Review the DB parameter groups.

Với RDS for PostgreSQL, hành vi bắt buộc SSL được điều khiển bằng tham số rds.force_ssl, và tham số này nằm trong DB parameter group gắn với instance. Mặc định nó ở giá trị 0, nghĩa là server chấp nhận cả kết nối mã hoá lẫn không mã hoá — đúng với hiện tượng mà AWS Config đang báo. Đặt rds.force_ssl sang 1 thì PostgreSQL từ chối mọi kết nối không dùng SSL/TLS, nên client cũ buộc phải chuyển sang kết nối mã hoá.

Đây là cách đúng vì DB parameter group chính là nơi RDS phơi ra các tham số cấu hình của engine cho người dùng — ta không SSH vào máy để sửa postgresql.conf được, nên AWS đưa tham số đó lên tầng parameter group. Sửa qua RDS Console hoặc CLI đều được. Lưu ý: rds.force_ssl là static parameter, nên sau khi đổi cần reboot instance thì giá trị mới có hiệu lực.

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

A — Edit the security group rules. Đây là phương án gần đúng nhất và là bẫy chính. Security group là firewall ở tầng network: nó lọc theo source IP/security group và port, tức là quyết định ai được kết nối tới cổng 5432. Nó hoàn toàn không nhìn vào nội dung của kết nối, nên không có cách nào phân biệt một session Postgres có bật TLS với một session không bật — cả hai đều đi qua cùng một port. Siết security group giúp thu hẹp bề mặt tấn công nhưng không trả lời được yêu cầu "mọi connection phải được mã hoá".

C — Enable SSL connections from the RDS Console. Nghe rất hợp lý nhưng đây là phương án bịa: RDS Console không có một công tắc tên "Enable SSL connections" ở cấp instance. Việc bật/ép SSL đi qua parameter group chứ không phải một checkbox riêng. Ngoài ra, chữ "enable" cũng sai hướng: SSL vốn đã sẵn sàng, thứ ta cần là ép buộc, không phải bật lên.

D — Patch the database with the SSL/TLS Postgres Addon. Sai ở hai tầng. Thứ nhất, RDS là dịch vụ managed — bạn không có quyền truy cập vào hệ điều hành hay cài đặt patch tuỳ ý lên máy chủ database; việc vá lỗi do AWS thực hiện theo maintenance window. Thứ hai, không tồn tại thứ gọi là "SSL/TLS Postgres Addon" cần cài thêm: hỗ trợ TLS đã nằm sẵn trong PostgreSQL và trong RDS.

📌 Điểm cần nhớ

• Trong RDS, mọi tham số cấu hình của engine mà người dùng chỉnh được đều nằm ở DB parameter group — thấy đề hỏi "đổi hành vi của database engine" thì nghĩ tới parameter group trước tiên. Với PostgreSQL, tham số ép mã hoá là rds.force_ssl.
• Phân biệt rõ encryption in transit (SSL/TLS, do parameter group + client cấu hình) với network access control (security group). Security group chỉ biết IP và port, không biết kết nối có mã hoá hay không.
• Phân biệt "cho phép" với "bắt buộc": RDS mặc định cho phép SSL nhưng không bắt buộc. Đề nào có chữ "ensure all" / "enforce" / "reject unencrypted" là đang hỏi về cơ chế enforce phía server.
• RDS là managed service: bất kỳ phương án nào nói tới cài đặt package, patch thủ công, hay sửa file cấu hình trên host đều loại được ngay mà không cần đọc kỹ.

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

Đề mô tả một mobile game vừa phát hành, người chơi tự tải ảnh đại diện thẳng lên một S3 bucket được chỉ định. Câu hỏi: làm sao cấp write access cho người dùng của mobile app một cách hiệu quả (effectively).

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

• "mobile application users" — đây là người dùng cuối trên Internet, không phải nhân viên của công ty, không thuộc một tổ chức có sẵn hệ thống danh tính doanh nghiệp.
• "a new mobile game" với "users have the chance to interact with each other" — số lượng người dùng có thể rất lớn và tăng liên tục, mỗi lần cài app là một danh tính mới.
• "upload their images directly into a designated S3 bucket" — app gọi thẳng S3, nên client phải cầm được credentials AWS tạm thời; không có tầng backend nào đứng ra ký thay.

Ba ràng buộc đó cùng chỉ về một hướng: cần cơ chế federation cho người dùng cuối quy mô lớn, đổi danh tính lấy một IAM role tạm thời, chứ không phải cấp IAM user cố định.

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

D — Federate the users with Cognito so they can assume a role to access S3.

Amazon Cognito sinh ra đúng cho bài toán này: thêm sign-up, sign-in và access control cho web/mobile app, mở rộng tới hàng triệu người dùng, hỗ trợ đăng nhập bằng social identity provider (Facebook, Google, Amazon) lẫn identity provider doanh nghiệp qua SAML 2.0.

Mô hình chuẩn gồm hai nửa, và cần phân biệt rõ:

• Cognito User Pool — nơi xác thực riêng cho ứng dụng: đăng ký tài khoản, đăng nhập, quản lý hồ sơ người chơi.
• Cognito Identity Pool — nơi đổi danh tính đã xác thực lấy temporary AWS credentials bằng cách assume một IAM role, để client gọi thẳng dịch vụ AWS như S3.

Người chơi đăng nhập vào user pool, identity pool cấp credentials tạm ứng với IAM role có quyền ghi vào bucket. Không có secret key dài hạn nào nằm trong app, credentials tự hết hạn, và role policy có thể giới hạn mỗi người chỉ ghi được vào prefix của chính mình. Đây là lựa chọn công nghệ phù hợp nhất để quản lý tài khoản người dùng mobile.

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

A — Lambda tạo một IAM User cho mỗi người dùng mới, lưu API keys trong database của app. Đây là phương án "gần đúng" nhất về mặt ý tưởng (mỗi người một danh tính riêng), nhưng hỏng ở chỗ chọn sai loại danh tính. IAM user dành cho danh tính trong tài khoản AWS của bạn — nhân viên, workload — chứ không dành cho người dùng cuối của ứng dụng. Với một game có thể lên tới hàng triệu người chơi, việc tạo IAM user cho từng người là không khả thi: số lượng IAM user trong một account là hữu hạn, và bạn còn phải tự lo vòng đời khoá (xoay vòng, thu hồi khi người dùng xoá tài khoản). Chưa kể việc cất access key dài hạn vào database của app là thêm một kho bí mật phải bảo vệ.

B — Federate người dùng bằng SAML để dùng SSO truy cập S3. Đúng hướng "federation" nhưng sai loại federation. SAML dùng khi người dùng đã có sẵn danh tính trong một identity provider của tổ chức (Active Directory, hệ thống SSO doanh nghiệp) và bạn muốn ánh xạ danh tính đó sang IAM role. Trong đề không hề có chi tiết nào cho thấy người chơi thuộc về một tổ chức nào — họ là người dùng công cộng tải game về từ app store. Không có IdP doanh nghiệp thì không có gì để federate qua SAML.

C — Tạo một IAM user rồi publish access keys ngay trong mobile application. Đây là security bad practice rõ ràng. Access key nhúng trong ứng dụng phân phối cho bên thứ ba coi như bị lộ: bất kỳ ai cũng có thể giải nén app hoặc bắt lưu lượng để lấy khoá, rồi dùng chính khoá đó ghi bất cứ thứ gì vào bucket. Ngoài ra mọi người dùng chia sẻ chung một danh tính nên không thể phân tách quyền hay truy vết ai đã upload gì, và muốn thu hồi thì phải cập nhật lại toàn bộ app đã cài.

📌 Điểm cần nhớ

• Người dùng cuối của web/mobile app ⇒ Cognito. Nhân viên/tổ chức có IdP sẵn ⇒ SAML federation. Đề bài có nhắc tới "organization"/"corporate directory" hay không chính là chỗ phân biệt hai phương án này.
• Đừng bao giờ tạo IAM user cho người dùng ứng dụng. IAM user là danh tính trong AWS account của bạn, không mở rộng tới quy mô người dùng Internet.
• Access key dài hạn không được nằm trong ứng dụng client. Mọi truy cập từ mobile/browser vào dịch vụ AWS phải đi qua temporary credentials lấy từ việc assume role.
• Nhớ cặp User Pool / Identity Pool: User Pool lo authentication (ai là ai), Identity Pool lo authorization để lấy AWS credentials tạm mà gọi S3, DynamoDB… Câu hỏi có cụm "access AWS services directly" thì Identity Pool luôn xuất hiện trong đáp án đúng.

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

Đề mô tả một tình huống rất cụ thể: bạn dùng cfn-init để cài đặt và cấu hình ứng dụng trên EC2 instance, dùng cfn-signal để báo cho CloudFormation biết ứng dụng đã sẵn sàng. Vấn đề là CloudFormation báo stack hoàn tất trong khi instance vẫn đang chạy dở cfn-init.

Cụm từ quyết định nằm ở chỗ "CloudFormation completes successfully, even though the instance is still executing the cfn-init script". Đây không phải lỗi cài đặt sai, không phải lỗi quyền, không phải lỗi script hỏng — script vẫn chạy bình thường. Vấn đề duy nhất là CloudFormation không chịu chờ. Nó tạo xong resource EC2 (tức là API RunInstances trả về thành công) rồi coi như xong việc, đi tiếp và kết thúc stack.

Nói cách khác, câu hỏi này không hỏi "cái gì cài đặt sai", mà hỏi "cái gì đáng ra phải chặn CloudFormation lại mà bạn quên đặt vào". Phải tìm phương án nào là cơ chế tạm dừng và chờ tín hiệu.

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

C — You forgot the Wait Condition.

Ba mảnh ghép của cơ chế này phải có đủ thì mới hoạt động:

• cfn-init đọc metadata từ khoá AWS::CloudFormation::Init trong template rồi thực thi: tải và phân tích metadata, cài package, ghi file xuống đĩa, bật/tắt và khởi động/dừng service.
• cfn-signal gửi tín hiệu về cho CloudFormation, báo rằng instance đã được tạo hoặc cập nhật thành công — dùng đúng cho tình huống cài phần mềm xong mới coi là "sẵn sàng".
• Wait Condition là phía nhận tín hiệu đó. Nó khiến CloudFormation dừng lại giữa chừng quá trình tạo stack và chờ.

CloudFormation tạo wait condition như một resource bình thường. Khi tạo, nó đặt trạng thái resource này là CREATE_IN_PROGRESS và đứng chờ cho tới khi nhận đủ số tín hiệu thành công cần thiết, hoặc tới khi hết thời gian timeout. Nhận đủ tín hiệu trước hạn thì stack chạy tiếp; hết hạn mà chưa đủ thì wait condition chuyển sang CREATE_FAILED và stack bị rollback.

Thiếu wait condition thì cfn-signal gửi tín hiệu đi mà không có ai chờ để nghe — CloudFormation không có lý do gì để dừng lại, nên nó hoàn tất stack ngay khi instance được khởi tạo, đúng như triệu chứng đề mô tả.

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

A — You forgot to include the cfn-signal command in your user data. Đây là phương án gần đúng nhất và là distractor được thiết kế kỹ, vì nó nhắc đúng tên cfn-signal — thứ có mặt trong đề. Nhưng đề đã nói rõ ngay câu đầu là bạn đang dùng cfn-signal, nên không thể nói là "quên". Ngoài ra, phần chờ tín hiệu này được quản lý qua chính CloudFormation chứ không phải qua user data — nên quy trách nhiệm cho user data là đặt sai chỗ. Cái thiếu là phía nhận tín hiệu, không phải phía gửi.

B — You forgot to include a deletion policy. DeletionPolicy quyết định điều gì xảy ra với resource khi stack bị xoá hoặc resource bị gỡ bỏ — giữ lại, snapshot, hay xoá luôn. Nó thuộc về vòng đời lúc kết thúc, hoàn toàn không liên quan tới việc theo dõi trạng thái của cfn-init lúc tạo stack. Hai chuyện xảy ra ở hai đầu đối lập của vòng đời stack.

D — You did not disable Rollbacks. Rollback chỉ quyết định điều gì xảy ra sau khi một resource bị coi là thất bại: cuộn ngược lại hay giữ nguyên hiện trạng để gỡ lỗi. Nó không hề ảnh hưởng tới khả năng CloudFormation theo dõi trạng thái của cfn-init. Ở đây stack thậm chí còn không thất bại — nó báo thành công, nên rollback chưa bao giờ được kích hoạt để mà bàn tới. Phương án này giải quyết một triệu chứng ngược hẳn với triệu chứng trong đề.

📌 Điểm cần nhớ

• cfn-signal là phía gửi, Wait Condition là phía nhận. Có tín hiệu mà không có ai chờ thì tín hiệu vô nghĩa; gặp triệu chứng "stack xong quá sớm" thì nghĩ ngay tới phía chờ còn thiếu.
• CloudFormation mặc định coi EC2 là "tạo xong" khi instance được cấp phát, không phải khi phần mềm bên trong đã cài đặt và cấu hình xong. Muốn nó chờ tới lúc ứng dụng thật sự sẵn sàng thì phải khai báo tường minh.
• Wait condition có timeout, và hết hạn là CREATE_FAILED kèm rollback. Đây là hành vi đúng như thiết kế — nó chính là cách stack phát hiện ứng dụng cài hỏng.
• Khi phân loại phương án, hãy hỏi thuộc tính này tác động vào giai đoạn nào của vòng đời stack: DeletionPolicy tác động lúc xoá, rollback tác động sau khi thất bại, còn wait condition tác động ngay giữa lúc tạo — chỉ cái cuối khớp với triệu chứng.