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

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

Đề mô tả một SysOps administrator xem số liệu hiệu năng của một EC2 instance trong CloudWatch, nhìn vào metric DiskReadBytes và thấy nó báo 0 byte trong suốt cả ngày. Câu hỏi yêu cầu chọn lời giải thích khả dĩ nhất cho con số 0 đó.

Cụm từ quyết định đáp án là chính tên metric: DiskReadBytes. Trong bộ metric mà EC2 gửi sẵn sang CloudWatch (namespace AWS/EC2), nhóm DiskReadBytes / DiskWriteBytes / DiskReadOps / DiskWriteOps chỉ đo hoạt động đọc–ghi trên instance store volume gắn vào instance. Hoạt động của EBS volume không nằm trong nhóm metric này — EBS có bộ metric riêng ở namespace AWS/EBS (VolumeReadBytes, VolumeWriteBytes…). Nắm được ranh giới đó là trả lời được ngay, vì cả bốn phương án đều là những lý do "nghe hợp lý" cho một biểu đồ phẳng bằng 0.

Chi tiết thứ hai cũng đáng chú ý: "0 bytes trong cả một ngày" — nghĩa là không phải thiếu điểm dữ liệu, mà là có dữ liệu và dữ liệu bằng 0. Điều này loại được những phương án nói về tần suất hay cách thu thập số liệu.

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

A — "An instance store volume is not attached to the EC2 instance."

DiskReadBytes cộng dồn toàn bộ số byte đọc được từ mọi instance store volume mà instance có. Nếu instance chạy hoàn toàn trên EBS (trường hợp phổ biến nhất) và không có instance store volume nào gắn vào, thì đơn giản là không tồn tại nguồn dữ liệu để metric này đếm — nên nó báo 0 đều đặn, cả ngày, dù máy vẫn đọc ghi ổ đĩa rất nhiều qua EBS.

Đây chính là bẫy vận hành thường gặp: người quản trị mở CloudWatch, thấy DiskReadBytes bằng 0 và tưởng máy đang "không đọc đĩa", trong khi thật ra họ đang nhìn nhầm chỗ — phải xem metric EBS mới thấy hoạt động thật.

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

B — "An Amazon EBS volume is not attached to the EC2 instance."

Đây là phương án gần đúng nhất, và nó hỏng ở đúng chỗ mấu chốt của câu hỏi: DiskReadBytes không phản ánh hoạt động của EBS. Có gắn EBS hay không gắn EBS thì metric này vẫn không thay đổi. Ngoài ra lập luận còn tự mâu thuẫn — một instance khởi động từ EBS mà "không có EBS volume nào" thì đã không chạy được để mà báo số liệu. Muốn theo dõi đọc–ghi trên EBS thì phải xem các metric ở namespace AWS/EBS.

C — "The CloudWatch agent is not installed on the EC2 instance."

CloudWatch agent cần cho các metric mà hypervisor không nhìn thấy được — tiêu biểu là bộ nhớ (memory), dung lượng đĩa còn trống ở mức filesystem, và log trong máy. Còn DiskReadBytes là metric mặc định do nền tảng EC2 phát ra, không cần cài gì thêm. Thêm nữa, nếu thật sự thiếu agent thì kết quả sẽ là không có metric nào cả, chứ không phải một metric hiện diện đầy đủ với giá trị 0.

D — "Detailed monitoring is not enabled on the EC2 instance."

Detailed monitoring chỉ đổi độ mịn thời gian của việc báo số liệu — bật lên thì điểm dữ liệu dày hơn, tắt đi thì thưa hơn. Nó không đổi giá trị của metric. Với monitoring cơ bản, instance vẫn gửi DiskReadBytes đều đặn; nếu có đọc từ instance store thì con số phải khác 0. Vậy phương án này giải thích được "ít điểm dữ liệu hơn", nhưng không giải thích nổi "bằng 0 suốt cả ngày".

📌 Điểm cần nhớ

• Nhóm metric DiskReadBytes / DiskWriteBytes / DiskReadOps / DiskWriteOps trong namespace AWS/EC2 chỉ đo instance store; hoạt động của EBS nằm ở namespace AWS/EBS với các metric Volume*.
• Metric bằng 0 khác hẳn metric không tồn tại: giá trị 0 nghĩa là đường ống thu thập vẫn chạy, chỉ là không có gì để đếm — nên đừng đổ lỗi cho agent hay cấu hình monitoring.
• CloudWatch agent dành cho những thứ chỉ nhìn thấy được từ bên trong hệ điều hành (memory, dung lượng filesystem, log). Metric do hypervisor phát ra thì không cần agent.
• Detailed monitoring ảnh hưởng tới tần suất báo số liệu, không ảnh hưởng tới bản thân con số — gặp phương án này trong câu hỏi kiểu "vì sao giá trị sai/bằng 0" thì gần như luôn là mồi nhử.

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

Đề mô tả một Amazon RDS database được mã hoá bằng customer managed AWS KMS key, và yêu cầu chia sẻ snapshot của nó sang một AWS account khác cùng công ty.

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

• "encrypted using a customer managed AWS KMS key" — khoá đang dùng là khoá do khách hàng quản lý, tức là key policy sửa được. Đây chính là điều kiện cần để chia sẻ snapshot mã hoá.
• "shared with another AWS account" — chia sẻ chứ không phải sao chép dữ liệu thủ công; RDS đã có sẵn cơ chế share snapshot.
• "must always remain encrypted" — chữ always loại thẳng mọi phương án có một khoảnh khắc dữ liệu nằm ở dạng không mã hoá.

Điểm mấu chốt cần nhớ: RDS snapshot mã hoá bằng KMS key chỉ dùng được ở account đích khi account đó có quyền dùng chính KMS key đã mã hoá nó. Vì thế bài toán "chia sẻ snapshot mã hoá" thực chất là bài toán cấp quyền trên key policy, không phải bài toán di chuyển dữ liệu.

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

A làm đúng hai bước theo trình tự AWS quy định:

1. Thêm account thứ hai làm key user trong key policy của customer managed KMS key. Đây là bước cấp cho account đích khả năng gọi các thao tác mã hoá/giải mã bằng khoá đó. Không có bước này, account đích nhận được snapshot nhưng không giải mã nổi, nên cũng không restore ra database được.
2. Copy snapshot bằng chính KMS key đó rồi share sang account đích. Snapshot giữ nguyên trạng thái mã hoá suốt quá trình, thoả mãn ràng buộc always remain encrypted.

Sau đó, phía account đích sẽ copy snapshot đã được share về account mình (thường là copy lại bằng một KMS key của chính họ) rồi restore. Toàn bộ luồng không có bước nào dữ liệu nằm ở dạng plaintext.

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

B — Lambda bóc dữ liệu ra S3 rồi Lambda thứ hai dựng lại snapshot: đây không phải là sai về bảo mật mà sai về tính khả thi. Snapshot của RDS là định dạng nội bộ của công cụ; không có cách nào để một Lambda "ghi dữ liệu vào S3" rồi một Lambda khác "tạo ra một encrypted snapshot" từ đó. Muốn đưa dữ liệu trở lại RDS thì phải restore/import qua database engine chứ không phải chế tác snapshot. Ngoài ra phương án này còn tự dựng lại một cơ chế mà RDS + KMS đã cung cấp sẵn, với rất nhiều mã phải bảo trì và rất nhiều chỗ hỏng.

C — tạo bản copy không mã hoá rồi share, sau đó mã hoá lại: đây là phương án gần đúng nhất về mặt thao tác vì RDS đúng là cho phép copy snapshot bỏ mã hoá và cho phép share snapshot không mã hoá dễ dàng hơn. Nhưng nó hỏng ngay ở ràng buộc trong đề: có một giai đoạn snapshot tồn tại ở dạng unencrypted, và đề nói dữ liệu phải mã hoá luôn luôn. Việc mã hoá lại ở account đích không cứu được — vi phạm đã xảy ra trước đó rồi.

D — copy snapshot và mã hoá bằng default AWS managed KMS key, rồi thêm account kia làm key user: phương án này bẫy ở chỗ nghe rất giống A, chỉ đổi loại khoá. Nhưng AWS managed key (khoá mặc định của dịch vụ) không cho sửa key policy — bạn không thể thêm key user vào đó, nên bước hai của phương án này không thực hiện được. Hệ quả là snapshot mã hoá bằng default key không share sang account khác được. Đây chính là lý do tồn tại của yêu cầu "customer managed key" trong quy trình chuẩn: chỉ khoá do khách hàng quản lý mới có key policy sửa được để cấp quyền cross-account.

📌 Điểm cần nhớ

• Snapshot RDS mã hoá bằng AWS managed (default) KMS key thì không chia sẻ cross-account được; muốn share thì phải copy sang một customer managed key. Thấy phương án nào nói "default KMS key" + "share sang account khác" là loại được ngay.
• Chia sẻ snapshot mã hoá luôn gồm hai vế: share snapshot (quyền trên RDS) và cấp quyền dùng KMS key (key policy). Thiếu vế thứ hai thì account đích nhận được snapshot mà không giải mã được.
• Cụm "must always remain encrypted" trong đề là dấu hiệu loại mọi phương án đi qua trạng thái unencrypted, kể cả khi mã hoá lại ở bước cuối.
• Khi AWS đã có cơ chế gốc (share snapshot + KMS key policy), phương án tự dựng đường ống bằng Lambda/S3 gần như luôn là đáp án sai trong đề thi — vừa phức tạp hơn, vừa thường không khả thi về mặt định dạng dữ liệu.

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

Đề mô tả một ứng dụng web stateless chạy trên một fleet EC2 instance, dùng Route 53 multivalue answer routing để phân phối lưu lượng. SysOps administrator muốn thêm instance trước một đợt tăng tải dự kiến, nhưng gặp lỗi InstanceLimitExceeded. Câu hỏi: làm gì để giải quyết chính lỗi đó?

Cụm từ quyết định đáp án là tên lỗi: InstanceLimitExceeded. Đây không phải lỗi hết capacity của AWS (InsufficientInstanceCapacity), cũng không phải lỗi mạng hay lỗi cấu hình subnet — nó nói rằng tài khoản đã chạm hạn mức (quota) số On-Demand instance được chạy trong Region đó. Điểm mấu chốt thứ hai: hạn mức này áp theo Region, không phải theo VPC, theo AZ hay theo placement group.

Hai chi tiết "stateless" và "multivalue answer routing" là bối cảnh gây nhiễu — chúng chỉ giải thích vì sao việc thêm instance là hợp lý, chứ không liên quan gì tới nguyên nhân lỗi. Nhận ra điều này giúp loại ngay các phương án đi theo hướng "đổi chỗ đặt instance".

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

B — Use Service Quotas to request an EC2 quota increase.

Lỗi InstanceLimitExceeded nghĩa là tài khoản đã đạt giới hạn số On-Demand instance đang chạy được phép có trong Region. Cách xử lý đúng và duy nhất về bản chất là xin nâng hạn mức: dùng Service Quotas để gửi yêu cầu tăng quota EC2 cho Region đó (trang Limits trong console EC2 cũng dẫn tới cùng luồng yêu cầu này). Khi quota được nâng, lệnh launch instance sẽ thành công.

Đây là hành động nhắm thẳng vào nguyên nhân gốc: vấn đề nằm ở quyền được chạy bao nhiêu instance, không nằm ở chỗ đặt chúng ở đâu.

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

A — Launch new EC2 instances in another VPC. Sai vì hạn mức On-Demand instance tính theo Region cho cả tài khoản, không tính theo VPC. Tạo thêm một VPC trong cùng Region rồi launch vào đó vẫn tiêu đúng quota cũ và vẫn trả về đúng lỗi đó. Ngoài ra còn kéo theo chi phí vận hành thừa: routing, security group, có thể cả peering — mà chẳng giải quyết gì.

C — Add new EC2 instances in a placement group. Sai vì placement group chỉ điều khiển cách AWS bố trí instance về mặt vật lý (cluster để giảm độ trễ mạng, spread để tách rời phần cứng, partition để tách theo nhóm hạ tầng). Nó không cấp thêm hạn mức nào cả. Instance nằm trong placement group vẫn được đếm vào cùng quota EC2 của Region, nên lệnh launch vẫn hỏng y hệt. Với một web app stateless đứng sau Route 53, placement group cũng không mang lại lợi ích đáng kể.

D — Launch the EC2 instances in a different Availability Zone. Đây là phương án gần đúng nhất và dễ chọn nhầm nhất, vì đổi AZ đúng là cách xử lý quen thuộc cho một lỗi khác: InsufficientInstanceCapacity — khi AWS tạm thời hết capacity cho loại instance đó trong một AZ cụ thể. Nhưng ở đây lỗi là InstanceLimitExceeded, mà quota thì áp ở cấp Region, bao trùm mọi AZ bên trong. Chuyển sang AZ khác trong cùng Region vẫn đụng đúng trần cũ. Nó hỏng ở chỗ chẩn đoán nhầm lỗi, chứ không phải ở chỗ hành động vô nghĩa.

📌 Điểm cần nhớ

• Đọc kỹ tên lỗi trước khi chọn hành động. InstanceLimitExceeded = chạm quota của tài khoản → xin tăng quota. InsufficientInstanceCapacity = AWS hết capacity ở AZ/loại instance đó → thử AZ khác, loại instance khác, hoặc thử lại sau. Hai lỗi nghe giống nhau nhưng cách chữa ngược nhau.
• Nhớ phạm vi (scope) của từng loại giới hạn. Quota EC2 áp theo Region + theo tài khoản. Mọi phương án kiểu "đổi VPC", "đổi AZ", "đổi subnet" đều không thoát được một giới hạn ở cấp Region.
• Service Quotas là cửa chính thức để xem và xin nâng hạn mức cho các dịch vụ AWS; trang Limits trong console EC2 chỉ là lối vào khác của cùng luồng đó.
• Placement group là công cụ bố trí vật lý, không phải công cụ về hạn mức hay khả năng mở rộng. Thấy nó xuất hiện trong một câu hỏi về quota thì gần như chắc chắn là phương án nhiễu.
• Cảnh giác với chi tiết bối cảnh không liên quan. "Stateless", "Route 53 multivalue answer routing" ở đây chỉ dựng cảnh; đáp án được quyết bởi đúng một chuỗi ký tự là tên lỗi.

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

Đề đưa ra một IAM policy và hỏi: "Which actions does this policy allow? (Select TWO.)" — tức là chọn hai hành động mà chính sách này cho phép, chứ không phải hai hành động nó chặn.

Cụm từ quyết định nằm ngay trong khối Action: mỗi dòng viết ở một mức độ rộng khác nhau, và đó chính là thứ phân biệt năm phương án gần giống nhau:

• "rds:CreateDBInstance" — một action đơn lẻ, không có dấu *
• "elasticloadbalancing:*" — dấu * phủ toàn bộ service
• "lambda:*" — dấu * phủ toàn bộ service
• "sns:ListTopics*" — dấu * nhưng đứng sau tiền tố ListTopics, nên chỉ nở ra được những action bắt đầu bằng chuỗi đó

"Effect": "Allow" và "Resource": "*" chỉ nói rằng chính sách này là cấp quyền và không giới hạn tài nguyên. Chúng không cứu được một action không có tên trong danh sách: IAM mặc định là deny, cái gì không được liệt kê thì không được phép. Vậy toàn bộ bài toán rút về việc đọc kỹ vị trí của dấu * trong từng dòng.

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

B — Describe AWS load balancers. Dòng elasticloadbalancing:* cho phép mọi action thuộc namespace elasticloadbalancing. Hành động mô tả load balancer (họ action Describe* của Elastic Load Balancing) nằm trong namespace đó, nên dấu * bao trọn. Đây là quyền rộng nhất trong cả chính sách.

E — Invoke an AWS Lambda function. Tương tự, lambda:* cho phép mọi action thuộc namespace lambda, và gọi hàm (lambda:InvokeFunction) là một action thuộc chính namespace này. Nên nó được cho phép.

Điểm chung của hai đáp án đúng: cả hai đều rơi vào một namespace được cấp * toàn phần.

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

A — Delete an Amazon RDS database. Đây là phương án gần đúng nhất và là cái bẫy chính. Chính sách có nhắc tới RDS, nhưng chỉ đúng một action duy nhất: rds:CreateDBInstance. Không có dấu * ở đây, nên nó chỉ cho phép tạo DB instance. Xoá là một action khác (rds:DeleteDBInstance), không có tên trong danh sách → mặc định bị deny. Sai lầm điển hình là đọc lướt thành "policy này cấp quyền RDS".

C — Create an IAM role for an AWS Lambda function. Phương án này khai thác chỗ dễ nhầm nhất: nó có nhắc Lambda, mà chính sách thì cho lambda:*. Nhưng hành động thật sự cần ở đây là tạo IAM role, tức action thuộc namespace iam (iam:CreateRole), không thuộc namespace lambda. Dấu * trong lambda:* chỉ nở ra trong phạm vi service Lambda, không tràn sang IAM. Trong chính sách này không có bất kỳ dòng iam: nào → bị deny. Bài học: đừng phân loại action theo ngữ cảnh nghiệp vụ ("việc này phục vụ Lambda"), mà theo service prefix đứng trước dấu hai chấm.

D — Delete an Amazon SNS topic. Cũng là phương án gần đúng. Chính sách có nhắc SNS, nhưng dòng đó là sns:ListTopics* — dấu * bị neo sau tiền tố ListTopics, nên nó chỉ mở ra những action bắt đầu bằng đúng chuỗi ký tự này. Xoá topic là sns:DeleteTopic, không khớp tiền tố → không được cấp. Đây là ví dụ rõ nhất cho việc Service:Tiền tố* khác hẳn Service:*.

📌 Điểm cần nhớ

• Vị trí dấu * quyết định phạm vi. service:* = toàn bộ service; service:Prefix* = chỉ những action khớp tiền tố; không có * = đúng một action duy nhất, không suy rộng sang action "anh em" cùng tài nguyên.
• IAM mặc định deny. Với dạng câu "policy này cho phép gì", chỉ cần một action không khớp bất kỳ dòng nào trong Action là loại phương án đó, không cần tìm câu Deny.
• Xác định quyền theo service prefix, không theo cảm giác chủ đề. Một việc "liên quan đến Lambda" vẫn có thể là action của service khác (iam:CreateRole), và khi đó lambda:* không giúp gì cả.
• Resource: "*" không mở rộng danh sách action. Nó chỉ bỏ giới hạn về tài nguyên cho những action đã được liệt kê; đọc nhầm nó thành "quyền toàn phần" là bẫy hay gặp.
• Cặp Create / Delete, List / Delete là chỗ đề hay đặt bẫy — luôn đối chiếu tên action trong phương án với đúng chuỗi ký tự có trong policy.

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

Đề mô tả một Lambda function xử lý dữ liệu rồi ghi vào Amazon RDS, và thông tin đăng nhập database đang nằm thẳng trong mã nguồn Lambda. Yêu cầu đặt ra có hai vế: credentials không được lưu ở dạng plaintext, và mật khẩu phải được xoay vòng (rotate) mỗi 30 ngày.

Cụm từ quyết định đáp án là "MOST operationally efficient". Đây là chìa khoá phân biệt, bởi vì cả A lẫn C đều về mặt kỹ thuật đáp ứng được hai yêu cầu chức năng: lưu credentials có mã hoá, và đổi mật khẩu định kỳ. Điểm khác nhau nằm ở khối lượng vận hành: một bên bắt bạn tự viết và tự bảo trì mã rotation, một bên dùng tính năng có sẵn của dịch vụ. Khi đề đã nói rõ "operationally efficient", phương án nào yêu cầu viết custom code và tự lo lịch chạy sẽ thua phương án dùng chức năng dựng sẵn.

Cụm thứ hai đáng để ý là "the password is rotated every 30 days" — đối tượng phải xoay vòng là mật khẩu database, chứ không phải một cái khoá mã hoá hay một certificate. Cụm này loại thẳng những phương án xoay vòng nhầm đối tượng.

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

Đáp án đúng theo tệp là C — AWS Secrets Manager.

Secrets Manager sinh ra đúng để giải bài toán này. Bạn tạo một secret chứa credentials của database, và với các loại secret dành cho Amazon RDS, Amazon DocumentDB và Amazon Redshift, Secrets Manager cho phép bật automatic rotation ngay trong lúc tạo secret: chọn RDS database tương ứng rồi đặt lịch xoay vòng.

Điểm mấu chốt là khi rotate, Secrets Manager cập nhật mật khẩu ở cả hai nơi cùng lúc — trong bản thân secret và trong chính database — nên không có khoảng thời gian mà ứng dụng cầm mật khẩu cũ còn database đã đổi. Cơ chế bên dưới vẫn là một Lambda rotation function (nó gọi Secrets Manager API để đọc/ghi secret, đồng thời gửi request tới database để đổi mật khẩu người dùng), nhưng với RDS thì bạn không phải tự viết hàm đó — đây chính là lý do nó "most operationally efficient".

Phần còn lại chỉ là sửa Lambda: thay vì hardcode chuỗi mật khẩu, gọi Secrets Manager để lấy credentials lúc chạy. Nhờ vậy credentials không còn nằm plaintext trong code, và mỗi lần rotate diễn ra thì Lambda tự nhiên lấy được giá trị mới mà không cần deploy lại.

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

A — Parameter Store SecureString + custom Lambda + EventBridge. Đây là phương án gần đúng nhất, và nó chạy được: SecureString mã hoá giá trị nên vế "không plaintext" đạt, EventBridge lo được lịch 30 ngày. Chỗ nó hỏng là Parameter Store không có chức năng tự động xoay vòng credentials. Bạn phải tự viết Lambda đổi mật khẩu, tự xử lý việc đồng bộ giữa RDS và Parameter Store, tự lo lỗi và tự bảo trì đoạn code đó về sau. So với việc bật một công tắc có sẵn trong Secrets Manager, đây là giải pháp tốn công vận hành hơn hẳn — nên nó thua ở đúng tiêu chí đề đưa ra.

B — KMS key + custom Lambda + environment variables. Sai ở chỗ xoay vòng nhầm đối tượng. KMS quản lý khoá mã hoá, không quản lý mật khẩu database. Phương án chỉ nói tạo key để mã hoá mật khẩu rồi cất bản mã trong environment variables, nhưng không hề chỉ ra cơ chế nào đảm bảo mật khẩu được đổi sau mỗi 30 ngày như đề yêu cầu. Ngoài ra, cất bí mật trong environment variables của Lambda nghĩa là mỗi lần đổi mật khẩu lại phải cập nhật cấu hình function — thêm một việc tay nữa, càng xa tiêu chí operationally efficient.

D — ACM certificate + certificate-based authentication. Sai về mặt bản chất dịch vụ. Certificate của ACM là SSL/TLS certificate, dùng để mã hoá kênh truyền và xác thực danh tính máy chủ, chứ không dùng được làm cơ chế xác thực giữa Lambda và Amazon RDS theo cách phương án mô tả. Đề hỏi về credentials đăng nhập database và việc xoay vòng mật khẩu; đáp án này thay thế hẳn bằng một mô hình xác thực khác mà AWS không hỗ trợ ở đây, nên nó không giải quyết được yêu cầu ban đầu.

📌 Điểm cần nhớ

• Thấy đề nhắc tới credentials của RDS / DocumentDB / Redshift kèm yêu cầu rotate định kỳ thì phản xạ đầu tiên là Secrets Manager với automatic rotation — đây là kịch bản dịch vụ đó được thiết kế sẵn cho.
• Parameter Store SecureString và Secrets Manager đều lưu bí mật có mã hoá, nhưng chỉ Secrets Manager có rotation dựng sẵn. Khi đề nhấn "operationally efficient" hay "least operational overhead", cụm đó thường chính là điểm phân biệt hai dịch vụ này.
• Cụm "custom Lambda function" xuất hiện trong một phương án gần như luôn là dấu hiệu trừ điểm ở những câu hỏi về hiệu quả vận hành: nó nghĩa là bạn nhận thêm code phải viết và phải bảo trì.
• Đọc kỹ đối tượng nào được xoay vòng. KMS xoay khoá mã hoá, ACM xoay certificate, Secrets Manager xoay chính credentials — đề yêu cầu đổi mật khẩu database thì hai cái đầu không đáp ứng dù nghe cũng có chữ "rotate".
• Không hardcode bí mật trong code Lambda, và cũng đừng coi environment variables là chỗ cất bí mật đạt chuẩn: bí mật nên nằm ở một secret store để ứng dụng lấy lúc chạy, nhờ đó rotate xong không cần deploy lại.

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

Đề mô tả một EC2 instance chạy Ubuntu đã cài sẵn SSM Agent, nhưng đội DevOps không mở được session bằng Session Manager. Câu hỏi là: sửa gì để kết nối được?

Cụm từ quyết định nằm ở hai chi tiết được cài cắm rất có chủ ý:

• "pre-configured with the AWS Systems Manager Agent (SSM Agent)" — agent đã có sẵn, nên nguyên nhân không phải là thiếu agent.
• "they possess the necessary IAM permissions and have successfully connected to other instances in the same subnet" — đây là mấu chốt. Quyền IAM của người dùng đã đủ, và các instance khác trong cùng subnet vẫn kết nối được, nghĩa là đường mạng ra endpoint của Systems Manager (route, NAT/VPC endpoint, NACL) hoạt động bình thường và không phải nguyên nhân.

Loại trừ hai thứ đó, chỉ còn lại một khác biệt thuộc về riêng instance này: quyền phía instance, tức IAM role (instance profile) gắn vào nó. Session Manager cần hai vế quyền độc lập — quyền của người gọi (đã xác nhận đủ) và quyền của chính instance để SSM Agent đăng ký với dịch vụ Systems Manager.

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

B — Gắn managed policy AmazonSSMManagedInstanceCore vào IAM role của instance Ubuntu.

SSM Agent không được dịch vụ "gọi vào"; chính nó phải chủ động dùng thông tin xác thực từ instance profile để đăng ký và giữ kênh liên lạc với Systems Manager. Nếu role của instance không có các quyền API cần thiết, agent chạy nhưng instance không bao giờ xuất hiện như một managed instance, và Session Manager không có gì để mở session tới — đúng với triệu chứng "đã có agent mà vẫn không vào được".

AmazonSSMManagedInstanceCore là managed policy do AWS cung cấp, chứa đúng bộ quyền tối thiểu để một EC2 instance được Systems Manager quản lý. Gắn nó vào role của instance là cách chuẩn tắc, và giải thích tiếng Anh trong nguồn cũng chốt đúng điểm này: đây là "minimum permissions necessary for the EC2 instance to be managed by the Systems Manager".

Điều này cũng giải thích luôn vì sao instance khác trong cùng subnet vẫn vào được: chúng có role đúng, còn instance này thì không.

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

A — Tạo key pair mới, cho Session Manager dùng key pair đó, phát private key cho đội DevOps. Sai từ tiền đề: Session Manager không xác thực bằng key pair. Cơ chế truy cập của nó dựa hoàn toàn vào IAM (policy của người gọi + role của instance), và đó chính là điểm hấp dẫn của nó — bỏ được việc quản lý, phân phát và xoay vòng private key. Không hề có tuỳ chọn "set Session Manager to utilize this key pair". Phát tán private key cho cả một đội còn đi ngược lại lý do người ta chọn Session Manager ngay từ đầu.

C — Thêm inbound rule mở port 22 trong security group. Đây là phương án gây nhiễu mạnh nhất, vì phản xạ quen thuộc của người quản trị Linux là "không vào được → mở SSH". Nhưng Session Manager không dùng port 22 và không cần bất kỳ inbound rule nào: kết nối do agent trên instance khởi tạo đi ra tới endpoint của Systems Manager, tức là chiều outbound. Security group mặc định cho phép outbound, nên không có gì phải mở vào. Mở 22 chẳng những không sửa được lỗi mà còn nới rộng bề mặt tấn công một cách vô ích.

D — Cấu hình lại SSM Agent để xác thực bằng username "admin". Nhầm tầng. SSM Agent chạy ở mức hệ thống như một dịch vụ, danh tính mà nó dùng để nói chuyện với Systems Manager là credential từ IAM role của instance, không phải một tài khoản OS. Không có khái niệm "đặt username cho agent để đăng nhập". Tài khoản OS chỉ liên quan tới việc phiên làm việc sau đó chạy dưới người dùng nào, và đó là chuyện khác hẳn với việc instance có kết nối được tới dịch vụ hay không.

📌 Điểm cần nhớ

• Session Manager cần hai vế quyền: IAM policy của người gọi và IAM role gắn trên instance. Đề nói "user đã đủ quyền" là đang đẩy bạn về vế thứ hai.
• AmazonSSMManagedInstanceCore là câu trả lời mặc định cho mọi triệu chứng kiểu "đã cài SSM Agent nhưng instance không hiện ra như managed instance".
• SSM Agent kết nối đi ra, nên Session Manager không đòi mở inbound port 22. Thấy phương án "mở port 22" trong câu về Session Manager thì gần như chắc chắn là mồi nhử.
• Session Manager không dùng key pair; mọi phương án dựa trên private key đều sai về nguyên lý, không chỉ sai về mức độ phù hợp.
• Chi tiết "các instance khác trong cùng subnet vẫn kết nối được" là cách đề loại bỏ nguyên nhân mạng — hãy đọc nó như một mệnh đề loại trừ, không phải thông tin thừa.

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

Đề mô tả một ứng dụng dùng Amazon RDS đặt trong một Region duy nhất, và công ty muốn bổ sung khả năng disaster recovery (DR) across geographic locations. Câu hỏi chốt lại: giải pháp nào cho RTO và RPO thấp nhất.

Có hai cụm từ quyết định đáp án, và phải đọc cả hai:

• "across geographic locations" — DR phải vượt ra khỏi Region hiện tại. Cụm này một mình đã loại được mọi phương án chỉ nằm trong một Region.
• "lowest RTO and RPO" — RTO là thời gian đưa hệ thống chạy lại, RPO là lượng dữ liệu chấp nhận mất. Cụm này phân biệt giữa các phương án còn lại: cùng là cross-Region cả, nhưng snapshot và replication cho hai mức RPO khác hẳn nhau.

Điểm mấu chốt: snapshot là ảnh chụp theo chu kỳ, còn read replica là dòng dữ liệu chảy liên tục. Chu kỳ chụp bao lâu thì RPO xấu nhất bằng đúng chừng đó.

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

Đáp án đúng theo tệp là C — Create a cross-Region read replica for the database.

Cross-Region read replica của Amazon RDS nhận thay đổi từ DB chính bằng asynchronous replication, tức là mọi ghi trên bản chính được đẩy sang bản replica ở Region khác một cách liên tục chứ không đợi tới mốc chụp tiếp theo. Độ trễ replication qua Region đúng là lớn hơn replica cùng Region — khoảng cách địa lý và đường truyền giữa các Region làm điều đó — nhưng nó vẫn nhỏ hơn hẳn khoảng cách giữa hai lần snapshot. Nghĩa là RPO thấp nhất trong các phương án hợp lệ.

Về RTO: khi Region chính hỏng, replica có thể được promote thành database độc lập. Đây là thao tác trên một instance đã tồn tại và đã có sẵn dữ liệu — không phải dựng mới. Trong khi đó mọi giải pháp dựa trên snapshot đều bắt buộc phải restore, tức là provision một DB instance hoàn toàn mới rồi nạp dữ liệu vào, mất nhiều thời gian hơn. Vậy C thắng ở cả hai chiều RTO và RPO cùng lúc.

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

A — Take automated snapshots and replicate them across Regions. Đây là phương án hợp lệ về mặt DR (dữ liệu thật sự nằm ở Region khác), nên không thể gạt đi nhanh — nó chỉ thua ở con số. Automated snapshot chạy theo chu kỳ, nên mọi thay đổi phát sinh sau lần chụp cuối cùng sẽ mất khi Region chính sập → RPO cao. Khi cần khôi phục lại phải restore snapshot thành một DB instance mới, tốn thêm thời gian provision → RTO cao. Đúng hướng, sai mức độ.

B — Run an AWS Lambda function on a schedule to create and copy snapshots across Regions. Về bản chất đây vẫn là phương án A, chỉ khác là tự viết cơ chế lập lịch bằng Lambda thay vì dùng automated snapshot có sẵn. Mọi nhược điểm của A giữ nguyên: dữ liệu chỉ mới tới thời điểm chụp gần nhất (RPO cao), và vẫn phải restore thành instance mới (RTO cao). Thêm vào đó là công sức tự vận hành phần lập lịch mà không đổi lại được RTO/RPO tốt hơn. Đây là bẫy kiểu "nghe có vẻ chủ động và tinh vi hơn" nhưng không cải thiện đúng chỉ số đề đang hỏi.

D — Create a Multi-AZ read replica for the database. Phương án này hỏng ngay ở yêu cầu đầu tiên, chứ không phải ở chỉ số. Multi-AZ là cơ chế chống hỏng trong phạm vi một Region — các Availability Zone là những khu vực hạ tầng tách biệt nhưng vẫn thuộc cùng một Region. Đề đòi DR across geographic locations, nên dù Multi-AZ có RTO/RPO rất tốt cho tình huống hỏng một AZ, nó không đáp ứng được yêu cầu địa lý. Đây là phương án gần đúng nguy hiểm nhất: nếu chỉ đọc lướt cụm "lowest RTO and RPO" mà bỏ qua "across geographic locations" thì rất dễ chọn nhầm D.

📌 Điểm cần nhớ

• Đọc ràng buộc phạm vi trước khi so sánh chỉ số: "across Regions / geographic locations" loại thẳng mọi giải pháp Multi-AZ, vì AZ nằm trong cùng một Region.
• Replication liên tục luôn cho RPO tốt hơn snapshot theo lịch. Với snapshot, RPO xấu nhất bằng đúng khoảng cách giữa hai lần chụp; với read replica, RPO chỉ bằng độ trễ replication.
• Promote một replica đã có sẵn nhanh hơn restore một snapshot thành instance mới, vì restore phải provision hạ tầng rồi mới nạp dữ liệu — đó là lý do read replica thắng luôn cả về RTO.
• Phương án "tự viết Lambda chạy theo lịch" thường chỉ là bản tự làm lại của cơ chế snapshot có sẵn; nếu nó không đổi được bản chất của RTO/RPO thì thêm phần tự vận hành cũng không giúp nó đúng hơn.

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

Đề mô tả một ứng dụng production chạy trên các subnet nằm ở những AWS account khác nhau nhưng trong cùng một Region. Yêu cầu là SysOps administrator phải map được Availability Zone giữa các account để bảo đảm high availability.

Cụm từ quyết định đáp án là "across accounts" (và "map Availability Zones"). Nếu bài toán chỉ nằm trong một account thì tên AZ kiểu us-east-1a là đủ để phân biệt, và hầu hết các phương án đều dùng được. Chính vì phải so khớp giữa hai account khác nhau nên câu hỏi rơi vào một đặc điểm rất riêng của AWS: tên AZ được ánh xạ ngẫu nhiên theo từng account. us-east-1a của account A hoàn toàn có thể là một AZ vật lý khác với us-east-1a của account B. AWS làm vậy để phân tán tải, tránh việc mọi khách hàng đều dồn tài nguyên vào "zone a".

Vì thế câu hỏi thực chất đang kiểm tra: bạn có biết thứ định danh nào của AZ là nhất quán trên mọi account hay không. Từ khoá phân biệt các phương án nằm ở đuôi tên trường trả về: Id hay Name.

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

Đáp án đúng theo tệp là A và E — cả hai đều so khớp bằng AZ ID.

E — DescribeAvailabilityZones, so khớp zoneId. Đây là cách trực tiếp nhất. AZ ID (ví dụ use1-az1 cho Region us-east-1) là định danh duy nhất và ổn định cho một Availability Zone: cùng một AZ ID thì chỉ đúng một địa điểm vật lý, giống hệt nhau ở mọi AWS account. Gọi API này ở cả hai account rồi ghép theo zoneId sẽ cho biết chính xác us-east-1a bên này tương ứng với zone nào bên kia.

A — DescribeSubnets, so khớp availabilityZoneId. Cùng nguyên lý, nhưng tiếp cận từ hướng tài nguyên. Vì bài toán nêu rõ ứng dụng chạy trên subnet, mà mỗi subnet lại gắn với đúng một AZ, nên phản hồi của DescribeSubnets cũng kèm sẵn trường availabilityZoneId. Cách này còn tiện hơn ở chỗ nó nói thẳng subnet nào nằm ở AZ vật lý nào, không cần bước tra cứu trung gian.

Đề yêu cầu chọn hai, và hai phương án này chính là hai đường lấy cùng một thông tin: qua API AZ hoặc qua API subnet.

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

B — DescribeSubnets, so khớp defaultForAz. Sai hoàn toàn về mục đích. defaultForAz là một giá trị boolean cho biết subnet đó có phải là default subnet của AZ hay không (subnet mà AWS tự tạo trong default VPC). Nó không mang bất kỳ thông tin định danh vị trí nào, và ở hai account thì rất nhiều subnet cùng trả về true — không thể ghép cặp được gì.

C — DescribeAvailabilityZones, so khớp zoneName. Đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. API được gọi là đúng API, chỉ sai đúng một trường. zoneName trả về tên kiểu us-east-1a — mà tên này được ánh xạ độc lập cho từng account. So khớp us-east-1a với us-east-1a sẽ ra kết quả "trùng khớp" trông rất thuyết phục nhưng có thể trỏ vào hai AZ vật lý khác nhau. Hậu quả đúng vào thứ đề bài muốn tránh: tưởng đã trải tài nguyên qua nhiều zone, thực tế lại dồn vào một zone, hoặc ngược lại.

D — DescribeSubnets, so khớp availabilityZoneName. Mắc đúng lỗi của C, chỉ khác điểm xuất phát. Gọi đúng API DescribeSubnets như phương án A, nhưng lấy trường Name thay vì Id. Vì tên AZ không nhất quán giữa các account, kết quả so khớp vẫn không đáng tin. Cặp A–D và cặp E–C được đặt cạnh nhau chính là để buộc người học phải chọn giữa Id và Name, chứ không phải chọn giữa hai API.

📌 Điểm cần nhớ

• Tên AZ (us-east-1a) chỉ có ý nghĩa trong phạm vi một account; AZ ID (use1-az1) mới là định danh vật lý dùng chung cho mọi account. Hễ đề nhắc tới việc so sánh, ghép cặp, hay map AZ giữa nhiều account, đáp án gần như chắc chắn xoay quanh AZ ID.
• Có hai đường lấy AZ ID và cả hai đều hợp lệ: DescribeAvailabilityZones → zoneId, và DescribeSubnets → availabilityZoneId. Câu hỏi kiểu "Select TWO" thường ghép đúng hai đường này lại.
• Khi các phương án chỉ khác nhau ở hậu tố tên trường (Id so với Name), hãy đọc lại ràng buộc trong đề trước khi chọn API — API đúng mà trường sai vẫn là đáp án sai.
• defaultForAz là cờ mô tả thuộc tính của subnet, không phải thông tin vị trí. Đừng nhầm một trường boolean với một định danh.

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

Đề mô tả một web application được tách thành các microservices chạy trên những Amazon EC2 instance khác nhau, và nhiệm vụ của SysOps administrator là định tuyến request tới đúng EC2 endpoint tương ứng với từng service.

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

• "separate microservices ... route connection requests to the appropriate EC2 endpoints" — đây không phải bài toán chia tải đều giữa các server giống hệt nhau, mà là bài toán định tuyến theo nội dung request (content-based routing): request tới /orders phải đi về nhóm EC2 chạy service đơn hàng, /users đi về nhóm khác. Muốn làm được thì thiết bị định tuyến phải đọc được tầng ứng dụng (HTTP).
• "with the LEAST administrative effort" — loại bỏ mọi phương án đòi ghép nhiều dịch vụ lại với nhau hoặc phải tự dựng thêm logic định tuyến. Cần một dịch vụ managed làm sẵn việc này bằng cấu hình rule.

Ghép hai ràng buộc lại: cần một load balancer hiểu HTTP, hỗ trợ path-based routing ngay trong listener rule.

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

D — Use an Application Load Balancer (ALB) and do path-based routing.

ALB hoạt động ở layer 7, nên nó phân tích được URL của request. Trong listener của ALB, bạn tạo các rule với điều kiện dựa trên đường dẫn URL và hành động forward tới target group tương ứng. Mỗi microservice có một target group riêng chứa các EC2 instance của nó, và ALB tự động đưa request về đúng nhóm dựa trên nội dung URL.

Đây chính xác là kịch bản mà tài liệu AWS mô tả: cấu trúc ứng dụng thành các service nhỏ hơn và route request tới đúng service dựa trên nội dung URL. Về mặt công sức vận hành, đây là cấu hình khai báo thuần tuý — thêm rule, gán target group — không phải viết code, không phải ghép thêm dịch vụ nào khác.

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

A — Amazon CloudFront và forward host header về origin. Đây là phương án gần đúng nhất về mặt "có dính tới định tuyến", nhưng nó hỏng ở chỗ forward header không phải là định tuyến. Việc chuyển tiếp host header chỉ đơn giản là đưa header đó xuống origin để origin tự xử lý — bản thân hành động này không đưa traffic tới đúng EC2 endpoint của từng microservice. Nghĩa là bạn vẫn chưa giải quyết được yêu cầu chính của đề, và phía sau vẫn cần một thứ khác đứng ra phân luồng.

B — Network Load Balancer và path-based routing. Phương án này "gần đúng" theo kiểu bẫy: nó nêu đúng kỹ thuật cần dùng (path-based routing) nhưng gắn vào sai dịch vụ. NLB hoạt động ở tầng thấp hơn, làm việc với kết nối TCP/UDP chứ không phân tích nội dung HTTP, nên NLB không hỗ trợ path-based routing. Bạn không thể tạo rule theo đường dẫn URL trên NLB. Cụm "path-based routing" đứng cạnh "NLB" là điểm sai duy nhất nhưng chí mạng.

C — AWS Global Accelerator với weighted routing policy. Sai ở hai tầng. Thứ nhất, weighted routing bản chất là chính sách của Route 53, và weighted routing chia traffic theo trọng số đã cấu hình — tức là theo tỷ lệ phần trăm, ngẫu nhiên với từng request. Nó không hề biết request này thuộc microservice nào để gửi đúng chỗ. Thứ hai, Global Accelerator sinh ra cho bài toán tối ưu đường mạng và điểm vào toàn cầu, không phải để phân luồng theo nội dung URL. Dùng nó ở đây vừa không đạt yêu cầu chức năng, vừa tăng công sức cấu hình — trái với "LEAST administrative effort".

📌 Điểm cần nhớ

• Định tuyến theo nội dung (path-based, host-based) là đặc quyền của layer 7 → chỉ ALB làm được. Thấy "path-based routing" hay "route by URL" trong đề thì gần như chắc chắn đáp án là ALB.
• NLB không đọc HTTP. Bất kỳ phương án nào ghép NLB với path/host/header-based routing đều là bẫy — chọn NLB khi đề nói về TCP/UDP, static IP, hoặc hiệu năng kết nối thuần.
• Phân biệt "forward header" với "route". Forward header chỉ là truyền thông tin xuống origin để origin tự xử lý; nó không tự nó quyết định traffic đi đâu.
• Weighted routing chia theo tỷ lệ, không chia theo ngữ nghĩa. Khi đề yêu cầu đưa request tới đúng thành phần nào đó, weighted/latency/geolocation routing đều sai — chúng phân phối theo tiêu chí khác chứ không đọc nội dung request.

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

Một công ty thương mại điện tử chạy website sau một Application Load Balancer (ALB) ở region Singapore. Khi lượng khách ở Bắc Mỹ tăng lên, họ gặp vấn đề độ trễ, nên dựng thêm một bản site nữa ở region Oregon. Câu hỏi: làm gì để giữ nguyên URL mà vẫn đưa người dùng tới endpoint có độ trễ thấp nhất?

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

• "maintain the URL" — tên miền không được đổi, người dùng vẫn gõ đúng một địa chỉ. Nghĩa là việc phân luồng phải xảy ra ở tầng DNS, trên chính bản ghi Route 53 đang có, chứ không phải bắt khách Bắc Mỹ dùng một hostname khác.
• "route users to the lowest latency endpoint" — tiêu chí chọn region là độ trễ mạng đo được, không phải vị trí địa lý, không phải chia tải, không phải danh sách nhiều giá trị.

Cụm thứ hai chính là ràng buộc phân biệt bốn phương án, vì cả bốn đều là thao tác trên Route 53 và đều giữ nguyên URL. Chỉ có một chính sách định tuyến lấy latency làm tiêu chí.

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

A. Chuyển bản ghi Route 53 hiện có sang latency routing policy, tạo hai latency record trỏ tới hai ALB tương ứng.

Latency routing policy được thiết kế đúng cho tình huống này: cùng một tên miền có nhiều resource record set, mỗi cái gắn với một region. Khi có truy vấn DNS, Route 53 dựa trên dữ liệu độ trễ mạng giữa người dùng và các region để trả về resource cho kết quả nhanh nhất với chính người dùng đó. Khách ở Bắc Mỹ sẽ nhận DNS name của ALB tại Oregon, khách ở châu Á nhận ALB tại Singapore — mà tên miền công khai không đổi chút nào.

Chi tiết "hai latency record" cũng đúng về mặt cấu hình: latency routing cần mỗi endpoint một record riêng, cùng tên và cùng loại, mỗi record khai region tương ứng. Một record đơn lẻ không diễn đạt được lựa chọn.

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

B. Geolocation routing policy, mỗi region trỏ tới ALB tương ứng. Đây là phương án gần đúng nhất, và trong nhiều trường hợp thực tế nó cho kết quả trông giống nhau — khách Bắc Mỹ vẫn đi về Oregon. Nhưng nó hỏng ở tiêu chí: geolocation quyết định theo vị trí địa lý suy ra từ truy vấn DNS, không đo độ trễ. Đường mạng nhanh nhất không phải lúc nào cũng là region gần nhất về địa lý. Geolocation dùng đúng khi mục đích là bản địa hoá nội dung, hiển thị đúng ngôn ngữ, hoặc tuân thủ ràng buộc pháp lý theo quốc gia — còn đề bài nói thẳng vấn đề là latency.

C. Multivalue answer routing policy, thêm DNS name của ALB mới. Multivalue answer trả về nhiều giá trị cùng lúc cho một truy vấn, kèm health check, và client tự chọn một trong số đó. Nó giúp tăng khả năng sẵn sàng và rải tải một cách thô sơ, nhưng hoàn toàn không có khái niệm "endpoint nào nhanh hơn". Khách Bắc Mỹ vẫn có thể vớ phải ALB ở Singapore, và vấn đề độ trễ không được giải quyết.

D. Gắn thêm DNS name của ALB Oregon vào bản ghi Route 53 hiện có. Đây là phương án yếu nhất: chỉ nhét thêm một giá trị vào record mà không đổi routing policy. Không có chính sách nào ra quyết định, nên chẳng có gì bảo đảm traffic đi tới region cho độ trễ thấp nhất. Nó chỉ là thao tác cơ học, không hề trả lời câu hỏi.

📌 Điểm cần nhớ

• Đề nhắc "lowest latency" hoặc "fastest response time" → chọn latency routing policy. Đề nhắc quốc gia, châu lục, bản địa hoá nội dung, tuân thủ theo vùng → chọn geolocation routing policy. Hai cái này rất hay bị đưa cạnh nhau trong cùng một câu.
• Latency routing cần một record riêng cho mỗi region, cùng tên và cùng loại record — không phải nhét nhiều giá trị vào một record.
• Multivalue answer thiên về khả năng sẵn sàng và trả nhiều giá trị cho client tự chọn, không hề tối ưu theo hiệu năng đường truyền.
• Yêu cầu "giữ nguyên URL" gần như luôn hàm ý lời giải nằm ở tầng DNS của Route 53, tức là đổi routing policy trên chính bản ghi đang dùng, chứ không phải cấp thêm hostname mới cho người dùng.