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

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

Đề mô tả một SysOps administrator đã triển khai nhiều ứng dụng trên một fleet EC2 instances, rồi hỏi: "What is the right way to configure scheduled events for these EC2 instances?"

Cụm từ quyết định là "scheduled events" — đây là một thuật ngữ riêng của EC2, không phải "sự kiện lập lịch do bạn tự đặt". Trong ngữ cảnh EC2, scheduled events là những sự kiện bảo trì mà AWS lên lịch cho instance của bạn: reboot, stop/start, hoặc retirement — thường vì phần cứng máy chủ vật lý bên dưới cần bảo trì hoặc đã xuống cấp.

Bẫy của câu này nằm ở chỗ ba phương án còn lại đều là dịch vụ AWS có thật và đều liên quan tới monitoring, nên người đọc lướt rất dễ nghĩ "chắc phải chọn một cái để cấu hình". Nhưng ràng buộc thật nằm ở động từ "configure" — câu hỏi kiểm tra xem bạn có biết rằng đây là loại sự kiện do AWS khởi tạo, phía khách hàng chỉ được quan sát và phản ứng, chứ không được tạo ra.

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

C — Scheduled events are managed by AWS, you cannot configure scheduled events for your instances.

AWS lên lịch các sự kiện này cho instance của bạn — reboot, stop/start, retirement — và chúng không xảy ra thường xuyên. Khi một instance của bạn sắp bị ảnh hưởng, AWS gửi email tới địa chỉ gắn với AWS account trước thời điểm sự kiện diễn ra, kèm chi tiết ngày bắt đầu và ngày kết thúc. Tuỳ loại sự kiện, bạn có thể chủ động can thiệp vào thời điểm sự kiện xảy ra (ví dụ tự reboot hoặc stop/start sớm hơn để tránh bị làm vào lúc bất tiện).

AWS đồng thời phát ra một AWS Health event, và event này thì bạn theo dõi được bằng CloudWatch Events. Ngoài ra bạn có thể xem danh sách sự kiện AWS đã lên lịch, tuỳ chỉnh nội dung thông báo (thêm/bớt tag trong email), và thực hiện hành động khi instance được lên lịch reboot, retire hay stop.

Điểm mấu chốt: tất cả những thứ trên đều là xem, nhận thông báo, phản ứng — không có thao tác nào là tạo ra một scheduled event. Đó chính xác là điều phương án C khẳng định.

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

A — Use Amazon EventBridge to configure scheduled events on Amazon EC2 instances. Đây là phương án gần đúng nhất và là bẫy chính, vì EventBridge có khái niệm scheduled rule (chạy theo cron/rate) nên tên gọi nghe trùng khớp. EventBridge giúp tự động hoá các dịch vụ AWS và phản ứng tự động với system event: event từ các dịch vụ AWS được đưa vào EventBridge gần như tức thời, và bạn khai báo hành động tự động khi event khớp rule bạn viết. Nhưng chỗ hỏng là chiều tác động: EventBridge nằm ở phía nhận và phản ứng với event, nó không đi ngược lên tầng hạ tầng của AWS để đặt lịch bảo trì cho instance. Bạn dùng nó để bắt AWS Health event báo về scheduled event — chứ không phải để cấu hình scheduled event.

B — Use CloudWatch Agent to configure scheduled events on Amazon EC2 instances. CloudWatch Agent là phần mềm cài bên trong instance, nhiệm vụ là thu thập log và metric ở mức hệ điều hành từ host lẫn guest trên EC2 instances và cả máy chủ on-premises (memory, disk, log file...). Nó là công cụ thu thập dữ liệu, hoàn toàn không có khả năng điều khiển vòng đời instance, càng không cấu hình được scheduled event.

D — Use CloudWatch Alarm to configure scheduled events on Amazon EC2 instances. CloudWatch Alarm theo dõi một metric đơn lẻ trong khoảng thời gian bạn chỉ định và thực hiện hành động dựa trên việc giá trị metric so với ngưỡng cho trước qua một số chu kỳ. Hành động đó là gửi thông báo tới một Amazon SNS topic hoặc kích hoạt EC2 Auto Scaling policy. Alarm là cơ chế phản ứng theo ngưỡng metric, tức là bị động và dựa trên số liệu — trong khi scheduled event chẳng liên quan gì tới ngưỡng metric nào cả. Alarm không dùng để cấu hình scheduled event.

📌 Điểm cần nhớ

• "Scheduled events" trong EC2 = sự kiện bảo trì do AWS lên lịch (reboot, stop/start, retirement). Đây là thuật ngữ riêng, đừng đọc thành "tác vụ định kỳ do người dùng đặt lịch".
• Phân biệt rõ cấu hình/tạo ra với quan sát và phản ứng: khách hàng chỉ được xem sự kiện, tuỳ chỉnh thông báo (thêm/bớt tag trong email) và hành động trước hạn — không tạo được sự kiện.
• Kênh thông báo là email tới địa chỉ của AWS account kèm ngày bắt đầu/kết thúc, cộng với AWS Health event để theo dõi tự động bằng CloudWatch Events.
• Nhớ đúng vai từng dịch vụ để không bị dụ: CloudWatch Agent thu thập log và metric mức OS; CloudWatch Alarm so metric với ngưỡng rồi bắn SNS hoặc Auto Scaling policy; EventBridge nhận system event và chạy hành động theo rule. Cả ba đều thuộc chiều phản ứng, không có cái nào ra lệnh cho lịch bảo trì hạ tầng của AWS.
• Trong đề trắc nghiệm, khi một phương án nói thẳng "bạn không làm được việc này, AWS quản lý", đừng loại nó theo phản xạ — với các tác vụ thuộc phần trách nhiệm của AWS trong shared responsibility model, đó thường là đá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ể: lập trình viên tạo rule trên Amazon EventBridge, target là một AWS Lambda function, đã tạo IAM Role đủ quyền và gắn Role đó vào rule — nhưng rule vẫn thất bại, và dấu hiệu chẩn đoán là "the IAM Role associated with the rule is not being used when calling the Lambda function".

Cụm từ quyết định chính là dấu hiệu đó: Role không phải bị sai quyền, cũng không phải bị từ chối — nó đơn giản là không được dùng tới. Đây là hai loại triệu chứng hoàn toàn khác nhau. Nếu Role thiếu quyền, ta sẽ thấy lỗi AccessDenied khi EventBridge gọi Lambda. Còn "không được dùng đến" nghĩa là cơ chế cấp quyền cho loại target này vốn dĩ không đi qua IAM Role.

Cụm từ thứ hai cũng quan trọng không kém: loại target là Lambda function. Cách EventBridge lấy quyền để gọi target phụ thuộc vào chính loại target đó, nên đọc lướt qua chi tiết này là mất manh mối.

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

Đáp án D — với Lambda function làm target của EventBridge, phải cấp quyền bằng resource-based policy, IAM Role không có tác dụng.

Khi một rule khớp sự kiện, EventBridge phải tự gọi API tới tài nguyên bạn sở hữu: invoke Lambda function, publish vào SNS topic, hay đẩy event vào Kinesis stream. Để làm được việc đó nó cần quyền — nhưng nguồn quyền khác nhau tuỳ loại target:

• Với Lambda, Amazon SNS, Amazon SQS và Amazon CloudWatch Logs: EventBridge dựa vào resource-based policy gắn trên chính tài nguyên đích. Tức là trên Lambda function phải có một policy statement cho phép principal của EventBridge được lambda:InvokeFunction.
• Với Kinesis stream: EventBridge dựa vào IAM Role gắn vào rule.

Vì vậy trong tình huống này, IAM Role mà lập trình viên gắn vào rule đúng là bị bỏ qua — nó chỉ có ý nghĩa với nhóm target dùng Role. Triệu chứng trong đề khớp chính xác với mô tả này. Cách sửa: thêm resource-based policy trên Lambda function cho phép EventBridge invoke nó.

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

A. Không được dùng AWS CLI để thêm permission cho EventBridge target — Phát biểu này sai về mặt sự kiện. AWS CLI hoàn toàn dùng được để thêm quyền cho target của EventBridge rule (chẳng hạn thêm permission lên Lambda function). Phương án còn đánh lạc hướng theo kiểu "lỗi nằm ở công cụ bạn dùng", trong khi đề không hề nhắc tới công cụ nào — không có gì trong tình huống gợi ý rằng CLI là nguyên nhân.

B. IAM Role cấu hình sai, hãy xoá và tạo lại Role rồi gắn lại vào rule — Đây là phương án gần đúng nhất và cũng là bẫy nặng nhất, vì nó là phản xạ tự nhiên khi thấy chữ "IAM Role" trong một câu về lỗi phân quyền. Nhưng nó hỏng ngay ở chỗ mâu thuẫn với triệu chứng trong đề: Role không được dùng đến, chứ không phải được dùng rồi bị từ chối. Tạo lại một Role hoàn hảo đến mấy thì với target là Lambda, nó vẫn không được dùng — sửa xong lỗi vẫn còn nguyên. Đây thuần tuý là distractor.

C. Với Lambda, EventBridge dựa vào Access Control List (ACL); IAM Role không dùng được — Nửa sau của câu này đúng (IAM Role không dùng được với Lambda target), nên nó dễ lọt lưới nếu chỉ đọc vế cuối. Nhưng nửa đầu sai: EventBridge không dùng ACL để cấp quyền cho target. Cơ chế đúng tên là resource-based policy. ACL cũng là khái niệm thuộc phạm vi khác, không phải cách phân quyền ở cấp người dùng cho luồng invoke này. Đúng một nửa vẫn là sai — và D nói đúng cả hai vế.

📌 Điểm cần nhớ

• Loại target quyết định cơ chế cấp quyền của EventBridge: Lambda, SNS, SQS, CloudWatch Logs → resource-based policy trên chính tài nguyên; Kinesis stream → IAM Role gắn vào rule. Đây là điểm phân biệt hay được hỏi.
• Phân biệt "quyền bị từ chối" với "quyền không được dùng đến". Triệu chứng thứ nhất dẫn tới việc sửa nội dung policy; triệu chứng thứ hai dẫn tới việc sửa loại cơ chế phân quyền. Đề thi thường cài manh mối này vào một mệnh đề duy nhất.
• Cẩn thận với phương án đúng một nửa. Một phương án phủ định đúng (IAM Role không dùng được) nhưng khẳng định sai (dùng ACL) vẫn là phương án sai — phải kiểm cả hai vế trước khi chọn.
• Khi đề bảo "tạo lại tài nguyên từ đầu" mà triệu chứng cho thấy tài nguyên đó chưa từng được sử dụng, đó gần như luôn là distractor: hành động ấy không chạm tới nguyên nhân gốc.

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

Tình huống: một trang web chạy trên Amazon EC2, đặt CloudFront ở phía trước để giảm độ trễ. Một trang quan trọng vừa lên được một giờ thì phát hiện lỗi, đã có người truy cập, và công ty muốn gỡ nó xuống càng nhanh càng tốt.

Cụm từ quyết định đáp án là "quickly remove the file from the CloudFront distribution" — kết hợp với chi tiết "few users have already accessed this page". Hai chi tiết này gộp lại nói rất rõ vấn đề nằm ở đâu: file đã được cache tại các edge location vì đã có người yêu cầu nó. Sửa hay xoá file ở origin (EC2) không đủ, vì edge vẫn tiếp tục trả bản cũ cho tới khi hết hạn cache.

Vậy đề không hỏi "làm sao sửa trang", cũng không hỏi "làm sao chặn người dùng xem trang". Đề hỏi làm sao ép CloudFront bỏ bản đã cache ở edge trước khi nó tự hết hạn. Đọc ra ràng buộc đó thì chỉ còn đúng một phương án nói về cơ chế xoá cache của CloudFront.

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

A – Invalidate the file from CloudFront distribution so that the file is removed immediately.

Khi cần gỡ một file khỏi edge cache của CloudFront trước khi nó hết hạn, CloudFront cho hai cách: invalidate file đó, hoặc dùng file versioning để phục vụ một phiên bản có tên khác. Ở đây đề đòi gỡ nhanh chính file đang lỗi, nên invalidation là đúng công cụ.

Cơ chế: submit một invalidation request, CloudFront chuyển yêu cầu đó tới tất cả edge location trong vòng vài giây và mỗi edge bắt đầu xử lý ngay. Sau đó, lần đầu tiên có viewer yêu cầu file này, edge không dùng bản cũ nữa mà quay về origin lấy bản mới nhất. Đúng với yêu cầu "as soon as possible" của đề bài.

Một hệ quả đáng nhớ: vì lệnh được phát đi ngay lập tức tới mọi edge, bạn không huỷ được một invalidation sau khi đã submit. Bạn có thể xem lại danh sách invalidation đã gửi, xem chi tiết từng cái, sao chép một cái cũ rồi sửa danh sách đường dẫn để chạy lại — nhưng không xoá được chúng khỏi danh sách.

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

B – Specify a default root object. Default root object là đối tượng CloudFront trả về khi người dùng gọi URL gốc của distribution thay vì gọi một object cụ thể (ví dụ vào https://example.com/ thì nhận index.html). Nó có ích để tránh phơi bày nội dung bên trong distribution, nhưng nó không liên quan gì tới việc gỡ một file đã nằm trong cache. Trang lỗi ở đây vẫn có URL riêng của nó, người dùng gọi thẳng URL đó vẫn nhận bản cache như thường.

C – "Cache 24 giờ nên không thể gỡ trước thời hạn". Đây là phương án gài bẫy kiểu nửa đúng: vế đầu về hành vi cache mặc định của CloudFront là mô tả đúng, nên người đọc vội dễ gật đầu luôn. Nhưng kết luận thì sai: hoàn toàn gỡ được sớm hơn, bằng invalidation hoặc bằng versioning file. Bài học rút ra là đừng chấp nhận cả phương án chỉ vì phần mô tả kỹ thuật của nó nghe quen tai — phải xét riêng phần khẳng định "không thể".

D – Use CloudFront policies to control what the users can see. Đây là phương án gần đúng nhất về mặt "nghe có vẻ liên quan tới cache", và cũng vì thế dễ chọn nhầm. Cache policy trong CloudFront dùng để điều khiển những giá trị nào được đưa vào cache key cho object lưu ở edge — query string của HTTP request, header, cookie. Nó quyết định cách phân biệt các biến thể của một object, chứ không phải công cụ xoá một object đã cache. Chỉnh policy cũng không làm biến mất bản đang nằm ở edge.

📌 Điểm cần nhớ

• Khi đề nói file đã được cache và cần gỡ ngay, phản xạ đúng là CloudFront invalidation; cách thay thế duy nhất còn lại là file versioning (đổi tên file để phục vụ phiên bản khác).
• Invalidation được phát tới mọi edge trong vài giây và không huỷ được sau khi submit — cân nhắc kỹ đường dẫn trước khi gửi.
• Default root object giải quyết chuyện "gọi URL gốc thì trả về gì", không dính dáng tới việc dọn cache.
• CloudFront cache policy định nghĩa cache key (query string, header, cookie) — tức là cách tạo và phân biệt mục cache, chứ không phải cách xoá mục cache.
• Cảnh giác với phương án mở đầu bằng một mô tả đúng rồi kết bằng "nên không thể làm được": phần mô tả đúng không cứu nổi một kết luận sai.

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

Đề mô tả một VPC duy nhất có hai subnet: public subnet chứa EC2 instance chạy ứng dụng, private subnet chứa RDS database. Câu hỏi là làm sao để EC2 nói chuyện được với RDS.

Cụm từ quyết định đáp án nằm ngay câu đầu: "has configured its AWS VPC with one public and one private subnet" — số ít, một VPC, và cả hai subnet đều nằm trong VPC đó. Đây không phải bài toán nối hai mạng khác nhau, cũng không phải bài toán ra Internet. Toàn bộ lưu lượng là trong nội bộ một VPC.

Mấu chốt kỹ thuật đi kèm: mỗi route table trong VPC luôn có sẵn một dòng đầu tiên là local route trỏ toàn bộ dải CIDR của VPC về chính VPC. Dòng này AWS tạo tự động, không xoá được, và nó chính là thứ cho phép instance ở subnet này định tuyến tới instance ở subnet khác cùng VPC. Nói cách khác, khả năng giao tiếp giữa các subnet là mặc định có sẵn, không phải thứ phải bật lên.

Cần phân biệt rõ hai khái niệm hay bị lẫn trong đề thi:

• Public vs private subnet chỉ khác nhau ở chỗ route table của nó có route ra Internet Gateway hay không. Nó nói về đường ra ngoài, không nói gì về đường đi nội bộ.
• Việc gọi là "private" không có nghĩa subnet đó bị cô lập khỏi các subnet anh em.

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

Đáp án đúng theo tệp là B — "Subnets inside a VPC can communicate with each other without the need for any further configuration".

Khi tạo VPC, AWS sinh sẵn main route table với entry local phủ dải CIDR của VPC. Mọi subnet, dù được liên kết tường minh với một route table riêng hay ngầm định với main route table, đều thừa hưởng entry local đó. Vì vậy EC2 ở public subnet đã có sẵn đường định tuyến tới địa chỉ IP riêng của RDS ở private subnet — không cần dựng thêm thành phần mạng nào.

Đây là câu kiểm tra hiểu biết nền: thí sinh hay tưởng phải "nối" hai subnet lại với nhau bằng một dịch vụ nào đó, trong khi thực tế cấu trúc VPC đã lo sẵn phần định tuyến nội bộ.

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

A — Configure a VPC peering for enabling communication between the subnets VPC peering là kết nối mạng giữa hai VPC khác nhau, cho phép định tuyến lưu lượng bằng địa chỉ IPv4/IPv6 riêng giữa chúng. Ở đây chỉ có đúng một VPC, nên peering không có đối tượng thứ hai để nối. Đây là bẫy điển hình: dùng đúng công cụ nhưng sai phạm vi — peering giải quyết ranh giới VPC, không giải quyết ranh giới subnet.

C — Create a Security Group that allows connection from different subnets inside a VPC Đây là phương án gần đúng nhất, nên cần nói rõ nó hỏng ở đâu. Trong thực tế bạn vẫn phải mở port trên security group của RDS thì kết nối database mới thành công. Nhưng theo lời giải của đề, security group hoạt động ở mức instance, không phải mức subnet — nó là virtual firewall gắn vào từng resource để kiểm soát inbound/outbound, chứ không phải cơ chế "cho phép các subnet nói chuyện với nhau". Cách diễn đạt của phương án này mô tả sai bản chất security group, biến nó thành thứ dùng để kết nối subnet. Ngoài ra câu hỏi hỏi về khả năng giao tiếp giữa các subnet, và khả năng đó đến từ local route, không đến từ security group.

D — Elastic IP can be configured to initiate communication between private and public subnets Elastic IP là địa chỉ IP public được giữ chỗ, gán cho EC2 instance trong một region cho tới khi bạn giải phóng. Nó phục vụ việc truy cập từ/ra Internet bằng địa chỉ cố định. Giao tiếp nội bộ trong VPC diễn ra qua private IP, hoàn toàn không cần địa chỉ public. Tệ hơn, gán Elastic IP cho tài nguyên trong private subnet là đi ngược ý đồ thiết kế: private subnet tồn tại chính để không phơi ra Internet.

📌 Điểm cần nhớ

• Route table của mọi VPC luôn có sẵn local route phủ dải CIDR của VPC, không xoá được — đây là lý do các subnet cùng VPC nói chuyện được với nhau ngay từ đầu.
• "Public" hay "private" chỉ nói về việc route table có đường ra Internet Gateway hay không; nó không quyết định khả năng giao tiếp nội bộ giữa các subnet.
• VPC peering dành cho lưu lượng giữa các VPC. Thấy đề chỉ có một VPC thì loại peering ngay.
• Elastic IP phục vụ truy cập qua Internet bằng địa chỉ public cố định; lưu lượng trong VPC dùng private IP nên không cần tới nó.
• Security group là firewall ở mức instance, không phải cơ chế kết nối subnet — phân biệt được điều này sẽ loại được rất nhiều phương án mồi trong Domain Networking.

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

Đề mô tả một doanh nghiệp trực tuyến lớn dùng nhiều Amazon EBS volume, và yêu cầu nghiệp vụ là phải chụp EBS snapshot đều đặn "every few minutes" để giữ dữ liệu quan trọng phòng khi hỏng hóc. Câu hỏi yêu cầu đề xuất một cách hiệu quả (an effective way) để đáp ứng.

Cụm từ quyết định đáp án là "every few minutes" kết hợp với "effective way". Đây là bài toán lịch chạy lặp lại theo chu kỳ cố định — tức là cần một thứ đóng vai trò bộ đếm giờ (scheduler) đứng ra kích hoạt hành động chụp snapshot. Bốn phương án khác nhau chủ yếu ở chỗ: cái gì phát ra tín hiệu theo thời gian? Phương án nào không có nguồn phát tín hiệu định kỳ hợp lý thì loại.

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

A — Use Amazon CloudWatch events to schedule automated EBS Snapshots.

Amazon CloudWatch Events cho phép tạo rule chạy theo lịch: hoặc theo fixed rate (chạy lại sau mỗi khoảng thời gian cố định — đúng nhu cầu "every few minutes"), hoặc theo cron expression nếu muốn chỉ định thời điểm cụ thể trong ngày. Rule đó có thể nhắm thẳng tới hành động tạo snapshot cho một EBS volume đang có, nên đây là con đường trực tiếp nhất: một rule khai báo, không phải viết và duy trì code.

Nó cũng phù hợp với bản chất của EBS snapshot: snapshot là backup dạng incremental — chỉ những block đã thay đổi kể từ snapshot gần nhất mới được lưu. Nhờ vậy chụp dày đặc vài phút một lần vẫn nhanh và không nhân bản dữ liệu, tiết kiệm chi phí lưu trữ, trong khi mỗi snapshot vẫn chứa đủ thông tin để khôi phục ra một EBS volume mới tại thời điểm chụp. Đúng tinh thần "effective" mà đề hỏi.

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

B — Dùng Amazon SNS để trigger AWS Lambda function chụp snapshot. Đây là phương án gần đúng nhất và cũng là bẫy chính. Về mặt kỹ thuật, SNS và Lambda có tích hợp sẵn: notification của SNS gọi được Lambda, và Lambda hoàn toàn viết code chụp snapshot được. Chỗ hỏng nằm ở vai trò của SNS: SNS là dịch vụ pub/sub gửi thông báo, nó không phải bộ đếm giờ — bản thân nó không tự phát message mỗi vài phút. Vậy vẫn còn thiếu thứ kích hoạt SNS theo lịch, và ta chỉ vừa chèn thêm một mắt xích vào giữa. Kết quả là một giải pháp vòng vèo, không trực tiếp, và không tiết kiệm chi phí so với phương án A.

C — Snapshot tự động là một mục cấu hình ngay trên màn hình cấu hình Amazon EC2 trong AWS console. Đây đơn giản là một phát biểu sai, được đặt vào chỉ để làm nhiễu (distractor). Màn hình cấu hình EC2 trong console không có một ô "bật snapshot tự động" như vậy; việc lập lịch snapshot phải do một cơ chế lên lịch bên ngoài đảm nhận. Gặp phương án dạng "chỉ cần tick một ô trong console là xong" mà không kèm tên dịch vụ nào cụ thể, hãy nghi ngờ ngay.

D — Dùng AWS Lambda function tự khởi tạo snapshot mỗi vài phút. Lỗi cốt lõi: Lambda không phải là hàm tự gọi chính nó — nó luôn cần một dịch vụ khác đứng ra invoke. Phương án này bỏ trống đúng chỗ quan trọng nhất của bài toán: ai bấm nút mỗi vài phút? Nếu cố lách bằng cách viết code cho Lambda tự invoke lại chính nó, hậu quả là số lần gọi song song bùng nổ, biến nó thành một giải pháp rất đắt đỏ và khó kiểm soát. So sánh với B: B ít nhất có một dịch vụ ngoài invoke Lambda (dù chưa giải quyết được chuyện lịch), còn D thì không có gì cả.

📌 Điểm cần nhớ

• "Every few minutes" / "on a schedule" ⇒ nghĩ ngay tới CloudWatch Events rule theo lịch, với hai kiểu khai báo: fixed rate cho chu kỳ đều, cron expression cho thời điểm cụ thể.
• AWS Lambda không tự chạy được. Bất kỳ phương án nào để Lambda "tự động chạy định kỳ" mà không nêu nguồn invoke đều là phương án sai — hãy tìm xem cái gì kích hoạt nó.
• Phân biệt vai trò dịch vụ: SNS là pub/sub để gửi thông báo, không phải scheduler. Chèn SNS vào giữa chỉ làm chuỗi dài thêm chứ không tạo ra tín hiệu theo thời gian.
• EBS snapshot là incremental — chỉ lưu block đã thay đổi so với snapshot trước, nhưng mỗi snapshot vẫn đủ để khôi phục ra volume mới. Đây là lý do việc chụp với tần suất dày vẫn khả thi về thời gian lẫn chi phí.
• Phương án phát biểu rằng một tính năng "có sẵn ngay trên console" mà không gắn với dịch vụ nào cụ thể thường là distractor thuần tuý.

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

Đề mô tả một công ty vừa chuyển hạ tầng máy chủ sang Amazon EC2 và muốn dùng CloudWatch metrics để theo dõi trạng thái từng instance. Câu hỏi: cách cấu hình đúng để việc giám sát bằng CloudWatch hoạt động.

Cụm từ quyết định nằm ở chỗ "track the state of each of the instances" kết hợp với EC2 instances. Chi tiết thứ hai mới là điểm phân biệt thật sự: cả bốn phương án đều xoay quanh CloudWatch Agent, nên thứ cần chọn không phải "có cài agent hay không" mà là agent lấy quyền ghi metric lên CloudWatch từ đâu. Và vì tải chạy trên EC2, cơ chế cấp quyền đúng là IAM role gắn vào instance, chứ không phải IAM user hay Security Group.

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

Đáp án B — cài CloudWatch Agent trên tất cả instance và gắn một IAM role cho EC2 instance.

Mọi thao tác lên tài nguyên AWS đều cần quyền. CloudWatch Agent chạy bên trong hệ điều hành của instance và phải gọi API của CloudWatch để ghi metric lên, nên nó cần credentials hợp lệ. Với EC2, cách cấp quyền chuẩn là tạo một IAM role (điển hình là role CloudWatchAgentServerRole) rồi gắn vào instance; agent lấy credentials tạm thời qua instance metadata, không cần ai nhúng access key vào máy.

Hai vế của đáp án đều bắt buộc: cài agent (vì metric ở mức hệ điều hành như bộ nhớ, dung lượng đĩa, tiến trình không có sẵn ở phần giám sát mặc định của EC2) và gắn IAM role (vì không có role thì agent cài xong vẫn không đẩy được dữ liệu lên CloudWatch).

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

A — Cấu hình CloudWatch từ AWS Console, AWS tự động cài và cấu hình agent. Sai ở phần "tự động". AWS không tự cài CloudWatch Agent vào instance của bạn. Việc cài đặt là trách nhiệm của khách hàng — làm thủ công, qua CLI, hoặc qua các cơ chế triển khai như Systems Manager/user data. Bật gì đó trong Console không sinh ra agent bên trong hệ điều hành.

C — Cài agent và gắn Security Group phù hợp cho EC2 instance. Đây là phương án gần đúng nhất và cũng là bẫy hay gặp: nó nhầm kết nối mạng với phân quyền. Security Group là firewall ở tầng instance, kiểm soát luồng traffic được phép vào/ra; nó không cấp quyền gọi API AWS. Agent có mở được đường ra tới endpoint CloudWatch đi nữa, thiếu credentials thì lời gọi vẫn bị từ chối. Cơ chế cấp quyền cho agent là IAM role hoặc IAM user, không phải Security Group.

D — Cài agent và gắn một IAM user cho EC2 instance. Cũng gần đúng, vì IAM user có là một cách cấp credentials cho CloudWatch Agent — nhưng đó là cách dành cho máy chủ không phải EC2 (ví dụ máy on-premises). Với instance chạy trên EC2, khuyến nghị là dùng IAM role. Về mặt kỹ thuật, IAM user cũng không "attach" vào instance theo cách role làm được: dùng user nghĩa là phải đặt access key/secret key nằm trên máy — thêm bí mật lâu dài cần xoay vòng và bảo quản, đúng thứ mà instance role sinh ra để loại bỏ.

📌 Điểm cần nhớ

• EC2 gọi dịch vụ AWS ⇒ IAM role gắn vào instance. Thấy phương án đề nghị IAM user hay access key cho một workload chạy trên EC2 thì gần như chắc chắn đó là phương án sai trong đề thi.
• IAM ≠ Security Group. IAM trả lời "được phép làm gì với API AWS", Security Group trả lời "gói tin nào đi qua được". Phương án đánh tráo hai khái niệm này xuất hiện rất thường xuyên.
• CloudWatch Agent phải tự cài, AWS không cài hộ. Bất kỳ phương án nào nói AWS "tự động cài và cấu hình" agent đều nên loại ngay.
• Cần metric ở mức hệ điều hành (memory, disk, process) thì bắt buộc phải có agent; nếu chỉ cần các metric ở mức hypervisor thì phần giám sát mặc định của EC2 đã đủ — đọc kỹ đề xem nó đòi loại metric nào.

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

Bối cảnh: nhiều team dùng chung một bộ tài nguyên (EC2, S3 bucket, RDS), và một lập trình viên mới đã xoá nhầm dữ liệu trong bucket dùng chung. Yêu cầu đặt ra cho SysOps Administrator được nêu rất rõ:

"secure the data present in S3 buckets by allowing recovery of objects in case of an accidental deletion"

Cụm quyết định là "allowing recovery ... in case of an accidental deletion" — tức là cho phép khôi phục sau khi đã lỡ xoá, chứ không phải ngăn không cho xoá, cũng không phải siết quyền truy cập. Đây chính là ràng buộc tách bạch bốn phương án: một phương án là cơ chế khôi phục, một phương án là cơ chế cấm sửa/xoá, một phương án là cơ chế kiểm soát quyền, và một phương án là cơ chế sao chép giữa các bucket.

Chi tiết thứ hai cũng quan trọng: các team vẫn đang làm việc trên dữ liệu đó, nên giải pháp không được cản trở việc ghi đè và xoá hợp lệ hằng ngày.

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

B — Enable S3 versioning on all the buckets used in the project.

Versioning là cách giữ nhiều phiên bản của cùng một object trong cùng một bucket. Khi bật versioning, S3 lưu lại, truy xuất và khôi phục được mọi phiên bản của mọi object trong bucket, nên nó xử lý được cả hai kiểu sự cố mà đề mô tả: thao tác sai của người dùng và lỗi của ứng dụng.

Cụ thể với hai tình huống hay gặp:

1. Xoá object: S3 không xoá hẳn mà chèn một delete marker trở thành phiên bản hiện hành. Phiên bản cũ vẫn còn nguyên, xoá delete marker là dữ liệu trở lại.
2. Ghi đè object: kết quả là một phiên bản mới trong bucket, phiên bản trước đó vẫn khôi phục được.

Đúng tinh thần "allowing recovery": vừa cho phép các team tiếp tục ghi/xoá bình thường, vừa luôn có đường lùi. Ngoài ra, khi bucket bật versioning nhận nhiều yêu cầu ghi đồng thời lên cùng một object, S3 lưu tất cả các object đó thay vì để chúng đè mất nhau.

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

A — Enable S3 Object Lock to lock all the objects. Đây là phương án gần đúng nhất và cũng là bẫy chính. Object Lock lưu object theo mô hình WORM (write-once-read-many), ngăn object bị xoá hoặc ghi đè trong một khoảng thời gian cố định hoặc vô thời hạn. Nó phòng ngừa việc xoá chứ không cung cấp khả năng khôi phục — và quan trọng hơn, nó chống lại chính bối cảnh của đề: developer từ nhiều team đang cần thay đổi object trong bucket, khoá hết lại là chặn luôn công việc hợp lệ hằng ngày.

C — Use Amazon S3 bucket owner condition to restrict access to unintended users. Đây là hiểu nhầm về công dụng của tính năng. Bucket owner condition dùng để xác minh bucket đích thuộc đúng AWS account mà bạn mong đợi khi thực hiện thao tác S3 — một biện pháp hữu ích, nhưng nó không kiểm soát việc một developer hợp lệ trong chính account đó xoá dữ liệu, và cũng không giúp lấy lại object đã mất. Sai cả về vấn đề lẫn về kết quả.

D — Use Amazon S3 replication to replicate critical objects. Replication sao chép object tự động, bất đồng bộ giữa các bucket S3. Mục đích thường thấy của nó là chống sự cố hạ tầng hoặc nhân bản dữ liệu sang môi trường khác (production, testing, development), chứ không phải chống xoá nhầm. Nó không phải là cơ chế khôi phục được đề bài yêu cầu, và trong bối cảnh này không giải quyết được vấn đề.

📌 Điểm cần nhớ

• Phân biệt cho rõ ba nhóm động từ trong đề: "recover / restore" → versioning; "prevent deletion / WORM / compliance" → Object Lock; "restrict who can do what" → cơ chế kiểm soát quyền. Đọc đúng động từ là chọn xong đáp án.
• Versioning là cơ chế khôi phục mặc định của S3 cho cả xoá nhầm lẫn ghi đè nhầm: xoá tạo delete marker, ghi đè tạo phiên bản mới, phiên bản cũ luôn còn đó.
• Object Lock chỉ hợp khi dữ liệu không được phép thay đổi. Đề nào còn nói người dùng đang cần sửa/xoá bình thường thì Object Lock là phương án hỏng, dù nó nghe "an toàn" hơn.
• Replication là bài toán về vị trí/độ bền của bản sao, không phải bài toán về lịch sử phiên bản. Đừng dùng nó để trả lời câu hỏi về accidental deletion.

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

Đề mô tả một công ty thương mại điện tử dùng AWS Elastic Beanstalk để dựng môi trường test, trong đó RDS instance được gắn trực tiếp vào environment. Giờ họ muốn tách (decouple) database ra khỏi environment để dùng cho việc phân tích và báo cáo ở một môi trường khác.

Cụm từ quyết định đáp án nằm ở câu cuối: "wants to avoid downtime and database sync issues" — không được có thời gian chết và không được lệch dữ liệu. Chính ràng buộc này loại bỏ mọi phương án có bước "terminate environment hiện tại".

Cần nhớ một điểm nền: khi RDS instance được tạo bên trong một Elastic Beanstalk environment, vòng đời của DB gắn với vòng đời của environment — xoá environment là mất luôn DB. Đó đúng là lý do vì sao AWS chỉ khuyến nghị cách gắn trực tiếp này cho môi trường dev/test, không dùng cho production.

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

Phương án B — dùng kiểu triển khai blue/green của Elastic Beanstalk: giữ environment A đang chạy, tách RDS DB instance ra khỏi nó, rồi tạo environment B mới với thông tin kết nối trỏ tới chính DB instance vừa tách.

Cách này thoả cả hai ràng buộc của đề:

• Không downtime: environment A vẫn phục vụ trong suốt quá trình dựng environment B. Chỉ khi B đã chạy tốt mới chuyển hẳn sang.
• Không lệch dữ liệu: environment B nối vào đúng DB instance đang dùng, không phải một bản khôi phục từ snapshot, nên không có chuyện dữ liệu ghi thêm sau lúc chụp snapshot bị mất.

Trong quy trình này, snapshot và bật Deletion protection trên DB instance đóng vai trò lưới an toàn — để nếu environment A bị xoá thì DB không bị xoá theo. Một điều kiện bắt buộc: environment B không được tự tạo RDS instance của riêng nó trong cùng application, nếu không lại lặp lại đúng vấn đề gắn vòng đời DB vào environment.

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

A. "AWS không hỗ trợ decouple RDS khỏi environment đang chạy" — phát biểu này sai về mặt sự kiện. AWS có hướng dẫn chính thức cho đúng thao tác tách RDS khỏi Elastic Beanstalk environment. Đây là loại phương án bịa ra một giới hạn không tồn tại rồi ép người học chọn cách phá đi làm lại; nhận ra nó bằng cách để ý những câu khẳng định tuyệt đối kiểu "not currently supported".

C. "Vì là môi trường test nên cứ snapshot rồi terminate, dựng lại từ snapshot" — đây là phương án gần đúng nhất và cũng là bẫy chính. Về mặt kỹ thuật nó chạy được, và cụm "test environment" trong đề dễ khiến người đọc thấy nó chấp nhận được. Nhưng nó hỏng ở đúng ràng buộc mà đề nêu ra: terminate rồi dựng lại có downtime, và khôi phục từ snapshot nghĩa là mọi giao dịch ghi sau thời điểm chụp đều mất — chính là database sync issue mà đề yêu cầu tránh. Đề còn nói rõ đang test một sản phẩm "high-stakes", nên lập luận "chỉ là test thôi mà" không đứng vững.

D. "Dùng Immutable deployment" — sai vì nhầm phạm vi tác dụng. Immutable deployment là cơ chế cập nhật phiên bản ứng dụng: Elastic Beanstalk dựng một nhóm instance mới chạy phiên bản mới trong một Auto Scaling group riêng, song song với nhóm cũ; nếu health check không đạt thì huỷ nhóm mới và giữ nguyên nhóm cũ. Nó bảo vệ tầng ứng dụng khỏi một lần deploy hỏng dở dang, chứ không giải quyết việc tách database ra khỏi vòng đời environment. Dùng nó ở đây là trả lời sai câu hỏi — và như lời giải gốc nhận xét, còn là quá mức cần thiết cho một môi trường test.

📌 Điểm cần nhớ

• RDS instance tạo bên trong Elastic Beanstalk environment có vòng đời gắn với environment — xoá environment là mất DB. Chỉ nên dùng cho dev/test; production thì tạo RDS độc lập rồi truyền thông tin kết nối vào.
• Đề nhắc "no downtime" kèm "no data sync issues" thì gần như luôn loại hết các phương án có bước terminate/snapshot-restore, và trỏ về blue/green.
• Phân biệt hai khái niệm dễ lẫn của Elastic Beanstalk: blue/green là chuyển giữa hai environment riêng biệt (giải quyết được chuyện tách tài nguyên như RDS); immutable / rolling chỉ là các kiểu cập nhật trong cùng một environment, thuộc tầng ứng dụng.
• Khi tách DB theo blue/green, hai việc phải làm là bật Deletion protection trên DB instance và bảo đảm environment mới không tự tạo RDS instance của nó.

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

Đề mô tả một công ty dùng AWS CloudFormation để mô hình hoá và cấp phát hạ tầng. Một thao tác sai của con người đã xoá mất một service quan trọng khỏi stack, gây thiệt hại cho hoạt động kinh doanh. Yêu cầu đặt ra là tìm giải pháp nhanh và hiệu quả để khoá các tài nguyên quan trọng, không cho update hoặc delete.

Cụm từ quyết định đáp án là: "lock the critical resources from any updates or deletes" — khoá chính tài nguyên khỏi bị sửa/xoá, và "quick and effective" — nghĩa là dùng cơ chế có sẵn ngay trong CloudFormation chứ không phải tái cấu trúc template hay dựng quy trình xung quanh.

Điểm phân biệt ở đây là phạm vi tác dụng của từng cơ chế: có cái tác động lên tài nguyên trong stack lúc update (đúng thứ đề cần), có cái chỉ tác động lên cách tổ chức template, có cái tác động lên input đầu vào, có cái nằm hoàn toàn ngoài CloudFormation.

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

B — Use Stack policies to protect critical stack resources from unintentional updates.

Stack policy là một tài liệu JSON gắn vào stack, mô tả những hành động update nào được phép thực hiện lên những resource nào (theo Effect Allow/Deny, các action Update:Modify, Update:Replace, Update:Delete, và Resource chỉ định logical ID). Đây đúng là cơ chế CloudFormation sinh ra để bảo vệ tài nguyên quan trọng khỏi những thay đổi ngoài ý muốn có thể làm resource bị gián đoạn hoặc bị thay thế.

Điều làm nó khớp hoàn hảo với đề: khi stack đã có stack policy bảo vệ, trong lúc update bạn phải chỉ định tường minh (explicitly) các protected resource mà bạn muốn thay đổi; nếu không, không có thay đổi nào được áp lên chúng. Nghĩa là mặc định an toàn — chính là "lock" mà đề nói tới, và đúng kịch bản "human error" vì nó buộc người vận hành phải chủ ý mở khoá thay vì lỡ tay.

Nó cũng thoả tiêu chí "quick": chỉ cần đính kèm một JSON policy vào stack, không phải viết lại template. Khuyến nghị của AWS là đặt stack policy ngay khi tạo stack có chứa critical resources.

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

A — Nested stacks giữ cấu hình ở parent kể cả khi child mất. Nested stack là stack tạo ra stack khác. Mục đích của nó là tái sử dụng và tổ chức template: khi hạ tầng lớn dần, những thành phần lặp lại được tách ra thành template riêng rồi gọi từ stack cha. Đây thuần tuý là bài toán quản lý cấu trúc, không có bất kỳ cơ chế bảo vệ nào chống update hay delete resource. Mô tả trong phương án ("parent retain configuration even if child is lost") cũng không phải cách nested stack hoạt động. Chia nhỏ stack ra không ngăn được ai xoá resource trong stack con.

C — Revision controls. Đây là phương án gần đúng nhất và cũng là cái dễ chọn nhầm. Template CloudFormation là code, nên đưa vào revision control kèm code review là best practice thật sự của AWS để theo dõi thay đổi và giữ lịch sử chính xác của hạ tầng. Chỗ nó hỏng: revision control chỉ ghi lại và soát xét thay đổi trên file template, nó nằm ngoài CloudFormation và không có quyền chặn một lệnh update/delete được thực thi lên stack đang chạy. Nó giúp bạn biết ai đã làm gì sau khi chuyện xảy ra, chứ không khoá được resource như đề yêu cầu. Nói cách khác: hữu ích, nhưng là kiểm soát quy trình, không phải kiểm soát thực thi — không giải quyết được tình huống này.

D — Parameter constraints để chỉ định Identity nào được update stack. Phương án này sai ở cả hai vế. Về bản chất, parameter constraint dùng để mô tả giá trị đầu vào hợp lệ (MinLength, MaxLength, AllowedPattern, AllowedValues…) để CloudFormation bắt lỗi giá trị không hợp lệ trước khi tạo stack. Nó hoàn toàn là chuyện validate input, không liên quan gì tới danh tính (identity) hay quyền hạn — việc ai được phép gọi API update thuộc về IAM, không phải parameter constraint. Và quan trọng nhất với đề bài: nó không bảo vệ được resource khỏi bị xoá.

📌 Điểm cần nhớ

• Thấy đề nói "bảo vệ resource trong stack khỏi update/delete ngoài ý muốn" → phản xạ đầu tiên là stack policy (JSON, gắn vào stack, Deny các action Update:* trên resource chỉ định).
• Cơ chế của stack policy là mặc định từ chối: resource đã được bảo vệ chỉ đổi được khi bạn chỉ định tường minh nó trong lần update — đây là điều làm nó chống được lỗi thao tác của con người.
• Phân biệt rõ ba tầng khác nhau trong CloudFormation, đề hay đem ra làm distractor: nested stacks = tổ chức/tái sử dụng template; parameter constraints = validate giá trị đầu vào; stack policies = kiểm soát hành động update lên resource.
• Revision control / code review là best practice cho template nhưng nằm ngoài runtime của CloudFormation — nó phát hiện và truy vết, không chặn. Đề nào đòi "lock", "prevent", "protect from deletion" thì nó không phải đáp án.

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

Đề mô tả một công ty đang tạo IAM role thủ công, dẫn tới role bị thiếu quyền. Công ty đã mở rộng thành nhiều AWS account và đang dùng AWS Organizations để quản lý các account đó. Yêu cầu: tự động hoá việc tạo và quản lý IAM role cho nhiều AWS account.

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

• "automating the process" — phải là quy trình tự động, không phải "làm bằng tay nhưng đỡ vất vả hơn".
• "for multiple AWS accounts" — phạm vi là nhiều account, không phải một account.
• "already uses AWS Organizations" — gợi ý rõ rằng lời giải nên tận dụng tích hợp sẵn có với Organizations.

Ràng buộc phân biệt mạnh nhất là cặp "automating" + "multiple accounts". Nó tách được hai phương án nghe rất giống nhau: dùng CloudFormation template thường (A) và dùng CloudFormation StackSets (C). Cả hai đều là infrastructure as code, nhưng chỉ một trong hai giải quyết được chiều "nhiều account".

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

Đáp án đúng theo tệp là C — Use CloudFormation StackSets with AWS Organizations to deploy and manage IAM roles to multiple AWS accounts simultaneously.

StackSets là phần mở rộng của CloudFormation cho phép triển khai một stack ra nhiều account và nhiều Region từ một chỗ duy nhất. Đây chính xác là hình dạng của bài toán: cùng một định nghĩa IAM role, cần tồn tại ở nhiều account.

Điểm khiến nó khớp hoàn hảo với đề là tích hợp với AWS Organizations. Khi bật chia sẻ dữ liệu giữa CloudFormation và Organizations, bạn triển khai StackSet từ management account tới toàn bộ tổ chức hoặc tới từng OU cụ thể. Kèm theo đó là service-managed permissions: StackSets tự cấu hình các IAM permission cần thiết để deploy vào các account thành viên, thay vì bạn phải tự tạo role tin cậy ở từng account (mô hình self-managed).

Quan trọng với đề bài: với mô hình service-managed, tài nguyên được tạo tự động khi có account mới gia nhập tổ chức và xoá khi account rời đi. Đó là vòng đời tự động thật sự — đúng nghĩa "automate the process of creating and managing", chứ không chỉ tự động ở lần chạy đầu tiên. Và vì role sinh ra từ một template chung, lỗi "role thiếu quyền" do làm tay biến mất: sửa template một lần, cập nhật lan ra mọi account.

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

A — Create CloudFormation templates and reuse them to create necessary IAM roles in each of the AWS accounts. Đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. CloudFormation template đúng là giải quyết được vế "định nghĩa role bằng code", loại bỏ chuyện gõ tay từng quyền — nên phần lớn lỗi thiếu quyền sẽ hết. Nhưng chữ "reuse them ... in each of the AWS accounts" tự thú nhận điểm yếu: bạn vẫn phải đăng nhập vào từng account rồi tạo stack thủ công, và mỗi lần cập nhật template lại phải lặp lại vòng đó ở mọi account. Account mới gia nhập tổ chức cũng không tự có role. Vậy nó là bán tự động, trong khi đề đòi tự động hoá cho nhiều account. C chính là A cộng thêm đúng phần còn thiếu.

B — Use AWS Directory Service with AWS Organizations to automatically associate necessary IAM roles with the Microsoft Active Directory users. AWS Directory Service (AWS Managed Microsoft AD) là dịch vụ chạy Microsoft Active Directory dạng managed, hoặc kết nối tài nguyên AWS với AD on-premises có sẵn. Nó thuộc về bài toán danh tính người dùng — gán người dùng AD vào role đã tồn tại. Nó không tạo ra các IAM role, mà đề bài thì đang hỏng ở khâu tạo role (role sinh ra thiếu quyền). Sai cả bài toán.

D — Use AWS Resource Access Manager that integrates with AWS Organizations to deploy and manage shared resources across AWS accounts. AWS RAM có tích hợp với Organizations thật, nên nghe rất hợp tai. Nhưng RAM làm việc chia sẻ một tài nguyên bạn đang sở hữu cho account khác dùng chung — cùng một tài nguyên, nhiều account cùng truy cập. Đề bài lại cần tái tạo cùng một định nghĩa role thành nhiều bản riêng ở từng account. Hai chuyện khác hẳn nhau: "share one" so với "provision many". Thêm nữa, IAM role không nằm trong nhóm tài nguyên mà RAM dùng để giải bài toán này.

📌 Điểm cần nhớ

• Thấy "nhiều AWS account" + "CloudFormation" trong cùng một câu thì gần như luôn là StackSets, không phải template thường. Template thường chỉ giải quyết phạm vi một account, một stack.
• Đề nhắc "already uses AWS Organizations" là tín hiệu cố ý: hãy chọn phương án khai thác tích hợp với Organizations. Với StackSets, đó là triển khai theo OU/toàn tổ chức và service-managed permissions.
• Phân biệt hai động từ khi đọc phương án: RAM = share (một tài nguyên, nhiều account cùng dùng); StackSets = provision/replicate (nhiều bản của cùng một định nghĩa). Nhầm hai cái này là bẫy quen thuộc.
• Directory Service thuộc tầng danh tính, không thuộc tầng cấp phát tài nguyên. Nó gắn người dùng vào role, chứ không sinh ra role.
• Cẩn thận với phương án chỉ "đỡ thủ công hơn" khi đề yêu cầu "automate": nếu vẫn phải lặp lại thao tác ở từng account, và account mới không được xử lý tự động, thì chưa phải tự động hoá.