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

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

Một hãng sản xuất dùng Amazon RDS để theo dõi kho hàng, và nhiều AWS Lambda function kết nối tới database bằng thông tin đăng nhập nhúng thẳng trong code. Yêu cầu đặt ra có hai vế:

1. Credentials không được lưu ở dạng plaintext.
2. Mật khẩu phải đổi mỗi 30 ngày.

Cụm từ quyết định là "in the most operationally effective way" (cách vận hành hiệu quả nhất). Đây là dấu hiệu kinh điển: cả bốn phương án đều có thể làm được việc, nhưng ba trong số đó bắt bạn tự viết và tự nuôi một Lambda xoay mật khẩu, tự lên lịch, tự cập nhật nơi lưu trữ. Cụm thứ hai cần chú ý là "Amazon RDS" — RDS nằm trong nhóm database mà AWS có sẵn tích hợp xoay credentials tự động, nên nó mở đường cho một dịch vụ làm hộ toàn bộ việc đó.

Nói gọn: đề không hỏi "cách nào chạy được", mà hỏi "cách nào ít việc tay nhất mà vẫn đạt cả hai yêu cầu".

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

Đáp án D — AWS Secrets Manager.

Secrets Manager sinh ra đúng cho bài toán này: lưu trữ và quản lý secrets dùng để truy cập tài nguyên trên AWS, dịch vụ bên thứ ba và cả hệ thống on-premises. Điểm mấu chốt hợp với đề: Secrets Manager có hỗ trợ sẵn việc rotation credentials cho Amazon RDS (cùng với Amazon DocumentDB và Amazon Redshift). Nó tích hợp trực tiếp với các dịch vụ này để xoay secret một cách an toàn mà không cần sửa code ứng dụng.

Khi cấu hình rotation tự động, bạn chỉ khai báo chu kỳ — ở đây là 30 ngày. Đến hạn, Secrets Manager tự kích hoạt một Lambda function để đổi mật khẩu; bạn không phải viết logic xoay, không phải dựng lịch EventBridge riêng, không phải lo đồng bộ giá trị mới về từng nơi.

Các Lambda function làm việc với database chỉ cần sửa lại để đọc mật khẩu mới nhất từ Secrets Manager mỗi lần cần kết nối. Nhờ vậy chúng luôn dùng đúng phiên bản hiện hành của mật khẩu, kể cả ngay sau một lần rotation. Cả hai yêu cầu của đề — không plaintext, đổi mật khẩu định kỳ 30 ngày — được đáp ứng bằng cấu hình chứ không bằng code tự viết.

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

A — KMS mã hoá mật khẩu rồi để trong environment variable. Đây là phương án "an toàn về mặt mã hoá" nhưng lệch mục đích dịch vụ. AWS KMS chủ yếu là dịch vụ quản lý khoá, nó không được thiết kế để tự xoay credentials. Bạn vẫn phải tự viết Lambda xoay mật khẩu, rồi sau mỗi lần xoay lại phải mã hoá lại giá trị mới và cập nhật environment variable cho từng function. So với Secrets Manager — thứ được làm ra đúng cho việc này và xoay tự động — cách này kém hiệu quả về vận hành hơn hẳn.

B — Lưu mật khẩu thẳng trong environment variable + Lambda xoay + EventBridge. Đây là phương án yếu nhất và hỏng cả hai vế của đề. Thứ nhất, lưu mật khẩu trong environment variable dạng plaintext là không an toàn, vi phạm trực tiếp yêu cầu "không lưu plaintext" — đáng chú ý là nó còn không dùng KMS như phương án A. Thứ hai, việc rotation là thủ công: bạn tự viết, tự lên lịch, và còn phải cập nhật lại biến môi trường cho mọi function — nhiều bước hơn, dễ sai sót hơn so với rotation tự động của Secrets Manager.

C — Parameter Store SecureString + Lambda xoay + EventBridge. Đây là phương án gần đúng nhất, và cũng là bẫy chính của câu hỏi. Nó đạt vế thứ nhất: SecureString giải quyết được chuyện plaintext, Parameter Store cho lưu trữ cấu hình và secrets có phân cấp, an toàn. Chỗ nó hỏng nằm ở vế thứ hai: Parameter Store không hỗ trợ tự động xoay mật khẩu như Secrets Manager. Vì thế bạn buộc phải tự dựng Lambda rotation, tự lên lịch EventBridge, tự viết bước cập nhật giá trị mới vào Parameter Store — tức là quá trình rotation về bản chất vẫn là thủ công. Đề hỏi "operationally effective", nên một giải pháp đúng nhưng phải tự nuôi thêm code và lịch chạy sẽ thua giải pháp có sẵn tính năng đó.

📌 Điểm cần nhớ

• Đề nhắc "rotation tự động" cho RDS/DocumentDB/Redshift → nghĩ tới Secrets Manager trước tiên. Đây là tích hợp có sẵn, khai báo chu kỳ là xong, không cần sửa code ứng dụng.
• Parameter Store SecureString vs Secrets Manager: cả hai đều lưu secret an toàn, không plaintext. Ranh giới phân biệt trong đề thi thường là rotation tự động — có yêu cầu đó thì chọn Secrets Manager; chỉ cần lưu trữ an toàn thuần tuý thì Parameter Store là lựa chọn hợp lý.
• KMS không phải nơi lưu secret, nó là nơi quản lý khoá. Thấy phương án dùng KMS để "giữ mật khẩu" thì hãy hỏi ai sẽ lo phần xoay và phần phân phối giá trị mới.
• Environment variable của Lambda không phải chỗ cất credentials. Nó ở dạng plaintext, và mỗi lần đổi mật khẩu lại phải cập nhật thủ công cho từng function.
• Cụm "most operationally effective/efficient" là chỉ dẫn chấm điểm: khi nhiều phương án đều chạy được, phương án dùng tính năng managed có sẵn thắng phương án bắt bạn tự viết Lambda và tự lên lịch.

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

Đề mô tả một tổ chức chạy nhiều EC2 instance ở nhiều region, và đặt ra hai yêu cầu tách bạch:

1. EC2 không được để lộ SSH ra Internet — tức là phải phát hiện được security group nào đang mở port 22 cho 0.0.0.0/0.
2. Security group rules phải được tự động sửa để gỡ quyền truy cập đó khi bị phát hiện — tức là phải có phần khắc phục (remediation).

Cụm từ quyết định đáp án là "should be automatically modified to remove this access if it is detected". Nó chia câu hỏi thành đúng hai vế: detect và remediate. Đề yêu cầu chọn TWO, nghĩa là mỗi phương án đúng phải gánh một vế. Bất kỳ phương án nào chỉ cảnh báo, chỉ ghi log, hoặc chỉ thông báo mà không sửa rule đều rơi ngay ở vế thứ hai — dù nghe rất hợp lý ở vế thứ nhất.

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

C — AWS Config rule kiểm tra security group có cho phép SSH từ 0.0.0.0/0 hay không. Đây là vế detect. AWS Config theo dõi cấu hình tài nguyên AWS và đánh giá chúng theo các rule mà bạn định nghĩa. Với security group, Config đánh giá chính trạng thái cấu hình (inbound rule nào đang mở, cho dải CIDR nào), rồi gắn nhãn compliant / non-compliant. Đây đúng là kiểu bài toán "tài nguyên đang ở cấu hình sai" chứ không phải "có ai đó vừa làm hành động gì".

B — AWS Systems Manager Automation document để cập nhật các security group rule đã bị đánh dấu. Đây là vế remediate. Automation document đóng gói các bước vận hành lặp đi lặp lại thành một quy trình chạy được tự động trên tài nguyên AWS. Khi Config đã chỉ ra security group non-compliant, Automation document sẽ thực hiện việc thu hồi inbound rule mở SSH. Cặp B + C ghép lại thành đúng luồng mà đề mô tả: Config phát hiện → Automation sửa.

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

A — EventBridge phát hiện thay đổi security group rồi kích hoạt Lambda để sửa. Đây là phương án gần đúng nhất, vì phần Lambda thực sự sửa được rule. Chỗ nó hỏng nằm ở vế phát hiện: EventBridge là dịch vụ định tuyến sự kiện, bản thân nó không có chức năng sẵn để soi cấu hình security group và kết luận rule nào đang mở SSH ra Internet. Nó phản ứng theo sự kiện đi tới, không đánh giá trạng thái cấu hình hiện có. Hệ quả thực tế: các security group đã mở sẵn từ trước (không phát sinh thay đổi nào mới) sẽ không bao giờ được xử lý — trong khi đề nói rõ là phát hiện nếu tình trạng đó tồn tại.

D — GuardDuty detector giám sát và cảnh báo khi security group cho phép SSH từ 0.0.0.0/0. Hỏng ở hai điểm. Thứ nhất, GuardDuty là dịch vụ threat detection — nó phân tích dấu hiệu hành vi độc hại, không phải công cụ đánh giá tuân thủ cấu hình security group theo rule bạn đặt ra. Thứ hai, ngay cả khi phát hiện được, GuardDuty chỉ alert, hoàn toàn không sửa rule — vế "automatically modified to remove this access" không được đáp ứng.

E — CloudTrail giám sát thay đổi security group rồi gửi thông báo tới SNS topic. CloudTrail đúng là ghi lại được lời gọi API thay đổi security group, nên phần "biết có chuyện xảy ra" là hợp lý. Nhưng đầu ra ở đây dừng ở một notification gửi vào SNS: có người nhận được thư, còn port vẫn mở nguyên. Đây là con đường thông báo cho người, không phải tự động khắc phục. Cùng lỗi nền tảng với A: CloudTrail ghi hành động đã diễn ra, không đánh giá cấu hình đang tồn tại, nên security group mở sẵn từ trước cũng nằm ngoài tầm.

📌 Điểm cần nhớ

• Câu hỏi kiểu "detect + auto-remediate" thường cần hai dịch vụ ghép lại: một cái đánh giá, một cái sửa. Đọc kỹ xem phương án bạn chọn phủ vế nào — chọn hai phương án cùng phủ một vế là sai.
• Phân biệt đánh giá cấu hình với ghi nhận sự kiện: AWS Config trả lời "tài nguyên này đang đúng chuẩn không?", còn CloudTrail/EventBridge trả lời "vừa có ai làm gì?". Yêu cầu quét cả tài nguyên có sẵn thì nghiêng về Config.
• Alert ≠ remediate. Phương án dừng ở SNS notification hay ở cảnh báo của GuardDuty sẽ luôn thiếu, khi đề dùng chữ "automatically modified", "automatically remediate" hay "without manual intervention".
• GuardDuty là threat detection, không phải compliance. Thấy nó xuất hiện trong câu hỏi về "security group có mở port X không" thì gần như chắc là mồi nhử; bài toán tuân thủ cấu hình thuộc về AWS Config.
• Systems Manager Automation document là đáp án quen thuộc cho phần hành động khắc phục có thể lặp lại trên tài nguyên AWS, đặc biệt khi ghép sau một Config rule.

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

Đề mô tả một ứng dụng sinh ra dữ liệu phải được lưu trữ ít nhất 7 năm, dùng Amazon Glacier để archive, và hỏi cấu hình nào đáp ứng được yêu cầu đó.

Cụm từ quyết định là "compliance requirement" đi kèm "must be archived for at least 7 years". Hai chữ này gộp lại có nghĩa rất hẹp: không phải "hãy lưu dữ liệu vào Glacier" (chuyện đó Glacier vốn đã làm), mà là phải có một cơ chế cưỡng chế việc giữ dữ liệu, không cho ai — kể cả chính người quản trị tài khoản — xoá sớm hoặc nới lỏng luật. Đây chính là mô hình WORM (write once read many) mà các quy định tài chính, y tế, kiểm toán hay đòi hỏi.

Cả bốn phương án đều là "một loại cấu hình của Glacier vault", nghe rất giống nhau. Ràng buộc phân biệt chúng nằm ở chỗ: cái nào có tính bất biến (immutable), khoá lại được và không sửa được về sau? Chỉ có một cái làm được điều đó.

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

C — A Glacier vault lock policy.

Vault Lock cho phép gắn vào từng vault một policy chứa các control tuân thủ, ví dụ "không được xoá archive trước khi đủ 7 năm". Điểm mấu chốt là quy trình khoá gồm hai bước: khởi tạo policy ở trạng thái in-progress để kiểm thử, rồi lock nó lại. Sau khi đã lock, policy không còn sửa hay gỡ được nữa — Glacier tự cưỡng chế các điều kiện trong đó.

Chính tính "khoá vĩnh viễn" này là thứ đáp ứng yêu cầu compliance: kiểm toán viên không chỉ cần thấy bạn có ý định giữ dữ liệu 7 năm, mà cần bằng chứng rằng không ai có thể xoá nó sớm, kể cả người có quyền quản trị. Vault lock policy được viết bằng chính ngôn ngữ policy của IAM, nên diễn đạt được điều kiện dạng "chặn DeleteArchive khi archive chưa đủ tuổi X".

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

A — A Glacier vault notification. Đây là cấu hình thông báo: khi một job trên vault hoàn tất, Glacier gửi message tới một SNS topic. Nó thuần tuý là cơ chế báo tin về tiến độ công việc, không hề can thiệp vào quyền xoá hay thời gian lưu giữ. Có bật hay không thì dữ liệu vẫn xoá được như thường.

B — A Glacier data retrieval policy. Phương án bẫy nặng nhất vì chữ "retrieval" dễ bị đọc nhầm thành "retention". Nhưng data retrieval policy dùng để đặt hạn mức và quản lý hoạt động lấy dữ liệu ra trong một AWS account theo từng Region — nghĩa là kiểm soát chuyện đọc/tải về (và chi phí đi kèm), chứ hoàn toàn không nói gì tới việc dữ liệu được giữ lại bao lâu hay có bị xoá hay không. Nó chặn đường ra, không chặn đường xoá.

C là đáp án đúng (xem mục trên).

D — A Glacier vault access policy. Đây là phương án gần đúng nhất và đáng nói kỹ. Vault access policy là một resource-based policy dùng để quản lý quyền truy cập vào vault, và về mặt cú pháp nó hoàn toàn có thể chứa một câu Deny cho hành động xoá. Vậy nó hỏng ở đâu? Ở chỗ nó sửa được và gỡ được bất cứ lúc nào. Ai có quyền chỉnh policy chỉ cần bỏ câu Deny đi là xoá dữ liệu được ngay. Với một yêu cầu compliance, một biện pháp có thể bị chính người vận hành vô hiệu hoá trong vài giây thì không phải là biện pháp cưỡng chế. Đúng sự khác biệt này là lý do AWS tách riêng vault lock policy ra khỏi vault access policy: cùng ngôn ngữ policy, nhưng một cái immutable sau khi lock, một cái thì không.

📌 Điểm cần nhớ

• Thấy "compliance", "retention", "WORM", "không được xoá trong N năm" trong đề Glacier → nghĩ ngay tới Vault Lock. Đó là cấu hình duy nhất của Glacier mang tính bất biến.
• Phân biệt cho chắc bốn thứ dễ lẫn: vault lock policy = luật tuân thủ khoá vĩnh viễn; vault access policy = phân quyền truy cập, sửa được; data retrieval policy = hạn mức lấy dữ liệu ra theo account/Region; vault notification = báo tin qua SNS khi job xong.
• Nguyên tắc chung khi chọn giữa hai phương án cùng làm được một việc: đề nhấn compliance thì tiêu chí không phải "có chặn được không" mà là "có thể bị người trong nội bộ gỡ bỏ không". Cái gỡ được luôn thua.
• Vault Lock có bước khởi tạo rồi mới khoá — thiết kế như vậy để kiểm thử policy trước, vì một khi đã lock thì không quay lại được.

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

Đề mô tả một static website chạy trên Amazon S3, phục vụ hàng nghìn người dùng khắp thế giới, và ngay sau khi ra mắt thì người dùng báo lỗi 503 Service Unavailable. Câu hỏi yêu cầu chỉ ra nguyên nhân có khả năng nhất.

Cụm từ quyết định đáp án nằm ở chính mã lỗi 503 — chứ không phải ở kiến trúc hay quyền truy cập. Trong HTTP, họ mã 5xx nghĩa là phía server không phục vụ được yêu cầu, còn lỗi do phía client (sai quyền, tài nguyên không tồn tại, chữ ký hết hạn) luôn rơi vào họ 4xx. Cụm thứ hai bổ trợ là "thousands of users from around the world" ngay sau khi launch: một lượng truy cập lớn dồn vào cùng một prefix trong khoảng thời gian rất ngắn.

Ghép hai manh mối lại: server-side error + request rate tăng vọt → đây là kịch bản S3 trả 503 vì tốc độ request quá cao so với mức nó đang scale tới.

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

B — The request rate to Amazon S3 is too high.

S3 có khả năng mở rộng rất lớn, nhưng việc mở rộng đó diễn ra dần dần: khi lưu lượng tới một prefix tăng đột ngột, S3 cần thời gian để phân vùng lại và nâng năng lực phục vụ. Trong giai đoạn đó, các request vượt quá năng lực hiện thời sẽ bị trả về 503 Slow Down / Service Unavailable — đúng loại lỗi mà người dùng đang báo.

Bối cảnh trong đề khớp hoàn hảo: website vừa ra mắt (S3 chưa có thời gian scale theo lưu lượng thực tế) và hàng nghìn người dùng đổ vào cùng lúc, tất cả đều đọc từ cùng một bucket static website. Đây chính là kiểu tải mà tài liệu AWS mô tả là nguyên nhân phổ biến nhất của lỗi 5xx trên S3.

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

A — The users do not have the correct permissions to access the website. Đây là phương án gần đúng nhất về mặt "nghe hợp lý", nhưng nó hỏng ở mã lỗi. Thiếu quyền trên S3 (bucket policy chưa cho public read, ACL chặn, v.v.) trả về 403 Access Denied, một lỗi 4xx phía client — không phải 503. Ngoài ra, nếu là vấn đề quyền thì lỗi đã xuất hiện với mọi người ngay từ request đầu tiên, chứ không phải phát sinh sau khi lượng truy cập tăng.

C — The pre-signed URL has expired and no longer exists. Sai ở hai điểm. Thứ nhất, pre-signed URL hết hạn cũng cho lỗi phía client (4xx), không phải 503. Thứ hai, một static website công khai không dùng pre-signed URL để phục vụ trang cho hàng nghìn người ẩn danh — pre-signed URL là cơ chế cấp quyền truy cập tạm thời cho một object riêng lẻ, không phải cách vận hành một website tĩnh.

D — There is an issue with the S3 Transfer Acceleration service. Sai vì nhầm chiều dữ liệu. S3 Transfer Acceleration là tính năng tăng tốc truyền dữ liệu vào/ra bucket qua edge location của CloudFront, chủ yếu dùng cho upload dữ liệu lớn từ xa. Nó không phải thành phần nằm trên đường phục vụ static website endpoint, nên nó không phải "nguyên nhân có khả năng nhất" ở đây. Đề cũng không hề nhắc tới việc bật tính năng này.

📌 Điểm cần nhớ

• Đọc mã lỗi trước khi đọc kịch bản. 4xx = lỗi phía client (403 Access Denied, 404 Not Found, chữ ký/pre-signed URL hết hạn); 5xx = lỗi phía service. Riêng chi tiết này đã loại được A và C trong câu này.
• 503 trên S3 gắn liền với request rate quá cao. S3 scale được rất lớn nhưng cần thời gian nâng năng lực khi lưu lượng tới một prefix tăng đột ngột; giai đoạn quá độ đó chính là lúc 503 xuất hiện.
• Vấn đề về quyền không bao giờ biểu hiện thành 503. Thấy phương án nói về permission mà đề ghi 5xx thì loại ngay.
• S3 Transfer Acceleration là chuyện tăng tốc truyền dữ liệu tới bucket, không phải chuyện phục vụ static website. Gặp phương án nêu một tính năng không nằm trên đường đi của request trong đề thì đó là mồi nhử.

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

Đề mô tả một máy trong data center (IP 3.104.75.244) ping một EC2 instance nằm ở private subnet (172.31.10.10) qua VPN, và không nhận được phản hồi. Câu hỏi yêu cầu tìm nguyên nhân có khả năng nhất.

Cụm từ quyết định nằm ngay trong hai dòng VPC Flow Logs, chứ không nằm trong phần văn xuôi:

• Dòng 1: 3.104.75.244 → 172.31.10.10 ... ACCEPT — gói tin đi vào được chấp nhận.
• Dòng 2: 172.31.10.10 → 3.104.75.244 ... REJECT — gói tin đi ra (chính là ICMP echo reply) bị chặn.

Hai chi tiết ghép lại cho ra một kết luận rất hẹp: chiều inbound hoàn toàn ổn, vấn đề nằm ở chiều outbound. Và vì luồng bị chặn là traffic trả lời của một kết nối đã được chấp nhận, ràng buộc thứ hai xuất hiện: chỉ có thành phần lọc stateless mới có thể chặn được nó. Trong VPC, thành phần stateless là network ACL; security group là stateful.

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

Đáp án đúng theo tệp là D — cần sửa network ACL để cho phép traffic outbound tới máy on-premises.

Network ACL hoạt động ở mức subnet và stateless: nó đánh giá từng gói tin độc lập, không ghi nhớ rằng gói đi vào trước đó đã được cho qua. Vì vậy một luồng hai chiều cần hai rule riêng biệt — một rule inbound cho gói đi vào, một rule outbound cho gói trả lời đi ra.

Flow log cho thấy rule inbound đã có (dòng ACCEPT), nhưng gói trả lời từ instance ra ngoài bị REJECT. Đúng khớp với tình huống network ACL thiếu rule outbound cho phép đi tới 3.104.75.244. Máy on-premises ping không thấy trả lời chính vì echo reply chết ngay tại biên subnet.

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

A. Sửa security group để cho phép outbound tới máy on-premises — đây là phương án gần đúng nhất và là bẫy chính của câu hỏi. Đúng là chiều bị chặn là outbound, nhưng security group stateful: khi một kết nối đã được cho phép đi vào, traffic trả lời tự động được cho ra, bất kể rule outbound viết thế nào. Thêm nữa, security group mặc định đã cho phép toàn bộ outbound. Nên dù có sửa outbound rule của security group cũng không giải quyết được gì.

B. Sửa network ACL để cho phép inbound từ máy on-premises — đúng thành phần (network ACL) nhưng sai chiều. Dòng flow log đầu tiên đã ghi ACCEPT cho luồng inbound, chứng minh rule inbound đang hoạt động bình thường. Sửa thứ đã đúng thì không thay đổi được kết quả.

C. Sửa security group để cho phép inbound từ máy on-premises — sai cả hai mặt: sai chiều (inbound đã ACCEPT) và sai thành phần (kể cả nếu security group chặn thì cũng chặn ở chiều vào, mà chiều vào rõ ràng đã thông). Đây là phương án dễ loại nhất.

📌 Điểm cần nhớ

• Security group là stateful, network ACL là stateless. Hễ đề bài cho thấy traffic trả lời bị chặn trong khi traffic đi vào được chấp nhận, thủ phạm gần như luôn là network ACL, không phải security group.
• Network ACL cần rule cho cả hai chiều cho mỗi luồng giao tiếp; quên chiều outbound là lỗi kinh điển, và triệu chứng là "kết nối tới được nhưng không bao giờ có phản hồi".
• Đọc VPC Flow Logs theo cặp source → destination. So sánh địa chỉ nguồn/đích của từng dòng với ACCEPT/REJECT sẽ chỉ thẳng ra chiều nào đang hỏng, thu hẹp bốn phương án xuống còn một rất nhanh.
• Security group áp ở mức ENI của instance, network ACL áp ở mức subnet. Khi khoanh vùng sự cố, xác định chiều nào hỏng trước, rồi mới xác định thành phần nào dựa vào tính stateful/stateless.

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

Đề mô tả một health check của Amazon Route 53 kiểu String Matching (loại HTTP_STR_MATCH). Chuỗi cần tìm là /html — tức thẻ đóng cuối trang, được chọn với ý đồ "nếu thấy nó thì trang đã tải xong hoàn toàn". Health check báo failed, nhưng khi mở trang bằng trình duyệt thì trang hiện ra bình thường.

Cụm từ quyết định nằm ở chính chỗ ghép hai chi tiết đó lại: "searching for /html at the end of the page" và "the page loads successfully when navigating directly to it".

• Trang tải được ⇒ endpoint sống, TCP bắt tay được, HTTP trả về mã thành công. Vậy nguyên nhân không nằm ở kết nối hay ở trạng thái server.
• Chuỗi nằm ở cuối trang ⇒ vị trí của nó trong response body là điều đáng ngờ nhất, vì Route 53 không đọc toàn bộ body khi so khớp.

Nói cách khác, đề đang kiểm tra một điều duy nhất: bạn có nhớ rằng String Matching chỉ soi một phần đầu có giới hạn của response body hay không.

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

C — The search string is not in the first 5120 bytes of the response body.

Cách hoạt động của HTTP_STR_MATCH: Route 53 mở kết nối TCP tới endpoint; nếu thành công thì gửi một HTTP request và tìm chuỗi SearchString trong 5.120 byte đầu tiên của response body. Thấy chuỗi thì coi là healthy; không thấy — hoặc endpoint không phản hồi — thì coi là unhealthy. Chuỗi phải nằm trọn vẹn trong khoảng byte đó, không được nằm vắt qua ranh giới.

Đặt vào tình huống của đề: quản trị viên cố tình chọn chuỗi ở cuối trang. Với một trang HTML thật, phần cuối gần như chắc chắn vượt quá 5.120 byte đầu. Trình duyệt tải hết body nên vẫn hiển thị bình thường, còn Route 53 dừng đọc sớm hơn nhiều nên không bao giờ nhìn thấy chuỗi → health check fail dù trang hoàn toàn khỏe mạnh. Đúng khớp với nghịch lý mà đề mô tả.

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

A — The search string is not HTML-encoded. Route 53 so khớp chuỗi trên byte thô của response body, không phân tích HTML và không đòi hỏi bạn mã hoá gì. /html gõ nguyên văn là hợp lệ. Nếu Route 53 có yêu cầu HTML-encode thì lỗi sẽ xảy ra ngay cả với trang rất ngắn, mà điều đó không phải cách dịch vụ này làm việc.

B — The search string should not include the forward slash (/). Đây là phương án dễ mắc bẫy nhất, vì nhìn thoáng qua dấu / trông giống ký tự đặc biệt cần thoát. Thực tế dấu gạch chéo là một ký tự bình thường trong search string, không bị cấm và cũng không cần escape. Hơn nữa, nếu bỏ dấu / đi thì chuỗi thành html — chuỗi này còn khớp cả thẻ mở <html> ở đầu trang, tức là health check sẽ pass chứ không fail. Phương án này vừa sai về luật, vừa mâu thuẫn với triệu chứng đang quan sát được.

C — đã giải thích ở trên.

D — The search string must be longer than 4 characters. Không có ràng buộc độ dài tối thiểu cho search string. Ngoài ra bản thân lập luận trong phương án cũng tự mâu thuẫn: /html có 5 ký tự, nên kể cả giả sử tồn tại ngưỡng "dài hơn 4 ký tự" thì chuỗi này vẫn thoả — không giải thích được vì sao check fail.

📌 Điểm cần nhớ

• String Matching của Route 53 chỉ soi phần đầu của response body (5.120 byte đầu), không đọc hết trang. Chuỗi phải nằm trọn trong khoảng đó.
• Vì vậy, chọn chuỗi ở gần đầu trang — một marker do ứng dụng chủ động đặt sớm trong body — thay vì bám vào thẻ đóng cuối trang để "chứng minh trang tải xong".
• Triệu chứng "trang mở bằng trình duyệt thì bình thường nhưng health check fail" là dấu hiệu đặc trưng của lỗi cấu hình chính health check, không phải lỗi endpoint: sai chuỗi, sai vị trí chuỗi, sai path, hoặc sai kiểu health check.
• Search string là so khớp chuỗi thô: phân biệt hoa thường theo nội dung thực tế, không cần HTML-encode, không cấm ký tự như /, và không có yêu cầu độ dài tối thiểu.

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

Đề mô tả một website đang dùng Amazon ElastiCache for Memcached, người vận hành thấy CPU utilization cao trên CloudWatch và hỏi phải làm gì để xử lý. Câu hỏi yêu cầu chọn HAI phương án.

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

1. "Memcached" — không phải Redis. Memcached là engine hỗ trợ phân mảnh dữ liệu (partitioning) qua nhiều node, nên nó mở rộng theo chiều ngang rất tự nhiên: thêm node là thêm sức chứa và thêm CPU. Đây là điều làm phương án A hợp lệ.
2. "high CPU utilization" — nút thắt nằm ở CPU của node cache, không phải ở dung lượng đĩa, không phải ở việc phân phối kết nối mạng. Bất kỳ phương án nào không làm tăng lượng CPU sẵn có cho cluster đều bị loại ngay.
3. "cluster" + "(Select TWO)" — đề chờ đợi hai hướng mở rộng kinh điển của Memcached: scale out (thêm node) và scale up (đổi sang node type lớn hơn).

Nói cách khác, đây là câu kiểm tra xem bạn có nắm được rằng ElastiCache Memcached mở rộng được cả hai chiều, và các cơ chế quen thuộc của EC2 (load balancer, Auto Scaling group, EBS) không áp dụng cho ElastiCache.

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

Đáp án theo tệp là A và E.

A — Add additional nodes to the existing ElastiCache cluster (scale horizontally). Engine Memcached hỗ trợ chia dữ liệu ra nhiều node trong cùng một cluster. Muốn mở rộng theo chiều ngang thì chỉ cần thêm (hoặc bớt) node — số node trong một Memcached cluster nằm trong một khoảng do dịch vụ quy định, và bạn điều chỉnh trực tiếp trên cluster đang chạy. Mỗi node mới mang theo CPU riêng của nó, nên tải đọc/ghi được rải mỏng ra và mức CPU trên từng node giảm xuống. Đây đúng là cách xử lý nghẽn CPU.

E — Vertically scale the ElastiCache cluster by changing the node type. Cách còn lại là đổi sang node type mạnh hơn (nhiều vCPU hơn). Lưu ý điểm đặc thù mà tài liệu nhấn mạnh: với Memcached, việc scale theo chiều dọc được thực hiện bằng cách tạo cluster mới với node type mong muốn, và cluster Memcached luôn khởi đầu rỗng trừ khi ứng dụng tự nạp lại dữ liệu vào. Đây là cái giá phải trả (cache lạnh sau khi đổi), nhưng nó vẫn là một cách hợp lệ và trực tiếp để tăng CPU cho cluster.

Cả hai phương án đều tấn công đúng vào thứ đang thiếu: năng lực CPU.

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

B — Add a load balancer to route traffic to the ElastiCache cluster. Đây là phương án gần đúng nhất về mặt trực giác: thấy tải cao thì nghĩ tới chia tải. Nhưng nó hỏng ở chỗ client Memcached không nói chuyện qua load balancer. Việc phân phối dữ liệu giữa các node được quyết định ở phía ứng dụng: client băm key và tự chọn node tương ứng (key space mapping, thường qua consistent hashing trong thư viện client). Một load balancer đứng chắn phía trước sẽ đẩy request tới node ngẫu nhiên, làm sai hoàn toàn ánh xạ key → node, dẫn tới cache miss hàng loạt chứ không giảm được CPU. ElastiCache cung cấp cấu hình endpoint để client tự khám phá danh sách node, đó mới là cơ chế đúng.

C — Add a larger Amazon EBS volume to the ElastiCache cluster nodes. Sai ở hai tầng. Thứ nhất, vấn đề trong đề là CPU, thêm dung lượng lưu trữ không tạo ra thêm chu kỳ CPU nào — kể cả nếu làm được thì cũng không chạm tới triệu chứng. Thứ hai, Memcached là cache in-memory thuần: dữ liệu nằm trong RAM của node, người dùng không gắn thêm EBS volume vào node ElastiCache theo kiểu quản trị EC2. Phương án này áp mô hình EC2 lên một dịch vụ được quản lý.

D — Create an Auto Scaling group for the ElastiCache cluster. Đây cũng là bẫy quen thuộc: Auto Scaling group là khái niệm của EC2, không dùng cho các node ElastiCache. Bạn không bọc node cache vào một ASG rồi để nó tự thêm/bớt instance. Việc thay đổi số node của Memcached cluster được làm qua chính API/console của ElastiCache (như phương án A mô tả), chứ không qua ASG. Ngoài ra, ngay cả khi có cơ chế tự động, nó cũng không phải là "remediation step" trực tiếp cho một sự cố CPU đang diễn ra như đề đang mô tả.

📌 Điểm cần nhớ

• Memcached mở rộng được cả hai chiều: horizontal bằng cách thêm/bớt node trong cluster, vertical bằng cách đổi node type. Câu hỏi kiểu "CPU cao trên ElastiCache, chọn hai" gần như luôn nhắm vào đúng cặp này.
• Scale vertical với Memcached đồng nghĩa với cluster mới và cache rỗng — dữ liệu không được mang theo, ứng dụng phải tự nạp lại. Đây là khác biệt cần nhớ khi so với các lựa chọn scale khác.
• Load balancer không dùng để phân phối traffic tới node Memcached. Việc ánh xạ key sang node là trách nhiệm của client/ứng dụng; chèn load balancer vào giữa sẽ phá vỡ ánh xạ đó.
• Auto Scaling group và EBS volume là khái niệm của EC2, không áp cho node ElastiCache. Thấy phương án nào mang các khái niệm quản trị EC2 gán vào một dịch vụ được quản lý như ElastiCache thì nên nghi ngờ ngay.

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

Đề mô tả một SysOps Administrator dùng Amazon Inspector để quét bảo mật và tuân thủ cho các EC2 instance, nhưng phát hiện một số instance bị thiếu security findings — nghĩa là dịch vụ vẫn chạy, vẫn có kết quả cho phần lớn instance, chỉ riêng vài máy thì không ra kết quả.

Cụm từ quyết định đáp án là "missing for some instances". Nếu Inspector cấu hình sai ở mức tài khoản hoặc mức assessment target thì toàn bộ instance sẽ không có findings, chứ không phải chỉ vài máy. Việc kết quả thiếu theo từng máy trỏ thẳng tới một thành phần được cài đặt và chạy trên chính instance đó — tức là Inspector agent. Máy nào không có agent, hoặc agent chết/không gửi được dữ liệu telemetry, thì máy đó không có findings, còn các máy khác vẫn bình thường.

Câu hỏi cũng chỉ yêu cầu hành động để "attempt to resolve" — tức là bước xử lý sự cố hợp lý đầu tiên, không phải một giải pháp kiến trúc lớn.

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

D. Verify that the Amazon Inspector agent is installed and running on the affected instances and then restart the agent.

Inspector agent là thành phần chạy bên trong EC2 instance, có nhiệm vụ thu thập thông tin về package đã cài, cấu hình phần mềm và hành vi của hệ điều hành, rồi gửi về dịch vụ telemetry của Inspector. Không có dữ liệu này thì Inspector không có gì để đánh giá, và instance đó đơn giản là không xuất hiện findings.

Vì vậy hành động đúng là kiểm tra theo đúng hai bước mà phương án nêu ra:

1. Xác minh agent đã được cài trên các instance bị ảnh hưởng — nếu chưa có thì cài.
2. Xác minh agent đang chạy, và restart agent — trường hợp agent đã cài nhưng ở trạng thái treo hoặc ngừng gửi dữ liệu, việc khởi động lại thường khiến nó đẩy thông tin lên telemetry service trở lại.

Đây đúng là quy trình khắc phục nhắm vào phạm vi lỗi mà đề mô tả: lỗi cục bộ trên từng máy, xử lý trên từng máy.

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

A. Verify that the unified agent for Amazon CloudWatch is installed... collecting the necessary metrics. Đây là phương án gây nhiễu mạnh nhất vì cũng nói về "agent trên instance" — đúng hướng chẩn đoán nhưng sai tên agent. CloudWatch unified agent phục vụ việc thu thập metrics và log cho CloudWatch; Amazon Inspector không lấy dữ liệu đánh giá bảo mật từ CloudWatch agent. Cài hay cấu hình lại CloudWatch agent cũng sẽ không sinh thêm findings nào cho Inspector.

B. Generate the missing security findings list manually by logging in to the affected EC2 instances and running CLI commands. Sai vì đây là làm thay việc của dịch vụ. Findings là kết quả do Inspector sinh ra từ dữ liệu agent gửi lên; không có quy trình "tự tay tạo findings còn thiếu" bằng cách SSH vào máy chạy lệnh. Ngoài ra cách này hoàn toàn thủ công, không lặp lại được và không sửa được nguyên nhân gốc — lần quét sau vẫn thiếu y như cũ.

C. Move the instances to a public subnet and attach an Elastic IP address to ensure connectivity to the Amazon Inspector service. Phương án này có một hạt nhân đúng: instance cần liên lạc được tới endpoint của Inspector. Nhưng kết luận thì sai. Instance nằm trong private subnet vẫn ra ngoài được thông qua NAT Gateway hoặc NAT instance, nên không hề bắt buộc phải chuyển sang public subnet và gắn Elastic IP. Đây còn là hành động đánh đổi bảo mật rất tệ: mở địa chỉ public cho các máy vốn đang được che kín, chỉ để chữa một vấn đề nhiều khả năng nằm ở agent.

📌 Điểm cần nhớ

• Phạm vi lỗi chỉ ra tầng lỗi. Thiếu dữ liệu ở một số instance → nghi thành phần chạy trên chính instance (agent). Thiếu ở tất cả → nghi cấu hình mức dịch vụ, assessment target hoặc IAM.
• Amazon Inspector agent thu thập package và cấu hình phần mềm trên EC2 rồi gửi về telemetry service. Không có agent hoạt động thì máy đó không có findings.
• Đừng lẫn agent này với agent khác. CloudWatch unified agent lo metrics/log, không cung cấp dữ liệu cho Inspector. Đề thi rất hay đặt hai agent cạnh nhau làm mồi nhử.
• Private subnet + NAT là đủ để ra endpoint AWS. Bất kỳ phương án nào đòi chuyển máy sang public subnet hoặc gắn Elastic IP "để có kết nối" đều đáng nghi: nó vừa không cần thiết, vừa làm giảm mức bảo mật.

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

Đề mô tả một ứng dụng lưu các file cấu hình trong một Amazon S3 bucket, và yêu cầu: "A history of revisions of the configuration files must be maintained in case a rollback is required" — phải giữ được lịch sử các bản chỉnh sửa của cùng một file, để khi cần thì quay ngược về bản trước.

Cụm từ quyết định là "history of revisions ... in case a rollback is required". Đây không phải yêu cầu về phân loại dữ liệu, không phải yêu cầu về chi phí lưu trữ, cũng không phải yêu cầu về truy cập từ trình duyệt. Nó nói đúng một chuyện: cùng một object key, nhiều bản nội dung khác nhau theo thời gian, và lấy lại được bản cũ. Trong S3, đó chính là định nghĩa của versioning.

Một chi tiết nữa đáng chú ý: các file cấu hình bị ghi đè liên tục theo cùng tên. Mặc định S3 ghi đè object là mất bản cũ vĩnh viễn — nên câu hỏi thực chất hỏi "làm sao để lần ghi đè tiếp theo không xoá mất bản trước".

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

Đáp án đúng theo tệp là B — Enable versioning on the S3 bucket.

Versioning là cơ chế giữ nhiều biến thể của cùng một object trong cùng một bucket. Khi bật versioning, mỗi lần ghi vào cùng một key, S3 không đè lên nội dung cũ mà tạo thêm một version mới với version ID riêng; các version trước vẫn còn nguyên và truy xuất được. Nhờ vậy bạn preserve, retrieve và restore được mọi phiên bản của mọi object trong bucket.

Đúng với kịch bản của đề: file cấu hình sửa sai thì chỉ cần lấy lại version trước đó — đó chính là "rollback". Versioning cũng bảo vệ khỏi cả hai loại sự cố: thao tác nhầm của con người và lỗi của ứng dụng. Ngay cả khi S3 nhận nhiều write request đồng thời cho cùng một object, nó vẫn lưu lại tất cả các object đó.

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

A. Enable object tagging on the S3 bucket — Tagging chỉ gắn metadata dạng cặp key–value lên object, phục vụ phân loại, lọc, phân quyền theo tag hoặc làm điều kiện cho lifecycle. Tag không nhân bản nội dung và không giữ lại nội dung cũ: ghi đè object thì tag mới đi cùng nội dung mới, còn nội dung cũ vẫn mất. Nó mô tả object chứ không lưu trữ lịch sử của object.

C. Enable cross-origin resource sharing on the S3 bucket — CORS là cấu hình cho phép trình duyệt ở một origin (tên miền) gọi tài nguyên nằm ở origin khác. Đây thuần tuý là chuyện truy cập từ phía web client, hoàn toàn không liên quan tới việc giữ bản sao các phiên bản của object. Bật hay tắt CORS không ảnh hưởng gì tới dữ liệu bị ghi đè.

D. Enable a lifecycle policy on the S3 bucket — Đây là phương án gần đúng nhất và dễ chọn nhầm, vì lifecycle policy nghe như "quản lý object theo thời gian". Nhưng việc nó làm là chuyển dữ liệu giữa các storage class hoặc xoá object khi đến hạn — tức là quyết định object nằm ở đâu và sống bao lâu, không tạo ra hay giữ lại các bản revision. Chỗ hỏng cụ thể: nếu chỉ bật lifecycle mà không có versioning, ghi đè file cấu hình vẫn mất bản cũ, chẳng có gì để rollback. Lifecycle chỉ bổ trợ cho versioning (ví dụ dọn bớt các version cũ), chứ tự nó không đáp ứng được yêu cầu của đề.

📌 Điểm cần nhớ

• Từ khoá "revisions" / "previous version" / "rollback" / "recover an overwritten object" trong đề S3 → nghĩ ngay tới versioning, đó là cơ chế duy nhất giữ nhiều bản của cùng một object key.
• Phân biệt rành mạch bốn nhóm tính năng S3 hay bị trộn trong đề: versioning = giữ lịch sử phiên bản; lifecycle = chuyển storage class và hết hạn/xoá; tagging = metadata để phân loại và ra điều kiện; CORS = cho phép trình duyệt gọi chéo origin.
• Mặc định (chưa bật versioning), ghi đè một object trong S3 là mất bản cũ vĩnh viễn — bảo vệ dữ liệu khỏi thao tác nhầm phải bật trước, không "cứu" được sau khi đã ghi đè.
• Lifecycle và versioning thường đi cùng nhau nhưng vai trò khác nhau: bật versioning để có bản cũ, dùng lifecycle để dọn bớt bản cũ. Đề hỏi "giữ lịch sử" thì chọn versioning, đề hỏi "giảm chi phí lưu trữ theo thời gian" mới chọn lifecycle.

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

Đề mô tả một công ty có data center đặt ngay tại văn phòng, và đưa ra hai ràng buộc phải thoả cùng lúc:

1. "low-latency local access to image files for users in the office" — người dùng ngồi tại văn phòng phải đọc file ảnh với độ trễ thấp, nghĩa là dữ liệu phải nằm ngay tại chỗ, không đi qua đường truyền Internet mỗi lần đọc.
2. "A synchronized backup of the images must be maintained in an offsite location" — đồng thời phải có bản sao được đồng bộ ở nơi khác, phục vụ disaster recovery.

Cụm từ quyết định là "local access ... while also providing for disaster recovery". Chữ while also nói rõ đây không phải bài toán chọn một trong hai: một giải pháp chỉ để dữ liệu trên cloud rồi truy cập qua mạng sẽ trượt vế thứ nhất; một giải pháp chỉ để dữ liệu tại chỗ sẽ trượt vế thứ hai. Chỉ phương án nào giữ bản đầy đủ tại chỗ và tự đẩy bản sao lên AWS mới đạt cả hai.

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

Đáp án đúng là A — AWS Storage Gateway (volume gateway) ở chế độ stored volume, mount từ client qua iSCSI.

Volume gateway chạy ở hai chế độ, và sự khác nhau giữa chúng chính là mấu chốt của câu này:

• Cached volume: toàn bộ volume nằm trong Amazon S3 của dịch vụ, chỉ phần dữ liệu vừa truy cập được giữ trong cache cục bộ của gateway.
• Stored volume: toàn bộ dữ liệu nằm sẵn ngay trên gateway tại chỗ, nên đọc rất nhanh; song song đó volume gateway duy trì một bản sao bất đồng bộ (asynchronous copy) của volume đó lên S3 bucket của dịch vụ, dưới dạng snapshot.

Ánh xạ đúng vào hai yêu cầu của đề: ảnh được phục vụ với độ trễ thấp từ chính appliance/máy ảo Storage Gateway đặt trong văn phòng, còn snapshot trên S3 là bản sao offsite dùng để khôi phục khi có sự cố. Client trong văn phòng mount volume này qua iSCSI — đúng giao thức mà volume gateway trình ra cho máy chủ tại chỗ.

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

B — Amazon S3 kèm S3 Transfer Acceleration để "duy trì cache cho file hay dùng". Đây là phương án gài bẫy bằng chữ cache, nhưng mô tả sai công dụng của tính năng. Transfer Acceleration không tạo cache cục bộ nào cả — nó định tuyến lưu lượng qua edge location của CloudFront để tăng tốc việc truyền dữ liệu tới/lui S3 (đặc biệt là upload từ xa). Dữ liệu vẫn nằm trên S3, tức vẫn ở phía AWS, nên vế "low-latency local access" không được đáp ứng.

C — Lưu ảnh trên S3 rồi dùng AWS Server Migration Service để đồng bộ dữ liệu S3 xuống máy chủ tại chỗ. Sai ngay ở chỗ dùng sai dịch vụ: AWS SMS là công cụ migrate server (chuyển máy chủ on-premises lên AWS), không phải cơ chế đồng bộ dữ liệu hai chiều giữa S3 và máy chủ nội bộ. Không có chức năng "đồng bộ S3 về local server" như phương án mô tả, nên kiến trúc này không tồn tại được.

D — Mount một Amazon EFS volume lên máy chủ tại chỗ rồi chia sẻ cho nhân viên. Đây là phương án gần đúng nhất về mặt hình thức, vì EFS đúng là file system chia sẻ và có thể được mount. Nhưng nó hỏng ở cả hai vế: file system thực sự vẫn nằm trong AWS, nên mỗi lượt đọc ảnh đều phải đi qua đường truyền ra ngoài — không phải local access độ trễ thấp như đề đòi. Và bản thân việc mount EFS cũng không tạo ra bản sao offsite nào của dữ liệu như một cơ chế DR; ở đây chỉ có một bản dữ liệu duy nhất, đặt ở nơi xa người dùng.

📌 Điểm cần nhớ

• Đề bài đòi vừa đọc nhanh tại chỗ vừa có bản sao offsite gần như luôn trỏ tới AWS Storage Gateway — đây là dịch vụ được thiết kế đúng cho kiểu kiến trúc hybrid đó.
• Phân biệt hai chế độ của volume gateway: stored volume = toàn bộ dữ liệu ở local, bản sao đẩy lên S3; cached volume = dữ liệu chính ở S3, chỉ phần nóng nằm trong cache local. Đề nhấn mạnh "toàn bộ truy cập nhanh tại chỗ" thì chọn stored.
• Volume gateway trình dữ liệu ra cho client bằng iSCSI (dạng block). Thấy chữ iSCSI trong phương án là dấu hiệu đang nói tới volume gateway.
• S3 Transfer Acceleration không phải là cache, nó chỉ tăng tốc đường truyền tới S3. Và AWS Server Migration Service dùng để di chuyển server, không phải để đồng bộ dữ liệu — hai dịch vụ này hay bị mô tả sai chức năng trong các phương án nhiễu.