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

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

Đề mô tả một quản trị viên đã tạo xong các identity-based policy và giờ chuyển sang tạo resource-based policy. Câu hỏi chốt lại: "Which is the only resource-based policy that the IAM service supports?"

Cụm từ quyết định là "the only resource-based policy that the IAM service supports" — có hai ràng buộc chồng lên nhau:

1. resource-based policy — loại policy gắn trực tiếp lên tài nguyên, trong đó có phần Principal chỉ rõ ai được phép. Điều này loại ngay mọi thứ thuộc nhóm identity-based hoặc nhóm "hàng rào giới hạn quyền".
2. của chính IAM service — không phải resource-based policy nói chung. S3 bucket policy, SQS queue policy, KMS key policy đều là resource-based policy, nhưng chúng thuộc dịch vụ khác. Trong phạm vi bản thân IAM, chỉ có đúng một loại.

Ai chỉ đọc lướt "resource-based policy" mà bỏ qua "IAM service supports" sẽ dễ bị các phương án IAM-nghe-quen kéo đi.

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

Đáp án đúng theo tệp là A – Trust policy.

IAM role vừa là một identity, vừa là một resource. Vì là identity nên nó nhận identity-based policy (permissions policy) để quyết định role đó làm được gì. Vì là resource nên nó nhận thêm một resource-based policy — chính là role trust policy — quyết định ai được phép assume role đó.

Trust policy có đầy đủ đặc điểm của một resource-based policy: là JSON document gắn thẳng vào tài nguyên (role), và có phần Principal liệt kê các thực thể được tin cậy — AWS account, IAM user, IAM role, service principal, hay federated user — kèm điều kiện áp dụng. Đây là lý do khi tạo role bạn luôn phải khai hai thứ: trust policy (ai vào được) và permissions policy (vào rồi làm gì).

Và đúng như đề nhấn mạnh, role trust policy là loại resource-based policy duy nhất mà bản thân IAM hỗ trợ.

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

B – Permissions boundary. Đây là phương án gần đúng nhất vì nó cũng gắn vào một IAM entity (user hoặc role). Nhưng nó hỏng ở chỗ: permissions boundary dùng một managed policy để đặt trần quyền tối đa mà identity-based policy có thể cấp cho entity đó — quyền thực tế là phần giao của identity-based policy và boundary. Nó không có Principal, không cấp quyền cho ai cả, chỉ giới hạn. Đó là một tính năng nâng cao của identity-based policy, không phải resource-based policy.

C – Access control list (ACL). ACL đúng là kiểu policy gắn lên tài nguyên và kiểm soát principal ở account khác truy cập tài nguyên. Nhưng nó hỏng ở hai điểm với câu này: ACL không kiểm soát được principal trong cùng account, và quan trọng hơn — nó thuộc về các dịch vụ như Amazon S3, AWS WAF, Amazon VPC, không phải IAM. ACL cũng không dùng cú pháp JSON policy như các loại còn lại.

D – AWS Organizations Service Control Policies (SCP). SCP là JSON policy, nghe rất giống, nhưng thuộc AWS Organizations chứ không phải IAM, và nó không gắn vào tài nguyên — nó gắn vào account hoặc organizational unit (OU). Vai trò của SCP là đặt trần quyền tối đa cho mọi entity trong member account, kể cả root user của account đó; một Deny tường minh trong SCP ghi đè mọi Allow. Cũng là hàng rào giới hạn, không phải policy cấp quyền gắn trên resource.

📌 Điểm cần nhớ

• Dấu hiệu nhận diện resource-based policy: có phần Principal. Policy nào không khai principal (permissions boundary, SCP, identity-based policy) thì không phải resource-based policy.
• IAM role là ngoại lệ "hai vai" — vừa identity vừa resource — nên luôn cần cả trust policy lẫn permissions policy. Đây là lý do IAM có được một resource-based policy duy nhất.
• Phân biệt "cấp quyền" với "đặt trần quyền". Permissions boundary và SCP đều chỉ giới hạn quyền tối đa, không tự cấp quyền cho ai; quyền thực tế là phần giao giữa chúng và policy cấp quyền.
• Đọc kỹ chủ ngữ của câu hỏi. "Resource-based policy" nói chung có rất nhiều (S3 bucket policy, KMS key policy…), nhưng khi đề giới hạn "mà IAM service hỗ trợ" thì đáp án chỉ còn trust policy.

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

Đề mô tả một công ty bán lẻ đa quốc gia dùng AWS Organizations. CloudTrail đã bật ở các member account, nhưng việc truy cập log CloudTrail rải rác qua nhiều tài khoản và nhiều Region đang làm chậm quá trình xử lý sự cố. Họ quyết định chuyển sang dùng organization trail.

Câu hỏi không hỏi "chọn giải pháp nào" mà hỏi "những điểm quan trọng cần nhớ khi cấu hình organization trail" — tức là một câu kiểm tra kiến thức thực tế, chọn hai phát biểu đúng trong năm phát biểu về CloudTrail nói chung và organization trail nói riêng.

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

• "(Select two)" — phải chọn đủ hai, và trong danh sách có những phát biểu gần đúng cố tình đặt cạnh phát biểu đúng để đánh lừa.
• "organization trail" — mọi phát biểu phủ nhận sự tồn tại của khái niệm này, hoặc mô tả sai quyền của member account đối với nó, đều sai.

Vì đây là câu "chọn phát biểu đúng", cách làm là xét tính đúng/sai của từng mệnh đề một cách độc lập, không so sánh chúng với nhau.

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

B — "By default, CloudTrail tracks only bucket-level actions. To track object-level actions, you need to enable Amazon S3 data events"

CloudTrail chia sự kiện thành hai loại. Management events (còn gọi là sự kiện mức bucket với S3) là các thao tác quản trị lên chính bucket — tạo bucket, đổi policy, đổi cấu hình — và được ghi mặc định. Data events là các thao tác lên object bên trong bucket (GetObject, PutObject, DeleteObject), khối lượng rất lớn nên không bật mặc định; muốn có thì phải bật S3 data events cho trail. Khi đã bật, CloudTrail ghi lại chi tiết từng lời gọi API trên object: tài khoản gọi, IAM role, thời điểm, địa chỉ IP nguồn… và đẩy sang S3 cùng CloudWatch Events để xử lý tự động.

E — "Member accounts will be able to see the organization trail, but cannot modify or delete it"

Organization trail phải được tạo từ master (management) account. Khi đánh dấu trail đó áp dụng cho cả organization, nó tự động được áp xuống mọi member account — đúng thứ mà đề bài đang cần, vì nhờ vậy log của mọi division và mọi Region được gom về một chỗ. Ở phía member account, trail này hiển thị được nhưng ở trạng thái chỉ đọc: không sửa cấu hình, không xoá, không tắt. Đây chính là điểm mấu chốt cần nhớ — quyền quản lý nằm trọn ở master account, member chỉ nhìn thấy trail đang tồn tại.

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

A — "Member accounts do not have access to organization trail, neither do they have access to the Amazon S3 bucket that logs the files"

Đây là phương án gần đúng nhất và cũng nguy hiểm nhất, vì nửa sau của nó đúng: theo mặc định, member account không có quyền đọc file log trong S3 bucket của organization trail. Nhưng nửa đầu sai — member account vẫn nhìn thấy organization trail trong tài khoản của mình, chỉ là không sửa/xoá được. Một mệnh đề chỉ đúng một nửa thì vẫn là mệnh đề sai. So sánh A với E sẽ thấy chúng cố ý đối lập nhau ở đúng chi tiết "có thấy trail hay không" — đó là chỗ phân biệt.

C — "By default, CloudTrail event log files are not encrypted"

Ngược hoàn toàn với thực tế. File log của CloudTrail khi đưa vào S3 được mã hoá mặc định bằng server-side encryption của S3 (SSE). Người dùng có thể nâng lên mã hoá bằng khoá KMS do mình quản lý nếu muốn kiểm soát chặt hơn, nhưng "không mã hoá" thì không đúng.

D — "There is nothing called Organization Trail. The master account can, however, enable CloudTrail logging, to keep track of all activities across AWS accounts"

Sai ngay ở mệnh đề đầu tiên: organization trail là một tính năng có thật của CloudTrail khi dùng cùng AWS Organizations, và chính đề bài cũng đang nói tới nó. Loại phương án kiểu "khái niệm này không tồn tại" thường xuất hiện để bắt người học không chắc về thuật ngữ; chỉ cần biết tính năng có thật là loại được ngay.

📌 Điểm cần nhớ

• Organization trail được tạo ở master account của AWS Organizations và tự động áp cho mọi member account; member thấy được nhưng không sửa/xoá được — đúng mô hình quản trị tập trung mà đề bài cần.
• Mặc định member account không đọc được file log trong S3 bucket của organization trail; muốn cho đọc thì phải cấp quyền tường minh trên bucket. Đừng lẫn "không thấy trail" với "không đọc được log".
• CloudTrail mặc định chỉ ghi management events; muốn theo dõi thao tác trên object trong S3 phải bật S3 data events — đây là bẫy kinh điển khi đề hỏi "vì sao không thấy log GetObject/PutObject".
• File log CloudTrail trong S3 đã được mã hoá mặc định bằng SSE; mọi phát biểu nói log không mã hoá đều sai.
• Với câu dạng "chọn phát biểu đúng", hãy xét đúng/sai từng mệnh đề độc lập, và cảnh giác với phương án đúng một nửa như A — chỉ một chi tiết sai là cả phương án sai.

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

Bối cảnh là một systems administrator viết CloudFormation template để dựng tài nguyên, và tài nguyên được provisioning "based on certain conditions". Nhưng câu hỏi thật sự nằm ở dòng cuối, và cụm từ quyết định là "does not allow for conditions" — hỏi ngược, tìm section KHÔNG dùng được condition.

Đây là kiểu câu dễ mất điểm vì đọc lướt: ba dòng đầu nói về việc dùng condition, làm người đọc theo quán tính đi tìm section dùng được condition. Ràng buộc phân biệt bốn phương án là chỗ một condition đã định nghĩa có thể được gắn vào (associate) ở đâu trong template. Câu trả lời theo tài liệu CloudFormation: chỉ ở Resources và Outputs. Bất kỳ section nào ngoài hai chỗ đó (và ngoài chính chỗ khai báo condition) đều là đáp án của câu hỏi phủ định này.

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

D — Parameters là section không cho phép dùng condition.

Parameters là nơi khai báo các giá trị đầu vào mà người chạy stack truyền vào mỗi lần create hoặc update stack. Nó nằm ở đầu chuỗi xử lý: giá trị parameter chính là nguyên liệu để CloudFormation đánh giá các condition trong section Conditions. Vì thứ tự đó, một parameter không thể phụ thuộc vào condition — nếu cho phép, ta sẽ có vòng lặp: condition cần giá trị parameter để đánh giá, mà parameter lại cần condition để biết mình có tồn tại hay không.

Đúng như phần giải thích gốc ghi rõ: "Conditions cannot be used within the Parameters section. After you define all your conditions, you can associate them with resources and resource properties only in the Resources and Outputs sections of a template."

Nói cách khác, Parameters chỉ khai báo Type, Default, AllowedValues, Description... chứ không nhận thuộc tính Condition và không dùng được Fn::If để bật/tắt chính nó.

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

A — Resources: đây chính là nơi chủ đạo dùng condition. Mỗi resource nhận được thuộc tính Condition trỏ tới tên một condition đã khai báo; condition sai thì resource không được tạo. Ngoài ra Fn::If còn dùng được ngay trong property của resource để đổi giá trị theo môi trường (ví dụ chọn instance type lớn cho prod, nhỏ cho test). Là một trong hai section được phép, nên không phải đáp án.

B — Conditions: gần đúng nhất về mặt "bẫy", vì nếu hiểu "dùng condition" là "gắn condition vào một entity để entity đó tồn tại hay không" thì section này quả thật không làm việc đó. Nhưng nó hỏng ở chỗ: Conditions là section định nghĩa condition — mọi biểu thức Fn::Equals, Fn::And, Fn::Or, Fn::Not đều nằm ở đây, và một condition còn tham chiếu được condition khác. Nói section Conditions "không cho phép condition" là mâu thuẫn với chính vai trò của nó, nên nó không thể là đáp án của câu hỏi này.

C — Outputs: cũng là section được phép. Output khai báo giá trị xuất ra để hiển thị trên console, trả về khi describe stack, hoặc export cho cross-stack reference. Mỗi output nhận thuộc tính Condition, nên có thể chỉ xuất ra một giá trị (ví dụ tên S3 bucket) khi tài nguyên tương ứng thật sự được tạo. Đây là vế thứ hai trong câu "only in the Resources and Outputs sections", nên loại.

📌 Điểm cần nhớ

• Condition trong CloudFormation chỉ được gắn vào entity ở hai section: Resources và Outputs. Nhớ đúng cặp này là giải được cả họ câu hỏi dạng "section nào dùng/không dùng được condition".
• Parameters là đầu vào, không phải đầu ra của logic điều kiện — condition đánh giá dựa trên parameter, nên parameter không thể phụ thuộc ngược lại condition.
• Section Conditions là nơi khai báo, khác hẳn với việc áp dụng condition; đừng lẫn hai vai trò này khi đề hỏi mẹo.
• Với đề hỏi phủ định (does not, except, NOT), hãy tách riêng phần bối cảnh và phần câu hỏi thật — đoạn mở đầu thường mô tả use case thuận để kéo người đọc chọn nhầm một phương án "đúng nhưng ngược ý đề".

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

Đề mô tả một ứng dụng được nhà cung cấp bên thứ ba host tại yourapp.freehosting.com, còn tên miền www.yourdomain.com thì bạn sở hữu và quản lý trong Route 53. Câu hỏi: nên tạo bản ghi Route 53 loại nào?

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

1. "hosted by a provider on yourapp.freehosting.com" — đích đến là một tên miền, không phải địa chỉ IP, và cũng không phải tài nguyên AWS. Nhà cung cấp có thể đổi IP bất cứ lúc nào mà không báo bạn.
2. www.yourdomain.com — đây là subdomain, không phải zone apex. Chi tiết này rất quan trọng vì nó mở đường cho CNAME (nếu đề hỏi yourdomain.com trần thì CNAME bị cấm theo chuẩn DNS).
3. "which you own and manage under Route 53" — bạn chỉ điều khiển được phía tên miền của mình, hoàn toàn không có quyền gì với hạ tầng của freehosting.com.

Tóm lại: ánh xạ một tên miền sang một tên miền khác không thuộc AWS, tại một subdomain.

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

B — Create a CNAME record.

CNAME (Canonical Name) là loại bản ghi ánh xạ tên của bản ghi hiện tại sang một tên miền khác, dù đó là domain khác (example.net) hay subdomain (zenith.example.org). Đúng chính xác nhu cầu của đề: www.yourdomain.com → yourapp.freehosting.com.

Ưu điểm thực tế: khi resolver truy vấn www.yourdomain.com, nó nhận về tên yourapp.freehosting.com rồi tiếp tục phân giải tên đó theo DNS của nhà cung cấp. Nhà cung cấp đổi IP thì bạn không phải sửa gì trong Route 53 — điều bắt buộc phải có khi bạn không kiểm soát hạ tầng đích.

Điều kiện cho phép dùng CNAME ở đây: bản ghi nằm ở www., tức subdomain. Giao thức DNS không cho tạo CNAME tại zone apex (node đỉnh của namespace, ở đây là yourdomain.com). Đề đã cẩn thận đặt www. nên ràng buộc này được thoả.

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

A — PTR record. PTR (Pointer) làm việc ngược chiều hoàn toàn: phân giải từ địa chỉ IP ra tên miền đầy đủ (FQDN), tức Reverse DNS. Nó dùng cho các việc như kiểm tra danh tiếng máy chủ gửi mail, chứ không phục vụ việc người dùng gõ tên miền trên trình duyệt. PTR không ánh xạ được tên miền này sang tên miền kia.

C — A record. Đây là phương án gần đúng nhất về mặt "trỏ được", nhưng hỏng ở kiểu dữ liệu đích: A record chỉ nhận địa chỉ IP, không nhận tên miền. Đề chỉ cho bạn một cái tên yourapp.freehosting.com, muốn dùng A record thì phải tự tra IP hiện tại của nó rồi hardcode vào. Hai vấn đề đi kèm: bạn không kiểm soát hạ tầng nhà cung cấp nên họ đổi IP là site chết, và các dịch vụ hosting kiểu này thường đứng sau hạ tầng chia sẻ có IP thay đổi. A record giải quyết sai bài toán mà đề đặt ra.

D — Alias record. Đây là phương án bẫy chính, vì Alias nghe như CNAME và thậm chí dùng được ở zone apex. Nhưng Alias là phần mở rộng riêng của Route 53 và chỉ trỏ tới tài nguyên AWS được chọn — CloudFront distribution, S3 bucket cấu hình static website, ELB, hoặc một bản ghi khác trong cùng hosted zone. yourapp.freehosting.com là website bên thứ ba, không phải tài nguyên AWS và bạn không có quyền gì với nó, nên nó không đủ điều kiện làm mục tiêu Alias. Alias không dùng để ánh xạ sang một tên miền tuỳ ý ngoài AWS.

📌 Điểm cần nhớ

• Phân biệt theo kiểu của đích: A record → địa chỉ IP; CNAME → tên miền bất kỳ; Alias → tài nguyên AWS được hỗ trợ hoặc bản ghi khác trong cùng hosted zone.
• Đích nằm ngoài AWS (hosting bên thứ ba, SaaS, CDN của hãng khác) thì loại ngay Alias, câu trả lời gần như luôn là CNAME.
• Zone apex là ranh giới quyết định: DNS cấm CNAME tại đỉnh zone (example.com), nhưng cho phép ở subdomain (www.example.com). Đọc kỹ đề xem có chữ www. hay không — cùng một tình huống mà thiếu www. thì đáp án đổi hẳn.
• Alias là giải pháp riêng của Route 53 sinh ra chính để lách giới hạn zone apex khi trỏ tới tài nguyên AWS; sức mạnh đó chỉ có giá trị khi đích thực sự là tài nguyên AWS.
• PTR thuộc chiều ngược (IP → tên), gần như không bao giờ là đáp án cho câu hỏi "cho người dùng truy cập bằng tên miền của tôi".

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

Một startup dùng Elastic Beanstalk để quản lý hạ tầng và muốn triển khai phiên bản ứng dụng mới lên các EC2 instance. Đề mô tả rất rõ trạng thái mong muốn trong lúc deploy: "some instances should serve requests with the old application version, while other instances should serve requests using the new application version until the deployment is completed" — tức là trong suốt quá trình triển khai, hai phiên bản cùng chạy song song trên các instance khác nhau.

Nhưng ràng buộc thật sự quyết định đáp án nằm ở câu hỏi cuối: "without incurring additional costs". Cụm này loại bỏ mọi deployment policy nào phải thêm instance mới trong lúc deploy, vì instance mới đồng nghĩa với tiền EC2 phát sinh. Vế "hai phiên bản cùng phục vụ" thì có tới ba policy thoả mãn; chỉ vế "không tốn thêm chi phí" mới cắt được xuống một.

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

D — Rolling là đáp án đúng.

Rolling triển khai phiên bản mới theo từng batch trên chính các instance đang có. Mỗi batch được rút khỏi phục vụ (out of service), cập nhật lên phiên bản mới, rồi đưa trở lại; các batch chưa tới lượt vẫn đang chạy phiên bản cũ và vẫn nhận request. Đúng như đề mô tả: một số instance phục vụ bản cũ, một số phục vụ bản mới, cho tới khi deploy xong.

Về chi phí: số lượng EC2 instance không tăng — Elastic Beanstalk tái sử dụng đúng các instance sẵn có. Cái giá phải trả là capacity giảm tạm thời đúng bằng số instance trong batch đang được cập nhật, và thời gian deploy dài hơn. Nhưng đây là đánh đổi về hiệu năng/thời gian, không phải về tiền — nên Rolling là policy duy nhất thoả cả hai điều kiện của đề.

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

A — Immutable: Policy này luôn deploy bản mới lên instance hoàn toàn mới chứ không cập nhật instance cũ. Nó có ưu điểm lớn là rollback nhanh và an toàn khi deploy hỏng, và trong lúc chuyển tiếp thì đúng là hai phiên bản cùng tồn tại. Nhưng vì phải dựng thêm cả một nhóm instance mới song song với nhóm cũ, chi phí EC2 trong giai đoạn deploy tăng lên rõ rệt — vi phạm thẳng ràng buộc "without incurring additional costs".

B — All at once: Deploy bản mới lên toàn bộ instance cùng lúc. Đây là cách nhanh nhất và cũng không thêm instance nào, nên vế chi phí thì đạt. Nhưng nó hỏng ở vế đầu: không hề có giai đoạn hai phiên bản cùng phục vụ — mọi instance chuyển sang bản mới đồng thời, và ứng dụng có thể không truy cập được (hoặc availability rất thấp) trong một khoảng ngắn. Đề yêu cầu hai phiên bản song song, All at once không cho điều đó.

C — Rolling with additional batches: Đây là phương án gần đúng nhất và cũng là bẫy chính của câu này. Nó cũng deploy theo batch, cũng có giai đoạn hai phiên bản cùng phục vụ, giống hệt Rolling. Điểm khác biệt duy nhất: trước khi bắt đầu, nó launch thêm một batch instance mới để giữ nguyên full capacity suốt quá trình deploy. Chính "additional batch" đó là chi phí phát sinh. Policy này hợp lý khi bạn bắt buộc phải giữ nguyên băng thông phục vụ trong lúc deploy, nhưng đề đã nói rõ là không được tốn thêm tiền — nên nó bị loại. Ngoài ra thời gian deploy còn dài hơn cả Rolling thường.

📌 Điểm cần nhớ

• Bốn deployment policy của Elastic Beanstalk trong câu này chia theo hai trục: có thêm instance mới hay không (Immutable, Rolling with additional batches → có; Rolling, All at once → không) và có giai đoạn hai phiên bản cùng chạy hay không (All at once → không; ba cái còn lại → có).
• Gặp từ khoá "without additional cost" / "no extra cost" trong câu hỏi về deploy Elastic Beanstalk, hãy loại ngay Immutable và Rolling with additional batches — cả hai đều dựng thêm EC2 instance.
• Gặp từ khoá "no downtime" hoặc "old and new version serve traffic simultaneously", hãy loại ngay All at once.
• Rolling đánh đổi capacity tạm giảm + thời gian deploy dài hơn để lấy chi phí không đổi; Rolling with additional batches trả tiền thêm để giữ full capacity. Nhận ra bạn đang được hỏi về trục nào là ra đáp án.

🧩 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 Aurora Serverless (bản tương thích MySQL) và muốn audit hoạt động của database, thu thập rồi publish log lên Amazon CloudWatch. Câu hỏi là: cần cấu hình những bước nào để đạt được điều đó.

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

• "Aurora Serverless" — đây không phải Aurora provisioned. Aurora Serverless chạy trên một proxy fleet các DB instance được cấp phát và thu hồi tự động. Người dùng không sở hữu một DB instance cố định nào để log file nằm trên đó, nên mọi phương án dựa vào "mở console RDS xem log của instance" đều sai ngay từ mô hình kiến trúc.
• "What configuration steps are needed" — đề hỏi phải cấu hình gì, tức là mặc nhiên thừa nhận việc này không tự động xảy ra. Cụm này loại thẳng phương án nói log "được gửi tự động".

Ghép hai cụm lại: đáp án phải là một hành động cấu hình cụ thể, ở tầng cluster parameter group, để bật đúng loại log mà engine MySQL sinh ra.

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

Đáp án đúng theo tệp là B — "For MySQL-compatible DB clusters, you can enable the slow query log, general log, or audit logs to get a view of the database activity".

Với Aurora Serverless tương thích MySQL, cách lấy được cái nhìn về hoạt động database là sửa cluster parameter group của cluster đó rồi bật các log của engine: slow query log, general log, hoặc audit log. Đây chính là "configuration steps" mà đề hỏi.

Khi các log này đã được bật, Aurora Serverless sẽ publish chúng lên CloudWatch Logs, và từ CloudWatch bạn xem được, tải về được, đặt metric filter hay alarm lên được. Nói cách khác, phần "collect and publish to CloudWatch" trong đề không phải là một bước riêng phải dựng thêm — nó là hệ quả sau khi bạn bật log ở parameter group. Đúng như giải thích gốc: "To enable logs, first modify the cluster parameter groups for an Aurora serverless cluster."

Ba loại log này cũng khớp đúng với yêu cầu "audit the database activity": general log ghi lại các kết nối và câu truy vấn, slow query log ghi các truy vấn chậm, audit log ghi vết truy cập phục vụ mục đích kiểm toán.

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

A — "You can view the logs directly from the Amazon Relational Database Service (Amazon RDS) console" Sai vì mô hình kiến trúc của Aurora Serverless. Không có DB instance trực tiếp nào thuộc về bạn để chứa file log, nên console RDS không hiển thị log file như với Aurora provisioned hay RDS thường. Đây là phương án bẫy dành cho người áp thói quen từ RDS truyền thống sang. Ngoài ra, kể cả nếu xem được, nó cũng không đáp ứng yêu cầu "publish lên CloudWatch" của đề.

C — "Aurora Serverless cluster is integrated with Amazon CloudWatch and logs are sent automatically" Đây là phương án gần đúng nhất và dễ chọn nhầm nhất. Nửa đầu đúng: Aurora Serverless có tích hợp với CloudWatch và sẽ đẩy log lên đó. Chỗ hỏng nằm ở chữ "automatically" — các log này không được bật sẵn mặc định. Phải cấu hình cluster parameter group trước thì Aurora mới publish. Vì đề hỏi thẳng "cần cấu hình những bước nào", một phương án khẳng định "chẳng cần làm gì cả" là mâu thuẫn với chính câu hỏi.

D — "…hence you cannot see the log files. You can connect with your AWS support contact" Cũng đúng một nửa rồi kết luận sai. Phần "Aurora Serverless connects to a proxy fleet of DB instances" là mô tả chính xác kiến trúc, và đúng là vì thế bạn không xem được log file trực tiếp. Nhưng suy ra "không xem được log" và "phải nhờ AWS Support" thì sai: bạn hoàn toàn tự làm được bằng cách bật log ở parameter group rồi đọc trên CloudWatch. Trong đề thi AWS, phương án "liên hệ AWS Support" gần như luôn là phương án loại, trừ khi vấn đề thật sự nằm ngoài quyền điều khiển của khách hàng (ví dụ tăng hạn mức cứng).

📌 Điểm cần nhớ

• Aurora Serverless không có DB instance riêng để bạn chạm tới — nó dùng một proxy fleet co giãn tự động. Hệ quả trực tiếp: không xem log file qua console RDS, mọi log phải đi đường CloudWatch Logs.
• Log của engine không bật sẵn. Với cluster tương thích MySQL, bật slow query log / general log / audit log bằng cách sửa cluster parameter group, không phải sửa DB parameter group của instance.
• Phân biệt kỹ "có tích hợp với CloudWatch" và "tự động gửi log". Tích hợp là khả năng sẵn có; gửi log vẫn là việc bạn phải bật. Đề hỏi "configuration steps" là tín hiệu loại ngay các phương án kiểu "tự động, khỏi làm gì".
• Phương án "liên hệ AWS Support" trong câu hỏi vận hành thường là bẫy — hãy tìm cấu hình mà khách hàng tự làm được trước khi tin rằng tính năng đó không tồn tại.

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

Đề mô tả một công ty đang chuyển hạ tầng on-premises lên AWS Cloud, và có compliance rules cùng regulatory guidelines bắt buộc họ phải dùng phần mềm của chính họ, loại cần cấu hình ở mức socket ("its own software that needs socket level configurations").

Cụm từ quyết định là "socket level configurations" — tức là phần mềm được cấp phép và cấu hình theo socket vật lý (per-socket), và ở nhiều trường hợp là per-core hoặc per-VM. Đây là ngôn ngữ của bring-your-own-license (BYOL): giấy phép gắn với phần cứng vật lý bên dưới, nên người dùng phải nhìn thấy và kiểm soát được máy chủ vật lý — số socket, số core, và biết instance của mình nằm trên đúng máy chủ nào.

Câu hỏi không hỏi về giá, không hỏi về tính sẵn sàng, cũng không hỏi về cam kết dài hạn. Nó chỉ hỏi: mô hình EC2 nào cho bạn quyền nhìn thấy tầng phần cứng vật lý để thoả mãn giấy phép tính theo socket. Đó chính là trục phân biệt bốn phương án.

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

Đáp án đúng theo tệp là C — Amazon EC2 Dedicated Host.

Một Dedicated Host là một máy chủ vật lý với toàn bộ năng lực EC2 dành riêng cho bạn sử dụng. Điểm mấu chốt: Dedicated Host phơi bày thuộc tính của phần cứng vật lý ra cho bạn, và cho phép bạn dùng giấy phép phần mềm sẵn có tính theo socket, theo core, hoặc theo VM — bao gồm Windows Server, Microsoft SQL Server, SUSE và Linux Enterprise Server.

Vì bạn sở hữu nguyên máy chủ vật lý đó và biết được cấu hình socket/core của nó, bạn có thể chứng minh với bên cấp phép và với bên kiểm toán compliance rằng phần mềm chỉ chạy trên đúng số socket đã mua. Đây chính xác là yêu cầu mà đề nêu ra, nên C là lựa chọn phù hợp.

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

A — Amazon EC2 Dedicated Instance. Đây là phương án gần đúng nhất và là cái bẫy chính của câu hỏi. Dedicated Instance cũng chạy trên phần cứng dành riêng cho một khách hàng, trong một VPC, và được cô lập vật lý ở mức phần cứng khỏi các AWS account khác — kể cả khi các account đó cùng thuộc một payer account. Nghe rất giống Dedicated Host. Nhưng nó hỏng ở chỗ: Dedicated Instance vẫn có thể dùng chung phần cứng với các instance khác trong cùng AWS account của bạn mà không phải là Dedicated Instance, và quan trọng hơn — nó không cho bạn quyền nhìn thấy hay kiểm soát máy chủ vật lý cùng thuộc tính socket của nó. Không thấy được socket thì không phục vụ được giấy phép tính theo socket. Cô lập khỏi khách hàng khác ≠ hiển thị phần cứng để BYOL.

B — Reserved Instances "cho phép lên kế hoạch và giúp cài phần mềm cần thiết". Reserved Instance là một mô hình thanh toán/cam kết, không phải mô hình cách ly phần cứng. Nó chỉ nói bạn cam kết dùng một mức capacity trong thời gian dài để đổi lấy giá tốt hơn. Vế "help install the necessary software" trong phương án là câu chữ đánh lạc hướng — không có cơ chế nào của Reserved Instance liên quan tới việc cài đặt hay cấp phép phần mềm. Bạn không thể cài phần mềm cần lập trình ở mức socket trên Reserved Instances.

D — On-Demand instances "sẵn sàng cao và không cần lên kế hoạch trước". Cũng như B, đây là một mô hình thanh toán (trả theo lượng dùng, không cam kết), không phải mô hình phần cứng. Mô tả "highly available, require no prior planning" đúng về mặt tiện lợi vận hành nhưng hoàn toàn lệch trục câu hỏi. On-Demand instance chạy trên hạ tầng dùng chung và không phơi bày thông tin socket vật lý, nên không cài được phần mềm cần cấu hình ở mức socket.

📌 Điểm cần nhớ

• Thấy các từ khoá "socket level", "per-socket / per-core license", "BYOL", "existing software licenses" trong đề thi → gần như chắc chắn đáp án là Dedicated Host, không phải Dedicated Instance.
• Phân biệt hai khái niệm dễ lẫn: Dedicated Instance = cách ly phần cứng khỏi các AWS account khác; Dedicated Host = bạn được cấp nguyên máy chủ vật lý và nhìn thấy thuộc tính phần cứng (socket, core) để phục vụ cấp phép và compliance.
• Đừng lẫn mô hình thanh toán với mô hình cách ly phần cứng. On-Demand, Reserved Instances, Savings Plans trả lời câu hỏi "trả tiền thế nào"; Dedicated Host và Dedicated Instance trả lời câu hỏi "chạy trên phần cứng nào".
• Phương án nào gắn một lợi ích không liên quan vào tên dịch vụ (kiểu "Reserved Instances giúp cài phần mềm") thường là mồi nhử — hãy kiểm lại xem dịch vụ đó thực sự giải quyết trục nào của bài toán.

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

Đề mô tả một tổ chức đi từ một AWS account duy nhất lên multi-account, mỗi account lại có nhiều môi trường (Production, Development, Testing) và trước nay việc backup được quản lý ở mức từng account. Yêu cầu là chuyển sang mô hình quản lý backup tập trung.

Cụm từ quyết định nằm ở câu cuối phần mô tả: "centralized backup management process that consolidates and automates Cross-Region backup tasks across AWS accounts". Ba ràng buộc dính liền nhau:

• centralized / across AWS accounts — phải quản trị được từ một chỗ cho nhiều account, tức là gắn với AWS Organizations, không phải cấu hình lặp lại trong từng account.
• Cross-Region — sao chép bản backup sang Region khác phải là tính năng có sẵn, không phải thứ tự dựng.
• consolidates and automates — một mặt phẳng điều khiển chung cho nhiều loại tài nguyên, không phải mỗi dịch vụ một cơ chế riêng.

Ngoài ra, đề nhắc tới việc phân biệt môi trường — gợi ý lời giải nên dùng tag để gom tài nguyên vào các chính sách backup khác nhau.

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

Đáp án D — tạo backup plan trong AWS Backup, gắn tag theo môi trường, tách một policy cho Production và một policy cho non-production, rồi đặt lịch theo chính sách của tổ chức.

AWS Backup là dịch vụ backup được quản lý hoàn toàn, sinh ra đúng để gom việc sao lưu của nhiều dịch vụ AWS về một chỗ: Amazon EBS, Amazon EC2, Amazon RDS, Amazon Aurora, Amazon DynamoDB, Amazon EFS, AWS Storage Gateway… Thay vì mỗi dịch vụ một cơ chế snapshot riêng, người vận hành chỉ khai báo backup plan (lịch chạy, thời gian giữ, vault đích) rồi assign resources vào plan đó.

Hai điểm khớp thẳng với đề:

• AWS Backup tích hợp AWS Organizations để triển khai backup policy từ account quản lý xuống các account thành viên, giữ được một góc nhìn tập trung về chính sách backup trong môi trường multi-account. Đây chính là chữ centralized mà đề đòi.
• Việc assign resource bằng tag là cách gán chuẩn của AWS Backup, nên "tag theo Production / Development / Testing rồi cho mỗi nhóm một policy" không phải mẹo chắp vá mà là cách dùng đúng thiết kế. Production có thể chạy dày hơn, giữ lâu hơn, và bật cross-Region copy trong cùng backup plan; non-production thì thưa hơn, rẻ hơn — hợp với domain Cost and Performance Optimization.

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

A — Amazon Data Lifecycle Manager (DLM). Đây là phương án gần đúng nhất và cũng dễ mắc bẫy nhất, vì DLM cũng dùng tag, cũng có lifecycle policy, cũng tự động tạo và xoá theo lịch. Nhưng phạm vi của DLM là vòng đời tài nguyên EBS — chủ yếu là EBS snapshot (và AMI dựa trên EBS). Nó không phải mặt phẳng điều khiển chung cho RDS, DynamoDB, EFS…, và bản thân đề bài mô tả nó quá rộng ("manage all the AWS resources under an account") so với thực tế dịch vụ. Ngoài ra cách diễn đạt "under an account" đã tự tố ra: vẫn là quản lý ở mức từng account, đúng cái mà tổ chức đang muốn thoát khỏi.

B — Amazon EventBridge dựng workflow backup. EventBridge là serverless event bus để nối các ứng dụng và dịch vụ lại với nhau; về mặt kỹ thuật thì đúng là có thể dựng một giải pháp backup quanh nó (lịch chạy, gọi API snapshot, xử lý kết quả). Vấn đề là nó không tối ưu: bạn phải tự viết và tự bảo trì logic cho từng loại tài nguyên, tự lo phần cross-Region copy, tự lo phần trải chính sách ra nhiều account — trong khi AWS đã có dịch vụ chuyên trách làm sẵn những việc đó. Câu hỏi hỏi "the right choice", không hỏi "cách nào chạy được". Chi tiết trong phương án cũng lệch: S3 lifecycle policy là chuyển/xoá đối tượng theo tuổi, không phải cơ chế sinh sự kiện backup.

C — AWS Systems Manager Maintenance Windows + CloudWatch dashboard. Maintenance Windows dùng để định nghĩa khung thời gian được phép thực hiện các thao tác có thể gây gián đoạn trên instance: vá hệ điều hành, cập nhật driver, cài phần mềm. Nó là công cụ về thời điểm chạy tác vụ vận hành, không phải dịch vụ backup — không có khái niệm backup plan, vault, retention hay cross-Region copy. Phần CloudWatch dashboard chỉ thêm khả năng quan sát, không giải quyết yêu cầu tập trung hoá và tự động hoá backup. Và cũng như A, mô tả dừng ở "all resources under the AWS account", không chạm tới vế multi-account.

📌 Điểm cần nhớ

• Thấy đồng thời backup + multi-account + cross-Region + centralized trong đề thì mặc định nghĩ tới AWS Backup; nó tích hợp AWS Organizations để trải backup policy xuống các account thành viên và có sẵn cross-Region copy trong backup plan.
• DLM là bẫy kinh điển của AWS Backup: cả hai đều dùng tag và lifecycle. Phân biệt bằng phạm vi — DLM gói gọn trong vòng đời EBS snapshot / AMI, AWS Backup phủ nhiều dịch vụ và nhiều account.
• Systems Manager Maintenance Windows là về patching và các thao tác gây gián đoạn theo lịch, không phải công cụ backup. Xuất hiện trong phương án backup gần như luôn là distractor.
• Phương án "tự dựng bằng EventBridge" thường chạy được nhưng không phải câu trả lời đúng khi AWS có dịch vụ managed chuyên trách — đề thi ưu tiên giải pháp ít phải tự vận hành nhất.
• Mẹo đọc đề: chú ý phương án nào chỉ nói "under an account" trong khi đề đòi "across accounts" — riêng chi tiết đó đã loại được vài lựa chọn.

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

Đề bài mô tả một công ty thương mại điện tử đang chạy hạ tầng trên các EC2 instance instance store-backed, và muốn chuyển ứng dụng sang một instance cũng là instance store-backed nhưng khác instance type để có hiệu năng tốt hơn.

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

• "instance store-backed instance" — loại instance này không thay đổi instance type tại chỗ được như instance EBS-backed. Với EBS-backed, quy trình quen thuộc là stop instance → đổi thuộc tính instance type → start lại. Instance store-backed không có bước "stop" theo nghĩa đó (dừng là mất dữ liệu ổ đĩa cục bộ), nên cách duy nhất là tạo image rồi launch instance mới từ image đó với instance type mong muốn.
• "for uninterrupted access/service" — cụm này mới là thứ tách hai phương án C và D vốn giống hệt nhau ở nửa đầu. Khi ứng dụng phải phục vụ liên tục qua một địa chỉ IP cố định, câu hỏi thực chất là: địa chỉ IP nào mang theo được sang instance mới?

Nói cách khác, đề gộp hai kiến thức: cách "resize" một instance store-backed instance, và sự khác nhau giữa public IP tự động với Elastic IP.

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

Đáp án đúng theo tệp là D: tạo image từ instance hiện tại, launch instance mới từ image đó với instance type cần dùng, rồi lấy Elastic IP đang gắn ở instance cũ gắn sang instance mới.

Phương án này đúng ở cả hai vế:

• Vế di trú: với instance store-backed instance, muốn đổi sang instance type khác thì phải tạo một image (AMI) từ instance đang chạy, rồi dùng image đó để launch instance mới ở instance type mong muốn. Sau khi instance mới hoạt động ổn, terminate instance gốc. Đây chính là quy trình migrate mà tài liệu EC2 mô tả.
• Vế giữ dịch vụ liên tục: Elastic IP là địa chỉ IPv4 tĩnh do tài khoản sở hữu, tách rời khỏi vòng đời của instance. Bạn có thể disassociate khỏi instance cũ và associate sang instance mới, nên client vẫn trỏ tới đúng một địa chỉ IP trong suốt quá trình chuyển đổi. Đó là lý do Elastic IP là công cụ chuẩn cho các thao tác thay thế/di trú instance.

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

A. "Không resize được instance store-backed instance; thay vào đó cấu hình EBS volume làm root device rồi migrate qua EBS volume" — Sai ngay ở tiền đề: instance store-backed instance vẫn "resize" được theo nghĩa tạo image rồi launch instance mới ở type khác, không hề bị kẹt. Ngoài ra, root device type là thuộc tính được cố định lúc launch instance từ AMI tương ứng, không phải thứ bạn gắn thêm vào một instance đang chạy để biến nó thành EBS-backed. Đề cũng không hề nói công ty muốn đổi sang EBS-backed — họ muốn sang một instance store-backed instance khác. Phương án này vừa sai kỹ thuật vừa lệch yêu cầu.

B. "Không resize được; thay vào đó chọn một instance tương thích rồi chuyển ứng dụng sang" — Sai cùng tiền đề với A: khẳng định "không resize được" là không đúng. Vế sau thì mơ hồ tới mức vô dụng: "chuyển ứng dụng sang instance mới" không nói bằng cách nào (tạo image? cài lại thủ công?) và hoàn toàn bỏ qua yêu cầu phục vụ liên tục — không đả động gì tới việc giữ địa chỉ IP cho người dùng. Một câu trả lời đúng phải giải quyết cả tính liên tục của dịch vụ.

C. "Tạo image, launch instance mới với instance type cần dùng; public IP gắn với instance có thể chuyển theo instance" — Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Nửa đầu hoàn toàn chính xác, trùng với đáp án D. Chỗ hỏng nằm ở nửa sau: public IP tự động cấp không di chuyển theo được. Địa chỉ đó do AWS gán cho instance và bị thu hồi khi instance thay đổi/kết thúc — nó không thuộc quyền sở hữu của bạn nên không thể gắn nó sang instance mới. Instance mới sẽ nhận một public IP hoàn toàn khác, và người dùng đang trỏ vào địa chỉ cũ sẽ mất kết nối — đúng thứ mà cụm "uninterrupted access" trong đề cấm xảy ra. Chỉ Elastic IP mới chuyển được giữa các instance.

📌 Điểm cần nhớ

• Instance store-backed instance đổi instance type = tạo image → launch instance mới từ image → terminate instance cũ. Không có thao tác đổi thuộc tính tại chỗ như với EBS-backed instance (stop → đổi type → start).
• Public IP tự động ≠ Elastic IP. Public IP do AWS gán, gắn với vòng đời instance và bị thu hồi khi instance thay đổi; Elastic IP thuộc về tài khoản bạn và associate/disassociate được giữa các instance. Thấy đề nhắc "uninterrupted" hay "giữ nguyên địa chỉ" thì đáp án gần như luôn là Elastic IP.
• Cảnh giác với phương án mở đầu bằng một khẳng định phủ định sai ("You can't resize…"). Nếu tiền đề sai thì phần còn lại có hợp lý đến mấy cũng loại được ngay, khỏi cần đọc kỹ vế sau.
• Khi hai phương án chỉ khác nhau ở nửa cuối câu, ràng buộc phân biệt nằm đúng ở đó. Ở đây C và D giống hệt nhau tới chữ "instance type that you need"; toàn bộ điểm số nằm ở việc chọn public IP hay Elastic IP.

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

Đề mô tả một công ty mạng xã hội lưu ảnh người dùng trên Amazon S3, mã hoá bằng AWS KMS với Customer Master Key (CMK) do chính công ty quản lý. Một quản trị viên lỡ tay xoá CMK, khiến toàn bộ ảnh không đọc được nữa. Câu hỏi yêu cầu chọn cách xử lý.

Cụm từ quyết định đáp án nằm ở đúng một chi tiết thời gian: "accidentally deleted the CMK a day ago" — một ngày trước. Nếu bỏ qua mốc thời gian này thì cả bốn phương án đều nghe hợp lý ở mức nào đó. Nhưng KMS không xoá key ngay khi bạn bấm xoá: thao tác "xoá CMK" thực chất là lên lịch xoá (schedule key deletion), và trong suốt thời gian chờ, key ở trạng thái Pending deletion chứ chưa biến mất. Một ngày trôi qua vẫn nằm gọn trong khoảng chờ tối thiểu mà KMS bắt buộc, nên key vẫn còn.

Chi tiết thứ hai đáng chú ý: dữ liệu nằm trên S3 và được mã hoá bằng CMK đó. Nghĩa là ảnh vẫn nguyên vẹn trong bucket — thứ bị mất chỉ là khả năng giải mã. Khôi phục được key là khôi phục được toàn bộ dữ liệu, không cần phục hồi gì thêm từ S3.

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

B — CMK bị xoá một ngày trước nên đang ở trạng thái 'pending deletion', chỉ cần huỷ lệnh xoá là lấy lại được key.

Xoá một CMK là hành động phá huỷ và không thể đảo ngược: mọi dữ liệu từng mã hoá bằng key đó sẽ vĩnh viễn không giải mã được. Chính vì mức độ nguy hiểm này, AWS KMS áp đặt một khoảng thời gian chờ bắt buộc thay vì xoá tức thì. Bạn chỉ có thể lên lịch xoá, chọn độ dài khoảng chờ trong một biên độ do KMS quy định (tối thiểu vài ngày, mặc định là giá trị dài nhất trong biên độ đó).

Trong suốt khoảng chờ, key state là Pending deletion: key không dùng để mã hoá/giải mã được nữa (nên ứng dụng đang lỗi là đúng), nhưng vật liệu khoá vẫn tồn tại. Thao tác Cancel key deletion đưa key về trạng thái Disabled; sau đó chỉ cần enable lại là S3 giải mã được ảnh như cũ.

Với mốc "một ngày trước", công ty còn dư thời gian để thực hiện việc này — đây chính là kịch bản mà cơ chế waiting period được thiết kế ra để cứu.

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

A — Liên hệ AWS Support để lấy CMK từ bản sao lưu của họ. Nghe có vẻ hợp lý vì AWS Support đúng là cứu được nhiều tình huống khác, nhưng ở đây thì không. Vật liệu khoá của CMK nằm trong HSM và AWS không giữ bản sao lưu nào mà nhân viên support truy cập được để trả lại cho khách hàng. Đây là ranh giới cố ý của mô hình bảo mật KMS: nếu support lấy lại được key thì key không còn là bí mật của riêng bạn. Sau khi hết waiting period, key mất là mất thật, không ai khôi phục nổi.

C — Ra thông báo trên web app báo người dùng rằng dữ liệu đã mất. Phương án này gần đúng về mặt quy trình nếu dữ liệu thật sự mất — nhưng tiền đề của nó sai. Dữ liệu chưa mất: key mới chỉ đang chờ xoá, huỷ lệnh xoá là phục hồi được. Chọn C là đầu hàng trước khi thử biện pháp kỹ thuật còn hiệu lực, đồng thời gây thiệt hại uy tín không đáng có. Đây là kiểu bẫy quen thuộc trong đề: một hành động "đúng đắn về nghiệp vụ" nhưng dựa trên chẩn đoán kỹ thuật sai.

D — Tài khoản root của AWS có thể khôi phục CMK. Sai vì nhầm lẫn giữa quyền hạn và khả năng kỹ thuật. Root user có quyền cao nhất trong account, nhưng quyền không tạo ra vật liệu khoá đã bị huỷ. Nếu CMK đã qua waiting period và bị xoá, root cũng bó tay hệt như mọi principal khác. Còn khi key vẫn đang Pending deletion thì việc cần làm là cancel key deletion — thao tác này bất kỳ principal nào có đủ permission trên key đều làm được, không phải đặc quyền riêng của root.

📌 Điểm cần nhớ

• Trong AWS KMS, "xoá CMK" luôn là schedule key deletion kèm waiting period bắt buộc; trong khoảng đó key ở trạng thái Pending deletion và cancel key deletion vẫn cứu được. Gặp đề nói key vừa bị xoá cách đây vài ngày — phản xạ đầu tiên là kiểm tra trạng thái pending.
• Key đang Pending deletion thì không dùng được cho mã hoá/giải mã, nên triệu chứng "dữ liệu không đọc được" không đồng nghĩa với "key đã mất vĩnh viễn". Phân biệt hai chuyện này là mấu chốt của cả câu hỏi.
• AWS Support và root user đều không khôi phục được CMK đã xoá hẳn. Mọi phương án dựa vào "nhờ AWS lấy lại" hay "root làm được" trong ngữ cảnh KMS đều là distractor.
• Khi dữ liệu S3 được mã hoá bằng KMS, object vẫn còn nguyên trong bucket — thứ bị mất là khả năng giải mã. Cứu được key là cứu được dữ liệu, không cần khôi phục object.