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

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

Đề mô tả một fleet EC2 instance nằm sau một Auto Scaling Group (ASG), và nói rõ rằng SysOps Administrator đã bật instance scale-in protection cho các instance đó. Sau đó một scale-in event xảy ra, và câu hỏi là: kết quả của sự kiện này là gì?

Cụm từ quyết định đáp án là "protected from termination during scale-in" — tức đây là instance scale-in protection của Auto Scaling, chứ không phải EC2 termination protection (thứ chỉ chặn việc terminate thủ công qua console/API). Cụm từ thứ hai cũng quan trọng: "A scale-in event has occurred" — đề khẳng định sự kiện đã xảy ra rồi, nên mọi phương án nói rằng sự kiện không được sinh ra đều đi ngược với chính đề bài.

Điểm mấu chốt cần phân biệt: scale-in protection tác động lên hành vi terminate instance, chứ không chặn ASG thay đổi con số capacity. Hai việc này là hai bước tách rời nhau, và đó chính là chỗ các phương án khác nhau.

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

Đáp án đúng theo tệp là A — "The desired capacity of the ASG is decremented, but ASG will not be able to terminate any instance".

Khi một chính sách scaling hoặc lịch scaling kích hoạt scale-in, Auto Scaling group giảm desired capacity xuống trước. Đó là con số thể hiện "tôi muốn có bao nhiêu instance", và ASG cập nhật nó ngay lập tức, không phụ thuộc vào trạng thái của từng instance.

Bước tiếp theo mới là chọn instance để terminate cho khớp với desired capacity mới. Nhưng vì toàn bộ instance đều bật scale-in protection, ASG không tìm được ứng viên nào hợp lệ để terminate. Kết quả là desired capacity đã giảm nhưng số instance đang chạy vẫn giữ nguyên — nhóm rơi vào trạng thái số instance thực tế cao hơn desired capacity. ASG sẽ chỉ terminate được khi cờ scale-in protection trên các instance bị tắt đi.

Một điểm phụ đáng nhớ mà giải thích gốc nhấn mạnh: scale-in protection không bảo vệ instance khỏi việc terminate thủ công qua EC2 console / terminate-instances / TerminateInstances API, không bảo vệ khỏi việc bị thay thế khi trượt health check (muốn chặn thì phải suspend tiến trình ReplaceUnhealthy), và không bảo vệ khỏi Spot Instance interruption. Nó chỉ có tác dụng đúng trong luồng scale-in của Auto Scaling.

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

B — "The desired capacity of the ASG is decremented and the instances are terminated based on the configuration": đây là phương án gần đúng nhất, vì vế đầu hoàn toàn chính xác — desired capacity thật sự bị giảm. Nó hỏng ở vế sau: nếu instance vẫn bị terminate "theo cấu hình" thì scale-in protection chẳng còn ý nghĩa gì. Đúng ra cơ chế bảo vệ chặn ở khâu chọn instance để terminate, nên vế thứ hai không xảy ra.

C — "When all instances are termination protected, scale-in event is not generated": sai ở chỗ hiểu nhầm phạm vi tác dụng của cờ bảo vệ. Scale-in protection là thuộc tính của instance, nó không hề tác động ngược lên việc chính sách scaling có kích hoạt hay không. Sự kiện scale-in vẫn được sinh ra bình thường, ASG vẫn hành động — chỉ là hành động đó dừng lại ở việc giảm desired capacity. Ngoài ra phương án này còn mâu thuẫn thẳng với đề, vì đề đã nói "a scale-in event has occurred".

D — "The minimum capacity of the ASG is decremented, but ASG will not be able to terminate any instance": vế sau đúng, nhưng vế đầu sai đối tượng. Scale-in thao tác trên desired capacity, không đụng tới minimum capacity. Min và max capacity là giới hạn biên do người vận hành đặt ra, chúng chỉ đổi khi ai đó chủ động cập nhật cấu hình ASG; hoạt động scaling tự động chỉ dịch chuyển desired capacity trong khoảng đó. Đây là kiểu bẫy đánh vào việc lẫn lộn ba thông số min/desired/max.

📌 Điểm cần nhớ

• Trong ASG, hoạt động scaling luôn thay đổi desired capacity; min và max chỉ là biên và chỉ đổi khi cấu hình ASG được sửa. Thấy phương án nói scale-in làm giảm min capacity thì gần như chắc chắn là bẫy.
• Instance scale-in protection chỉ chặn bước terminate trong luồng scale-in, không chặn việc sự kiện scale-in xảy ra và không chặn việc desired capacity bị giảm. Hệ quả là ASG có thể chạy nhiều instance hơn desired capacity.
• Phân biệt rõ hai cơ chế tên gọi giống nhau: EC2 termination protection chống terminate thủ công qua console/API, còn Auto Scaling instance scale-in protection chống terminate trong scale-in. Đề thường mô tả bằng chữ ("protected from termination during scale-in") để buộc bạn nhận ra cơ chế nào đang được nói tới.
• Scale-in protection không cứu instance khỏi: terminate thủ công, bị thay thế do trượt health check (phải suspend ReplaceUnhealthy mới chặn được), và Spot Instance interruption.

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

Đề nhắc tới AWS Shared Responsibility Model rồi hỏi: với một abstracted service như Amazon S3, việc nào thuộc trách nhiệm của AWS.

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

• "abstracted service" — S3 và DynamoDB thuộc nhóm dịch vụ trừu tượng: khách hàng không nhìn thấy, không SSH vào, không vá hệ điều hành bên dưới. Khách hàng chỉ làm việc với endpoint để ghi và đọc dữ liệu. Đây là điểm khác biệt so với EC2, nơi khách hàng phải tự lo hệ điều hành khách.
• "is the responsibility of AWS" — đề hỏi vế "Security OF the Cloud" (AWS lo), không phải vế "Security IN the Cloud" (khách hàng lo). Đọc lướt qua chữ này là chọn ngay một phương án thao tác trên S3 — mà mọi thao tác trên dữ liệu đều là phần của khách hàng.

Gộp hai cụm lại: cần tìm phương án nói về tầng hạ tầng bên dưới S3, không phải về dữ liệu hay cấu hình bucket.

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

C. Maintaining the operating systems and platforms for Amazon S3.

Với abstracted service, AWS vận hành tầng hạ tầng (infrastructure layer), hệ điều hành và platform. Khách hàng không có quyền truy cập vào các tầng đó và cũng không có cách nào tác động tới chúng — không có instance nào để đăng nhập, không có bản vá nào để cài. Toàn bộ việc vận hành, vá lỗi, thay phần cứng, phân tán dữ liệu dư thừa qua nhiều Availability Zone đều nằm trong phần "Security of the Cloud" mà AWS chịu trách nhiệm.

Đây cũng là phương án duy nhất trong danh sách mô tả một việc mà khách hàng về nguyên tắc không thể làm được, nên nó bắt buộc thuộc về AWS.

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

A. Defining rules to move data across different S3 storage classes — Đây là lifecycle rule, do khách hàng định nghĩa: chọn sau bao lâu thì chuyển object sang lớp lưu trữ rẻ hơn, khi nào thì xoá. AWS chỉ chịu trách nhiệm duy trì bản thân các storage class đó — phần cứng và phần mềm phía sau. Phương án này gần đúng ở chỗ nó có nhắc tới storage class (thứ AWS xây dựng), nhưng động từ "defining rules" là hành vi cấu hình, và cấu hình luôn thuộc về khách hàng.

B. Choosing encryption options for data present in S3 buckets — Đây là phương án gây nhầm nhiều nhất, vì mã hoá nghe rất giống "việc bảo mật của AWS". Cần tách hai vế: AWS cung cấp các tuỳ chọn mã hoá và lo phần quản lý khoá của dịch vụ; còn chọn tuỳ chọn nào cho phù hợp yêu cầu nghiệp vụ là quyết định của khách hàng. Chữ "choosing" đặt phương án này hẳn về phía khách hàng.

D. Managing the data present in S3 Buckets — Rõ ràng thuộc về khách hàng. AWS không biết dữ liệu của bạn là gì, phân loại ra sao, ai được đọc. Quản lý dữ liệu, phân loại tài sản và dùng IAM để cấp quyền đúng người là phần "Security in the Cloud". AWS chỉ lo hạ tầng lưu trữ và việc lưu dữ liệu dư thừa qua nhiều AZ.

📌 Điểm cần nhớ

• Công thức gốc: AWS lo "Security OF the Cloud" (hạ tầng, OS, platform, phần cứng, mạng vật lý), khách hàng lo "Security IN the Cloud" (dữ liệu, phân loại, quyền IAM, cấu hình).
• Với abstracted service (S3, DynamoDB), ranh giới bị đẩy lên rất cao: AWS lo tới tận platform, khách hàng chỉ còn dữ liệu và quyền. Với EC2 thì ngược lại — khách hàng phải tự vá hệ điều hành khách.
• Mẹo loại nhanh: phương án nào chứa động từ cấu hình/quyết định (choosing, defining, managing data, classifying) thì gần như chắc chắn là việc của khách hàng.
• Cẩn thận với mã hoá: AWS cung cấp và duy trì cơ chế mã hoá, còn bật nó lên và chọn kiểu nào là việc của khách hàng. Ranh giới nằm ở chỗ đó, không phải ở chữ "encryption".

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

Đề mô tả một quản trị viên mới tạo read replica cho Amazon RDS for MySQL, và các replica này liên tục báo lỗi. Câu hỏi yêu cầu chọn hai gợi ý khi troubleshooting replica errors.

Cụm từ quyết định là "read replicas ... running into errors consistently" — tức là lỗi làm quá trình replication gãy, chứ không phải câu hỏi về hiệu năng, về replica lag, hay về cách tạo replica. Vì vậy phương án đúng phải là thứ thực sự làm replication dừng lại, và phải là mệnh đề đúng về mặt kỹ thuật — nhiều phương án ở đây chạm đúng chủ đề (storage engine, hàm non-deterministic, read_only) nhưng phát biểu sai chiều, nên hỏng ở chi tiết chứ không hỏng ở chủ đề.

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

C — max_allowed_packet của read replica nhỏ hơn của source DB instance thì sinh lỗi replica. max_allowed_packet là tham số tuỳ chỉnh đặt trong DB parameter group, quy định kích thước tối đa của một câu lệnh DML chạy trên database. Nếu source chấp nhận gói lớn hơn mức replica cho phép, thì bản ghi replication mang câu lệnh vượt ngưỡng sẽ không áp được lên replica: tiến trình replication ném lỗi và dừng. Đây đúng là một hạng mục cần kiểm khi replica lỗi liên tục — và cách chữa là đồng bộ tham số này giữa source và replica thông qua parameter group.

E — Ghi vào bảng trên read replica có thể làm gãy replication. Read replica áp lại thay đổi từ source; nếu có ai ghi trực tiếp lên bảng của replica, dữ liệu hai bên lệch nhau, và thay đổi kế tiếp từ source có thể xung đột với dữ liệu đã bị sửa tay — replication đứt. Đó là lý do replica mặc định ở chế độ chỉ đọc.

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

A — "Read replica chạy được trên cả transactional lẫn nontransactional storage engine, nhưng engine nontransactional dễ lỗi do cách quản lý bộ nhớ". Sai ngay ở vế đầu, và đây là phương án gần đúng nhất nên phải nói rõ: read replica chỉ hoạt động với transactional storage engine. Dùng engine nontransactional như MyISAM có thể làm gãy replication — không phải "chạy được nhưng dễ lỗi". Vế giải thích về "cách quản lý bộ nhớ" cũng là lý do bịa, nguyên nhân thật nằm ở việc engine không có giao dịch nên không đảm bảo áp lại thay đổi một cách nhất quán.

B — "Câu lệnh chứa hàm non-deterministic như SYSDATE() phải được khai báo trước trong cấu hình". Phần tiền đề đúng chủ đề: các truy vấn không xác định như SLEEP(), SYSDATE(), SYSTEM_USER() là unsafe và có thể làm gãy replication. Nhưng phần kết luận bịa ra một cơ chế không tồn tại — không có tuỳ chọn "predefine" các hàm đó trong cấu hình để tạo replica thành công. Đây là kiểu bẫy lấy một sự thật thật rồi gắn thêm một thao tác không có thật.

D — "Muốn ghi an toàn vào bảng trên read replica thì tạo index sau khi đặt read_only = 0". Phương án này mâu thuẫn trực tiếp với E, và E mới là mệnh đề đúng. Đặt read_only về 0 chỉ gỡ bỏ rào chắn, nó không làm cho việc ghi trở nên an toàn: dữ liệu trên replica vẫn lệch khỏi source và replication vẫn có thể gãy. Việc "tạo index" thêm vào chỉ là chi tiết đánh lạc hướng, không liên quan gì đến an toàn của replication.

📌 Điểm cần nhớ

• Read replica của RDS for MySQL là chỉ đọc theo thiết kế; mọi thao tác ghi trực tiếp lên replica đều là nguồn gây gãy replication, và tắt read_only không hoá giải điều đó.
• Khi replica lỗi liên tục, hãy soát các tham số trong DB parameter group giữa source và replica, điển hình là max_allowed_packet — replica nhỏ hơn source là công thức gây lỗi.
• Read replica đòi transactional storage engine; MyISAM và các engine nontransactional khác có thể làm hỏng replication.
• Các truy vấn unsafe/nondeterministic (SYSDATE(), SLEEP(), SYSTEM_USER()) là rủi ro có thật cho replication, nhưng cách xử lý là tránh dùng chúng, không phải khai báo trước ở đâu đó.

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

Đề mô tả một nhóm phát triển đã viết sẵn configurable scripts và muốn chạy chúng every day để monitor the business endpoints and APIs, đồng thời tích hợp vào Amazon CloudWatch phục vụ giám sát và phân tích tổng thể.

Cụm từ quyết định đáp án là "configurable scripts that need to be run every day to monitor the business endpoints and APIs". Ba yếu tố nằm gọn trong một câu:

• có script do người dùng viết — nghĩa là cần một cơ chế chạy code, không phải chỉ đọc số liệu có sẵn;
• chạy theo lịch (hằng ngày, lặp lại);
• đối tượng giám sát là endpoints và APIs — tức chủ động gọi vào dịch vụ từ bên ngoài để kiểm tra, chứ không chờ dữ liệu do ứng dụng tự phát ra.

Trong họ tính năng CloudWatch, chỉ có đúng một thành phần vừa nhận script vừa chạy theo lịch vừa gọi thẳng vào endpoint. Phương án nào không chạy được script thì lập tức loại.

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

B — CloudWatch Synthetics tạo canary.

CloudWatch Synthetics cho phép tạo canary: chính là những script cấu hình được, chạy theo lịch, để giám sát endpoint và API. Canary đi đúng lộ trình và thực hiện đúng các thao tác mà một khách hàng thật sẽ làm, nên bạn kiểm chứng được trải nghiệm người dùng ngay cả khi ứng dụng không có lưu lượng thật — và phát hiện sự cố trước khi khách hàng gặp phải.

Về mặt kỹ thuật, canary là script Node.js; chúng tạo ra Lambda function trong tài khoản của bạn dùng Node.js làm framework, và làm việc được trên cả HTTP lẫn HTTPS. Canary dạng UI truy cập được trình duyệt Google Chrome chạy headless thông qua Puppeteer.

Canary kiểm tra tính sẵn sàng (availability) và độ trễ (latency) của endpoint, lưu được dữ liệu thời gian tải và ảnh chụp màn hình giao diện. Chúng giám sát REST API, URL và nội dung website, đồng thời phát hiện được các thay đổi trái phép do phishing, code injection và cross-site scripting.

Quan trọng nhất với đề bài: canary chạy được một lần hoặc theo lịch định kỳ, lịch chạy có thể duy trì liên tục cả ngày với tần suất dày. Yêu cầu "chạy mỗi ngày" của nhóm phát triển vì thế được đáp ứng nguyên bản, và kết quả sinh ra CloudWatch metrics để theo dõi — đúng phần "tích hợp với CloudWatch" mà đề đòi hỏi.

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

A — CloudWatch ServiceLens. Đây là phương án gần đúng nhất và dễ gây phân vân, vì ServiceLens thật sự là công cụ quan sát rất mạnh: nó nâng khả năng observability bằng cách gom traces, metrics, logs và alarms về một chỗ, tích hợp CloudWatch với AWS X-Ray để dựng bức tranh đầu-cuối của ứng dụng, giúp khoanh vùng điểm nghẽn hiệu năng và xác định người dùng bị ảnh hưởng. Chỗ nó hỏng: ServiceLens tổng hợp và hiển thị dữ liệu đã có, nó không phải nơi bạn nạp một script tự viết vào rồi bảo nó chạy hằng ngày. Đề cần một cơ chế thực thi script theo lịch, ServiceLens không cung cấp điều đó.

C — Composite Alarm. Composite alarm chứa một biểu thức luật (rule expression) dựa trên trạng thái của các alarm khác mà bạn đã tạo; nó chỉ chuyển sang trạng thái ALARM khi mọi điều kiện trong luật được thoả. Các alarm được tham chiếu trong biểu thức có thể là metric alarm hoặc composite alarm khác. Nói cách khác, đầu vào của nó là alarm, không phải script. Nó nằm ở cuối chuỗi — cảnh báo khi số liệu đã xấu — chứ không tạo ra số liệu, nên không giải quyết được yêu cầu của đề.

D — CloudWatch Dashboard tích hợp script vào Alarms. Đây là phương án bịa ra hoàn toàn, chỉ để làm nhiễu. Dashboard là nơi trình bày biểu đồ và widget từ metric sẵn có; không tồn tại thiết lập nào trong Dashboard cho phép nhúng script người dùng viết vào các alarm do CloudWatch sinh ra và quản lý. Gặp mô tả nghe lạ tai kiểu này thì nên nghi ngờ ngay.

📌 Điểm cần nhớ

• Đề bài có ba từ khoá script + theo lịch + endpoint/API thì gần như chắc chắn nói tới CloudWatch Synthetics canary. Canary là script Node.js, chạy trên Lambda, hỗ trợ HTTP/HTTPS, và đo availability, latency, nội dung trang, ảnh chụp màn hình.
• Canary là giám sát chủ động — tự tạo lưu lượng để kiểm tra, nên phát hiện lỗi cả khi không có người dùng thật. Đây là điểm phân biệt với mọi hình thức giám sát chỉ ngồi đọc dữ liệu do ứng dụng phát ra.
• Phân biệt vai trò trong họ CloudWatch: Synthetics sinh ra số liệu, ServiceLens gom và tương quan traces/metrics/logs/alarms (kèm X-Ray), Composite Alarm tổng hợp trạng thái của các alarm khác, Dashboard hiển thị. Câu hỏi hỏi khâu nào thì chọn đúng công cụ của khâu đó.
• Phương án mô tả một dịch vụ làm việc vượt quá vai trò vốn có của nó (Dashboard chạy script, Composite Alarm nhận script) thường là distractor bịa đặt — loại trước, rồi mới cân nhắc phần còn lại.

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

Đề mô tả hai Auto Scaling Group (ASG) do cùng một systems administrator tạo ra cho hai nhóm phát triển. Instance của một ASG có CloudWatch agent chạy sẵn, ASG còn lại thì không. Câu hỏi yêu cầu chỉ ra root-cause của sự khác biệt đó.

Cụm từ quyết định nằm ở câu: "The administrator has not manually installed the agents on either group of instances" — không ai cài tay trên cả hai bên. Vậy agent trên nhóm thứ nhất phải đến từ một nguồn tự động nào đó, và nguồn duy nhất có thể sinh ra khác biệt giữa hai ASG khi không có thao tác cài đặt thủ công chính là nội dung của AMI mà mỗi ASG dùng để khởi tạo instance.

Cụm từ thứ hai đáng chú ý: "two separate development teams" và "two configurations" — hai launch configuration/launch template khác nhau, tức hai AMI có thể khác nhau. Đề không hề nói tới lỗi khởi tạo, instance không lên được, hay bất kỳ thông báo lỗi nào; cả hai ASG đều đang chạy bình thường. Đó là ràng buộc loại thẳng những phương án đổ lỗi cho sự cố kiến trúc.

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

Đáp án đúng theo tệp là B: nếu AMI đã chứa sẵn CloudWatch agent thì agent đó tự có mặt trên mọi EC2 instance mà ASG khởi tạo từ AMI đó; developer cần chọn đúng AMI đã cài sẵn agent.

ASG không "cài phần mềm". Nó chỉ nhân bản instance từ một AMI theo launch configuration/launch template. Mọi phần mềm nằm trong image sẽ xuất hiện trên instance mới, mọi phần mềm không nằm trong image thì phải được đưa vào bằng cách khác (user data, cấu hình quản lý...). Với AMI Amazon Linux tiêu chuẩn, CloudWatch agent không có sẵn — phải tự cài đặt (AWS hướng dẫn cài qua trình quản lý gói).

Ghép lại đúng với tình huống đề: nhóm thứ nhất dùng AMI đã bake sẵn CloudWatch agent nên instance nào lên cũng có agent mà không ai phải đụng tay; nhóm thứ hai dùng AMI stock nên instance không có agent. Không có thao tác thủ công nào, khác biệt duy nhất là AMI — đó chính là root-cause.

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

A — "có một flag bật CloudWatch agent lúc cấu hình ASG, developer lỡ tick nhầm ở một ASG": đây là phương án gây nhiễu thuần tuý. Trong quy trình tạo ASG không tồn tại một ô tick kiểu "cài CloudWatch agent lên instance". Cái ASG có liên quan tới CloudWatch là group metrics collection (thu thập số liệu của chính ASG như GroupInService Instances) và detailed monitoring của instance — đều là số liệu do EC2/ASG phát ra ở phía hypervisor, hoàn toàn khác với việc cài agent bên trong hệ điều hành để đọc memory, disk, log. Phương án này nghe hợp lý vì có tồn tại tuỳ chọn liên quan tới CloudWatch trong ASG, nhưng nó gán cho tuỳ chọn đó một chức năng không có.

C — "kiến trúc instance không tương thích với AMI đã chọn, hệ quả là một số dịch vụ AWS không được cài như mong đợi": sai ở chỗ mô tả hậu quả. Khi kiến trúc AMI và instance type không khớp, ASG không khởi tạo được instance nào cả và trả về lỗi nói rõ vấn đề tương thích. Nó không cho ra instance chạy được nhưng thiếu vài thành phần. Trong khi đó đề mô tả instance của cả hai nhóm đều đang hoạt động, chỉ khác nhau ở agent — kịch bản này không khớp.

D — "kiến trúc InstanceType trong launch configuration không khớp với kiến trúc image, ASG được tạo với lỗi nên bỏ qua CloudWatch agent, cần rà lại vì có thể còn dịch vụ khác bị bỏ qua": đây là biến thể tinh vi hơn của C và là phương án gần đúng nhất về mặt kỹ thuật, vì nó nêu đúng một tình huống lỗi có thật (mismatch kiến trúc giữa instance type và image). Nhưng nó hỏng ở phần suy luận hậu quả: việc khởi tạo instance là all-or-nothing — hoặc thành công, hoặc thất bại hoàn toàn. Không có cơ chế "cài dở dang", "bỏ qua một vài dịch vụ rồi vẫn chạy tiếp". Câu khuyến nghị "rà soát kỹ vì có thể còn dịch vụ khác bị bỏ qua" càng làm lộ ra giả định sai đó. Ngoài ra nó vẫn không giải thích được vì sao nhóm kia lại có agent, trong khi B giải thích được cả hai vế.

📌 Điểm cần nhớ

• ASG chỉ launch instance từ AMI theo launch template/launch configuration; nó không cài phần mềm. Phần mềm phải nằm sẵn trong AMI hoặc được đưa vào qua user data / công cụ quản lý cấu hình.
• CloudWatch agent không có sẵn trong AMI Amazon Linux tiêu chuẩn. Muốn mọi instance đều có agent thì bake nó vào AMI (golden image) hoặc cài qua user data — đó là cách duy nhất để "tự động có agent" mà không ai đụng tay.
• Phân biệt hai lớp giám sát: metric mặc định của EC2/ASG (CPU, network, group metrics) đến từ hypervisor, còn metric bên trong OS (memory, disk usage, log file) bắt buộc phải có CloudWatch agent.
• Với câu hỏi root-cause: lỗi tương thích kiến trúc AMI ↔ instance type làm việc launch thất bại hoàn toàn kèm thông báo lỗi, chứ không tạo ra instance chạy được mà thiếu thành phần. Thấy phương án nào mô tả "cài dở dang, bỏ qua vài dịch vụ" thì gần như chắc chắn là distractor.

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

Đề mô tả một ứng dụng tài chính chuyển từ data center lên AWS, chạy trên nhiều Amazon EC2 instance đặt ở nhiều khu vực địa lý khác nhau. CTO muốn biết đường truyền giữa các instance là gì khi chúng nói chuyện với nhau bằng public IP address. Chọn hai đáp án đúng.

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

• "when they interact using public IP addresses" — đây không phải câu hỏi về private IP hay VPC nội bộ. Dùng public IP thường bị hiểu mặc định là "đi ra Internet", và cả năm phương án đều xoay quanh việc gói tin có rời khỏi mạng AWS hay không.
• "in different geographical areas" — có yếu tố khác Region, nên đáp án phải phân biệt được cùng Region với khác Region, và trong trường hợp khác Region thì phân biệt tiếp có hay không có Inter-Region VPC Peering.

Nói cách khác, đề đang kiểm tra ba tình huống: cùng Region, khác Region có peering, khác Region không có peering. Hai đáp án đúng là hai tình huống mà AWS bảo đảm lưu lượng ở lại trong mạng AWS.

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

Đáp án đúng theo tệp là B và C.

B — Traffic giữa hai EC2 instance trong cùng một AWS Region ở lại trong mạng AWS, kể cả khi đi qua public IP address. Đây là điểm dễ hiểu sai nhất: dùng public IP không có nghĩa là gói tin phải ra Internet. Khi hai instance trong cùng Region trao đổi qua public IP, hạ tầng mạng của AWS trong Region đó vẫn giữ lưu lượng nội bộ, không đẩy nó ra ngoài mạng của nhà cung cấp.

C — Traffic giữa các EC2 instance ở khác Region ở lại trong mạng AWS nếu giữa hai VPC có Inter-Region VPC Peering connection. Inter-Region VPC Peering dựng một đường kết nối giữa hai VPC ở hai Region khác nhau và lưu lượng đi trên hạ tầng của AWS chứ không qua Internet công cộng. Chính sự tồn tại của peering connection là điều kiện tạo ra bảo đảm này — bỏ nó đi thì bảo đảm cũng mất.

Điểm chung của hai đáp án: mỗi cái đều nêu một điều kiện cụ thể (cùng Region, hoặc khác Region + có peering) chứ không tuyên bố điều gì chung chung.

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

A — "Traffic giữa hai EC2 instance luôn luôn ở lại trong mạng AWS... nhờ AWS Global Infrastructure." Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nó chính là đáp án B bị nới rộng ra thành "luôn luôn". Chỗ hỏng nằm ở chữ always: nó xoá mất điều kiện "cùng Region" của B và điều kiện "có peering" của C. Trường hợp khác Region mà không có Inter-Region VPC Peering thì lưu lượng không được bảo đảm ở lại trong mạng AWS — nên câu khẳng định tuyệt đối này sai.

D — "Direct Connect là cách giao tiếp mặc định khi không có Inter-Region VPC Peering; mọi traffic sẽ dùng Direct Connect và không ra Internet." Sai ở chữ default. AWS Direct Connect là dịch vụ khách hàng phải chủ động đăng ký và trả tiền, dùng để nối hạ tầng on-premises với AWS thay cho đường Internet. Nó không tự bật, và cũng không phải cơ chế mà hai EC2 instance dùng để nói chuyện với nhau giữa hai Region. Ở đây đề còn gài thêm bối cảnh "chuyển từ on-premises lên AWS" khiến Direct Connect nghe có vẻ liên quan — nhưng ứng dụng đã ở trên AWS rồi, câu hỏi là về giao tiếp giữa các instance.

E — "Khác Region và không có Inter-Region VPC Peering thì sẽ dùng edge location để giao tiếp mà không ra Internet." Đây đúng là tình huống thứ ba, nhưng kết luận bị đảo ngược: trường hợp này không có bảo đảm lưu lượng ở lại trong mạng AWS. Việc gán vai trò đó cho edge location cũng không đúng chức năng — edge location phục vụ việc phân phối nội dung tới người dùng đầu cuối, không phải đường đi mặc định cho traffic giữa hai EC2 instance ở hai Region. Nếu E đúng thì C sẽ trở nên vô nghĩa, vì đã chẳng cần peering làm gì nữa.

📌 Điểm cần nhớ

• Public IP ≠ đi ra Internet. Hai EC2 instance trong cùng một Region trao đổi qua public IP vẫn ở trong mạng AWS.
• Nhớ đủ ba tình huống: cùng Region → trong mạng AWS; khác Region + Inter-Region VPC Peering → trong mạng AWS; khác Region + không peering → không được bảo đảm.
• Cảnh giác với các từ tuyệt đối như always / default / all traffic trong phương án. Chúng thường là bản "nới rộng" của một câu đúng, và chính phần nới rộng đó làm nó sai.
• Direct Connect luôn là thứ phải chọn mua và cấu hình, không bao giờ là hành vi mặc định — bất kỳ phương án nào nói Direct Connect tự động được dùng đều đáng nghi.

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

Đề mô tả một tình huống vận hành: công cụ kiểm tra bảo mật bật cờ đỏ "Security Groups - Unrestricted Access" cho các security group do AWS Directory Service tự tạo ra. Câu hỏi là: xử lý sự cố này thế nào?

Cụm từ quyết định đáp án là "the security groups created by AWS Directory Services" — tức là các security group này không phải do con người tạo, mà do một managed service tự sinh ra khi dựng managed domain controller. Cụm thứ hai cần chú ý là chính nội dung cờ đỏ: "Unrestricted Access", nghĩa là có inbound rule mở 0.0.0.0/0.

Ghép hai cụm đó lại, câu hỏi không hỏi "sửa security group thế nào" mà hỏi "cờ đỏ này có phải vấn đề thật không". Đây là dạng câu kiểm tra xem thí sinh có phân biệt được cảnh báo theo hình thức (rule ghi 0.0.0.0/0) với rủi ro thực tế (ai thực sự tới được cổng đó) hay không.

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

Đáp án đúng là D — bỏ qua hoặc suppress cờ đỏ, vì trong tình huống này làm vậy là an toàn.

AWS Directory Service là managed service: khi dựng domain controller, nó tự tạo một security group trong VPC của bạn với bộ rule cho những port mà Active Directory cần. Bộ inbound rule mặc định đó cho phép traffic từ mọi nguồn (0.0.0.0/0) tới các port này — nên công cụ quét thấy đúng cái mẫu "unrestricted access" và bật cờ.

Nhưng rule mở không đồng nghĩa với đường vào mở. Traffic tới các domain controller đó trên thực tế bị giới hạn ở traffic từ chính VPC của bạn, từ các VPC peered, hoặc từ mạng nối vào qua Direct Connect, Transit Gateway hay VPN. Lý do kỹ thuật nằm ở tầng dưới: các ENI mà security group này gắn vào không có và không thể gắn Elastic IP, nên không có đường nào từ Internet đi thẳng tới chúng. Security group là lớp lọc thứ hai, chứ không tự tạo ra khả năng tiếp cận — không có địa chỉ public thì 0.0.0.0/0 chỉ có ý nghĩa trong phạm vi mạng đã định tuyến tới.

Vì vậy cấu hình này không tạo ra lỗ hổng bảo mật, và hành động đúng của SysOps Administrator là ghi nhận đây là false positive rồi bỏ qua/suppress nó.

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

A — Dùng AWS Trusted Advisor để biết lý do chính xác rồi làm theo khuyến nghị. Đây là phương án gần đúng nhất và dễ bị chọn, vì Trusted Advisor thật sự có kiểm tra bảo mật về security group mở. Vấn đề: Trusted Advisor chính là nguồn của loại cờ đỏ này, chứ không phải nơi giải thích tại sao trường hợp cụ thể này lại an toàn. Nó đánh giá theo mẫu rule, không biết ENI phía sau không thể có Elastic IP. Làm theo khuyến nghị của nó ở đây là đi siết đúng thứ không cần siết.

B — Nghi ngờ IAM role/user dùng để khởi tạo dịch vụ thiếu quyền. Sai vì lẫn hai chuyện khác hẳn nhau. Cờ đỏ nói về nội dung inbound rule của security group, không nói gì về quyền hạn. Nếu IAM thiếu quyền thì việc dựng directory đã thất bại ngay từ đầu, chứ không cho ra một security group hoàn chỉnh có rule mở. Đây là chẩn đoán nhắm sai tầng.

C — Kiểm tra rồi sửa lại cấu hình security group cho hợp chuẩn bảo mật của AWS. Đây là bẫy chính của câu hỏi, vì nó là phản xạ tự nhiên khi thấy 0.0.0.0/0. Hỏng ở hai chỗ: thứ nhất, bộ rule đó đã đúng chuẩn — chính AWS tạo ra nó cho Directory Service; thứ hai, đây là security group của một managed service, tự tay sửa các port mà Active Directory cần sẽ làm hỏng hoạt động của domain controller (join domain, xác thực, replication) mà chẳng đổi lại được lợi ích bảo mật nào, vì rủi ro thực tế vốn đã bằng không.

📌 Điểm cần nhớ

• Rule mở 0.0.0.0/0 chưa chắc là đường vào mở. Phải xét cả khả năng tiếp cận thực tế: ENI có Elastic IP không, có nằm sau đường định tuyến từ Internet không. Không có địa chỉ public thì phạm vi thực của rule chỉ là VPC và các mạng đã nối vào (peering, Direct Connect, Transit Gateway, VPN).
• Security group do managed service tự tạo thì đừng sửa tay. AWS Directory Service tạo security group với đúng bộ port Active Directory cần; siết lại theo cảm tính sẽ làm gãy dịch vụ.
• Công cụ quét bảo mật báo theo mẫu, không báo theo ngữ cảnh. Cờ đỏ của Trusted Advisor là điểm khởi đầu để điều tra, không phải mệnh lệnh phải sửa. Kết luận đúng đôi khi là suppress một false positive đã được xác minh.
• Trong đề thi, khi phương án "bỏ qua cảnh báo" xuất hiện cùng một dịch vụ managed và cấu hình mặc định do AWS sinh ra, hãy cân nhắc nghiêm túc — đó thường là dấu hiệu câu hỏi đang kiểm tra khả năng nhận diện false positive.

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

Đề mô tả một ứng dụng thương mại điện tử chạy trên fleet EC2 có Auto Scaling Group. Hiệu năng bình thường suốt cả ngày, chỉ từ 5–6 giờ chiều gần như mỗi ngày là màn hình giật lag và đơn hàng thất bại; log máy chủ xác nhận lượng truy cập tăng vọt đúng khung giờ đó.

Cụm từ quyết định đáp án là "between 5-6 PM almost every day" cộng với "a sharp spike ... every day". Đây không phải tải tăng ngẫu nhiên mà là một khuôn mẫu lặp lại theo thời gian, đoán trước được. Cụm thứ hai là "optimal way ... while keeping the application available" — nghĩa là lời giải phải tự động, không cần người trực tay mỗi chiều, và không được làm gián đoạn dịch vụ.

Khi đề bài đã nói rõ "cùng một khung giờ, mỗi ngày", bài toán chuyển từ "phản ứng theo chỉ số" sang "lên lịch theo thời gian". Đó chính là chỗ phân biệt bốn phương án.

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

D — Create a scheduled scaling action to scale up before the traffic spike hits the servers.

Scheduled scaling cho phép bạn tự đặt lịch co giãn của riêng mình. Bạn tạo một scheduled action gắn vào Auto Scaling Group, khai báo thời điểm bắt đầu có hiệu lực cùng với các giá trị minimum, maximum và desired capacity mới. Đến đúng thời điểm đó, EC2 Auto Scaling cập nhật group theo bộ giá trị đã khai, và hành động co giãn diễn ra tự động như một hàm của ngày giờ. Scheduled action tạo được cho một lần duy nhất hoặc theo lịch lặp lại — ở đây là lặp hằng ngày.

Điểm mấu chốt: vì đặt lịch trước khi đợt tăng tải ập tới, các instance mới có thời gian khởi động và sẵn sàng nhận traffic ngay khi 5 giờ chiều đến, thay vì đợi chỉ số vượt ngưỡng rồi mới bắt đầu launch. Ứng dụng vẫn phục vụ liên tục trong suốt quá trình, và không cần ai can thiệp mỗi ngày.

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

A — Manually add a few more instances to the ASG. Về mặt kỹ thuật thì làm được: bạn có thể thay đổi kích thước của một Auto Scaling Group đang chạy bất cứ lúc nào, bằng cách cập nhật desired capacity hoặc thay đổi các instance đang gắn vào group. Đây là phương án gần đúng nhất vì nó thật sự giải quyết được triệu chứng. Chỗ hỏng là chữ "optimal" trong đề: cách này đòi hỏi con người can thiệp mỗi ngày, đúng khung giờ, không được quên — trong khi AWS đã có sẵn cơ chế thanh lịch và hiệu quả hơn cho đúng tình huống lặp lại này. Một lời giải vận hành thủ công hằng ngày không phải lời giải tối ưu.

B — Configure an Elastic Load Balancer to replace the ASG. Sai vì hiểu nhầm vai trò của hai dịch vụ. Elastic Load Balancer phân phối traffic đến giữa các instance đang có, nhưng nó không tự launch thêm instance mới. Bỏ ASG đi để thay bằng ELB là gỡ mất đúng thành phần duy nhất có khả năng scale-out. Kết quả: traffic vẫn được chia đều, nhưng chia đều lên một số lượng máy không đủ — vẫn lag, vẫn hỏng đơn hàng. Hai dịch vụ này bổ sung cho nhau chứ không thay thế nhau.

C — Modify the Auto Scaling Group launch configuration to include more instances. Sai ở hai tầng. Thứ nhất, launch configuration không sửa được sau khi đã tạo — một ASG gắn với một launch configuration tại một thời điểm, và muốn đổi thì phải tạo bản mới rồi trỏ ASG sang. Thứ hai, launch configuration là nơi mô tả instance được tạo ra trông như thế nào (AMI, instance type, security group, key pair), chứ không phải nơi khai bao nhiêu instance — số lượng nằm ở min/max/desired capacity của chính ASG. Phương án này nhắm sai cả đối tượng cấu hình lẫn thuộc tính cần đổi.

📌 Điểm cần nhớ

• Tải tăng đoán trước được theo lịch (cùng giờ, cùng thứ, cùng ngày) → scheduled scaling. Tải tăng bất thường, không biết trước → dynamic scaling theo metric. Cụm từ chỉ thời gian lặp lại trong đề chính là tín hiệu chọn scheduled action.
• Scheduled action đặt lại bộ ba min / max / desired capacity tại một mốc thời gian, chạy một lần hoặc lặp; đặt lịch trước đợt tăng tải để instance kịp khởi động và warm up.
• ELB ≠ ASG. ELB phân phối traffic, ASG tạo và huỷ instance. Bất kỳ phương án nào đề nghị dùng ELB thay cho ASG để xử lý vấn đề dung lượng đều sai.
• Launch configuration mô tả instance trông ra sao, không mô tả có bao nhiêu instance, và nó bất biến sau khi tạo. Đây là cặp bẫy hay lặp lại trong đề thi.
• Với đề hỏi cách "optimal", phương án cần người thao tác tay định kỳ gần như luôn thua phương án tự động hoá — dù về kỹ thuật nó vẫn chạy được.

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

Đề mô tả một tình huống vận hành rất cụ thể: developer gắn một EBS volume vào EC2 instance, nhưng sau 10–15 phút volume vẫn nằm ở trạng thái attaching. Câu hỏi yêu cầu SysOps Administrator đề xuất cách xử lý.

Cụm từ quyết định là "still in the attaching state". Đây không phải trạng thái error, không phải attached rồi mount hỏng, cũng không phải lỗi quyền truy cập. Trạng thái attaching kéo dài nghĩa là AWS đã chấp nhận lệnh gắn nhưng thao tác không hoàn tất được ở phía instance — nghĩa là vấn đề nằm ở cách instance ánh xạ device name, chứ không phải ở phần cứng hay ở khoá mã hoá. Một chi tiết phụ trợ nữa: đây là secondary volume gắn vào một instance đang chạy, tức là instance đã có sẵn ít nhất một device name đang được block device driver sử dụng.

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

Đáp án đúng là A — kiểm tra device name đã chỉ định có đang bị dùng hay không, rồi force detach và gắn lại bằng một device name khác.

Khi gắn EBS volume, bạn chỉ định một device name (console tự điền sẵn một giá trị). Nhưng tên đó chỉ là tên phía Amazon EC2; block device driver bên trong hệ điều hành của instance mới là nơi thực sự mount và đặt tên thiết bị, và tên nó dùng có thể khác tên bạn khai. Nếu bạn chọn một device name mà EC2 thấy còn trống nhưng block device driver bên trong lại đang chiếm, thao tác gắn thất bại và volume kẹt ở attaching. Hai nguyên nhân phổ biến theo tài liệu AWS:

• Driver remap tên: trên instance HVM, /dev/sda1 được remap thành /dev/xvda. Cố gắn một volume phụ vào /dev/xvda sẽ kẹt ngay.
• Driver chưa nhả tên: sau một lần force detach, block device driver có thể chưa trả lại device name để dùng lại. Gắn volume mới vào đúng tên đó cũng kẹt.

Cách xử lý chuẩn: force detach volume, rồi attach lại với device name khác — instance phải ở trạng thái running thì thao tác này mới có tác dụng. Nếu vẫn không được, reboot hoặc stop/start instance để nó chuyển sang phần cứng nền khác (lưu ý stop/start làm mất dữ liệu instance store).

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

B — thiếu custom KMS key dùng để mã hoá snapshot. Đây là phương án gần đúng nhất về mặt "nghe có lý", vì KMS key thật sự có ảnh hưởng tới EBS volume mã hoá. Nhưng nó hỏng ở chỗ triệu chứng không khớp: vấn đề về KMS key biểu hiện ở lúc tạo volume từ snapshot hoặc lúc khởi động instance, và báo lỗi truy cập khoá — nó không đẩy volume vào trạng thái attaching treo. Ngoài ra, khoá mã hoá của một EBS volume được gán khi tạo volume, không phải thứ "thêm vào cấu hình volume" sau đó.

C — I/O credit balance tích luỹ lỗi làm volume không attach được. I/O credit là khái niệm có thật với các loại volume dùng cơ chế burst, nhưng nó chỉ chi phối hiệu năng của volume đã hoạt động, hoàn toàn không liên quan tới thao tác attach. Không có cơ chế nào để "lỗi tích luỹ credit" chặn việc gắn volume. Đây là phương án bịa ra để đánh lạc hướng.

D — trạng thái attaching nghĩa là phần cứng nền đã hỏng, không sửa được, phải mở service request. Phương án này gài đúng một sự thật nhưng gán sai trạng thái. Khi phần cứng nền của EBS volume hỏng, volume có status là error, chứ không phải attaching; khi đó dữ liệu là không khôi phục được, EBS coi volume là mất, và AWS không tính phí cho volume ở trạng thái error. Vế "không bị tính phí" trong phương án là đúng — nhưng nó chỉ đúng với error, nên áp vào tình huống attaching của đề là sai. Đây là kiểu bẫy trộn thông tin đúng vào ngữ cảnh sai.

📌 Điểm cần nhớ

• Đọc kỹ tên trạng thái: attaching (kẹt giữa chừng, sửa được) khác hẳn error (phần cứng nền hỏng, không khôi phục được, không bị tính phí). Nhiều câu hỏi EBS phân biệt phương án đúng/sai chỉ bằng chi tiết này.
• Device name phía EC2 và device name phía OS là hai thứ khác nhau. Block device driver trong instance có thể remap hoặc chưa nhả tên, nên EC2 thấy trống không có nghĩa là OS thấy trống.
• Quy trình xử lý volume kẹt attaching: force detach → attach lại với device name khác (instance phải đang running) → nếu vẫn kẹt thì reboot, hoặc stop/start để đổi phần cứng nền (nhớ instance store data sẽ mất).
• I/O credit chỉ ảnh hưởng hiệu năng, không ảnh hưởng vòng đời attach/detach. Thấy phương án ghép credit balance với lỗi attach thì gần như chắc chắn là distractor.

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

Một lập trình viên mới dùng cùng một CloudFormation template để tạo nhiều stack ở nhiều AWS Region khác nhau. Kết quả: có tài nguyên được tạo, có tài nguyên bị thiếu, và các tài nguyên đã tạo thì hành xử bất thường. Câu hỏi yêu cầu tìm nguyên nhân khả dĩ.

Cụm từ quyết định nằm ở hai chỗ ghép lại:

• "multiple stacks ... in different AWS Regions per the ... same template" — tái sử dụng một template cho nhiều stack.
• "some resources were created and some omitted" — stack không rollback toàn bộ, nó vẫn tồn tại và vẫn phục vụ, chỉ là nội dung không như mong đợi.

Vế thứ hai là chốt chặn loại phương án. CloudFormation vốn hoạt động theo kiểu tất-cả-hoặc-không: bất kỳ lỗi nào trong lúc tạo stack đều kích hoạt rollback và xoá sạch những gì vừa tạo. Vì vậy mọi phương án mô tả một lỗi lúc tạo stack đều mâu thuẫn với hiện trạng "tạo được một phần rồi chạy sai". Nguyên nhân phải là thứ khiến stack tạo thành công nhưng các stack lại giẫm lên nhau.

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

D — Template có custom named IAM resources.

IAM là dịch vụ global, không thuộc Region nào. Tên của một IAM resource (role, user, group, managed policy) phải duy nhất trong phạm vi cả account, không phải duy nhất trong Region. Khi template đặt tên cứng cho IAM resource (ví dụ khai RoleName, UserName, ManagedPolicyName thay vì để CloudFormation tự sinh tên), thì:

• Stack ở Region thứ hai không tạo ra một IAM role mới riêng cho nó — nó đụng vào chính cái tên đã tồn tại. Kết quả là nhiều stack ở nhiều Region cùng chia sẻ một IAM resource thay vì mỗi stack có bản riêng.
• Từ đó sinh ra đúng triệu chứng trong đề: nhìn vào thì "thiếu tài nguyên" (không có bản IAM riêng cho stack đó), và hành vi thì lẫn lộn vì các stack dùng chung quyền.
• Tệ hơn nữa, đây là hỏng không khôi phục được: xoá hoặc sửa IAM resource dùng chung ở stack này sẽ vô tình sửa luôn tài nguyên của stack kia.

Vì thế AWS khuyến cáo rõ: nếu template chứa custom named IAM resources thì đừng dùng lại nó để tạo nhiều stack.

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

A — Dependency errors khiến stack không được tạo trọn vẹn. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì "dependency error" nghe rất khớp với "some resources omitted". Nhưng nó hỏng ở chỗ hiểu sai cơ chế CloudFormation: bất kỳ lỗi nào trong quá trình tạo stack cũng làm rollback toàn bộ, kết quả là không tài nguyên nào còn lại, chứ không phải một stack lai giữa có và thiếu. Đề mô tả các tài nguyên đã tạo vẫn đang chạy và team đang gặp lỗi hành vi khi dùng chúng — điều đó chỉ xảy ra khi stack đã CREATE_COMPLETE.

B — Thiếu IAM permission để tạo tài nguyên của các dịch vụ bên dưới. Nội dung phát biểu này bản thân nó đúng về mặt kiến thức — làm việc với CloudFormation thật sự cần cả quyền dùng CloudFormation lẫn quyền dùng các dịch vụ được mô tả trong template. Đây là kiểu bẫy "câu đúng nhưng không trả lời đúng câu hỏi". Nếu thiếu quyền, lời gọi tạo tài nguyên bị từ chối → stack lỗi → rollback → stack không được tạo ra. Lại rơi vào cùng mâu thuẫn với A. Ngoài ra nó không giải thích được vì sao vấn đề chỉ lộ ra khi tạo nhiều stack từ cùng template.

C — Template được tạo bằng tuỳ chọn use-once only. CloudFormation không có tuỳ chọn nào như vậy. Template được thiết kế để tái sử dụng nhiều lần, tạo bao nhiêu stack tuỳ ý; không tồn tại cờ đánh dấu template chỉ dùng một lần. Đây là phương án bịa hoàn toàn, đưa vào làm nhiễu. Gặp một cái tên tuỳ chọn nghe lạ mà bạn chưa từng thấy trong tài liệu thì khả năng cao đó là distractor.

📌 Điểm cần nhớ

• CloudFormation tạo stack theo kiểu tất-cả-hoặc-không. Hễ đề mô tả "một phần tài nguyên tồn tại và đang chạy sai", hãy loại ngay mọi phương án đổ lỗi cho lỗi lúc tạo stack (thiếu quyền, dependency, lỗi cú pháp) — những thứ đó dẫn tới rollback, không dẫn tới stack nửa vời.
• IAM là dịch vụ global, tên IAM resource duy nhất theo account chứ không theo Region. Đặt tên cứng cho IAM resource trong template rồi nhân bản stack sang Region khác là công thức tạo ra tài nguyên dùng chung ngoài ý muốn.
• Để CloudFormation tự sinh tên cho IAM resource khi định tái sử dụng template; chỉ đặt tên tuỳ ý khi chắc chắn stack là duy nhất trong account.
• Hư hỏng do shared resource nguy hiểm hơn lỗi tạo stack, vì nó không báo lỗi lúc deploy mà chỉ lộ ra khi một stack sửa/xoá tài nguyên và kéo theo các stack khác.