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

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

Đề đặt bối cảnh: một công ty thương mại điện tử dùng AWS Systems Manager để tự động hoá công việc quản trị cho cả đội Amazon EC2 đang chạy ứng dụng. Câu hỏi chốt lại: nên dùng cái gì để khôi phục tự động một instance đang bị suy giảm (impaired)?

Cụm từ quyết định đáp án nằm ở hai chỗ, và phải đọc cùng nhau:

• "AWS Systems Manager" — khoanh vùng câu trả lời phải là một Automation document của Systems Manager, chứ không phải một dịch vụ khác.
• "recover an impaired instance" — mục tiêu là cứu một instance đang không truy cập được, tức là chẩn đoán và lấy lại quyền truy cập vào máy đang chạy. Đây không phải vá lỗi, không phải làm mới AMI, không phải triển khai lại hạ tầng.

Cả bốn phương án (trừ phương án bịa) đều là tên document thật của Systems Manager, nên bài này thực chất kiểm tra: bạn có nhớ document nào làm việc gì hay không. Ràng buộc phân biệt là mục đích của document — cứu instance so với tạo AMI so với cập nhật stack.

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

Đáp án đúng theo tệp là B — dùng document AWSSupport-ExecuteEC2Rescue.

Một Automation document trong Systems Manager định nghĩa quy trình tự động: chuỗi hành động mà Systems Manager thực hiện trên các managed instance và tài nguyên AWS. Systems Manager có sẵn nhiều Automation document dựng trước cho các việc thường gặp — khởi động lại instance, tạo AMI, và cứu instance.

AWSSupport-ExecuteEC2Rescue là document dành riêng cho tình huống instance trở nên không tiếp cận được. Nguyên nhân có thể là cấu hình mạng sai, sự cố RDP, hoặc firewall đặt sai. Trước khi có document này, muốn lấy lại quyền truy cập phải làm rất nhiều bước tay: tách volume, gắn sang instance khác, sửa cấu hình, gắn trả lại. Document này gói toàn bộ quy trình đó lại — bạn chỉ cần đưa instance ID và cho nó chạy, khớp đúng với chữ "automatically" trong đề.

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

A — "Automatic recovery of impaired instances is not possible currently": sai về mặt sự kiện. Systems Manager Automation có hẳn document dựng trước cho đúng việc này. Đây là distractor kiểu phủ định — trong đề thi AWS, phương án khẳng định "không làm được" hầu như luôn sai, vì đề đã tự nêu Systems Manager ở câu dẫn thì rõ ràng có đường làm.

C — AWS-UpdateWindowsAmi: đây là phương án gần đúng nhất, và cũng chính là bẫy. Nó thật, nó là Automation document của Systems Manager, nó cũng "sửa chữa" thứ gì đó. Nhưng công việc của nó — cùng với AWS-UpdateLinuxAmi — là tạo golden AMI từ một source AMI: bật instance từ AMI nguồn, cài bản cập nhật, rồi chụp thành AMI mới. Nó tác động lên ảnh máy dùng cho các lần khởi tạo sau, không hề chạm tới instance đang bị suy giảm ngay lúc này. Instance hỏng vẫn nằm đó, vẫn không truy cập được. Ngoài ra nó chỉ phục vụ Windows, còn đề nói "fleet of EC2 instances" không giới hạn hệ điều hành.

D — AWS-UpdateCloudFormationStackWithApproval: cũng là document thật, nhưng để cập nhật các tài nguyên đã triển khai bằng CloudFormation template, kèm bước phê duyệt thủ công trước khi áp dụng. Hai điểm hỏng: (1) nó làm việc ở tầng stack, không chẩn đoán hay cứu một instance cụ thể — nếu instance mất truy cập vì firewall hay RDP thì cập nhật stack chẳng giải quyết được gì; (2) chữ WithApproval nghĩa là có người phải bấm duyệt, trái hẳn với yêu cầu "automatically" của đề. Chưa kể đề không nói gì về việc đội instance này được triển khai bằng CloudFormation.

📌 Điểm cần nhớ

• Đọc tiền tố của tên document là đã lọc được một nửa: AWSSupport-* là các quy trình chẩn đoán/khắc phục sự cố kiểu AWS Support, AWS-Update* là các quy trình bảo trì và cập nhật. Đề nói "recover impaired" thì nhìn AWSSupport-.
• AWSSupport-ExecuteEC2Rescue = lấy lại quyền truy cập vào EC2 instance không tiếp cận được (lỗi mạng, RDP, firewall), chỉ cần đưa instance ID.
• AWS-UpdateLinuxAmi / AWS-UpdateWindowsAmi = tạo golden AMI từ source AMI. Chúng sửa ảnh máy cho tương lai, không sửa instance đang chạy — đừng lẫn "cập nhật" với "khôi phục".
• Từ khoá "automatically" trong đề loại thẳng mọi document có WithApproval trong tên, vì tên đó tự nói rằng nó cần người duyệt.
• Phương án nói "AWS hiện chưa làm được việc này" gần như luôn là distractor, nhất là khi câu dẫn đã chỉ đúng dịch vụ có sẵn tính năng đó.

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

Đề nói về một EC2 instance EBS volume backed đang bị quá tải và cần nâng cấp; developer muốn biết những điều cần lưu ý khi đổi instance type. Câu yêu cầu chọn ba phát biểu đúng.

Cụm từ quyết định nằm ngay ở dòng đầu: "Amazon EBS volume backed EC2 instance" và động tác "changing the instance type" — tức là thao tác resize instance. Đây là chìa khoá phân biệt, vì cả nhóm phương án xoay quanh đúng ba chuyện: (1) resize đòi hỏi root device là gì, (2) instance phải ở trạng thái nào khi resize, (3) cái gì được giữ lại và cái gì mất đi sau khi stop/start. Ai đọc lướt cụm "EBS backed" sẽ dễ nuốt phương án F, còn ai không nhớ hành vi của public IPv4 sau khi stop/start sẽ nuốt phương án E.

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

A — Instance nằm trong Auto Scaling group sẽ bị đánh dấu unhealthy khi stop. Resize bắt buộc phải stop instance. Auto Scaling nhìn instance ở trạng thái stopped là instance không còn phục vụ được, nên đánh dấu unhealthy, có thể terminate nó và launch một instance thay thế. Muốn tránh, người vận hành cần suspend các scaling process của group trong lúc resize.

B — Chỉ resize được khi root device là EBS volume. Đúng theo cơ chế: EBS root volume tách rời khỏi phần cứng vật lý nên có thể gắn lại vào một host khác với instance type mới. Nếu root device là instance store volume thì không có đường resize — phải migrate ứng dụng sang một instance mới với instance type mong muốn. Đề đã nói rõ instance này là EBS backed, tức là con đường resize mở ra đúng vì lý do này.

C — Phải stop instance trước khi đổi instance type; AWS chuyển instance sang phần cứng mới nhưng instance ID không đổi. Đây là mô tả chuẩn của chu trình stop → change instance type → start. Việc stop/start khiến AWS đặt instance lên host vật lý khác, nhưng định danh logic — instance ID — được giữ nguyên, nên mọi tham chiếu tới instance ID vẫn còn giá trị.

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

D — "Không có downtime nếu chọn instance type tương thích, AWS khởi động instance mới và chuyển ứng dụng sang." Sai cả về cơ chế lẫn kết luận. Không hề có chuyện AWS "chuyển ứng dụng" giúp bạn; resize là stop rồi start chính instance đó. AWS khuyến nghị lên kế hoạch cho khoảng downtime: bản thân bước stop và resize mất một khoảng thời gian, còn thời gian instance khởi động lại còn phụ thuộc vào startup script của ứng dụng nên không cố định. Đây là phương án dễ chọn nhầm nhất vì nó nghe giống trải nghiệm "live resize" ở nơi khác.

E — "Instance mới giữ nguyên public IPv4, private IPv4, Elastic IP và IPv6." Gần đúng nhưng hỏng ở đúng một chỗ: public IPv4 address. Khi stop/start, nếu instance đang dùng public IPv4 do AWS cấp tự động thì địa chỉ đó bị thu hồi và instance nhận một public IPv4 mới. Ba thứ còn lại — private IPv4, Elastic IP, IPv6 — thì đúng là được giữ. Chính vì phương án gom cả bốn vào một rổ nên nó sai; đây cũng là lý do Elastic IP tồn tại: nó là địa chỉ public ổn định qua các lần stop/start.

F — "Resize được với cả EBS lẫn instance store, chỉ là instance store khởi động lâu hơn do mất cache." Sai ở mệnh đề chính. Với root device là instance store, resize không phải là chậm hơn mà là không làm được — phải migrate sang instance mới. Vế giải thích "mất cache nên khởi động lâu" được thêm vào để nghe có lý và trực tiếp mâu thuẫn với phương án B, vốn là đáp án đúng.

📌 Điểm cần nhớ

• Resize instance = stop → đổi instance type → start, và điều kiện tiên quyết là root device phải là EBS volume. Instance store–backed thì chỉ còn đường migrate sang instance mới.
• Stop/start giữ nguyên instance ID, private IPv4, Elastic IP và IPv6, nhưng thả public IPv4 tự động và cấp cái mới. Cần địa chỉ public cố định thì dùng Elastic IP.
• Resize luôn có downtime — đề bài nào hứa "no downtime" khi đổi instance type đều là bẫy.
• Instance trong Auto Scaling group phải suspend scaling process trước khi stop, nếu không group sẽ coi nó unhealthy, terminate và launch instance thay thế.

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

Đề mô tả một công ty dùng AWS X-Ray để trace luồng ứng dụng, và họ đang chạy đủ loại dịch vụ: API Gateway, EC2, S3, Elastic Load Balancer, Lambda. Câu hỏi là: cần lưu ý điều gì khi dùng X-Ray với những dịch vụ này?

Cụm từ quyết định nằm ở chỗ đề liệt kê Elastic Load Balancers chung với các dịch vụ khác rồi hỏi "keep in mind" — tức là đề đang tìm cái ngoại lệ trong danh sách. Bốn phương án đều có dạng "X không tích hợp / không dùng được với X-Ray", nên bài toán thực chất là: trong bốn dịch vụ được nêu, dịch vụ nào không phải là nguồn gửi dữ liệu trace cho X-Ray? Ba dịch vụ còn lại đều là integration đầy đủ của X-Ray, chỉ có load balancer là đứng ngoài.

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

B — Application Load Balancers do not send data to X-Ray.

Application Load Balancer có tham gia vào câu chuyện tracing, nhưng chỉ ở một vai trò duy nhất: nó chèn một trace ID vào request HTTP đi vào, qua header X-Amzn-Trace-Id. Header đó là thứ giúp các segment sinh ra ở downstream (API Gateway, EC2, Lambda) được ghép lại thành cùng một trace.

Nhưng chèn header không phải là gửi dữ liệu. ALB tự nó không tạo segment, không gọi lên X-Ray API, và vì vậy không xuất hiện như một node trên service map. Đây chính xác là "điều cần lưu ý": người vận hành mở service map ra, thấy client nối thẳng tới API Gateway hay EC2 mà không thấy load balancer ở giữa, dễ tưởng cấu hình sai — trong khi đó là hành vi bình thường theo thiết kế.

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

A — X-Ray không trace được Lambda vì không tích hợp. Sai hẳn, và sai theo hướng ngược lại: Lambda là một trong những integration chặt chẽ nhất của X-Ray. Nền tảng Lambda tự chạy X-Ray daemon trong môi trường thực thi và tự ghi một segment mô tả lần gọi hàm — gồm cả thời gian khởi tạo và thời gian chạy code. Người dùng chỉ cần bật tracing cho hàm, không phải cài agent gì.

C — Không dùng X-Ray để trace request tới API Gateway. Cũng sai. API Gateway hỗ trợ X-Ray tracing và trace được request của người dùng khi nó đi xuyên qua API tới các dịch vụ phía sau. Đáng chú ý là hỗ trợ này áp dụng cho mọi loại endpoint của API Gateway — Regional, edge-optimized và private — nên không có kẽ hở nào để nói "loại endpoint của tôi thì không được". Phương án này thoạt nhìn có vẻ hợp lý với ai chỉ quen dùng CloudWatch cho API Gateway, nhưng nó phủ nhận một integration chính thức.

D — X-Ray không tích hợp S3, phải dùng CloudTrail. Đây là phương án gần đúng nhất và nguy hiểm nhất, vì nửa sau của nó nghe rất quen: CloudTrail đúng là công cụ ghi lại API call trên S3. Nhưng nửa đầu sai, và hai công cụ này giải quyết hai bài toán khác nhau. X-Ray có tích hợp với Amazon S3: nó trace được các upstream request khi ứng dụng của bạn ghi/cập nhật vào bucket, để bạn thấy lời gọi S3 nằm ở đâu trong luồng và tốn bao lâu. CloudTrail thì phục vụ audit — ai gọi, gọi lúc nào — chứ không dựng ra bức tranh latency của một request end-to-end. Trả lời D là đánh tráo "audit log" thành "distributed tracing".

📌 Điểm cần nhớ

• Load balancer chèn trace ID, nhưng không gửi trace. ALB thêm header X-Amzn-Trace-Id để gắn kết các segment downstream, còn bản thân nó không tạo segment và không hiện lên service map.
• Không có node trên service map ≠ không được trace. Khi debug service map thiếu thành phần, hãy phân biệt "dịch vụ này không phải nguồn dữ liệu X-Ray" với "cấu hình tracing của tôi hỏng".
• API Gateway, Lambda và S3 đều là integration hợp lệ của X-Ray. Lambda đặc biệt ở chỗ nền tảng tự chạy daemon và tự ghi segment cho lần gọi hàm; API Gateway hỗ trợ cả ba loại endpoint.
• Đừng lẫn CloudTrail với X-Ray. CloudTrail trả lời "ai đã gọi API nào", X-Ray trả lời "một request đi qua những đâu và chậm ở khâu nào". Với S3, cả hai đều dùng được, cho hai mục đích khác nhau.

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

Đề mô tả một công ty bán lẻ để tệp quan trọng trong một Amazon S3 bucket, và bucket đó được cấu hình làm website endpoint. Yêu cầu: chỉ cho phép truy cập qua CloudFront, không ai được lấy tệp trực tiếp bằng URL của S3.

Cụm từ quyết định nằm ngay ở phần mô tả hiện trạng: "also configured as a website endpoint". Đây chính là ràng buộc phân biệt hai phương án A và D — hai phương án còn lại (Security Group, Network ACL) chỉ là nhiễu về mặt kiến trúc mạng.

Điểm mấu chốt: một S3 bucket bật static website hosting không còn được CloudFront coi là S3 origin, mà phải khai báo như một custom origin. Bỏ qua chi tiết này là chọn ngay phương án nghe quen tai nhất mà sai.

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

A — Setup the Amazon S3 bucket as a custom origin with CloudFront, restrict access bằng custom headers.

Vì bucket đang chạy ở dạng website endpoint, cấu hình bắt buộc là khai nó thành custom origin trong CloudFront. Với custom origin, cơ chế khoá truy cập là origin custom headers: CloudFront gắn thêm một header bí mật vào mọi request gửi tới origin, và origin chỉ phục vụ những request có header đó. Ai gọi thẳng URL S3 sẽ không có header nên bị từ chối.

Kèm theo, tài liệu AWS yêu cầu siết hai thiết lập giao thức để header bí mật không bị lộ trên đường truyền:

• Viewer Protocol Policy: bắt người dùng truy cập CloudFront bằng HTTPS.
• Origin Protocol Policy: bắt CloudFront dùng đúng giao thức đó khi chuyển tiếp về origin.

Sau khi bật, phía origin phải được cập nhật để chỉ chấp nhận request có custom header — đây là bước làm cho cấu hình thực sự có hiệu lực, không phải chỉ khai báo bên CloudFront là xong.

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

D — Origin Access Identity (OAI): đây là phương án gần đúng nhất và cũng là bẫy chính của câu hỏi. OAI đúng là cơ chế chuẩn để giới hạn truy cập S3 chỉ qua CloudFront — nhưng nó chỉ dùng được khi bucket là REST API endpoint, tức S3 origin thông thường. Khi bucket được cấu hình làm website endpoint, tính năng origin access identity không dùng được, vì CloudFront lúc đó xử lý bucket như custom origin chứ không phải S3 origin. Chi tiết "website endpoint" trong đề chính là thứ loại D.

C — Security Group: Security Group là tường lửa ảo gắn vào Amazon EC2 instance (và các elastic network interface trong VPC), kiểm soát traffic vào/ra ở mức instance. Không gắn Security Group vào CloudFront được, cũng không gắn được vào một S3 bucket. Phương án này sai ngay ở tầng dịch vụ, chưa nói đến việc nó không diễn đạt được yêu cầu "chỉ CloudFront mới vào được".

B — Network ACL: Network ACL là lớp bảo mật tuỳ chọn của VPC, hoạt động như tường lửa ở mức subnet, lọc traffic ra vào một hoặc nhiều subnet. CloudFront là dịch vụ edge toàn cầu, nằm ngoài VPC của bạn, nên Network ACL không áp dụng cho CloudFront. Ngoài ra S3 cũng không nằm trong subnet của bạn để mà lọc bằng NACL.

Điểm chung của B và C: cả hai đều là công cụ mạng cấp VPC, trong khi vấn đề ở đây là kiểm soát truy cập cấp ứng dụng/HTTP giữa CloudFront và origin.

📌 Điểm cần nhớ

• S3 bucket bật static website hosting = custom origin đối với CloudFront, không phải S3 origin. Đọc đề thấy chữ "website endpoint" là phải đổi hướng suy nghĩ ngay.
• OAI chỉ hoạt động với S3 REST endpoint. Với custom origin (kể cả S3 website endpoint), cách khoá truy cập là origin custom headers + origin tự kiểm tra header đó.
• Muốn custom header có tác dụng bảo mật thật thì phải ép HTTPS ở cả viewer lẫn origin protocol policy, nếu không header bí mật đi qua đường truyền rõ.
• Security Group và Network ACL là công cụ trong VPC (instance và subnet). Thấy chúng xuất hiện trong câu hỏi về CloudFront hay S3 thì gần như chắc chắn là phương án nhiễu.

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

Tình huống: một SysOps Administrator đã tăng dung lượng của EBS volume đang gắn vào một EC2 instance. Thao tác trên volume xem như đã xong, nhưng file system bên trong instance vẫn báo dung lượng cũ. Đề hỏi cấu hình sai ở đâu và sửa thế nào.

Cụm từ quyết định nằm ở câu thứ hai: "the increased size is not reflected in the file system". Đề cố ý tách bạch hai lớp khác nhau:

• Lớp block device — chính EBS volume, thứ vừa được modify và giờ đã lớn hơn thật.
• Lớp file system — ext4, XFS, NTFS… nằm trên block device đó, và nó vẫn giữ metadata mô tả kích thước cũ.

Đề không nói volume bị lỗi, không nói modify thất bại, cũng không nói volume kẹt ở trạng thái nào. Nó nói riêng file system chưa thấy phần dung lượng mới. Vậy đây không phải "cấu hình sai" theo nghĩa hỏng hóc, mà là thiếu một bước bắt buộc: mở rộng file system sau khi mở rộng volume.

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

Đáp án đúng theo tệp là C — "After you increase the size of an EBS volume, you must extend the file system to a larger size".

Tăng kích thước EBS volume chỉ làm block device to ra. File system nằm trên đó không tự nhận biết phần không gian mới; phải chạy lệnh mở rộng đặc thù theo từng loại file system để nó ghi lại metadata cho khớp dung lượng mới của volume.

Trên Linux, quy trình gồm hai ý:

1. Volume có thể có partition chứa file system và dữ liệu. Tăng kích thước volume không tự tăng kích thước partition — nên trước khi mở rộng file system, phải kiểm tra xem có partition cần mở rộng theo dung lượng mới không.
2. Sau đó dùng lệnh riêng của file system để resize nó lên đúng dung lượng mới của volume.

Việc resize có thể bắt đầu ngay khi volume bước vào trạng thái optimizing — không cần chờ modify hoàn tất 100%, và đặc biệt là không cần detach hay reboot gì cả.

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

A — "Volume có thể đã được encrypt; volume encrypted không hiện thay đổi khi còn attach, hãy detach rồi attach lại." Encryption của EBS hoàn toàn không liên quan tới tình huống này. Mã hoá EBS trong suốt với instance: dữ liệu được mã hoá/giải mã ở tầng dưới, còn hệ điều hành nhìn thấy một block device bình thường. Volume encrypted hay không thì việc mở rộng file system vẫn phải làm y hệt. Phương án này gán nguyên nhân cho một thuộc tính chẳng liên quan.

B — "Phải detach rồi attach lại volume thì thay đổi mới hiện ra." Đây là distractor gần đúng nhất và cũng là bẫy phổ biến nhất, vì nó nghe hợp lý với người quen suy nghĩ "phải khởi động lại thì mới nhận". Nó hỏng ở chỗ: detach/attach chỉ tác động tới việc gắn block device vào instance — nó không hề chạm vào metadata của file system. Có detach và attach lại bao nhiêu lần thì file system vẫn báo kích thước cũ, vì chưa ai bảo nó resize. Ngoài ra cách này còn buộc phải unmount, tức là chịu gián đoạn dịch vụ để đổi lấy đúng con số không thay đổi gì.

D — "Linux tự nhận thay đổi, Windows thì không; dùng Windows Disk Management để tăng kích thước đĩa." Phương án này đúng một nửa vế sau và sai hẳn vế đầu — kiểu bẫy khó chịu nhất. Vế sai: Linux không tự nhận; như đã nói, trên Linux vẫn phải tự chạy lệnh mở rộng file system. Vế đúng: trên Windows, sau khi tăng kích thước EBS volume, đúng là dùng Windows Disk Management hoặc PowerShell để mở rộng đĩa lên dung lượng mới, và cũng có thể bắt đầu ngay khi volume vào trạng thái optimizing. Nhưng vì phương án này dựng lên một sự khác biệt Linux–Windows không có thật, nó mô tả sai nguyên nhân. C mới là phát biểu đúng cho cả hai hệ điều hành.

📌 Điểm cần nhớ

• Modify volume và extend file system là hai bước tách rời. EBS lo phần block device; mở rộng file system là việc phải làm bên trong instance, trên mọi hệ điều hành — không có ngoại lệ cho Linux.
• Trên Linux, nhớ thêm một tầng nữa: nếu volume có partition thì phải mở rộng partition trước, rồi mới resize file system. Bỏ qua bước này là file system chỉ lớn tới hết partition cũ.
• Việc resize file system không đòi hỏi detach volume hay dừng instance — có thể làm ngay khi volume ở trạng thái optimizing.
• Gặp phương án viện dẫn encryption làm nguyên nhân cho một hành vi vận hành thông thường thì nên nghi ngờ: mã hoá EBS là trong suốt với hệ điều hành, hầu như không đổi quy trình thao tác nào.
• Cảnh giác với phương án đúng một nửa như D: nó gói một thao tác có thật (Disk Management trên Windows) vào một tiền đề sai (Linux tự nhận). Đọc kỹ mệnh đề đầu tiên trước khi bị phần kỹ thuật quen thuộc phía sau thuyết phục.

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

Đề mô tả một tình huống rất cụ thể về CloudWatch Agent: có hai file cấu hình — file thứ nhất thu thập metrics và logs chung cho mọi server, file thứ hai thu thập metrics riêng cho một vài ứng dụng. Agent được khởi động với file thứ nhất, sau đó file thứ hai được append vào.

Cụm từ quyết định đáp án nằm ở câu: "You have given the same name to both the files but stored these files in different file paths."

Đây chính là ràng buộc phân biệt các phương án. Nếu hai file có tên khác nhau, kết quả sẽ là gộp cấu hình — agent thu thập tất cả metrics và logs liệt kê trong cả hai file. Nhưng đề cố tình đặt trùng tên file, và còn nhấn thêm rằng chúng nằm ở đường dẫn khác nhau để gài bẫy người đọc nghĩ rằng "khác path thì khác file". Với CloudWatch Agent, cái được dùng để phân biệt là tên file, không phải đường dẫn đầy đủ.

Câu hỏi hỏi "What is the outcome" — tức là hỏi hệ quả thực tế của việc trùng tên đó.

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

Đáp án đúng là B — The append command overwrites the information from the first configuration file instead of appending to it.

CloudWatch Agent hỗ trợ dùng nhiều file cấu hình cùng lúc. Quy trình chuẩn là khởi động agent bằng tuỳ chọn fetch-config với file cấu hình đầu tiên, rồi dùng chính lệnh đó nhưng với tuỳ chọn append-config để nối thêm file thứ hai vào agent đang chạy. Khi làm đúng, toàn bộ metrics và logs khai báo trong bất kỳ file nào cũng đều được thu thập.

Tuy nhiên, tài liệu AWS nêu rõ một điều kiện bắt buộc: mọi file cấu hình dùng chung trên cùng một server phải có tên file khác nhau — khác nhau giữa các file append với nhau, và khác cả với file cấu hình khởi tạo ban đầu. Nếu dùng append-config với một file trùng tên với file agent đang dùng, lệnh append sẽ ghi đè thông tin của file thứ nhất thay vì nối thêm. Và điều này đúng ngay cả khi hai file trùng tên đó nằm ở hai đường dẫn khác nhau — đúng chính xác tình huống đề bài mô tả.

Kết quả: cấu hình chung cho toàn bộ server (file thứ nhất) bị mất, agent chỉ còn chạy với metrics của các ứng dụng trong file thứ hai. Đây là kiểu lỗi rất khó phát hiện vì lệnh không báo lỗi — chỉ đến khi mở CloudWatch ra mới thấy metrics và logs chung biến mất.

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

A — Two different Agents are started with different configurations. Sai về cơ chế. append-config không sinh ra một tiến trình agent thứ hai; nó tác động lên chính agent đang chạy. Trên một server chỉ có một CloudWatch Agent hoạt động, và việc "chạy hai agent song song mỗi cái một cấu hình" không phải cách CloudWatch Agent làm việc.

C — Second configuration file parameters are added to the Agent already running. Đây là phương án gần đúng nhất, và cũng là bẫy chính của câu hỏi. Mô tả trong C chính xác là hành vi bình thường của append-config — trong trường hợp hai file có tên khác nhau. Nó hỏng ở chỗ bỏ qua đúng cái ràng buộc mà đề bài đã cài vào: hai file trùng tên. Khi trùng tên, cơ chế không còn là "cộng thêm" mà chuyển thành "ghi đè". Chọn C nghĩa là đã đọc đề nhưng bỏ qua chi tiết same name.

D — A CloudWatch Agent can have only one configuration file. Sai hoàn toàn về mặt khả năng. CloudWatch Agent được thiết kế để dùng nhiều file cấu hình, đó chính là lý do tồn tại tuỳ chọn append-config. Nếu D đúng thì kịch bản "cấu hình chung cho mọi server + cấu hình riêng theo ứng dụng" mà đề bài mô tả sẽ không thực hiện được ngay từ đầu. Lưu ý phân biệt: agent có thể dùng nhiều file cấu hình, nhưng kết quả cuối cùng là một cấu hình hợp nhất đang chạy — không nên nhầm hai chuyện này với nhau.

📌 Điểm cần nhớ

• fetch-config dùng để khởi động agent với file cấu hình đầu tiên; append-config dùng để nối thêm file cấu hình vào agent đang chạy. Đây là mô hình chuẩn cho kịch bản "một cấu hình baseline chung + nhiều cấu hình bổ sung theo ứng dụng".
• Điều kiện bắt buộc để append hoạt động đúng: tên file phải khác nhau. Trùng tên thì append biến thành ghi đè, và cấu hình cũ mất trắng.
• Đường dẫn khác nhau không cứu được việc trùng tên — CloudWatch Agent phân biệt các file cấu hình theo tên file, không theo full path. Đây là chi tiết mà đề thi rất hay đem ra làm bẫy.
• File cấu hình CloudWatch Agent có thể lưu ngay trên server hoặc trong Parameter Store; cách lưu không thay đổi quy tắc trùng tên ở trên.
• Khi gặp câu hỏi kiểu "outcome là gì", hãy quét lại đề tìm chi tiết bất thường được nhấn mạnh (ở đây là same name + different file paths) — chi tiết đó thường chính là thứ lật ngược đáp án từ hành vi mặc định sang hành vi ngoại lệ.

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

Đề đặt bạn vào vai SysOps Administrator, cần tính tổng lượng network usage của toàn bộ EC2 instance của công ty và xác định instance nào dùng nhiều băng thông nhất trong một khoảng ngày. Câu hỏi chốt lại rất hẹp: metric nào của Amazon CloudWatch cho bạn dữ liệu đó.

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

• "network usage" / "bandwidth" — thứ cần đo là lưu lượng mạng, không phải I/O đĩa, không phải CPU.
• "per instance" (which instance used the most) — cần số liệu tách theo từng EC2 instance, tức metric phải có dimension InstanceId.
• "Amazon CloudWatch metric(s)" — nguồn dữ liệu bắt buộc là CloudWatch, chứ không phải báo cáo chi phí hay công cụ khác.

Ba ràng buộc này gộp lại loại được hết các phương án nhiễu: cái thì đo sai thứ (đĩa), cái thì đúng ý nghĩa nhưng sai nơi cư trú (báo cáo chi phí), cái thì không tồn tại.

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

Đáp án đúng theo tệp là D — NetworkIn và NetworkOut.

Đây là cặp metric mà EC2 phát ra sẵn cho CloudWatch dưới namespace của EC2, gắn theo từng instance:

• NetworkIn — số byte instance nhận được trên tất cả network interface của nó. Metric này cho biết khối lượng lưu lượng mạng đi vào một instance.
• NetworkOut — số byte instance gửi đi trên tất cả network interface. Metric này cho biết khối lượng lưu lượng mạng đi ra từ instance đó.

Đơn vị của cả hai là Bytes, và con số báo về là tổng số byte trong khoảng thời gian (period) của data point, chứ không phải tốc độ tức thời. Vì vậy chúng ghép đúng vào cả hai vế của đề:

• Tổng network usage: lấy statistic Sum của NetworkIn + NetworkOut rồi cộng dồn (aggregate) các data point trong khoảng ngày cần tính.
• Instance nào dùng nhiều nhất: vì metric tách theo từng instance, chỉ cần so tổng đã cộng dồn giữa các instance.

Một chi tiết đáng nhớ có trong giải thích gốc: nếu muốn đổi ra Bytes/giây, hãy chia con số Sum cho độ dài period — với basic monitoring (period 5 phút) thì chia cho 300, với detailed monitoring (period 1 phút) thì chia cho 60. Nhưng ở câu này, đề hỏi tổng lượng dùng, nên Sum thô đã là thứ cần rồi, không phải quy đổi.

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

A. NetworkTotalBytes — metric này không tồn tại. Nó là distractor được đặt tên nghe rất hợp lý: đề hỏi "total network usage" thì một metric tên "NetworkTotalBytes" trông như câu trả lời đóng gói sẵn. Đây chính là cái bẫy hay gặp nhất trong đề AWS: tên phương án được ghép từ đúng chữ trong đề bài. EC2 không gộp sẵn in + out thành một metric duy nhất — bạn phải tự cộng NetworkIn với NetworkOut.

B. DataTransfer-Out-Bytes — đây là phương án gần đúng nhất và cần nói rõ nó hỏng ở đâu. Nó thực sự liên quan tới lưu lượng mạng, nhưng nó là chỉ số dùng trong báo cáo AWS Cost Explorer, tức thuộc về ngữ cảnh chi phí/hoá đơn, không phải metric giám sát EC2 trong CloudWatch mà đề bài yêu cầu. Ngoài ra nó chỉ nói về phần truyền ra (out), nên kể cả nếu chấp nhận nguồn dữ liệu đó thì cũng thiếu chiều vào — không tính được "total network usage" như đề đòi.

C. DiskReadBytes và DiskWriteBytes — đúng là hai metric EC2 có thật trong CloudWatch, nhưng chúng đo I/O đĩa, không phải mạng:

• DiskReadBytes: số byte đọc từ tất cả instance store volume gắn với instance — dùng để biết ứng dụng đọc bao nhiêu dữ liệu từ đĩa.
• DiskWriteBytes: số byte ghi xuống các instance store volume đó.

Cặp này hữu ích khi đánh giá tốc độ/khối lượng làm việc với đĩa của ứng dụng, nhưng hoàn toàn không nói gì về bandwidth. Chọn nó là đọc nhầm chữ "usage" thành "I/O nói chung" thay vì "network".

📌 Điểm cần nhớ

• NetworkIn + NetworkOut là cặp metric chuẩn của EC2 trong CloudWatch để đo lưu lượng mạng theo từng instance; đơn vị Bytes, giá trị là tổng byte trong period, và tách theo từng instance nên so sánh được instance nào ngốn băng thông nhất.
• Muốn ra tổng lượng dùng trong một khoảng ngày thì dùng statistic Sum rồi cộng dồn các data point; muốn ra tốc độ (Bytes/giây) thì chia Sum cho độ dài period (basic monitoring 5 phút, detailed monitoring 1 phút).
• Phân biệt rành mạch Network* (mạng) với Disk* (I/O đĩa) — đọc lướt chữ "usage" rất dễ chọn nhầm sang DiskReadBytes/DiskWriteBytes.
• Chỉ số kiểu DataTransfer-Out-Bytes thuộc thế giới chi phí (Cost Explorer), không phải metric giám sát trong CloudWatch — đề hỏi "CloudWatch metric" là đã loại nó.
• Cảnh giác với phương án mang tên ghép y hệt chữ trong đề bài (NetworkTotalBytes); nếu bạn chưa từng thấy metric đó trong tài liệu EC2, khả năng cao nó được bịa ra làm nhiễu.

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

Đề mô tả một ứng dụng production chạy trên Amazon EC2, dùng MySQL RDS làm cơ sở dữ liệu. Nhóm vận hành muốn làm cho phần RDS deployment trở nên highly available and failure-proof, và hỏi cách "easy and effective" để đạt được điều đó.

Cụm từ quyết định đáp án là "highly available and failure-proof" kết hợp với "easy and effective way". Đây là hai ràng buộc riêng biệt, cần đọc cả hai:

• "highly available" loại ngay những phương án chỉ giải quyết chuyện khôi phục sau sự cố (backup) hoặc sức chứa (scale up storage). High availability nghĩa là khi một thành phần chết, hệ thống vẫn phục vụ được — chứ không phải "có thể lấy lại dữ liệu sau khi chết".
• "easy" ám chỉ một tính năng có sẵn, bật bằng một tuỳ chọn, chứ không phải thứ phải tự dựng.

Một cái bẫy khác nằm ở chữ RDS deployment — câu hỏi giới hạn phạm vi vào chính tầng database, không phải vào tầng ứng dụng đang chạy trên EC2.

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

B — Configure the RDS to be a multi Availability Zone (AZ) deployment.

Multi-AZ chính là cơ chế Amazon RDS cung cấp sẵn để đạt high availability và failover cho DB instance. Khi bật Multi-AZ, RDS tự động tạo và duy trì một standby replica đồng bộ (synchronous) nằm ở một Availability Zone khác. Primary DB instance được sao chép đồng bộ sang standby, nhờ đó:

• Dữ liệu có tính dư thừa (redundancy) qua nhiều AZ.
• Tránh I/O freeze và giảm đột biến độ trễ trong lúc chạy system backup, vì backup lấy từ standby.
• Chịu được cả hỏng DB instance lẫn gián đoạn cả một Availability Zone.
• Bảo trì hệ thống theo kế hoạch cũng ít gây gián đoạn hơn.

Về vế "easy": trên RDS console chỉ cần chọn tuỳ chọn Multi-AZ lúc tạo DB instance, hoặc modify một instance đang có để bật lên. Cũng làm được bằng AWS CLI (create-db-instance, modify-db-instance) hay RDS API (CreateDBInstance, ModifyDBInstance). Không phải viết script, không phải tự dựng replication — đúng tinh thần "easy and effective" mà đề yêu cầu.

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

A — Scale up your DB instance when you are approaching storage capacity limits. Đây là vertical scaling, giải quyết vấn đề dung lượng/hiệu năng chứ không phải tính sẵn sàng. Dù có nâng instance to đến đâu thì vẫn chỉ có một instance duy nhất — nó chết là database chết. Phương án này còn lạc đề ở chỗ đề không hề nói tới chuyện sắp hết chỗ lưu trữ.

C — Configure automated backups for the RDS instance. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất, vì backup nghe rất "failure-proof". Automated backups thực sự có giá trị: RDS sao lưu database cùng transaction log, giữ theo retention period do người dùng đặt, cho phép point-in-time recovery. Nhưng chỗ nó hỏng là: backup thuộc về disaster recovery, không phải high availability. Khi instance chết, backup không tự đứng lên phục vụ thay — phải có người khôi phục, và trong suốt thời gian đó ứng dụng vẫn đứt. Một database quan trọng cần Multi-AZ để chịu được lỗi, backup chỉ để sửa hậu quả sau đó.

D — Configure your JVM with a TTL value of no more than 60 seconds. Phương án này không sai về mặt kỹ thuật, và đó chính là chỗ gài bẫy. JVM cache lại kết quả phân giải DNS; khi RDS failover, endpoint được trỏ sang standby, nên nếu JVM giữ DNS cache quá lâu thì ứng dụng vẫn cố nối tới instance cũ đã chết. Đặt TTL ngắn đúng là một phần của cấu hình high availability. Nhưng nó chỉ có tác dụng khi failover xảy ra — mà muốn có failover thì trước hết phải có Multi-AZ. Nói cách khác, D là bước bổ trợ phụ thuộc vào B; chọn D mà không có B thì chẳng có gì để failover sang cả. Ngoài ra D chỉnh ở tầng ứng dụng trên EC2, trong khi đề hỏi về cấu hình của RDS deployment.

📌 Điểm cần nhớ

• High availability ≠ backup. Multi-AZ giúp hệ thống chịu được lỗi và tự failover; automated backup chỉ giúp khôi phục sau lỗi và luôn kèm downtime. Đề hỏi "highly available" thì chọn nhóm đầu.
• Multi-AZ dùng standby replica đồng bộ ở AZ khác, phục vụ mục đích availability — nó không phải cơ chế để mở rộng khả năng đọc.
• Vertical scaling không tạo ra tính sẵn sàng. Còn đúng một instance thì vẫn còn đúng một điểm chết duy nhất.
• Cẩn thận với phương án "đúng nhưng không đủ". Chỉnh DNS TTL phía client là việc nên làm, nhưng nó là hệ quả đi kèm của Multi-AZ chứ không thay thế được Multi-AZ. Khi hai phương án cùng đúng một phần, hãy chọn cái tạo ra điều kiện tiên quyết, không chọn cái tinh chỉnh bên trên nó.

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

Đề đặt ra một tình huống nghe có vẻ nghịch lý: CTO là root user của chính AWS account đó, thế mà lại không truy cập được một S3 bucket nằm trong account của công ty mình. Câu hỏi đòi hai thứ cùng lúc: lý do của hành vi này, và cách sửa.

Cụm từ quyết định nằm ở chỗ: bucket đó nằm trong chính account của công ty ("present in the company's own AWS account"), và root user đã tạo ra các IAM user khác ("has created other AWS users using the root user account"). Hai chi tiết này gạt bỏ ngay mọi lời giải thích kiểu "bucket thuộc account khác", đồng thời gợi ý rằng một trong các IAM user do CTO tạo ra chính là người đã gắn bucket policy lên bucket.

Điểm kiến thức bị đánh trúng: root user không đứng ngoài vòng kiểm soát của resource-based policy. Nhiều người học thuộc lòng câu "root có toàn quyền trong account" rồi coi đó là bất khả xâm phạm — đề bài cố tình dựng bẫy quanh đúng niềm tin đó.

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

Đáp án đúng là C: nếu một IAM user có full access vào IAM và Amazon S3 gắn một bucket policy lên bucket mà không khai AWS account root user trong phần tử Principal, thì root user bị từ chối truy cập bucket đó.

Cơ chế ở đây là sự khác nhau giữa hai loại policy. Với S3, bucket policy là một resource-based policy: nó tự khai ai được đụng vào tài nguyên. Với resource-based policy, quyền không tự động chảy xuống từ vị thế "chủ account" — request chỉ được cho phép khi principal của nó khớp với những gì policy liệt kê. Một IAM user có AdministratorAccess hoàn toàn đủ quyền để viết ra một bucket policy chỉ liệt kê chính họ (hoặc một nhóm principal hẹp), và khi đó root user không nằm trong danh sách nên bị chặn.

Cách sửa cũng nằm ngay trong đáp án và phần giải thích nguồn: root user vẫn sửa được bucket policy từ S3 console hoặc AWS CLI, và chỉ cần thêm chính mình vào Principal:

"Principal": { "AWS": "arn:aws:iam::123456789012:root" }

Nói cách khác, đây là tình huống tự khoá cửa chứ không phải mất quyền vĩnh viễn — root vẫn đủ thẩm quyền để mở lại policy cho chính mình.

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

A. Bucket policy có wildcard * trong Principal bị AWS tuyên vô hiệu, policy rơi vào trạng thái invalid và hành vi ngẫu nhiên. Sai từ gốc. AWS không có cơ chế nào "tuyên vô hiệu" một bucket policy hợp lệ về cú pháp, và policy đánh giá hoàn toàn tất định — không có chuyện "random behavior". Wildcard trong Principal là cách viết hợp lệ (chính là cách mở public một bucket, thường bị chặn bởi Block Public Access chứ không bị "hoá vô hiệu"). Phương án này còn lạc đề: nó nói về mở quá rộng, trong khi đề đang mô tả tình huống bị chặn.

B. Root luôn có quyền với mọi tài nguyên trong account; bucket này chắc là của account khác được chia sẻ nên mới hiện trong danh sách. Đây là phương án gần đúng nhất và cũng là bẫy chính, vì nửa đầu đúng với trực giác. Nó hỏng ở hai chỗ. Thứ nhất, nó mâu thuẫn trực tiếp với đề bài: đề nói rõ bucket nằm trong chính account của công ty, nên không thể viện cớ bucket thuộc account khác. Thứ hai, tiền đề "root luôn có quyền với mọi tài nguyên" chính là điều câu hỏi này muốn bác bỏ — resource-based policy có thể loại root ra khỏi danh sách principal.

D. Root có quyền với mọi tài nguyên trong account; liên hệ AWS Support để xử lý. Cùng một tiền đề sai như B, và phần "cách sửa" cũng sai. Đây là vấn đề cấu hình do chính khách hàng gây ra, và chính khách hàng sửa được bằng cách chỉnh bucket policy. Nhờ AWS Support ở đây là leo thang không cần thiết cho một việc tự làm được trong vài phút. Trong đề thi, phương án "contact AWS Support" cho một sự cố mà admin tự khắc phục được gần như luôn là mồi nhử.

📌 Điểm cần nhớ

• Root user không tự động vượt qua resource-based policy. Bucket policy của S3 quyết định ai được truy cập dựa trên Principal; không có tên trong đó thì root cũng bị từ chối.
• Phân biệt identity-based policy và resource-based policy. IAM policy gắn vào user/role; bucket policy gắn vào tài nguyên. Truy cập S3 là kết quả đánh giá cả hai phía, không chỉ phía danh tính.
• Muốn root truy cập lại thì sửa Principal thành ARN root của account (arn:aws:iam::<account-id>:root) — root vẫn đủ thẩm quyền chỉnh chính bucket policy đó qua console hoặc CLI.
• Đọc kỹ ràng buộc trong đề trước khi chọn. Khi đề đã khẳng định bucket nằm trong chính account, mọi phương án giải thích bằng "bucket của account khác" đều tự loại.
• Cảnh giác với phương án "liên hệ AWS Support" khi sự cố xuất phát từ cấu hình của chính khách hàng và có cách tự sửa rõ ràng.

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

Một công ty truyền thông lưu bài viết trên các bucket Amazon S3 và đã bật server access logging cho toàn bộ bucket. Họ cần một giải pháp làm được ba việc cùng lúc:

1. Kiểm tra định kỳ xem logging có đang bật hay không;
2. Áp dụng cho cả bucket hiện có lẫn bucket tạo mới sau này;
3. Tự động sửa (automate the remedy) khi phát hiện bucket không tuân thủ.

Cụm từ quyết định đáp án là "regularly check ... for all the existing buckets and for any new ones" cộng với "automate the remedy". Đây chính là mô tả của một dịch vụ đánh giá tuân thủ cấu hình liên tục, có sẵn cơ chế remediation — chứ không phải một dịch vụ ghi log, một dịch vụ chỉ khuyến nghị, hay một hàm code tự viết. Vế "existing + new" loại bỏ những giải pháp chỉ chạy một lần; vế "automate the remedy" loại bỏ những giải pháp chỉ dừng ở mức báo động.

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

Phương án A — dùng AWS Config rules. AWS Config theo dõi cấu hình của tài nguyên AWS và đánh giá chúng theo các rule mô tả cấu hình mong muốn. Có sẵn managed rule s3-bucket-logging-enabled kiểm tra đúng thứ câu hỏi cần: bucket đã bật server access logging hay chưa. Rule của AWS Config chạy đánh giá bằng Lambda ở phía dưới và trả về trạng thái compliant / noncompliant cho từng tài nguyên; vì Config theo dõi liên tục nên bucket mới tạo cũng lọt vào phạm vi đánh giá mà không phải cấu hình lại gì.

Phần quan trọng còn lại là Auto-Remediation của AWS Config: mỗi rule có thể gắn một remediation action, và action đó được thực thi tự động ngay khi tài nguyên bị đánh giá là non-compliant. Ngoài s3-bucket-logging-enabled, cùng cơ chế này còn áp dụng cho các rule S3 khác như s3-bucket-server-side-encryption-enabled, s3-bucket-public-read-prohibited, s3-bucket-public-write-prohibited. Như vậy A đáp ứng trọn cả ba yêu cầu: kiểm tra định kỳ, phủ cả tài nguyên cũ lẫn mới, và tự sửa.

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

B — Bật AWS CloudTrail để theo dõi, rồi dùng Lambda để sửa. Sai ở tiền đề mà chính phương án tự nêu ra: nó khẳng định "AWS does not provide an automatic remediation process". Điều đó không đúng — AWS Config có sẵn Auto-Remediation, nên lý do biện minh cho việc tự viết Lambda sụp đổ. Thêm nữa, CloudTrail ghi lại các lời gọi API trên tài khoản, nó không phải công cụ đánh giá xem một bucket có đang bật logging hay không; đây là hai loại thông tin khác nhau.

C — Lambda tự kiểm tra rồi bắn SNS. Đây là phương án gần đúng nhất và hỏng ở hai chỗ. Thứ nhất, nó chỉ thông báo chứ không sửa — SNS gửi cảnh báo, còn đề bài đòi automate the remedy. Thứ hai, Lambda không tự poll được; nó cần một cơ chế hoặc dịch vụ bên ngoài kích hoạt. Nếu viết logic tự gọi lại chính nó trong cùng hàm Lambda thì hàm sẽ chạy liên tục, ăn hết tài nguyên có sẵn và trở thành giải pháp đắt đỏ. Nói cách khác, phương án này vừa thiếu vế remediation, vừa thiếu vế "regularly".

D — AWS Trusted Advisor kiểm tra rồi cấu hình remedy action. Vế đầu đúng: Trusted Advisor thực sự có check về cấu hình bucket S3 liên quan tới server access logging, nằm trong bộ kiểm tra best practices. Nhưng vế sau sai — Trusted Advisor chỉ đưa ra khuyến nghị sau khi kiểm tra, không tự động thực thi hành động khắc phục. Không có chỗ để "configure a remedy action with Trusted Advisor" như phương án mô tả. Vì vậy nó không phải giải pháp tối ưu cho tình huống này.

📌 Điểm cần nhớ

• Đề bài nhắc tới kiểm tra tuân thủ cấu hình + tự động khắc phục thì nghĩ ngay tới AWS Config rule + Auto-Remediation; đây là cặp từ khoá gần như luôn dẫn về AWS Config.
• Phân biệt rõ vai trò: CloudTrail ghi lại lời gọi API (ai làm gì, lúc nào), AWS Config ghi lại và đánh giá trạng thái cấu hình của tài nguyên. Câu hỏi hỏi "bucket có bật logging không" là câu hỏi về cấu hình.
• Trusted Advisor chỉ khuyến nghị, không tự sửa. Phương án nào gán khả năng auto-remediation cho Trusted Advisor thì loại.
• Lambda không tự lên lịch cho chính nó — nó luôn cần thứ khác kích hoạt. Phương án "viết Lambda tự kiểm tra định kỳ" mà không nêu cơ chế trigger là dấu hiệu của phương án sai; và dừng ở SNS notification thì mới là cảnh báo, chưa phải remediation.