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

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

Một đội EC2 instances chạy trong VPC, định kỳ đẩy log lên một dịch vụ bên thứ ba qua internet. Dịch vụ đó vừa bật IP whitelisting và yêu cầu mọi lần upload phải đến từ một địa chỉ IP duy nhất.

Cụm từ quyết định là "requires all uploads to come from a single IP address" — cộng với chi tiết đây là một fleet, tức nhiều instance chứ không phải một máy. Đề không hỏi làm sao để có internet (các máy đang có sẵn), mà hỏi làm sao để nhiều nguồn khác nhau xuất hiện dưới cùng một IP công cộng khi nhìn từ bên ngoài.

Hai chi tiết phụ cũng cần giữ trong đầu: IP mà dịch vụ nhìn thấy là IP nguồn công cộng của gói tin đi ra, và whitelist ở đây nhận một địa chỉ, không phải một dải. Vậy cần một thành phần nằm trên đường ra internet, làm nhiệm vụ dịch địa chỉ nguồn về chung một IP.

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

D — Move all of the EC2 instances behind a NAT gateway and provide the gateway IP address to the service.

NAT gateway cung cấp kết nối internet cho instances nằm trong private subnet, và nó thực hiện đúng việc network address translation: IP nguồn private của từng instance được dịch thành một IP công cộng có thể định tuyến trên internet — chính Elastic IP gắn với NAT gateway.

Hệ quả là dù fleet có bao nhiêu máy, dịch vụ bên thứ ba luôn thấy traffic đến từ một địa chỉ duy nhất: IP của NAT gateway. Đây là cách đơn giản nhất thoả yêu cầu của đề, và địa chỉ đó ổn định nên đưa vào whitelist được. Traffic vẫn là outbound do instance khởi tạo, đúng với mô hình hoạt động của NAT gateway.

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

A — Tạo một ENI dùng chung cho các EC2 instances rồi đưa Elastic IP của ENI cho dịch vụ. Đây là phương án gần đúng về mặt ý tưởng — gom mọi máy sau một IP duy nhất — nhưng hỏng ở chỗ kỹ thuật: không thể gắn nhiều EC2 instances vào cùng một ENI. Một ENI thuộc về một instance tại một thời điểm; nó không phải thiết bị dùng chung. Nên cấu hình mô tả trong phương án này không dựng lên được.

B — Đặt các instances sau một internet gateway và đưa IP của gateway cho dịch vụ. Nghe hợp lý vì internet gateway cũng nằm trên đường ra internet, nhưng IGW không làm NAT theo kiểu gom nhiều nguồn về một IP. Instance trong public subnet đi qua IGW vẫn giữ IP công cộng riêng của chính nó làm địa chỉ nguồn. Kết quả là dịch vụ bên thứ ba thấy nhiều IP khác nhau — đúng thứ mà whitelist đang chặn. Ngoài ra IGW không phải là một thiết bị có "IP của gateway" để khai báo cho bên ngoài.

C — Dồn hết instances vào một subnet rồi đưa CIDR block của subnet cho dịch vụ. Sai ở bản chất địa chỉ: CIDR block của subnet là dải IP private bên trong VPC, dịch vụ bên ngoài internet không bao giờ nhìn thấy nó và cũng không định tuyến tới được. Thêm nữa, đề đòi một IP, còn CIDR là một dải — kể cả nếu là dải public thì vẫn không khớp yêu cầu. Gom vào một subnet không tự nó thay đổi IP nguồn mà traffic mang ra internet.

📌 Điểm cần nhớ

• Thấy yêu cầu "traffic từ nhiều instance phải đến từ một IP duy nhất" (IP whitelisting bên thứ ba) → nghĩ ngay tới NAT gateway: nó dịch IP nguồn của cả nhóm về một Elastic IP.
• Phân biệt rõ vai trò: internet gateway cho phép đi ra internet nhưng giữ nguyên IP công cộng riêng của từng instance; NAT gateway mới là thứ gộp nhiều nguồn thành một địa chỉ.
• Một ENI không dùng chung cho nhiều instance — mọi phương án đề xuất "một ENI cho cả fleet" đều loại được ngay mà không cần xét tiếp.
• CIDR block của subnet là địa chỉ private, không phải danh tính trên internet. Cái mà bên ngoài nhìn thấy luôn là IP công cộng sau khi đã đi qua IGW hoặc NAT gateway.

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

Đề mô tả một fleet EC2 instances nằm trong private subnet, phải gửi dữ liệu ra Internet, và hoá đơn NAT gateway tăng mạnh. Câu hỏi cuối cùng là: "How can a SysOps Administrator identify which instances are creating the most network traffic?"

Cụm từ quyết định đáp án là "which instances are creating the most network traffic". Nó đặt ra hai yêu cầu cùng lúc, và phải thoả cả hai:

1. Which instances — cần định danh được từng nguồn phát, tức phải có source IP của mỗi instance trong private subnet.
2. The most network traffic — cần đo được khối lượng byte đi qua NAT gateway, chứ không phải chỉ biết "có kết nối".

Chi tiết "private subnet + NAT gateway" cũng quan trọng: mọi instance ra Internet đều bị NAT gateway dịch địa chỉ, nên nhìn từ phía ngoài chúng dùng chung một địa chỉ công cộng. Muốn tách ra ai là ai thì phải quan sát ở phía trong, nơi còn giữ private IP nguồn. Đây chính là chỗ loại bỏ ba phương án còn lại: chúng hoặc không có dữ liệu ở mức luồng mạng, hoặc không phân giải được tới từng instance.

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

D — Enable flow logs on the NAT gateway elastic network interface and use Amazon CloudWatch Logs Insights to filter data based on the source IP addresses.

VPC Flow Logs là cơ chế duy nhất trong danh sách ghi lại thông tin ở mức luồng IP: source IP, destination IP, port, protocol, số packet và số byte của từng luồng. Flow logs bật được ở mức VPC, mức subnet, hoặc mức từng elastic network interface — và NAT gateway chính là một ENI trong VPC, nên bật flow logs ngay trên ENI đó sẽ thu đúng phần lưu lượng đang bị tính tiền, không lẫn lưu lượng nội bộ không đi qua NAT.

Sau khi log chảy vào CloudWatch Logs, CloudWatch Logs Insights cho phép truy vấn: gom nhóm theo srcAddr rồi cộng dồn trường byte, sắp xếp giảm dần. Kết quả là bảng xếp hạng private IP nào đẩy nhiều dữ liệu nhất qua NAT gateway — từ private IP tra ngược ra instance là việc đơn giản. Đúng hai yêu cầu của đề: định danh được nguồn, và đo được khối lượng.

Phần giải thích gốc của đề cũng nói đúng như vậy: flow logs bật trên ENI của NAT gateway (hoặc trên VPC), rồi dùng CloudWatch Insights lọc theo source IP.

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

A — AWS Cost and Usage Report, group by instance ID. Đây là phương án nghe hợp lý nhất vì đề mở đầu bằng chuyện hoá đơn, nên người làm bài dễ bị kéo về hướng công cụ chi phí. Nhưng Cost and Usage Report báo cáo chi phí theo tài nguyên bị tính tiền, mà tài nguyên bị tính tiền ở đây là NAT gateway — phí giờ chạy và phí dữ liệu xử lý qua NAT gateway. Chi phí đó không được quy về từng EC2 instance đứng sau NAT, nên không có cách nào "group by instance ID" để ra thủ phạm. CUR cho biết tốn bao nhiêu, không cho biết ai gây ra.

B — Gắn Elastic IP cho từng instance rồi xem metrics trong CloudWatch, lọc theo instance ID. Hỏng ở hai chỗ. Thứ nhất, gắn Elastic IP cho từng instance làm thay đổi kiến trúc: instance có địa chỉ công cộng thì không còn đi qua NAT gateway nữa, tức là phá bỏ chính thứ đang cần điều tra thay vì đo nó. Thứ hai, CloudWatch cho EC2 chỉ có performance metrics như NetworkIn/NetworkOut — đó là tổng byte của instance, gộp cả lưu lượng nội bộ trong VPC lẫn lưu lượng ra Internet, và không tách được phần nào thực sự đi qua NAT gateway. Metrics là số liệu tổng hợp, không phải bản ghi luồng có source/destination.

C — Xem CloudTrail logs, tìm API actions dùng NAT gateway. Nhầm lẫn kinh điển giữa control plane và data plane. CloudTrail ghi các lời gọi API quản trị: ai tạo NAT gateway, ai sửa route table, ai xoá subnet. Việc một instance gửi gói tin TCP ra Internet không phải là một API call — không có action nào tên kiểu "SendDataThroughNatGateway" để mà tìm. Dù bật CloudTrail đầy đủ thì log vẫn hoàn toàn im lặng về lưu lượng dữ liệu.

📌 Điểm cần nhớ

• Câu hỏi "ai gửi nhiều dữ liệu nhất" trong VPC → VPC Flow Logs. Đây là nguồn duy nhất có source IP, destination IP, port và byte count ở mức từng luồng.
• Flow logs bật được ở ba cấp: VPC, subnet, hoặc từng ENI. Chọn cấp ENI khi muốn khoanh đúng một điểm nghi ngờ (như ENI của NAT gateway) để log gọn và truy vấn nhanh hơn.
• Phân biệt CloudTrail với flow logs: CloudTrail = ai gọi API gì (control plane); Flow Logs = gói tin đi từ đâu tới đâu (data plane). Lưu lượng mạng không bao giờ xuất hiện trong CloudTrail.
• Phân biệt CloudWatch metrics với CloudWatch Logs Insights: metrics là số đo tổng hợp theo thời gian (NetworkIn/NetworkOut), không tách được theo đối tác hay theo đường ra; Logs Insights là công cụ truy vấn để stats sum(bytes) by srcAddr trên flow logs.
• Công cụ chi phí (Cost and Usage Report, Cost Explorer) trả lời "tốn bao nhiêu ở tài nguyên nào", không trả lời "instance nào gây ra". Đề nhắc tới hoá đơn không có nghĩa lời giải nằm ở tầng billing.

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

Đề mô tả một tình huống rất cụ thể của AWS CloudFormation: quản trị viên tạo stack lần đầu tiên, việc tạo stack thất bại và stack rơi vào trạng thái ROLLBACK_COMPLETE. Sau đó lỗi trong template đã được sửa, và câu hỏi là: làm sao để tiếp tục triển khai?

Cụm từ quyết định đáp án là ROLLBACK_COMPLETE — không phải "template đã được sửa", cũng không phải "muốn tiếp tục". Trạng thái này chỉ xuất hiện sau một lần tạo stack (create) thất bại: CloudFormation đã rollback, tức là đã xoá sạch những resource kịp tạo ra trong lần thử đó. Cái còn lại trên console chỉ là một bản ghi stack rỗng, không còn resource nào bên dưới.

Ràng buộc mấu chốt: một stack đang ở ROLLBACK_COMPLETE không chấp nhận thao tác update. Thao tác duy nhất hợp lệ với nó là delete. Vì vậy "tiếp tục" ở đây không thể hiểu theo nghĩa "sửa tiếp cái stack cũ", mà phải là tạo một stack mới.

Chú ý phân biệt với UPDATE_ROLLBACK_COMPLETE — trạng thái sau khi update thất bại và rollback về bản trước. Stack đó vẫn còn resource và vẫn update tiếp được. Đề bài nói rõ "attempted to use it for the first time to create a new stack", nên đây là create chứ không phải update.

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

D — Relaunch the template to create a new stack.

Ở ROLLBACK_COMPLETE, mọi resource sinh ra trong lần create hỏng đã bị dọn sạch — quá trình rollback đã hoàn tất đúng như tên gọi. Bản thân stack không giữ hạ tầng nào để "sửa tiếp", nó chỉ là cái vỏ ghi lại một lần thử thất bại. CloudFormation vì thế chỉ cho phép xoá nó.

Đường đi hợp lệ là: xoá stack ở trạng thái ROLLBACK_COMPLETE (hoặc dùng một tên stack khác), rồi chạy lại create-stack với template đã sửa. Đó chính xác là điều phương án D mô tả — triển khai lại template để tạo stack mới. Vì lần trước không để lại resource nào nên việc chạy lại không gây trùng lặp hay xung đột tài nguyên do chính lần thử đó tạo ra.

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

A — Perform an update-stack action on the failed stack. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi, vì trực giác nói rằng "template sai → sửa template → update stack". Nó hỏng ở đúng một chỗ: update-stack yêu cầu stack đang ở trạng thái cho phép cập nhật (ví dụ CREATE_COMPLETE, UPDATE_COMPLETE, UPDATE_ROLLBACK_COMPLETE). Stack ở ROLLBACK_COMPLETE không nằm trong số đó, lời gọi sẽ bị từ chối. Ngoài ra, ngay cả nếu chạy được thì cũng vô nghĩa: không còn resource nào để cập nhật.

B — Run the execute-change-set command. Change set là cơ chế xem trước và áp dụng thay đổi lên stack. Muốn execute-change-set thì trước đó phải create-change-set thành công — mà bạn không tạo được change set cho một stack đang ở ROLLBACK_COMPLETE. Phương án này thất bại sớm hơn cả A: nó giả định tồn tại một change set mà trong tình huống đề bài không thể có. Về bản chất change set cũng chỉ là một biến thể của luồng update, nên nó vướng đúng rào cản trạng thái như phương án A.

C — Run a validate-template command. Lệnh này chỉ kiểm tra cú pháp JSON/YAML và cấu trúc template có hợp lệ hay không. Nó không triển khai gì cả, không tạo và không sửa stack nào. Dùng nó là hợp lý ở bước rà soát trước khi deploy, nhưng đề đã nói lỗi trong template đã được resolve rồi và người quản trị muốn tiếp tục deployment — validate không đưa hạ tầng tiến thêm một bước nào. Đây là phương án sai vì trả lời nhầm câu hỏi, không phải vì trạng thái stack.

📌 Điểm cần nhớ

• ROLLBACK_COMPLETE = create thất bại và đã dọn sạch. Thao tác duy nhất còn hợp lệ trên stack đó là delete; muốn triển khai lại thì xoá đi rồi create-stack lần nữa.
• Phân biệt rõ hai trạng thái nghe giống nhau: ROLLBACK_COMPLETE (create hỏng, không update được) và UPDATE_ROLLBACK_COMPLETE (update hỏng, stack cũ còn nguyên, update tiếp được). Đề nói "first time / create a new stack" là tín hiệu chỉ về vế thứ nhất.
• Change set không phải lối tắt vượt qua rào cản trạng thái. create-change-set/execute-change-set là luồng update, nên bị chặn ở đúng những trạng thái mà update-stack bị chặn.
• validate-template chỉ kiểm cú pháp template, không đụng tới stack. Gặp phương án này trong câu hỏi về "làm sao deploy tiếp / khắc phục stack", gần như luôn là mồi nhử.

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

Đề hỏi: theo shared responsibility model, những hoạt động nào liên quan tới Amazon EC2 là trách nhiệm của AWS (chọn HAI).

Cụm từ quyết định đáp án là "for which... activities is AWS responsible" — tức là chỉ lấy phần "Security of the Cloud", chứ không phải "Security in the Cloud" của khách hàng. Cụm thứ hai cũng quan trọng không kém: "Amazon EC2". EC2 là dịch vụ hạ tầng (IaaS), nên ranh giới trách nhiệm bị đẩy xuống rất thấp: AWS dừng lại ở hypervisor và mọi thứ bên dưới nó (phần cứng, mạng vật lý, trung tâm dữ liệu); từ guest OS trở lên là việc của khách hàng.

Với dạng câu này, mẹo phân biệt rất máy móc: đọc từng phương án và hỏi "thứ này khách hàng có bấm/chỉnh được bằng Console, CLI hay SSH không?". Nếu có, thì đó là trách nhiệm khách hàng. Nếu khách hàng không có cách nào chạm tới (không ai SSH vào hypervisor của AWS, không ai đi kéo cáp trong data center), thì đó là trách nhiệm AWS.

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

Đáp án đúng theo tệp là A và D.

A. Patching the hypervisor. Hypervisor là lớp ảo hoá nằm dưới các EC2 instance, thuộc phần "infrastructure that runs all of the services offered in the AWS Cloud". Khách hàng không hề có quyền truy cập vào lớp này — nó không xuất hiện trong bất kỳ API nào của AWS dành cho người dùng. Vá lỗi cho nó hoàn toàn thuộc về AWS, và AWS làm việc đó một cách trong suốt với khách hàng.

D. Maintaining network infrastructure. Hạ tầng mạng vật lý — thiết bị mạng, đường truyền, kết nối giữa các Availability Zone, cơ sở vật chất của data center — nằm trong đúng danh sách mà tài liệu shared responsibility model liệt kê: hardware, software, networking, and facilities. Lưu ý phân biệt: cấu hình mạng logic mà khách hàng tự dựng (VPC, subnet, route table, security group) là việc của khách hàng; còn duy trì hạ tầng mạng bên dưới là việc của AWS. Phương án D nói về vế thứ hai.

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

B. Configuring security groups. Đây là phương án dễ nhầm nhất vì security group nghe rất giống "bảo mật", mà bảo mật thì hay bị gán cho AWS. Nhưng security group là firewall ảo do khách hàng cấu hình: bạn tự quyết định mở cổng nào, cho dải IP nào. AWS chỉ cung cấp cơ chế và bảo đảm cơ chế đó chạy đúng; còn luật bạn viết vào đó thì AWS không đụng tới. Mở cổng 22 ra toàn Internet là lỗi của khách hàng, không phải lỗi của AWS.

C. Monitoring EBS volume utilization. Cũng là một phương án gần đúng: AWS có cung cấp sẵn công cụ đo (CloudWatch phát metric cho EBS volume). Nhưng "monitoring" ở đây nghĩa là theo dõi và hành động — đặt alarm, quyết định ngưỡng bao nhiêu là nguy hiểm, mở rộng volume khi sắp đầy. AWS không biết bao nhiêu phần trăm dung lượng là "đủ" đối với workload của bạn, nên việc theo dõi mức sử dụng thuộc về khách hàng. Có sẵn công cụ không đồng nghĩa với việc AWS chịu trách nhiệm dùng công cụ đó thay bạn.

E. Patching the guest operating system. Đây là bẫy chính, cố tình đặt cạnh phương án A để xem thí sinh có phân biệt được hypervisor với guest OS hay không. Với Amazon EC2, hệ điều hành chạy bên trong instance là của khách hàng: bạn SSH/RDP vào được, cài phần mềm được, và vì thế bạn phải tự vá nó. AWS có thể phát hành AMI đã cập nhật, nhưng instance đang chạy của bạn thì AWS không tự vá. (Điểm này khác với các dịch vụ managed, nơi AWS lo phần OS — nhưng câu hỏi này nói rõ là EC2.)

📌 Điểm cần nhớ

• Ranh giới trong shared responsibility model: AWS lo "Security of the Cloud" (hardware, software nền, networking, facilities), khách hàng lo "Security in the Cloud" (dữ liệu, cấu hình, OS, quyền truy cập).
• Với Amazon EC2, đường phân chia nằm đúng ở giữa hypervisor (AWS) và guest OS (khách hàng). Câu hỏi rất hay đặt hai thứ này cạnh nhau để đánh lừa.
• Quy tắc kiểm tra nhanh: thứ gì khách hàng cấu hình hoặc đăng nhập vào được thì thuộc trách nhiệm khách hàng — security group, guest OS, monitoring EBS đều rơi vào nhóm này.
• AWS cung cấp công cụ ≠ AWS chịu trách nhiệm dùng công cụ. CloudWatch có sẵn metric cho EBS, nhưng đặt ngưỡng và phản ứng vẫn là việc của bạn.
• Phân biệt hạ tầng mạng vật lý (AWS duy trì) với cấu hình mạng logic như VPC, subnet, route table, security group (khách hàng tự dựng).

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

Đề mô tả một Amazon RDS MySQL bị chậm trong giai đoạn cao điểm, và chỉ ra rõ một chỉ số cụ thể: CloudWatch cho thấy CPU utilization gần chạm 100%. Câu hỏi là nên làm gì để xử lý.

Cụm từ quyết định đáp án chính là "CPU utilization was reaching close to 100%". Đây không phải triệu chứng mơ hồ kiểu "database chậm" — nó chỉ đích danh tài nguyên đang cạn: CPU của chính instance. Khi nút thắt là tài nguyên tính toán của node database, thứ cần thay đổi là kích thước của node đó, chứ không phải thêm một lớp cache ở tầng khác hay bật một tính năng thiên về tính sẵn sàng.

Cụm phụ trợ thứ hai cần để ý: đề nói "database queries were running more slowly" nhưng không phân biệt read hay write, và trong bốn phương án cũng không có Read Replica. Vì vậy hướng "scale reads" không có chỗ để bấu víu — chỉ còn hướng scale vertically.

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

A — Modify the RDS MySQL instance so it is a larger instance type.

Đây chính là scale vertically: đổi instance class của RDS sang loại lớn hơn để có thêm vCPU và RAM. Vì nút thắt được CloudWatch chỉ ra là CPU, tăng số vCPU tác động thẳng vào đúng chỗ đang nghẽn — các query sẽ có thêm năng lực xử lý và thời gian phản hồi cải thiện.

Giải thích gốc của đề nhấn mạnh thêm một điểm quan trọng: về nguyên tắc có hai cách mở rộng năng lực của database. Cách thứ nhất là dùng Read Replica để phân tán tải đọc — nhiều khả năng đó là giải pháp hợp nhất cho tình huống này, nhưng nó không được đưa ra trong danh sách phương án. Cách thứ hai, và là cách duy nhất còn lại ở đây, là đổi sang instance type lớn hơn.

Ngoài ra, thao tác này là một thay đổi cấu hình có sẵn của RDS — không phải viết lại kiến trúc ứng dụng — nên nó là hành động trực tiếp và khả thi nhất mà một SysOps Administrator có thể làm với dữ kiện đề cho.

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

B — Configure Amazon CloudFront to cache database queries and reduce load on RDS.

Sai về bản chất kiến trúc. CloudFront là CDN, nó đặt trước application server hoặc ELB để cache nội dung như ảnh, video, file tĩnh — nó không đứng trước một database và không cache được kết quả truy vấn SQL. RDS không nói giao thức HTTP mà CloudFront phục vụ. Đây là phương án nghe có vẻ "giảm tải" nhưng đặt sai tầng hoàn toàn.

C — Enable the Multi-AZ feature for the RDS instance to enable extra capacity.

Đây là phương án gần đúng nhất và cũng là bẫy chính của câu. Multi-AZ đúng là tạo thêm một bản sao của database, nên rất dễ nghĩ rằng "có thêm một node là có thêm capacity". Nhưng chỗ nó hỏng nằm ở mục đích của tính năng: Multi-AZ là cơ chế high availability / disaster recovery. Bản standby là bản replicated của primary, dùng để failover khi primary gặp sự cố — nó không phục vụ traffic đọc hay ghi của ứng dụng. Bật Multi-AZ không hề làm giảm CPU utilization trên node đang gánh 100%.

Lưu ý phân biệt: thứ dùng để phục vụ tải đọc là Read Replica, không phải standby của Multi-AZ. Hai khái niệm này khác nhau về mục đích dù nghe đều là "bản sao".

D — Scale horizontally by adding additional RDS MySQL nodes to offload write requests.

Sai vì mô tả một việc RDS không làm được. Trong RDS MySQL, chỉ có duy nhất một node ghi được — kể cả khi đã triển khai Multi-AZ. Bạn không thể thêm node để chia tải ghi. Write chỉ scale theo chiều dọc, tức là quay về đúng phương án A. Phương án này dùng đúng thuật ngữ ("scale horizontally") nhưng gán cho nó một khả năng không tồn tại.

📌 Điểm cần nhớ

• CPU utilization gần 100% trên RDS ⇒ scale vertically, tức đổi sang instance class lớn hơn. Chỉ số CloudWatch trong đề thường chính là manh mối chỉ đích danh tài nguyên nghẽn — bám vào nó.
• Multi-AZ ≠ thêm capacity. Multi-AZ phục vụ high availability và failover; standby không nhận traffic. Muốn chia tải đọc thì phải là Read Replica. Đề nào đưa Multi-AZ ra như một cách tăng hiệu năng thì gần như chắc chắn đó là bẫy.
• Write không scale ngang được trên RDS MySQL: luôn chỉ một node writable. Read scale ngang bằng Read Replica, write chỉ scale dọc bằng instance type lớn hơn.
• CloudFront là CDN đặt trước tầng ứng dụng/ELB, không đặt trước database và không cache query. Gặp phương án ghép một dịch vụ đúng vào sai tầng kiến trúc thì loại ngay.
• Khi giải pháp "lý tưởng" không có trong danh sách (ở đây là Read Replica), hãy chọn phương án tốt nhất trong bốn lựa chọn được cho, đừng loại hết vì thiếu đáp án mình mong đợi.

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

Đề mô tả một stack CloudFormation tạo Auto Scaling group, mỗi EC2 instance được cấu hình bằng user data script nằm trong launch template. Stack fail khi tạo Auto Scaling group, và câu chốt vấn đề là:

"The wait condition is not receiving the required number of signals"

Đây chính là cụm từ quyết định. Nó không nói instance không khởi động được, không nói ứng dụng lỗi, không nói thiếu dung lượng — nó nói CloudFormation không nhận đủ số tín hiệu (signal) mà wait condition / CreationPolicy đang chờ.

Cơ chế ở đây: khi một resource có wait condition hoặc CreationPolicy, CloudFormation không tự coi resource là CREATE_COMPLETE khi EC2 chạy. Nó dừng lại chờ đủ N tín hiệu thành công gửi ngược về, trong một khoảng timeout. Ai gửi tín hiệu đó? Chính instance, ở cuối user data script, bằng cfn-signal. Không ai gửi → hết timeout → resource fail. Vậy câu hỏi thực chất là: "phía nào chịu trách nhiệm phát tín hiệu, và nó đã được gọi chưa?"

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

D — Gọi cfn-signal ở cuối user data script.

cfn-signal là helper script của CloudFormation, được gọi từ trong user data để báo về rằng instance đã đạt tới trạng thái mong muốn. Nó là mảnh còn thiếu duy nhất khớp với triệu chứng "không nhận đủ số signal": wait condition đang chờ tín hiệu, mà trong user data không hề có lệnh nào phát tín hiệu.

Đặt ở cuối script cũng có ý nghĩa: tín hiệu chỉ nên gửi sau khi mọi bước cài đặt đã xong, để CloudFormation coi resource là hoàn tất đúng lúc phần cấu hình thật sự sẵn sàng. Gọi sớm thì stack báo thành công trong khi instance chưa cấu hình xong.

cfn-signal cũng gửi được cả tín hiệu thất bại, nên khi resource fail bạn còn xem log để lần ra nguyên nhân — nhưng ở câu này, tình huống là không có tín hiệu nào cả.

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

A — Giảm desired count của Auto Scaling group. Phương án này bám vào chữ "required number of signals" và tưởng rằng cứ giảm số instance thì số signal cần cũng giảm theo, nên sẽ đủ. Nhưng vấn đề không nằm ở bao nhiêu, mà ở chỗ không instance nào gửi signal cả. Cần 1 hay cần 5 thì đều nhận được 0. Giảm số lượng chỉ khiến stack fail chậm hơn chứ không sửa được nguyên nhân.

B — Đặt AssignPublicIp = True trong launch template. Đây là phương án gần đúng nhất và đáng nói kỹ. Nó xuất phát từ một suy luận hợp lý: cfn-signal gọi ra endpoint của CloudFormation, nên instance phải có đường ra ngoài. Chỗ hỏng là public IP không phải cách duy nhất để instance có đường ra — instance nằm trong private subnet đi qua NAT device vẫn gọi được bình thường. Quan trọng hơn: dù có IP public hay không thì signal cũng chỉ được gửi khi có lệnh gửi trong user data. Sửa đường mạng cho một lệnh chưa từng được gọi thì không giải quyết gì.

C — Sửa security group cho phép outbound qua port 8080. Sai ở hai tầng. Thứ nhất, cfn-signal liên lạc với CloudFormation qua HTTPS, không phải port 8080 — con số 8080 ở đây là thứ gây nhiễu, không dính gì tới cơ chế signal. Thứ hai, security group của EC2 theo mặc định cho phép toàn bộ traffic đi ra, nên outbound thường không phải là thứ chặn signal. Cả hai lý do đều dẫn tới cùng kết luận: đây không phải nguyên nhân.

📌 Điểm cần nhớ

• Thấy cụm "wait condition is not receiving signals" hoặc "CreationPolicy timeout" trong đề CloudFormation → nghĩ ngay tới cfn-signal trong user data, đừng đi tìm lỗi mạng.
• Resource có wait condition / CreationPolicy không tự chuyển sang CREATE_COMPLETE khi EC2 chạy; nó chờ tín hiệu do chính instance chủ động gửi.
• cfn-signal phải nằm ở cuối user data script, sau khi cấu hình xong — gọi sớm là báo thành công giả.
• Phân biệt "không có ai gửi" với "gửi được nhưng bị chặn": các phương án về public IP, security group, hay số lượng instance đều giả định tín hiệu đã tồn tại. Khi user data hoàn toàn không có lệnh signal, mọi cách sửa đường truyền đều vô nghĩa.
• Security group của EC2 mặc định mở outbound, nên "thêm rule outbound" hiếm khi là đáp án cho các câu về kết nối đi ra.

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

Đề mô tả một fleet EC2 chạy Linux, vá hệ điều hành theo lịch bằng AWS Systems Manager Patch Manager, và người dùng than phiền ứng dụng phản hồi chậm trong lúc đang vá. Câu hỏi: làm sao để patch vẫn được triển khai tự động mà ảnh hưởng tới khách hàng là ít nhất.

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

• "patched … using AWS Systems Manager Patch Manager" — công cụ đã được chốt sẵn. Đáp án phải nằm trong khả năng của Patch Manager, không phải đổi sang cơ chế khác.
• "deployed automatically" — loại mọi phương án cần thao tác tay.
• "MINIMAL customer impact" — nguyên nhân gốc là quá nhiều instance bị vá cùng lúc, làm tụt số instance còn phục vụ được. Thứ cần chỉnh là tốc độ triển khai (rate control) trong maintenance window, chứ không phải lịch hay ảnh máy.

Nói gọn: đề đang hỏi về concurrency của việc vá, không hỏi về cách tạo image hay cách chia nhóm.

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

B — Cấu hình maintenance window để mỗi lần chỉ vá 10% số instance trong patch group.

Patch Manager chạy công việc vá thông qua maintenance window, và maintenance window có tuỳ chọn rate control: giới hạn số target được xử lý đồng thời (khai theo số tuyệt đối hoặc theo phần trăm), kèm ngưỡng lỗi cho phép. Đặt mức đồng thời ở 10% nghĩa là tại mọi thời điểm chỉ một phần nhỏ fleet đang bận vá và có thể đang khởi động lại, còn khoảng 90% vẫn nhận traffic bình thường — đúng định nghĩa "rolling patch".

Đáp án này thoả cả hai ràng buộc cùng lúc: vẫn hoàn toàn tự động (vẫn là Patch Manager chạy theo lịch, không ai phải bấm gì), và giảm ảnh hưởng trực tiếp bằng cách hạ số instance bị rút khỏi vòng phục vụ tại một thời điểm. Đây là nút chỉnh đúng chỗ đau mà đề mô tả.

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

A — Tạo AMI đã vá sẵn, rồi cấu hình maintenance window triển khai AMI đó cho 10% fleet mỗi lượt. Sai ở chỗ hiểu nhầm bản chất Patch Manager: nó cài bản vá lên instance đang chạy, chứ không thay thế AMI cho instance. Việc thay máy bằng AMI mới thuộc về quy trình khác (dựng instance mới từ image rồi luân chuyển), không phải một tuỳ chọn có sẵn của maintenance window trong Patch Manager. Phần "10% mỗi lượt" nghe rất giống đáp án đúng, nhưng vế đầu đã mô tả một hành vi mà công cụ trong đề không làm được — đó chính là chỗ hỏng.

C — Dùng nhiều patch group riêng và cập nhật các group vào những thời điểm khác nhau. Đây là phương án gần đúng nhất và cũng dễ chọn nhầm nhất. Chia group rồi lệch giờ đúng là có giãn bớt việc vá theo trục thời gian, và vẫn tự động. Nhưng nó không hề giới hạn số instance được vá đồng thời bên trong mỗi group: nếu một group có 100 máy thì tới giờ của group đó, cả 100 máy vẫn có thể bị vá cùng lúc và người dùng vẫn gặp đúng triệu chứng cũ. Muốn C thật sự hiệu quả thì vẫn phải đặt thêm rate control — tức là vẫn phải làm chính việc mà B đã làm. B giải quyết trực tiếp nguyên nhân, C chỉ dời nó đi.

D — Cập nhật từng instance một, dùng snapshot của một AMI đã vá. Hỏng ở hai điểm. Thứ nhất, "one at a time" theo cách thủ công không phải giải pháp tự động, trái thẳng với yêu cầu "deployed automatically". Thứ hai, thay thế máy bằng ảnh đã vá chỉ khả thi khi ứng dụng stateless hoặc lưu state ở volume tách khỏi ổ hệ điều hành — đề không cho biết điều đó, nên đây là giả định không có căn cứ. Ngoài ra, dựng lại từng máy một cho cả fleet thì thời gian vá kéo dài lê thê so với vá tại chỗ.

📌 Điểm cần nhớ

• Với Patch Manager, nút chỉnh để giảm ảnh hưởng khi vá là rate control trong maintenance window (số hoặc phần trăm target chạy đồng thời), không phải đổi lịch hay đổi image.
• Phân biệt rõ hai khái niệm hay bị trộn: patch group quyết định máy nào nhận patch baseline nào, còn maintenance window quyết định khi nào và bao nhiêu máy một lúc. Đề hỏi "cùng lúc bao nhiêu" thì đáp án nằm ở maintenance window.
• Patch Manager vá instance đang chạy tại chỗ, nó không thay AMI — mọi phương án mô tả Patch Manager triển khai AMI đều sai bản chất, dù phần còn lại nghe hợp lý.
• Gặp từ khoá "automatically" trong đề thì loại ngay mọi phương án có thao tác tay; gặp "MINIMAL impact" thì tìm phương án hạ mức đồng thời, vì đó mới là thứ quyết định còn bao nhiêu máy phục vụ được trong lúc bảo trì.

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

Đề mô tả một S3 bucket đặt ở us-east-1, còn người dùng thì ngồi ở ap-south-1 và truy cập qua Internet. Yêu cầu là tăng tốc độ truyền các tệp lớn theo cả hai chiều (upload lên bucket và download từ bucket).

Cụm từ quyết định đáp án nằm ở ba chỗ chồng lên nhau:

• "users located in ap-south-1 ... interact via the internet" — khoảng cách địa lý xa và đường đi là Internet công cộng. Đây là bài toán độ trễ và chất lượng đường truyền, không phải bài toán mã hoá hay cách đặt tên object.
• "transferring large files to and from" — hai chiều, và là tệp lớn. Cái cần cải thiện là thông lượng đường truyền đường dài, không phải số lượng request mỗi giây.
• Bucket vẫn ở us-east-1 — đề không nói được phép di chuyển hay nhân bản dữ liệu sang region khác, nên giải pháp phải giữ nguyên chỗ chứa dữ liệu.

Gộp lại: cần một cơ chế rút ngắn chặng Internet công cộng mà không đụng tới vị trí bucket.

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

Đáp án theo tệp là C — bật S3 Transfer Acceleration và truy cập bằng endpoint s3-accelerate.

S3 Transfer Acceleration tận dụng mạng lưới edge location của CloudFront trải khắp toàn cầu. Thay vì client ở ap-south-1 phải kéo dữ liệu suốt chặng Internet công cộng tới us-east-1, dữ liệu đi vào edge location gần nhất trước, rồi từ đó chạy tiếp tới Amazon S3 qua đường mạng nội bộ đã được tối ưu của AWS. Chặng Internet công cộng — chặng khó đoán nhất, hay mất gói và biến động độ trễ nhất — bị rút ngắn xuống còn đoạn từ người dùng tới edge gần họ.

Đúng ba điều kiện đề nêu:

• Áp dụng cho cả upload lẫn download, khớp với "to and from".
• Lợi ích rõ nhất với tệp lớn truyền đường dài, đúng kịch bản us-east-1 ↔ ap-south-1.
• Bucket vẫn nằm nguyên ở us-east-1, không phải di chuyển hay sao chép dữ liệu.

Chi tiết đáng chú ý trong phương án: nó nêu rõ phải dùng endpoint mới s3-accelerate. Bật tính năng ở cấp bucket thôi chưa đủ — client vẫn gọi vào endpoint S3 thường thì lưu lượng vẫn đi đường cũ và không có gì nhanh lên. Phần "use the new endpoint's domain name" chính là mảnh ghép làm phương án này hoàn chỉnh.

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

A — Đổi server-side encryption từ AES sang RSA. Nhầm lẫn giữa hai phạm trù khác hẳn nhau: AES và RSA là thuật toán bảo mật dữ liệu, không phải nút chỉnh hiệu năng đường truyền. Đổi cách mã hoá dữ liệu lúc lưu (at rest) không làm gói tin đi từ ap-south-1 tới us-east-1 nhanh hơn chút nào. Tệ hơn, xét về bản chất thuật toán thì AES là mã hoá đối xứng, nhanh và hiệu quả hơn hẳn RSA khi xử lý khối lượng dữ liệu lớn — nên nếu thay được thật thì hướng đi còn là chậm hơn, không phải nhanh hơn.

B — Tạo bucket mới trùng tên ở ap-south-1 rồi dùng endpoint mới. Đây là phương án gần đúng nhất về mặt trực giác: đưa dữ liệu tới gần người dùng đúng là một hướng hợp lý. Nhưng nó hỏng ở hai chỗ:

1. Tên bucket S3 là duy nhất trên toàn cầu, không phân theo region và không phân theo tài khoản. Không thể tạo một bucket "identical name" ở ap-south-1 khi tên đó đã bị bucket ở us-east-1 chiếm. Phương án chết ngay ở bước đầu tiên.
2. Kể cả giả sử đặt được tên khác, tạo bucket rỗng không tự mang dữ liệu sang. Bucket mới sẽ trống trơn; muốn có dữ liệu ở đó phải thiết lập cơ chế nhân bản hoặc sao chép riêng — đề không nhắc gì tới việc đó, và người dùng trỏ vào bucket mới sẽ không tìm thấy tệp nào.

D — Giảm bớt prefix trong bucket. Prefix liên quan tới cách S3 phân vùng và scale số request mỗi giây, tức là bài toán tần suất thao tác, không phải bài toán tốc độ truyền một tệp lớn qua khoảng cách địa lý xa. Vấn đề trong đề là độ trễ và thông lượng của chặng đường mạng, còn prefix thì không đụng gì tới chặng đó. Ngoài ra hướng tối ưu prefix theo thông lệ là trải rộng prefix ra để phân tán tải, chứ không phải gom lại — nên phương án này vừa sai chủ đề vừa sai chiều.

📌 Điểm cần nhớ

• Thấy đề nêu người dùng ở xa region của bucket + truyền tệp lớn qua Internet + không được đổi chỗ dữ liệu → nghĩ ngay tới S3 Transfer Acceleration. Nó rút ngắn chặng Internet công cộng bằng edge location của CloudFront rồi đi tiếp qua mạng nội bộ AWS.
• Bật Transfer Acceleration phải đi kèm việc client chuyển sang endpoint s3-accelerate. Bật ở bucket mà vẫn gọi endpoint cũ thì không có tác dụng gì — đây là chi tiết hay bị cắt bớt trong các phương án gài bẫy.
• Tên bucket S3 là duy nhất toàn cầu. Bất kỳ phương án nào bảo "tạo bucket trùng tên ở region khác" đều loại được ngay, không cần đọc tiếp phần sau.
• Phân biệt rõ ba nhóm nút chỉnh của S3: mã hoá cho bảo mật, prefix cho khả năng scale số request mỗi giây, Transfer Acceleration / vị trí dữ liệu cho tốc độ truyền đường dài. Đề hỏi nhóm nào thì chỉ nhóm đó mới là đáp án.

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

Đề mô tả một ứng dụng chạy trên Amazon EC2 instance, xử lý dữ liệu rồi ghi log lên một Amazon S3 bucket. Nhiệm vụ của SysOps Administrator là cho phép instance đó truy cập bucket.

Cụm từ quyết định nằm ở câu hỏi cuối: "How can this be configured for optimum security?" — optimum security, tức là bảo mật tối ưu. Đây không phải câu hỏi "cách nào chạy được", vì thực tế cả bốn phương án đều có thể làm cho ứng dụng đọc/ghi được S3 theo cách này hay cách khác. Ràng buộc phân biệt là cách nào cấp quyền mà không phải phân phát và tự quản lý long-term credentials, đồng thời không mở quyền rộng hơn mức cần.

Chi tiết thứ hai cũng quan trọng: chủ thể cần quyền là một EC2 instance, không phải một con người. Khi đối tượng cần quyền là workload chạy trên AWS chứ không phải người dùng, mô hình đúng luôn là IAM role gắn vào workload đó.

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

Đáp án đúng theo tệp là D — Create an IAM role for Amazon S3 access and attach it to the EC2 instance.

Ứng dụng chạy trên EC2 vẫn phải ký các request tới AWS API bằng credentials. Có hai cách để credentials tới được instance: hoặc developer tự nhét credentials vào instance, hoặc để AWS cấp.

IAM role gắn vào EC2 instance đi theo cách thứ hai: role cung cấp temporary credentials cho ứng dụng chạy trên instance đó. Bạn chỉ định IAM role lúc launch instance (hoặc gắn sau), và ứng dụng bên trong dùng credentials tạm thời do role cấp để ký request tới S3.

Điểm được lợi về bảo mật:

• Không phải phân phát long-term credentials (username/password hay access key) tới từng instance. Không có bí mật dài hạn nằm trên đĩa để rò rỉ.
• Không phải tự lo chuyện xoay vòng (rotate) credentials. Nếu tự lưu access key, developer phải truyền key an toàn tới mọi instance và cập nhật lại từng instance mỗi khi tới kỳ rotate — theo đúng lời giải thích gốc, "that's a lot of additional work".
• Quyền được viết trong policy của role nên giới hạn đúng vào S3 access mà ứng dụng cần, đúng tinh thần least privilege.

Đây là best practice của AWS cho trường hợp ứng dụng trên EC2 cần gọi dịch vụ AWS khác — chính là tình huống của đề.

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

A. Apply an S3 bucket policy to allow access from all EC2 instances. Đây là phương án gần đúng nhất về mặt "chạy được": bucket policy đúng là một cách cấp quyền hợp lệ trên S3. Nhưng nó hỏng ở chỗ phạm vi: cho phép truy cập từ all EC2 instances nghĩa là mở bucket cho rất nhiều instance chứ không chỉ instance đang cần. Đề hỏi optimum security, mà cấp quyền rộng hơn mức cần thiết thì ngược hẳn với least privilege. Một instance bất kỳ bị chiếm quyền cũng chạm được vào log files.

B. Store access keys in an Amazon Machine Image (AMI). Đây chính là kiểu "nhét long-term credentials vào instance" mà IAM role sinh ra để thay thế. Nhúng access key vào AMI còn tệ hơn nhúng vào một instance đơn lẻ: mọi instance launch từ AMI đó đều mang cùng một cặp key, và key nằm lại trong image. Muốn rotate key thì phải dựng AMI mới và thay toàn bộ instance. Nó có thể chạy được, nhưng không phải giải pháp bảo mật nhất — dùng role mới là best practice.

C. Create an IAM user and delegate access to the EC2 instance. Nghe hợp lý vì IAM user cũng là một identity có policy gắn vào, nhưng nó hỏng ở đúng chữ "delegate": bạn không delegate được bằng IAM user account. Delegation trong IAM là cơ chế của role — role có trust policy nói ai được assume nó, còn IAM user thì không có khái niệm đó và cũng không "gắn" được vào một EC2 instance. Trên thực tế, cách duy nhất để một IAM user cấp quyền cho ứng dụng trên EC2 là sinh access key của user đó rồi copy vào instance — tức là quay lại đúng vấn đề long-term credentials của phương án B.

📌 Điểm cần nhớ

• Khi đề nói một workload chạy trên AWS (EC2, Lambda, ECS…) cần gọi dịch vụ AWS khác, đáp án gần như luôn là IAM role gắn vào workload đó, không phải IAM user, không phải access key.
• Giá trị cốt lõi của IAM role là temporary credentials: không phân phát bí mật dài hạn, không phải tự xây quy trình rotate.
• Thấy phương án có chữ access key được lưu ở đâu đó (AMI, file cấu hình, biến môi trường, source code) thì loại — đó là dấu hiệu kinh điển của đáp án sai trong các câu hỏi về bảo mật.
• Trong hai phương án đều "chạy được", hãy chọn theo least privilege: cụm từ kiểu all instances, all users, ""* cho thấy phạm vi quá rộng và loại phương án đó khỏi mục "optimum security".
• Delegation là đặc quyền của role, không phải của user — nhớ điều này để loại nhanh các phương án ghép "IAM user + delegate".

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

Đề mô tả một tình huống rất cụ thể: dữ liệu được chuyển từ thiết bị WORM sang một S3 bucket đã bật S3 Object Lock ở governance mode, trong quá trình đó lọt vào một mớ dữ liệu thừa. SysOps administrator dùng AWS CLI để xoá nhưng bị lỗi. Câu hỏi yêu cầu chọn hai việc phải làm để xoá được.

Cụm từ quyết định là "governance mode". Object Lock có hai chế độ, và chúng khác nhau ở đúng một điểm mấu chốt: governance mode cho phép phá rào nếu người gọi có quyền đặc biệt và nói rõ ý định phá rào; compliance mode thì không ai phá được, kể cả tài khoản root, cho tới khi hết hạn giữ. Đề đã đặt sẵn governance mode, nghĩa là đề đang hỏi về đúng cơ chế bypass đó.

Cụm thứ hai đáng chú ý: "(Select TWO)" kết hợp với việc thao tác thực hiện qua AWS CLI. Cơ chế bypass của Object Lock không tự động — nó đòi hỏi hai vế tách rời nhau: một vế quyền IAM, một vế tín hiệu trong chính request. Có quyền mà không khai báo thì vẫn bị chặn; khai báo mà không có quyền thì bị từ chối. Chính vì hai vế này mà câu hỏi chọn được đúng hai đáp án.

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

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

A — Assume a role có quyền s3:BypassGovernanceRetention. Ở governance mode, S3 chặn ghi đè và xoá mọi phiên bản object đang trong thời gian giữ, trừ khi người gọi có quyền đặc biệt. Quyền đó chính là s3:BypassGovernanceRetention. Đây là vế "được phép" — không có nó thì mọi lệnh xoá đều trả về lỗi từ chối truy cập, bất kể gọi bằng CLI, SDK hay console.

B — Thêm header x-amz-bypass-governance-retention:true vào request xoá. Đây là vế "cố ý". AWS bắt người gọi phải tuyên bố tường minh rằng mình muốn vượt rào bảo vệ, chứ không mặc định vượt chỉ vì có quyền. Với API thì đó là header nói trên; với AWS CLI và các SDK thì dùng tham số tương đương. Thiết kế này tránh việc một người có quyền cao vô tình xoá mất dữ liệu đang được giữ.

Hai bước cộng lại — có quyền, và nói rõ ý định — là đúng cái mà tình huống trong đề cần.

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

C — Đổi Object Lock từ governance mode sang compliance mode. Đây là phương án đi ngược hẳn mục tiêu. Compliance mode là chế độ chặt hơn: phiên bản object được bảo vệ thì không người dùng nào ghi đè hay xoá được trong thời gian giữ, kể cả root, và cũng không có cơ chế bypass nào. Chọn C là tự tay khoá vĩnh viễn đúng đống dữ liệu thừa mà mình đang muốn dọn.

D — Assume a role có quyền s3:PutObjectRetention. Đây là phương án gần đúng nhất và là bẫy chính của câu này, vì nó cũng là một quyền liên quan tới Object Lock, cũng ở dạng "assume a role" giống A. Nhưng s3:PutObjectRetention chỉ cho phép đặt hoặc chỉnh cấu hình retention trên object. Nó không phải là quyền vượt rào governance mode, nên tự nó không mở đường cho lệnh xoá. Chỗ nó hỏng: nhầm "được sửa thiết lập giữ" với "được xoá bất chấp thiết lập giữ" — hai việc khác nhau, và AWS tách chúng thành hai quyền riêng đúng vì lý do đó.

E — Kéo dài Retain Until Date cho dữ liệu bị ảnh hưởng. Retain Until Date là mốc thời gian object còn bị khoá. Kéo dài mốc này làm dữ liệu được bảo vệ lâu hơn, tức là khoảng thời gian không xoá được kéo dài thêm — hoàn toàn trái với việc cần làm. Phương án này chỉ hợp lý nếu đề hỏi "làm sao giữ dữ liệu lâu hơn", không phải "làm sao xoá".

📌 Điểm cần nhớ

• Governance mode = có thể vượt rào; compliance mode = không ai vượt được. Đề nhắc chế độ nào là gợi ý trực tiếp cho đáp án; thấy "compliance" thì mọi phương án kiểu "xoá bằng quyền cao hơn" đều sai.
• Bypass governance cần đủ hai vế: quyền s3:BypassGovernanceRetention và khai báo tường minh trong request (header x-amz-bypass-governance-retention:true, hoặc tham số tương đương của CLI/SDK). Câu "Select TWO" quanh Object Lock thường chính là hai vế này.
• Phân biệt các quyền na ná nhau: s3:PutObjectRetention để chỉnh thiết lập giữ, s3:BypassGovernanceRetention để xoá/ghi đè bất chấp thiết lập giữ. Tên gần giống nhưng phạm vi khác hẳn.
• Cẩn thận phương án siết chặt thêm khi đề đang cần nới lỏng. Đổi sang compliance mode hay kéo dài Retain Until Date đều là thao tác tăng mức bảo vệ, không thể là lời giải cho một câu hỏi về xoá dữ liệu.